Toward a common prototyping language

Abstract

Several years ago the U.S. Department of Defense created its Defense Science Board Task Force on Military Software, chaired by Dr. Frederick Brooks, to provide recommendations on how best to solve the problem of escalating military software acquisition costs. The final report (reference 2) of this task force was completed in September 1987, and was widely distributed. Among its several major conclusions are the following: DoD Directive 5000.29 and STD 2167 codify the best 1975 thinking about software, including a so-called 'waterfall' model calling for formal specification, then request for bids, then contracting, delivery, installation, and maintenance. In the decade since the waterfall model was developed, our discipline has come to recognize that setting the requirements is the most difficult and crucial part of the software building process, and one that requires iteration between the designers and users. In best modern practice, the early specification is embodied in a prototype, which the intended users can themselves drive in order to see the consequences of their imaginings. Then, as the design effort begins to yield data on the cost and schedule consequences of particular specifications, the designers and the users revise the specifications. Directive 5000.29 not only does not encourage this best modern practice, it essentially forbids it. We recommend that it be revised immediately to mandate and facilitate early prototyping before the baseline specifications are established. DoD STD-2167 likewise needs a radical overhaul to reflect best modern practice. Draft DoD STD 2167A is a step, but it does not go nearly far enough. As drafted, it continues to reinforce exactly the document-driven, specify-then-build approach that lies at the heart of so many DoD software problems.