Glossary


Industrial and Military Standards

A-B-C- D-E-F- G-H-I- J-K-L- M-N-O- P-Q-R- S-T-U- V-W-X- Y-Z

Identification

Industrial and Military Standards

Definitions/Uses

2001
Reference /Scacchi, 2001/ Process Models in Software Engineering

Definition/
Use Industrial firms often adopt some variation of the classic model as the basis for standardizing their software development practices /Royce, 1970/, /Boehm, 1976/, /Distaso, 1980/, /Humphrey, 1985/, /Scacchi, 1984/, /Sommerville, 1999/. Such standardization is often motivated by needs to simplify or eliminate complications that emerge during large software development or project management.
From 1970's through the present, many government contractors organized their software development activities according to succession of military software standards such as MIL-STD 2167A, MIL-STD-498, and IEEE-STD-016. ISO 12207 /Moore, 1997/ is now the standard that most such contractors now follow. These standards are an outgrowth of the classic life cycle activities, together with the documents required by clients who procure either software systems or complex platforms with embedded software systems. Military software system are often constrained in ways not found in industrial or academic practice, including:

(1) required use of military standard computing equipment (which is often technologically dated and possesses limited processing capabilities);

(2) are embedded in larger systems (e.g., airplanes, submarines, missiles, command and control systems) which are mission-critical (i.e., those whose untimely failure could result in military disadvantage and/or life-threatening risks);

(3) are developed under contract to private firms through cumbersome procurement and acquisition procedures that can be subject to public scrutiny and legislative intervention; and

(4) many embedded software systems for the military are among the largest and most complex systems in the world /Moore, 1997/. Finally, the development of custom software systems using commercial off-the-shelf (COTS) components or products is a recent direction for government contractors, and thus represents new challenges for how to incorporate a component-based development into the overall software life cycle. Accordingly, new software life cycle models that exploit COTS component will continue to appear in the next few years.
In industrial settings, standard software development models represent often provide explicit detailed guidelines for how to deploy, install, customize or tune a new software system release in its operating application environment. In addition, these standards are intended to be compatible with provision of software quality assurance, configuration management, and independent verification and validation services in a multi-contractor development project. Early efforts in monitoring and measuring software process performance found in industrial practice appear in /Humphrey, 1985/, /Radice, 1985/, /Basili, 1988/. These efforts in turn help pave the way for what many software development organizations now practice, or have been certified to practice, software capability assessments, following the Capability Maturity Method developed by the Software Engineering Institute /Paulk, 1995/.

Rationales The author classifies Incremental Development as one of the traditional software life cycle models

2001
Reference	/Scacchi, 2001/ Process Models in Software Engineering
Definition/ Use	Industrial firms often adopt some variation of the classic model as the basis for standardizing their software development practices /Royce, 1970/, /Boehm, 1976/, /Distaso, 1980/, /Humphrey, 1985/, /Scacchi, 1984/, /Sommerville, 1999/. Such standardization is often motivated by needs to simplify or eliminate complications that emerge during large software development or project management. From 1970's through the present, many government contractors organized their software development activities according to succession of military software standards such as MIL-STD 2167A, MIL-STD-498, and IEEE-STD-016. ISO 12207 /Moore, 1997/ is now the standard that most such contractors now follow. These standards are an outgrowth of the classic life cycle activities, together with the documents required by clients who procure either software systems or complex platforms with embedded software systems. Military software system are often constrained in ways not found in industrial or academic practice, including: (1) required use of military standard computing equipment (which is often technologically dated and possesses limited processing capabilities); (2) are embedded in larger systems (e.g., airplanes, submarines, missiles, command and control systems) which are mission-critical (i.e., those whose untimely failure could result in military disadvantage and/or life-threatening risks); (3) are developed under contract to private firms through cumbersome procurement and acquisition procedures that can be subject to public scrutiny and legislative intervention; and (4) many embedded software systems for the military are among the largest and most complex systems in the world /Moore, 1997/. Finally, the development of custom software systems using commercial off-the-shelf (COTS) components or products is a recent direction for government contractors, and thus represents new challenges for how to incorporate a component-based development into the overall software life cycle. Accordingly, new software life cycle models that exploit COTS component will continue to appear in the next few years. In industrial settings, standard software development models represent often provide explicit detailed guidelines for how to deploy, install, customize or tune a new software system release in its operating application environment. In addition, these standards are intended to be compatible with provision of software quality assurance, configuration management, and independent verification and validation services in a multi-contractor development project. Early efforts in monitoring and measuring software process performance found in industrial practice appear in /Humphrey, 1985/, /Radice, 1985/, /Basili, 1988/. These efforts in turn help pave the way for what many software development organizations now practice, or have been certified to practice, software capability assessments, following the Capability Maturity Method developed by the Software Engineering Institute /Paulk, 1995/.
Rationales	The author classifies Incremental Development as one of the traditional software life cycle models

Identification

Definitions/Uses

See also