0% found this document useful (0 votes)
38 views23 pages

Overview of the Classical Waterfall Model

The document discusses several software development life cycle models including the classical waterfall model, V-model, incremental model, evolutionary models using prototyping and spiral development, and a concurrent development model.

Uploaded by

Anushka Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
38 views23 pages

Overview of the Classical Waterfall Model

The document discusses several software development life cycle models including the classical waterfall model, V-model, incremental model, evolutionary models using prototyping and spiral development, and a concurrent development model.

Uploaded by

Anushka Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 23

LECTURE -4

SOFTWARE DEVELOPMENT LIFE CYCLE


MODELS
(INCLUDING CLASSICAL WATERFALL MODEL)

1
CLASSICAL WATERFALL MODEL

Classical waterfall model divides life cycle into phases:

 feasibility study,
 requirements analysis and specification,
 design,
 coding and unit testing,
 integration and system testing,
 maintenance.

2
CLASSICAL WATERFALL MODEL

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance

3
THE WATERFALL MODEL

Communicat ion
project init iat ion Planning
requirement gat hering estimating Modeling
scheduling
analysis Const ruct ion
tracking
design Deployment
code
t est delivery
support
f eedback

Source : S/W Engineering Pressman 7/e


4
THE V-MODEL

Source : S/W Engineering Pressman 7/e


5
THE INCREMENTAL MODEL

increment # n
Co m m u n i c a t i o n
Pl a n n i n g

Mode ling
analys is Co n s t r u c t i o n
design
code De p l o y m e n t
t est d e l i v e ry
fe edbac k

delivery of
increment # 2 nt h increment

Co m m u n i c a t i o n
Pla nni ng
M odeling
analys is Co n s t r u c t i o n
design code De p l o y m e n t
t est d e l i v e ry
fe edbac k
delivery of
increment # 1 2nd increment

Co m m u n i c a t i o n
Pla nni ng
M ode ling
analy sis Co n s t r u c t i o n
design code
t est
De p l o y m e n t
de l i v e ry delivery of
feedba ck

1st increment

project calendar time


Source : S/W Engineering Pressman 7/e
6
EVOLUTIONARY MODELS: PROTOTYPING

Quick
Q u ick p lan

Co m m u n icat io n plan
communication

Modeling
Mo d e l i n g
Q u ick d e sig n
Quick design

Deploym ent
Deployment Construction
D e live r y
delivery & of Co
prototype
n st r u ct io n
& Fe e d b ack Construction
feedback of
ofr oprototype
p t o t yp e

Source : S/W Engineering Pressman 7/e


7
EVOLUTIONARY MODELS: THE SPIRAL MODEL
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test

Source : S/W Engineering Pressman 7/e


8
EVOLUTIONARY MODELS: CONCURRENT MODEL
none

Modeling act ivit y

represents the state


Under of a software engineering
activity or task
development

Await ing
changes

Under review

Under
revision

Baselined

Done

Source : S/W Engineering Pressman 7/e


9
RELATIVE EFFORT FOR PHASES

Phases between feasibility study and


testing 60
 known as development phases. 50
Among all life cycle phases Relative Effort
40
 maintenance phase consumes
maximum effort. 30

Among development phases, 20


 testing phase consumes the maximum 10
effort. 0

Maintnce
Design

Test
Coding
Req. Sp
CLASSICAL WATERFALL MODEL
Most organizations usually define:
 standards on the outputs (deliverables) produced at the end of every
phase
 entry and exit criteria for every phase.
They also prescribe specific methodologies for:
 specification,
 design,
 testing,
 project management, etc.
The guidelines and methodologies of an organization:
 called the organization's software development methodology.
Software development organizations:
 expect fresh engineers to master the organization's software
development methodology.
FEASIBILITY STUDY
Main aim of feasibility study:determine whether developing the
product
 financially worthwhile
 technically feasible.
First roughly understand what the customer wants:
 different data which would be input to the system,
 processing needed on these data,
 output data to be produced by the system,
 various constraints on the behavior of the system.

