Software Engineering: A Practitioner’s

Approach, 6/e

Chapter 3
Prescriptive Process Models
.
 Prescriptive Process Models
• Prescribe a distinct (‫(متميز‬set of activities, actions, tasks,
milestones, and work products required to engineer high quality
software.
• Adapted to meet the needs of software engineers and managers for
a specific project.
• 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.
• 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
 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?
• The following processes are called prescriptive because they
prescribe:
– a set of process elements
• framework activites, SE actions, tasks, work products,
quality assurance mechanisms, change control
mechanisms for each project.
– a workflow
• ie the manner in which the process elements are
interrelated to one another.
• All SW process models can accommodate the generic
framework activities but each applies emphasis to activities and
defines a workflow that invokes each framework activity in a
different way.
 The Waterfall Model
Communication
Project initiation
Requirements gathering

Planning
Estimating
Scheduling
Tracking
Modeling
Analysis
Design
Construction
Code
Test

Deployment
Delivery
Support
Feedback
 Characteristics of waterfall:
• Consists of a set of phases that a project progresses through in a
sequential order.
• Each phase must be completed before the project can progress to
the next phase.
• At the end of each phase is some form of gateway, usually a
formal review where that decision is made.
• There is no overlap between phases.
• Straight forward, simple to understand and use.
• Deliverables are frozen at the end of each phase and server as the
baseline for the following phases.
• You do not see the software until the end of the project (big bang
software development).
• Changes are not supposed to happen or are limited or are tightly
controlled.
 The Waterfall Model
• Also known as Linear Sequential Model
• Classic life cycle
• Advantages:
– old fashioned but reasonable approach when requirements are
well understood.
• Disadvantages:
– Real projects rarely follow a sequential flow which is why this
model sometimes fails..
– Difficult for customer to state all requirements explicitly
– No working version until late in development process.
• This model is often inappropriate for normal SW development
where the work is fast paced and subject to a never-ending stream
of changes to features, functions and information content.
 Process: Generic Phases
1. Definition phase: what to build
– Establish what the requirements of the system are
– Use system engineering, project planning, requirements
analysis
2. Development phase: how to build it
- Establish how the system is to be realized – design and build
– Use software design, code generation, testing
3. Support:
– Handle changes as the software environment evolves
– Must handle four types of changes: correction, adaptation,
enhancement, prevention
4. This process is complemented by a number of umbrella
activities, such as:
– project management, configuration control, risk
management
 Incremental Model

Deliver increasing functionality at each increment. First iteration is the core.

(+) manages risk, deals well with staffing problems, (-) can be slow
 The incremental model
• Combines elements of the linear model and prototyping
• Delivers a series of releases that provide progressively more
functionality for the customer as each increment is delivered.
• First increment often core product
• Focuses on operational product (not throw-away prototype)
• Used when not enough resources are available to deliver the complete
product in time
• Increments help to manage technical risks (e.g. currently unavailable
hardware)
• If the customer demands delivery by a date that is impossible to meet,
suggest delivering one or more increments by that date and the rest of
the SW ie additional increments later.
• Word processing example: 1st basic core functionality, 2nd extended
editing, 3rd spelling and grammar checks
 The RAD Model
Team # n
Mo de lin g
business modeling
data modeling
process modeling

Co n st ru ct io n
component reuse
Team # 2 automatic code
Communication generation
testing
Modeling
business modeling
data modeling
process modeling

Planning
Construction Deployment
Team # 1 component reuse integration
automatic code
generation delivery
Modeling testing feedback
business modeling
data modeling
process modeling

Construction
component reuse
automatic code
generation
testing

60 - 90 days
• Incremental SW process model emphasizes short
development cycles.
• RAD is a high speed adaptation of the waterfall model.
– Achieved by using component based construction.
• Requirements must be well understood.
• Project scope must be constrained.
• Each major function is addressed by a separate RAD
team in parallel and then integrated to form a whole.
• Drawbacks
– need sufficient human resources
– developers and customers must be committed to
communication.
– system must be modularizable.
– if performance is an issue, project may fail.
– if project makes heavy of a new technology, project is
at risk.
Evolutionary Models:
Prototyping
Quick
Quick plan
plan
Communication
communication

Modeling
Modeling
Quick design
Quick design

Deployment
Deployment
delivery &
Delivery
Construction
feedback
& Feedback Construction
of
of prototype
prototype
• SW evolves over time
• Requirements change as development proceeds
• Tight market deadlines sometimes makes delivery of
a complete product not possible.
• Core requirements are well understood but details or
system extensions have yet to be defined.
• This is when evolutionary process models make sense
– produce an increasingly more complete version of
the SW with each iteration.
 Prototypting
• Focuses on a representation of those aspects of the SW that are
visible to the end-used.
• It is deployed and then evaluated.
– Feedback is used to refine requirements and then iterated.
• Used when the customer has a legitimate need but clueless about
the details, develop a prototype first.
– Unsure of
• algorithm efficiency
• adaptability of the OS
• human-machine interaction
• Prototyping can be implemented within the context of any one of
the process models.
– Assists in understanding what is to be built when requirements
are fuzzy
 The benefits of prototyping are:
• a working model is provided to the customer/user early in the
process, enabling early assessment and bolstering confidence,
• the developer gains experience and insight by building the
model, thereby resulting in a more solid implementation of "the
real thing"
• the prototype serves to clarify otherwise vague requirements,
reducing ambiguity and improving communication between
developer and user.
• Increased customer satisfaction during development
phase.
 prototyping problems:
• The user sees and believes that the prototype (a model) can be
easily transformed into a production system.
• many users have pressured developers into releasing prototypes for
production use that have been unreliable,
• The developer often makes technical compromises to build a "quick
and dirty" model. Sometimes these compromises are propagated
into the production system, resulting in implementation and
maintenance problems.
• Prototyping does not aim to develop final working products ->
customer may disapprove of final “development” phase, turning
prototype into supportable product.
• product – Quality will suffer.
– usually implementation compromises have been make to get the
prototype working quickly.
– Possibly an inappropriate OS or programming language was
chosen
– Inefficient algorithm used.
Evolutionary Models: The
Spiral planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test
 The Spiral Model
• Customer communication: Establish effective
communication
• Planning: Define resources, timelines etc.
• Risk analysis: Assess technical and management risks
• Construction & release: construct, test, install, provide
user support
• Customer evaluation: obtain feedback
• Couples iterative nature of prototyping with controlled
and systematic aspect of the linear sequential model
• Early iterations may be paper models or prototypes
• Can be used throughout the life of the product
• Reduces risk if properly applied
 Spiral Model
• Couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model.
• Risk driven model
– Incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.
• Realistic approach to development of large-scale systems and
SW.
– The Developer and customer better understand and react to
risks at each evolutionary level as the SW evolves.
• Problematic for fixed-budget development
– project cost is revisited and revised as each circuit is
completed.
– Does not work in a contract situation.
• Demands considerable risk assessment expertise and relise on this
expertise for success.
 Evolutionary Models: Concurrent
Modeling activity
Under none
development

Awaiting
changes Under
review
Under
revision
Baselined

Done
 Concurrent Model
• Appropriate for system engineering projects where
different engineering teams are involved.
• Represented as a series of framework activites, software
engineering actions and tasks and their associated states.
– All activites exist concurrently but reside in different
states.
– A series of events trigger transitions from state to
state.
• Applicable to all types of SW development and provides
an accurate picture of the current state of a project.
• A event generated at one point in the process network,
triggers transitions among the states.
 The concurrent development model
• Defines a series of events that will trigger transitions
from state to state for each of the software engineering
activities.
• Concurrent process model: recognizes that different
stages of the project (analysis, design, coding) will have
achieved different states (e.g. under development,
awaiting changes, done, etc.)
– + provides accurate picture of current project state
– - must exist in parasitic relationship with another
model
 The Component-Based (OO) Model
identify
candidate
classes
Planning Risk 
Analysis
Customer  construct look­up
classes
Communicati nth iteration
of system in library
on

put new extract
classes classes
in library if available

engineer
classes
if unavailable
Customer    Engineering, 
Evaluation Construction 
OO analysis
OO design
& Release OO programming
OO testing

• Similar to spiral but uses pre-packaged classes wherever possible

• (+) emphasises reuse, (-) must design with further reuse in mind
 Component based development
• It is the process to apply when reuse is a development
objective
• evolutionary in nature – iterative approach
• Composes applications from prepackaged SW
components.
• Modeling and construction activities begin with the
identification of candidate components.
 Formal methods
• A set of activities that leads to formal mathematical
specification of computer SW.
• Goal is to remove ambiguity, incompleteness and
inconsistency.
• Serve as basis for program verification.
• Why not widely used?
– time-comsuming and expensive
– extensive training required
– difficult to use the model to as a communication
mechanism to unsophisticated customers.
• Used frequently to build safety-critical SW (avionics and
medical devices) and among developers who would
suffer economic hardship should SW errors occur.
 Other Process Models
• Formal methods: the process to apply when a mathematical
specification is to be developed.
– + Attack ambiguity, incompleteness and inconsistency
– + allows formal verification
– - time consuming and expensive
– - requires extensive training
– - not good for customer communication
 Aspect-Oriented SW
Development
• provides a process and methodological
approach for defining, specifying, designing, and
constructing aspects
• As systems become more complex, customer
required properties or areas of technical interest
called concerns span the entire architecture.
– high level properties of a system
• security
• fault tolerance
– functions
• application of business rules
– systemic
• task synchronization
• memory management
• user interfaces, collaborative work
• crosscutting concerns: concerns cut
across multiple system functions, features,
and information
• Aspectual requirements: define
crosscutting concerns that have impact
across the SW architecture
 Unified Process
• Attempts to draw the best features and
characteristcs of conventional SW process
models.
– BUT characterize them in a way that implements the
best principles of agile SW development.
• Recognizes the importance of customer
communication and streamlined methods for
describing the customer’s view
– use cases
• Emphasized SW architecture
– keeps the focus on the right goals
• ie understandability, future change and reuse
• UML provides the technology to support
OO SW but not the process framework.
• The Unified Process is the framework for
OO SE using UML as developed by
Jacobson, Rumbaugh and Booch.
• Iterative, incremental and adapted to meet
specific project needs.
• The idea is to make development more
agile and responsive to change.
• The phases are inceptiom, elaboration,
construction, transition and production
The Unified Process (UP)
elaboration
Elaboration

inception
Inception

inception

construction
Release
transition
software increment

production
 Inception phase
UP Work Products
Elaboration phase
Vision document
Initial use-case model
Initial project glossary Construction phase
Use-case model
Initial business case Supplementary requirements
Initial risk assessment. including non-functional Design model
Transition phase
Project plan, Analysis model Software components
phases and iterations. Software architect ure Integrated software Delivered software increment
Business model, Description. increment Beta test report s
if necessary. Executable architectural Test plan and procedure General user feedback
One or more prototypes prototype.
I nc ept i o
Test cases
n Preliminary design model Support documentation
Revised risk list user manuals
Project plan including installat ion manuals
iteration plan description of current
adapted workflows increment
milestones
technical work products
Preliminary user manual
• From the SE point of view, the most important work
product during the inception is the use-case model.
– imply SW feature and functions by describing a set of
preconditions, a flow of events or a scenario, and a
set of post-conditions for the interaction.
• The elaboration phase produces a set of work products
that elaborate requriements including nonfunctional
requirements and produce an architectural description
and a preliminary design.
• Construction produces an implementation
• Deployment maps components into the physicial
computing environment.
• A Test model describes the tests to ensure the use-
cases are properly constructed.
 Summary
• Prescriptive SW Processes
– suggest a somewhat different process flow
– perform the same set of generic framework activites
• communication, planning, modeling, construction,
deployment
• Waterfall – linear
• Incremental – series of increments
• RAD larger projects with tight time frames
• Evolutionary – iterative
• Component – reuse and assembly
• Formal Methods – mathematical
• Aspect-oriented – cross-cutting concerns
• Unified Process – use-case driven, architecture-centric,
iterative and incremental. Framework for UML methods
and tools.