IT314 - Software Engineering

Asim Banerjee

1st February 2011

[email protected]
Waterfall Model - Work Products (1/2)
Some of the work products of the waterfall model are:
• Systems Requirements Specification Document
• Project Plan
• System Design Document
• Detailed Design Document
• Test Plan (with test cases)
• Test Report
• Final Code
• Software manuals (e.g. User manual, Installation
manual, etc.)
• Review Reports
IT314 - Software Engineering 2
Waterfall Model - Work Products (2/2)
NOTE: Any other document that enables the
project team to achieve its project objectives,
should be maintained as one of the work
products of the project.

IT314 - Software Engineering 3

 Waterfall model – Limitations (1/2)
• Real projects rarely follow the sequential flow
that the model proposes.
• The model requires that all the requirements
are stated explicitly.
• Changes can cause confusion as the project
proceeds.
• The model has difficulty in accommodating the
natural uncertainty that exists in many
projects.

IT314 - Software Engineering 4

 Waterfall model – Limitations (2/2)
• The working versions of the programs are
available only late in the project time span,
hence the customer must have patience.
• A major blunder, if undetected until working
program is reviewed, can be disastrous.

IT314 - Software Engineering 5

Any Questions?

IT314 - Software Engineering 6

 Iterative Waterfall Model (1/2)
Feasibility Feasibility Report
Principle of “Phase
containment of Requirements Requirements document
errors”: Project Plan, Test Plan
– If and when errors Design System & Detailed
occur, they should design document
be detected (and
corrected) as early Coding
Programs
as possible
Product
Note: This dramatically Testing
reduces rework Test Report
Maintenance
IT314 - Software Engineering 7
 Iterative Waterfall Model (2/2)
• In real life, defects are likely to be introduced during each
phase of development
Note:
– It is desirable to minimize (if not eliminate) human errors during
software development
– These defects get detected (later) as the development
progresses
– Detected defects are then corrected by going back to the
appropriate phase (where the defect got introduced)
– This process can become time consuming and costly
• Hence it is desirable to detect the defects as early as
possible, preferably in the same phase itself i.e. before
moving on to the next phase.

IT314 - Software Engineering 8

Any Questions?

IT314 - Software Engineering 9

 Prototyping Model (1/6)

Requirements
• This approach suggests gathering
building a prototype before Quick
developing the actual design
software
Refine Build
requirements prototype

Customer Prototype
suggestions evaluation
Customer
Design acceptance

Implement

Test

IT314 - Software Engineering Maintain 10

 Prototyping Model (2/6)

Approach to prototyping:
– Prototypes are built using several shortcuts
• Limited functional capabilities
• Low reliability
• Inefficient performance
Note: Prototype usually turns out to be a very crude version
of the proposed system
– Prototyping may involve several iteration (until
receiving customer acceptance)
– After acceptance of the prototype, the development
can be done using a simple waterfall model

IT314 - Software Engineering 11

 Prototyping Model (3/6)

Note:
– Requirements gathering phase includes prototyping
– Prototype code may be thrown away
– Time/effort spent on prototype is worth it
• SRS gets supplemented with prototype
• Experience in building prototype is carried forward to
development
Advantages of prototyping
– Provides a good mechanism for understanding the
customer requirements
IT314 - Software Engineering 12
 Prototyping Model (4/6)

• Illustrates data formats, messages, reports, interactive

dialogues
• Specially useful for GUI (Graphic User Interface)
development
– Facilitates critical examination of technical issues
associated with software development
• Performance related issues
e.g. response times
e.g. efficiency of algorithms
– Reduces wasted development effort
• Difficulty of “getting a product right first time”
• Inevitable discarding of initial product
IT314 - Software Engineering 13
 Prototyping Model (5/6)

Situations warranting prototyping:

– User requirements are not well understood
– Technical aspects are not well understood
Problems with Prototyping model
– Usually the prototype is built without adequately
considering overall software quality or long-term
maintainability.
– Lack of appreciation that Prototype building is very
different from product building.

