Waterfall Model or Linear Sequential Model

In the Waterfall Model, a few phases have been identified in a software lifecycle process, which occur sequentially. Each phase is executed once. The model recognizes feedback loop between phases and it insists on confining the feedback loops to successive phases only, so as to minimize the expensive rework involved in feedback across many phases.

This model is best suited when a set of high quality, stable user requirements exists. Its limitations stem from the fact that it requires complete knowledge of all requirements at early stages of the life cycle, commitment of all financial and other resources up front (with a low visibility until the software is ready) and lack of flexibility to accept change to requirements. The Waterfall Model is inappropriate for development situations where these factors may pose problems.

RAD Model

Rapid Application Development (RAD) is a linear sequential software development process model that emphasizes an extremely short development cycle. The RAD model is a “high-speed” adaptation of the Waterfall Model in which rapid development is achieved by using a component based construction approach using “RAD tools”. If requirements are well understood and the project scope is limited, the RAD process enables a development team to create a “fully functional system” within very short time periods.

The time constraints imposed on a RAD project demand scalable scope. If a business application can be modularized in a way that enables each major function to be completed in say, less than 3 months, it is a candidate for RAD. Each major function can be addressed by a separate RAD team and then integrated to form a whole application.

Not all types of applications are suitable for RAD. If a system cannot be properly modularized, building the components necessary for RAD will be problematic. If high performance is an issue, or if the technical risks are high (may be arising out of use of new technology), or if the extent of interoperability of the proposed application with existing programs is significant, RAD is not suitable as a life cycle model.

Incremental Model

The Incremental Model combines the elements of Waterfall Model with the philosophy of an iterative approach. As illustrated below, it applies the linear sequences in the Waterfall Model in a staggered manner as the calendar time progresses. Each linear sequence produces an incremental deliverable of the software. The first increment is often a core software where the basic requirements are addressed, but many supplementary features remain undelivered. The core software is reviewed in detail by the customer and may be even used. As a result of the detailed review and/or use of the core software a plan is developed for the next increment. The plan addresses the modification of the core software to better meet the needs of the customer and delivery of the additional features and functionality. This process is repeated following the delivery of each increment until the complete software is produced.

This has a number of distinct advantages over the traditional sequential development model. This is the best choice for projects that have high technical risks, and objective is achieved by breaking down the project organization and systems construction into manageable sub-projects. The advantage of this model is that the development team learns of customer’s expectations in gradual steps and gets the opportunity to implement changes in the same incremental steps. It is particularly useful when staffing is unavailable for a complete implementation of the full system by the project deadline. The core software can be implemented with fewer staff that can be put to use by the user. If the core software is well received by the user, additional staff is added to work on the next increment(s).

Prototyping Model

In Prototyping Model the software requirements are developed in a series of iterations. The life cycle starts with requirement analysis. The analysts discuss the overall system objectives with the customer, identify whatever requirements are known, and outline areas where further definition is needed. Based on this knowledge a quick “Conceptual or Gross Design” is made which focuses on a representation of those aspects of the software that will be visible to the customer / user. On basis of the Gross Design a prototype is built which serve to obtain user feedback and refine the requirements of the software to be produced. Iteration occurs as the prototype is tuned to satisfy the needs of the customer and thus facilitate a better understanding of the customer requirements and thereby, modification, and refinement of the system requirements.

Spiral Model

One of the better alternatives to the above models is a non-linear life cycle model known as the Spiral Model. This couples the iterative nature of the Prototyping Model with the controlled and systematic approach of the Waterfall Model. This model does not necessitate either a full knowledge of user requirements, or a full commitment of funds for the entire development work at the beginning of the project. Feedback between phases is a natural activity in this life cycle model.

Like the Waterfall Model, the Spiral Model starts out with a set of objectives that specify quality and costs associated with the reaching of goals. In this technique, the developer creates a model of the software that must be built. The model may be

• a paper prototype or PC-based model that depicts man-machine interaction in a form that enables the user to understand how such interaction will occur. Or
• a working prototype that implements some subsets of the functions required of the desired software.