LECTURE -5

SOFTWARE ENGINEERING
OTHER LIFE CYCLE MODELS

1
 ITERATIVE WATERFALL MODEL

Defects usually get detected much later in the life cycle:

o For example, a design defect might go unnoticed till the coding or testing
phase.

Once a defect is detected:

o we need to go back to the phase where it was introduced
o redo some of the work done during that and all subsequent phases.

Therefore we need feedback paths in the classical waterfall model

2
ITERATIVE WATERFALL MODEL

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance

3
ITERATIVE WATERFALL MODEL
o Errors should be detected in the same phase in which they are introduced.

 For example:
o if a design problem is detected in the design phase itself,
o the problem can be taken care of much more easily
o than if it is identified at the end of the integration and system testing
phase.
 Reason: rework must be carried out not only to the design but also to code
and test phases.

 The principle of detecting errors as close to its point of introduction as

possible:
 is known as phase containment of errors.

 Irrespective of the life cycle model actually followed:

o the documents should reflect a classical waterfall model of
development,
o comprehension of the documents is facilitated. 4
PROTOTYPING MODEL
Before starting actual development,
o a working prototype of the system should first be built.
A prototype is a toy implementation of a system:
o limited functional capabilities,
o low reliability,
o inefficient performance.

Reasons for developing a prototype :

 Illustrate to the customer:
 input data formats, messages, reports, or interactive dialogs.
 Examine technical issues associated with product development:
 Often major design decisions depend on issues like:
 response time of a hardware controller,
 efficiency of a sorting algorithm, etc.

5
PROTOTYPING MODEL
 The third reason for developing a prototype is:
 it is impossible to get it right the first time,
 we must plan to throw away the first product
 if we want to develop a good product.
 Methodology
o Start with approximate requirements.
o Carry out a quick design.
o Prototype model is built using several short-cuts:
o Short-cuts might involve using inefficient, inaccurate, or dummy functions.
o A function may use a table look-up rather than performing the actual
computations.
 The developed prototype is submitted to the customer for his evaluation:
 Based on the user feedback, requirements are refined.
 This cycle continues until the user approves the prototype.
The actual system is developed using the classical waterfall approach.

6
PROTOTYPING MODEL

Build Prototype

Requirements Customer Customer

Gathering Quick Design Evaluation of satisfied Design
Prototype

Refine Implement
Requirements

Test

Maintain

7
 PROTOTYPING MODEL
 Requirements analysis and specification phase becomes redundant:
o final working prototype (with all user feedbacks incorporated) serves as an
animated requirements specification.

 Design and code for the prototype is usually thrown away:

o However, the experience gathered from developing the prototype helps a
great deal while developing the actual product.

 Even though construction of a working prototype model involves additional cost --

- overall development cost might be lower for:
o systems with unclear user requirements,
o systems with unresolved technical issues.

 Many user requirements get properly defined and technical issues get resolved:
 these would have appeared later as change requests and resulted in
incurring massive redesign costs.
8
EVOLUTIONARY MODEL

 Evolutionary model (aka successive versions or incremental

model):
 The system is broken down into several modules which can
be incrementally implemented and delivered.

 First develop the core modules of the system.

 The initial product skeleton is refined into increasing levels of

capability:
 by adding new functionalities in successive versions.

9
EVOLUTIONARY MODEL

Successive version of the product:

o functioning systems capable of performing some useful
work.
o A new release may include new functionality:
o also existing functionality in the current release might
have been enhanced.

10
EVOLUTIONARY MODEL (CONT.)

C
A AB A
B

11
ADVANTAGE AND DISADVANTAGE OF
EVOLUTIONARY MODEL
Advantages :

Users get a chance to experiment with a partially developed system:

o much before the full working version is released,
Helps finding exact user requirements:
o much before fully working system is developed.
Core modules get tested thoroughly:
o reduces chances of errors in final product.

Disadvantages :
Often, difficult to subdivide problems into functional units:
 which can be incrementally implemented and delivered.
 evolutionary model is useful for very large problems,
 where it is easier to find modules for incremental implementation.

12
EVOLUTIONARY MODEL WITH ITERATION
Many organizations use a combination of iterative and incremental
development:
o a new release may include new functionality
o existing functionality from the current release may also have been
modified.
Several advantages:
o Training can start on an earlier release
o customer feedback taken into account
o Markets can be created:
o for functionality that has never been offered.
o Frequent releases allow developers to fix unanticipated problems
quickly

13
SPIRAL MODEL
 Proposed by Boehm in 1988.
 Each loop of the spiral represents a phase of the software process:
o the innermost loop might be concerned with system feasibility,
o the next loop with system requirements definition,
o the next one with system design, and so on.
 There are no fixed phases in this model, the phases shown in the figure are
just examples.

 The team must decide:

 how to structure the project into phases.
 Start work using some generic model:
 add extra phases
 for specific projects or when problems are identified during a project.
 Each loop in the spiral is split into four sectors (quadrants).

14
SPIRAL MODEL (CONT.)

Determine Identify &

Objectives Resolve Risks

Customer
Evaluation of Develop Next
Prototype Level of Product

15
 OBJECTIVE SETTING (FIRST QUADRANT)
o Identify objectives of the phase,
o Examine the risks associated with these objectives.
o Risk:
o any adverse circumstance that might hamper
successful completion of a software project.
o Find alternate solutions possible.

RISK ASSESSMENT AND REDUCTION (SECOND QUADRANT)

o For each identified project risk,

o a detailed analysis is carried out.
o Steps are taken to reduce the risk.
o For example, if there is a risk that the requirements are inappropriate:
o a prototype system may be developed.

16
SPIRAL MODEL

Development and Validation (Third quadrant)

 develop and validate the next level of the product.

Review and Planning (Fourth quadrant):

 review the results achieved so far with the customer and
plan the next iteration around the spiral.

 With each iteration around the spiral:

 progressively more complete version of the software gets
built.

17
SPIRAL MODEL AS A META MODEL
Subsumes all discussed models:
o a single loop spiral represents waterfall model.
o uses an evolutionary approach --
o iterations through the spiral are evolutionary levels.
o enables understanding and reacting to risks during each iteration
along the spiral.
o uses:
o prototyping as a risk reduction mechanism
o retains the step-wise approach of the waterfall model.

18
COMPARISON OF LIFE CYCLE MODELS
o Iterative waterfall model
 most widely used model.
 But, suitable only for well-understood problems.
o Prototype model is suitable for projects not well understood:
 user requirements
 technical aspects
o Evolutionary model is suitable for large problems:
 can be decomposed into a set of modules that can be incrementally
implemented,
 incremental delivery of the system is acceptable to the customer.
o The spiral model:
 suitable for development of technically challenging software products
that are subject to several kinds of risks.

19
20