NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/ada/2583

Internet Message Format | 1992-09-10 | 12.5 KB

Path: sparky!uunet!gatech!wrdis01!sadis01!dgray
From: [e-mail] ( SCDR)
Newsgroups: comp.lang.ada
Subject: AF Ada waivers (was Re: Ada for Small Processors)
Keywords: waiver, exception
Message-ID: <[e-mail]>
Date: 10 Sep 92 19:41:51 GMT
References: <[e-mail]> <EACHUS.92Sep8121403@Dr_No.mitre.org> <[e-mail]>
Organization: 1923CCSG/SC Kelly AFB, San Antonio, TX
Lines: 286

In article <[e-mail]> [e-mail] (Rob Spray) writes:
>In <EACHUS.92Sep8121403@Dr_No.mitre.org> eachus@Dr_No.mitre.org (Robert I. Eachus) writes:
>
>>In article <[e-mail]> [e-mail] (Rob Spray) writes:
>
>>   > A project I am familiar with got a waiver to write a few hundred
>>   > line C program for an Intel 8031.
>
>>   Was this an Air Force program? If so, what you got was almost
>>certainly an exception not a waiver, but that's a different issue.
>
>Well, I saw a piece of paper with the requisite emblems on it
>and I thought it said waiver, but it's been a while since I was
>in that game.  Now you've brought it up, Bob, what is the difference?

As someone who has had to deal directly with this paperwork for the last
couple years, I hope it's okay if I answer that.  The difference between the
two is basically the approval authority and the amount of work required to
produce the paperwork.  If a program is not going to be completely Ada, you want
to apply for an exception NOT a waiver (if possible, more on that later) for
three reasons: 1) An exception is usually just a few pages and describes how the
project fits into a few well-defined categories versus the waiver requirement
of a FULL life-cycle cost analysis (a painful task)  2) As of four months ago,
NO WAIVERS HAD BEEN APPROVED for the entire USAF - not a good projection for
success.  3) It takes longer to get a waiver approved.  Exceptions go only to
HQ USAF/SC; waivers have to go up to the Asst Sec'y of the AF for Acquisition.

Unfortunately, you can only for an exception if you fit into one of the neat
categories outlined in Asst Sec'y Mosemann's policy letter dated 7 Aug 1990.
Instead of typing that all out for you guys, I'll just append a copy of that
letter to this article.  Hope that answers your questions.

    -Doug

1Lt Doug Gray  --  SC Ada/Software Engineering Officer
[phone]
DSN:945-7155

========================  Enclosure  =================================

                    DEPARTMENT OF THE AIR FORCE
                     WASHINGTON DC 20330-1000

OFFICE OF THE ASSISTANT SECRETARY

                                          07 AUG 1990

MEMORANDUM FOR THE VICE CHIEF OF STAFF
               MAJOR COMMAND, SEPARATE OPERATING AGENCY, AND
               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 lifecycle 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.

                                 LLOYD K. MOSEMANN, II
                                 Deputy Assistant Secretary
                                 (Communications, Computers &
                                  Logistics)

1 Attachment
Programming Languages
Policy


                  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 Jan 83).  This policy implements DOD
Directives 3405.1 (Computer Programming Language Policy, 1 Apr
87) and 3405.2 (Use of Ada in Weapon Systems, 30 Mar 87).  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 require an "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 DODD 3405.1, Computer Programming
Language Policy, 2 Apr 87 (Ada, C/ATLAS, COBOL, CMS-2M, CMS-2Y,
FORTRAN, JOVIAL J73, Minimal BASIC, PASCAL, and SPL/1).

    d.  Fourth 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 O, 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, command and control,
intelligence, automated test equipment, and information systems)
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.

                                                  Atch 1


4.  Exemptions.

    a.  Desktop computers and workstation software developed for
individual use, stand alone, unique, in-house applications.

    b.  Short term/ad hoc user applications (less than three
years useful life).

    c.  Products that come with software (e.g., automotive diagnostic
systems) for which 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.  (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 than 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).

2


    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 and automatic test
equipment software, 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.  (No waiver required.)

    h.  Industrial Process Equipment Acquisition programs for
which AFLC is the implementing command, to include stand-alone
micro-controller devices and devices where microcomputers are
used as microcontrollers.  (No waiver required.)

    i.  For small projects where using Ada is not feasible or
cost effective over the system life cycle, 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.

3


    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
to SAF/AQ, the sole USAF Ada waiver approval authority.

     d.  Waiver requests for Class IV modification programs with
cost of more than $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 a rationale/justification for the exception.  An informational
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 encouraged 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,
AUTOVON 225-9934 or (703)-697-3624.