The RAD (Rapid Application Development) model is a high speed version of the waterfall model. The emphasis is on short development cycle. Short development cycle is achieved by using component-based construction. Typical use for RAD development is for information systems. Following are the four phases of RAD:
1. Requirements Planning: The Requirements Planning stage consists of a review of the areas immediately associated with the proposed system. This review produces a broad definition of the system requirements in terms of the functions the system will support. The deliverables from the Requirements Planning stage include an outline system area model (entity and process models) of the area under study, a definition of the system's scope, and a cost justification for the new system.
2. User Design: The User Design stage consists of a detailed analysis of the business activities related to the proposed system. Key users, meeting in workshops, decompose business functions and define entity types associated with the system. They complete the analysis by creating action diagrams defining the interactions between processes and data. Following the analysis, the design of the system is outlined. System procedures are designed, and preliminary layouts of screens are developed. Prototypes of critical procedures are built and reviewed. A plan for implementing the system is prepared.
3. Construction: In the Construction stage, a small team of developers, working directly with users, finalizes the design and builds the system. The software construction process consists of a series of "design-and-build" steps in which the users have the opportunity to fine-tune the requirements and review the resulting software implementation. This stage also includes preparing for the cutover to production. In addition to the tested software, Construction stage deliverables include documentation and instructions necessary to operate the new application, and routines and procedures needed to put the system into operation.
4. Implementation: The implementation stage involves implementing the new system and managing the change from the old system environment to the new one. This may include implementing bridges between existing and new systems, converting data, and training users. User acceptance is the end point of the implementation stage.
An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model. Consider an iterative lifecycle model which consists of repeating the following four phases in sequence: - A Requirements phase, in which the requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements. - A Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design. - An Implementation and Test phase, when the software is coded, integrated and tested. - A Review phase, in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed.
For each cycle of the model, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes referred to as incremental prototyping). Eventually a point will be reached where the requirements are complete and the software can be delivered, or it becomes impossible to enhance the software as required, and a fresh start has to be made. The iterative lifecycle model can be likened to producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution.
The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model. The first three phases of the example iterative model is in fact an abbreviated form of a sequential V or waterfall lifecycle model. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software.
Prototyping has been discussed in the literature as an important approach to early requirements validation. A prototype is an enactable mock-up or model of a software system that enables evaluation of features or functions through user and developer interaction with operational scenarios. Prototyping exposes functional and behavioral aspects of the system as well as implementation considerations, thereby increasing the accuracy of requirements and helping to control their volatility during development. The requirements of a system or a class of systems are gathered in an evolutionary fashion. Requirements knowledge is never complete, but rather evolves over time as new requirements are identified, existing requirements are expanded, and obsolete requirements are discarded.
There are really two broad categories of prototyping approaches: those that involve the creation of a series of fielded prototypes, and those intent on exploring ideas without resorting to field deployment. The former are most commonly referred to as field or evolutionary prototypes, while the latter go by many names, including rapid, concept, throw- away, experimental, and exploratory prototypes. For convenience, we will refer to these broad categories as evolutionary and concept prototypes respectively.
Concept prototyping is a mechanism for achieving validation prior to commitment. Concept prototyping may be used to validate requirements prior to commitment to specific designs. Similarly, concept prototyping may be used to validate potential designs prior to commitment to specific implementations. In this sense, prototyping as a software development paradigm can be seen as tacit acceptance that requirements are not fully known or understood prior to design and implementation. Concept prototyping can be used as a means to explore new requirements and thus assist in the ongoing evolution of requirements.
Viewed from a different perspective, the entire lifecycle of a product can be seen as a series of increasingly detailed evolutionary prototypes. The evolutionary view of the software lifecycle considers the first delivery to be an initial fielded prototype. Subsequent modifications and enhancements result in delivery of further, more mature prototypes. This process continues until eventual product retirement. Adoption of this view eliminates the arbitrary distinction between developers and maintainers resulting in an important shift in mindset affecting strategies for cost estimation, development approach, and product acquisition.
SDLC Model: Progressive Development Lifecycle Model
A common problem with software development is that software is needed quickly, but it will take a long time to fully develop. The solution is to form a compromise between time scales and functionality, providing "interim" deliveries of software, with reduced functionality, but serving as a stepping stones towards the fully functional software. It is also possible to use such a stepping stone approach as a means of reducing risk. The usual names given to this approach to software development are progressive development or phased implementation. The corresponding lifecycle model is referred to as a progressive development lifecycle. Within a progressive development lifecycle, each individual phase of development will follow its own software development lifecycle, typically using a V or waterfall model. The actual number of phases will depend upon the development.
Each delivery of software will have to pass acceptance testing to verify the software fulfils the relevant parts of the overall requirements. The testing and integration of each phase will require time and effort. Therefore, there is a point at which an increase in the number of development phases will actually become counter productive, giving an increased cost and time scale, which will have to be weighed carefully against the need for an early solution.
The software produced by an early phase of the model may never actually be used; it may just serve as a prototype. A prototype will take short cuts in order to provide a quick means of validating key requirements and verifying critical areas of design. These short cuts may be in areas such as reduced documentation and testing. When such short cuts are taken, it is essential to plan to discard the prototype and implement the next phase from scratch, because the reduced quality of the prototype will not provide a good foundation for continued development.
A variant of the waterfall model — the V-model — associates each development activity with a test or validation at the same level of abstraction. Each development activity builds a more detailed model of the system than the one before it, and each validation tests a higher abstraction than its predecessor.
