INFORMATION TECHNOLOGY STANDARDS GUIDANCE

(ITSG)

(Part 2 of 14 parts)

SOFTWARE ENGINEERING SERVICES

 

 

 

 

 

 

 

 

Version 3.1 - April 7, 1997

 

 

AREA IPSC

DISTRIBUTION STATEMENT A: Approved for public release; distribution unlimited

TABLE OF CONTENTS

3.2 Software engineering services 3.2-

3.2.1 Software engineering environments 3.2-

3.2.1.1 CASE/software development environment 3.2-

3.2.1.2 Reusable source code libraries 3.2-

3.2.1.3 Specialized language and compiler tools 3.2-

3.2.2 Software life cycle processes 3.2-

3.2.2.1 Software life cycle 3.2-

3.2.2.2 Software configuration management 3.2-

3.2.2.3 Documentation standards 3.2-

3.2.2.4 Joint reviews 3.2-

3.2.2.5 Software requirements 3.2-

3.2.2.6 Software design 3.2-

3.2.2.7 Software management indicators 3.2-

3.2.2.8 Software testing and product evaluation 3.2-

3.2.2.9 Software quality assurance 3.2-

3.2.2.10 Software problem categories/priorities 3.2-

3.2.2.11 Software safety 3.2-

3.2.2.12 Software support 3.2-

3.2.2.13 Software distribution 3.2-

3.2.2.14 Software license management 3.2-

3.2.3 Programming languages 3.2-

3.2.3.1 Programming language framework 3.2-

3.2.3.2 Ada 3.2-

3.2.3.3 C, C++ 3.2-

3.2.3.4 FORTRAN 3.2-

3.2.3.5 COBOL 3.2-

3.2.3.6 JOVIAL 3.2-

3.2.3.7 MUMPS 3.2-

3.2.3.8 Simulation languages 3.2-

3.2.3.9 Artificial intelligence languages 3.2-

3.2.3.10 Fourth generation languages 3.2-

3.2.4 Bindings 3.2-

3.2.4.1 Ada bindings 3.2-

3.2.4.2 C language bindings 3.2-

3.2.4.3 FORTRAN bindings 3.2-

3.2.4.4 Bindings to COTS products 3.2-

3.2.5 Software Engineering Security Services 3.2-

3.2.5.1 Security models and architectures 3.2-

3.2.5.2 System development security 3.2-

3.2.5.3 Personal authentication 3.2-

3.2.5.4 Certification and accreditation 3.2-

3.2.5.5 Security risk management 3.2-

3.2.5.6 Detection and notification 3.2-

3.2.5.7 Security recovery 3.2-

LIST OF TABLES

3.2-1 CASE/software development environment standards 3.2-

3.2-2 Reusable source code libraries standards 3.2-

3.2-3 Specialized language and compiler tools standards 3.2-

3.2-4 Software life cycle standards 3.2-

3.2-5 Software configuration management standards 3.2-

3.2-6 Documentation standards standards 3.2-

3.2-7 Joint reviews standards 3.2-

3.2-8 Software requirements standards 3.2-

3.2-9 Software design standards 3.2-

3.2-10 Software management indicators standards 3.2-

3.2-11 Software testing and product evaluation standards 3.2-

3.2-12 Software quality assurance standards 3.2-

3.2-13 Software problem categories/priorities standards 3.2-

3.2-14 Software safety standards 3.2-

3.2-15 Software support standards 3.2-

3.2-16 Software distribution standards 3.2-

3.2-17 Software license management standards 3.2-

3.2-18 Programming language framework standards 3.2-

3.2-19 Ada standards 3.2-

3.2-20 C, C++ standards 3.2-

3.2-21 FORTRAN standards 3.2-

3.2-22 COBOL standards 3.2-

3.2-23 JOVIAL standards 3.2-

3.2-24 MUMPS standards 3.2-

3.2-25 Simulation languages standards 3.2-

3.2-26 Artificial intelligence languages standards 3.2-

3.2-27 Fourth generation languages standards 3.2-

3.2-28 Ada bindings standards 3.2-

3.2-29 C language bindings standards 3.2-

3.2-30 FORTRAN bindings standards 3.2-

3.2-31 Bindings to COTS products standards 3.2-

3.2-32 Security models and architectures standards 3.2-

3.2-33 System development security standards 3.2-

3.2-34 Personal authentication standards 3.2-

3.2-35 Certification and accreditation standards 3.2-

3.2-36 Security risk management standards 3.2-

3.2-37 Detection and notification standards 3.2-

3.2-38 Security recovery standards 3.2-

3.2 Software engineering services. Software engineering services cover all Open System Environment (OSE) services related to the support of information systems development. These services include, but are not limited to, Computer Aided Software Engineering (CASE), software life cycle processes, programming languages, and language bindings.

NOTE: Throughout Part 2, all tables shall have abbreviations listed under the column Standard Type as follows:

a. National Public Consensus = NPC.
b. International Public Consensus = IPC.
c. Government Public Consensus = GPC.
d. Consortia Public Consensus = CPC.
e. Corporate Private Non-Consensus = CPN-C.

For the standard reference column of the table an "R" before the date indicates "reaffirmed."

3.2.1 Software engineering environments. Software Engineering Environments (SEE) provide a set of services across one or more life cycle phases (e.g., requirements, implementation) and support development activities (e.g., design and coding). A SEE consists of resources (hardware, software, tools) and an integration mechanism (e.g., operating system or framework), and is designed around a set of supporting standards and interfaces. The identified SEE standards and interfaces are intended to facilitate the passing of information and data internal and external to the SEE, as well as to provide access to required services. In this document, emphasis is placed on the standards, interfaces, metadata formats and guides that provide the basis for integration, expansion and tailoring of the SEE, its tools and resources.

3.2.1.1 CASE/software development environment. The environments and tools considered are inclusive of all integrated CASE environments. The identified documents support extensive and diverse environments containing numerous integrated software development tools that span the software life cycle. These environments include sets of tools, firmware devices and hardware necessary to support the development and design of software. The tools span a broad range of services and may include, but are not limited to analysis tools, design and test tools, simulation and prototyping tools, code generators and analyzers, and other management tools used in SEEs.

3.2.1.1.1 Standards. Table 3.2-1 presents standards for software development environments.

TABLE 3.2-1 CASE/software development environment standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

Recommended Practice for the Evaluation and Selection of CASE Tools

1209:1993

Adopted

(Approved)

IPC

ECMA

Portable Common Tool Environment (PCTE) - Abstract Specification

149 (1994)

Informational

(Approved)

NPC

IEEE

Standard Reference Model for Computing System Engineering Tool Interconnections

1175:1992

Informational

(Approved)

NPC

EIA

CDIF interim standards (CASE Data Interchange Format)

PN2387, 2389, 2329

Informational

(Approved)

IPC

ISO

Portable Common Tool Environment (PCTE) - Part 1: Abstract Specification (ECMA 149:1990)

13719-1:1995

Informational

(Approved)

NPC

ANSI

CASE Tool Integration Messages (CTIM) X3.273

(X3H6)

Informational

(Draft)

ECMA 149, Portable Common Tools Environment (PCTE) was developed by the European Economic Community (EEC), ECMA, and European regional standards organizations. ECMA 149 is an abstract specification of a tool portability interface. The document has matured, with international collaboration, and is incorporated in ISO 13719-1:1994.

The IEEE standard 1175 is a Standard Reference Model for Computing System Engineering Tool Interconnections. The core of this standard is the Semantic Transfer Language (STL), which describes concepts such as data, conditions, events, and states, as well as transformation, control-transition, and state-transition operations. This standard supports both textual and graphical forms.

CASE Data Interchange standards, such as the Electronics Industries Association's (EIA) CASE Data Interchange Format (CDIF), (eventually to become three ISO standards) for the exchange of information between CASEs. The three standards address: a framework standard, a syntax standard, and a semantic standard. When completed these standards will provide data interchange among CASE tools used in an integrated CASE environment.

3.2.1.1.2 Alternative specifications. No alternative specifications are known.

3.2.1.1.3 Standards deficiencies. Implementations of existing standards are scarce. PCTE has only two known environment implementations (TRANSTAR and PORTOS). A previous implementation of PCTE, Emeraude, is now called TRANSTAR. Many tools requiring encapsulation into the PCTE framework already exist and have been integrated into the UNIX environment. Customers using these tools and wanting to migrate into the PCTE world would have to encapsulate something that already has been integrated into a potential environment on the UNIX side. The latter would be an inefficient means of integrating a tool into the PCTE side of the house, despite the need for the existence of such (especially if the user already has these tools resident within his UNIX environment). The increased popularity of the CORBA specification may preclude PCTE usage and obviate the need for such.

3.2.1.1.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.2.1.1.5 Related standards. The following list contains additional references:

a. Reference Model for SEE Frameworks (NIST SP-500-211/ECMA TR/55).

b. Next Generation Computer Resources for Project Support Environments V2.0 (RM PSE) NIST SP-500-213.

c. Other related integrated software development services, such as A Tool Integration Standard (ATIS), have been proposed in the U.S., (by the CASE Integration Services Committee (CIS) working with ANSI), and Europe.

3.2.1.1.6 Recommendations. ANSI/IEEE 1209 is the recommended standard for CASE/software development, but additional definitions can be found in NIST SP 500-213. To ensure uniformity and consistency of service definitions between vendors, contractors, tools, integrators, etc., NIST SP 500-211, Reference Model for SEE Frameworks, is a technical report containing an extensive set of service descriptions and definitions for a SEE framework from which tools may be selected. The report presents consensus definitions of services and is intended to assist individuals in communicating and identifying information relative to SEE services for making comparisons, adjudicating differences in implementations, and resolving issues. It is recommended when defining framework and software engineering services. The document was developed with the participation from ECMA and DOD, with a corresponding version published by ECMA for the European community.

3.2.1.2 Reusable source code libraries. Emerging and maturing reusable source code libraries are collections of components that can be compiled for reuse on different machines with different applications. A number of government agencies and commercial enterprises are currently involved in reusable libraries. Use of the term library is intended to imply certification of the reusable components. Reusable components include models, design, architectural structures, requirements, code, documentation, and other reusable entity.

3.2.1.2.1 Standards. Table 3.2-2 presents standards for reusable source code libraries.

TABLE 3.2-2 Reusable source code libraries standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OMG

Object Management Group (OMG) Object Class Libraries

Object Management Group (OMG) Object Class Libraries

Informational

(Formative)

3.2.1.2.2 Alternative efforts. The following libraries are available:

a. DOD Reuse Libraries:

b. Commercial Reuse Libraries:

3.2.1.2.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.1.2.4 Portability caveats. This is a high portability risk area because no standards exist.

3.2.1.2.5 Related standards. Related standards are unknown. Reusable source code standards have yet to be developed. However, companion standards to software reuse are DOD-STD-498 and EIA/IEEE J-STD-016, since any reuse guidelines must be consistent with them. Furthermore, in the absence of formal, adopted standards, the following reuse guides and documents may be of assistance in addressing the reuse issues:

a. DOD Software Reuse Vision and Strategy, July 1992, DOD Technical Report 1222-04-210/40, NTIS Accession No. ADA 260109.

b. Glossary of Software Reuse Terms, NIST Special Publication 500-222, December 1992.

c. STARS ASSET Documents:

3.2.1.2.6 Recommendations. Standards on reuse libraries are emerging and lag behind other standards. Reuse libraries should be evaluated to identify components that meet functional requirements and are cost effective over the life of the system. Effective reuse of components can be achieved if early system life cycle requirements and domain analysis are performed to identify potential reuse components for inclusion into a repsoitory.

3.2.1.3 Specialized language and compiler tools. Specialized language and compiler tools are a collection of traditional operating system-based tools to update, maintain, and regenerate programs, develop system software, and provide sophisticated pattern matching functions.

Operating system-based software development tools are a collection of traditional tools to support standardized software development, maintenance, management, and version control.

3.2.1.3.1 Standards. Table 3.2-3 presents standards for specialized language and compiler tools.

TABLE 3.2-3 Specialized language and compiler tools standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Emerging

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (adopts ISO/IEC 9945-2:1993)

FIPS PUB 189:1994

Informational

(Approved)

NPC

IEEE

POSIX, Part 2: Shell and Utilities - (Additional Utilities)

P1003.2b

Emerging

(Draft)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.2.1.3.2 Alternative specifications. The following specifications are also available:

a. X/Open (formerly a USL specification): SVR4.

b. Berkeley 4.3 Unix.

c. GNU Tools, debuggers, other utilities, compilers, and specialized languages (programs from the Free Software Foundation).

d. BISON YACC PD work alike from GNU.

e. FLEX LEX PD work alike.

f. Mortice Kern Systems' LEX and YACC tools.

g. AFLEX and YACC (ACADIA PROJECT tools that generate Ada code).

h. OSF: OSF/1's "lint" (C language program checker), "m4" (Expand macro definitions), "ld" (Link editor for object files), "as" (Assembler).

3.2.1.3.3 Standards deficiencies. IEEE 1003.2/ISO/IEC 9945-2 lacks most of the programming language and compiler facilities present in XPG4, SVID, and OSF/1, such as the link editor ("ld"), macro definition expander ("m4"), the assembler ("as"), the C language program checker ("lint"), and the C program beautifier ("cb"). These utilities are important enough that most of them are supported by the consortia.

Operating system-based software development tool standards lack most traditional UNIX-based software development utilities. More than 40 of these software development utilities exist. IEEE1003.2 and 1003.2a combined support only seven utilities.

POSIX lacks the most important, most widely desired of the software development utilities -- the Source Code Control System (SCCS) for version control.

The SVID supports a large number of software development utilities not existing in X/Open or OSF/1.

3.2.1.3.4 Portability caveats. The IEEE 1003.2 standard method for calling the compiler to compile standard C programs is "c89" compared to the "cc" command traditionally used to call the compiler.

Incompatibility errors due to inconsistent data types may creep into programs and reduce their portability across different machines and with different applications because the IEEE 1003.2 standard does not support "lint," the traditional C language program data-type checker. Although C language program checkers may be bundled with different vendors' systems, user portability is reduced, because no standard interface exists for invoking or using these program checkers.

The POSIX "awk" utility differs from traditional awk implementations and specifications because of POSIX changes made to support internationalized programs.

The options specified in the IEEE 1003.2 "awk" are different from any specified by X/Open, the SVID, and OSF/1. X/Open and the SVID specify the same options, but these are not the same as those specified by OSF/1.

Most of the UNIX-based tools related to software development are licensed by AT&T, while the others are based on Berkeley UNIX and licensed from U.C. Berkeley. These tools are not necessarily compatible. The incompatibility almost always affects the interfaces and programmer portability, but does not necessarily affect source code portability.

3.2.1.3.5 Related standards. The NIST Integrated Software Engineering Environment (ISEE) reference model discusses operating system-based software development tools.

3.2.1.3.6 Recommendations. ISO/IEC 9945-2 as profiled by FIPS 189 is recommended for language and compiler tools.

3.2.2 Software life cycle processes. The standards listed below identify the software life cycle process. This is the process that begins when a software product is conceptualized and ends when the software is no longer available for use. It includes a set of activities, methods, practices, and transformations that are used to develop and maintain software and the associated products (e.g., project plans, design documents, code, test cases, and user manuals). The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and eventually the retirement phase.

3.2.2.1 Software life cycle. This section presents standards for the overall process rather than concentrating on single aspects of the cycle.

3.2.2.1.1 Standards. Table 3.2-4 presents standards for software life cycle processes.

TABLE 3.2-4 Software life cycle standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Software Life Cycle Processes

12207:1995

Adopted

(Approved)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

NPC

ANSI/IEEE

Developing Software Life Cycle Processes

1074:1992

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

GPC

DOD

Defense System Software Development

DOD-STD-2167A

Informational

(Superseded)

GPC

DOD

DOD Automated Information Systems (AIS) Documentation Standards

DOD-STD-7935A

Informational

(Superseded)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.2.1.2 Alternative specifications. No other specifications are known.

3.2.2.1.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.1.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.1.5 Related standards. The NIST ISEE reference model discusses operating system-based software development tools.

3.2.2.1.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

3.2.2.2 Software configuration management. (This BSA appears both in part 2 and part 9.) Configuration management is the process of applying administrative and technical procedures throughout the software life cycle to identity, define, and baseline configuration items for software in a system; control modifications and releases of the items; record and report the status of the items and modification requests; ensure the completeness and correctness of the items; and control storage, handling, and delivery of the items. This includes activities employed by the developer to identify entities (such as computer files, documents, Computer Software Configuration Items) whose version and status are to be tracked and controlled, to apply such controls, to keep records of these controls, and to audit that these controls are being applied.

3.2.2.2.1 Standards. Table 3.2-5 presents standards for software configuration management.

TABLE 3.2-5 Software configuration management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

NPC

EIA

National Consensus Standard for Configuration Management

IS-649

Adopted

(Approved)

NPC

ANSI/IEEE

Software Configuration Management

1042:1987

Informational

(Approved)

NPC

ANSI/IEEE

Software Configuration Management Plans

828:1990

Informational

(Approved)

GPC

NIST

Guideline for Software Documentation Management

FIPS PUB 105:1984

Informational

(Approved)

GPC

DOD

Configuration Management

MIL-STD-973(I3): 1995

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.2.2.2 Alternative specifications. The following additional guidance document is also available: Guidelines for Configuration Management (MIL-HDBK-761), although it is used with MIL-STD-973(I3): 1995, which will most likely be canceled.

3.2.2.2.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.2.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.2.5 Related standards. None.

3.2.2.2.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

3.2.2.3 Documentation standards. Documentation standards provide the process for recording information produced by a life-cycle process or activity. The process contains the set of activities that plan, design, develop, edit, distribute, and maintain those documents needed by managers, engineers, and users of the system or software for configuration management and system life cycle support.

3.2.2.3.1 Standards. Table 3.2-6 presents standards for documentation.

TABLE 3.2-6 Documentation standards standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

GPC

NIST

Guideline for Software Documentation Management

FIPS PUB 105:1984

Informational

(Approved)

IPC

ISO

Documentation Symbols and Conventions for Data, program and System Flowcharts, Program Network Charts, and System Resources Charts

5807:1985

Informational

(Approved)

IPC

ISO

Program Flow for Processing Sequential Files in Terms of Record Groups

6593:1985

Informational

(Approved)

NPC

IEEE

Software Test Documentation

829:1983

Informational

(Approved)

IPC

ISO

User Documentation and Cover Information for Consumer Software Packages

9127:1988

Informational

(Approved)

IPC

ISO

Program Constructs and Conventions for Their Representation

8631:1989

Informational

(Approved)

NPC

ANSI/IEEE

Recommended Practice for Software Design Descriptions

1016:1987

Informational

(Approved)

NPC

IEEE

Taxonomy for Software Engineering Standard

1002:1987

Informational

(Approved)

IPC

ISO

Guidelines for the Documentation of Computer-based Application Systems

6592:1985

Informational

(Approved)

NPC

ANSI/ANS

Guidelines for the Documentation of Digital Computer Systems

10.3:1986

Informational

(Approved)

NPC

IEEE

Software User Documentation

1063:1987

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

GPC

DOD

Defense System Software Development

DOD-STD-2167A

Informational

(Superseded)

GPC

DOD

DOD Automated Information Systems (AIS) Documentation Standards

DOD-STD-7935A

Informational

(Superseded)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

GPC

DOD

Defense System Software Quality Program

MIL-STD-2168

Informational

(Canceled)

3.2.2.3.2 Alternative specifications. No other specifications are known.

3.2.2.3.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.3.4 Portability caveats. Although they do not provide software portability, these standards can be used to facilitate program and design portability, as well as facilitating the development of user documentation.

3.2.2.3.5 Related standards. None.

3.2.2.3.6 Recommendations. The adopted standard is recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

3.2.2.4 Joint reviews. Joint reviews are processes or meetings involving representatives of both the acquirer and the developer, during which the developer presents the status and software products of a life-cycle activity or a phase of a project to the acquirer for comment and approval. Joint reviews are conducted at both the management and technical levels throughout the life of the contract.

3.2.2.4.1 Standards. Table 3.2-7 presents standards for joint reviews.

TABLE 3.2-7 Joint reviews standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

NPC

ANSI/IEEE

Software Reviews and Audits

1028:1988

Adopted

(Approved)

NPC

IEEE

Trial USE Standard for Applications and Management of the Systems Engineering Process

1220:1994

Informational

(Approved)

NPC

EIA

Systems Engineering

632:1994

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.2.4.2 Alternative specifications. No other specifications are known.

3.2.2.4.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.4.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.4.5 Related standards. None.

3.2.2.4.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

For other related information, consult ANSI/IEEE 1028.

3.2.2.5 Software requirements. Software requirements standards cover the creation, manipulation, and representation of requirements. They may include software capabilities, data elements, internal and external software interfaces, system software and hardware configuration items that communicate with software components, and system states and modes within which the specific software executes. A software requirement is a condition or capability that must be met by software that a user needs to solve a problem or achieve an objective.

3.2.2.5.1 Standards. Table 3.2-8 presents standards for software requirements.

TABLE 3.2-8 Software requirements standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

NPC

ANSI/IEEE

Software Requirements Specifications

830:1984

Adopted

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

GPC

DOD

Defense System Software Development

DOD-STD-2167A

Informational

(Superseded)

GPC

DOD

DOD Automated Information Systems (AIS) Documentation Standards

DOD-STD-7935A

Informational

(Superseded)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.2.5.2 Alternative specifications. No other specifications are known.

3.2.2.5.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.5.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.5.5 Related standards. None.

3.2.2.5.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

For other related information, consult ANSI/IEEE 830.

3.2.2.6 Software design. These software design standards provide the capability to capture, represent, create, analyze, and refine the design attributes of the software components of a system or subsystem. Their attributes can be the structure or functionality of the software or other characteristics such as user interface design or performance considerations. Software designs are typically dependent on a set of requirements. They describe interrelationships of software components, including interfaces, invocation parameters, data elements, and the states and modes within which the specific software sub-components execute. The outcome of the software design includes definition of the software components and subcomponents.

3.2.2.6.1 Standards. Table 3.2-9 presents standards for software design.

TABLE 3.2-9 Software design standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

NPC

IEEE

Guide for Software Design Descriptions

1016.1:1993

Informational

(Approved)

NPC

ANSI/IEEE

Recommended Practice for Software Design Descriptions

1016:1987

Informational

(Approved)

NPC

ANSI/IEEE

Recommended Practices for Ada as a Program Design Language

990:1987

Informational

(Approved)

GPC

DOD

Defense System Software Development

DOD-STD-2167A

Informational

(Superseded)

GPC

DOD

DOD Automated Information Systems (AIS) Documentation Standards

DOD-STD-7935A

Informational

(Superseded)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.2.6.2 Alternative specifications. No other specifications are known.

3.2.2.6.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.6.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.6.5 Related standards. None.

3.2.2.6.6 Recommendations. The adopted standard is recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

3.2.2.7 Software management indicators. (This BSA appears both in part 2 and part 9.) Software management indicators aid in managing the software development process. Various measurements of both software products and software processes are available. Product measures(such as lines of code, function points, etc.) are often associated with the product specification and should be used as management indicators throughout the product life cycle. Process measures(such as software trouble reports) should be tracked to determine whether the software development process is within statistical control limits. Key indicators should be identified in the software development plan, and the developer should then collect, analyze, interpret, take corrective actions, and report on the selected key management indicators.

3.2.2.7.1 Standards. Table 3.2-10 presents standards for software management indicators.

TABLE 3.2-10 Software management indicators standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

IPC

ISO/IEC

Quality Characteristics and Guidelines for Their Use

9126:1991

Adopted

(Approved)

NPC

IEEE

Use of Standard Measures to Produce Reliable Software

982.2:1988

Informational

(Approved)

NPC

IEEE

Standard Dictionary of Measures to Produce Reliable Software

982.1:1988

Informational

(Approved)

NPC

IEEE

Software Productivity Metrics

1045:1992

Informational

(Approved)

NPC

IEEE

Software Quality Metrics Methodology

1061:1992

Informational

(Approved)

IPC

ISO/IEC

Software Life Cycle Processes

12207:1995

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.2.7.2 Alternative specifications. For additional metrics information, consult the following documents:

a. Metrics for I-CASE Pilot Project (MIPP) Program, Metrics Reporting Guidebook, (prepared by Mitre Corporation, 27 May 1994, for DISA/JIEO/CIM/TXEM).

b. Practical Software Measurement: A Guide to Objective Program Insight, Draft 12 April 1995.

c. Streamlined Integrated Software Metrics Approach (SISMA) Guidebook; Application of STEP Metrics, (prepared by Software Productivity Solutions, Indialantic, FL 32903, 12 July 1993, for the U.S. Army).

d. Software Measurement Guidebook, (prepared by the Software Productivity Consortium Services Corporation, December 1992, Herndon VA, for DARPA).

3.2.2.7.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.7.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.7.5 Related standards. Related software management guidance can be found in the Software Engineering Institute's Capability Maturity Model (CMM). The Software Engineering Institute's CMM provides guidance on how to gain control of the software development and maintenance processes. The CMM has defined an evaluation procedure, the CMM Based Appraisal (CBA), as a means of identifying the risks associated with potential contractor performance. Diagnostic tools based on the CMM have been deployed. One of those tools, the Software Capability Evaluation(SCE), is designed to be used by an acquiring organization to either identify process risks associated with a particular proposal during the source selection or to monitor the risk-reducing process improvements during the contract execution.

