Like Agile or Kanban, Waterfall refers to the traditional software development life cycle (SDLC) methodologies. The main idea behind it is to break the processes involved in creating software programs into several discrete but interrelated stages and to perform them subsequently one after another. That is why it is called ‘waterfall’, or sometimes the linear-sequential life cycle model.
Waterfall Software Development Explained
Introduced by Winston Royce in 1970, the Waterfall Model became the first process model to organize not only software development but other activities as well. The central point is the sequential flow of activities, where each phase is dependent on the deliverables of the previous one. Consequently, the next step of the SDLC Waterfall journey is carefully planned and begins after the previous one is completed.
A typical Waterfall SDLC structure can be considered as the simplest and less flexible one. Performed in a strict top-down fashion, the progress flows in largely one direction. When it comes to software development, this model includes several phases: requirement analysis, system design, implementation, system testing, release, and maintenance. All of them are cascaded with each other. Let’s take a closer look at each of them:
- Product planning. The first thing that runs Waterfall SDLC is planning. Here, it is necessary to determine the type, purpose, function, and design of a product in the clearest detail. To discuss requirements and achieve the most effective solution, it is recommended to conduct a team brainstorming.
- Technical requirement analysis. Unlike the previous stage, where the primary task was to make plans, this one is about capturing and recording them in product requirement documents. More specifically, it is necessary to determine the technical steps to follow these requirements.
- Specification. This phase is about marking all the specifications of the input and output or the final product.
- Design. The team is expected to decide on and plan the technical approach to develop a product. Besides, it is advisable to emphasize the project's high-level technical details like what programming language will be used, what databases will be involved, and more.
- Coding. After the design stage, it is the built stage, that is nothing but coding the software.
- Software testing. This stage includes various testing techniques and approaches, selected for each type of project separately. The prime goal is to check whether the developed product fulfills the specifications formulated by the client. Typically, this stage includes the integration of unit tests, performing functional and non-functional testing, tracking, and reporting all testing activities.
- Release. At this stage, the team deploys the application in the respective environment and ensures that the test exit criteria are met.
- Product support. After all previous stages were done, it is mandatory to check how the app runs in the respective environment. Maybe there is a need to add changes to code or fix some bugs. In such a way, a new version should be planned.
Software Testing in the Waterfall Model
Among software development activities in SDLC Waterfall, software testing is the main one. During this phase, several testing types are conducted. The most common ones are the unit, system, and acceptance testing. As for the QA techniques, Black Box Approach is the most frequently applied one in the Waterfall Model. It requires no deep knowledge of the internal structure of the application. Issues, found during testing, should be properly logged and reported to the developers’ team.
Other QA activities, which are not explicitly described in the waterfall process, can also be applied between the phases. For instance, part of the criteria for a transition from one phase to another is the quality that usually takes the form of testing. It aims to make sure that specific quality plans or standards have been accomplished or followed, as different forms, reviews, or verifications demonstrate.
This picture illustrates QA activities in the waterfall process.
Such QA activities as inspections and reviews carried out at the transitions from one stage to the next are demonstrated as gates to penetrate. The exception is between testing and release, where the activities are conducted with acceptance testing. Other QA activities are scattered in all phases: the general place of use is shown by the dotted line. It is focused on error averting in the early stages, on error removal during coding and testing, and on defect containment in support.
Fault prevention activities
Fault prevention activities are aimed to avert bugs and errors before they penetrate into a system. Among such activities, there is the verification of technical documentation, specifications, and product design. If documentation is not complete or clear, the software will probably have numerous bugs.
The purpose of error prevention activities is the elimination of software bugs resources. It is an important step that should be performed in the early stages of the software development process because of several considerable reasons. They are:
- conceptual mistakes by programmers or software designers
- lack of knowledge about the domain
- lack of experience with certain development technologies
Defect containment activities
Defect containment is aimed to reduce software costs and increase software quality. These activities imply analyzing at which phase the defect has appeared for the first time and at which it has been detected. It is usually reported as the percentage of defects captured in the stage in which they appeared.
Eventually, failure averting and containment measures, such as fault tolerance and safety assurance, are the center of phases. But their design, planning, and implementation should be carried out during the software development. In other words, these methodologies are similar to adding some tools or references to the product in order to make them fault-tolerant.
Final Thoughts
A distinct disadvantage of the waterfall methodology is testing comes towards the end of the project, leaving no opportunity for backtracking. Once the design stage is reached, QA teams cannot go back and change requirements. As a result, it isn't easy to estimate time and cost for each phase. For minor projects where requirements are well understood, this model may work well. But, it may show its weaknesses concerning flexibility when it comes to larger projects like a product launch. It is worth being prepared for such a turn of events.