Chapter-3

Software Process Model

Software process model

 Process models prescribe a distinct set of activities, actions,

tasks, milestones, and work products required to engineer high
quality software.

 Process models are not perfect, but provide roadmap for

software engineering work.

 Software models provide stability, control, and organization to

a process that if not managed can easily get out of control

 Software process models are adapted to meet the needs of

software engineers and managers for a specific project.
Build and Fix Model
Build and Fix Model

The earlier approach

 Product is constructed without specification or any attempt at
design.
 developers simply build a product that is reworked as many
times as necessary to satisfy the client.
 model may work for small projects but is totally unsatisfactory
for products of any reasonable size.
 Maintenance is high.
 Source of difficulties and deficiencies
— impossible to predict
— impossible to manage
Why Models are needed?

 Symptoms of inadequacy: the software crisis

— scheduled time and cost exceeded
— user expectations not met
— poor quality
Process as a "black box"

Informal
Requirements
Process

Product

Quality?

Uncertain /
Incomplete requirement
In the beginning
Problems

 The assumption is that requirements can be fully understood

prior to development
 Interaction with the customer occurs only at the beginning
(requirements) and end (after delivery)
 Unfortunately the assumption almost never holds
Process as a "white box"

Informal
Requirements
Process

Product

feedback
Advantages

 Reduce risks by improving visibility

 Allow project changes as the project progresses
— based on feedback from the customer
Prescriptive Model

 Prescriptive process models advocate an orderly approach to

software engineering
— Organize framework activities in a certain order
 Each action in terms of a task set that identifies the work to be
accomplished to meet the goals.
 Software engineer choose process framework that includes
activities like;
— Communication
— Planning
— Modeling
— Construction
— Deployment
Prescriptive Model

 Calling this model as “Prescribe” because it recommend a set

of process elements, activities, action task, work product &
quality.
 Each elements are inter related to one another (called
workflow).
Waterfall Model
 Waterfall Model

The sequential phases in Waterfall model are:

 Requirement Gathering and analysis: All possible
requirements of the system to be developed are captured in
this phase and documented in a requirement specification doc.

 System Design: The requirement specifications from first

phase are studied in this phase and system design is prepared.
System Design helps in specifying hardware and system
requirements and also helps in defining overall system
architecture.
 Implementation: With inputs from system design, the system
is first developed in small programs called units, which are
integrated in the next phase. Each unit is developed and tested
for its functionality which is referred to as Unit Testing.
Waterfall Model

 Integration and Testing: All the units developed in the

implementation phase are integrated into a system after testing
of each unit. Post integration the entire system is tested for
any faults and failures.

 Deployment of system: Once the functional and non

functional testing is done, the product is deployed in the
customer environment or released into the market.

 Maintenance: There are some issues which come up in the

client environment. To fix those issues patches are released.
Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer
environment.
Waterfall Model-Applications

Every software developed is different and requires a

suitable SDLC approach to be followed based on the
internal and external factors. Some situations where
the use of Waterfall model is most appropriate are:

 Requirements are very well documented, clear and fixed.

 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to
support the product.
Waterfall Model-Disadvantages

Problems:
1. Real projects are rarely follow the sequential model.
2. Difficult for the customer to state all the requirement
explicitly.
3. Assumes patience from customer - working version of
program will not available until programs not getting change
fully.
Waterfall Model-Advantages

 The advantage of waterfall development is that it allows for

departmentalization and control. A schedule can be set with
deadlines for each stage of development and a product can
proceed through the development process model phases one
by one.

 Development moves from concept, through design,

implementation, testing, installation, troubleshooting, and
ends up at operation and maintenance. Each phase of
development proceeds in strict order.
V-Model
V-Model

 V Model is an enhanced version of the classic waterfall model

whereby each level of the development life-cycle is verified
before moving on to the next level. With this model, software
testing explicitly starts at the very beginning, i.e. as soon as
the requirements are written.

 The left side of the "V" represents the decomposition of

requirements, and creation of system specifications

 The right side of the V represents integration of parts and their

validation
V-Model

 "Validation. The assurance that a product, service, or system

meets the needs of the customer and other identified
stakeholders. It often involves acceptance and suitability with
external customers. Contrast with verification.“

 "Verification. The evaluation of whether or not a product,

service, or system complies with a regulation, requirement,
specification, or imposed condition. It is often an internal
process. Contrast with validation."

 It is sometimes said that validation can be expressed by the