3.2.2.7.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. MIL-STD-498 contains requirements for security and privacy for software development and documentation. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

For other related information, consult ISO/IEC 9126. Appropriate standards should be selected based on software metrics requirements.

3.2.2.8 Software testing and product evaluation. Software testing and evaluation standards support the test and evaluation of software systems. Testing is performed on individual software components (unit testing), on collections of software components (integration testing), and on complete software systems (system testing). Evaluation includes in-process software evaluation, final software product evaluation, and independent evaluation activities to ensure the functional completeness of the configuration items against their requirements and the physical completeness of the configuration items (whether its design and code reflect an up-to-date technical description).

3.2.2.8.1 Standards. Table 3.2-11 presents standards for software testing and product evaluation.

TABLE 3.2-11 Software testing and product evaluation standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

NPC

ANSI/IEEE

Software Verification and Validation Plans

1012:1987

Adopted

(Approved)

NPC

ANSI/IEEE

Software Test Documentation

829:1983 (R1991)

Adopted

(Approved)

NPC

ANSI/IEEE

Software Unit Testing

1008:1987

Adopted

(Approved)

NPC

IEEE

Guide for Software Verification and Validation Plans

1059:1993

Informational

(Approved)

GPC

NIST

Guide for Verification and Validation Plans (Adopts ANSI/IEEE 1012:1987)

FIPS PUB 132:1987

Informational

(Approved)

IPC

ISO/IEC

Software Life Cycle Processes

12207:1995

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

GPC

DOD

Defense System Software Development

DOD-STD-2167A

Informational

(Superseded)

GPC

DOD

DOD Automated Information Systems (AIS) Documentation Standards

DOD-STD-7935A

Informational

(Superseded)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.2.8.2 Alternative specifications. No other specifications are known.

3.2.2.8.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.8.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.8.5 Related standards. None.

3.2.2.8.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

For other related information, consult ANSI/IEEE 829, ANSI/IEEE 1008, and ANSI/IEEE 1012.

3.2.2.9 Software quality assurance. Software quality assurance standards provide a planned and systematic pattern of all actions necessary to provide adequate confidence that a software work product conforms to established technical requirements. Further, it provides a set of activities designed to evaluate the process by which software work products are developed and maintained.

3.2.2.9.1 Standards. Table 3.2-12 presents standards for software quality assurance.

TABLE 3.2-12 Software quality assurance standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

IPC

ISO

Model for Quality Assurance in Design, Development, Production, Installation and Servicing

9001:1994

Adopted

(Approved)

NPC

ANSI/IEEE

Software Quality Assurance Plans

730.1:1989

Adopted

(Approved)

IPC

ISO

Quality Management and Quality Assurance Standards - Part 3: Guidelines for Application of ISO 9001 to the Development, Supply and Maintenance of Software

9000-3:1991 (Corrected and Reprinted - 1993)

Adopted

(Approved)

NPC

IEEE

Software Quality Management Systems, Part 1: Requirements

1298:1992

Adopted

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

GPC

DOD

Defense System Software Development

DOD-STD-2167A

Informational

(Superseded)

GPC

DOD

DOD Automated Information Systems (AIS) Documentation Standards

DOD-STD-7935A

Informational

(Superseded)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

GPC

DOD

Defense System Software Quality Program

MIL-STD-2168

Informational

(Canceled)

3.2.2.9.2 Alternative specifications. No other specifications are known.

3.2.2.9.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.9.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.9.5 Related standards. None.

3.2.2.9.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

For other related information, consult ANSI/IEEE 730, ISO 9001, ISO 9000-3 and IEEE 1298.

3.2.2.10 Software problem categories/priorities. These standards provide the developer with a structured format to prepare a corrective action and process improvement system for software development. They also provide a procedure for handling all problems detected and changes recommended in development products after they have been released for software product evaluation. This includes the classification by category and priority of such problems.

3.2.2.10.1 Standards. Table 3.2-13 presents standards for software problem categories and priorities.

TABLE 3.2-13 Software problem categories/priorities standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

NPC

IEEE

Classification for Software Anomalies

1044:1993

Adopted

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

GPC

DOD

Defense System Software Development

DOD-STD-2167A

Informational

(Superseded)

GPC

DOD

DOD Automated Information Systems (AIS) Documentation Standards

DOD-STD-7935A

Informational

(Superseded)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.2.10.2 Alternative specifications. No other specifications are known.

3.2.2.10.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.10.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.10.5 Related standards. None.

3.2.2.10.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

For other related information, consult ANSI/IEEE 1044.

3.2.2.11 Software safety. (This BSA appears in both Part 2: Software Engineering and Part 9: System Management.) These standards provide procedures for identifying as safety-critical those CSCIs or portions thereof whose failure could lead to a hazardous system state (one that could result in death, injury, loss of property, or environmental harm). The developer shall develop a safety assurance strategy, including both tests and analyses, to assure that the requirements, design, implementation, and operating procedures for the identified software minimize or eliminate the potential for hazardous conditions. The objective is to eliminate hazards, and reduce the associated risk to a level of acceptability to the managing activity.

3.2.2.11.1 Standards. Table 3.2-14 presents standards for software safety.

TABLE 3.2-14 Software safety standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

System Safety Program Requirements

MIL-STD-882C: 1996

Adopted

(Approved)

NPC

IEEE

Software Safety Plans

1228:1994

Informational

(Approved)

3.2.2.11.2 Alternative specifications. No other specifications are known.

3.2.2.11.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.11.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.11.5 Related standards. None.

3.2.2.11.6 Recommendations. MIL-STD-882C is recommended.

3.2.2.12 Software support. The standards listed below identify those activities that take place to ensure that software installed at user sites continues to perform as intended and fulfill its intended role in system operation. Software support includes software maintenance, aid to users, and related activities.

3.2.2.12.1 Standards. Table 3.2-15 presents standards for software support.

TABLE 3.2-15 Software support standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

NPC

IEEE

Software Maintenance

1219:1993

Adopted

(Approved)

GPC

NIST

Guideline on Software Maintenance

FIPS PUB 106:1984

Informational

(Approved)

GPC

DOD

Mission Critical Computer Resources Software Support

MIL-HDBK-347:1990

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.2.12.2 Alternative specifications. No alternate specifications are known.

3.2.2.12.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.2.12.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.2.12.5 Related standards. MIL-HDBK-347, Mission- Critical Computer Resources Software Support, provides related information.

3.2.2.12.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

For other related information, consult ANSI/IEEE 1219.

3.2.2.13 Software distribution. (This BSA appears both in part 2 and part 9.) Software distribution and installation services comprise utilities for packaging, installing, and distributing software for use on heterogeneous and potentially incompatible systems. These services will enable network managers to transmit software to any stand-alone or networked system, regardless of the media used for distribution. Standards for software distribution in a system provide a standardized layout for distributing and installing software in a single system or network. They explicitly define each phase of software distribution, installation, and configuration--covering such distribution media as disks, tapes, and CD-ROM.

3.2.2.13.1 Standards. Table 3.2-16 presents standards for software distribution.

TABLE 3.2-16 Software distribution standards

Standard TypeStandard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX System Administration - Part 2: Software Administration (former P1003.7.2)

1387.2:1995

Adopted

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170)

T908: 1995

Emerging

(Approved)

CPC

X/Open

Systems Management: Distributed Software Administration (XDSA)

P429:1997

Informational

(Approved)

3.2.2.13.2 Alternative specifications. The following specifications are also available:

a. Hewlett-Packard: "swinstall" and "swpackage" systems.

b. USG: SVR4-based "pkgadd" system.

c. Santa Cruz Operation (SCO): "custom+" system.

3.2.2.13.3 Standards deficiencies. IEEE 1387.2 does not provide for acting upon log files in remote file systems. No Ada bindings are available for software distribution standards.

3.2.2.13.4 Portability caveats. Although the IEEE 1387.2 standard is based on Hewlett-Packard's "swinstall" and "swpackage" systems, the standard has modified the specifications so that they are not exactly like the HP systems.

3.2.2.13.5 Related standards. The following standards are related to software distribution or software distribution standards:

a. ISO/IEC JTC1 IS 9595:1991: Common Management Information Service (CMIS).

b. ISO/IEC JTC1 IS 9596:1991: Common Management Information Protocol (CMIP).

c. ISO/IEC IS 11578: 1996, Information Technology - Open Systems Interconnection - Remote Procedure Call (RPC).

d. Internet RFC 1155 (STD 17): Structure and Identification of Management Information for TCP/IP-based Internets.

e. Internet RFC 1157 (STD 15): A Simple Network Management Protocol.

f. Internet RFC 1213 (STD 17): Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

g. Network Management Forum: OMNIPoint 1.

3.2.2.13.6 Recommendations. IEEE 1387.2 is recommended.

A new version of the X/Open Single UNIX Specification (Spec. 1170) is expected to be issued in 1997.

3.2.2.14 Software license management. (This BSA appears in both part 2 and part 9.) License management addresses the problem of tracking software licenses in a distributed systems environment. The DME licensing technology includes models that assist users in keeping track of how many software copies are needed and who is using it once it is purchased. Software license management for a system provides license administration, monitoring, and enforcement services that allow more detailed, firm and equitable licensing terms for users, and better protection against illegal software usage for vendors.

3.2.2.14.1 Standards. Table 3.2-17 presents standards for software license management.

TABLE 3.2-17 Software license management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX System Administration - Part 2: Software Administration (former P1003.7.2)

1387.2:1995

Adopted

(Approved)

CPC

X/Open

Systems Management: Distributed Software Administration (XDSA)

P429:1997

Informational

(Approved)

CPC

OSF

Distributed Management Environment (DME): License Management (LM) Service

DME LM

Informational

(Historic (Not recommended))

3.2.2.14.2 Alternative specifications. The following specifications are also available:

a. Hewlett-Packard: Network License System (NetLS) Version 2.0 on which OSF's DME License Management System (LS) is based.

b. Gradient Technologies: PC Client libraries for license management and PC Ally server, on which DME's License Management PC component is based.

3.2.2.14.3 Standards deficiencies. No Ada bindings exist for any of the configuration management standards or consortia specifications.

3.2.2.14.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.2.2.14.5 Related standards. The following standards are related to license management or license management standards:

a. ISO/IEC JTC1 IS 9595:1991: Common Management Information Service (CMIS).

b. ISO/IEC JTC1 IS 9596:1991: Common Management Information Protocol (CMIP).

c. ISO/IEC IS 11578: 1996, Information Technology - Open Systems Interconnection - Remote Procedure Call (RPC).

d. Internet RFC 1155 (STD 17): Structure and Identification of Management Information for TCP/IP-based Internets.

e. Internet RFC 1157 (STD 15): A Simple Network Management Protocol.

f. Internet RFC 1213 (STD 17): Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

g. Network Management Forum: OMNIPoint 1.

3.2.2.14.6 Recommendations. IEEE 1387.2 is recommended.

3.2.3 Programming languages. Programming languages include all languages represented by the ISO, the European Computer Manufacturers' Association (ECMA), the International Electrotechnical Commission (IEC), the American National Standards Institute (ANSI), the IEEE, NIST, or DOD standards, as well as those used by DOD but not represented by standards. Quotes regarding the number of languages used by DOD range from 50 to 300; however, this volume only includes languages playing major roles in DOD systems and those supporting DOD-Wide goals of economy, interoperability, and portability.

Certification of conformance to the source language specification results in a higher degree of portability across platforms for all languages. Test suites to validate source language standards conformance are available from the NIST, the IEEE, and the Ada Joint Program Office (AJPO). Specific conformance test suites will be addressed for each language covered in this document.

3.2.3.1 Programming language framework. Coverage of language standards is currently limited to those Higher Order Languages (HOL) deemed to represent the majority of Commercial Off The Shelf (COTS) and custom applications used within the DOD. The relevant standards will be listed along with coverage of Standards Deficiencies, Portability Caveats, Tailoring Guidance, Alternative Specifications, Related Standards, and Recommendations for use.

Public Law (PL) 102-172 states, "Notwithstanding any other provisions of law, after 1 June 1991, where cost effective, all Department of Defense software shall be written in the programming language Ada, in the absence of special exemption by an official designated by the Secretary of Defense." The Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASD/C3I) has been designated as the DOD Ada Waiver review authority, with some responsibilities delegated to the services and the Defense Intelligence Agency. (ASD(C3I) Memorandum, 17 April 1992, "Delegations of Authority and Clarifying Guidance on Waivers from the Use of the Ada Programming Language") Software used by the DOD includes Commercial Off-the-Shelf (COTS), Government Off-the-Shelf (GOTS), and new DOD-developed software. New DOD-developed software includes custom applications as well as software to integrate COTS and GOTS. Ada is the preferred software development language for all new and revised DOD-developed software.

