The Committee on the Review of the Past and Present Contexts for the Use of Ada in the Department of Defense reviewed the DOD policy currently in use for programming language selection ("Computer Programming Language Policy," DOD Directive 3405.1, dated April 2, 1987), as well as two different draft revisions of that policy. This appendix contains the most recent draft (dated May 15, 1996) reviewed by the committee and incorporates modifications suggested by the committee to make the directive consistent with the recommendations presented in the main text of this report. Modifications are noted in italic font.

This modified draft directive is intended to serve as a "template" for development of the new DOD Directive 3405.1. The "enclosures" that are typically attached to DOD directives have been omitted for brevity. However, a list of references follows the text of the draft directive, and technical terms are defined in Appendix C of this report; both sets of documentation are suitable as enclosures for the revised formal DOD directive. The enclosure titled "Ada Waiver Procedures" has been omitted from the template because the committee eliminated the waiver process in its recommended policy. Other emendations of the draft text to condense wording or otherwise revise original text are not strictly documented; comparison with the May 15, 1996, draft directive shows minor changes not accommodated by the device of italicizing more substantial revisions.

A. REISSUANCE AND PURPOSE

This Directive:

1. Updates and establishes policy for management of software developed, used, or maintained by, or for, the Department of Defense (DOD).
2. Is used in software management decisions across a functional or mission area, domain, or product-line. It contains broad software engineering and programming language policy that will be followed by DOD.
3. Establishes the requirement for a Software Engineering Plan Review Board (SEPRB) by the Office of the Secretary of Defense (OSD), the Military Departments (including the National Guard and Reserve Components), and the DOD components.
4. Supersedes reference (a); cancels references (b) and (c); implements Federal Information Resource Management Regulation (FIRMR) Subpart 201-24.201, Federal Software Exchange Program (reference (d)); and supports DOD Directive 8000.1 (reference (e)) and DOD Directive 5000.1 (reference (f)) and DOD Instruction 5000.2 (reference (g)).
5. Authorizes publication of DOD Instruction 3405.1, "Software Management Implementation."

B. APPLICABILITY AND SCOPE

This Directive applies to:

1. The Office of the Secretary of Defense (OSD), the Military Departments (including the National Guard and Reserve components), the Chairman of the Joint Chiefs of Staff and the Joint Staff, the Unified Combatant Commands, the Inspector General of the Department of Defense, the Defense Agencies, and the DOD Field Activities (hereafter referred to collectively as "the DOD Components").
2. All software developed, acquired, or used by the DOD, including that managed in accordance with DOD Directive 5000.1 (reference (f)).
3. DOD research and development activities funded by 6.4 and 6.5 appropriations as defined in Volume 2, DOD 7000.14-R, (reference (1)).
4. Software developed, acquired, or used by DOD research and development activities, and funded by 6.1, 6.2, and 6. 3a appropriations, is exempted from this directive.

C. DEFINITIONS

Committee note: Terms used in this directive and modifications to it are defined in Appendix C of this report, and those definitions are suitable for inclusion as an enclosure in a new DOD directive.

D. POLICY

It is DOD policy to:

1. Perform trade-off and business-case analysis in the development and acquisition of affordable, rapidly produced, high-quality software. Quality includes functionality, fitness for a purpose, assurance (i.e., reliability, survivability, availability, safety, security), efficiency, ease of use, interoperability, future adaptability (i.e., extensibility, maintainability, portability, and compliance with standards), and the development of DOD software expertise. Cost includes full life-cycle cost, consequence of system failure, impact on system operational costs, and use of other scarce resources such as expert personnel.
2. Exploit and contribute to open standards-based technical architectures that support rapid, flexible, and incremental software improvements, and that accommodate increasing reliance on the commercial sector to satisfy evolving mission and functional requirements. Exploit and contribute to

2. software architectures that serve as the basis for management and investment decisions for reuse opportunities, interoperability requirements, and development or product-lines and product-line components. Facilitate the reuse of software assets.
3. Define mission and functional requirements so that commercial and non-developmental items may be used to fulfill such requirements. To the maximum extent practicable, modify requirements and conduct market research and analysis, prior to commencing a development effort, to take advantage of a commercial or non-developmental "best value" solution. Give preference to commercial off-the-shelf (COTS) items first and non-developmental items (NDI) second when satisfying software asset requirements.
4. Implement and continuously improve software process management and software engineering disciplines. Use software engineering environments that facilitate software process management and software engineering disciplines.
5. Employ software developers who possess mature software engineering capabilities. Software developers should have a successful past performance record, experience in the software domain or product-line, a mature software development process, and evidence of use and adequate staffing and training in software methodologies, tools, and environments.
6. Use metrics when monitoring and managing production and delivery of software assets, evaluating maintenance and management practices, implementing software architectures and product-lines, and effecting continuous software process improvement.
7. Enforce compliance with contractual terms and conditions for use of software, including copyright and license agreements. Centralize this function to the maximum extent practicable.
8. Use commercial fourth-generation programming languages (4GLs) where appropriate, when they provide significant improvements in productivity, usability, maintainability, and portability. Selection of 4GLs and associated tools must be based on established acceptance in the commercial marketplace where benefits of the technology have been demonstrated. Any software code generated using a 4GL must also be maintained in the 4GL.
9. Use the highest-level language meeting quality, cost, and scheduling constraints for each software component. Principles for choice of this language are as follows:
1. Higher-level languages are generally preferable to lower-level languages.
2. Standardized and non-proprietary languages are preferred. Using standards increases portability of code and programmers. Non-proprietary languages reduce the risk of vendor lock-in.
3. New languages must not be developed as part of a system development, except for domain-specific languages providing directives for application generators.
4. Quality, time, and cost factors should be considered in selecting a language.

