To RAD or not to RAD
The Rapid Application Development methodology was developed to respond to the need to deliver systems very fast. The RAD approach is not appropriate to all projects - an air traffic control system based on RAD would not instill much confidence. Project scope, size and circumstances all determine the success of a RAD approach. The following categorize indicates suitability for a RAD approach:
PROJECT SCOPE
Suitable for RAD - Focused scope where the business objectives are well defined and narrow.
Unsuitable for RAD - Broad scope where the business objectives are obscure or broad.
PROJECT DATA
Suitable for RAD - Data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data.
Unsuitable for RAD - Complex and voluminous data must be analyzed, designed and created within the scope of the project.
PROJECT DECISIONS
Suitable for RAD - Decisions can be made by a small number of people who are available and preferably co-located.
Unsuitable for RAD - Many people must be involved in the decisions on the project, the decision makers are not available on a timely basis or they are geographically dispersed.
PROJECT TEAM
Suitable for RAD - The project team is small (preferably six people or less).
Unsuitable for RAD - The project team is large or there are multiple teams whose work needs to be coordinated.
PROJECT TECHNICAL ARCHITECTURE
Suitable for RAD - The technical architecture is defined and clear and the key technology components are in place and tested.
Unsuitable for RAD - The technical architecture is unclear and much of the technology will be used for the first time within the project.
PROJECT TECHNICAL REQUIREMENTS
Suitable for RAD - Technical requirements (response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of the technology being used. In fact targeted performance should be less than 70% of the published limits of the technologies.
Unsuitable for RAD - Technical requirements are tight for the equipment to be used.
PRINCIPLES BEHIND THE DEFINITION
A. In certain situations, a usable 80% solution can be produced in 20% of the time that would have been required to produce a total solution.
B. In certain situations, the business requirements for a system can be fully satisfied even if some of its operational requirements are not satisfied.
C. In certain situations, the acceptability of a system can be assessed against the agreed minimum useful set of requirements rather than all requirements.
PROBLEMS ADDRESSED BY RAD
A. With conventional methods, there is a long delay before the customer gets to see any results.
B. With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use.
C. With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered.
WHY USE RAD?
A. BAD REASONS FOR USING RAD
1. to prevent cost overruns (RAD needs a team already disciplined in cost management)
2. to prevent runaway schedules (RAD needs a team already disciplined in time management)
B. GOOD REASONS FOR USING RAD
1. to converge early toward a design acceptable to the customer and feasible for the developers
2. to limit a project's exposure to the forces of change
3. to save development time, possibly at the expense of economy or product quality
WHEN RAD WORKS AND WHEN IT DOESN'T
A. RAD TENDS TO WORK WHEN
1. The application will be run standalone.
2. Major use can be made of preexisting class libraries (APIs).
3. Performance is not critical.
4. Product distribution will be narrow (in-house or vertical market).
5. Project scope (macro-schedule) is constrained.
6. Reliability is not critical.
7. System can be split into several independent modules.
8. The product is aimed at a highly specialized IS (information systems) market.
9. The project has strong micro-schedule constraints (timeboxes).
10. The required technology is more than a year old.
B. RAD TENDS TO FAIL WHEN ...
1. Application must interoperate with existing programs.
2. Few plug-in components are available.
3. Optimal performance is required.
4. Product development can't take advantage of high-end IS tools (e.g., 4GLs).
5. Product distribution will be wide (horizontal or mass market).
6. RAD becomes QADAD (Quick And Dirty Application Development).
7. RAD methods are used to build operating systems (reliability target too high for RAD), computer games (performance target too high for RAD).
8. Technical risks are high due to use of "bleeding" edge technology.
9. The product is mission- or life-critical.
10. The system cannot be modularized (defeats parallelism).
EVALUATION OF RAD
A. ADVANTAGES OF RAD
1. Buying may save money compared to building
2. Deliverables sometimes easier to port (because they make greater use of high-level abstractions, scripts, intermediate code)
3. Development conducted at a higher level of abstraction (because RAD tools operate at that level)
4. Early visibility (because of prototyping)
5. Greater flexibility (because developers can redesign almost at will)
6. Greatly reduced manual coding (because of wizards, code generators, code reuse)
7. Increased user involvement (because they are represented on the team at all times)
8. Possibly fewer defects (because CASE tools may generate much of the code)
9. Possibly reduced cost (because time is money, also because of reuse)
10. Shorter development cycles (because development tilts toward schedule and away from economy and quality)
11. Standardized look and feel (because APIs and other reusable components give a consistent appearance)
B. DISADVANTAGES
1. Buying may not save money compared to building
2. Cost of integrated toolset and hardware to run it
3. Harder to gauge progress (because there are no classic milestones)
4. Less efficient (because code isn't hand crafted)
5. Loss of scientific precision (because no formal methods are used)
6. May accidentally empower a return to the uncontrolled practices of the early days of software development
7. More defects (because of the "code-like-hell" syndrome)
8. Prototype may not scale up, a B-I-G problem
9. Reduced features (because of timeboxing, software reuse)
10. Reliance on third-party components may ...
a. sacrifice needed functionality
b. add unneeded functionality
c. create legal problems
11. Requirements may not converge (because the interests of customers and developers may diverge from one iteration to the next)
12. Standardized look and feel (undistinguished, lackluster appearance)
13. Successful efforts difficult to repeat (no two projects evolve the same way)
14. Unwanted features (through reuse of existing components)
Reference:
http://www.gantthead.com/content/processes/11306.cfm
http://csweb.cs.bgsu.edu/maner/domains/RAD.htm#4
http://software-document.blogspot.com/2010/11/rapid-application-development-quick.html
No comments:
Post a Comment