Legislative Mandate for Ada (AF Policy)

Legislative Mandate for Ada (AF Policy)

[vtarbox]

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