Chapter 2: Software Process Models

What is process models?

Software Engineering is a discipline that integrates process, methods, and tools for the
development of computer software. This strategy is often referred to as a process model
or a software engineering paradigm. A process model for software engineering is chosen
based on the nature of the project and application, the methods and tools to be used, and
the controls and deliverables that are required.

2.1 )Waterfall Model

Sometimes called the “classic life cycle” or the “waterfall model”, the linear sequential
model suggests a systematic, sequential approach to software development that begins at
the system level and progresses through analysis, design coding, testing, and
maintenance. It is the simplest and widely used process model for software development.
Here the phases involved in the software development are organized in a linear order.

Model after the conventional engineering cycle, the linear sequential model
encompasses the following activities.

1. System/Information engineering & modeling

2. Software requirement analysis
3. Design
4. Code generation
5. Testing
6. Maintenance

1) System / Information engineering and modeling:

Because software is always part of a larger system (or business), work begins by
establishing requirements for all system elements and then allocating some subset of these
requirements to software. This system view is essential when software must interface with
other elements such as hardware, people, and databases. This provides Top-Level design
and analysis.
2) Software requirement analysis:

The requirements gathering process is intensified and focused specifically on software.

Analysis is important for software engineer to understand the information domain for the
software, required functions, behaviour, performance, and interfacing. Requirements for
both the system and the software are documented and reviewed with the customer.

3) Design: Software design is actually a multi-step process that focuses on data structure,
software architecture, procedural detail and interface characterization. The design process
translates requirements into a representation of the software that can be assessed for
quality before code generation begins. The design documents must e prepared and stored
as a part of software configuration.

4) Code Generation: The code generation step translates the design into a machine
readable form. If design is performed in a detailed manner, code generation can be
accomplished mechanistically.

5) Testing: Once code has been generated, program testing begins. The testing process
focuses on the logical internals of the software, assuring that all statements have been
tested, and on the functional externals – that is, conducting test to uncover errors and
ensure that defined input will produce actual results that agree with required results.

6) Maintenance/ Support: Software will undergo change after it is delivered to the

customer. Change will occur because, errors have been encountered, because the software
must be adapted to accommodate changes in its external environment (e.g. change in
device) or customer requires functional or performance enhancement. Software
Maintenance/Support reapplies each of the preceding phases to an existing program.
Advantages:

 Simple and systematic.

 Linear ordering clearly marks the end of the one phase and starting of another phase
 The output of particular phase will be input put for next phase there for this
output are normally referred as intermediate product or based line

Disadvantages:

 Real projects rarely follow the sequential flow that the model proposes.
Changes can cause confusion as the project team proceeds.

1) Freezing the requirements

 It is difficult for the customer to state all requirements explicitly at the

beginning of the projects.
 The water fall model assumes that the requirement should be completely
specified before the rest of the development can proceed. In some situations it
might be required that, first develop a part of the system completely and then
later enhance a system where the client face an important role in requirement
specification.

2) No idea about the software

 The customer must have patience. A working version of program(s) will not be
available until late in the project time span.

3) Waste of time and money:Blocking state

 Development is often delayed unnecessarily. The linear nature of the classic life
cycle leads to “Blocking state” in which some project team members must wait
for other members of the team to complete dependant tasks.
 The time spent waiting can exceed the time spent on productive work.

2.2) Prototyping Model

Many times following situations are occurred ,

 Customers define a set of general objectives for software, but not detailed input,
processing or output requirements.
 The developer may be unsure of the efficiency of an algorithm, the adaptability of an
operation system, or the form that human-machine interaction should take.
In such cases prototyping approach can be used. Prototyping is an approach that enables the
developer to create a model of the software that must be built.
The aim of this model is to overcome
the limitations of the waterfall model
that is instead of freezing the
requirements before the design or
coding phase a throw-away prototype
is built to help understand the
requirements. The prototyping model
may be in any one of these forms:
1. Paper prototype (PC based
model): It enables the user to
understand how interaction
will occur (Slide Show or
diagram).
2. Working prototype: It
implements some subset of the
function required for the
desired software.
3. An existing program: It performs all the existing function required but we can improve it
for the new development.
 The prototyping paradigm begins with requirements gathering. Developer and customer
