1

Chapter 3Prescriptive Process

ModelsSoftware Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

Software process model Attempt to organize the software life cycle by

defining activities involved in software production order of activities and their relationships

Goals of a software process standardization, predictability, productivity, high

product quality, ability to plan time and budget requirements

Code&FixThe earliest approach Write code Fix it to eliminate any errors that have been

detected, to enhance existing functionality, or to add new features

Source of difficulties and deficiencies impossible to predict impossible to manage

Models are needed Symptoms of inadequacy: the software

crisis scheduled time and cost exceeded user expectations not met poor quality

The size and economic value of software applications required appropriate "process models"

Process model goals (B. Boehm 1988)

"determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions:

What shall we do next?How long shall we continue to do it?"

Process as a "black box"

Product

Process

Informal Requirements

Quality?Uncertain /Incomplete requirementIn the beginning

Problems The assumption is that requirements can be

fully understood prior to development Interaction with the customer occurs only at

the beginning (requirements) and end (after delivery)

Unfortunately the assumption almost never holds

Process as a "white box"

Product

Process

Informal Requirements

feedback

Advantages Reduce risks by improving visibility Allow project changes as the project

progresses based on feedback from the customer

The main activities of software production They must be performed independently

of the model The model simply affects the flow

among activities

11

Prescriptive Models

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?

Prescriptive process models advocate an Prescriptive process models advocate an orderly approach to software engineeringorderly approach to software engineering

12

The Waterfall Model

13

Waterfall Model Assumptions1. The requirements are knowable in advance of implementation.

2. The requirements have no unresolved, high-risk implications e.g., risks due to COTS choices, cost, schedule, performance,

safety, security, user interfaces, organizational impacts3. The nature of the requirements will not change very much

During development; during evolution4. The requirements are compatible with all the key system

stakeholders’ expectations e.g., users, customer, developers, maintainers, investors

5. The right architecture for implementing the requirements is well understood.

6. There is enough calendar time to proceed sequentially.

14

Process for Offshore?

Deploy

Analysis

Design

Accept. test

Construct

System test

15

The V ModelIf we rely on testing alone, defects created first are detected last

SystemRequirements

SoftwareRequirements

SoftwareDesign

SoftwareImplementation

UnitTesting

IntegrationTesting

SoftwareTesting

SystemTesting

system test plan

software test plan

integration plan

unit plan

ProductRelease

time

UserNeed

16

Incremental Models: Incremental

17

Incremental Models: RAD Model

18

Evolutionary Models: Prototyping

19

Risk Exposure

20

Unified Process ModelA software process that is:A software process that is:

use-case drivenuse-case driven architecture-centricarchitecture-centric iterative and incrementaliterative and incremental

Closely aligned with theClosely aligned with theUnified Modeling Language Unified Modeling Language (UML)(UML)

21

inception

The Unified Process (UP)

22

UP Work Products

inception

23

Lifecycle for Enterprise Unified Process

inception

24

Synchronize-and Stabilize Model Microsoft’s life-cycle model Requirements analysis—interview potential

customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small teams

working in parallel

25

Synchronize-and Stabilize Model (contd) At the end of the day—synchronize (test and

debug) At the end of the build—stabilize (freeze build) Components always work together

Get early insights into operation of product

26

Evolutionary Models: The Spiral

27

Spiral Model Simplified form

Waterfall model plus risk analysis

Precede each phase by Alternatives Risk analysis

Follow each phase by Evaluation Planning of next

phase

28

Simplified Spiral Model If risks

cannot be resolved, project is immediately terminated

29

Full Spiral Model Radial dimension: cumulative cost to date Angular dimension: progress through the

spiral

30

Full Spiral Model (contd)

31

Analysis of Spiral Model Strengths

Easy to judge how much to test No distinction between development, maintenance

Weaknesses For large-scale software only For internal (in-house) software only

32

Object-Oriented Life-Cycle Models Need for iteration within and between phases

Fountain model Recursive/parallel life cycle Round-trip gestalt Unified software development process

All incorporate some form of Iteration Parallelism Incremental development

Danger CABTAB

33

Fountain Model Features Overlap

(parallelism) Arrows

(iteration) Smaller

maintenance circle

34

Software Process Spectrum

lightweight heavyweightmiddleweight

XPSCRUM

DSDMFDD RUPdX

ICONIXCrystal Clear Crystal Violet

EUPOPEN

35

Conclusions Different life-cycle models Each with own strengths Each with own weaknesses Criteria for deciding on a model include

The organization Its management Skills of the employees The nature of the product

Best suggestion “Mix-and-match” life-cycle model

36

Model Driven Architecture

37

What is MDA in essence? Automated approach to translate high level

design to low level implementation by means of separation of concerns

From high-level model to running application

Risk proportional to expectations!

38

Finding the “right” language

Assembler

3GL

IDEs & 4GL

Model Driven Architecture

Computer Hardware

Developer Autom

ation

Abstraction

39

“ You should use iterative development only on projects you want to

succeed”

Martin Fowler

40

Model Driven Architecture Can you actually have incremental MDA?

Or is it automated waterfall?

Need rigorous models Need high quality requirements

Capture requirements Understand requirements

41

MDA or Offshore? Automation versus reduce cost of labor

Objectives Reduce required intelligence Increase repetition

Goal Reduce costs of development