3.2.3.1.1 Standards. Table 3.2-18 presents standards for programming languages.

TABLE 3.2-18 Programming language framework standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Ada (Adopts ANSI/ISO/IEC 8652: 1995)

FIPS PUB 119-1: 1995

Adopted

(Approved)

NPC/IPC

ANSI/ISO/IEC

Ada-95

8652:1995

Adopted

(Approved)

GPC

NIST

Pascal (Adopts ANSI/IEEE 770 X3.97-1983/R1990)

FIPS PUB 109:1985

Informational

(Approved)

GPC

NIST

MUMPS (Adopts ANSI/MDC X11.1-1990)

FIPS PUB 125-1:1993

Informational

(Approved)

GPC

NIST

BASIC (ANSI X3.113-1987/R1993, reflects major changes, improvements and additions to the BASIC specifications.)

FIPS PUB 68-2:1987/R1993

Informational

(Approved)

GPC

DOD (USAF)

JOVIAL (J73)

MIL-STD-1589C: 1996

Informational

(Approved)

IPC

ISO/IEC

Ada

8652:1987

Informational

(Approved)

NPC/IPC

ANSI/ISO

Programming Languages: C

9899:1992

Informational

(Approved)

GPC

NIST

C (Adopts ANSI/ISO/IEC 9899:1992)

FIPS PUB 160:1992

Informational

(Approved)

IPC

ISO

FORTRAN-90

1539:1991

Informational

(Approved)

NPC

ANSI

FORTRAN-77

X3.9-1978 (R1989)

Informational

(Approved)

NPC

ANSI

COBOL

X3. 23: 1993

Informational

(Approved)

NPC

ANSI/IEEE

Pascal

770X3.97-1983 (R1990)

Informational

(Approved)

IPC

ISO

Pascal

7185:1983

Informational

(Approved)

NPC

ANSI

COBOL

X3. 23a: 1989

Informational

(Approved)

GPC

NIST

COBOL (adopts ANSI X3.23a: 1989 and X3.23b: 1993)

FIPS PUB 21-4:1995

Informational

(Approved)

GPC

DOD (AJPO)

Ada Programming Language

MIL-STD-1815A:1983

Informational

(Approved)

IPC

ISO/IEC

C++

SC22 WG22, X3J16

Informational

(Draft)

NPC

ANSI/X3J13

Common LISP (X3.226 Programming Language Common LISP)

X3J13/92-101

Informational

(Draft)

GPC

NIST

Ada

FIPS PUB 119:1985

Informational

(Superseded)

3.2.3.1.2 Alternative specifications. Although many language standards exist other than HOLs listed above, the coverage of languages in this document is limited to those HOLs that represent the most significant percentage of DOD applications.

3.2.3.1.3 Standards deficiencies. Each programming language has its own strengths and weaknesses. Details containing specific language strengths and weaknesses are contained in language rationale, comparison documents, and dissertations external to the standards and this document.

3.2.3.1.4 Portability caveats. Despite the existence of programming language standards, each vendor and platform implementation may contain features not included in the standard. Furthermore, conformance to the standard generally is neither verified nor regulated by the standards community. Therefore, portability of applications written in a specific language depends upon these factors:

a. The extent of conformance of a particular implementation to the standard.
b. The range of operating systems for implementations of the language.
c. The range of hardware suites for implementations of the language.

In all cases, the extent to which application programmers employ nonstandard features is a major factor in determining portability across platforms. Portability across languages also is affected by the factors mentioned, because translation from one source language to another requires more human-intensive effort if nonstandard features are employed. In addition, different source languages often provide different mechanisms for abstracting data and operating on data, and employ different approaches toward interaction with the operating system and hardware. For this reason, when transitioning from any source language to another, reverse engineering from the current specifications is preferred over simple source code translation.

3.2.3.1.5 Related standards. A number of standards exist or are in the definition process for Ada bindings to other components of open systems. Section 3.2.4.1 includes a table which lists these standards.

3.2.3.1.6 Recommendations. The adopted standards are recommended. The following order of preference applies to developing or modifying DOD software applications:

a. Reuse existing government-owned code without modification where significant savings in maintenance and development can be identified.

b. Use COTS software that is conformant with DOD-adopted standards without modifications, where significant savings in maintenance costs can be documented, although DOD will not maintain COTS software.

c. Modify existing Ada code.

d. Develop new code using Ada. Develop or modify non-Ada legacy code.

If a COTS software product is being procured, rather than a software product being developed, the programming language used by the developer of the COTS product is not of vital concern, unless it is expected the COTS product will be included as part of another application. If the COTS software will be incorporated into a larger application, one must carefully consider the extent of dependency upon the COTS-provided functions and have an understanding of the options in the event the vendor terminates support for the application.

3.2.3.2 Ada. Ada is a general purpose and systems programming language designed with an emphasis on reliability, readability, and maintainability. Originally intended for embedded, real-time systems development, use of Ada has extended into the MIS community and is appropriate for a broad range of applications areas. Ada is a language that enforces modern software engineering principles of data abstraction, information hiding, and modularity. Ada supports reusability though several features of the language: explicit support for program units; separation of interface specifications from the hidden body; strong, user definable typing of data and operators; overloading of function and procedure names; and generic units to supply parameterized code templates. The Ada standard (Ada-95) brings the language into line with newer software engineering concepts including extensions to improve support for real-time systems, object-oriented features, and mega-programming.

3.2.3.2.1 Standards. Table 3.2-19 presents standards for Ada.

TABLE 3.2-19 Ada standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Ada (Adopts ANSI/ISO/IEC 8652: 1995)

FIPS PUB 119-1: 1995

Adopted

(Approved)

NPC/IPC

ANSI/ISO/IEC

Ada-95

8652:1995

Adopted

(Approved)

IPC

ISO/IEC

Ada

8652:1987

Informational

(Approved)

GPC

DOD (AJPO)

Ada Programming Language

MIL-STD-1815A:1983

Informational

(Approved)

GPC

NIST

Ada

FIPS PUB 119:1985

Informational

(Superseded)

3.2.3.2.2 Alternative specifications. No other specifications are known.

3.2.3.2.3 Standards deficiencies. The most significant deficiencies in Ada-83 which have been addressed by Ada-95 are the inclusion of objects into the language, a more robust treatment of tasking, more flexible response to interrupts, an explicit definition of higher mathematical functions, and the explicit inclusion of bindings to other languages. All documented deficiencies in the Ada-83 standard are included in the Ada-95 Project Report, which is available through the Ada Information Clearinghouse.

3.2.3.2.4 Portability caveats. Within the limits of the features tested under the ACVC, Ada source code is completely portable across all compilers and hardware/operating system platforms. Portability problems will be more likely to exist when changing compiler vendors than when moving across platforms supported by a single compiler vendor. In particular, vendor-to-vendor portability problems can result from the use of Ada language components which are specified as implementation dependent (e.g., PRAGMAs). Special purpose libraries (e.g., support for DOS functionality) also are a major source of portability problems. In general, automated source translation software exists to resolve the major portion of these remaining incompatibilities. Efforts are underway to increase the depth and breadth of future releases of the ACVC so as to further reduce compiler and platform dependencies.

3.2.3.2.5 Related standards. SPC-91061-N, Ada Quality and Style: Guidelines for Professional Programmers, Version 2.01.01, 1991, is related to Ada. Similar to other programming languages, Ada style guides are desirable for their contribution to the quality and consistency of Ada code. The AJPO has endorsed this Software Productivity Consortium (SPC) publication as a suggested Ada Style Guide for DOD programs. This guide, available from the Ada Joint Program Office, contains more information on the handling of implementation-dependent features.

3.2.3.2.6 Recommendations. The use of the Ada (ANSI/ISO/IEC 8652: 1995, as adopted by FIPS PUB 119-1: 1995)) programming language (Ada-95) is mandated for new procurement. (See section 3.2.3.2 for details). Initially, there may be productivity limitations due to the absence of bindings and support tools for Ada-95. Transition of software from Ada-83 will not be required unless the availability of Ada-83 compilers becomes a problem or additional functionality supported by Ada-95 is required by the target system.

Implementation-defined features and other features which are not standard to the Ada programming language must be avoided. The Ada Quality and Style: Guidelines for Professional Programmers, available from the AJPO, contains more information on the handling ofimplementation-dependent features. This guideline can be used as a tailoring reference for many of the areas discussed in the following sections about Ada.

Although upward compatibility was a major design consideration for Ada-95, incompatibilities are likely between Ada-83 and Ada-95. When considering the transition to Ada-95, the Ada-83 system design and implementation should be assessed in view of the final documented incompatibilities. Discrepancies between Ada-83 and Ada-95 have been identified and suggested coding practices and source code modifications have been identified and tested, allowing recompilation of existing Ada-83 code by Ada-95 compilers. Information on these coding practices can be found in the Ada Style Guide and the Ada-95 Project Report, both available from the AJPO. A comprehensive transition to Ada-95 cannot be undertaken until Ada-95 compilers pass validation testing.

Despite these limitations, the ASD C3I in a Memorandum of 9 March 1994, encourages early use of Ada9X (Ada-95). The use of available unvalidated Ada-95 compilers is encouraged. Unvalidated Ada-95 compilers may be used for:

a. Research and development programs (6.1, 6.2, and 6.3A appropriations).

b. Proof of concept prototypes, so long as any subsequent system is delivered using validated Ada-95 compilers.

c. System development programs, so long as the systems are delivered using validated Ada-95 compilers, in accordance with the validation procedures issued by the AJPO.

Early use of Ada-95 provides access to the language's many enhancements, including full support for object-oriented programming, enhancements for realtime programming, and interfacing to other languages.

In systems where COTS software is to be used extensively, the amount of non-COTS code to be developed and the interfaces to the COTS software need to be considered when evaluating the long-term cost/benefits of using another HOL versus Ada as a development language. In most cases, developing Ada links to existing bindings has proven to be an effective development method. Furthermore, in applications where concurrent processing is required, the inherent implementation of concurrent methods by Ada is preferable to another HOL, since concurrent processing in other HOLs is handled often by invoking operating system calls. The concurrency methods in Ada are independent of the operating system.

3.2.3.3 C, C++. C is a systems programming language which has been adopted for widespread use as a general purpose language in developing commercial applications. C is a relatively "low level" language which deals with basic computer objects, such as characters, numbers, and addresses, and does not inherently provide operations to deal with composite objects, such as strings, sets, lists. Library units have been added to the language to partially support functionality of such objects. ANSI C is strongly typed and is an implicitly integer language, i.e., untyped functions and variables are assumed to be integer. The popularity of C derives from its support for low level control and interaction with peripherals and the operating system, the highly efficient code which is generated by modern C compilers, and the wide availability of such compilers.

C++ is an Object-Oriented Programming (OOP) superset of the C language. Existing C context is fully supported by C++ compilers, with additional support for data abstraction, encapsulation, object classes, inheritance (and multiple inheritance), polymorphism, and overloading. While considered a general purpose language, its core area of application is systems programming. C++ was developed to encourage good software engineering practice and the development of reuse libraries in the development of larger applications.

3.2.3.3.1 Standard. Table 3.2-20 presents standards for C.

TABLE 3.2-20 C, C++ standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC/IPC

ANSI/ISO

Programming Languages: C

9899:1992

Adopted

(Approved)

GPC

NIST

C (Adopts ANSI/ISO/IEC 9899:1992)

FIPS PUB 160:1992

Adopted

(Approved)

IPC

ISO/IEC

C, Amendment 1: Integrity Addendum

9899:1994 PDAM

Informational

(Draft)

IPC

ISO/IEC

C++

SC22 WG22, X3J16

Informational

(Draft)

3.2.3.3.2 Alternative specification. The original definition of the C language by Kernighan & Ritchie (K&R) is considered by many as "THE" specification of the C language. This specification is NOT coincident with the ANSI/ISO/IEC standard.

3.2.3.3.3 Standard deficiencies. While there is an existing ISO standard for the C language that supports and is supported by the IEEE 1003.1 C Language Binding to POSIX, the intrinsically low level nature of C and lack of direct support for modern software engineering approaches and discipline make it an undesirable language for the development of large, general purpose DoD software applications. C can offer benefits when used specifically for systems level programming, when required for especially compact or efficient code, or when used at an interfacing level where direct bindings to high level languages do not exist. The use of C in general purpose applications is often justified by a large population of "trained" C programmers; however, useful C code on large projects can only be developed by those few, highly self-disciplined, virtuoso, software engineers.

