From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!linus!decvax!ucbvax!usc-eclb.arpa!EBERARD From: EBERARD@USC-ECLB.ARPA (Edward V. Berard) Newsgroups: net.lang.ada Subject: Problems With DOD-STD-2167 Message-ID: <12148215050.47.EBERARD@USC-ECLB.ARPA> Date: Thu, 3-Oct-85 14:18:20 EDT Article-I.D.: USC-ECLB.12148215050.47.EBERARD Posted: Thu Oct 3 14:18:20 1985 Date-Received: Tue, 15-Oct-85 07:23:24 EDT Sender: daemon@ucbvax.ARPA Organization: The ARPA Internet List-Id: I have good news and I have bad news. The good news is that DOD-STD-2167, the new DoD standard for software development (which supersedes DOD-STD-1679A (NAVY) and MIL-STD-1644B (TD)), does indeed address Ada technology. Specifically, in Appendix C of the copy I have (dated 4 June 1985), the following paragraph appears: "30.2 Applicability. This appendix contains design and coding standards generally applicable to all programming languages. However, it does not provide complete design and coding standards for some higher order languages with advanced capabilities (e.g., Ada, PROLOG, etc.). In such cases, the contractor should propose additions to this appendix in either the the SSPM or SDP (see Appendix D) and obtain contracting agency approval." The good news appears to get even better. There is a MIL-HDBK-287, the "Defense System Software Development Handbook." This handbook is currently under formal review and will supersede DOD-HDBK-281. The copy I have is dated 6 September 1985. On page 43 of MIL-HDBK-287, starting with paragraph 4.4.17, there is a discussion of "Use of Ada with DOD-STD-2167 and Associated Standards." Among other things, this paragraph says: "This language, because of its advanced constructs, needs its own set of coding standards, as well as an explanation of how it maps to DOD-STD-2167 terminology. Appendix B provides a general set of coding standards that can be implemented on all Ada programs. The mapping of DOD-STD-2167 terminology to Ada is as follows:" This is followed by four paragraphs which talk about the mapping of Ada program units to DOD-STD-2167 terminology. Those of you who have any kind of background in software development methodologies and Ada, should recognize the above as the beginning of the bad news. DOD-STD-2167 is oriented almost exclusively towards a functional decomposition approach to software development. This makes the use of modern software engineering technology particularly difficult. Object oriented approaches (e.g., Object Oriented Design ala Booch or Love) and modeling approaches (e.g., Jackson System Development) are far better for Ada software development than functional decomposition. (I know this is a strong claim, yet I, and others, can back it up with empirical evidence, if you are interested.) In addition, concepts like "design a little, code a little" and prototyping have proven useful in the software development process, yet they do not seem to fit within the rigid mold cast by DOD-STD-2167. (Yes, I know that clever Ada software developers can "work around" the restrictions imposed by DOD-STD-2167, but they should be able make use of sound software engineering methodologies in a straightforward manner without having to subvert the intentions of the DoD.) [It seems inconsistent that the same organization, i.e., the DoD, can sponsor both DOD-STD-2167 and METHODMAN I & II. The former would have been an excellent document in the late 1960s, and the latter documents at least get us to the early 1980s.] The bad news gets worse. A quick check of Appendix B in MIL-HDBK-287 reveals that the authors have an uneven knowledge of both Ada and software engineering. Consider the following direct quotes: "20.6.1.2 Loops without exits (i.e. a loop without a FOR clause, a WHILE clause, or a nested exit statement) shall be used only in task bodies. In general, an infinite loop is a programming error. However, in Ada they do find use in the body of a task that must continue its function as long as the program is running." [This is a strange restriction, especially given that Ada is intended to be used in real-time applications where infinite loops are far more common than in non-real-time applications. Yes, infinite loops will show up most commonly, *but not exclusively*, in task bodies.] "20.10 Tasking. Ada tasking shall be used to implement parallel processing. Ada provides tasking features to allow parallel processing to be expressed within the language." [This statement I find particularly confusing. Does the author mean that I should not attempt to implement parallel processing using some other feature of the language?] "20.10.4" A task shall not call its own entries. This will result in a deadlock situation." [I find this admonishment particularly insulting. Do they think that a professional software engineer would produce code which would attempt this, and that the testing of the software would be so slipshod as not to detect such a blatant error?] There is no mention of generics in Appendix B. Maybe the concept of data abstraction is foreign to the author(s). To be fair, there is some sound advice contained in Appendix B of MIL-HDBK-287. Concepts like information hiding and abstraction are mentioned and strongly suggested. I agree with many of the coding suggestions made in the appendix. However, the level of the discussion in Appendix B indicates that the author(s) has a strong background in a language other than Ada (possibly Pascal). Sadly, both DOD-STD-2167 and MIL-HDBK-287 treat Ada as "just another coding language with some 'advanced capabilities'" which must be mapped into the FORTRAN mindset. The bad news gets even worse. It is extremely difficult to introduce new software technology. Even with DoD Directive 5000.31, it is difficult to insert Ada technology within an organization. Particularly enlightened organizations have realized that the language by itself is not enough, i.e., it must be used in the context of modern software engineering technology to achieve maximum benefits. Organizations such as Magnavox and Ford Aerospace have made radical changes in their treatment of the software life-cycle to accommodate not only the Ada language, but methodologies like Object Oriented Design. These changes involve a great deal of time money and effort. These organizations, and others, have been frustrated when they find that their contracting offices only think of Ada as a programming language, and in fact *discourage* the use of modern software engineering. It is not only the DoD contractors who must be educated in the new technology. The contracting agencies themselves must be aware of, appreciate, and *accommodate* modern software engineering technology. The DoD is to be commended for attempting to bring order out of the chaos which all too often characterizes software development. However, the current solution (i.e., DOD-STD-2167) penalizes better solutions in favor of 1960s style software development methodologies. The solution to the problem is to develop a software development standard which is capable of recognizing a variety of superior development methodologies. -- Ed Berard [If you are wondering why you haven't heard about MIL-HDBK-287, the list of reviewers, which includes organizations like EIA, AIA, IEEE, NSIA, and SSQ, does *not* include ACM, SIGAda, or AdaJUG.] P.S.: If you are interested in doing something about DOD-STD-2167, positive or negative, you should contact the newest SIGAda working group: "DOD-STD-2167 Constraints Upon Ada-Oriented Methodologies." The point of contact is: Mr. Donald Firesmith Magnavox Electronic Systems Company Advanced Software Systems Department TC-10-C-3 D519 1313 Production Road Fort Wayne, IN 46808 (219) 429 - 4327 -------