Waterfall model in software engineering

If you want to know about waterfall and iterative model.Then read this blog.Different phases of waterfall model are covered in this.

Software development processes are complex and challenging to understand. One of the most popular software development processes is the waterfall model. Developed in the 1950s, the waterfall model has become outdated as it does not consider modern software engineering practices. However, many organizations and project teams still use a waterfall model for creating software. We will define and explain a waterfall model in software development and how it compares to modern software development processes.

Table of contents

• What is Waterfall Model
• Phases of waterfall model
• Iterative waterfall model
• Advantages of waterfall model
• Disadvantages of waterfall model
• Conclusion

What is Waterfall Model?

A waterfall model is a planning process used to develop a product or component from start to finish. It is made up of five steps or phases that represent significant stages of creating a project. The steps are feasibility study,requirement analysis,design, programming, testing, and maintenance. 

Phases of waterfall model

1. Feasibility study of a project

Checking the scope of project on all aspects like technical and financial.

The first stage in the planning process is a feasibility study. A feasibility study is a detailed analysis of the project which shows the proposed cost, duration, and benefits of the project against various alternatives. A feasibility study should cover all aspects of a project – from planning to implementation and should not be limited to the scope of work.

 

Also explore: What Does A Software Engineer Do? Roles, Responsibilities, and Skills

2. Requirements analysis and specification of the project

A requirement set is simply a list of items the project team needs to meet.

A requirement set is simply a list of items the project team needs to meet. This phase aims to understand and properly document the customer’s exact requirements. Both customers and software developers work together to document all functional, performance, and interface requirements of the software. It describes the “what” of the system, not the “how .”This phase produces a large document called a Software Requirement Specification (SRS) document. This document contains detailed descriptions of what the system does in common language. 

Key Points 

1. Collect all requirements.  

2. Brainstorm and walkthrough to understand customer requirements.  

3. Run a proof of concept to see if your requirements are testable.

 

3. System Design of a project

Designing/outline of project.

A design specification is created to outline technical design requirements such as programming languages, hardware, data sources, architecture, and services. This phase aims to convert the requirements captured in the SRS into a suitable format that can be further coded in a programming language. It defines the overall software architecture and high-level and detailed design. All this is documented as a Software Design Document (SDD).

Key Points

 1. According to your requirements, a design will be created.

 2. Gather hardware/software requirements. 

 3. Document your design

 

4. Implementation/coding of the project

Coding of software/projects by the developers using different programming languages.

The development team is working on coding the project. 

They get the design documents/artifacts and verify that the solution follows the design finalized by the architect. Code generation can be done with less effort if the design is detailed and systematic. 

Developers must follow the coding guidelines and programming tools for this. Various high-level programming languages ​​such as C, C++, Pascal, Java, and PHP are used for coding. The programming language is chosen according to the type of software to be developed.  

 If the application is a banking application and security is a top priority in our requirements, some security checks and audit logging features will be implemented.

Key Points

1. Write the program/code according to the design  

2. Integrate the code for the next phase. 

3. Unit testing the code

 

5. Quality of assurance

The quality assurance team ensures the quality of the project.

Another essential type of assurance is quality control. This is done to ensure that the implemented systems and procedures are suitable for the task at hand. Periods of non-performance, breakdowns, and other corrective actions are all areas with potential for project integrity. Role-based assurance is one type of quality control.

 

6. Deployment of system

The team builds and installs the application on servers procured for the banking application. Once the product is tested and ready for use, it will be officially released in the relevant market. Product delivery may be phased according to the organization’s business strategy. Products are initially released in limited segments and tested in real business environments (UAT User Acceptance Testing). 

Based on the feedback, the product can be released to the target market segment as-is or with suggested improvements. After the product launch, the existing customer base will be maintained. 

Deployment activities include installing operating systems on servers, installing security patches, hardening servers, installing web and application servers, and installing databases.

Key Points

1. Make sure your environment is active 

2. Verify that the exit criteria for the test are met. 

3. Deploy your application to the appropriate environment.  

4. After deploying your application, run a sanity check on your environment to ensure that your application is not broken.

 

7. Testing

Every project is first tested before being given to the client.

There is a test team that tests the entire application and identifies any flaws in the application. The developer and the test team fix these bugs. 

Testers with banking expertise are hired to test the application from a business perspective. 

In the same way, the security testing team is responsible for the security testing of banking applications.

Key Points

1. Write the program/code according to the design  

2. Integrate the code for the next phase. 

3. Unit testing the code(module-wise testing)

 

8. Maintenance of project

Ensuring proper working of project/software after delivering it to customer.

This includes operating the software, importing data, correcting errors, and performing other tasks determining the project duration. The second is performance maintenance, which includes adjusting how the software runs to ensure it produces the expected performance.

 

Iterative waterfall Model

It’s pretty much the same as the traditional waterfall model But is a modified version of the classical waterfall model. The main change is that an iterative waterfall model provides a feedback path from each stage to the previous stage.  

For example, if testers find some design mistake, they can ask the design team to correct the design, or if bugs are not resolved during the maintenance phase, then the testing team will be asked to rework it. 

The feedback paths introduced by the iterative waterfall model are shown in the figure below. 

These feedback paths allow programmers to correct mistakes made at a particular stage if an error is detected later. A feedback path allows you to reprocess the stage where the error occurred and propagate those changes to later stages. 

Note: There is no feedback on the feasibility stage. That means once a project is started, there is no feedback path (feasibility study) to the stage because the project cannot be easily abandoned. 

 It’s good to catch your mistakes at the same stage you made them. Reduce the effort and time required to fix errors.

Advantages of classical waterfall model

• Detailed documentation occurs at all stages of the software development cycle.
• The project is fully dependent on the project team, with minimal customer intervention.
• When everyone defines project requirements at each step, the team can more accurately estimate time, labor, and costs for each task.
• Each phase provides a well-defined starting point and conclusion for the team to follow. This makes it easier for executives to manage the progress of each step and make sure everything is going as expected.

Disadvantages of classical waterfall model

• No phase overlapping. This means only the second phase can start after working on first phase. For example, the implementation phase can start after completing the designing phase. 
• Documentation by developers and testers takes a lot of time Valuable customer feedback cannot be included in the ongoing development stage.
• If you need to create a pivot after completing part or most of a project, you will have to go back to the beginning of the process and start over with new information.
• The waterfall model does not work well for big projects because it struggles to manage size and scope well.

Conclusion

The waterfall model is known to be inaccurate because it ignores many factors during its implementation process. First, there are many unknown factors involved in developing software; hence, a detailed specification can’t cover all possibilities. Lastly, there are risks associated with each stage of development— implementing the design can introduce bugs or create other problems that must be fixed later on in development. By ignoring these factors during implementation, project managers using the waterfall model produce projects that run late and cost too much money— resulting in an inaccurate representation of how software development actually happens.If you liked this article then hit the like button and ahre with your friends.