C++ is an emerging language with no current standard, although AT&T's Bell Labs, where the language originated and where development has continued, have produced defining documentation for the language, including The C++ Programming Language by Bjarne Stroustrup, one of the principal developers of the language. The lack of a current compiler standard makes C++ source code portability problematic. This is further complicated by the current popularity of C++ in the development of Graphical User Interface (GUI) based applications, which rely heavily on compiler vendor-specific interface libraries. Because the mechanics of the C language are embedded in C++, it is susceptible to many of the above noted difficulties with C, despite the introduction of OOP software engineering into the language.

3.2.3.3.4 Portability caveats. Differences between ANSI C and K&R C can be significant and can affect portability. Furthermore, the lack of a current compiler standard makes C++ source code portability problematic.

3.2.3.3.5 Related standards. No related standards to C or C++ are known.

3.2.3.3.6 Recommendations. ANSI/ISO/IEC 9899:1992 and FIPS PUB 160:1992 are the recommended standards for legacy systems written in C and C++ languages. Use of C++ for the development of critical systems applications is not recommended.

3.2.3.4 FORTRAN. FORTRAN, which is an acronym for FORMula TRANslating system, is a programming language originated in 1954 and designed to support scientific and engineering applications requiring calculation-intense computing. FORTRAN is the oldest surviving HOL and existing applications may have been developed in several dialects of the language: FORTRAN IV dates to 1962 and was standardized in 1966 (sometimes called FORTRAN 66) due to the large number of non-portable variants of FORTRAN IV which had been developed; FORTRAN 77 was a major extension to FORTRAN which introduced C and Pascal control structures into the language to limit the FORTRAN "spaghetti code" problem; and FORTRAN 90 is a further extension to the language to include flexible, modern data structures into FORTRAN. Most FORTRAN legacy programs have been developed under FORTRAN IV and FORTRAN 77. FORTRAN 90 has not gained wide spread acceptance within the FORTRAN programming community.

FORTRAN supports data typing by providing primarily numeric data types (INTEGER, REAL, DOUBLE PRECISION, COMPLEX), LOGICAL, and CHARACTER to support characters and strings (as arrays of CHARACTERs). Through FORTRAN 77, arrays were the only composite data type supported. More advanced data types are supported in the FORTRAN 90 standard. FORTRAN 77 does not support dynamic data structures or address pointers. I/O library by FORTRAN includes extensive I/O capabilities explicitly in the definition of the language. Additionally, a standard defining a FORTRAN 77 binding to POSIX has been developed by the IEEE as the 1003.9 standard. FORTRAN has explicit support for high level mathematical functionality, unlike C and Ada, where mathematical library units are defined externally to the base language. Basic logical operations are fully supported in FORTRAN. The LOGICAL type is functionally equivalent to the Boolean type in Ada. The "ELSE" construct was not supported in FORTRAN prior to FORTRAN 77. A CASE or SWITCH logical control mechanism is not supported in FORTRAN. Fixed point arithmetic is not explicitly supported in FORTRAN. Floating point is supported though the REAL and DOUBLE PRECISION types. FORTRAN supports implicit typing of REAL and INTEGER variables. Timing functionality, either simple or for concurrent operation, is not supported by FORTRAN. FORTRAN contains no object-oriented capabilities, though work in this area is being pursued by ANSI.

FORTRAN is included in the ITSG discussion of programming languages in deference to the large amount of available legacy engineering and scientific software written in the language.

3.2.3.4.1 Standards. Table 3.2-21 presents standards for FORTRAN.

TABLE 3.2-21 FORTRAN standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

ANSI

FORTRAN-90

X3.198-1992

Adopted

(Approved)

IPC

ISO

FORTRAN-90

1539:1991

Adopted

(Approved)

GPC

NIST

FORTRAN-77 (adopts ANSI X3.9)

FIPS PUB 69-1: 1985

Adopted

(Approved)

NPC

ANSI

FORTRAN-77

X3.9-1978 (R1989)

Adopted

(Approved)

NPC

ANSI

Object FORTRAN

TBD

Informational

(TBD)

3.2.3.4.2 Alternative specifications. The so-called "VAX Extensions" to FORTRAN 77 are widely supported. The IBM Systems Application Architecture (SAA) FORTRAN binding to SQL is also available, but is proprietary.

3.2.3.4.3 Standards deficiencies. FORTRAN 90 has not gained widespread acceptance in the FORTRAN programming community. Vendors have selectively implemented FORTRAN 90 attributes into their compilers. The few existing FORTRAN bindings to OSE component sub-systems are based upon FORTRAN 77. FORTRAN 77 does not supply a fully modern set of data types, control statements, and modularity support. In FORTRAN, the EQUIVALENCE statement can be used to break explicit typing of data.

Because of the nature of the language, the IEEE 1003.9 specification of the FORTRAN binding to POSIX is less stringent and more vendor and implementation dependent than IEEE 1003.1 and 1003.5 (C and Ada bindings, respectively).

3.2.3.4.4 Portability caveats. Older versions of FORTRAN, particularly FORTRAN IV, exhibit many portability problems, hence, the advent of FORTRAN 77. Legacy software written in versions of FORTRAN earlier than FORTRAN 77 can be expected to be difficult to port between platforms or operating systems. Modern compilers have been selective in "choosing" features of FORTRAN 90 to implement. This can cause obvious portability difficulties.

Numeric precision of REAL and DOUBLE PRECISION data types has been a historical trouble spot for porting of FORTRAN source code between platforms. The FORTRAN 77 standard addresses this problem. However, older FORTRAN IV applications may still exhibit these problems.

The use of special features for I/O, such as I/O handling features specific to the hardware, compiler or operating system, can lead to portability problems. FORTRAN IV legacy software can contain OS specific I/O.

Portability of FORTRAN across different operating system and hardware suites is subject to errors brought about by differences between FORTRAN compiler implementations and hardware/operating system internal numerical representations.

3.2.3.4.5 Related standards. Other than the standards referenced above, there are no other standards applicable to FORTRAN for compiler or user-defined data typing. The only standard related to math functions is the IEEE 754 floating point standard.

3.2.3.4.6 Recommendations. ISO1539:1991/ANSI X3.198:1992 and NIST FIPS PUB
69-1/ANSI X3.9:1978 (R1989) are the recommended standards for FORTRAN-based legacy systems. NIST FIPS PUB 69-1 is the recommended standard for legacy FORTRAN development. FORTRAN has been used traditionally for scientific processing. Although FORTRAN-90 contains added capability over FORTRAN-77, it does not contain any capabilities making it preferable to Ada for DOD applications. FORTRAN should not be chosen for the development of new DOD applications and should be used only to maintain legacy software. I/O based on the IEEE 1003.9 specified library is preferred for OSE systems.

3.2.3.5 COBOL. COBOL, an acronym for COmmon Business Oriented Language, is a programming language for use in financial and accounting applications. Created during the early 60s, COBOL is the most widely used language for data processing applications and has an extensive software legacy. It was intended as a design for a common language that would enable programs and programming techniques to be easily shared and transferred between machines. Despite this design goal, COBOL programs are verbose and not truly self documenting, and are difficult to maintain and tend toward "bugginess." COBOL is strictly for data processing applications and has no role as a more general language.

Only two types of variables are recognized by COBOL, numeric and non-numeric. Arrays and records are supported via the COBOL table and record description entry constructs. Dynamic structures are not supported. COBOL has a strong set of file manipulation functions for data processing applications. These functions are intrinsic to the language. COBOL supplies a minimal set of logical and mathematical operations. No advanced mathematical functions are supported. Logical variables are supported in COBOL via testable conditions. IF - ELSE control and relational test operators are supplied. Basic mathematical operations to support financial calculations are supported by COBOL. COBOL is not a real time language. It supports neither simple nor complex (e.g., concurrent) timing functionality. COBOL contains no object-oriented capabilities, though work in this area is being pursued by ANSI.

3.2.3.5.1 Standards. Table 3.2-22 presents standards for COBOL.

TABLE 3.2-22 COBOL standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

COBOL (adopts ANSI X3.23a: 1989 and X3.23b: 1993)

FIPS PUB 21-4:1995

Adopted

(Approved)

IPC

ISO

COBOL

1989:1985

Adopted

(Approved)

NPC

ANSI

COBOL

X3. 23: 1985

Adopted

(Approved)

NPC

ANSI

COBOL

X3. 23a: 1989

Informational

(Approved)

NPC

ANSI

COBOL

X3. 23: 1993

Informational

(Approved)

NPC

ANSI

Object COBOL

TBD

Informational

(Formative)

3.2.3.5.2 Alternative specifications. No other specifications are known.

3.2.3.5.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.3.5.4 Portability caveats. The COBOL language has a design goal of transparent portability of data across platforms. Portability of COBOL across different operating system and hardware suites is subject to errors brought about by differences between COBOL compiler implementations and hardware/operating system internal numerical representations.

3.2.3.5.5 Related standards. The emerging standard for Object COBOL is referenced in the table above.

3.2.3.5.6 Recommendations. NIST FIPS PUB 21-4/ISO 1989/ANSI X3.23 are the recommended standards for COBOL. COBOL should be included in an OSE only to maintain legacy software. However, Ada has been shown to be effective in these applications as well as less costly to maintain than existing COBOL software. Furthermore, Ada includes features, such as fixed point arithmetic, that have been identified as the cause of usability and portability problems in COBOL legacy applications. The reengineering of COBOL programs to Ada has been proven to be more cost-effective than maintaining the existing systems in the long term.