query "Are you building the right thing?" and verification by
"Are you building it right?"
V-Model-Advantages

 In V Model, Each phase has specific deliverables.

 Higher chance of success over the waterfall model due to the

development of test plans early on during the life cycle.

 Works well for small projects where requirements are easily

understood.
V-Model-Disadvantages

 Very rigid, like the waterfall model.

 Little flexibility and adjusting scope is difficult and expensive.

 Software is developed during the implementation phase, so no

early prototypes of the software are produced.
Incremental Process Model

C-
Communication
P - Planning
M – Modeling
C - Construction
D - Deployment
Incremental Process Model

 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.
 First Increment is often core product
— Includes basic requirement
— Many supplementary features (known & unknown) remain
undelivered
 A plan of next increment is prepared
— Modifications of the first increment
— Additional features of the first increment
 It is particularly useful when enough staffing is not available for the whole
project
 Incremental model focus more on delivery of operation product with each
increment.
Incremental Model-Applications

 Major requirements must be defined; however, some

functionalities or requested enhancements may evolve with
time.

 A new technology is being used and is being learnt by the

development team while working on the project.

 Resources with needed skill set are not available and are
planned to be used on contract basis for specific iterations.
Incremental Process Model-Advantages

 The cost of accommodating changing customer requirements

is reduced.
— Finding issues at an early stage of development enables to take
corrective measures in a limited budget.
— The amount of analysis and documentation that has to be redone is
much less than is required with the waterfall model.
 It is easier to get customer feedback on the development work
that has been done.
— Customers can comment on demonstrations of the software and see
how much has been implemented.
 More rapid delivery and deployment of useful software to the
customer is possible.
— Customers are able to use and gain value from the software earlier than
is possible with a waterfall process.
Incremental Process Model-Disadvantages

 The process is not visible.

— Managers need regular deliverables to measure progress. If systems
are developed quickly, it is not cost-effective to produce documents
that reflect every version of the system.
 System structure tends to degrade as new increments are
added.
— Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure. Incorporating
further software changes becomes increasingly difficult and costly.
Evolutionary Process Models

 Produce an increasingly more complete version of the

software with each iteration.
 Evolutionary Models are iterative.
 Evolutionary models are:
—Prototyping
—Spiral Model
—Concurrent Development Model
Evolutionary Process Models
Prototype Model

 Best approach when:

— Objectives defines by customer are general but does not have details
like input, processing, or output requirement.
— Developer may be unsure of the efficiency of an algorithm, O.S., or
the form that human machine interaction should take.
 It can be used as standalone process model.
 Model assist software engineer and customer to better understand what is
to be built when requirement are fuzzy.
 Prototyping start with communication, between a customer and software
engineer to define overall objective, identify requirements and make a
boundary.
 Going ahead, planned quickly and modeling (software layout visible to the
customers/end-user) occurs
Prototype Model

 Quick design leads to prototype construction.

 Prototype is deployed and evaluated by the customer/user.
 Feedback from customer/end user will refine requirement and
that is how iteration occurs during prototype to satisfy the
needs of the customer.

 Prototype can be serve as “the first system”.

 Both customers and developers like the prototyping paradigm.
 Customer/End user gets a feel for the actual system
 Developer get to build something immediately.
Types of prototyping- Throwaway prototyping

Also called close-ended prototyping. Throwaway or Rapid

Prototyping refers to the creation of a model that will
eventually be discarded rather than becoming part of the final
delivered software
 The most obvious reason for using Throwaway Prototyping is
that it can be done quickly
 Another strength of Throwaway Prototyping is its ability to
construct interfaces that the users can test.
Types of prototyping- Throwaway prototyping

In this approach the prototype is constructed with the idea that

it will be discarded and the final system will be built from
scratch. The steps in this approach are:
 Write preliminary requirements
 Design the prototype
 User experiences/uses the prototype, specifies new
requirements
 Repeat if necessary
 Write the final requirements
Types of prototyping- Evolutionary Prototyping

 Evolutionary Prototyping is quite different from Throwaway

Prototyping.
 The main goal when using Evolutionary Prototyping is to
build a very robust prototype in a structured manner and
constantly refine it.
 The reason for this is that the Evolutionary prototype, when
built, forms the heart of the new system, and the
improvements and further requirements will be built.
 When developing a system using Evolutionary Prototyping,
the system is continually refined and rebuilt.
"…evolutionary prototyping acknowledges that we do not
understand all the requirements and builds only those that
are well understood
Types of prototyping-Incremental Prototyping

 The final product is built as separate prototypes. At the end

