Software Process Models

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 method and
automated tools.

2
 Software Product
 In software engineering, any software developed
as per the requirements of the client is referred
to as a product. In other words, a product is the
outcome of a planned and controlled software
project.
 A software product consists of several entities
such as requirement specifications, design and
test documents, and user manuals.
 The objective gives the information about the
aim of the product, whereas the scope provides
details about fundamental data, functions, and
behavior of the product.
3
 Software Product
Product Process
Product is the final production phase in Process refers to a set of sequence of
the project. steps that should be followed with the
goal of creating a project.

Product focuses on the final result. Process focuses on completing every

step involved in the project that is
being developed.

Product follows the firm guidelines. Process follows the guidelines

consistently.
Product tends to be a short-term Process tends to be a long-term aspect.
aspect.
The goal of a product is to complete The goal of a process is to improve the
the work successfully. quality of the project.

4
 Software Process, Project, Product
 A software process as mentioned earlier, specifies a method
of development software.
 A software project, on the other hand is a development
project in which a software process is used.
 And software products are the outcomes of a software
project.
 Each software development project starts with some needs
and (hopefully) ends with some software that satisfies those
needs.
 A software process specifies the abstract set of activities
that should be performed to go from user needs to final
product.
 The actual act of executing the activities for some specific
user needs is a software project. And all the outputs that are
produced while the activities are being executed are the
products.
5
Layers of Software Engineering

6
A Generic Process Model

7
A Generic Process Model
An activity strives to achieve a broad
objective
◦ e.g., communication with stakeholders
An action (e.g., architectural design)
encompasses a set of tasks that produce a
major work product (e.g., an architectural
design model).
A task focuses on a small, but well-defined
objective (e.g., conducting a unit test) that
produces a tangible outcome.

8
Umbrella Activities
Complement the five process framework activities and help team
manage and control progress, quality, change, and risk.
 Software project tracking and control: assess progress against the
plan and take actions to maintain the schedule.
 Risk management: assesses risks that may affect the outcome and
quality.
 Software quality assurance: defines and conduct activities to ensure
quality.
 Technical reviews: assesses work products to uncover and remove
errors before going to the next activity.
 Measurement: define and collects process, project, and product
measures to ensure stakeholder’s needs are met.
 Software configuration management: manage the effects of change
throughout the software process.
 Reusability management: defines criteria for work product reuse
and establishes mechanism to achieve reusable components.
 Work product preparation and production: create work products
such as models, documents, logs, forms and lists. 9
A Task Set
 A task set defines the actual work to be
done to accomplish the objectives of a
software engineering action.
A list of the task to be accomplished
A list of the work products to be produced
A list of the quality assurance filters to be
applied

10
 Identifying a Task Set
 For example, a small software project
requested by one person with simple
requirements, the communication activity
might encompass little more than a phone all
with the stakeholder. Therefore, the only
necessary action is phone conversation, the
work tasks of this action are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of
requirements.
4. E-mail to stakeholder for review and approval.

11
A Generic Process Model
 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
activity are organized with respect to sequence
and time? See the process flow for answer.

12
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 path 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.
13
Process Flow

14
 Software Process Models

Model: A model is a simplified representation of a

complex reality.
Software Process Model: A simplified representation
of a software process, presented from a specific
perspective.

 Prescriptive Process Models

 Specialized Process Models
 Other Process Models

15
 Prescriptive Models
 A software life cycle model is either a descriptive or
prescriptive characterization of how software is or should be
developed.
 A descriptive model describes the history of how a particular
software system was developed.
 A prescriptive model prescribes how a new software
system should be developed.
 Prescriptive software models are those which prescribe the
components which make up a software model, including the
activities, the inputs and outputs of the activities, how quality
assurance is performed, how change is managed, and so on.

16
 Prescriptive Models
 Originally proposed to bring order to chaos.
 Often referred to as “conventional” process models
 Prescriptive process models advocate an orderly
approach to software engineering.
 Examples:
◦ Waterfall Model
◦ V-Model
◦ Incremental Model
◦ RAD Model
◦ Evolutionary Models (Prototyping, Spiral)

17
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 to

software development.
18
The V-Model
A variation of waterfall model
depicts the relationship of
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.
19
The Incremental Model

20
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 first increment is often a core product. Users
use it and evaluate it with more modifications to
better meet the needs.

21
The RAD Model
Rapid Application Development
Emphasizes a short development cycle
A “high speed” adaptation of the waterfall model
Uses a component-based construction approach
May deliver software within a very short time
period (e.g. , 60 to 90 days) if requirements are
well understood and project scope is constrained

22
The RAD Model
Team # n
Modeling
Modeling
business modeling
business modeling
data modeling
data modeling
process modeling
process modeling

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

Construction
Construction
component reuse
component reuse
automatic code
automatic code
generation
generation
testing
testing

60 – 90 days 23
The RAD Model - Drawbacks
For large, but scalable projects, RAD requires
sufficient human resources
RAD projects will fail if developers and
customers are not committed to the rapid-fire
activities
If a system cannot be properly modularized,
building the components necessary for RAD
will be problematic
If high performance is an issue, and
performance is to be achieved through tuning
the interfaces to system components, the RAD
approach may not work
RAD may not be appropriate when technical
risks are high
24
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.
25
Incremental Verses Evolutionary

26
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 steps: 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.

27
Evolutionary Models:
Prototyping
Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

28
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 increasingly growing a system’s degree of definition and
implementation while decreasing its degree of risk. The
other is a set of fix 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.
29
Evolutionary Models: The Spiral
 The first track 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.
30
Evolutionary Models: The Spiral

31
Weaknesses of 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 place has disappeared.
32
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 the states.

33
Concurrent Model

34
Thanks

35