3.2.3.6 JOVIAL. JOVIAL (Jules' Own Version of the International Algebraic Language) is an ALGOL-like scientific and engineering programming language developed by Jules Schwartz of Systems Development Corp. for the USAF in the 1960s. JOVIAL was the Air Force's solution to the need for a better structured and more stable mathematical language than FORTRAN long before the advent of Ada. JOVIAL includes unique data types for expressing real values.

3.2.3.6.1 Standards. Table 3.2-23 presents standards for JOVIAL.

TABLE 3.2-23 JOVIAL standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD (USAF)

JOVIAL (J73)

MIL-STD-1589C: 1996

Adopted

(Approved)

3.2.3.6.2 Alternative specifications. No other specifications are known.

3.2.3.6.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.3.6.4 Portability caveats. Portability problems related to the existing specification are unknown.

3.2.3.6.5 Related standards. No other specifications are known.

3.2.3.6.6 Recommendations. MIL-STD-1589C is the recommended standard for JOVIAL based legacy systems and software. JOVIAL has been used traditionally for real time and scientific processing. The availability of Ada compilers and cross-compilers make Ada a cost-effective alternative. In fact, the USAF has undertaken a policy of converting all useful, existing JOVIAL software into Ada.

3.2.3.7 MUMPS. MUMPS (Massachusetts General Hospital Utility MultiProgramming System) is an advanced, high-level programming language and integrated database used for business applications. It has extensive string handling functionality, making it suitable for databases with large text entries. MUMPS, renamed M during 1993, has been widely used for the computing needs of the medical community. Two major federal systems implemented with MUMPS are the Veterans Affairs' Decentralized Hospital Computer Program (DHCP) and the DOD Composite Health Care System (CHCS). MUMPS originated in 1965 and is based upon the 127 ASCII characters. MUMPS adopts ANSI/MDC X11.1-1995 and is currently being revised. A MUMPS validation suite is available from NTIS.

3.2.3.7.1 Standards. Table 3.2-24 presents standards for MUMPS.

TABLE 3.2-24 MUMPS standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

MUMPS (Adopts ANSI/MDC X11.1-1990)

FIPS PUB 125-1:1993

Adopted

(Approved)

NPC

ANSI/MDC

MUMPS

X11.1-1995

Informational

(Approved)

3.2.3.7.2 Alternative specifications. No other specifications are known.

3.2.3.7.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.3.7.4 Portability caveats. The MUMPS language is supported on a limited number of platform/operating system combinations.

3.2.3.7.5 Related standards. No other specifications are known.

3.2.3.7.6 Recommendations. The FIPS PUB 125-1 standard is recommended for MUMPS based legacy systems and software. MUMPS provides unique large record length database capabilities not found in other languages. However, currently underway is a development activity to provide a library of Ada units which can supply MUMPS like functionality to software developed in Ada.

3.2.3.8 Simulation languages. Simulation is the representation of selected characteristics of the behavior of one physical or abstract system by another system. In a digital computer system, simulation is done by software; for example, the representation of physical phenomena by means of operations performed by a computer system or the representation of operations of a computer system by those of another computer system.

3.2.3.8.1 Standards. Table 3.2-25 presents standards for simulation langauges.

TABLE 3.2-25 Simulation languages standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

TBD

TBD

GPSS

TBD-GPSS

Informational

(TBD)

TBD

TBD

Simscript

TBD-Simscript

Informational

(TBD)

TBD

TBD

Simula

TBD-Simula

Informational

(TBD)

3.2.3.8.2 Alternative specifications. No other specifications are known.

3.2.3.8.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.3.8.4 Portability caveats. No portability of code can be assumed in the use of these existing specialty simulation languages.

3.2.3.8.5 Related standards. No other specifications are known.

3.2.3.8.6 Recommendations. No standards are recommended for simulation languages. Special simulation languages allow for rapid prototyping and development of quick use simulation tools. Generally such software is not readily maintainable. Use should be limited to proof of concept rapid prototyping, novel algorithm development and demonstration, and limited use simulations which require an extremely short development cycle. Major simulation efforts which require a high order language should be implemented in Ada.

3.2.3.9 Artificial intelligence languages. Artificial Intelligence (AI) languages are a subfield within computer science concerned with developing a technology to enable computers to solve problems (or assist humans in solving problems). The LISP (LISt Processing) language is the most popular one for research in AI. LISP is a high-level, non-numeric language with the syntactic distinction that there is no difference between the treatment of data and instructions. LISP was developed in 1960 and its current, standardized version is referred to as Common LISP.

3.2.3.9.1 Standards. Table 3.2-26 presents standards for artificial intelligence languages.

TABLE 3.2-26 Artificial intelligence languages standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

PROLOG

TBD-PROLOG

Informational

(Draft)

NPC

ANSI/X3J13

Common LISP (X3.226 Programming Language Common LISP)

X3J13/92-101

Informational

(Draft)

NPC

IEEE

AI-ESTATE

SC 20, PAR 1232

Informational

(Draft (CD))

NPC

ANSI

Common LISP Object System (CLOS)

TBD

Informational

(Draft (CD))

NPC

IEEE

Interoperability of Knowledge-Based Systems

TBD-Interoperability of Knowledge-Based Systems

Informational

(Formative)

3.2.3.9.2 Alternative specifications. No other specifications are known.

3.2.3.9.3 Standards deficiencies. Deficiencies in the existing standards are unknown. Currently standards are being developed for Common LISP and PROLOG. Common LISP is more popular in the United States and PROLOG is more popular in England and Europe, posing potential interoperability problems.

3.2.3.9.4 Portability caveats. No portability of software written with these languages can be guaranteed.

3.2.3.9.5 Related standards. No other specifications are known.

3.2.3.9.6 Recommendations. No standards are recommended for artificial language standards. The current generation of artificial intelligence languages are laboratory tools useful in the study of AI concepts. Generally such software is not readily maintainable. Use should be limited to proof of concept rapid prototyping, novel algorithm development and demonstration, and general AI research activities.

3.2.3.10 Fourth generation languages. Fourth generation languages (4GLs) are designed to improve the productivity achieved by HOL (third generation) languages and to make computing power available to non-programmers. Features typically include an integrated database management system, query language, report generator, and screen definition facility. Addition features support function, financial modeling, spreadsheet capability, and statistical analysis functions.

3.2.3.10.1 Standards. Table 3.2-27 presents standards for fourth generation languages.

TABLE 3.2-27 Fourth generation languages standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N/A

N.A.

None

N.A.

Informational

(N.A.)

3.2.3.10.2 Alternative specifications. The only available specifications are proprietary.

3.2.3.10.3 Standards deficiencies. All 4GLs are proprietary. Therefore, 4GLs have not been standardized, and creation of a 4GL standard is not planned. Furthermore, 4GLs often lack the functionality to define a complete system within their specification language. They are not integrated, making them incapable of linking the various parts of the system. They make inefficient use of machine resources, and are very expensive in terms of hardware requirements and/or software license fees.

3.2.3.10.4 Portability caveats. Portability problems relating to the existing specification are unknown.

3.2.3.10.5 Related standards. The ANSI/ISO/IEC 9075-1992 standard, Database Languages - SQL, is related to 4GLs.

3.2.3.10.6 Recommendations. No standards are recommended for 4GLs. Implementation-defined features and other nonstandard features of the programming language must be avoided. The 4GL situation is improving. For example, AdaSAGE was developed for the government to provide tools and an environment for Ada programmers to develop major nonproprietary systems completely in Ada.

3.2.4 Bindings. Language bindings are interfaces to operating systems, network software, graphical user interfaces, database management systems, and other system software specific to a programming language. Bindings define conventions for accessing functionality of the specified sub-system. Calling conventions include the name of the functional service called, the arguments to be included in the call, the data type of these arguments, the order of the arguments, error conditions which may result, and returned values. Because of the extensive lists of available bindings for some languages, only a small subset of the available bindings will be listed for each language. References to complete listings of bindings for each language are included.

3.2.4.1 Ada bindings. Few Ada bindings currently are implemented, although many standards exist or are in development for Ada bindings to OSE component sub-systems. Due to the importance of the Ada language, many working groups are active in the development of specifications for many such bindings.

3.2.4.1.1 Standards. Table 3.2-28 presents standards for Ada bindings.

TABLE 3.2-28 Ada bindings standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX Ada Language Interfaces, Part 1: Binding for System API

1003.5:1992

Adopted

(Approved)

IPC

ISO

Database Language SQL (same as ANSI X3.135-1992)

9075:1992

Adopted

(Approved)

IPC

ISO/IEC

Ada Bindings of PHIGS (binding for Ada-83)

9593-3:1990

Adopted

(Approved)

GPC

NIST

PHIGS language bindings - Part 3: Ada (binding for Ada-83)

FIPS PUB 153:1992

Adopted

(Approved)

NPC

ANSI

SQL Ada Module Extensions (SAME) (binding for Ada-83)

X3.168-1989

Adopted

(Approved)

NPC/GPC

ANSI/NIST

SQL and Ada Bindings (ANSI X3.135:1992) (binding for Ada-83)

X3.135:1992 FIPS 127-2:1993

Adopted

(Approved)

IPC

ISO

Interfacing techniques for dialogues with graphical devices(CGI)--Languages Bindings - Part 3: Ada

9638-3:1994

Adopted

(Approved)

IPC

ISO/IEC

SQL Ada Module Description Language (SAMeDL), First Edition

12227:1995

Adopted

(Approved)

IPC

ECMA

Portable Common Tool Environment (PCTE) - Ada Programming Language Binding

162 (1991)

Informational

(Approved)

IPC

ISO

Graphical Kernel System for Three Dimensions (GKS-3D) language bindings - Part 3: Ada (binding for Ada-83)

8806-3:1988

Informational

(Approved)

GPC

DOD

USAF STARS X-Windows binding [actually a binding to Xlib and Xt]

STARS

Informational

(Approved)

IPC

ECMA

PCTE - Extensions for Support of Fine-Grain Objects - Ada Programming Language Binding

229 (1995)

Informational

(Approved)

NPC

ANSI

GKS Language Bindings for Ada

X3.124.3-1989

Informational

(Approved)

IPC

ISO

GKS Language Bindings - Part 3: Ada

8651-3:1988

Informational

(Approved)

GPC

NIST

GKS Bindings for Ada

FIPS PUB 120-1:1994

Informational

(Approved)

NPC

IEEE

POSIX Ada Language Interfaces - Part 1:Binding for Realtime Extensions

1003.5b:1996 (former 1003.20)

Informational

(Approved)

IPC

ISO/IEC

PHIGS PLUS/Ada bindings (binding for Ada-83)

9593-3 PDAM 1

Informational

(Draft)

IPC

ISO

Generic Package of Elementary Functions (GPEF) (binding for Ada-83)

TBD-Generic Package of Elementary Functions (GPEF) (binding for Ada-83)

Informational

(Draft)

NPC

IEEE

POSIX - Part 1: System API Amendment: Real-Time Distributed Systems Communications

P1003.21

Informational

(Draft)

IPC

ISO

Ada Europe Numerics Working Group Primitive Functions (binding for Ada-83)

TBD-Ada Europe Numerics Working Group Primitive Functions (binding for Ada-83)

Informational

(Draft)

TBD

TBD

Ada Semantic Interface Specification (ASIS) (binding is planned for approval on the summer of 95)

TBD-Ada Semantic Interface Specification (ASIS) (binding is planned for approval on the summer of 95

Informational

(Draft)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface Amendment 2: Ada bindings (binding for Ada-83)

10728 WDAM 2:1993(E)

Informational

(Draft)

GPC

NIST

Initial Graphics Exchange Specification (IGES): v. 5.2 OR 6.0

FIPS PUB 177-1 (future)

Informational

(Formative)

NPC

IEEE

Uniform Application Programming Interface - Graphical User Interfaces (binding for Ada-83)

P1201.1

Informational

(Formative)

NPC

IEEE

Ada binding to P1003.2 (binding for Ada-83)

TBD-Ada binding to P1003.2 (binding for Ada-83)

Informational

(Formative)

NPC

EIA

CASE Data Interchange Format (CDIF) Ada bindings (binding for Ada-83)

TBD

Informational

(Formative)

TBD

TBD

Standard Generalized Markup Language (SGML) Ada bindings

TBD-Standard Generalized Markup Language (SGML) Ada bindings

Informational

(Formative)

TBD

TBD

Transmission Control Protocol/Internet Protocol (TCP/IP) Ada bindings (binding for Ada-83)

TBD-Transmission Control Protocol/Internet Protocol (TCP/IP) Ada bindings (binding for Ada-83)

Informational

(Formative)

IPC

ISO/IEC

X.25 Ada bindings (binding for Ada-83)

X.25 Ada bindings (binding for Ada-83)

Informational

(Formative)

TBD

TBD

Generic Package of Primitive Functions (GPPF) (binding for Ada-83)

TBD-Generic Package of Primitive Functions (GPPF) (binding for Ada-83)

Informational

(TBD)

NPC

ANSI/ASME

Digital Representation for Communication of Product Definition Data

Y14.26M:1989

Informational

(Superseded)

3.2.4.1.2 Alternative specifications. The following specifications are also available:

a. Rational Systems: X Windows Xlib implementation.

b. U.S. Army HQ Communications-Electronics Command (CECOM), Center for Software Engineering, report on "Thin" Ada Binding to P1003.4 describes a possible Ada-language interface with the proposed IEEE P1003.4 real time standard.

3.2.4.1.3 Standards deficiencies. Most bindings standards are still incomplete and Ada bindings are needed for many standards. No formal standards or specifications for bindings exist between Ada and any graphical user interface. However, the USAF STARS program has developed an Ada binding for Xlib and the Xt Intrinsics.

The IEEE P1003.5 Group has defined an Ada binding to the POSIX operating system kernel which parallels the IEEE 1003.1 C binding. This binding does not include functionality similar to the IEEE 1003.2 POSIX C binding standard for Shell and Utilities. The IEEE P1003.20 Group, which is defining Ada bindings for the POSIX.4 real time extensions, was formed in July 1992. Few or no Ada bindings are defined for other IMS sub-systems.

No open standards or de facto specifications exist for a common, GUI-independent Interactive Design Tools Interchange Format (IDTIF) (e.g., Motif's User Interface Language (UIL) and Sun Microsystems' DEVGUIDE), that would allow different tools for developing interactive, graphical, windowing applications to exchange graphics objects and basic screen information. Work in this area is in progress in the Open Software Foundation's (OSF's) User Interface Management Services (UIMS) working group and as a part of X/Open's GUI research. Presently, few Interactive Design Tool products are available. Those that exist are just maturing and generally do not work with other tools.

Language bindings for character-oriented GUIs (i.e., the display, manipulation, and management of objects in windows on a character-oriented (non-bit-mapped) screen) are needed.

3.2.4.1.4 Portability caveats. It is possible to implement the X Window system in Ada, but this is a substantial amount of work. Some proprietary 4GL GUI builder products claim to have direct Ada bindings to Motif. Ada code can interface with the X libraries, which are written in C, but the Ada and C programming languages have fundamental incompatibilities. A number of COTS products support or supply such bindings.

3.2.4.1.5 Related standards. No other specifications are known.

3.2.4.1.6 Recommendations. The standards identified as adopted should be selected as needed.

3.2.4.2 C language bindings. C has been the language of choice among commercial software developers over the past decade for the development of interface bindings for SQL, communications, windowing systems, and operating systems. This "choice" has been formalized by the explicit generation of C binding standards for the various aspects of POSIX. Other languages which must interface to these support areas often are written with a library layer which binds to an existing C interface library. C++ is emerging as the language of choice among commercial developers for GUI based applications.

3.2.4.2.2 Standards. Table 3.2-29 presents standards for C language bindings.

TABLE 3.2-29 C language bindings standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Graphical Kernel System for 3 Dimensions (GKS-3D) Language Bindings, Part 4: C

8806-4:1991

Informational

(Approved)

IPC

ISO/IEC

PHIGS Language Binding, Part 4: C

9593-4:1991

Informational

(Approved)

NPC

IEEE

Open Systems Interconnection (OSI) Abstract Data Manipulation C Language Interfaces - Binding for Application Program Interface (API)

1327:1993

Informational

(Approved)

NPC

IEEE

X.400-Based Electronic Messaging C Language Interfaces - Binding for API

1327.1:1993

Informational

(Approved)

NPC

IEEE

Directory Services C Languages Interfaces - Binding for API

1327.2:1993

Informational

(Approved)

IPC

ECMA

Portable Common Tool Environment (PCTE) - C Programming Language Binding

158 (1994)

Informational

(Approved)

IPC

ECMA

PCTE - Extensions for Support of Fine-Grain Objects - C Programming Language Binding

228 (1995)

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Informational

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface

10728:1993

Informational

(Approved)

IPC

ISO

Portable Common Tool Environment (PCTE) - Part 2: C Programming Language Binding

13719-2:1995

Informational

(Approved)

IPC

ISO

GKS Language Bindings - Part 3: Ada

8651-3:1988

Informational

(Approved)

NPC

IEEE

OSI Application Program Interface (API) - ACE and Presentation Layer API [C Binding]

P1352

Informational

(Draft)

IPC

ISO/IEC

Image Processing and Interchange (IPI) API Language Bindings, Part 4: C

CD12087-4:

Informational

(Draft)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface Amendment 1: C Language Binding

10728 AMD 1:1994

Informational

(Draft)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

3.2.4.2.4 Alternative specifications. The SAA's SQL bindings to C are also available.

3.2.4.2.5 Standards deficiencies. Many standards lack a C binding, even in draft form, although more standards support C bindings than any other language.

3.2.4.2.6 Portability caveats. Portability problems related to the existing bindings are unknown.

3.2.4.2.7 Related standards. Other related standards are unknown.

3.2.4.2.8 Recommendations. No standards are recommended for C Bindings. C bindings should be used only in the absence of an equivalent Ada binding. A layered Ada-to-C binding approach should be taken to allow rapid migration to the Ada binding when it becomes available.

3.2.4.3 FORTRAN bindings. FORTRAN, because of its historic usefulness and popularity, has been the subject of bindings definition by several standards organizations. These standards and specifications are for standards bindings to the FORTRAN programming language.

3.2.4.3.1 Standards. Table 3.2-30 presents standards for FORTRAN bindings.

TABLE 3.2-30 FORTRAN bindings standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX FORTRAN 77 Language Interfaces - Part 1: Binding for System API

1003.9:1992

Informational

(Approved)

IPC

ISO

GKS-3D FORTRAN binding

8806-1:1988

Informational

(Approved)

IPC

ISO

Appendix for COBOL, FORTRAN, Pascal, and PL/1 bindings to SQL2 (Technical content of ISO 9075:1988, SQL, is retained as a level of the 1992 standard)

9075:1992 Appendix

Informational

(Approved)

IPC

ISO/IEC

PHIGS FORTRAN binding

9593-1:1990

Informational

(Approved)

GPC

NIST

PHIGS FORTRAN binding (Adopts ISO/IEC 9593.1:1990)

FIPS PUB 153:1992

Informational

(Approved)

GPC

NIST

FORTRAN binding to GKS

FIPS PUB 120-1:1994

Informational

(Approved)

NPC

ANSI

PHIGS FORTRAN binding (X3.144.1)

X3.144.1

Informational

(Approved)

NPC

ANSI

FORTRAN binding to GKS

X3.124.1-1985 (R1991)

Informational

(Approved)

NPC

IEEE

FORTRAN-90 bindings to POSIX

1003.19

Informational

(Draft)

3.2.4.3.2 Standards conformance. Conformance to the ISO/ANSI 1539-1990 standard or FIPS 69-1 is required.

3.2.4.3.3 Alternative specifications. No other specifications are available.

3.2.4.3.4 Standards deficiencies. Many standards lack a FORTRAN binding, even in draft form.

3.2.4.3.5 Portability caveats. Portability problems related to the existing bindings are unknown.

3.2.4.3.6 Related standards. Other related standards are unknown.

3.2.4.3.7 Recommendations. No standards are recommended for FORTRAN. Work on IEEE 1003.19 has been suspended. FORTRAN bindings should be used only in the absence of an equivalent Ada binding. A layered Ada to FORTRAN binding approach should be taken to allow rapid migration to the Ada binding when it becomes available.

3.2.4.4 Bindings to COTS products. These standards and specifications are for bindings for COTS products to a programming language (i.e., Ada).

3.2.4.4.1 Standards. Table 3.2-31 presents standards for bindings to COTS products.

TABLE 3.2-31 Bindings to COTS products standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

OSF/Motif binding to Ada

TBD-OSF/Motif binding to Ada

Informational

(Approved)

IPC

ISO/IEC

SQL Ada Module Description Language (SAMeDL), First Edition

12227:1995

Informational

(Approved)

TBD

TBD

Transmission Control Protocol/Internet Protocol (TCP/IP) Ada bindings (binding for Ada-83)

TBD-Transmission Control Protocol/Internet Protocol (TCP/IP) Ada bindings (binding for Ada-83)

Informational

(Formative)

3.2.4.4.2 Alternative specifications. A number of Ada bindings to Microsoft Windows. These are proprietary, as is Microsoft Windows, and should be used only to support legacy products.

3.2.4.4.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.4.4.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.2.4.4.6 Related standards. No other specifications are known.

3.2.4.4.7 Recommendations. No standards are recommended for COTS Ada bindings.

3.2.5 Software Engineering Security Services. Security engineering activities are critical processes during the software development life-cycle, as well as during system operation and maintenance. Concentration on the analysis and allocation of security requirements is the major goal to be accomplished. Once developed, software systems must take into account operational concerns such as certification and accreditation, risk management, and accountability functions. For users of the ITSG who are not familiar with security terminology, study of the following references is suggested:

a. National Information Systems Security (INFOSEC) Glossary, National Security Telecommunications and Information Systems Security (NTISSI) No. 4009, 5 June 1992.

b. Glossary of Telecommunications Terms, FED-STD-1037B, 3 June 1991.

c. Dictionary of Information Systems, ANSI X3.172, 1990.

d. Security in Open Systems - Data Elements and Service Definitions, ECMA 138:1989 (based on ECMA TR46:1988).

e. Glossary of Computer Security Terms, NCSC-TG-004, version 1, 21 October 1988.

3.2.5.1 Security models and architectures. (This BSA appears in part 2 and part 10.) Security models provide the necessary basis for the development of security-related protocols and security-related protocol elements.

3.2.5.1.1 Standards. Table 3.2-32 presents standards for security models and architectures.

TABLE 3.2-32 Security models and architectures standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

CPC

CEN/CENELEC/ITAEGV

Taxonomy of Security Standardization

ITAEGV N69 Ver 2 of 4/30/1992

Informational

(Approved)

IPC

ECMA

Security in Open Systems - Data Elements and Service Definitions

138 (1989)

Informational

(Approved)

IPC

ECMA

Security in Open Systems - A Security Framework

TR/46 (1988)

Informational

(Approved)

GPC

NIST

Guidelines for Security of Computer Applications

FIPS PUB 73:1980

Informational

(Approved)

IPC

ITU-T

Security Architecture for OSI for CCITT Applications: Security, Structure, and Applications

X.800 (1991)

Informational

(Approved)

CPC

X/Open

Security Guide (Second Edition)

G010 (2/91)

Informational

(Approved)

IPC

ITU-T

Reference Model of OSE for CCITT Applications-Data Communications Networks-OSI Model and Notation, Services Definition

X.200 (1989)

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 3: Naming and Addressing

7498-3:1989

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 4: Management Framework

7498-4:1989

Informational

(Approved)

IPC

ISO/IEC

OSI The Directory: Abstract Service Definition: (same as ITU-T X.511 (1993))

9594-3:1993 (or 1994)

Informational

(Approved)

IPC

ISO/IEC

OSI The Directory: Procedures for Distributed Operations:(same as ITU-T X.519(1993))

9594-4:1993 (or 1994)

Informational

(Approved)

IPC

ISO/IEC

OSI The Directory: Authentication Framework (same as ITU-T X.509 (1993))

9594-8:1993 (or 1994)

Informational

(Approved)

IPC

ISO

OSI Upper Layer Security Model

10745:1993

Informational

(Approved)

CPC

X/Open

Distributed Security Framework

G410 (12/94)

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

NPC

IEEE

Guide to the POSIX Open Systems Environment - A Security Framework

P1003.22: 1995

Informational

(Draft)

IPC

ISO/IEC

OSI Security Frameworks for Open Systems, Part 1: Overview

10181-1

Informational

(Draft)

IPC

ISO/IEC

Guide to Open Systems Security

TR by JTC1/SC21/N8380

Informational

(Draft)

IPC

ISO/IEC

Management Plan for Security

JTC1/SC21 SD-7

Informational

(Draft)

3.2.5.1.2 Alternate specifications. There are no alternate specifications.

3.2.5.1.3 Standards deficiencies. FIPS PUB 73 does not include information on modern security concepts.

3.2.5.1.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.5.1.5 Related standards. There are no related standards.

3.2.5.1.6 Recommendations. The DGSA, Volume 6 of the TAFIM, is the abstract and generic security architecture of the TAFIM. The DGSA provides security principles and target security capabilities to guide system security architects in creating specific security architectures consistent with the DGSA. The DGSA should be used by system security architects to develop logical and specific security architectures.

3.2.5.2 System development security. (This BSA appears in part 2, part 9, and part 10.) Development of secure systems requires that security engineering be a key discipline in conjunction with other system, software, and hardware engineering activities.

3.2.5.2.1 Standards. Table 3.2-33 presents standards for system development security.

TABLE 3.2-33 System development security standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

DOD

Trusted Network Interpretation

NCSC-TG-005, Version 1: 1987

Mandated

(Approved)

GPC

DOD

Trusted Database Management System Interpretation of the Trusted Computer Systems Evaluation Criteria

NCSC-TG-021, Version 1: 1991

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

GPC

DOD

FORTEZZA Cryptologic Programmers' Guide

MD40000501-1.52: 1996

Mandated

(Approved)

GPC

DOD

FORTEZZA Application Implementors' Guide

MD4002101-1.52: 1996

Mandated

(Approved)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Informational

(Approved)

IPC

ISO/IEC

Software Life Cycle Processes

12207:1995

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

GPC

NIST

Guidelines for Security of Computer Applications

FIPS PUB 83:1980

Informational

(Approved)

IPC

ISO/IEC

OSI The Directory: Abstract Service Definition: (same as ITU-T X.511 (1993))

9594-3:1993 (or 1994)

Informational

(Approved)

IPC

ISO/IEC

OSI The Directory: Procedures for Distributed Operations:(same as ITU-T X.519(1993))

9594-4:1993 (or 1994)

Informational

(Approved)

IPC

ISO/IEC

OSI The Directory: Authentication Framework (same as ITU-T X.509 (1993))

9594-8:1993 (or 1994)

Informational

(Approved)

CPC

X/Open

Generic Security Service API (GSS-API) Base

C441 (12/95)

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment n: Protection, Audit, and Control Interfaces (C Language), Draft 15

P1003.1e: 1995

Legacy

(Draft)

NPC

IEEE

POSIX Part 2: Shell and Utilities - Amendment n: Protection and Control Utilities, Draft 15

P1003.2c: 1995

Emerging

(Draft)

CPC

IETF

Generic Security Service - Application Program Interface, Version 2

RFC 2078: 1997

Emerging

(Draft)

CPC

IETF

Independent Data Unit Protection Generic Security Application Program Interface (IDUP-GSS-API)

draft-ietf-cat-idup-gss-06.txt, 26 November 1996

Emerging

(Draft)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.2.5.2.2 Alternative specification. There are no alternative specifications.

3.2.5.2.3 Standard deficiencies. Deficiencies in the existing standards are unknown.

3.2.5.2.4 Portability caveats. There are no portability caveats.

3.2.5.2.5 Related standards. DOD Directive 5200.28 "Security Requirements for Automated Information Systems (AISs)," provides the DOD-wide program for AIS security. It provides mandatory, minimum AIS security requirements for systems processing classified, sensitive but unclassified, and unclassified information. For intelligence systems, Director, Central Intelligence Directive (DCID) 1/16, "Security Policy for Uniform Protection of Intelligence Processed in Automated Information Systems and Networks," and "Security Manual for Uniform Protection of Intelligence Information Processed in Automated Information Systems and Networks," should be used in conjunction with DOD 5200.28-STD. The following guidelines also are for use with DOD 5200.28-STD:

a. NCSC-TG-006, Version 1, 28 March 1988, A Guide to Understanding Configuration Management in Trusted Systems

b. NCSC-TG-007, Version 1, 2 October 1988, A Guide to Understanding Design Documentation in Trusted Systems

c. NCSC-TG-008, Version 1, 15 December 1988, A Guide to Understanding Trusted Distribution in Trusted Systems

d. NCSC-TG-018, Version 1, July 1992, A Guide to Understanding Object Reuse in Trusted Systems

e. NCSC-TG-023, Version 1, July 1993, A Guide to Understanding Security Testing and Test Documentation in Trusted Systems

3.2.5.2.6 Recommendations. The standards listed as mandated are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. MIL-STD-498 contains requirements for security and privacy for software development and documentation. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service approval, until organizational processes for IEEE/EIA 12207US are in place.

If FORTEZZA services are used, the following two guidelines should be consulted:

a. MD4002101-1.52, 3/5/96, FORTEZZA Application Implementors' Guide

b. MD4000502-1.52, 1/30/96, FORTEZZA Cryptologic Programmers' Guide, Revision 1.52

3.2.5.3 Personal authentication. (This BSA appears in part 2, part 3, part 9, and part 10.) Personal authentication supports the accountability objective of being able to trace all security relevant events to individual users. In addition to supporting unique identification, standards are provided to authenticate the claimed identity.

3.2.5.3.1 Standards. Table 3.2-34 presents standards for personal authentication.

TABLE 3.2-34 Personal authentication standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

GPC

NIST

Password Usage

FIPS PUB 112: 1985

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

GPC

NIST

Guidelines on Evaluation of Techniques for Automated Personal Identification

FIPS PUB 48:1977

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Open Systems Interconnection - The Directory: Authentication Framework edition 2 (Same as ITU-T X.509:1993)

9594-8.2:1993

Informational

(Approved)

GPC

NIST

Guideline for Use of Advanced Authentication Technology Alternatives

FIPS PUB 190:1994

Informational

(Approved)

CPC

IETF

A One-Time Password System

RFC 1938: 1996

Emerging

(Draft)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

CPC

IETF

The Kerberos Network Authentication Service (V5)

RFC 1510:1993

Informational

(Draft)

3.2.5.3.2 Alternate specifications. There are no alternative specifications.

3.2.5.3.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

 

3.2.5.3.4 Portability caveats. OSF DCE Version 1.1's authentication service is based on Kerberos Version 5 (RFC 1510), but is not totally compatible with RFC 1510. DCE 1.2.2 adds testing and official support for Kerberos Version 5.

3.2.5.3.5 Related standards. The following standards are related to personal authentication standards (particularly TCSEC):

a. DOD 5200.28-STD, DOD Trusted Computer Systems Evaluation Criteria

b. NCSC-TG-017, Version 1, "A Guide to Understanding Identification and Authentication in Trusted Systems

c. CSC-STD-002-85, "Password Management Guideline"

d. NCSC-WA-002-85, "Personal Computer Security Considerations"

e. ITU-T X.509 (1993) (same as ISO 9594-8), The Directory: Authentication Framework

3.2.5.3.6 Recommendations. The mandated standards are recommended.

3.2.5.4 Certification and accreditation. (This BSA appears in part 2, part 9, and part 10.) Certification and accreditation constitute a set of procedures and judgments leading to a determination of the suitability of the system to operate in the targeted operational environment.

Accreditation is the official management authorization to operate a system. The accreditation normally grants approval for the system to operate (a) in a particular security mode, (b) with a prescribed set of countermeasures (administrative, physical, personnel, communications security, emissions, and computer security controls), (c) against a defined threat and with stated vulnerabilities and countermeasures, (d) within a given operational concept and environment, (e) with stated interconnections to other systems, (f) at an acceptable level of risk for which the accrediting authority has formally assumed responsibility, and (g) for a specified period of time. The Designated Approving Authority(s) (DAA) formally accepts security responsibility for the operation of the system and officially declares that the specified system will adequately protect against compromise, destruction, or unauthorized modification under stated parameters of the accreditation. The accreditation decision affixes security responsibility with the DAA and shows that due care has been taken for security in accordance with the applicable policies.

An accreditation decision is in effect after the issuance of a formal, dated statement of accreditation signed by the DAA, and remains in effect for the specified period of time (varies according to applicable policies). A system processing classified or sensitive unclassified information should be accredited prior to operation or testing with live data unless a written waiver is granted by the DAA. In some cases (e.g., when dealing with new technology, during a transition phase, or when additional time is needed for more rigorous testing), the DAA may grant an interim approval to operate for a specified period of time. At the end of the specified time period, the DAA must make the final accreditation decision.

Certification is conducted in support of the accreditation process. It is the comprehensive analysis of both the technical and nontechnical security features and other safeguards of a system to establish the extent to which a particular system meets the security requirements for its mission and operational environment. A complete system certification must consider factors dealing with the system in its unique environment, such as its proposed security mode of operation, specific users, applications, data sensitivity, system configuration, site/facility location, and interconnections with other systems. Certification should be done by personnel who are technically competent to assess the systems ability to meet the security requirements according to an acceptable methodology. The resulting documentation of the certification activities is provided to the DAA to support the accreditation decision. Many security activities support certification, such as risk analysis, security test and evaluation, and various types of evaluations.

Ideally, certification and accreditation procedures encompass the entire life cycle of the system. Ideally, the DAA is involved from the inception of the system to ensure that the accreditation goals are clearly defined. A successful certification effort implies that system security attributes were measured and tested against the threats of the intended operational scenarios. Additionally, certification and accreditation are seen as continuing and dynamic processes; the security state of the system needs to be tracked and assessed through changes to the system and its operational environment. Likewise, the management decision to accept the changing system for continued operation is an ongoing decision process.

Standards for certification and accreditation services provide definitions and procedures for the testing and accreditation of computer systems in so far as their conformance with security standards is concerned.

3.2.5.4.1 Standards. Table 3.2-35 presents standards for certification and accreditation.

TABLE 3.2-35 Certification and accreditation standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

NIST

Guideline for Computer Security Certification and Accreditation

FIPS PUB 102:1983

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

GPC

DOD

DOD Information Technology Certification and Accreditation Process

DITSCAP: 1996

Informational

(Draft)

3.2.5.4.2 Alternate specifications. No other consortia or de facto specifications are available.

3.2.5.4.3 Standards deficiencies. Because of its age, FIPS PUB 102 does not include services for the certification and accreditation of all modern security concepts. No known up-to-date standards exist for certification and accreditation.

Certification and accreditation evaluation criteria that address current information technology, such as distributed computing and networking, are needed. As new criteria such as the Common Criteria emerge, revision of existing certification and accreditation guidelines may be required.

3.2.5.4.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.2.5.4.5 Related standards. NCSC-TG-029, "Introduction to Certification and Accreditation," January 1994, discusses basic concepts related to certification and accreditation and is the first of a series of guidelines in the "Rainbow Series" supporting the Trusted Computer System Evaluation Criteria (TCSEC) standard.

3.2.5.4.6 Recommendations. The mandated standard is recommended.

Procurements that require that an AIS be certified and/or accredited must reference DOD Directive 5200.28 and applicable designated approving authority guidance. DOD Directive 5200.28, "Security Requirements for Automated Information Systems (AISs)," requires certification and accreditation of AIS. FIPS PUB 102, Guidelines for Computer Security and Accreditation provides Federal guidelines for certification and accreditation. Because of its age, this FIPS PUB does not include services for the certification and accreditation of all modern security concepts. DOD 5200.28-STD provides criteria to assess security assurances of trusted systems to specific classes. DCID 1/16 provides security requirements for systems processing intelligence information.

The DISA CISS and NSA are each developing documents that will standardize the certification and accreditation process within DOD. Each document is in draft form; final documents are expected to be issued in 1997. The NSA document, "Certification and Accreditation Process Handbook for Certifiers," will be published as a "Rainbow" series document supporting the TCSEC standard. This NSA handbook focuses on certification and accreditation of standalone systems. The DISA CISS document, "DOD Information Technology Certification and Accreditation Process" (DITSCAP), will be published as a DOD publication. The DITSCAP focuses on certification and accreditation in conjunction with the programmatic aspects of the DII.

3.2.5.5 Security risk management. (This BSA appears in part 2, part 7, part 9, and part 10.) Security risk management supports accreditation through a risk analysis of an information system and its operational environment, and the steps taken to manage the risk requirements.

3.2.5.5.1 Standards. Table 3.2-36 presents standards for security risk management.

TABLE 3.2-36 Security risk management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

NIST

Guideline for the Analysis of Local Area Network Security

FIPS PUB 191:1994

Informational

(Approved)

GPC

NIST

Guideline for Automated Data Processing Risk Analysis

FIPS PUB 65:1979

Informational

(Approved)

GPC

NIST

Guidelines for Automatic Data Processing Physical Security and Risk Management

FIPS PUB 31:1974

Informational

(Approved)

3.2.5.5.2 Alternate specifications. No alternative specifications are known.

3.2.5.5.3 Standards deficiencies. Because of its age, FIPS PUB 31 does not include information of all modern security concepts.

3.2.5.5.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.5.5.5 Related standards. The following standards are related to the TCSEC standard:

a. CSC-STD-003-85 25 June 1985, Computer Security Requirements - Guidance for Applying the Department of Defense Trusted Computer Security Evaluation Criteria in Specific Environments

b. CSC-STD-004-85, 25 June 1985, Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements - Guidance for Applying the Department of Defense Trusted Computer Security Evaluation Criteria in Specific Environments

3.2.5.5.6 Recommendations. The mandated standard is recommended. Office of Management and Budget (OMB) Circular A-130, "Management of Federal Information Resources," provides guidance on effective security risk management of federal information systems. NIST Special Publication 800-12, "An Introduction to Computer Security: The NIST Handbook" provides additional guidance on risk management. DOD Directive 5200.28 requires a risk analysis of an information system be conducted in its operational environment to support accreditation of the information system. System implementors should perform the risk analysis in accordance with CSC-STD-003-85 and CSC-STD-004-85 to determine the appropriate DOD-5200.28-STD class.

3.2.5.6 Detection and notification. (This BSA appears in part 2, part 9, and part 10.) Detection and notification objectives ensure that a secure system has the capability to recognize that it is: under attack; may potentially enter a non-available state; has been compromised; or has failed in a potentially compromising manner. Guidance in this area focuses on reporting detected security critical conditions to proper authorities, and implementing predetermined corrective actions.

3.2.5.6.1 Standards. Table 3.2-37 presents standards for detection and notification.

TABLE 3.2-37 Detection and notification standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

3.2.5.6.2 Alternate specifications. No alternate specifications are known.

There are no alternative specifications.

3.2.5.6.3 Standards deficiencies. No standards deficiencies are known.

3.2.5.6.4 Portability caveats. No portability caveats are known.

3.2.5.6.5 Related standards. NSA's C-Technical Report-001, Computer Viruses: Prevention, Detection, and Treatment, and NIST SP 800-5, A Guide to the Selection of Anti-Virus Tools and Techniques, provide guidance on computer viruses. The following specifications support the TCSEC standard:

a. NCSC-TG-005, Version 1, July 1987, Trusted Network Interpretation

b. NCSC-TG-015, Version 1, October 1989, A Guide to Understanding Trusted Facility Management

c. NCSC-TG-016, Version 1, October 1992, Guidelines for Writing Trusted Facility Manuals

3.2.5.6.6 Recommendations. The mandated standard is recommended.

3.2.5.7 Security recovery. (This BSA appears in part 2, part 9, and part 10.) Recovery guidance defines provisions to allow system personnel or processes with the proper authorizations to repair or eliminate the cause of security relevant failures, isolate compromised portions of the system, and revalidate proper operations prior to returning the system to a fully operational secure state.

3.2.5.7.1 Standards. Table 3.2-38 presents standards for security recovery.

TABLE 3.2-38 Security recovery standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

3.2.5.7.2 Alternate specifications. No alternative specifications are known.

There are no alternative specifications.

3.2.5.7.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.2.5.7.4 Portability caveats. Portability problems with the existing standards are unknown.

3.2.5.7.5 Related standards. The following specifications are related to the TCSEC standard:

a. NCSC-TG-005, Version 1, July 1987, Trusted Network Interpretation

b. NCSC-TG-022, Version 1, December 1991, A Guide to Understanding Trusted Recovery in Trusted Systems

c. NCSC-TG-015, Version 1, October 1989, A Guide to Understanding Trusted Facility Management

d. NCSC-TG-016, Version 1, October 1992, Guidelines for Writing Trusted Facility Manuals

3.2.5.7.6 Recommendations. The mandated standard is recommended.