Lecture 3
Unit -1
Feasibility Study
First roughly understand what the
customer wants:
different data which would be input to the
system,
Main aim of feasibility study:determine processing needed on these data,
whether developing the product output data to be produced by the system,
financially worthwhile various constraints on the behavior of the
system.
technically feasible.
2
Activities during Feasibility Study
Work out Work out an overall understanding of the problem.
Formulate Formulate different solution strategies.
Examine alternate solution strategies in terms of:
• resources required,
Examine • cost of development, and
• development time.
3
Activities during • Perform a cost/benefit analysis:
Feasibility Study • to determine which solution is the
best.
• you may determine that none of the
solutions is feasible due to:
• high cost,
• resource constraints,
• technical reasons.
4
• Aim of this phase:
• understand the exact requirements of the
Requirements customer,
Analysis and
• document them properly.
Specification
• Consists of two distinct activities:
• requirements gathering and analysis
• requirements specification.
5
• Collect all related data from the
customer:
Goals of • analyse the collected data to clearly
Requirements understand what the customer wants,
Analysis • find out any inconsistencies and
incompleteness in the requirements,
• resolve all inconsistencies and
incompleteness.
6
Requirements • Gathering relevant data:
• usually collected from the end-users
Gathering through interviews and discussions.
• For example, for a business
accounting software:
• interview all the accountants of
the organization to find out their
requirements.
7
Requirements • The data you initially collect from the
users:
Analysis • would usually contain several
contradictions and ambiguities:
(CONT.) • each user typically has only a partial
and incomplete view of the system.
8
Requirements • Ambiguities and contradictions:
Analysis • must be identified
(CONT.) • resolved by discussions with the
customers.
• Next, requirements are organized:
• into a Software Requirements
Specification (SRS) document.
9
Requirements • Engineers doing requirements
Analysis analysis and specification:
(CONT.) • are designated as analysts.
10
• Design phase transforms
requirements
specification:
Design • into a form suitable for
implementation in some
programming language.
11
Design
Two design
In technical terms:
approaches:
• during design phase, • traditional approach,
software architecture • object oriented
is derived from the approach.
SRS document.
12
Traditional Design
Approach
• Consists of two
activities:
• Structured analysis
• Structured design
13
Structured Analysis Activity
1 2 3
Identify all the Identify data flow Decompose each
functions to be among the functions. function recursively
performed. into sub-functions.
• Identify data flow among
the subfunctions as well.
14
Structured Analysis (CONT.)
Carried out using Data flow After structured analysis, carry
diagrams (DFDs). out structured design:
architectural design (or high-level design)
detailed design (or low-level design).
15
Structured Design
High-level • decompose the system into modules,
design: • represent relationships among the modules.
Detailed • different modules designed in greater detail:
• data structures and algorithms for each
design: module are designed.
16
Object Oriented Design
• First identify various objects (real world entities)
occurring in the problem:
• identify the relationships among the objects.
• For example, the objects in a pay-roll software may
be:
• employees,
• managers,
• pay-roll register,
• Departments, etc.
17
Object Oriented Design (CONT.)
OOD has several
Object structure
advantages:
• further refined to obtain • lower development
the detailed design. effort,
• lower development time,
• better maintainability.
18
Implementation
• Purpose of implementation phase
(coding phase):
• translate software design into
source code.
19
Implementation • During the implementation phase:
• each module of the design is
coded,
• each module is unit tested
• tested independently as a
stand alone unit, and
debugged,
• each module is documented.
20
Implementation (CONT.)
The end product of
The purpose of
implementation
unit testing:
phase:
a set of program
test if individual
modules that
modules work
have been tested
correctly.
individually.
21
Integration and System Testing
Different modules are integrated During each integration step,
in a planned manner:
modules are almost never integrated in one the partially integrated system is tested.
shot.
Normally integration is carried out through a
number of steps.
22
Integration and M1 M2
System Testing M3 M4
23
System Testing
After all the modules
have been
• system testing is carried out.
successfully
integrated and tested:
• ensure that the developed system
Goal of system
functions according to its requirements
testing:
as specified in the SRS document.
24
Maintenance
• Maintenance of any software
product:
• requires much more effort
than the effort to develop the
product itself.
• development effort to
maintenance effort is
typically 40:60.
25
Maintenance (CONT.)
Corrective • Correct errors which were not discovered during the
maintenance: product development phases.
Perfective • Improve implementation of the system
maintenance: • enhance functionalities of the system.
Adaptive • Port software to a new environment,
• e.g. to a new computer or to a new operating
maintenance: system.
26
Classical waterfall model divides
life cycle into phases:
• Feasibility study,
• Requirements analysis and
Classical specification,
Waterfall Model • Design,
• Coding and unit testing,
• Integration and system testing,
27
• Maintenance.
Feasibility Study
Req. Analysis
Classical Design
Waterfall Coding
Model Testing
Maintenance
28
Classical Waterfall Model (CONT.)
29
Most organizations usually They also prescribe specific
define: methodologies for:
entry and exit criteria for every phase. specification,
design,
testing,
project management, etc.
30
1. no feedback paths
Drawbacks of
2. difficult to accommodate changes
classical water
fall model 3. No overlapping of phases
4. Limited customer interactions
• Classical waterfall model is idealistic:
• assumes that no defect is introduced during
Iterative Waterfall any development activity.
Model
• in practice:
• defects do get introduced in almost every
phase of the life cycle.
31
• Defects usually get detected much
later in the life cycle:
Iterative Waterfall
Model (CONT.) • For example, a design defect might
go unnoticed till the coding or
testing phase.
32
Once a defect is detected:
we need to go back to redo some of the work
the phase where it was done during that and all
introduced subsequent phases.
Iterative
Waterfall Model
(CONT.)
Therefore we need
feedback paths in the
classical waterfall model.
33
Feasibility Study
Iterative Req. Analysis
Waterfall Design
Model Coding
(CONT.) Testing
Maintenance
34
Errors
should • in the same phase in which they are
be introduced.
Iterative detected
Waterfall Model
(CONT.) • if a design problem is detected in
the design phase itself,
For • the problem can be taken care of
much more easily than, if it is
example: identified at the end of the
integration and system testing
phase.
35
The principle of is known as
detecting errors as close phase
Phase
to its point of containment of
introduction as possible: errors.
containment
of errors Iterative waterfall model
is most widely used
Almost every other
model is derived
from the waterfall
model. model.
36
Before starting actual
development,
a working prototype of the
Prototyping system should first be built.
Model A prototype is a toy
implementation of a system:
limited functional capabilities,
low reliability, 37
inefficient performance.
• The reason for
developing a prototype
is:
• it is impossible to ``get
Prototyping it right'' the first time,
Model (CONT.) • we must plan to throw
away the first product
• if we want to develop a
good product. 38
• The developed prototype is
submitted to the customer for
his evaluation:
Prototyping • Based on the user feedback,
requirements are refined.
Model (CONT.) • This cycle continues until the user
approves the prototype.
• The actual system is developed
using the classical waterfall
approach. 39
Prototyping Model (CONT.)
Build Prototype
Customer
Requirements satisfied
Customer
Gathering Quick Design Evaluation of Design
Prototype
Implement
Refine
Requirements
Test
Maintenance
40
Prototyping Model (CONT.)
• Even though construction of a working prototype model
involves additional cost --- overall development cost
might be lower for:
• systems with unclear user requirements,
41
Evolutionary Model
• Evolutionary 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.
42
Evolutionary Model (CONT.)
• Successive version of the product:
• functioning systems capable of performing some
useful work.
• A new release may include new functionality:
• also existing functionality in the current release
might have been enhanced.
43
Evolutionary Model (CONT.)
A A A
B B
44
Advantages of Evolutionary Model
• Users get a chance to experiment with a partially developed
system:
• much before the full working version is released,
• Helps finding exact user requirements:
• much before fully working system is developed.
• Core modules get tested thoroughly:
• reduces chances of errors in final product.
45
Disadvantages of Evolutionary Model
• 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.
46
Spiral Model
• Proposed by Boehm in 1988.
• Each loop of the spiral represents a phase of the
software process:
• the innermost loop might be concerned with
system feasibility,
• the next loop with system requirements
definition,
• 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.
47
Determine Identify &
Objectives Resolve Risks
Spiral Model Review and
(CONT.) plan for next
phase
Develop Next Level of Product
48
Spiral Model (CONT.)
• 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).
50
Identify Identify objectives of the phase,
Objective
Examine the risks associated with
Setting (First Examine these objectives.
Quadrant) • Risk: any adverse circumstance that might
hamper successful completion of a software
project.
Find Find alternate solutions possible.
51
For each identified a detailed
analysis is
project risk, carried out.
Risk
Assessment
and Steps are taken to reduce the
Reduction risk.
(Second
Quadrant) For example, if a
there is a risk that prototype
system
the requirements may be
are inappropriate: developed.
52
Development and Validation (Third
quadrant):
• develop and validate the next level of the
product.
Review and Planning (Fourth
Spiral Model quadrant):
(CONT.) • 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.
53
Spiral Model as a meta model
• Subsumes all discussed models:
• a single loop spiral represents waterfall model.
• uses an evolutionary approach --
• iterations through the spiral are evolutionary
levels.
• enables understanding and reacting to risks
during each iteration along the spiral.
• uses:
• prototyping as a risk reduction mechanism
• retains the step-wise approach of the
waterfall model.
54
Comparison of Different Life Cycle Models
55
Iterative waterfall model Prototype model is suitable for
projects not well understood:
most widely used model. user requirements
But, suitable only for well-
understood problems.
Comparison of Different Life Cycle Models (CONT.)
Evolutionary model • can be decomposed into a set of modules that can
be incrementally implemented,
is suitable for large • incremental delivery of the system is acceptable to
problems:
56
the customer.
• suitable for development of technically challenging
The spiral model: software products that are subject to several kinds
of risks.
