Rad Realities
Total Page：16
File Type：pdf, Size：1020Kb
Software Engineering RAD REALITIES: BEYOND THE HYPE TO HOW RAD REALLY WORKS Building what the customer needs now and delivering it quickly is the new rallying cry for software development by Ellen Gottesdiener The volatile nature of business in the requires a small team of highly skilled individuals (in 1990s along with (hi: emergence of cluding customers) to work together using tools ihat newer technologies such us client/serv accelerate the testing, prototyping and construction ar er, object-oriented (OOl technologies, tifacts of the software product. It should be noted, and ;tn ever growing list of application however, that there can be exeptions to the small team development tools has made rapid ap size, particularly when dramatically new technologies plication development (RAD] a buzzword that falls off the lips of almost every i/S manager and developer. RAD Incremental Delivery RAD has been described as a tool, a methodology and an attitude. It is associated with prototyping and tech niques such as joint application design (JAD), which Chunk 1 require customer involvement and commitment. It is also feared as potentially a source of law-quality appli cations thai do noi scale up or that cannot sustain the Time; Tr.nlilinri.il Product Delivery demands of ongoing maintenance. The questions beg to be asked: "Is RAD just an other IAS fad'.' How might this approach to application Chunk I Chink 2 Chunk I Chunk 2 development change your life as a project manager or developer? What can the roots of RAD reveal to us Chunk 2 Chunk 2 Chunk 3 about the essence of this 10-year old approach? Can it live up to the pervasive marketing campaigns of tools vendors? Whal must be done to succeed with a RAD Time: RAD lncrenienf.il Product Delivery approach?" Source; E{tG CniiMilunj[ Fig. DEFINING RAD RAD products evolve based on continual customer feedback and RAD is an integrated set of techniques, guidelines .ire deployed in increments over lime. and tools that facilitate deploying a customer's soft ware needs within a short period of lime. This prede fined lime frame is called a "timebox." The software and techniques are employed. (See "Cigna Develops product does not "pop out" at the end of the develop One-Year Health Benefit System," page 35.) ment cycle, but instead evolves during the RAD devel opment process based on continued customer feed I'LATFORM INDEPENDENCE back. In addition, the whole software product is not RAD techniques and tools are platform indepen delivered at once, but is delivered in pieces by order of dent. RAD is not an excuse for "hacking" out software. business importance. In this way, the product is de For the PC developer applying RAD. more discipline ployed in increments over time. (See Fig. I.) is needed. For the mainframe developer applying Bach Increment, or "chunk" of the application RAD. more flexibility is needed. The key is striking typically lakes three to nine months. The RAD process the right balance. The software product development process is very different than traditional application development. [Hen Cotlesdicner ii president oi £HG Consulting, ln<., J Carmel, Ind.- Rather than focusing (in steps, tasks, and interim deliv- bMed facilitation, consulting and (raining firm specializing in helping organizations cri'ale maiile business .mil rechn« si models for information erables, RAD is oriented toward product delivery cycles Systems. She can ho reached via E-mail .u 71201. i I53@t ompuserve.com. defined by an end dale. Thus, the successful delivery ol Application Development Trend\ ■ august 1995 Software Engineering a product is based on the skills and ability of the team lo cessiiy of focusing on the business problem first (See learn about customer requirements as the software prod Fig. 2.1 Other RAD practitioners began by using tools uct is being built. In an evolutionary process, [earning in a mainframe environment while also changing the and adopting 10 the environment is key. By exposing the development methodology. Rob Dixon. a partner with software product lo the environment quickly and by let Tier Corp. of Walnut Creek. Calif., and author of Win ting customers critique, review, and provide feedback ning with CASE, used the IEI; CASE tool from Texas on a prototype, the team can make changes to ibe soft Instruments. Piano, Texas, in a Cobol/DB2 project. Dr. ware to allow for belter adaptation to the future produc Sam Bayer, consultant at Sapiens USA, Inc., Durham, tion environment. The product evolves within the time- N.C., used Sapien's own tools in mainframe RAD pro- box while the team learns. In addition. Hie quality of the jecis. — A detailed accounting of RAD in the main application is dependent upon maintaining a stable frame environment is told in Kerr and Hunter's book "memory" of the product structure. This is accom Inside RAD. a book that credits Shultz for his early plished through the use of models under work ;u DuPont. lying the interface design. Bull's-Eye for RAD Although tools are very critical to the RAD approach, RAD ROOTS the tools alone will not create a RAD emerged not from the PC or stable, scalable software prod client/server world but from the uct. "The tools have taken midrange Digital Equipment Corp. over the tSSfil," said Shultz. VAX environment in which Scott It is critical to look beyond ShllltZ, then a project marketing to the people, manager Bt DuPont, process, and organiza used Cortex's CorVi- tional issues to make sion code generator RAD what its inventor tool in conjunction envisioned it lobe. with new develop ment techniques. ShultZ called it STEPS IN RAD rapid iterative production prototyp The RAD process de ing (Kipp). Kipp involved uniquely fies a linear definition of combined tools, methods and people steps carried out in a se to deliver systems quickly to cus quence. RAD begins by defin tomers. His approach was later ing the desired product in an ini popularized by James Martin's Source: ASAP Systems FifJ. 2 tial planning phase. During 1991 book. Rapid Application planning, a definition of 77je primary focus in RAD should he the Development. the project scope is com business problem, not the technology. Now a senior manager at Ernst pleted along with some &. Young LLP in Dallas and having preliminary data/process participated in over 100 RAD pro analysis, risk assessment jects in his career, Schultz's approach was incorporated and estimating. A timebox is chosen — a fixed period into Ernst & Young LLP's Navigator methodology to for building a fragment, increment or chunk of the ap- form the Accelerated Systems Development (ASD) plicalion. Within lliis timebox, a spiral process occurs route map. ASD. says ShultZ, is essentially the "grand involving prototyping, modeling, architectural design, son of R1PP." Shultz's colleague during Rll'P's early construction and testing. (See Fig. 3.). Each cycle days at DuPont, Bucky Wallace, adapted similar tech within the timebox is completed "multiple times, each niques to the MVS mainframe environment. Working in time bringing the solution to higher levels of sophisti parallel with Sbultz. Wallace formed a technology cation and completion." said Shultz of Ernst & Young. group called Application Systems with Accelerated In some cases, a higher level of analysis may be need Productivity (ASAP) within DuPont. ASAP used main ed to insure proper prioiitizalion of RAD projects. An frame tools with a traditional waterfall methodology. information engineering-like analysis may then pro Starting with the goal of increasing productivity by ten ceed these steps. (See "USA Group Spices up .Scholar fold, Wallace discovered thai even if the code genera ships." page 32.| tion portion of the lifecycle was reduced lo 0%, overall Rob Dixon. Tier Corporation, described conduct savings in lime only came lo 3GS&. "I discovered that ing a one-month business area analysis (BAA) to de you have lo change the way you do things — the tools termine the subsets of application development needs were not enough." said Wallace, now President of AS in the whole business area and divide them into chunks AP Systems Inc., Landenberg. Pa. "Tools don't solve of requirements that can each be fulfilled in four to problems, people solve problems," he added. nine months of development. During this one month BAA, the team creates models to define the business BUSINESS PROBLEMS FIRST context, including data, functional decomposition, and Wallace emphasizes in his RAD approach the ne- perhaps object models with the aid of Case tools. AUGUST Iff.1; ■ Application Development Trends Software Engineering "We lake the most compelling ones customer priorities, assumes continual at a common goal, scope and si/.e. The and do them in the first chunk," said change will occur and imparts lo the development team and customers togeth Dixon. Burly and rapid definition of the team a sense of urgency. er determine the project's timeboxes. Ac project means understanding the busi A timebox is a mechanism to con cording to Highsmith, "The team has to ness problem, assessing the risks, priori trol resources and delivery scope: it pro be able lo juggle features lo meet the lime tizing ihe needs, and defining the incre vides a dramatically different way to that the customers help to decide. The ments in order of development. These manage a project. "The timebox is based customers know that any feature-set early activities have ilie affeel of team- on the belief thai we can do something of planned for the last cycle has the poten building us they focus sharply tial to be deleted if the overall on business needs and product timebox is in jeopardy. Time delivery. It also does much to Timebox for Each "Chunk" boxing doesn't work unless gain and maintain customer in both developers and customers volvement, a key aspect of the understand the need for trade RAD process.