DOD-STD-2167A

Last updated
Defense Systems Software Development
StatusCancelled 1994 / Legacy
Year startedFebruary 29, 1988 (1988-02-29)
Organization United States Department of Defense
Base standardsPreceded by
DOD-STD-2167
Related standards DOD-STD-2168
Succeeded by

DOD-STD-2167A (Department of Defense Standard 2167A), titled "Defense Systems Software Development", was a United States defense standard, published on February 29, 1988, which updated the less well known DOD-STD-2167 published 4 June 1985. This document established "uniform requirements for the software development that are applicable throughout the system life cycle." [1] This revision was written to allow the contractor more flexibility [2] and was a significant reorganization and reduction of the previous revision; e.g.., where the previous revision prescribed pages of design and coding standards, this revision only gave one page of general requirements for the contractor's coding standards; while DOD-STD-2167 listed 11 quality factors to be addressed for each software component in the SRS, DOD-STD-2167A only tasked the contractor to address relevant quality factors in the SRS. [3] Like DOD-STD-2167, it was designed to be used with DOD-STD-2168, "Defense System Software Quality Program".

Contents

On December 5, 1994 it was superseded by MIL-STD-498, which merged DOD-STD-2167A, DOD-STD-7935A, and DOD-STD-2168 into a single document, [4] and addressed some vendor criticisms.

Criticism

One criticism of the standard was that it was biased toward the Waterfall Model. Although the document states "the contractor is responsible for selecting software development methods (for example, rapid prototyping)", it also required "formal reviews and audits" that seemed to lock the vendor into designing and documenting the system before any implementation began.[ citation needed ]

Another criticism was the focus on design documents, to the exclusion of Computer-Aided Software Engineering (CASE) tools being used in the industry. Vendors would often use the CASE tools to design the software, then write several standards-required documents to describe the CASE-formatted data. This created problems matching design documents to the actual product.[ citation needed ]

Successors

One result of these criticisms was to begin designing a successor standard, which became MIL-STD-498. [5] Another result was a preference for formal industry-designed standards (such as IEEE 12207) and informal "best practice" specifications, rather than trying to determine the best processes and making them formal requirements on suppliers.

MIL-STD-2167A with MIL-STD-498 eventually became the basis for DO-178 in the early 1980s, [6] with DO-178 receiving subsequent subsequent revisions. MIL-STD-2167 and MIL-STD-498 together define standard software development life cycle processes that are expected to be implemented and followed as well as prescriptively defining standard document format and content. In contrast, the less proscriptive DO-178B/C defines objectives that should be accomplished as acceptable means [7] of demonstrating airworthiness, permitting relative flexibility in the life cycles and processes employed to accomplish those objectives. [8]

Related Research Articles

<span class="mw-page-title-main">Work breakdown structure</span> A deliverable-orientated breakdown of a project into smaller components.

A work-breakdown structure (WBS) in project management and systems engineering is a deliverable-oriented breakdown of a project into smaller components. A work breakdown structure is a key project deliverable that organizes the team's work into manageable sections. The Project Management Body of Knowledge defines the work-breakdown structure as a "hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables."

The waterfall model is a breakdown of project activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.

<span class="mw-page-title-main">Configuration management</span> Process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

<span class="mw-page-title-main">Iterative and incremental development</span> Development methodology

Iterative and incremental development is any combination of both iterative design or iterative method and incremental build model for development.

MIL-STD-1750A or 1750A is the formal definition of a 16-bit computer instruction set architecture (ISA), including both required and optional components, as described by the military standard document MIL-STD-1750A (1980). Since August 1996, it has been inactive for new designs.

