Rapid application Development (RAD) Technique
June 1, 2011
General RAD Concepts
Background
RAD refers to development lifecycle designed to give much faster development and high quality results than the traditional lifecycle.
It is designed to take maximum advantage of powerful development tools that have evolved in record years.
Need to apply RAD Technique
-Speeding up of development process which is very important in today’s business environment.
-To speedily create and amend info systems in organization in order to support the continuous changing business environment
NB: There is need to harness the characteristics of RAD so that most flexible and quality systems are delivered in the shortest time scale possible.
Characteristics of RAD
-Use of evolutionary prototyping techniques operating in an environment of high delivery time scales.
-To focus upon the identification of important users and involving them in workshops at early stages of development.
-Obtaining commitment from the business users
-The use of CASE integrated development environment
Concepts of RAD
RAD was traditionally viewed as quick fix approach but not a technique to deliver quality systems.
It was seen as a way of setting up a system quickly using a 4GL tools and DBMS products without the quality controls associated with other development projects.
The two common approaches used are:
1) The work of James Martin (1991)
Context of Information Engineering
2) Dynamic System Development Method (DSDM)
Is a framework and standards of RAD formed by a consortium of UK companies in January 1994.
Phases of RAD
a) Requirement Analysis
This concerns the definition of requirements. The techniques used in this phase are:
i. Joint Requirements Planning (JRP)
ii. Joint Application Development (JAD)
Both of these techniques are based on workshops or structured meetings.
i. Joint Requirements Planning (JRP)
The role of JRP is to identify the high level management requirements of the system at a strategic level. The participants are senior managers who have visions and understanding of the overall objective of the system and how it can contribute to the goals and strategies of the organization.
The workshops may be used to help determine those goals when they are not well understood.
JRP is a creative workshop that helps to:
Identify and create commitment to the goals of the system .
Identify priorities
Eliminate unnecessary functions
The difference between JRP & JAD is that different people are involved.
In JRP the participants need to have a contribution of overall business knowledge and specific knowledge about the proposed system with its requirements.
They also need to have the necessary authority and seniority to be able to make decisions and commitments.
It is suggested that if the right people are not available without referring to their seniors negates the RAD objectives which is to get requirements identified agreed in the shortest time possible.
b) User design
The main technique used in this phase is JAD in reality, user design is both analysis and design. Thus the JRP workshops may be combined with JAD in situations where the overall requirements are well established.
Normally, however JAD would follow on from JRP
c) Construction Phase
The construction phase in RAD concerns taking of the user design through detailed design and code generation.This phase is carried out by the IS professionals using CASE tools.
The construction highly depends on the uses of info engineering based case tools and prototyping.
The prototype are reviewed by the key users for approval where they are not approved, the requested changes are effected through series of interaction which are achieved quickly and testing enabled by use of CASE tools and prototyping.
Construction is performed by small teams of 3 to 4 experts in the use of CASE tools. The teams are kept small so as to reduce the number of interfaces and interactions between people in the teams.
They are required to work quickly, making maximum possible use of re-usable designs already in existence.
Large teams of developers would require large communication network and a number of communication resulting in low productivity as in the traditional development.
There should be a developer for each part of the system so as to reduce the number of potential interactions with other developers.
Using this approach the system can be viewed as quickly as 4-6 weeks and progressively refined and integrated with other aspects developed by other team members.
Once the detailed designs are agreed upon the code generated using the CASE tool and then the system is tested and approved.
All associated documentation is then produced and database optimization is then performed.
d) Cut-over:
This is the final phase that involves testing and the use of realistic data in operational situations. The users are trained on the system. The organization changes.
Implied by the system is implemented. The cut-over is finally effected by running the old and the new system in particular until the new system has proved itself. The old system is then phased out.
Comments
Got something to say?
You must be logged in to post a comment.
