Glazer, Joel (1990, ASQC) Westinghouse Electric Corporation, Baltimore, MD
Man is continuously searching for the perfect solution. No matter what the problem is, he has the belief or desire that a "silver bullet" exists to solve the problem. A current problem is the software crisis. This presentation addresses concerns and reservations some software developers express about "the proposed perfect solution", namely the recently released United States Department of Defense (DOD) Military Standards DOD-STD-2167A "Defense System Software Development" and DOD-STD-2168 "Defense System Software Quality Program" as well as the use of these standards in the procurement activities of weapon systems. The presentation identifies potential risk areas in the development of software associated with blind adherence to untailored standards.
The newly released issues of DOD-STD-2167A, DOD-STD-2168 and the related military standards of MIL-STD-483A, MIL-STD-490A, MIL-STD-499, and MIL-STD-1521B together with the various Data Item Descriptions (DIDs) are indeed the best U.S. military standards related to software in existence. To the author's knowledge, no other standards are as comprehensive for software acquisition. However, to follow these standards blindly for unprecedented development, a software project must be carefully and minutely planned, executed precisely and methodically as planned. Deviations must receive prior approval. Little room is allowed to provide a balance between conformance and flexibility in an unstable procurement environment. The standards emphasize documentation compliance and reviews by a multitude of independent and outside groups because the buyer (government) will usually be understaffed, pressed for time, and unable to perform the review. This creates the added need for the documents to be written in greater detail than is required for working papers, and to describe the software in a tutorial-like manner prior to stabilization of technical requirements.
In the world of cheap and easy access to computer power, the software engineer may be inclined to overlap the design and code phases. There is a tendency to abuse and neglect discipline because computer time and cost have been reduced to seconds and pennies; consequently there is a greater propensity to be careless and make errors due to the belief that the errors will be caught at the next go-around/iteration. The design language is a form of "coding". New tools are, or soon will be, available to increase productivity at the terminals with self-documenting code and reusable, provable correct constructs. This approach and these tools will reduce the need for multiple reviews because code will be created, tested, fixed and retested rapidly and, when complete, used to build larger constructs of code.
Software engineers are beginning to use software tools that can reduce the tedious work of capturing their thoughts on screen; this process is lone overdue. They have designed and developed such tools for other engineering disciplines and for household use, so why not use them themselves?
The basic beauty and benefit of software is inherent in its "softness": changeability, flexibility and quickness to implement. This characteristic, however, is also its greatest source of risk and pitfall; namely, change with no discipline, no traceability, and/or no control for the sake of expediency. Software is a double-edged sword that must be harnessed and channeled properly.
The future is bright, the search for the "perfect solution" must go on, but no "silver bullet" is to be found in the current versions of DOD standards. It might be brought closer with new and innovative tools, methodologies, techniques, and languages. The software crisis is not only DOD's, it is much wider. Collectively, from all areas of the software discipline, we must bring the perfect solution closer to reality.