the separate prototypes are merged in an overall design.
 By the help of incremental prototyping we can reduce the time
gap between user and software developer
Software Prototyping Application

 Software Prototyping is most useful in development of

systems having high level of user interactions such as online
systems. Systems which need users to fill out forms or go
through various screens before data is processed can use
prototyping very effectively to give the exact look and feel
even before the actual software is developed.

 Software that involves too much of data processing and most

of the functionality is internal with very little user interface
does not usually benefit from prototyping. Prototype
development could be an extra overhead in such projects and
may need lot of extra efforts
Prototyping-Advantages

 The software designer and implementer can obtain feedback

from the users early in the project.

 The client and the contractor can compare if the software

made matches the software specification, according to which
the software program is built.

 It also allows the software engineer some insight into the

accuracy of initial project estimates and whether the deadlines
and milestones proposed can be successfully met.
Prototyping-Disadvantages

 Users can begin to think that a prototype, intended to be

thrown away, is actually a final system that merely needs to be
finished or polished

 Developers can also become attached to prototypes they have

spent a great deal of effort producing; this can lead to
problems like attempting to convert a limited prototype into a
final system when it does not have an appropriate underlying
architecture.

 Developer often makes implementation in order to get a

prototype working quickly without considering other factors
in mind like OS, Programming language, etc.
Spiral Model

Couples iterative nature of prototyping with the controlled and

systematic aspects of the linear sequential model
 It provide potential for rapid development of increasingly
more complete version of the software.
 Using spiral, software developed in as series of evolutionary
release.
— Early iteration, release might be on paper or prototype.
— Later iteration, more complete version of software.
 Divided into framework activities (C,P,M,C,D). Each activity
represent one segment.
 Evolutionary process begins in a clockwise direction,
beginning at the center risk.
Spiral Model

 First circuit around the spiral might result in development of a

product specification. Subsequently, develop a prototype and
then progressively more sophisticated version of software.
Spiral Model

 Planning Phase: Requirements are gathered during the

planning phase. Requirements like ‘BRS’ that is ‘Business
Requirement Specifications’ and ‘SRS’ that is ‘System
Requirement specifications’.

 Risk Analysis: In the risk analysis phase, a process is

undertaken to identify risk and alternate solutions. A
prototype is produced at the end of the risk analysis phase. If
any risk is found during the risk analysis then alternate
solutions are suggested and implemented.
Spiral Model

 Engineering Phase: In this phase software is developed,

along with testing at the end of the phase. Hence in this phase
the development and testing is done.

 Evaluation phase: This phase allows the customer to evaluate

the output of the project to date before the project continues to
the next spiral.
Spiral Model

 Spiral models uses prototyping as a risk reduction mechanism

but, more important, enables the developer to apply the
prototyping approach at each stage in the evolution of the
product.

 It maintains the systematic stepwise approach suggested by

the classic life cycle but also incorporates it into an iterative
framework activity.

 If risks cannot be resolved, project is immediately terminated

Spiral Model-Applications

 For medium to high-risk projects.

 Long-term project commitment because of potential changes

to economic priorities as the requirements change with time.

 Customer is not sure of their requirements which is usually the

case.

 Requirements are complex and need evaluation to get clarity.

 Significant changes are expected in the product during the

development cycle.
Spiral Model-Disadvantages

 Management is more complex.

 End of project may not be known early.

 Not suitable for small or low risk projects and could be

expensive for small projects.

 Process is complex

 Spiral may go indefinitely

Concurrent Development Model
Concurrent Development Model

 It represented schematically as series of major technical

activities, tasks, and their associated states.

 It is often more appropriate for system engineering projects

where different engineering teams are involved.

 The activity-modeling may be in any one of the states for a

given time.

 All activities exist concurrently but reside in different states.

Concurrent Development Model

E.g.
 The analysis activity (existed in the none state while initial
customer communication was completed) now makes a
transition into the under development state.

 Analysis activity moves from the under development state

into the awaiting changes state only if customer indicates
changes in requirements.

 Series of event will trigger transition from state to state.

E.g. During initial stage there was inconsistency in design which

was uncovered. This will triggers the analysis action from the
Done state into Awaiting Changes state.
Concurrent Development Model

 Visibility of current state of project

 It define network of activities

 Each activities, actions and tasks on the network exists

simultaneously with other activities ,actions and tasks.

 Events generated at one point in the process network trigger

transitions among the states.