Waterfall Model And It’s Disadvantages
Read Time:11 Minute, 14 Second
WATERFALL MODEL
The waterfall model is possibly the most obvious and intuitive way in which software can be developed through team effort.
We can think of the waterfall model as a generic model that has been extended in many ways for catering to certain specific software development situations to realise all other software life cycle models.
Classical Waterfall Model
Classical waterfall model is intuitively the most obvious way to develop software.
It is simple but idealistic. In fact, it is hard to put this model into use in any non-trivial software development project.
One might wonder if this model is hard to use in practical development projects, then why study it at all? The reason is that all other life cycle models can be thought of as being extensions of the classical waterfall model.
Therefore, it makes sense to first understand the classical waterfall model, in order to be able to develop a proper understanding of other life cycle models. Besides, we shall see later in this text that this model though not used for software development; is implicitly used while documenting software.
The classical waterfall model divides the life cycle into a set of phases as shown in the following figure.
It can be easily observed from this figure that the diagrammatic representation of the classical waterfall model resembles a multi-level waterfall. This resemblance justifies the name of the model.
Phases of the classical waterfall model
The different phases of the classical waterfall model are
- feasibility study
- requirements analysis and specification
- design
- coding and unit testing
- integration and system testing
- maintenance.
The phases starting from the feasibility study to the integration and system testing phase are known as the development phases.
A software is developed during the development phases, and at the completion of the development phases, the software is delivered to the customer. After the delivery of software, customers start to use the software signalling the commencement of the operation phase.
As the customers start to use the software, changes to it become necessary on account of bug fixes and feature extensions, causing maintenance works to be undertaken. Therefore, the last phase is also known as the maintenance phase of the life cycle.
In the waterfall model, different life cycle phases typically require relatively different amounts of effort to be put in by the development team. The relative amounts of effort spent on different phases for a typical software has been shown in the following figure.
Observe from the above figure that among all the life cycle phases, the maintenance phase normally requires the maximum effort. On the average, about 60 per cent of the total effort put in by the development team in the entire life cycle is spent on the maintenance activities alone.
However, among the development phases, the integration and system testing phase requires the maximum effort in a typical development project
Feasibility study
The main focus of the feasibility study stage is to determine whether it would be financially and technically feasible to develop the software.
The feasibility study involves carrying out several activities such as collection of basic information relating to the software such as the different data items that would be input to the system, the processing required to be carried out on these data, the output data required to be produced by the system, as well as various constraints on the development.
These collected data are analysed to perform at the following:
Development of an overall understanding of the problem:
It is necessary to first develop an overall understanding of what the customer requires to be developed. For this, only the the important requirements of the customer need to be understood and the details of various requirements such as the screen layouts required in the graphical user interface (GUI), specific formulas or algorithms required for producing the required results, and the databases schema to be used are ignored.
Formulation of the various possible strategies for solving the problem:
In this activity, various possible high-level solution schemes to the problem are determined.
For example, solution in a client-server framework and a standalone application framework may be explored.
Evaluation of the different solution strategies:
The different identified solution schemes are analysed to evaluate their benefits and shortcomings.
Such evaluation often requires making approximate estimates of the resources required, cost of development, and development time required.
The different solutions are compared based on the estimations that have been worked out. Once the best solution is identified, all activities in the later phases are carried out as per this solution.
At this stage, it may also be determined that none of the solutions is feasible due to high cost, resource constraints, or some technical reasons. This scenario would, of course, require the project to be abandoned.
We can summarise the outcome of the feasibility study phase by noting that other than deciding whether to take up a project or not, at this stage very high-level decisions regarding the solution strategy is defined. Therefore, feasibility study is a very crucial stage in software development.
Requirements analysis and specification
The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly.
This phase consists of two distinct activities,
- Requirements gathering and analysis
- Requirements specification.
1.Requirements gathering and analysis:
The goal of the requirements gathering activity is to collect all relevant information regarding the software to be developed from the customer with a view to clearly understand the requirements.
For this, first requirements are gathered from the customer and then the gathered requirements are analysed.
The goal of the requirements analysis activity is to weed out the incompleteness and inconsistencies in these gathered requirements.
2.Requirements specification:
After the requirement gathering and analysis activities are complete, the identified requirements are documented. This is called a software requirements specification (SRS) document.
The SRS document is written using end-user terminology. This makes the SRS document understandable to the customer.
Therefore, understandability of the SRS document is an important issue.
The SRS document normally serves as a contract between the development team and the customer.
Any future dispute between the customer and the developers can be settled by examining the SRS document.
The SRS document is therefore an important document which must be thoroughly understood by the development team, and reviewed jointly with the customer.
The SRS document not only forms the basis for carrying out all the development activities, but several documents such as users’ manuals, system test plan, etc. are prepared directly based on it.
Design
The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language.
In technical terms, during the design phase the software architecture is derived from the SRS document.
Two distinctly different design approaches are popularly being used at present
the procedural and object-oriented design approaches.
Procedural design approach:
The traditional design approach is in use in many software development projects at the present time.
This traditional design technique is based on the data flow-oriented design approach.
It consists of two important activities; first structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined.
This is followed by a structured design step where the results of structured analysis are transformed into the software design.
During structured analysis, the functional requirements specified in the SRS document are decomposed into subfunctions and the data-flow among these subfunctions is analysed and represented diagrammatically in the form of DFDs.
Structured design is undertaken once the structured analysis activity is complete.
Structured design consists of two main activities—architectural design (also called high-level design ) and detailed design (also called Low-level design ).
High-level design involves decomposing the system into modules, and representing the interfaces and the invocation relationships among the modules.
A high-level software design is sometimes referred to as software architecture.
During the detailed design activity, internals of the individual modules such as the data structures and algorithms of the modules are designed and documented.
Object-oriented design approach:
In this technique, various objects that occur in the problem domain and the solution domain are first identified and the different relationships that exist among these objects are identified.
The object structure is further refined to obtain the detailed design.
Coding and unit testing
The purpose of the coding and unit testing phase is to translate a software design into source code and to ensure that individually each function is working correctly.
The coding phase is also sometimes called the implementation phase, since the design is implemented into a workable solution in this phase.
Each component of the design is implemented as a program module. The end-product of this phase is a set of program modules that have been individually unit tested.
The main objective of unit testing is to determine the correct working of the individual modules.
The specific activities carried out during unit testing include designing test cases, testing, debugging to fix problems, and management of test cases.
Integration and system testing
Integration of different modules is undertaken soon after they have been coded and unit tested.
During the integration and system testing phase, the different modules are integrated in a planned manner. Various modules making up a software are almost never integrated in one shot.
Integration of various modules are normally carried out incrementally over a number of steps.
During each integration step, previously planned modules are added to the partially integrated system and the resultant system is tested.
Finally, after all the modules have been successfully integrated and tested, the full working system is obtained.
System testing is carried out on this fully working system.
Integration testing is carried out to verify that the interfaces among different units are working satisfactorily.
The goal of system testing is to ensure that the developed system conforms to the requirements that have been laid out in the SRS document.
System testing usually consists of three different kinds of testing activities
Alpha Testing:
Alpha testing is the system testing performed by the development team.
Beta testing:
This is the system testing performed by a friendly set of customers.
Acceptance testing:
After the software has been delivered, the customer performs system testing to determine whether to accept the delivered software or to reject it.
Maintenance
The total effort spent on maintenance of a typical software during its operation phase is much more than that required for developing the software itself.
Many studies carried out in the past confirm this and indicate that the ratio of relative effort of developing a typical software product and the total effort spent on its maintenance is roughly 40:60.
Maintenance is required in the following three types of situations:
Corrective maintenance:
This type of maintenance is carried out to correct errors that were not discovered during the product development phase.
Perfective maintenance:
This type of maintenance is carried out to improve the performance of the system, or to enhance the functionalities of the system based on customer’s requests.
Adaptive maintenance:
Adaptive maintenance is usually required for porting the software to work in a new environment.
For example, porting may be required to get the software to work on a new computer platform or with a new operating system.
Shortcomings of the classical waterfall model
No feedback paths:
In the classical waterfall model, the evolution of a software from one phase to the next is analogous to a waterfall.
Just as water in a waterfall after having flowed down cannot flow back, once a phase is complete, the activities carried out in it and any artifacts produced in this phase are considered to be final and are closed for any rework.
This requires that all activities during a phase are flawlessly carried out. The classical waterfall model is idealistic in the sense that it assumes that no error is ever committed by the developers during any of the life cycle phase and therefore, incorporates no mechanism for error correction.
Difficult to accommodate change requests:
This model assumes that all customer requirements can be completely and correctly defined at the beginning of the project. There is much emphasis on creating an unambiguous and complete set of requirements. But, it is hard to achieve this even in ideal project scenarios. The customers’ requirements usually keep on changing with time. But, in this model it becomes difficult to accommodate any requirement change requests made by the customer after the requirements specification phase is complete, and this often becomes a source of customer discontent.
Inefficient error corrections:
This model defers integration of code and testing tasks until it is very late when the problems are harder to resolve.
No overlapping of phases:
This model recommends that the phases be carried out sequentially—new phase can start only after the previous one completes.
Happy
0 %
Sad
0 %
Excited
0 %
Sleepy
0 %
Angry
0 %
Surprise
0 %
0
0
Average Rating