The document describes the classical waterfall model of software engineering. It divides the software development life cycle into six sequential phases: feasibility study, requirements analysis and specification, design, coding and unit testing, integration and system testing, and maintenance. Each phase has specific goals and activities. For example, the requirements analysis phase aims to understand customer requirements and document them, while the design phase transforms requirements into a suitable form for implementation. The waterfall model is best for projects where requirements are stable and the technology is well understood.

1. SOFTWARE ENGINEERING
TOPIC NAME – CLASSICAL WATERFALL MODEL
PAPER NAME – SOFTWARE ENGINEERING
PAPER CODE – ESC501
STUDENT NAME – PROVAT MAJHI
STREAM – CSE
SEMESTER – 5TH
UNIVERSITY ROLL NUMBER – 23000121055

2. Classical waterfall model
Classical waterfall model divides life cycle into following
phases:
• Feasibility study
• Requirements analysis and specification
• Design
• Coding and unit testing
• Integration and system testing
• Maintenance

3. Classical Waterfall Model CONTD.
Feasibility study
Req. Analysis
&
specification
Design
Coding & Unit
Testing
Integration &
System
Testing
Maintenance

4. Feasibility Study
• Aim of feasibility study
- To determine whether developing the product is
• financially worthwhile
• technically feasible.
• Main activities during Feasibility Study
ˉWork out an overall understanding of the problem.
ˉFormulate different solution strategies.
ˉExamine alternate solution strategies
ˉPerform a cost/benefit analysis to determine which solution is the best.

5. Requirements Analysis and Specification
Aim of this phase:
- understand the exact requirements of the customer,
- document them properly.
Consists of two distinct activities:
- requirements gathering and analysis
- requirements specification.

6. Requirements Gathering
Collect all related data from the customer:
• analyze the collected data to clearly understand
• what the customer wants,
Gathering relevant data:
• usually collected from the end-users 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 Specifications
Next, requirements are organized:
• into a Software Requirements Specification (SRS)
document.
Engineers doing requirements analysis and
specification:
• are designated as Requirement Engineer or analysts.

8. 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 structured approach,
• object oriented approach.
• Traditional structured approach consists of:
• Structured analysis
• Structured design

9. Structured Analysis
Structured Analysis Steps
Identify all the functions to be performed.
Identify data flow among the functions.
Decompose each function recursively into sub- functions.
• Identify data flow among the sub functions as well.
Carry out design using Data flow diagrams (DFDs).
After structured analysis, carry out structured design:
• architectural design (or high-level design)
• detailed design (or low-level design).

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

11. 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, Departments, etc.
Object structure
• further refined to obtain the detailed design.

12. Coding and Unit Testing
Purpose of coding and unit testing phase:
• translate software design into source code.
During this phase:
• each module of the design is coded
• each module is unit tested
• each module is documented.

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

14. Integration and System Testing contd..
After all the modules have been successfully integrated and
tested:
• system testing is carried out.
Goal of system testing:
• ensure that the developed system functions according to its
requirements as specified in the SRS document.

15. Maintenance
Maintenance of any software product:
• requires much more effort than the effort to develop the product itself.
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.

16. When to use the Waterfall Model?
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.