Ads
  

The Rapid Application Development (RAD) Software Development Life Cycle Mod

The Rapid Application Development (RAD) Software Development Life Cycle Mod

The Rapid Application Development (RAD) Software Development Life Cycle Model

In the 1980s, IBM responded to the constricting nature of formal methods, such as the waterfall model, with the use of a rapid application development (RAD) approach. James Martin's book Rapid Application Development introduced this approach to the software community. With RAD, the user is engaged in all phases of the life cycle - not only requirements definition, but design, development, test, and final delivery as well. User involvement is increased from the norm by the use of a development tool or environment that allows product evaluation in all stages of its development. The availability of graphical user interface development tools and code generators made it possible. Tools such as Oracle Designer/2000, Java Jbuilder 3, Linux, Visual C++, Visual Basic 6, SAS, and other applications have entire books dedicated to using them as rapid application tools.

RAD is characterized by the quick turnaround time from requirements definition to completed system. It follows a sequence of evolutionary system integrations or prototypes that are reviewed with the customer, discovering requirements along the way. The development of each integrated delivery is limited to a well-defined period of time, generally about 60 days, called a time-box.

Factors that allow a system to be created in the 60 days of the time-box, without sacrificing quality, contain the use of high-powered development tools, a high reuse factor, and knowledgeable and dedicated resources.

The critical end-user roles shift work from programming and testing to planning and design. More work is created for users at the front of the life cycle, but they are rewarded with a system that is built more rapidly.

A Brief Description of the Phases in the RAD Model

The RAD model, shown in the following figure, represents the phases of its life cycle development process and the user involvement throughout the phases (the curved line).

■  Requirements planning phase - Requirements are gathered using a workshop technique called joint requirements planning (JRP), a structured discussion of the business problems at hand.

■  User description - Joint application design (JAD) is used to harness user involvement; the project team often uses automated tools to capture information from the users during this nontechnical design of the system.

■  Construction phase ("do until done") - This phase combines detailed design, the build (coding and testing), and the release to the customer inside a time-box. It is heavily dependent on the use of code generators, screen generators, and other types of productivity tools.

■  Cutover - This phase includes acceptance testing by the users, installation of the system, and user training.

The Rapid Application Development Model

Strengths of the RAD Model

When applied to a project for which it is well suited, strengths of the RAD model include the following:

■  Cycle time for the full product can be reduced due to the use of powerful development tools.

■  Fewer developers are required because the system is developed by a project team familiar with the problem domain.

■  Quick initial views of the product are possible.

■  Reduced cycle time and improved productivity with fewer people spell lower costs.

■  The time-box approach mitigates cost and schedule risk.

■  It makes effective use of off-the-shelf tools and frameworks.

■  Ongoing customer involvement minimizes the risk of not achieving customer satisfaction and ensures that the system meets the business needs and that the operational utility of the product is sound.

■  Each time-box includes analysis, design, and implementation (phases are separated from activities).

■  Constant integrations isolate problems and encourage customer feedback.

■  The focus moves from documentation to code - what you see is what you get (WYSIWYG).

■  It uses modeling approaches and tools - business modeling (how information flows, where it is generated, by whom, where it goes, how it is processed); data modeling (data objects and attributes and relationships identified); process modeling (data objects transformed); application generation (fourth-generation techniques).

■  It reuses existing program components.

Weaknesses of the RAD Model

Weaknesses of this model when applied to a project for which it is not well suited include the following:

■  If the users cannot be involved consistently throughout the life cycle, the final product will be adversely affected.

■  This model requires highly skilled and well-trained developers in the use of the chosen development tools to achieve the rapid turnaround time.

■  It requires a system that can be properly modularized.

■  It can fail if reusable components are not available.

■  It may be hard to use with legacy systems and many interfaces.

■  It requires developers and customers who are committed to rapid-fire activities in an abbreviated time frame.

■  Blindly applied, no bounds are placed on the cost or completion date of the project.

■  Teams developing commercial projects with RAD can overevolve the product and never ship it.

■  There is a risk of never achieving closure - the project manager must work closely with both the development team and the customer to avoid an infinite loop.

■  An efficient, accelerated development process must be in place for quick response to user feedback.

When to Use the RAD Model

A project manager may feel confident that the RAD model is appropriate when several of the following conditions are met:

■  On systems that may be modularized (component-based construction) and that are scalable;

■  On systems with reasonably well-known requirements;

■  When the end user can be involved throughout the life cycle;

■  When users are willing to become heavily involved in the use of automated tools;

■  On projects requiring short development times, usually about 60 days;

■  On systems that can be time-boxed to deliver functionality in increments;

■  When reusable parts are available through automated software repositories;

■  On systems that are proof-of-concept, noncritical, or small;

■  When cost and schedule are not a critical concern (such as internal tool development);

■  On systems that do not require high performance, especially through tuning interfaces;

■  When technical risks are low;

■  On information systems;

■  When the project team is familiar with the problem domain, skilled in the use of the development tools, and highly motivated.



Tags

life cycle, prototype, project manager
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus