Introduction to Software Engineering
Process Models
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
Software Engineering 9/e
By Ian Sommerville
Chapter 2 1
These slides are designed and adapted from slides provided by Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009) by Roger Pressman and Software Engineering 9/e Addison Wesley 2011 by Ian Sommerville
Social Learning
Process
• Software is embodied knowledge that is initially dispersed,
tacit and incomplete.
• In order to convert knowledge into software, dialogues are
needed between users and designers, between designers and
tools to bring knowledge into software.
• Software development is essentially an iterative social
learning process, and the outcome is “software capital”.
2
Definition of Software
Process
• A framework for the activities, actions, and tasks that
are required to build high-quality software.
• SP defines the approach that is taken as software is
engineered.
• Is not equal to software engineering, which also
encompasses technologies that populate the process–
technical methods and automated tools.
3
A Generic Process
Model 4
As we discussed before, a generic process
framework for software engineering defines five
framework activities-communication, planning,
modeling, construction, and deployment.
In addition, a set of umbrella activities- project
tracking and control, risk management, quality
assurance, configuration management, technical
reviews, and others are applied throughout the
process.
Next question is: how the framework activities and
the actions and tasks that occur within each
A Generic Process
activity are organized with respect to sequence
and time? See the process flow for answer.
Model 5
Process Flow
6
Linear process flow executes each of the five
activities in sequence.
An iterative process flow repeats one or more of
the activities before proceeding to the next.
An evolutionary process flow executes the
activities in a circular manner. Each circuit leads
to a more complete version of the software.
A parallel process flow executes one or more
activities in parallel with other activities
( modeling for one aspect of the software in
parallel with construction of another aspect of
the software.
Process Flow 7
• A process pattern
• describes a process-related problem that is encountered
during software engineering work,
• identifies the environment in which the problem has
been encountered, and
• suggests one or more proven solutions to the problem.
• Stated in more general terms, a process pattern provides
you with a template [Amb98]—a consistent method for
describing problem solutions within the context of the
software process.
( defined at different levels of abstraction)
1. Problems and solutions associated with a complete
process model (e.g. prototyping).
2. Problems and solutions associated with a framework
activity (e.g. planning) or
3. an action with a framework activity (e.g. project
estimating).
Process Patterns 8
• Stage patterns—defines a problem associated with
a framework activity for the process. It includes
multiple task patterns as well. For example,
EstablishingCommunication would incorporate the
task pattern RequirementsGathering and others.
• Task patterns—defines a problem associated with a
software engineering action or work task and
relevant to successful software engineering
practice
• Phase patterns—define the sequence of framework
activities that occur with the process, even when
the overall flow of activities is iterative in nature.
Process Pattern
Example includes SprialModel or Prototyping.
Types 9
An Example of Process Pattern
• Describes an approach that may be applicable when stakeholders have a general idea of what
must be done but are unsure of specific software requirements.
• Pattern name. RequiremetnsUnclear
• Intent. This pattern describes an approach for building a model that can be assessed iteratively by
stakeholders in an effort to identify or solidify software requirements.
• Type. Phase pattern
• Initial context. Conditions must be met (1) stakeholders have been
identified; (2) a mode of communication between stakeholders and the
software team has been established; (3) the overriding software problem
to be solved has been identified by stakeholders ; (4) an initial
understanding of project scope, basic business requirements and project
constraints has been developed.
• Problem. Requirements are hazy or nonexistent. stakeholders are unsure
of what they want.
• Solution. A description of the prototyping process would be presented
here.
• Resulting context. A software prototype that identifies basic
requirements. (modes of interaction, computational features, processing
functions) is approved by stakeholders. Following this, 1. This prototype
may evolve through a series of increments to become the production
software or 2. the prototype may be discarded.
10
• Related patterns. CustomerCommunication, IterativeDesign,
IterativeDevelopment, CustomerAssessment, RequirementExtraction.
Prescriptive Models
• Originally proposed to bring order to chaos.
• Prescriptive process models advocate an orderly approach to software
engineering. However, will some extent of chaos (less rigid) be beneficial
to bring some creativity?
That leads to a few questions …
• If prescriptive process models strive for structure and order (prescribe a
set of process elements and process flow), 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
It is the oldest paradigm for SE. When requirements are well
defined and reasonably stable, it leads to a linear fashion.
(problems: 1. rarely linear, iteration needed. 2. hard to state all requirements explicitly.
Blocking state. 3. code will not be released until very late.)
The classic life cycle suggests a systematic, sequential approach
12
to software development.
A variation of waterfall model
depicts the relationship of
The V-Model
quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activates.
Team first moves down the left
side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.
13
The
Incremental
Model
14
The Incremental
• Model
When initial requirements are reasonably well defined,
but the overall scope of the development effort precludes
a purely linear process. A compelling need to expand a
limited set of new functions to a later system release.
• It combines elements of linear and parallel process flows.
Each linear sequence produces deliverable increments of
the software.
• The first increment is often a core product with many
supplementary features. Users use it and evaluate it with
more modifications to better meet the needs. 15
Evolutionary Models
• Software system evolves over time as requirements often change
as development proceeds. Thus, a straight line to a complete end
product is not possible. However, a limited version must be
delivered to meet competitive pressure.
• Usually a set of core product or system requirements is well
understood, but the details and extension have yet to be defined.
• You need a process model that has been explicitly designed to
accommodate a product that evolved over time.
• It is iterative that enables you to develop increasingly more
complete version of the software.
• Two types are introduced, namely Prototyping and Spiral models.16
Evolutionary Models:
Prototyping
• When to use: Customer defines a set of general objectives but does not identify detailed
requirements for functions and features. Or Developer may be unsure of the efficiency
of an algorithm, the form that human computer interaction should take.
• What step: Begins with communication by meeting with stakeholders to define the
objective, identify whatever requirements are known, outline areas where further
definition is mandatory. A quick plan for prototyping and modeling (quick design)
occur. Quick design focuses on a representation of those aspects the software that will
be visible to end users. ( interface and output). Design leads to the construction of a
prototype which will be deployed and evaluated. Stakeholder’s comments will be used
to refine requirements.
• Both stakeholders and software engineers like the prototyping paradigm. Users get a
feel for the actual system, and developers get to build something immediately. However,
engineers may make compromises in order to get a prototype working quickly. The less-
than-ideal choice may be adopted forever after you get used to it. 17
Evolutionary Models:
Prototyping
Quick
plan
communication
Modeling
Quick design
Deployment Construction
delivery & of prototype
feedback Construction
of prototype
18
Evolutionary Models: The
• Spiral
It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall
model and is a risk-driven process model generator that is used to guide multi-stakeholder concurrent
engineering of software intensive systems.
• Two main distinguishing features: one is cyclic approach for incrementally growing a system’s degree of
definition and implementation while decreasing its degree of risk. The other is a set of anchor point
milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.
• A series of evolutionary releases are delivered. During the early iterations, the release might be a model or
prototype. During later iterations, increasingly more complete version of the engineered system are
produced.
• The first circuit in the clockwise direction might result in the product specification; subsequent passes
around the spiral might be used to develop a prototype and then progressively more sophisticated versions
of the software. Each pass results in adjustments to the project plan. Cost and schedule are adjusted based
on feedback. Also, the number of iterations will be adjusted by project manager.
• Good to develop large-scale system as software evolves as the process progresses and risk should be
understood and properly reacted to. Prototyping is used to reduce risk.
• However, it may be difficult to convince customers that it is controllable as it demands considerable risk
assessment expertise. 19
Evolutionary Models: The
Spiral
20
Three Concerns on
Evolutionary Processes
• First concern is that prototyping poses a problem to project planning because of
the uncertain number of cycles required to construct the product.
• Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that the
process will fall into chaos. On the other hand if the speed is too slow then
productivity could be affected.
• Third, software processes should be focused on flexibility and extensibility
rather than on high quality. We should prioritize the speed of the development
over zero defects. Extending the development in order to reach high quality
could result in a late delivery of the product when the opportunity niche has
disappeared.
21
Concurrent Model
• Allow a software team to represent iterative and concurrent elements of any of the
process models. For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the following actions: prototyping, analysis
and design.
• The Figure shows modeling may be in any one of the states at any given time. For
example, communication activity has completed its first iteration and in the awaiting
changes state. The modeling activity was in inactive state, now makes a transition into
the under development state. If customer indicates changes in requirements, the
modeling activity moves from the under development state into the awaiting changes
state.
• Concurrent modeling 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 trigger transitions among
22 the
states.
Concurrent Model
23
Assignment 1 a
Present comparative analysis of Waterfall Model,
Prototyping Model, V-Model and Spiral Model (using
Modeltemplate)
following Size Inc/Ite Cost Risk Change
Waterfall
Prototype
V-Model
Spiral
Kindly add incremental model in above table.
Write down the advantages and disadvantages of each 24
model mentioned above
