SDLC – Classical Waterfall Model

The classical waterfall model is elegant and intuitive. However, it is not a practical model because it cannot be used in actual software development projects. Thus, this model can be considered to be a theoretical way of developing software. The classical waterfall model divides the life cycle into the following phases.

• Feasibility Study
• Requirements Analysis and Specification
• Design
• Coding and Unit Testing
• Integration and System Testing
• Maintenance

It is easy to understand but not very practical to cater to complex projects. The phase between the feasibility study and testing is called the “Development Phase.”

In the development phase, the testing consumes maximum effort. This implies that coding takes less effort as compared to testing. So, hiring good coders will minimize the testing effort. Further, in the entire life cycle phases, the maintenance phase consumes maximum effort. It means just building and handover to the customer is not the end of the software development life cycle.

Important note: Whenever we select a vendor for the software development, we need to also consider maintenance costs for a few years depending upon the uses of the software product.

The most organization usually defines standards on the outputs (deliverables) produced at the end of every phase and every phase’s entry and exit criteria. It is not standardized that all organizations must follow one of the list process models and prescribed methods and tools. Organizations can customize it. So, most organizations issue guidelines and methodologies, and it is called the organization’s software development methodology. The software development organization expects fresh engineers to master the organization’s software development methodology before real development.

Feasibility Study

The main aim of the feasibility study is to determine whether developing the software is financially worthwhile, technically feasible, or not.

Roughly understand what customer wants:

1. Data which would be input into the system
2. The processing needed on these data
3. Output data to be produced by the system
4. Various constraints on the behavior of the system

Activities during the feasibility study

1. Workout an overall understanding of the problem
2. Formulate different solution strategies
3. Examine alternate solution strategies in terms of resource required, cost of development, and development time.
4. Perform a cost/benefit analysis to determine which solution is the best. It may be possible that none of the solutions is feasible due to high cost, resource constraints, and technical reasons.
5. Cost-benefit analysis (CBA) analyzes the following:
   • Development cost: It roughly estimates the entire development cost of the software product.
   • Setup cost: To start any development, various resources like development systems and software are needed. It also depends on the type of software development. For example: suppose we want to make an app for iOS, then we need at least a few apple smartphones and apple desktop systems.
   • Operational costs: The developers, managers, and other supporting staff require tea, coffee, rented building, electricity, etc. There is various kind of operational cost that must be included during the estimation.
6. Identify the value of benefits, and benefits should always be greater than costs (investment of software or product development). The benefits include cost of development + operational + setup + (quantifiable + non-quantifiable profits).
7. Feasibility study learning helps in writing a business case.

Requirements Analysis and Specification

The aim of this phase to understand the exact requirements of the customer and document them properly. It consists of three distinct activities:

• Requirements gathering
• Requirement analysis
• Requirement specification

The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed.

The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the product’s user and from the customer through interviews and discussions. The data collected from such a group of users usually contain several contradictions and ambiguities since each user typically has only a partial and incomplete view of the system. Therefore, it is necessary to identify all ambiguities and contradictions in the requirement and resolve them through further discussions with the customer.

After all the ambiguities, inconsistencies, and incompleteness have been resolved, and the requirements are properly understood, the requirements specification activity can be started. During the activity, the user requirements are systematically organized into a Software Requirements Specification document.

The important components of this document are functional requirements, non-functional requirements, and the goal of the implementation.

Design

The goal of the design phase is to transform the requirements specified in the SRS document into a suitable structure or implemented in some programming language. In technical terms, during the design phase, the software architecture is derived from the SRS document.

There are two commonly used design approaches:

• Traditional approach
• Object-oriented approach

Traditional design approach: It consists of two different activities.

• A structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. A structured design activity follows this.
• During structured design, the results of the structured analysis are transformed into the software design.

To understand this, we need to understand structured analysis and design techniques.

Object-oriented design approach: In this technique, various objects in the problem domain and the solution domain are first identified. The different relationships that exist among these objects are identified. This object structure is further refined to obtain the detailed design.

Coding and Unit Testing

The purpose of the coding phase of software development is to translate the software design into source code. 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 tested. During this phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation, as this is the most efficient way to debug the errors identified at this stage.

Integration and System Testing

Integration of different modules is undertaken once they have been coded and unit tested. During the integration and system testing phase, the modules are integrated in a planned manner. Finally, when all the modules have been successfully integrated and tested, system testing is carried out.

System testing aims to ensure that the developed system conforms to its requirements laid out in the SRS document. System testing usually consists of three different kinds of testing activities:

1. Alpha testing: It is system testing performed by the development team.
2. Beta testing: It is the system testing performed by a friendly set of customers.
3. Acceptance Testing: It is a system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product.

Maintenance

Maintenance of a typical software product requires much more than the effort necessary to develop the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of developing a typical software product to its maintenance effort is roughly in the 40:60 ratios.

Maintenance involves the following four kinds of activities:

1. Corrective errors that were not discovered during the product development phase. This is called corrective maintenance.
2. Improving the system’s implementation and enhancing the system’s functionalities according to the customer’s requirements. This is called perfective maintenance.
3. Porting the software to work in a new environment. This is called adaptive maintenance.
4. Maintenance is regularly performed on the solution to lessen the likelihood of it failing. It is performed while the solution is still working so that it does not break down unexpectedly. This is called Preventive maintenance.

Limitation of Classical waterfall model

The classical waterfall model is idealistic, and it assumes that no defect is introduced during any development activity. However, in practice, defects do get introduced in almost every phase of the life cycle.

Defects usually get detected much later in the life cycle. For example, A design defect might go unnoticed till the coding or testing phase. Once a defect is detected, the phase in which it occurred needs to be reworked. Further, the redo of some of the work done during that and all subsequent phases are expensive and time-consuming. Therefore the classical waterfall life cycle model needs some feedback mechanism.

Reference

1. Fundamentals of Software Engineering Book and NPTEL Video Lectures by Rajib Mall.

 1,247 total views,  1 views today