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.

Escape the waterfall: Agile for aerospace

“…The 1987 report [6] of this committee vilified the waterfall model codified in DOD-STD-2167: "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.…”

“…Chenu noted that while DO-178B allows for iterative and incremental development, traditionally a V model of development 6.D. [3][4][5][6] has been used that is not very Agile-like. He noted that his team was able to adapt XP practices for safety, such as writing documents incrementally so that they could be shipped after each iteration.…”

“…This 6.D. [3][4][5][6][7][8][9][10][11][12] pairing provides a high return in that the novice engineers are able to learn the system and the process while still providing value to the program. The experienced engineers often gained from these pairings as well because they were forced to answer questions that they might not have considered before.…”

Nuclear power plant diagnostics in APL

“…The current efforts in the development of the APL technology of NPP diagnostic systems prototyping are concentrated on building an expert system to support the design process. We are using the ideas of Rudd and Brown [9] in our further development of prototyping technology.…”