Waterfall Model

Waterfall Model



1-)Defination of Problem

At this stage, it is tried to be understood whether the system is necessary (why the system should be created) and how the project team system will be formed.

1.1-)Project Start

At the beginning of the project, it is tried to determine the contribution of the system to the operation. A new system request usually comes from outside the domain of information technology (such as marketing department, accounting department). It briefly indicates the need for the system, the needs of the operator, and how the system will meet this need.

The software team performs a feasibility analysis by working with the operation that requires the system.
• Technical feasibility (Is it feasible?)
• Economic feasibility (profitable?)
• Organizational feasibility (will it be used if it is done?)
As a result of this analysis, it is decided whether or not to accept the project.

As a result of this stage, a feasibility document is prepared.

1.2-)Project Managament

After the project is accepted, the project manager prepares a work plan, performs task sharing among the staff, and decides on the techniques that will help control the project throughout the entire software development life cycle.

At the end of this stage a project plan is prepared.


At this stage;
• Who will use the system?
• What will the system do?
• Where should the system be used?
• When will the system be used?
questions are answered.

At this stage, the project team examines existing systems, if any, identifies possible improvements and creates a draft for the new system.

This phase consists of three steps;
• An analysis strategy is developed. Existing system and problems are examined. How to design the new system is determined.
• Requirements are determined. Generally face-to-face interviews and surveys are used. How the operator will work with the new system is determined.
• System proposal is prepared. Analyzes made, drafts and models proposed for the new system are collected in the system recommendation document. This proposal is submitted to the operating system and to other decision makers. According to this proposal, it is decided whether the system will continue to develop.

At the end of this stage a system recommendation document is prepared.


At this stage it is decided how the system will work. The required software, hardware, computer network infrastructure, user interface, forms and reports are identified.

The design phase consists of four parts
• User Interface Design
(Such as menus, buttons, forms, reports to be used)
• Database Design
(The data to be stored on the disk will be determined, which data will be stored in which files, and where?)
• Data Structure Design
(In program, the data to be stored in memory is determined)
• Algorithm Design
(Flow diagrams, class diagrams)

At the end of the design phase, the feasibility analysis and the project plan are reviewed again and it is decided whether or not to continue the project.

At the end of this stage, the prepared documents are transferred to the programming team (programmers).



At this stage, the codes of the system are written or purchased.

• System development.
System codes are written and tested
• System installation
System modules are combined
New system is tried instead of old system
• System support
The new system is reviewed and the necessary changes are identified

At the end of this stage, an executable system is prepared.


It is checked whether the system works as designed.

• Installation test (working in hardware?)
• Compatibility test (Other applications, operating system (i) i)
• Regression testing (Are there any new errors after the changes?)
• Acceptance test (Customer test)
• Alpha test
• Beta test
• Functionality test
• Destructive testing
• Performance test
• Usability test
• Accessibility testing
• Safety test
• Internationalization – Localization test

Errors found at the end of this phase are identified as to how these errors are eliminated or how they can be removed.

6-)Maintenance – Repair

Improvements or changes that need to be made after the system has been delivered.

All stages may need to be repeated.


Documentation may not be seen as a separate phase since documentation is at the end of each stage.

• User Documents
• Technical Documents


Suitable for small projects where the requirements do not change

Steps can also be understood by the customer

Easy to manage
Job distribution
Project plan, schedule

Customer approval and / or payment may be made at the end of each stage.


Assumes system requirements will not change.
Existing (manual or software) can be accepted if the system is being rewritten
It’s hard for new systems (even the user may not know what he wants)

Technology may change for long-lasting systems

All software comes out at the end
The time for the software to reach the user is long.
The user will not see what he or she will take until very late
Either all or nothing

Swelling of requirements
Adds features that users or management may not use

Documentation is required at each stage

It may be necessary to repeat the previous steps to get the errors found in the test phase.

Leave a Reply

Your email address will not be published. Required fields are marked *