Chapter 3 Prescriptive Process Models

1
Chapter 3Prescriptive Process Models
Software Engineering A Practitioners Approach,
6th edition by Roger S. Pressman
2
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

3
CodeFix

• 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

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

5
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?"
6
Process as a "black box"
Quality?
Uncertain / Incomplete requirement In the
beginning
7
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

8
Process as a "white box"
9
Advantages

• Reduce risks by improving visibility
• Allow project changes as the project progresses
• based on feedback from the customer

10
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
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?

12
The Waterfall Model
13
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.

14
Process for Offshore?
Accept. test
Deploy
15
The V Model

• If we rely on testing alone, defects created
  first are detected last

16
Incremental Models Incremental
17
Incremental Models RAD Model
18
Evolutionary Models Prototyping
19
Risk Exposure
20
Unified Process Model

• A software process that is
• use-case driven
• architecture-centric
• iterative and incremental
• Closely aligned with the
• Unified Modeling Language (UML)

21
The Unified Process (UP)
inception
22
UP Work Products
inception
23
Lifecycle for Enterprise Unified Process
inception
24
Synchronize-and Stabilize Model

• Microsofts life-cycle model
• Requirements analysisinterview 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 daysynchronize (test and
  debug)
• At the end of the buildstabilize (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
Crystal Clear
Crystal Violet
ICONIX
DSDM
OPEN
XP
FDD
RUP
SCRUM
EUP
dX
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
Developer
Model Driven Architecture
Automation
Abstraction
IDEs 4GL
3GL
Assembler
Computer Hardware
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