Chapter 3

Prescriptive Process Models

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

by Roger S. Pressman

1
 Contents
• What is Software & Perspective Process Models?
• Process Flow
• Waterfall Model
• Incremental Models
- Incremental Model
- RAD(Rapid Application Development) Model
• Evolutionary Process Models
- Prototyping Model
- The Spiral Model
- The Concurrent Development Model
• Unified Process
 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
•Perspective process models define a distinct set of
activities, actions, tasks, milestones and work products
that are required to engineer high-quality software.
 Prescriptive Process Models
• Advocate an orderly approach to software
engineering.
• Elaborates to prescribe a set of process elements
such as framework activities, software engineering
actions, tasks, work products, quality assurance, and
change control mechanisms for each project.
• All software process models can accommodate the
generic framework activities described earlier.
 Why models are needed?
• Symptoms of inadequacy: the software crisis
– Scheduled time and cost exceeded
– User expectations are not reached
– Poor quality
• The size and economic value of software applications
required appropriate "process models“
Types of Process Models or Paradigms:
- Waterfall Model
- Incremental Models
- Evolutionary Models
- Unified Process
Process Flow
Waterfall (or Classic Life Cycle) Model
• Suggests a systematic, sequential approach to software
development that begins with customer specification
of requirements and progresses through planning,
modeling, construction, and deployment.
• It is the oldest paradigm
• Occurs in a limited number of new development
efforts when requirements are well defined and
reasonably stable.
The Waterfall Model
The Waterfall Model - Advantages
• Simple, Easy to understand and use
• Easy to manage due to the rigidity of the model. Each
phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements
are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
 Disadvantages
• Real projects rarely follow the sequential flow that the
model proposes.
• Difficult for the customer to state all requirements
explicitly since the waterfall model requires to known
them in advance.
• The customer must have patience to get the working
version of the program(s) because it will not be
available until late in the project time span.
• A major blunder, if undetected any error or defect until
the working program is reviewed, can be disastrous.
 Incremental Models
• Situation - Initial software requirements are
reasonably well defined, but the overall scope of the
development effort precludes a purely linear process.
• Need - provide a limited set of software functionality
to users quickly and then refine and expand on that
functionality in later software releases
• Types of Incremental Process Models
- Incremental Model
- RAD (Rapid Application Development) Model
 Incremental Model
• Combines elements of linear and parallel process flows.
• Applies linear sequences in a staggered fashion as calendar
time progresses.
• Each linear sequence produces deliverable “increments” of
the software in a manner that is similar to the increments
produced by an evolutionary process flow.
Ex.: word-processing software
• The first increment is often a core product, which
addresses basic requirements including many
supplementary features (some known, others unknown)
remain undelivered.
Incremental Model (Cont.)
 Incremental Model (Cont.)
Advantages Disadvantages
The software will be generated It requires a good planning and
quickly during the software life cycle design
It is flexible and less expensive to Each iteration phase is rigid and does
change requirements and scope not overlap each other

A customer can respond to each Rectifying a problem in one unit

building and errors can be identified requires correction in all the units and
easily consumes a lot of time
RAD (Rapid Application Development) Model
• It is an incremental software development process
model that emphasizes an extremely short
development cycle.
• A “high-speed” adaptation of the linear sequential
model in which rapid development is achieved by
using component-based construction.
• Enables a development team to create a “fully
functional system” within very short time periods (e.g.,
60 to 90 days)
• Used primarily for information systems applications
60 – 90 Days
 Advantages and Disadvantages
Advantages:
•Reduces development time.
•Increases reusability of components
•Encourages customer feedback
Disadvantages:
•For large but scalable projects, requires sufficient human resources to create
the right number of RAD teams.
•Requires developers and customers who are committed to the rapid-fire
activities necessary to get a system complete in a much abbreviated time
frame.
•If a system can not be properly modularized, building the components
necessary for RAD will be problematic.
•If high performance is an issue, the RAD approach may not work.
•Not all types of applications are suitable for RAD.
•RAD is not appropriate when technical risks are high.
 Evolutionary Process Models
• A set of core product or system requirements is well
understood, but the details of product or system extensions
have yet to be defined
• Need a process model that has been explicitly designed to
accommodate a product that evolves over time.
• Evolutionary models are iterative.
• Enables you to develop increasingly more complete versions of
the software.
• Types
- Prototyping
- The Spiral Model
- The concurrent development Model
 The Prototyping Model
• Customer defines a set of general objectives for
software, but does not identify detailed
requirements for functions and features.
• Prototyping can be used as a stand-alone
process model and supported by any one of the
process models for implementation process.
• the prototyping paradigm assists you and other
stakeholders to better understand what is to be
built when requirements are fuzzy.
The Prototyping Model
 Advantages and Disadvantages
Advantages:
•Iteration occurs as the prototype is tuned to satisfy the needs of
various stakeholders.
•It enables you to better understand what needs to be done.
•Serves as a mechanism for identifying software requirements.

