3 - Software Process Models

• Based on slides of:

• Ian Sommerville: http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/
Presentations/index.html
•

• Software Process Models

• Waterfall Model
• Incremental Model
• Prototyping Process Model
• Spiral Process Model
• RAD Model
• Unified Process Model
• Agile Process Models
•
 The Software Process
• A structured set of activities required to
develop a software system
For example:
– Requirements Specification
– Analysis and design
– Implementation.
– Validation
– Evolution
• A software process model is an abstract
representation of a process
– It presents a description of a process from
some particular perspective
 The Software Process

• Is not equal to software engineering,

which also encompasses technologies
that populate the process– technical
methods and automated tools.
 Software Process description
• When we describe processes, we usually
talk about the activities in these processes
and the ordering of these activities.
• Process descriptions may also include:
– Products, which are the outcomes of a process
activity;
– Roles, which reflect the responsibilities of the
people involved in the process;
– Pre- and post-conditions, which are statements
that are true before and after a process activity
has been enacted or a product produced.
 Characteristics of a Good Process
• Should be precisely defined – no ambiguity
about what is to be done, when, how, etc.
• It must be predictable – can be repeated in
other projects with confidence about its
outcome
– Predictable with respect to effort, cost:
Project A: Web-based library applications done by 3
persons in 4 months
 another project B (guest house bookings), similar in
complexity should also take about 12 person months.
 A Good Process …
• Facilitates early detection of and removal of
defects
– Defects add to project cost
– Late detection/correction is costly
• It should facilitate monitoring and
improvement
– Based on feedback
– Permit use of new tools, technologies
– Permit measurements
 What / who / why is Process Models?
 What: Go through a series of predictable steps--- a road map that
helps you create a timely, high-quality results.
 Who: Software engineers and their managers, clients also. People
adapt the process to their needs and follow it.
 Why: Provides stability, control, and organization to an activity that
can if left uncontrolled, become quite chaotic. However, modern
software engineering approaches must be agile and demand ONLY
those activities, controls and work products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the
software that you are building. One process might be good for
aircraft avionic system, while an entirely different process would be
used for website creation.
 How to ensure right: A number of software process assessment
mechanisms that enable us to determine the maturity of the
software process. However, the quality, timeliness and long-term
viability of the software are the best indicators of the efficiency of
the process you use.
8
 A General Process Model
 As we discussed before, a general process
framework for software engineering defines five
framework activities-communication, planning,
modeling, construction, and deployment.
 Next question is: how are the framework activities
and the actions and tasks that occur within each
activity organized with respect to sequence and
time? See the process flow for answer.

9
Process
Flow

10
 Process Flow
 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.

11
 Software Process Model
Software engineers have several choices for the selection
of software process models. The models are :
• Linear Sequential Model
• The Incremental Model
• The Prototype Model
• The (Boehm) Spiral Model
• The Rapid Application Development Model (RAD)
• Etc.
• In all models, core activities like Analysis, Design, Code, Test are
common. However their execution differs from model to model.

- deployment; make changes for

-- Errors, performance
changes in requirement
 The Linear Sequential Model (LSM)
• It is one of the earliest development models.
• The linear sequential model provides a systematic
approach to software development.
• In this approach, the process of software development
is represented by a sequence of steps.
• The sequential phases are what make this model linear,
simple and systematic in nature.
• Each phase must be completed before moving to next
phase.
• This model is also known as the Waterfall Model or the
Classical life cycle .
 The Waterfall Model

It is the oldest paradigm for SE. When requirements are well defined
and reasonably stable, it leads to a linear fashion.

14
The Waterfall Model
 Advantages of Linear Sequential Model

• It is easy to understand and implement.

