Article Preview
TopIntroduction
RAD is a linear sequential software development process model that emphasises extremely short development cycles (Pressman, 1997) and was conceived as a means of reducing time-to-market. RAD was trumpeted as the way to reduce software development time which, according to Reilley (1995) would cost less than traditional methods and which would deliver higher quality products that better met business requirements.
The promise of low-cost and high-quality would require the support of radically new tools and precepts in order to meet these aspirations. Again, Reilley (1995) has stated that these tools and techniques would include Developers creating requirement diagrams using automated tools (rather than by hand), Group interviews (in which customers and developers discuss application design together - replaced one-to-one interviews) and the introduction of Time-Boxing to set time limits on tasks.
Martin (1991) discusses how software practitioners have dramatically reduced development times of IS dramatically whilst maintaining, or in some cases improving, quality. The key to this success has not only been the implementation tool used. Correct application of the technique to the correct projects (or parts thereof) together with an appreciation of the less visible, although equally important, management style displayed is of vital importance.
TopRequirements Specification
The requirements specification process comprises a high level of user involvement which should reduce the risk of misunderstanding the specification. Additionally, interactivity at this level acknowledges the efficacy of the group process whilst reducing the risk of an unusable specification.
The user of a system or product may not necessarily be a specialist in the field of software engineering; as a result, familiarity (or unfamiliarity) of technical concepts may lead to a “comprehension gap”. One consequence of this may be a final specification which does not accurately reflect the true nature of the users’ requirements. RAD attempts to alleviate this danger by the inclusion of the user in the development team and process. No attempt should be made to unduly progress a specification to the next iteration or stage as each iteration should attempt to produce some form of usable system.
Cost Analysis
Traditional process decomposition techniques or function point analysis can be used to estimate the likely duration of a RAD project in the same way as they can for a traditional project. Due regard should be paid to:
- •
The production of time estimates from these breakdowns
- •
The RAD tools’ ability to reduce the number of lines of code required to implement each function point or process block
- •
The likely benefits of future productivity.
Resources should be optimised (for effective use of manpower) and so planning the duration of tasks and the division of tasks into smaller “subtasks” is a major element of the project planning process. RAD projects use relatively small teams (compared with traditional IS projects) who working on subtasks concurrently Reilley (1995), delivering components on an incremental basis. Planning the delivery of these installments would create pivotal milestones for the project upon which project progress can be measured or monitored.