Transcript Transparency Masters for Software Engineering: A

Chapter 3
Prescriptive Process Models
SWE311_Ch03 (071)
Software & Software Engineering
Slide 1
Overview

Prescriptive process models prescribe a distinct set of
activities, actions, tasks, milestones, and work products
required to engineer high quality software.

Prescriptive software process models are adapted to
meet the needs of software engineers and managers for
a specific project.

Prescriptive software models provide stability, control,
and organization to a process that if not managed can
easily get out of control.

Framework activities for a particular process model may
be organized into a process flow that may be linear,
incremental, or evolutionary.
SWE311_Ch03 (071)
Software & Software Engineering
Slide 2
Overview (cont)

The software engineer's work products (programs,
documentation, data) are produced as a consequence of
the activities defined by the software process.

The best indicators of how well a software process has
worked are the quality, timeliness, and long-term viability
of the resulting software product.
SWE311_Ch03 (071)
Software & Software Engineering
Slide 3
Objectives



Introduce process models and the roles they play in a
software engineering environment
Give examples of some of the most common process
models
Provide means of comparing process model
SWE311_Ch03 (071)
Software & Software Engineering
Slide 4
Software Process


Aimed to control the activities of software development
and as such improve quality...
A structured set of activities for





Specifying,
Designing,
Implementing and
Testing software systems
A software process model is an abstract representation
of a process

a description of a process from a particular perspective
SWE311_Ch03 (071)
Software & Software Engineering
Slide 5
Software Process Models

Software process models are general approaches for
organizing a project into activities

Help the project manager and his team to decide:




What work should be done
In what sequence to perform the work
The models should be seen as aids to thinking, not rigid
prescriptions of the way to do things
Each project ends up with its own unique plan because
 Projects differs in the nature of the project, people doing the
work, and the work environment
SWE311_Ch03 (071)
Software & Software Engineering
Slide 6
Prescriptive Models

Prescriptive process models advocate an orderly approach to software
engineering
Organize framework activities in a certain order
Originally proposed to bring order to the chaos of software development
They brought order to software engineering work and provide reasonable guidance to
software teams




Adopt following activities






Communication
Planning
Modeling
Construction
Deployment
Differ in


Emphasis of these activities
Manners in which the framework is invoked and its relationship with other
activities
SWE311_Ch03 (071)
Software & Software Engineering
Slide 7
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?
SWE311_Ch03 (071)
Software & Software Engineering
Slide 8
Software Processes

Every software engineering organization needs to
describe a set of framework activities for the processes it
adopts

Each framework activity needs to be populated with
software engineering actions

Each engineering action needs to be defined in terms of
a task set that defines the work and work products
needed to meet the development goals

The resulting process model should be adapted to
accommodate the nature of the specific project, people
doing the work, and the work environment
SWE311_Ch03 (071)
Software & Software Engineering
Slide 9
Software Processes (cont)

Regardless of the process model selected, software
engineers will chose a generic process framework that
includes these activities: communication, planning,
modeling, construction, and deployment

Each process model will prescribe a set of process
elements (framework activities, software engineering
actions, tasks, work products, quality assurance, and
change control mechanisms) and a workflow (the
manner in which the process elements are interrelated)

All software process models discussed in this chapter
can accommodate the generic framework activities
described previously
SWE311_Ch03 (071)
Software & Software Engineering
Slide 10
The Waterfall Model
Com m unic a t ion
proje c t init ia t ion
re quire m e nt ga t he ring
Planning
estimat ing
scheduling
tracking
Mode ling
analysis
design
Const r uc t ion
code
t est
De ploy m e nt
de liv e ry
s upport
f e e dba c k
Old fashioned but reasonable approach when requirements are well
understood
SWE311_Ch03 (071)
Software & Software Engineering
Slide 11
Limitations of the waterfall model

The model implies that you should attempt to complete a
given stage before moving on to the next stage






Does not account for the fact that requirements constantly
change.
It also means that customers can not use anything until the
entire system is complete.
The model makes no allowances for prototyping.
Assumes understanding of problem and full
requirements early on
It implies that you can get the requirements right by
simply writing them down and reviewing them.
Inflexible partitioning of the project into distinct stages makes
it difficult to respond to changing customer requirements.
SWE311_Ch03 (071)
Software & Software Engineering
Slide 12
Critique of Waterfall Model






continued
Followed systematic approach to development
The model implies that once the product is
finished, everything else is maintenance.
Assumes patience from customer
Surprises at the end are very expensive
Some teams sit ideal for other teams to finish
Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly
limited during the design process.
SWE311_Ch03 (071)
Software & Software Engineering
Slide 13
The Incremental Model
increment # n
Co m m u n i c a t i o n
Pla nning
M ode ling
analy s is
des ign
Co n s t ru c t i o n
c ode
t es t
De p l o y m e n t
d e l i v e ry
fe e dba c k
deliv ery of
nt h increment
increment # 2
Co m m u n i c a t i o n
Pla nning
M ode ling
analy s is
des ign
Co n s t ru c t i o n
c ode
De p l o y m e n t
t es t
d e l i v e ry
fe e dba c k
increment # 1
deliv ery of
2nd increment
Co m m u n i c a t i o n
Pla nning
M ode ling
analy s is
des ign
Co n s t ru c t i o n
c ode
De p l o y m e n t
t es t
d e l i v e ry
fe e dba c k
deliv ery of
1st increment
project calendar t ime
Delivers software in small but usable pieces, each piece builds on pieces
already delivered
SWE311_Ch03 (071)
Software & Software Engineering
Slide 14
The Incremental Model


Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments with
each increment delivering part of the required functionality.
First Increment is often core product




First Increment is used or evaluated
A plan of next increment is prepared




Includes basic requirement
Many supplementary features (known & unknown) remain undelivered
Modifications of the first increment
Additional features of the first increment
It is particularly useful when enough staffing is not available for the
whole project
Increment can be planned to manage technical risks
SWE311_Ch03 (071)
Software & Software Engineering
Slide 15
The Incremental Model

User requirements are prioritised and the highest priority
requirements are included in early increments.

Once the development of an increment is started, the
requirements are frozen though requirements for later increments
can continue to evolve.
Customer value can be delivered with each increment so system
functionality is available earlier.


Early increments act as a prototype to help elicit requirements for
later increments.

Lower risk of overall project failure.

The highest priority system services tend to receive the most testing.
SWE311_Ch03 (071)
Software & Software Engineering
Slide 16
The RAD Model
Team # n
M o d e lin g
bus ines s m odeling
dat a m odeling
proc ess m odeling
C o n s t r u c t io n
c om ponent reus e
aut om at ic c ode
generat ion
t est ing
Team # 2
Com m unicat ion
Mo d eling
b u si n e ss m o d e l i n g
dat a m odeling
p ro ce ss m o d e l i n g
Planning
Co nst r uct io n
Team # 1
co m p o n e n t re u se
a u t o m a t i c co d e
g e n e ra t i o n
t e st i n g
Mode ling
De ploym e nt
int egrat ion
deliv ery
feedback
business modeling
dat a modeling
process modeling
Const r uct ion
component reuse
aut omat ic code
generat ion
t est ing
6 0 - 9 0 days
Makes heavy use of reusable software components with an extremely short
development cycle
SWE311_Ch03 (071)
Software & Software Engineering
Slide 17
Critique of RAD

If requirements are well understood and project scope is
constrained



Construction emphasizes the reuse and the automatic
code generation
For large but scalable projects




