Chapter 3

Prescriptive Process Models

Software Engineering: A Practitioner’s Approach, 6th edition

by Roger S. Pressman

1
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&Fix

The 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"

Informal
Requirements
Process

Product

Quality?
Uncertain /
Incomplete
requirement
In 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"

Informal
Requirements
Process

Product

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
 Prescriptive Models
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?
11
The Waterfall Model

12
Waterfall Model Assumptions
1. 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 impacts
3. The nature of the requirements will not change very much
 During development; during evolution
4. 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.

13
Process for Offshore?
Analysis

Design
Construct

System test

Accept. test

Deploy

14
The V Model
If we rely on testing alone, defects
created first are detected last
User Product
Need System system test plan System Release
Requirements Testing
Software software test plan Software
Requirements Testing
integration plan
Software Integration
Design Testing
unit plan
Software Unit
Implementation Testing

time
15
Incremental Models: Incremental

16
Incremental Models: RAD Model

17
Evolutionary Models: Prototyping

18
Risk Exposure

19
Unified Process Model
A software process that is:

 use-case driven
 architecture-centric

 iterative and incremental

Closely aligned with the

Unified Modeling Language (UML)

20
The Unified Process (UP)

inception

21
UP Work Products

inception

22
Lifecycle for Enterprise Unified Process

inception

23
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

24
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

25
Evolutionary Models: The Spiral

26
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 27
Simplified Spiral Model
 If risks
cannot be
resolved,
project is
immediate
ly
terminate
d 28
Full Spiral Model
 Radial dimension: cumulative cost to date
 Angular dimension: progress through the
spiral

29
Full Spiral Model (contd)

30
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

31
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
32
Fountain Model
 Features
 Overlap
(parallelism)
 Arrows
(iteration)
 Smaller
maintenance
circle 33
 Software Process Spectrum

Crystal Clear Crystal Violet

DSDM ICONIX
XP OPEN
SCRUM dX FDD EUP RUP

lightweight middleweight heavyweight

34
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

35
Model Driven Architecture

36
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!

37
Finding the “right” language
Developer

Automation
Model Driven Architecture
Abstraction

IDEs & 4GL

3GL

Assembler

Computer Hardware
38
 “You should use iterative
development only on projects
you want to succeed”

Martin Fowler

39
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
40
MDA or Offshore?
 Automation versus reduce cost of labor

 Objectives
 Reduce required intelligence
 Increase repetition
 Goal
 Reduce costs of development
41