IT314 - Software Engineering 14

 Prototyping Model (6/6)

Problems with Prototyping model (Continued)

– Compromises on the choices like operating system or
programming language, are often made during
prototyping.
– Customer demands that the prototype be “quickly”
converted to a working product.
– The prototype is confused to be the actual product.

IT314 - Software Engineering 15

Any Questions?

IT314 - Software Engineering 16

Rapid Application Development (RAD) Model (1/2)

• Incremental software development process model

emphasizing an extremely short development cycle.
• It is an “high speed” adaptation of the waterfall model,
using component based construction.
• Enables a development team to create a “fully functional
system” within very short time periods, provided the
requirements are well understood and project scope is
constrained.
• RAD process works to reuse existing program
components (when possible) or create reusable
components (when necessary).
IT314 - Software Engineering 17
Rapid Application Development (RAD) Model (2/2)
• Problems with RAD model
– For large but scalable projects, RAD requires
sufficient human resources to create the right number
of RAD teams
– RAD requires equal commitment from the developers
and customers towards the rapid development
process.
– RAD cannot be applied to projects that cannot be
properly modularized.
– RAD is not appropriate for areas using new
technology (high technical risk).
– RAD requires that the requirements are “well
understood” and that the project scope is
“constrained”.
Any Questions?

IT314 - Software Engineering 19

 Evolutionary Model (1/3)
• This model is also known as SUCCESSIVE VERSIONS
model
• It involves:
– Breaking a system down into several modules (or functionalities)
such that
– These modules can be delivered in an incremental fashion
• Developer initially develops the core module and then
refines it by incrementally adding new functionalities
Note: Each successive version of the product is a working
version C
B B

A A A

IT314 - Software Engineering 20

 Evolutionary Model (2/3)

• Advantage:
– User gets an opportunity to experiment/use the partial system
much before the fully developed version is released
– Helps in eliciting requirements
– Core module gets tested very thoroughly
(since it gets tested at the time of each release)
– Entire resource requirements need not be committed to the
project at the same time
• Disadvantages:
– It is difficult to break down a system into functional units that can
be implemented in an incremental fashion

IT314 - Software Engineering 21

 Evolutionary Model (3/3)

Situations for using evolutionary model:

• Useful only in case of very large systems where:
– it is easy to identify modules which can be
implemented in incremental fashion
– incremental delivery is acceptable to the customer
• Examples of Evolutionary Models
– The incremental Model
– The Spiral Model
– The Concurrent development model

IT314 - Software Engineering 22

Any Questions?

IT314 - Software Engineering 23

 Customer Reaction (1/2)

Evolutionary model and Waterfall model

• Initially, the customer confidence is high
irrespective of the type of development approach
(waterfall or evolutionary)
• Reactions to lengthy monolithic development
process (e.g. waterfall model):
– Technical jargons are used
– Delays are announced
– Customer confidence drops off as there is no “visible
working product”
IT314 - Software Engineering 24
 Customer Reaction (2/2)

• Reactions to lengthy monolithic development

process (e.g. waterfall model) (continued):
– Results in customer resentment and resistance
• May manifest into sabotage or scapegoating,
• Reactions to Evolutionary model:
– In early stages, customer reactions are of the type
“this is not what I want”
– Incremental delivery, however, provides a much more
satisfying experience i.e. helps in overcoming initial
“loss of confidence”

IT314 - Software Engineering 25

Any Questions?

IT314 - Software Engineering 26

 Incremental Model (1/3)

• Combines elements of the waterfall model with

the iterative philosophy of prototyping.
• It applies the linear sequences in a staggered
fashion as calendar time progresses.
• Each linear sequence produces a deliverable
“increment” of the software.
• The process is repeated following the delivery of
each increment, until the complete product is
produced.
NOTE: The first increment is often the core product.
The client can use the core product
IT314 - Software Engineering 27
 Incremental Model (2/3)

