3 - Software 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 frommake
-deployment; model to model.
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
Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance
 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 be frozen too early in the life-cycle
• requirements are validated 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 customer to 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. A working version of the program(s)

will not be available until late 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 extension of
The V-Model 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

Define outline Assign requirements Design system

requirements to increments architecture

Develop system Validate Integrate Validate

increment increment increment system
Final
system
System incomplete
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.
 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 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 a prototype
 Prototyping Process
Initial
Requirements

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

CS 325
Lesson Two Maintain
Software Process &
Methodology
 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.
 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 -
Risk
• Uses prototyping
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.
 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
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.
 Summary of Principles of agile methods

Principle Description
Customer involvement The customer should be closely involved throughout the
development process. Their role is provide and prioritise new
system requirements and to evaluate the iterations of the system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognised and
exploited. The team should be left to develop their own ways of
working without prescriptive processes.
Embrace change Expect the system requirements to change and design the system
so that it can accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and in
the development process used. Wherever possible, actively work
to eliminate complexity from the system.
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.