meet and define the overall objectives for the software, identify whatever requirements are
known, and outline areas where further definition is mandatory.
 A "quick design" then occurs. The quick design focuses on a representation of those aspects
of the software that will be visible to the customer/user (e.g., input approaches and output
formats). The quick design leads to the construction of a prototype.
 The prototype is evaluated by the customer/user and used to refine requirements for the
software to be developed. Iteration occurs as the prototype is tuned to satisfy the needs of
the customer, while at the same time enabling the developer to better understand what
needs to be done.
 Ideally, the prototype serves as a mechanism for identifying software requirements. If a
working prototype is built, the developer attempts to make user of existing program
fragments or applies tools. (e.g. report generation, window managers, etc…) that enable
working program to be generated quickly.

The important characteristics of Prototype Model are:

 The cost of requirement analysis must be kept low, inorder for it to be feasible.
 The development approach followed is “quick and dirty”, the focus is on quicker development
than on the quality.
 Only minimal documentation is required because it is a throw-away prototype model.
 This model is very useful where requirements are not properly understood in the
beginning.
 It is an excellent method for reducing some types of risks involved with a project.
 The developer often makes implementation compromises in order to get a prototype
working quickly.
2.3) INCREMENTAL MODEL

In incremental model the whole requirement is divided into various builds. Multiple
development cycles take place here, making the life cycle a “multi-waterfall” cycle.
Cycles are divided up into smaller, more easily managed modules.

The incremental build model is a method of software development where the product is
designed, implemented and tested incrementally until the product is finished. It involves
both development and maintenance. The product is defined as finished when it satisfies all
of its requirements.

In this model, each module passes through the requirements, design, implementation and
testing phases. A working version of software is produced during the first module, so you
have working software early on during the software life cycle. Each subsequent release of
the module adds function to the previous release.

The process continues till the complete system is achieved. For

example:

In the diagram above when we

work incrementally we are adding piece by piece but expect that each piece is fully finished.
Thus keep on adding the pieces until it‟s complete. As in the image above a person has
thought of the application.

Then he started building it and in the first iteration the first module of the application or
product is totally ready and can be demoed to the customers.

Likewise in the second iteration the other module is ready and integrated with the first
module. Similarly, in the third iteration the whole product is ready and integrated. Hence,
the product got ready step by step.

Diagram of Incremental model:

Advantages of Incremental model:

 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and handled during it‟d
iteration.

Disadvantages of Incremental model:

 Needs good planning and design.

 Needs a clear and complete definition of the whole system before it can be
broken down and built incrementally.
 Total cost is higher than waterfall.

When to use the Incremental model:

 This model can be used when the requirements of the complete system are
clearly defined and understood.
 Major requirements must be defined; however, some details can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.
Difference Between Prototype and Incremental Model

 A prototype model is iterative - it seeks to progressively improve the design of a

given solution based on customer feedback and input. An incremental model breaks
up an overall solution into increments of functionality and develops each increment
individually.
 It is an iterative model. Once a state is completed , based on the feedback from
the user changes are made accordingly that is it moves
progressively.Requirements can be updated.
 Incremental Development Model
 It divides the overall process into smaller functionalities or modules and work on
them separately.
 All the requirements are to be gathered before-hand.
2.4 ) Spiral Model

The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral. Its one
of the software development
models like Waterfall, prototype, Incremental.

1) Planning Phase:

Requirements are gathered during the planning phase. Requirements like „BRS‟ that is
„Bussiness Requirement Specifications‟ and „SRS‟ that is „System Requirement
specifications‟.

2) 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.

3) 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.

4) Evaluation phase:

This phase allows the customer to evaluate the output of the project to date before the
project continues to the next spiral.
Diagram of Spiral model:

Advantages of Spiral model:

 High amount of risk analysis hence, avoidance of Risk is enhanced.

 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.

Disadvantages of Spiral model:

 Can be a costly model to use.

 Risk analysis requires highly specific expertise.
 Project‟s success is highly dependent on the risk analysis phase.
 Doesn‟t work well for smaller projects.

When to use Spiral model:

 When costs and risk evaluation is important

 For medium to high-risk projects
 Long-term project commitment unwise because of potential changes to
economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and exploration)