1

Chapter 3 Process Models

2

Prescriptive Models What is it

A prescriptive process model defines a distinct set of activities, actions, tasks, milestones, and work products to engineering high-quality software.

Prescriptive process models advocate an orderly approach to software engineering

That leads to a few questions … If prescriptive process models strive for structure and order, are

they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they

imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

3

Prescriptive Models (cont.)

Regardless of the process model selected, it should accommodate the following generic framework activities: communication planning modeling construction deployment

4

Process Models

Waterfall model Incremental process models

Incremental model RAD (rapid application development) model

Evolutionary process models Prototyping model Spiral model Concurrent development model

5

The Linear Model

Waterfall model Winston Royce, 1970 Also called the software life cycle

Communication Planning

ModelingConstruction

Deployment analysis design code

test

project initiation requirement gathering estimating

scheduling tracking

delivery support feedback

6

Problems of Waterfall Model

Real projects rarely follow the sequential flow that the model proposes

It is often difficult for the customer to state all requirements explicitly

The customer must have patience Applicable only when the requirements are well-

defined and stable

7

The Incremental Model

The objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements

This model combines elements of waterfall model applied in an iterative fashion

Particular useful when staffing is limited in initial stage

8

The Incremental Model (cont.)

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e ry f e e d b a c k

analys is

des ign code

t es t

increment # 1

increment # 2

delivery of 1st increment

delivery of 2nd increment

delivery of nth increment

increment # n

project calendar time

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

De p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des ign code

t es t

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des igncode t es t

9

The RAD Model

Rapid Application Development is an incremental software development process model, emphasizing a short development cycle (e.g., 60 to 90 days)

For application’s requirement been well understood

10

Communication

Planning

Modelingbusiness modeling data modeling process modeling

Constructioncomponent reuse automatic code generation testing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data modeling process modeling

Constructioncomponent reuse automatic code

generation test ing

Modelingbusiness modeling data modeling process modeling

Const ruct ioncomponent reuse automatic code generation testing

Team # 2

Team # n

integration delivery feedback

The RAD Model (cont.)

11

Need sufficient RAD teams for large, scalable projects

Easy to fail if developers and users are not committed to rapid-fire activities

The system need to be properly modularized May not be appropriate if high performance is an

issue May not be appropriate when technical risks are

high

Drawbacks of RAD Model

12

Objective is to understand the system requirements. Should start with poorly understood requirements

More commonly adopted within the context of any process model

Problems “prototype” yes, it’s a prototype Compromise (less-than-ideal) while implementation

The Prototyping Model

13

The Prototyping Model (cont.)

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

14

The Spiral Model

Originally proposed by Boehm Emphasize on risk management Using this model, software is developed in a

series of evolutionary releases The spiral model can be adapted to apply

throughout the life of the software It is a realistic model to the development of

large-scale systems

15

The Spiral Model

communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

16

Drawbacks of Spiral Model

May difficult to convince customers to adopt the model – uncertain number of cycles to construct the product

Requires considerable risk assessment expertise

Problems will occur if a major risk is not uncovered and managed

17

Concurrent Development Model

Also known as concurrent engineering Represented as a series of framework activities,

software engineering actions and tasks, and associated states

Define a series of events that will trigger transition from state to state

Provide an accurate picture of project current state

18

Concurrent Development Model

Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling activity

represents the stateof a software engineeringactivity or task

19

Still Other Process Models

Component-based development model The process to apply when reuse is a development

objective It is evolutionary in nature It incorporates the following steps

Research and evaluate available component-based products Consider component integration issues Design a software architecture to accommodate the

components Integrate components into the architecture Conduct comprehensive testing

20

Still Other Process Models (cont.)

Formal methods model The process to apply when a mathematical specification is to be

developed Ambiguity, incompleteness, and inconsistency can be discovered

and corrected more easily – promise of defect-free software Drawbacks

Time-consuming and expensive Need extensive training Hard to serve as a communication mechanism

Useful for safety-critical software, e.g., Aircraft avionics, medical devices

21

Still Other Process Models (cont.)

Aspect-oriented software development (AOSD) Aspect – customer concerns that cut across multiple system

functions, features and information, e.g., User interface aspects Distribution aspects (transport and receiving) Persistence aspects (data store/retrieve and indexing) Security aspects Transaction aspects

AOSD provides a process and methodological approach for defining, specifying, designing, and constructing aspects (modeled as components)

22

The Unified Process

What is UP Developed by Ivar Jacobson, James Rumbaugh, and

Grady Booch A framework for object-oriented software engineering using

UML (the Unified Modeling Language), an industry standard for object-oriented software development

It is a use-case driven, architecture-centric, iterative, and incremental model

23

The Unified Process (cont.)

Phases of UP Inception

Identify business requirements, described as use-cases Propose a rough system architecture

Elaboration Refine and expand the preliminary use-cases Expand the architecture to include five different views

Use-case model, analysis model, design model, implementation model, deployment model

24

The Unified Process (cont.)

Construction Develop or acquires the software components to

accomplish an initial release Transition

Software is given to users for beta-testing to collect defects and necessary changes

Create support information, e.g., user manuals, installation procedures, trouble-shooting guides

Production Monitor the on-going use of the software, and evaluate

defect reports and change requests

25

inceptioninception

The Unified Process (UP)

software increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration

26

UP Phases

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

27

UP Work Products

Inception phase

Elaboration phase

Construction phase

Transition phase

Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n

Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals description of current increment

Delivered software increment Beta test reports General user feedback