Compiling APL: the Yorktown APL translator
IBM Journal of Research and Development
APL graphics representation and analysis of space-based observations
APL '86 Proceedings of the international conference on APL
APL '86 Proceedings of the international conference on APL
AI Expert
APL '87 Proceedings of the international conference on APL: APL in transition
Solutions to logic problems in APL2
APL '87 Proceedings of the international conference on APL: APL in transition
The rise of the expert company
The rise of the expert company
Application Development without Programmers
Application Development without Programmers
CATS: computer aided testing of software
APL '91 Proceedings of the international conference on APL '91
Nuclear power plant diagnostics in APL
APL '91 Proceedings of the international conference on APL '91
A bibliography of APL articles on modeling and KBES
ACM SIGAPL APL Quote Quad
Do Russian children like APL2?
APL '92 Proceedings of the international conference on APL
Roles of APL in satellite surveillance
APL '93 Proceedings of the international conference on APL
Extending APL2 to include program control structures
APL '93 Proceedings of the international conference on APL
APL '94 Proceedings of the international conference on APL : the language and its applications: the language and its applications
Simulation of mail warehouse: an APL2 solution for a large company problem
APL '94 Proceedings of the international conference on APL : the language and its applications: the language and its applications
Hi-index | 0.00 |
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.