10. Use the Ada programming language (reference (i)) to develop software subsystems when all of the following apply:
1. The application is in a warfighting application area (i.e., weapon control, electronic warfare, wideband real-time surveillance, battle management, special battlefield communications).
2. Maintenance will be government-directed.
3. The expected size of the subsystem exceeds 10,000 lines of code, or the subsystem is critical.
4. There is no better COTS, NDI, 4GL, or higher-level solution consistent with quality and cost goals.
5. There is no life-cycle cost-effectiveness justification for using another programming language.
6. The code is new or re-engineered.

10. In cases meeting the above criteria, the required compliance level is set at 95% of the source lines of code. Up to 5% of the code can be written in other languages to facilitate component integration.
11. When the application is in a non-warfighting application area (e.g., office and management support, personnel, logistics, medicine, routine operations support), Ada will be analyzed as an option when substantial 3GL development is to be performed. The analysis will be in accordance with the principles set forth in D. 9 above.

E. RESPONSIBILITIES

1. The Under Secretary of Defense (Policy) shall ensure that requests from DOD Components for guidance on international transfer or export of DOD software are processed and appropriate guidance on such release is provided.
2. The Office of the Assistant Secretary of Defense (OASD) for C³I shall:
1. Provide policy, guidance, and oversight for the management of software consistent with applicable directives, and may issue additional instructions related to implementation of this Directive.
2. Issue policies and guidance to implement DOD software reuse practices and the Federal Software Exchange Program (reference (d)).
3. Direct DOD Components to establish programs, as appropriate, to enhance the software engineering processes and the transition of technologies from commercial and research programs into applications within weapon, automated information systems (AISs), and command and control systems.
4. Establish an OSD-level Software Engineering Plan Review (SEPR) process that will review all software architecture plans for any acquisition subject to OSD milestone decision authority (MDA). The purpose of this review will be to approve and certify the software engineering plans for the system software prior to Milestone I and II reviews. Certification indicates that the software plan conforms to the policy and principles contained within this Directive. For these reviews, the acquisition program shall establish a program-specific Software Engineering Plan Review Board (SEPRB). The SEPRB will be composed of at least 5 members who are software experts, will include key system stakeholders (e.g., users, maintainers, interoperation experts), and will be chaired by a representative of the OASD (C³I).
5. Establish a process for periodic review of SEPRB reviews performed by DOD components.
6. Identify research and development requirements to the Director, Defense Research and Engineering, for inclusion in research and development programs.

3. The Head of Each DOD Component shall:
1. Initiate appropriate strategies and actions to implement the policies in Section D within their areas of responsibility.
2. Establish a component-level SEPR process that will review all software architecture plans for any acquisition subject to component MDA. The purpose of this review will be to approve and certify the plans for the system software prior to Milestone I and II reviews. Certification indicates that the software plan conforms to the policy and principles contained within this Directive and applicable component policies. For these reviews, the acquisition program shall establish a program-specific SEPRB. The SEPRB will be composed of at least 5 members who are software experts, will include key system stakeholders (e.g., users, maintainers, interoperation experts, program executive officials), and will be chaired by a member appointed by the service or component acquisition executive.

3. Establish and monitor a SEPR process for non-MDA DOD component-directed software, and as appropriate for other DOD component software.
4. Delegate to appropriate subordinate organizations the authority to release software assets, as appropriate, to the Federal Software Exchange Program (FSEP), reference (d), and for DOD reuse purposes.
5. Specifically address investment strategies, including use of modern software technology and the transition to newer technologies, in the DOD Component planning, programming, and budgeting process.

F. EFFECTIVE DATE AND IMPLEMENTATION

This Directive is effective immediately.

G. REFERENCES:

• (a)	Department of Defense (DOD) Directive 3405.1, "Computer Programming Language Policy," April 2, 1987 (hereby canceled)

• (b)	Assistant Secretary of Defense for Command, Control, Communications and Intelligence (C3I) Memorandum, "Delegation of Authority and Clarifying Guidance on Waivers from the Use of the Ada Programming Language," April 17, 1992 (hereby canceled)

• (c)	DOD Instruction 7930.2, "ADP Software Exchange and Release," December 31, 1979 (hereby canceled)

• (d)	Federal Information Management Regulation (FIRMR) Subpart 201-24.201, Federal Software Exchange Program

• (e)	DOD Directive 8000.1, "Defense Information Management Program," October 27, 1992

• (f)	DOD Directive 5000.1, "Defense Acquisition," March 15, 1996

• (g)	DOD Instruction 5000.2, "Defense Acquisition Management Policies and Procedures," March 15, 1996

• (h)	DOD Directive TS-3600.1, "Information Warfare," December 21, 1992

• (i)	International Organization for Standardization (ISO/IEC 8652:1995), "Ada," February 15, 1995

• (j)	DOD Directive 5200.28, "Security Requirements for Automated Information Systems (AISs)," March 21, 1988

• (k)	DOD Regulation 5200.1-R, "Information Security Program Regulation," December 1987, authorized by DOD Directive 5200.1, "DOD Information Security Program," June 7, 1982

• (l)	DOD 7000.14-R, "DOD Financial Management Regulation," Volume 2, "Budget Presentation and Formulation," May 1994, authorized by DODI 7000.14, "DOD Financial Management Policy and Procedures"