ISO/IEC/IEEE 12207Systems and software engineering – Software life cycle processes is an international standard for software lifecycle processes. First introduced in 1995, it aims to be a primary standard that defines all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after business requirements specification(CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.

MIL-STD-498, Military Standard Software Development and Documentation, was a United States military standard whose purpose was to "establish uniform requirements for software development and documentation." It was released Nov. 8, 1994, and replaced DOD-STD-2167A, DOD-STD-2168, DOD-STD-7935A, and DOD-STD-1703. It was meant as an interim standard, to be in effect for about two years until a commercial standard was developed.

A United States defense standard, often called a military standard, "MIL-STD", "MIL-SPEC", or (informally) "MilSpecs", is used to help achieve standardization objectives by the U.S. Department of Defense.

Integrated logistic support (ILS) is a technology in the system engineering to lower a product life cycle cost and decrease demand for logistics by the maintenance system optimization to ease the product support. Although originally developed for military purposes, it is also widely used in commercial customer service organisations.

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety-critical software used in certain airborne systems. It was jointly developed by the safety-critical working group RTCA SC-167 of the Radio Technical Commission for Aeronautics (RTCA) and WG-12 of the European Organisation for Civil Aviation Equipment (EUROCAE). RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B. Although technically a guideline, it was a de facto standard for developing avionics software systems until it was replaced in 2012 by DO-178C.

A hazard analysis is used as the first step in a process used to assess risk. The result of a hazard analysis is the identification of different types of hazards. A hazard is a potential condition and exists or not. It may, in single existence or in combination with other hazards and conditions, become an actual Functional Failure or Accident (Mishap). The way this exactly happens in one particular sequence is called a scenario. This scenario has a probability of occurrence. Often a system has many potential failure scenarios. It also is assigned a classification, based on the worst case severity of the end condition. Risk is the combination of probability and severity. Preliminary risk levels can be provided in the hazard analysis. The validation, more precise prediction (verification) and acceptance of risk is determined in the risk assessment (analysis). The main goal of both is to provide the best selection of means of controlling or eliminating the risk. The term is used in several engineering specialties, including avionics, chemical process safety, safety engineering, reliability engineering and food safety.

<span class="mw-page-title-main">MIL-STD-810</span> Military standard

MIL-STD-810, U S Department of Defense Test Method Standard, Environmental Engineering Considerations and Laboratory Tests, is a United States Military Standard that emphasizes tailoring an equipment's environmental design and test limits to the conditions that it will experience throughout its service life, and establishing chamber test methods that replicate the effects of environments on the equipment rather than imitating the environments themselves. Although prepared specifically for U.S. military applications, the standard is often applied for commercial products as well.

The ISO/IEC 15288 is a technical standard in systems engineering which covers processes and lifecycle stages, developed by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). Planning for the ISO/IEC 15288:2002(E) standard started in 1994 when the need for a common systems engineering process framework was recognized. The previously accepted standard MIL STD 499A (1974) was cancelled after a memo from the United States Secretary of Defense (SECDEF) prohibited the use of most U.S. Military Standards without a waiver. The first edition was issued on 1 November 2002. Stuart Arnold was the editor and Harold Lawson was the architect of the standard. In 2004 this standard was adopted by the Institute of Electrical and Electronics Engineers as IEEE 15288. ISO/IEC 15288 has been updated 1 February 2008 as well as on 15 May 2015.

The terms "DOD-STD-2167" and "DOD-STD-2168" are the official specification numbers for superseded U.S. DoD military standards describing documents and procedures required for developing military computer systems. Specifically:

A concept of operations is a document describing the characteristics of a proposed system from the viewpoint of an individual who will use that system. Examples include business requirements specification or stakeholder requirements specification (StRS). CONOPS is used to communicate the quantitative and qualitative system characteristics to all stakeholders. CONOPS are widely used in the military, governmental services and other fields.

MIL-STD-129 standard is used for maintaining uniformity while marking military equipment and supplies that are transported through ships. This standard has been approved to be used by the United States Department of Defense and all other government agencies. Items must be marked for easy identification before they are transported. The marking helps the military personnel to fill the necessary requisition, when a particular stock goes short of the balance level.

<span class="mw-page-title-main">Trusted Computer System Evaluation Criteria</span>

Trusted Computer System Evaluation Criteria (TCSEC) is a United States Government Department of Defense (DoD) standard that sets basic requirements for assessing the effectiveness of computer security controls built into a computer system. The TCSEC was used to evaluate, classify, and select computer systems being considered for the processing, storage, and retrieval of sensitive or classified information.

MIL-STD-461 is a United States Military Standard that describes how to test equipment for electromagnetic compatibility.

References

  1. "DOD-STD-2167A, MILITARY STANDARD: DEFENSE SYSTEM SOFTWARE DEVELOPMENT]" (PDF). United States Department of Defense. 29 Feb 1988.
  2. Paul V. Shebalin (Summer 1994). "Software Development Standards and the DoD Program Manager" (PDF). Acquisition Review Quarterly. Defense Acquisition University.
  3. D. S. Maibor (1991). Christine Anderson (ed.). Aerospace Software Engineering (The DOD Life Cycle Model). p. 45. ISBN   9781600863905.
  4. "MIL-STD-498, MILITARY STANDARD: SOFTWARE DEVELOPMENT AND DOCUMENTATION [SUPERSEDED BY IEEE/EIA 12207.0, IEEE/EIA 12207.1 AND IEEE/EIA 12207.2]" (PDF). United States Department of Defense. 5 Dec 1994.
  5. Defence Aviation Authority, Australia, AAP 7001.054(AM1): Airworthiness Design Requirements Manual, Sect 2 Chap 7 - Aviation Software, p. 10, However, DOD-STD-2167A contains a number of notable shortfalls that were resolved by MIL-STD-498.
  6. Martin Beeby (2012). "DO-178C the future of Avionics Certification". atego. p. 3. Retrieved 23 Jan 2016.
  7. AC 20-115C Archived September 3, 2014, at the Wayback Machine
  8. William S. Levine, ed. (2011). The Control Handbook, Second Edition: Control System Applications. CRC Press. pp. 6–15, 6–16. ISBN   9781420073614.