Very short development time
RAD requires sufficient human resources
Projects fail if developers and customers are not
committed in a much abbreviated time-frame
Problematic if system can not be modularized
Not appropriate when technical risks are high
SWE311_Ch03 (071)
Software & Software Engineering
Slide 18
Evolutionary Models: Prototyping
Good first step when
customer has a legitimate
need, but is clueless about
the details, developer
needs to resist pressure to
extend a rough prototype
into a production product
Quick
plan ion
Com m unicat
Modeling
Quick design
Deployment
De live r y
& Fe e dback
Construction
of prototype
SWE311_Ch03 (071)
Software & Software Engineering
Qu ick p l an
Mo d e lin g
Qu ick d e sig n
Const r uct ion
of
pr ot ot ype
Slide 19
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
delivery
feedback
construction
code
test
Couples iterative nature of prototyping with the controlled and systematic
aspects of the linear sequential model
SWE311_Ch03 (071)
Software & Software Engineering
Slide 20
SWE311_Ch03 (071)
Software & Software Engineering
Slide 21
Evolutionary Models: Concurrent
none
Modeling act ivit y
represents the state
of a software engineering
activity or task
Under
Similar to spiral model often
used in development of
client/server applications
development
A wait ing
changes
Under review
Under
revision
Baselined
Done
SWE311_Ch03 (071)
Software & Software Engineering
Slide 22
Specialized Process
 Component based development—
Modelsspiral model variation in


which applications are built from prepackaged software
components called classes
Formal methods—emphasizes the mathematical
specification of requirements. Rigorous mathematical
notation used to specify, design, and verify computer-based
systems
Aspect-Oriented Software Development (AOSD)—provides a process
and methodological approach for defining, specifying,
designing, and constructing aspects like user interfaces,
security, and memory management that impact many parts
of the system being developed
SWE311_Ch03 (071)
Software & Software Engineering
Slide 23
Unified Process

Use-case driven, architecture centric, iterative, and incremental software
process closely aligned with the Unified Modeling Language (UML)

Attempts to draw on best features of traditional software process models
and implements many features of agile software development

Phases





Inception phase (customer communication and planning)
Elaboration phase (communication and modeling)
Construction phase
Transition phase (customer delivery and feedback)
Production phase (software monitoring and support)
SWE311_Ch03 (071)
Software & Software Engineering
Slide 24
The Unified Process (UP)
Elab
o r at io n
elaboration
Incep t io n
inception
inception
co nst r uct io n
Release
t r ansit io n
soft ware increment
p r o d uct io n
SWE311_Ch03 (071)
Software & Software Engineering
Slide 25
UP Phases
UP Phas e s
Incept ion
Elaborat ion
Const ruct ion
Transit ion
Product ion
Wor k flow s
Requirements
Analysis
Design
Implementation
Test
Support
Iterati ons
SWE311_Ch03 (071)
#1
#2
Software & Software Engineering
#n-1
#n
Slide 26
UP Work Products
Incept ion phase
Vision document
Init ial use-case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary .
One or more prot ot y pes
I nc e pt i o
n
SWE311_Ch03 (071)
Elaborat ion phase
Use-case model
Supplement ary requirement s
including non-funct ional
Analy sis model
Soft ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot y pe.
Preliminary design model
Rev ised risk list
Project plan including
it erat ion plan
adapt ed workflows
milest ones
t echnical work product s
Preliminary user manual
Const ruct ion phase
Design model
Soft ware component s
Int egrat ed soft ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
Software & Software Engineering
Transit ion phase
Deliv ered soft ware increment
Bet a t est report s
General user feedback
Slide 27
Attributes for Comparing Process Models




Overall flow and level of interdependencies among
tasks
Degree to which work tasks are defined within each
framework activity
Degree to which work products are identified and
required
Manner in which quality assurance activities are
applied
SWE311_Ch03 (071)
Software & Software Engineering
Slide 28
Attributes for Comparing Process Models
(cont)





Manner in which project tracking and control
activities are applied
Overall degree of detail and rigor of process
description
Degree to which stakeholders are involved in the
project
Level of autonomy given to project team
Degree to which team organization and roles are
prescribed
SWE311_Ch03 (071)
Software & Software Engineering
Slide 29