__-

- --

-. -_~.-- -___ -~

________-.

DEVELOPING A RAD, .STAN DARD

A UKconsortium has ganizati& and software-tool identified the special vendors - joined later by a sprinkling of academics - escharacteristics of RAD tablished the Dynamic Systerns Development Method projects andpublished a Consortiutn. Their goal was to develop and evolve confirst version of a tinuously a public-domain development standard. method for rapid application development. Objectives inThethreecritical success eluded publishing a framework for the method, profactors are easyaccess moting it, providing training to endusers, a stable and certification, and so on. The first version of the andskilleddevelopment DSDM proposed standard was published early this pear. team,anda commercial It identifies three factors that are critical for RAD methods: application. the end-user community must
have a committed senior staff that allows developers easy acDON MILLINGTON cessto end users, the developUniversity of Strathclyde, Glasgow ment team must be stable and have well-established skills, and the application area must IENNIFER STAPLETON logicaUK,ltd. be commercial, with flexible initial requirements and a clearly defined user group. In addition to these critical success factors, the proposed standard recommends that RAD projects + make business requirements a priority, as opposed to the quality of the systems operational characteristics; + take a product-based view, which emphasizes what the work produces and which is more flexible than an activiv-based view, which empha_____~~. ..~ ~-~ 54

n early 1994, end-user or-

sizes ho71) the work is done; + use first-class configuration-management procedures, because every change may be reversed; l motivate teams to a~ ~ chiev-e business objectives, rather than simply complete assigned tasks; 4 integrate testing through ~ out the life cycle; + base time and cost estimations on the functionality of i the end products rather than expected development activities; t focus risk assessment on system functionalin; rather ~ than system construction; and ~ + baseline high-level re~ quirements so that they are flexihle enough to be decomposed during development. The DSDM is more concerned with products than ac1 tivities that produce them. The standard thus specifies the products to be achieved, and leaves the techniques to be used and their notations open ~ and flexible. i ~ DEVELOPMENT PROCESS ~ ~ 4s Figure I shows, the DSDM development life cycle , is, divided into fjve phases. ~ Fn-st, developers conduct a study to determine whether or not a particular project meets the criteria for RAD success. They then issue aj&sibility w

1 pm-t and, if the project qualifies, an outline of a development plan. Next, developers conduct a b~s~~z~.~~~tu~y, which defines the business area, lists prioritized functions, and outlines a prototyping plan. In the third phase, developers run afirlzrtional-mol~el itemtion, producing a functional prototype, a statement of nonfunctional requirements, and an implementation strategy. , They then begin a clesi@nzdbdrl itemtiox, producing a tested syst :m that meets all hmctional and nonfunctional requir&nents. In the third and , fourth phases, developers identi@ prototypes, agree to a 1 schedule, create a prototype, and review the prototype. Each aspect of this iterative cycle is time-boxed: a specific time limit is set, with a norm of three iterations for initial investigation, retinement, and consolidation. The DSDM offers guidelines for managing this iterative process. In the fifth and final phase, developers implement the system in the usersenvironment, ~ providing documentation and training. Particular features. Once ~ $e;otn;i;r~D~;~~;;~~; framework, its technical work group proceeded to establish task groups to define differ( ent aspects of DSDM, ~--~____

including project management, personnel, tools and techniques, quality assurance, and software procurement. In each area, work and task groups generated proposals, refined them, and submitted them to the full consortium for approval. To meet the objective of having Version 1 available by January 1995, the groups used time-boxes to limit refinement time. Project management. In general, project management includes estimating resource needs and scheduling and monitoring activities and project resources - particularly staffing. Although Version 1 recommends established methods for life-cycle systems development, it also looks toward the development of techniques and tools that are better suited to RAD and to DSDM in particular. For example, the plan is to build estimating guidelines on the availability of data from the pilot use of Version 1. These guidelines should reflect the time-boxing constraint, which replaces the question How longwill be required to perform activity X? by the question How much of the system can be developed with Y personmonths of resource? Personnel. Because R4D makes unique demands on developers and users, DSDIM recommends the use of small teams (fewer than seven people) that include both users and developers. This makes conmunication easier and encourages the good working relationships critical for success. -Although specific roles are identified for team memhers such as technical manager,

team leader, scribe, visionary, and adviser-user - an individual can fill several roles over the course of development. DSDIM emphasizes the use of a team that carries a project through to its conclusion. Tools and techniques. The intention of DSDLM is not to mandate the use of specific techniques or particular tools. Its emphasis instead is on the products of each stage. It identifies default techniques to support the creation of products and includes both structured and object-oriented methods. Quality assurance. In DSDM, quality assurance is aimed at delivering a system that performs as the business requires. Although these requirements may not be recorded in any formal specification, developers meet this goal by running iterative tests during all stages of the DSD,M development, focusing on the system components most critical for business success.

Fig-m-e 1. Five phases of the DSDM

development life cycle. TFe bold lines indicate tramition amongAphases.- (Fi-am DSDM Consortium; wed with permission.)

sortium membership grew to about 60 organizations, representing a wide range of UK commercial institutions and a few academic institntions with a keen interest in RAD. In response to interest from outside the UK, plans were establish ed for wider participation in the developmen;and use of DSDM. Although meetings to discuss Software procurement. InDSDM and DSDM seminars have been held in the Nethcreasingly, when one company provides software to anotherlands, Scandinavia, and Auser, a legal contract is involved. tralia, the plans to manage the Such contracts usually include Consortium s activities outside a formal specification, w-hich the UK are still tentative. is not required as part of Version 2 of the DSDlM DSDM. Instead, the standard Manual is scheduled to be pubidentities alternative bases for lished in January 1996. In the establishing and monitoring interim, the method is being contractual relationships and used on a trial basis by DSDM provides guidelines for specifConsortium members with exsuch as tensive R4D experience who ic documents, Invitation to Tender and are looking for problems and Vendor Proposal. new ideas. At the same time, ~ working groups are creating material to enhance Version 1 DSDM STATUS in a range of areas, including system maintenance, reuse, and During its first year, conthe relationship of DSDM to

other methods. Several companies have been accredited to run one-day awareness cou,ses and longer practitioner courses on DSDLM. Potential practitioners must have at least six months practical RAD experience and pass an oral examination before certification is granted. Staff members from a few companies, such as British Aimays, FI Group, and MDA Computing, have already been certified. For details on the consortium and the availability of the DSDM manual, contact the DSDM Consortium Secretariat, The Coach House, Church Hill, Kingsnorth, AAshford, Kent TN23 3EG, LK +

twer in the DepartmerIt ofComputw Science. Unizwsi~ojStratbc&k, Glasgow UK.

IEEE

SOFTWARE

55

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.