Mil Std

This is a landmark standard established by the U.S. Department of Defense (DoD) [10.5], building on an earlier DoD Standard known as Mil-Std-2167A [10.6], which had a major influence on how companies developed software for the DoD as well as for other parts of the government, that is, government civil agencies.

The table of contents for the general requirements for software development is shown in Exhibit 10.1. This exhibit provides an overview of the scope of this standard. Under item 4.1, the detailed software development process is delineated, as shown in Exhibit 10.2.

Exhibit 10.1: General Requirements of DoD Software Standard

4.1 Software development process

4.2 General requirements for software development

4.2.1 Software development methods

4.2.2 Standards for software products

4.2.3 Reusable software products

• Incorporating reusable software products

• Developing reusable software products

4.2.4 Handling of critical requirements

• Security assurance

• Assurance of other critical requirements

4.2.5 Computer hardware resource utilization

4.2.6 Recording rationale

4.2.7 Access for acquirer review

Exhibit 10.2: The Software Development Process a. Project planning and oversight b. Establishing a software development environment c. System requirements analysis d. System design e. Software requirements analysis f. Software design g. Software implementation and unit testing h. Unit integration and testing i. Computer Software Configuration Item (CSCI) qualification testing j. CSCI/Hardware Configuration Item (HWCI) integration and testing k. System qualification testing l. Preparing for software use m. Preparing for software transition n. Integral processes:

(1) Software configuration management

(2) Software product evaluation

(3) Software quality assurance

(4) Corrective action

(5) Joint technical and management reviews

(6) Other activities

From these exhibits, we see the initial focus on the ''system,'' which then moves to the specific software item considerations. The more limited view of the software development process in DoD-Std-2167A is also expanded. Finally, the last item listed (Exhibit 10.2, Other activities) includes:

• Risk management

• Software management indicators

• Security and privacy

• Subcontractor management

• Interface with software independent verification and validation (IV&V) agents

• Coordination with associate developers

• Improvement of project processes

In this standard, software is decomposed into

• Computer software configuration items (CSCIs)

• Computer software components (CSCs)

• Computer software units (CSUs)

which, to a large extent, parallels the decomposition notions previously described in systems engineering. That is, the systems engineer decomposes the system into functions and subfunctions. The view presented in this standard is that the systems (software) engineer breaks down the system into segments. These segments are then broken down into hardware and software configuration items. Once that breakdown is accomplished, the CSCIs are decomposed into CSCs and the CSCs into CSUs. This provides a challenge for the systems engineer, namely, to bring system functional decomposition in conformance with the preceding software breakdown structure. A way to meet that challenge is to associate one or more layers of functional decomposition with the ''segment'' element. Once the lowest level of functional decomposition is attained, then the HWCI and CSCI breakout is entirely appropriate. This issue, at times, represents a disconnect between how systems engineers, in distinction to software engineers, look at and analyze a system that is composed of both hardware and software.

This standard was intended to supercede DoD-Std-2167A by making certain improvements. Particular emphasis was placed on resolving issues in 2167A with respect to the following:

1. Improving compatibility with incremental and evolutionary development methods

2. Improving compatibility with nonhierarchical design methods, that is, object-oriented methods

3. Improving compatibility with computer-aided software engineering (CASE) tools

4. Providing alternatives to, and more flexibility in, the preparation of documentation

5. Providing clearer requirements for incorporating reusable software

6. Including the use of software management indicators

7. Putting more emphasis on software supportability

8. Improving links to systems engineering

Each of these suggests one or more key issues with respect to the overall subject of software development. As such, they are discussed further either later in this chapter or in Chapter 12, which deals with trends in software engineering. It should be noted, however, that this standard makes the explicit statement that it ''is not intended to specify or discourage the use of any particular software development method.'' In addition, and in conjunction with other standards, it ''provides the means for establishing, evaluating, and maintaining quality in software development products.''

10.2.2 DoD-Std-2168

This standard [10.7], dealing with software quality evaluation, represented a companion standard to 2167A. Its basic function was to establish require ments for evaluating the quality of software and associated documentation and activities for mission-critical computer systems. It also may be applied to the independent verification and validation (IV&V) of software.

The essence of this standard was to provide a framework for the preceding evaluation. Evaluation matrices are defined for each of the products of the eight steps identified as part of the software development process. The basic evaluation criteria for this process are:

1. Adherence to required format and documentation standards

2. Compliance with contractual requirements

3. Internal consistency

4. Understandability

5. Technical adequacy

6. Appropriate degree of completeness

7. Traceability to indicated documents

8. Consistency with indicated documents

9. Feasibility

10. Appropriate requirements analysis, design, coding techniques used to prepare item

11. Appropriate level of detail

12. Appropriate allocation of sizing and timing resources

13. Adequate test coverage of requirements

14. Adequacy of planned tools, facilities, procedures, methods, and resources

15. Appropriate content for intended audience

The standard also defines software quality factors that may be included as requirements in the software requirements specification, namely:

• Correctness

• Efficiency

• Flexibility

• Interoperability

• Maintainability

• Portability

• Reliability

• Reusability

• Testability

We also note that this standard called for an evaluation of risk management, expressed in the following manner:

The contractor shall evaluate the procedures employed and the results achieved by risk management throughout the software development cycle. This evaluation shall verify that risk factors are identified and assessed, resources are assigned to reducing risk factors, alternatives for reducing risk are identified and analyzed, and sound alternatives are selected, inplemented and evaluated.

The subject of risk management arises explicitly in the context of a development process known as the Spiral Model, cited again later in this chapter. The matter of software quality is also closely related to reliability, which is also is discussed later in this chapter.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment