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.7 required=5.0 tests=BAYES_00,INVALID_DATE, LOTS_OF_MONEY,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!trwind!venice!sleepy!vtarbox From: vtarbox@sleepy.bmd.trw.com Newsgroups: comp.lang.ada Subject: Legislative Mandate for Ada (AF Policy) Message-ID: <1001.276fbb38@sleepy.bmd.trw.com> Date: 20 Dec 90 02:10:48 GMT Reply-To: vtarbox@sleepy.bmd.trw.com (Val Tarbox) List-Id: I have followed, with some interest, the dialogue that has occurred since the posting by Mike Feldman outlining the "Legislative Mandate for Ada" [<2449@sparko.gwu.edu> mfeldman@seas.gwu.edu]. I thought some of you might be interested in the contents of an action memorandum issued at the Air Force secretariat level on 07 Aug 90. A complete unedited transcript is provided, below. It immediately implements AF policy establishing Ada as the single implementation language for *all* new (not just new weapon systems) and upgraded software systems in the Air Force. Please note the memorandum preceded the legislative action (Section 8092) by almost three months. What impact this will have on AF policy is unclear. It may have no impact depending upon the interpretation of the phrase "...where cost-effective..." in Section 8092. I hope the following sheds more light regarding the mind-set of the Air Force bureaucrats (and possibly others within DOD). It may create more fog depending upon interpretations from another viewpoint. If any have seen this before, I apologize for the repeat. Sorry for the length but I'm not the author. So here we go! --- THE MEMORANDUM --- 07 August 1990 Memorandum for the: Vice Chief of Staff Major Command Separate Operating Agency Direct Reporting Unit Commanders Air Force Program Executive Officers Subject: Air Force Policy on Programming Languages - Action Memorandum Growing mission demands for software, particularly in the austere budget environment we face, require a solid commitment to software engineering. Ada is more than a language; it is a proven technology that facilitates software engineering, reducing risk and life-cycle costs. Accordingly, the attached policy establishes Ada as the single implementation language for all new and upgraded software systems in the Air Force. This policy supersedes CSAF/CVA letter, Air Force Policy on Programming Languages, November 9, 1988. Now is the time to move aggressively to Ada. Please give your personal support to ensuring that the attached policy is fully implemented within your organization. The Air Staff will incorporate this policy into an appropriate Air Force regulation applicable to all software domains. Signed: Lloyd K. Mosemann, II Deputy Assistant Secretary of the Air Force Communications, Computers, and Logistics --- THE ATTACHMENT --- PROGRAMMING LANGUAGES POLICY 1. INTRODUCTION Air Force policy requires the use of the Ada programming language as defined in ANSI/MIL-STD-1815A-1983 (Ada Programming Language, 22 January 1983). This policy implements DOD Directives 3505.1 (Computer Programming Language Policy, 2 April 1987) and 3505.2 (Use of Ada in Weapon Systems, 30 March 1987). This policy remains in effect until it is published in an Air Force regulation. 2. DEFINITIONS a. Ada Implementation: A software system in which Ada is used to meet all or most of the language requirements. Use of other languages in an Ada implementation will be limited to those needed for special functions and requires and "exception request". b. Commercial-Off-The-Shelf (COTS) Software: Software already developed, tested, and sold to other DOD or commercial customers, supported by a commercial vendor over the system life-cycle, and requiring no government modifications over the system life-cycle. c. DOD approved High Order Languages (HOLs): The languages listed in Enclosure 3 to DOD Directive 3405.1 (Computer Programming Language Policy, 02 April 1987). - Ada - SPL/1 - COBOL - CMS-2M - CMS-2Y - PASCAL - C/ATLAS - FORTRAN - JOVIAL J73 - MINIMAL BASIC d. Forth Generation Languages (4GLs): Nonprocedural COTS computer programming languages which consist of compact, English-like statements which describe the overall tasks a computer is to carry out without specifying any individual steps or their order. For the purpose of this policy, 4GLs include products which generate HOL Code. e. Software engineering: The science of analysis, design, development, implementation, test, evaluation, and maintenance of computer software over its life-cycle. f. Validated Ada Compiler: A compiler registered with the Ada Joint Program Office (AJPO). A project-validated compiler, a compiler that is registered with the AJPO at project start or Milestone 0, is considered validated for the entire life-cycle of the designated project. 3. APPLICABILITY This policy applies to all Air Force organizations to include both in-house and contractor work. It covers all computer software systems, e.g.: - Weapon - Intelligence - Information Systems - Command and Control - Automatic Test Equipment developed, acquired, or managed under the AFR 700 series, AFR 800 series, or AFR 57-4, and includes software for the entire range of computer hardware. 4. EXEMPTIONS a. Desktop computers and workstation software developed for individual use, stand alone, unique in-house applications. b. Short term/adhoc user applications (less that three years useful life). c. Products that come with software (e.g., automotive diagnostic systems) for which the Air Force has no maintenance responsibility. 5. POLICY a. The Ada programming language, as defined in ANSI/MIL-STD-1815A-1983, is the single, common, high order computer programming language for all computer resources used in the Air Force. A validated Ada compiler and modern software engineering principles that facilitate the use of Ada must be used, unless a waiver has been granted. The order of preference to meet Air Force software requirements follows: (1) Reuse/modify existing Ada code. (Waiver Not Required). (2) Use COTS software (software requiring no modifications or government maintenance). (Waiver Not Required). (3) Develop new Ada code. (Waiver Not Required). (4) Use 4GLs that generate Ada code or support Database Language SQL (Federal Information Processing Standard 127-1). (Exception Request Required). (5) Develop non-Ada code, modify COTS, or use 4GLs that generate non-Ada code or do not support SQL. (Waiver Required). [Note: A waiver is required to use DOD-approved HOLs (except Ada) and non-DOD-approved languages (e.g., C and Assembly)] b. Systems under development using a non-Ada language that was authorized prior to the effective date of this letter may continue to use non-Ada through deployment and maintenance. (Waiver Not Required). c. Ada is required when more that one-third of the existing code is altered (excluding COTS) at any one time. (Under one-third, Waiver Not Required). System Managers are encouraged to move to Ada with any software or hardware upgrade. d. 4GLs can be used to support rapid prototyping and evolutionary development. (Exception Request Required). e. Other languages (e.g., Assembly, C, C/ATLAS, 4GL, another HOL) may be mixed with the Ada code in an Ada implementation for a special function or routine. (Exception Request Required). f. If Ada is used for Unit Under Test (UUT) and Automatic Test Equipment (ATE), it shall use C/ATLAS standard nouns, noun modifiers, and procedural terminology (i.e., verbs, macros) and be consistent with the intent of standards being developed within the Institute of Electrical and Electronic Engineers (IEEE) effort called ATLAS/Ada Based Environment for Test (ABET). g. Support Tools which PMRT to AFLC with specialized operating systems, (e.g., simulators, stimulators) for which no validated Ada compiler exists. (Waiver Not Required). h. Industrial Process Equipment Acquisition (IPEA) programs for which AFLC is the implementing command, to include stand-alone microcontroller devices and devices where microcomputers are used as microcontrollers. (Waiver Not Required). i. For small projects where using Ada is not feasible or cost effective over the system life-cycle, and an exception request, instead of a waiver request, may be used. 6. WAIVERS a. Waiver requests must contain a description of the project, the rationale and/or justification for not using Ada, and a life-cycle analysis. The analysis must show that the recommended solution is the most cost effective and most beneficial to the Air Force over the system life-cycle. As a minimum, the analysis must: (1) Use a 10-year life-cycle, if actual life-cycle is unknown. (2) Use approved DOD inflation rates. (3) Specify development, life-cycle maintenance, training, and replacement costs. (4) Address portability, reuse, performance, and risk. (5) Include a statement of maintainability from the responsible software maintainer. b. The cost/effort to do the analysis should be commensurate with the size and cost of the project. For example, developing an Ada compiler/support environment may not be cost effective for some projects over the system life-cycle. c. Waiver requests will be submitted through appropriate levels (unit, base, MAJCOM/SOA, Air Staff functional area) to HQ USAF/SC as early as possible in the development cycle. Waivers must be approved before a commitment is made to the architecture (i.e., before release of the final Request for Proposal for contractor software development, and before system design begins for in-house development). HQ USAF/SC will staff waiver requests with cognizant HQ USAF offices and make a consolidated recommendation of SAF/AQ, the sole USAF Ada waiver approval authority. d. Waiver requests for Class IV modification programs with cost of more the $10M, will be part of the program package staffed at HQ USAF. The Ada waiver will be included in the package and will be staffed in conjunction with the program. An informational copy may be sent to HQ USAF/SC, but will not be acted upon until validated by the appropriate level. 7. EXCEPTIONS a. An exception request, instead of a waiver request, will be submitted through appropriate levels to HQ USAF/SC for approval, and must be approved before implementing the solution. The exception request must include a description of the project and the rational/justification for the exception An information copy may be sent to HQ USAF/SC, but will not be acted upon until validated by the appropriate level. b. An exception request is not required for test equipment procured to be compliant with Modular Automatic Test Equipment (MATE) standards. This includes the use of the government furnished MATE Control and Support Software (MCSS), written in JOVIAL, which accommodates ATLAS constructs in the test program. However, our intention is to develop Ada for MATE applications, and program offices are encourage to develop Ada usages in advance of formal MATE conversion. 8. TECHNICAL ASSISTANCE Technical assistance on use of Ada (tools, environments, bindings, software engineering, training, and data base management systems) is available from HQ USAF/SCTT, DSN 225-9934 or DSN 223-2699. Lloyd K. Mosemann, II Deputy Assistant Secretary of the Air Force Communications, Computers, and Logistics SAF/AQK Room 4E128 Pentagon Washington, DC 20330 DSN 227-3624 (703) 938-4843 --- END OF ACTION MEMORANDUM --- Val Tarbox TRW Space & Technology Group 801-625-8024