• It prohibits skipping any phase in the sequence.
• Points to importance of documentation
• Disciplined and well-structured approach
• Easy to plan from project management point of view
• It is ideal for small projects and when the requirements
and goals of the project are well established in advance.
Disadvantages of Linear Sequential Model
• In practical conditions, software projects are seldom
sequential. Iteration and overlapping often occur . This
model is not suitable for such projects.
• The working version of the software is available to the
customer after testing. Therefore, if there is any major
error during the coding it will not be found till end of the
testing.
• Due to linear nature if any phase is not completed , the
software analyst and developers cannot proceed further.
The waterfall model is unrealistic for many reasons:
• requirements must befrozen too early in the life-cycle
• requirements arevalidated too late
 Problems with the Waterfall
Lifecycle
1. “Real projects rarely follow the sequential flow that the model
proposes.Iteration always occurs and creates problems in the
application of the paradigm”

2. “It is often difficult for the customerto state all requirements explicitly.
The classic life cycle requires this and has difficulty accommodating
the natural uncertainty that exists at the beginning of many projects.”

3. “The customer must have patience. Aworking version of the

program(s) will not be available untillate in the project timespan. A
major blunder, if undetected until the working program is reviewed,
can be disastrous.”
— Pressman, SE
 • The V-model is an
The V-Model extension of the waterfall
model.
• Show the relationships
between development
phases and test phases
• 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.
19
 Testing stages
• Unit testing
– Individual components are tested
• Module testing
– Related collections of dependent components are
tested
• Sub-system testing
– Modules are integrated into sub-systems and tested.
The focus here should be on interface testing
• System testing
– Testing of the system as a whole. Testing of
emergent properties
• Acceptance testing
– Testing with customer data to check that it is
acceptable
 Software Architecture
Building blocks and their connections

System Interface

A B C

Shared D
component

Integration Testing
 Incremental Development
• 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.
• 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.
Incremental Development – Version I
The Incremental Model

24
 The Incremental Model
• When initial requirements are reasonably well
defined, but the overall scope of the development
effort prevents 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 software is developed and delivered in small
increments and the linear sequential model is
applied to each increment.
• 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.
• The core product addresses the primary needs of
the final product.
25
 Incremental Development –
Advantages
• 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.
 Advantages of using the
Incremental Model
• It requires less human resources, especially for the
first few increments.
• It guarantees early delivery of the final product, each
increment leads to the development of the software.
• If any resource staff is unavailable, it does not affect
or delay the project.
• The incremental model is therefore ideal for those
projects in which sufficient manpower is not
available to meet difficult project deadlines.
Disadvantages of Using Incremental Model

• Systems are often poorly structured.

• Software quality is sometimes compromised in

the rush to finish the software earlier than
planned.
Incremental means adding, iterative
means reworking (by Alistair Cockburn)
• Incremental development is a staging and scheduling strategy in
which the various parts of the system are developed at different
times or rates and integrated as they are completed. The
alternative is to develop the entire system with a big bang
integration at the end.
• Iterative development is a rework scheduling strategy in which
time is set aside to revise and improve parts of the system. The
alternative development is to get it right the first time (or at least
Increment Iterate
declare that it is right!).
fundamentally means“add fundamentally means
onto” . “change” .
repeating the process on a repeating the process on
new section of work. thesame section of work
repeat the process (, design, repeat the process (, design,
implement, evaluate), implement, evaluate),
 Incremental Development

• The first increment delivers one slice of

functionality through the whole system.
• The second increment delivers another
slice of functionality through the whole system.
•
The third increment delivers the rest of
the system
 Iterative Development
• \

• The first iteration delivers enough of

feature 1 to evaluate what is correct
and what needs revision.
• After the second iteration, some revised
parts still need improvement.
• The third iteration produces the final
and stable feature
Incremental vs. Iterative
 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 iteration that enables you to develop increasingly
more complete version of the software.
• Two types are introduced, namely Prototyping and Spiral
models. 33
 Prototyping
 In practice, neither users nor developers know
in advance all the factors that affect desired
outcome
Thus considerable "thrashing" between one
activity and back may take place in order to
gain knowledge about the problem
One way to control such thrashing: develop a
partial product and allow customers and
developers to examine it for feasibility
Advantage: revisions made at requirements
stage rather than the more costly testing
stage
The partially developed product is aprototype
 Prototyping Process Model
Initial
Requirements

Design
To validate the user requirements for
new software before progressing too
far in the development process,
Review &
prototypes of the software system
Prototype
Update
may be developed.
Whether a low-fidelity prototype
that illustrates the look-and-feel of
Customer
Evaluation the design or a high-fidelity
prototype that implements part of
Customer the system’s functionality, approval
Satisfaction
Development by the customer is required before
full system implementation is
begun.
Test

CS 325
Lesson Two Maintain
Software Process & Methodology
Page 35
 Prototyping Model
• In this model the developer and client interact to established
the requirements of the software.
• Define the broad set of objectives.
• This is followed up by the quick design, in which the visible
elements of the software, the input and the output are
designed.
• The quick design stresses the clients view of the software .
• The final product of the design is a prototype.
• The client then evaluates the prototype and provides its
recommendations and suggestion to the analyst.
• The process continues in an iterative manner until all the user
requirements are met.
 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 with stakeholders to define
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 of 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.
• Comments: 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.
37
 Advantages of Prototyping Model
• Due the interaction between the client and developer right
from the beginning , the objectives and requirements of the
software is well established.
• Suitable for the projects when client has not clear idea about
his requirements.
• The client can provide its input during development of the
prototype.
• The prototype serves as an aid for the development of the final
product.
Disadvantages of Prototyping Model
• The quality of the software development is
compromised in the rush to present a working
version of the software to the client.
• The client looks at the working version of the
product at the outset and expect the final version of
the product to be delivered immediately. This
causes additional pressure over the developers to
adopt shortcut in order to meet the final product
deadline.
 Boehm’s Spiral Model
• Process is represented as a spiral rather than as a
sequence of activities with backtracking
• Each loop in the spiral represents a phase in the
process.
thus, the innermost loop might be concerned with
system feasibility, the next loop with requirements
definition, the next loop with system design and so
on.
• Each loop in the spiral is split into four sectors
• No fixed phases such as specification or design --
loops in the spiral are chosen depending on what is
required
• Risks are explicitly assessed and resolved throughout
the process.
– This was the motivation behind developing the Spiral Model
Boehm’s Spiral Model of the Software Process

Chapter 2 Software Processes 12

 Spiral Model Sectors
This variation of the evolutionary approach emphasizes extensive
risk assessment to allow for easy adaptation to changes and
identification of problems.
• Objective setting
• Specific objectives, alternatives, and constraints for the phase are
identified.
• Risk assessment and reduction
• Risks are assessed and activities put in place to reduce the key risks.
• Development and validation
• A development model for the system is chosen which can be any of the
generic models. Development takes place.
• Planning
• The project is reviewed and the next phase of the spiral is planned.

Chapter 2 Software Processes 13

 The Spiral Model
• The spiral model is recommended where the
requirements and solution call for developing full-fledge,
large, complicated system with lots of features and
facilities from the scratch.
• It is used when experimenting on technology, trying out
new skills and when the user is not able to offer
requirements in clear terms.
• It emphasizes the quick development of the software,
which is released in increments.
• Spiral model has been very influential in helping people think
about iteration in software processes and introducing the risk-
driven approach to development.
• In practice, however, the model is rarely used as published for
practical software development.
 Advantages of Using Spiral Model

The spiral model has the following advantages :

• This model is more in tune with large real-life project
development.
• Prototyping can be applied at any level in evaluation
process.
– This helps to reduce technical risk.
• It is suitable for application that can use an object
oriented approach to develop software.
 Disadvantages of Using Spiral Model

The spiral model has the following disadvantages:

• It can cause problems in negotiating a development contract
with the client.
• It requires considerable experience in risk management for the
project to be successful.
• It requires a lot of patience and time in years before this
model’s effectiveness can be assessed accurately.
 Three Concerns on Evolutionary
• First concern is that Processes
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. 46
Rapid Application Development:
• RAD is a high speed version of linear sequential model. It is
characterized by a very short development life cycle, in which
the objective is to accelerate the development.
• The RAD model follows a component-based approach.
• In this approach individual components developed by different
people are assembled to develop a large software system.
 RAD
• Minimal planning and
fast prototyping.
• Developing instead of
planning
• The lack of pre-
planning generally
allows software to be
written much faster,
and makes it easier to
change requirements.
 Advantages of Using RAD Model:
The RAD has following advantages:

• Due to emphasis on rapid development , it results in

the delivery of fully functional project in short time
period.
• It encourages the development of program
component that is reusable.
Disadvantages of Using RAD Model:
The RAD model has following disadvantages :
• It requires dedication and commitment on the part of the
developers as well as the client to meet the deadline. If either
party is indifferent in needs of other, the project will run into
serious problem.
• Its application area is restricted to system that are modular
and reusable in nature.
• It is not suitable for the applications that have a high degree of
technical risk.
• It is not suitable for large projects because they require more
manpower for creating multiple RAD groups.
 Unified Process Model
• A modern process model derived from
the work on the UML.
• Unified Process—a “use-case driven,
architecture-centric, iterative and
incremental” software process closely
aligned with the Unified Modeling
Language (UML) to model and develop
object-oriented system iteratively and
incrementally.
51
(R)UP phases and iterations

Picture taken from: http://www.ibm.com/developerworks/webservices/library/ws-soa-

term2/
 (R)UP phases
• One cycle consists of four phases:
– Inception
• Establish the business case for the system.
– Elaboration
• Develop an understanding of the problem
domain and the system architecture.
– Construction
• System design, programming and testing.
– Transition
• Deploy the system in its operating environment.
 (R)UP
• In each phase many different workflows (like
management, requirements, design,
implementation workflow, etc.) can be
addressed simultaneously.
• At the end of each cycle some kind of
prototype or artifact are produced.
• The phases can be repeated many times (i.e.
iterations), producing one or many prototypes
or artifacts.
• During the cycles the requirements are stable
which offers possibilities to plan the
development process for this cycle.
• Between the cycles the requirements change.
 Agile Process Models
The predictive nature of conventional software
development is sometimes seen as an illusion.
An alternative approach, agile
development, is characterized by:
• Small but highly competent
development teams
• The principal measure of progress
is working code
• Changes in requirements are
welcome, even if late
• Developers, customers, and
managers are all on the same team
• Software delivery is stressed more
than analysis and design

CS 325
Lesson Two
Software Process & Methodology
Page 55
Project Failure – the trigger for Agility
• One of the primary causes of project
failure was the extended period of time it
took to develop a system.
• Costs escalated and requirements
changed.

• Agile methods intend to develop systems

more quickly with limited time spent on
analysis and design.
 What is an Agile method? (1)

• Focus on the code rather than the design.

• Based on an iterative approach to software
development.
• Intended to deliver working software quickly.
• Evolve quickly to meet changing requirements.
• There are claims that agile methods are probably
best suited to small/medium-sized business
systems or PC products.
 What is an agile method? (2)
• Agile proponents believe:
– Current software development processes are
too heavyweight or cumbersome
• Too many things are done that are not directly
related to software product being produced
– Current software development is too rigid
• Difficulty with incomplete or changing
requirements
• Short development cycles (Internet applications)
– More active customer involvement needed
Summary of Principles of agile methods
Claimed Problems with agile methods
• It can be difficult to keep the interest of customers
who are involved in the process.
• Team members may be unsuited to the intense
involvement that characterizes agile methods.
• Prioritising changes can be difficult where there are
multiple stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other
approaches to iterative development.
Incremental & iterative - summary
• Iterative model - This model iterates requirements, design, build
and test phases again and again for each requirement and builds
up a system iteratively till the system is completely build.
• Incremental model - It is non integrated development model. This
model divides work in chunks and one team can work on many
chunks. It is more flexible.
• Spiral model - This model uses series of prototypes in stages,
the development ends when the prototypes are developed into
functional system. It is flexible model and used for
large and complicated projects.
• Evolutionary model - It is more customer focused model. In this
model the software is divided in small units which is delivered
earlier to the customers.
• V-Model - It is more focused on testing. For every phase some
testing activity are done.