Software development is teamwork carried out by various skilled professionals in the software development company.
The software development life cycle (SDLC) implies the series of steps or phases that must be followed to successfully develop software that meets all client requirements.
It is a process that leads to the production of high-quality software with minimal cost and maximum efficiency.
SDLC comprises various models which can be applied in order to arrive at a final software product. These models include the waterfall model, agile model, incremental model, v-model, spiral model, and Big bang model. In this tutorial, we would be focusing on the waterfall model.
The Waterfall Model
The waterfall is one of the oldest models which originated in the manufacturing and construction industry. It is also referred to as a traditional model or basic model or linear-sequential life cycle model. It is easy to use and understand.
In the waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in phases.
In the waterfall model, the software development process is demonstrated in a linear sequence of flow. This implies that any phase in the development process can only begin when the previous phase is completed. In the waterfall model, the outcome of a preceding step acts as the input of the next step or phase in sequential order.
The waterfall approach:
The waterfall model of software development can be divided into six unique phases. These six phases include:
- Requirement analysis:
This is the first step in the waterfall approach where you get all the requirements for the software from the client by interviewing them and asking them questions to understand their needs. You find out what they are trying to build and the purpose of it, you identify the stakeholders who are going to be involved, you come up with your scope, you do your feasibility study to ensure that you’re on the right track. All the planning that needs to happen before you do anything is done in this first phase. Also, this is the phase where you clarify any ambiguity that may happen between the client’s expectation and what you understood. This is where you communicate with your client and understand what the problem is to be able to come up with the best solution.
- System design:
Once the needed analysis is completed, the subsequent phase is to properly define and document the software requirements and ensure that they are approved by the client. This is usually done via SRS (software requirement specification) which consists of all the product requirements to be designed and developed during the project’s life cycle. More than one product design is proposed and documented in a design document specification (DDS) based on the requirements of the client and the best one is selected. In this phase, the software architect will draw the blueprint of the software which contains all the components which will be implemented. All the requirements are translated into technical details. This finally results in two important documents: low-level design and high-level design.
- Implementation and coding:
This phase involves taking your requirements and designs made and then transferring them into actionable codes. Here you select the appropriate programming language to use. You write the code for every aspect of the documented design.
You will need to carry out various tests on the software product including unit testing, progression testing, functional and non-functional testing. Testing is done so as to ensure that the software is reliable and that it doesn’t act in any way that is unexpected. In this stage, the software product errors are detected, fixed, and tested again until the product obtains maximum quality and standard defined in the SRS.
Once the product is tested and ready for operation, you deploy it to various types of environments. Most of the time, you’ll be deploying to the production environment. This is where your end-users are located, where people are actually using your software for their businesses. You can also deploy in a demo environment
You have to make sure that the software is up to date, that it’s current, it stays relevant. Ensure that it works well on various devices including mobile devices and computers. Also, ensure that it’s suitable on different browsers. Improve on new client’s requirements where necessary.
Merits of waterfall models
Using the waterfall model during the Software Development Life Cycle (SDLC) model has some unique benefits. Apart from its simple and ideal approach for software development; it is also regarded as the basic foundation for building other SDLC models. The advantages of the waterfall model are itemized below:
- There is no overlapping when using this model, this also means that each phase is first processed and must have ended before the next phase begins.
- The usage of the model is simple and easy to manipulate.
- The model is rigid. This means that it can be managed easily because each phase has a review process and a specific end product.
- Proper documentation of the actions, processes, and results in each phase.
- The waterfall model has a clearly defined milestone.
- It is easy to obtain good quality in each phase because the entry and exit standards are properly documented.
- It is easy to use the waterfall model for small projects because the requirements are well understood.
- Good software development ethics are reinforced. Examples include the define- before -design habit, and also the design- before -code habit.
Demerits of waterfall model
As good as the benefits the waterfall model possesses, it also has some limitations and shortcomings. Basically, it is not used in large and modern projects. The demerits of the waterfall model are:
- Due to the high-risk factor and uncertainty that larger and complex projects possess, the waterfall model is not appropriate.
- Since there is no initial prototype that the waterfall model follows, there is late delivery of the final project.
- A waterfall model naturally assumes that no error is made during any of the phases. Therefore, there is no feedback path mechanism that makes way for correcting errors when present.
- The waterfall model also assumes that the customer accurately gives all the requirements at the start of the project, but this is not true because customers’ requirements change consistently as time progresses in the project. The model, therefore, makes it strenuous to accept customer changes after the testing phase.
- It is not suitable for long and currently running projects.
- No working software is produced until towards the end of the life cycle.
- Difficult to have a risk reduction strategy.
Examples of waterfall model
The waterfall model was the major mainstream for software development until the year 2000. In the years before the start of the 21st century, the waterfall model was used in developing enterprise applications which are Supply Chain Management Systems (SCMS), Human Resource Management Systems (HRMS), Point of Sales (POS) Systems used for retail transactions, Customer Relationship Management (CRM) systems and so on. Nowadays, Agile Methodology has taken over the Software development industry. Some notable examples of that waterfall model is preferred are:
- Development of aircraft and military programs through the Department of Defense (DOD). Waterfall models can be used for the stringent protocols and requirements that are required. Also, the requirement and specific contracts are made available and are known well. The waterfall model is deemed to be compatible with the rigorous oversight process and acquisition process as given by the Government.
- A system related to human life whereby a system malfunction could lead to loss of human life. These could lead to the culprits facing a jail sentence. In this scenario, human life is of more importance than the money and time used for the system.
- Other sectors include Healthcare, Space shuttles, Healthcare, Control system for nuclear facilities, and so on.
Criteria for using the waterfall model
There are some important criteria that should be met before considering using the waterfall model. They are listed below:
- The project should be short-term.
- The technology should be well understood.
- The resources should be sufficient coupled with the required expertise.
- The requirements for the project should be clear, well known, and fixed.
- Defining the product should be stable.
Waterfall model vs agile model
In recent times, the Agile model has replaced the waterfall model in Software development; even though other useful models (including the Agile model) have their basis gotten from the waterfall model. There are a few disparities between the waterfall model and the agile model and they are discussed below;
|S/N||Waterfall Model||Agile Model|
|1.||The head of a project hierarchy is the driving force.||The team is the driving force of the project.|
|2.||The planning of a waterfall project is done sequentially with definitive milestones.||The planning of an agile project is done iteratively meaning it can adapt to changes in requirements.|
|3.||Planning for waterfall models is done for longer periods.||Planning for agile periods is generally done in the short term.|
|4.||The roles involved in a waterfall project are high because of several levels of hierarchy.||The team involved in an agile project has a lesser role to play.|
|5.||The success of the project is dependent on the implementation of the given requirements.||The success of the project is based on the client receiving a good business value.|
|6.||Dependency on the final consumers is little especially during the development and intermediate phase.||Dependency on the final consumer is significant throughout the project.|
|7.||The waterfall model is more process-oriented, that is, steps are thoroughly followed during each phase.||The Agile model is more people-oriented.|
The importance of taking the sign-off of the deliverables during each phase cannot be overemphasized when dealing with waterfall models. In recent times, most projects make use of the Agile model; even though the waterfall model can still be used for smaller projects as far as the requirements are well and properly documented.