Disadvantages:
•Stakeholders see what appears to be a working version of the
software, but they will not focus on overall quality of the product.
•As a software engineer, you often make implementation
compromises in order to get a prototype working quickly.
 The Spiral Model
• Proposed by Barry Boehm [Boe88] and it is an evolutionary software
process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model.
• It is a risk-driven process model is used to guide multi-stakeholder
concurrent engineering of software intensive systems.
• It has two main distinguishing features such as
(1) Cyclic approach for incrementally growing a system’s degree
of definition and implementation while decreasing its degree of
risk.
(2) A set of anchor point milestones for ensuring stakeholder
commitment to feasible and mutually satisfactory system
solutions.
The Spiral Model (Cont.)
 Advantages and Disadvantages
Advantages:
•It is a realistic approach to the development of large-scale systems and software.
•Uses prototyping as a risk reduction mechanism to enables you to apply at any stage in
the evolution of the product.
•Maintains the systematic stepwise approach suggested by the classic life cycle but
incorporates it into an iterative framework that is more realistically reflects the real
world.
•Demands a direct consideration of technical risks at all stages of the project and, if
properly applied, should reduce risks before they become problematic.
Disadvantages:
•But like other paradigms, the spiral model is not a panacea. It may be difficult to
convince customers (particularly in contract situations) that the evolutionary approach is
controllable.
•Demands considerable risk assessment expertise and relies on this expertise for success.
If a major risk is not uncovered and managed, problems will undoubtedly occur.
The Concurrent Development Model
• Also called as concurrent engineering, allows a software team to
represent iterative and concurrent elements of any of the early process
models.
• Example:
- The modeling activity defined for the spiral model is accomplished by
invoking one or more of the following software engineering actions:
prototyping, analysis & design.
- The modeling activity may be in any one of the states noted at any
given time. Similarly, other activities, actions, or tasks (e.g.,
communication or construction) can be represented in an analogous
manner.
• Defines a series of events that will trigger transitions from state to state
for each of the software engineering activities, actions, or tasks.
The Concurrent Development Model
 Advantages & Disadvantages
Advantages:
•It is applicable to all types of software development and provides
an accurate picture of the current state of a project.
•Rather than confining software engineering activities, actions, and
tasks to a sequence of events, it defines a process network.
•Each activity, action, or task on the network exists simultaneously
with other activities, actions, or tasks.
•Events generated at one point in the process network trigger
transitions among the states.
Disadvantages:
•It needs better communication between the team members. This
may not be achieved all the time.
•It requires to remember the status of the different activities.
Final Comment on Evolutionary Process Models
• Modern computer software is characterized by continual
change, by very tight time lines, and need for end user–
customer satisfaction.
Concerns
• Prototyping poses a problem to project planning because of the
uncertain number of cycles required to construct the product.
• Evolutionary software processes do not establish the maximum
speed of the evolution.
• Software processes should be focused on flexibility and
extensibility rather than on high quality
Note that The intent of evolutionary models is to develop high-
quality software in an iterative or incremental manner.
 Unified Process (UP)
• It is an attempt to draw on the best features and
characteristics of traditional software process
models, but characterize them in a way that
implements many of the best principles.
• Recognizes the importance of customer
communication and streamlined methods for
describing the customer’s view of a system.
• Emphasizes the important role of software
architecture and “helps the architect focus on the
right goals, such as understandability, reliance to
future changes, and reuse”
 Unified Process - History
Year Description
1980- - Object Oriented methods and Programming languages
1990 - Object Oriented Analysis (OOA)
- Object Oriented Design (OOD)
Early James Rumbaugh [Rum91], Grady Booch [Boo94], and Ivar Jacobson [Jac92]
1990’s began working on a “unified method” that would combine the best features of
each of their individual object-oriented analysis and design methods and adopt
additional features proposed by other experts, which is supported by UML
(Unified Modelling Language)
UML - Contains a robust notation for the modelling and development of object-
( 9 types oriented systems
of - By 1997, it becomes a de facto industry standard for object-oriented software
diagrams development.
are - UML provided the necessary technology to support object-oriented software
available engineering practice without process framework .
) - Over the next few years, Jacobson, Rumbaugh, and Booch developed the
Unified Process, a framework for object-oriented software engineering using
UML will be continued.
 Unified Process (Cont.)
A software process that is:

- Use-case driven
- Architecture-centric
- Iterative and incremental

Closely aligned with the Unified Modeling Language (UML)

The Unified Process - Phases

32
 UP – Phases Expansion
• Inception - collaborating with stakeholders, identification of business
requirements, proposal of rough architecture, plan for the system is
developed.
• Elaboration - refines and expands the preliminary use cases that were
developed as part of the inception phase and expands the architectural
representation to include five different views of the software such as the use
case model, the requirements model, the design model, the implementation
model, and the deployment model.
• Construction - Develops or acquires the software components that will make
each use case as operational for end users.
• Transition - Encompasses the latter stages of the generic construction
activity and the first part of the generic deployment (delivery and feedback)
activity.
• Production - The ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and defect reports and
requests for changes are submitted and evaluated.
Major Work Products for Each UP Phase