AbstractRAD Business CaseRAD Forms: GRAD, CRAD, FRAD, and DRADAn Opportunity Tree for Full-Scale RADFigure 3. The RAD Opportunity TreeMaking RAD Work for Your Project--Extended version of March 1999 IEEE Computer column --B. BoehmMarch 1999USC-CSE-99-512IEEE ComputerMarch 1999, pp. 113-117Making RAD Work for Your Project-- Extended version of March 1999 IEEE Computer column --Barry Boehm, USCMarch 1999AbstractA significant recent trend we have observed among our USC Center for Software Engineering’s industry and government Affiliates is that reducing the schedule of a software development project was becoming considerably more important than reducing its cost. This led to an Affiliates’ Workshop on Rapid Application Development (RAD) to explore its trends and issues. Some of the main things we learned at the workshop were:- There are good business reasons why software development schedule is often more important than cost.- There are various forms of RAD. None are best for all situations. Some are to be avoided in all situations.- For mainstream software development projects, we could construct a RAD Opportunity Tree which helps sort out the best RAD mixed strategy for a given situation.RAD Business CaseThe main business reason for RAD derives from the fact that any investment in software development is done to reap a downstream benefit flow in higher profits, reduced inefficiencies, better public service, etc. Clearly, the sooner the initial operational capability (IOC) is ready, the sooner you can enjoy the benefit flow. Three additional features heighten the business justification (see Figure 1):- IOC’s earlier in a market window will capture more market share, revenues, and profits.- Earlier revenues and profits are paid in less-devalued dollars.- Ever decreasing technology half-lives reduce the time window within which the benefits, revenues, and profits can be realized.Thus, investing in RAD strategies has strong business value, even in the conservative care in which they increase development cost (generally, they don’t).RAD Forms: GRAD, CRAD, FRAD, and DRADThere are a number of RAD forms in which to invest. Some are best for some situations, and not for others: Generator RAD (GRAD), Composition RAD (CRAD), and Full-System RAD (FRAD). The most frequently used form on ambitious systems is not recommended in any situation: Dumb RAD (DRAD).Generator RAD involves the use of very high level languages such as spreadsheets, business fourth generation languages such as IDEAL or Focus, or other domain-specific languages for such domains as finance, industrial process control, or equipment testing. Portions of these domains are sufficiently bounded and mature that you can simply use the language to state what information processing capability you want, and the generator assembles, integrates, and executes the pre-written components necessary to provide you with the capability. With GRAD, individual users with relatively little programming expertise can generate an application in a few hours to days that would have taken several programmers several months to produce 20 years ago.The main problem with GRAD is scalability, as the generators often buy ease of expression and assembly at the cost of efficiency. This is not a problem for small applications, but has led to major disasters for large systems. For example, the New Jersey Department of Motor Vehicles’ registration system was written in IDEAL to meet a rapid schedule, but was so slow that at one point over a million New Jersey vehicles were driving around with unprocessed license renewals [1].Composition RAD (CRAD) involves the use of small “tiger teams” to rapidly assemble small to medium-large systems based on large components (networking packages, GUI builders, database management systems, distributed middleware) and applications-domain class libraries. Typically, a 3-5 person tiger team can compose an Figure 1. Net Value (Benefits-Costs) of RAD InvestmentsNetValueAggressiveRADTimeTraditionalDevelopmentTechnologyHalf-LifeMarketWindowBasicSpeedupsIOCapplication in 3-5 months that would take a team of 15-20 programmers a year or two to do using traditional methods.CRAD is more scalable than GRAD, but can still have serious scalability problems on large systems. A recent example was the London Ambulance System [2], which used Visual Basic for rapid composition. The system went live on a Monday morning, and was so backed up by Tuesday afternoon that it was shut down. After about a week of attempted performance improvements, it was abandoned forever.Another frequent problem to beware of is that a number of independently-developed GRAD and CRAD systems will have difficulty interoperating with each other and with the rest of your applications, with incompatible class libraries, GUI’s, and infrastructure. The best remedy for this problem is to develop an enterprise architecture of standard inter-application interfaces; common data and class definitions; GUI guidelines; and preferred componentry where necessary.Some treatments of RAD confine its use to GRAD and CRAD approaches. But for larger systems not well suited to GRAD and CRAD, there are a number of effective techniques for reducing cycle time. These Full-Scale RAD (FRAD) techniques are discussed in more detail below.Avoiding Dumb RAD (DRAD)Before discussing FRAD techniques, let us dispose of the major RAD form to be avoided: Dumb RAD (DRAD). This form is most frequently encountered when a decision-maker sets an arbitrarily short deadline for the completion of a software project, without having done any analysis of its feasibility. This can happen for political reasons (“It’s got to be running before the next election”); early indecisiveness (“We spent 15 months getting approvals from the lawyers, planning committees, and standards people, and there are only 9 months left to do the job”); alarmist fears of closing market windows; or pure optimism about your organization’s technical capabilities.The usual result, as documented in numerous additional failed-RAD projects suchas Bank of America’s Master Net, the London Stock Exchange, the American Airlines consortium’s CONFIRM system, and the Denver Airport baggage system [1,2], is that Dumb RAD projects quickly turn into Disaster RAD or Death-march RAD projects.The best way to deal with the threat of a DRAD project is to turn it into a SAIV (schedule as independent variable)