Waterfall Software Engineering Life Cycle
The waterfall model is a linear and sequential model defined for software engineering life cycle. It is a classic and very popular model that distinctly defines various phases and the goals that each phase has to achieve. It is called a waterfall model because just like a waterfall once the course of life cycle has started there is no looking back.The water will flow from the top to bottom and not reverse its course. In similar fashion in this life cycle the course of software development cannot be reversed.
In waterfall model the approach is very strict and well defined but there is not much of scope for revision. Testing is a phase and does not go hand in hand with development. So, it is not possible to detect defects early in development stage.
Waterfall Software Engineering Life Cycle
The sequences of phases in waterfall model are as follows:
- Requirement and gathering: The requirement of the client is captured and all the necessary documentation is done.
- System Design: based on the requirement gathered the system is designed; this helps in defining in creating the system architecture and also helps in defining the hardware and software requirement of the system.
- Implementation: Based on the system design the coding begins. The program is divided into small independent units that are later integrated to form the complete system. Once the units are ready they are tested as per the defined specifications.
- Integration testing: Once the units have been tested they are integrated into a system and then the entire system is tested in one go for defects.
- Deployment: The system is ready for deployment once the defects uncovered during integration testing have been fixed. After the testing of the integrated system, the defects are fixed and testing is done again to verify is all defects have been closed. The system is now ready for market release and can be deployed in the customer’s environment.
- Maintenance: If any defect or issue arises after the software has been delivered to the customer then patches or new version of the software is released to deal with the problem.
All phases mentioned above are cascaded with each other and one phase can start only after the previous phase has been closed successfully.
Waterfall model can be used in situations where the requirements are well defined and clear, the product is stable and there are enough of resources available for each phase. Waterfall model should be practically implemented only in small and easily manageable projects. It should not be used in projects in which the requirements are at moderate to high risk.
Requirements Specification and Analysis
The development of a software application depends only one thing and that is how well the requirements are captured and documented. This process of identifying and then documenting the requirements for software development is called Requirement specification and analysis.
The client, the management team and the technical support team of the company discuss the requirement of the software in complete detail. These requirements are analyzed, discussed several times and then documented till they are clear and complete.
User Requirement Specification
The requirements can be documented in the format defined by the company such as description in word docs, flow charts, drawings etc. The outcome of the entire exercise is a detailed document that describes what the customer wants. This is necessary so that one is able to understand the requirement of the client properly. In present day we say that defect is anything that is not in line with the requirement of the customer. If we capture the requirement incorrectly we will start the project on the wrong foot.
User Requirement Specification
This document defines what a user wants and what his expectations from the software are. This document gives a clear picture about the business needs of a client. This document is written by the end users. These requirements are tested in the user acceptance testing. This document is not technical in nature. It talks about the business need of the user and forms the foundation for planning the next steps in capturing the requirements and system design.
Software Requirement Specification
The software requirement specification defines how the user wants the software to function. The purpose of this document is as follows:
- The customer and the supplier agree on this requirement. It describes the functionality of the software in complete detail.
- The software design is prepared on the basis of SRS document.
- Clear cut SRS document simplifies development and testing process.
- It helps in scheduling activities and estimating costs.
- SRS serves as a foundation for validation and verification.
Software Requirement Specification
Software Design
Software Design can be of the following types:
- High Level Software Design
- Detailed Software Level Design
Software Design
High Level Software Design
High level software design provides a clear picture about the database design and the function architecture of the system. High level Software design serves as a guide for the development team. Whenever there is any doubt regarding the design flow, the developers refer to High Level Design (HLD) document. In order to create this document it is important that the Software Requirements Specification (SRS) document should be absolutely clear.
Detailed Software Level Design
Detailed software level design or Low Level Design (LLD) involves breaking the high level design in smaller sections and writing down the logic that would serve as program specification. LLD provides detailed information about the system and it cannot be created till the HLD is ready.
Software Design Processes
Software design Processes can be classified as:
- Top Down Design Approach
- Bottom Up Design Approach
Top Down Design Approach
Top-down approach is a very systematic approach in which first the outline of the system is devised without defining details of any subsystem. Once the outline for the system is ready it is time to move down step by step to every subsystem. Every sub system is defined in complete detail till the specification reaches the base elements.
Bottom Up Design Approach
Bottom up design approach is exactly the opposite of top down approach. In this case the first step involves defining the base elements in complete detail and then linking these elements to form various sub systems which are further linked together till the time the complete system is formed. This approach can be compared to planting a tree where at the beginning all that we have in hand in a seed but as we start working on it a tree is formed.
TEST INSTITUTE™