Analysis Design Code Test

Increment 1

Increment 2 Analysis Design Code Test

Increment 3 Analysis Design Code Test

Incremental Model - The Time sequence of development

Calendar Time
NOTE: Feedback from usage of the core product is used to
modify the core product to better meet the needs of the
customer. Other features are added later.
IT314 - Software Engineering 28
 Incremental Model (3/3)

• Advantages of Incremental Model

– Useful when staffing is unavailable for a complete
implementation by the business deadline of the project
– Early increments can be implemented by fewer people, and
depending on the acceptability of the core product, more
resources can be added to implement subsequent stages.
– Increments can be planned to manage technical risks.
• Disadvantages of Incremental Model
– Agreement on the core product is not easy
– The process can be time consuming
– Depends on the client agreeing for it.

IT314 - Software Engineering 29

Any Questions?

IT314 - Software Engineering 30

 Spiral Model (1/5)
1: Determine objective. 2. Evaluate alternatives.
Identify alternatives. Identify/ resolve risks

4. Customer evaluation 3. Develop next level

of prototype of the product
Note: RADIUS indicates cost
ANGLE indicates progress
IT314 - Software Engineering 31
 Spiral Model (2/5)

Four Quadrants of Spiral Model

1. Identify objectives of the product and identify
alternative solutions.
2. Evaluate alternative solutions. Identify
potential risks. Resolve risks by building
prototype
3. Develop next level of product. Verify this
product
4. Evaluation of the product by customer.

IT314 - Software Engineering 32

 Spiral Model (3/5)

• Plan the next iteration around the spiral (if

required)
NOTE:
• Radius of the spiral (at any point) indicates
the cost incurred on the project (so far)
• Angular dimension represents progress
• Spiral model can be viewed as meta model
– Single loop spiral model represents a Waterfall
model

IT314 - Software Engineering 33

 Spiral Model (4/5)

• Spiral model … meta model (Continued)

– Looping around each cycle represents evolutionary
model
• More complete version of the product gets built
progressively
– Prototyping is used as a risk reduction mechanism
• Provides direct support for coping with project risks
• After final iteration, all risks are resolved and the
“requirements” are ready for development
– Completion of the final product is done according to
the Waterfall Model
IT314 - Software Engineering 34
 Spiral Model (5/5)

NOTE: Spiral model subsumes all the models

discussed earlier
• Situations for using spiral model
– Development of technically challenging products
which are prone to several risks.

IT314 - Software Engineering 35

Any Questions?

IT314 - Software Engineering 36

Concurrent Development Model (1/3)
• Typically in a large project, there are
personnel on the project involved in activities
typically associated with many phases of
development simultaneously.
• The model can be represented schematically
as a series of major technical activities, tasks
and their associated states
• Some of the States Possible
– Under development
– Awaiting Changes
– Under Revision
IT314 - Software Engineering 37
 Concurrent Development Model (2/3)
• Some of the States Possible (Continued)
– Under Review
– Baselined
– Done
• It defines a series of events that will trigger
transition from one state to another for each of
the SE activities

IT314 - Software Engineering 38

Concurrent Development Model (3/3)
None

Activity A
Under Development

Schematic
representation Awaiting Changes Under Review
of an activity (A)
with concurrent Under Revision
development
process model Baselined

IT314 - Software Engineering Done 39

Recap: Software Life Cycle Models
• Classical Waterfall Model
• Iterative Waterfall Model
• Prototyping Model
• Rapid Application Development (RAD) model
• Evolutionary Models
– Incremental Model
– Spiral Model
– Concurrent Development Model
– Schematic representation of an activity (A) with
concurrent development process model
IT314 - Software Engineering 40
 Group Assignment
Assess the merits and demerits of each
development life cycle model and select
one development life cycle model for your
project. Justify your selection.

Submit by: 4th February 2011 12:00 hrs.

IT314 - Software Engineering 41