12
ACTIVITIES DURING FEASIBILITY STUDY

 Work out an overall understanding of the problem.


 Formulate different solution strategies.
 Examine alternate solution strategies in terms of:
 resources required,
 cost of development, and
 development time.
 Perform a cost/benefit analysis:
 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.

13
REQUIREMENTS ANALYSIS AND SPECIFICATION
Aim of this phase:
o understand the exact requirements of the customer,
o document them properly.
Consists of two distinct activities:
o requirements gathering and analysis
o requirements specification.

GOALS OF REQUIREMENTS ANALYSIS


Collect all related data from the customer:
o analyze the collected data to clearly understand what the customer
wants,
o find out any inconsistencies and incompleteness in the requirements,
o resolve all inconsistencies and incompleteness.

14
REQUIREMENTS GATHERING
Gathering relevant data:
o usually collected from the end-users through interviews and
discussions.
o For example, for a business accounting software:
o interview all the accountants of the organization to find out their
requirements.
REQUIREMENTS ANALYSIS
The data you initially collect from the users:
 would usually contain several contradictions and ambiguities:
 each user typically has only a partial and incomplete view of the system.
Ambiguities and contradictions:
 must be identified
 resolved by discussions with the customers.
Next, requirements are organized:
 into a Software Requirements Specification (SRS) document
 Engineers doing requirements analysis and specification are designated 15
as analysts.
DESIGN

 Design phase transforms requirements specification:


 into a form suitable for implementation in some programming
language.
 In technical terms:
 during design phase, software architecture is derived from the SRS
document.
 Two design approaches:
 traditional approach,
 object oriented approach

16
TRADITIONAL DESIGN APPROACH
Consists of two activities:
 Structured analysis
 Structured design

STRUCTURED ANALYSIS

o Identify all the functions to be performed.


o Identify data flow among the functions.
o Decompose each function recursively into sub-functions.
 Identify data flow among the sub functions as well.
o Carried out using Data flow diagrams (DFDs).
o After structured analysis, carry out structured design:
 architectural design (or high-level design)
 detailed design (or low-level design).

17
STRUCTURED DESIGN
 High-level design:
 decompose the system into modules,
 represent invocation relationships among the modules.
 Detailed design:
 different modules designed in greater detail:
 data structures and algorithms for each module are designed.

OBJECT ORIENTED DESIGN


 First identify various objects (real world entities) occurring in the problem:
o identify the relationships among the objects.
o For example, the objects in a pay-roll software may be:
o employees, managers, pay-roll register,Departments, etc.

 Object structure
 further refined to obtain the detailed design.
 OOD has several advantages:
 lower development effort,
 lower development time, 18
 better maintainability.
IMPLEMENTATION
 Purpose of implementation phase (aka coding and unit testing
phase):
o translate software design into source code.
 During the implementation phase:
o each module of the design is coded,
o each module is unit tested
o tested independently as a stand alone unit, and
debugged,
o each module is documented.
 The purpose of unit testing:
o test if individual modules work correctly.
 The end product of implementation phase:
o a set of program modules that have been tested
individually. 19
INTEGRATION AND SYSTEM TESTING
 Different modules are integrated in a planned manner:
 modules are almost never integrated in one shot.
 Normally integration is carried out through a number of
steps.
 During each integration step,
 the partially integrated system is tested.
 After all the modules have been successfully integrated and
tested:
 system testing is carried out.
Goal of system testing:
To ensure that the developed system functions according to
its requirements as specified in the SRS document

20
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.

Types of Maintenance

Corrective maintenance:
 Correct errors which were not discovered during the product
development phases.
Perfective maintenance:
 Improve implementation of the system
 enhance functionalities of the system.
Adaptive maintenance:
 Port software to a new environment,
 e.g. to a new computer or to a new operating system.

21
Assignment 3

“Cambridge Analytica- Facebook Data


Scandal and Controversy: Issues,
Methodology and Challenges”

Write an article 05 pages ( 12-15


paragraph) on above topic.
Last Date : 10 Days from Today.

You will be allotted a time for


presentation on above topic.

22
23

You might also like