Standard 2168 (DOD 1988b) contains the requirements for the development, documentation and implementation of a software quality program. The software quality program includes planning for and conducting:
Evaluations of the quality of software
Associated documentation and related activities
Follow-up activities necessary to assure timely and effective resolution of problems
The DID s are a comprehensive set of documentation standards that cover all phases of software development, maintenance and the production of user reference manuals. The DID s include a section called preparation instructions that provide a large degree of freedom by permitting tailoring of the document format and the use of alternate presentation styles. The full set of DID s is described in Table 2.
Standard 2167 states that it is not intended to specify or discourage the use of any particular software development method (DOD 1988a). However, as mentioned previously, the standard is heavily inclined toward phased development
172 © Copyright Virtual University of Pakistan
in the required development stages and reviews, requiring system design to be followed by software requirements, software design, implementation and testing. The Data Item Descriptions define the formal documentation standards for all required documents generated during the development of software according to standard 2167. DID s apply to the development of one or more computer system configuration items (CSCI s), a term used throughout the 2167 standard to identify high level decomposition components of a computer system. Table 2: DOD Data Item Descriptions (DID s)
Development documentation
• Software development plan System documentation
• System/segment specification
• System/segment design document Software design and requirements
• Software requirements specification
• Software design document Interface design and requirements
• Interface requirements, specification
• Interface design document Version description
• Version description document Test documentation
• Software test plan
• Software test description
• Test report Release manuals
• Computer system operator's manual
• Software user's manual
• Software programmer's manual
• Firmware support manual
Maintenance documentation and source code
• Computer resources integrated support document
173 © Copyright Virtual University of Pakistan
A CSCI, as applied to software; is a component of the system that can be individually controlled, configured, tested and documented. CSCI s are often reviewed and approved as separate development items, and though a single review or audit can consider more than one CSCI, each is usually addressed separately during the review process. There are no clear-cut guidelines for the division of a software system into CSCI s as the division is essentially one of convenience.
Table 3: DOD Data Item Description standards
Data requirements title Acronym 1. System segment design document SSDD 2.Software development plan SDP 3.Software requirements specification SRS 4. Interface requirements specification IRS 5. Interface design document IDD 6. Software design document SDD 7. Software product specification SPS 8. Version description document VDD
9. Software test plan STP
10. Software test description STD II. Software test report STR 12. Computer system operator's manual CSOM 13. Software user's manual SUM 14. Software programmer's manual SPM 15. Software support manual FSM 16. Computer resources integrated support document CRISD 17. Engineering change proposal ECP 18. Specification change notice SCN
Table 3 contains a list of the DID s referenced by standard 2167A. The software quality DID is referenced separately in the DOD software quality program
standard 2168. All DID document formats follow a similar pattern. Several of the sections are common to most, if not all of the documents, such as:
• Title page format
• Table of contents
• Scope (including identification, overview, references etc.)
• Other applicable documents
174 © Copyright Virtual University of Pakistan
phasis is on the required content and not on the required format. This is specifically addressed in the preparation instructions accompanying each DIn addition, the page format, page numbering scheme, section numbering scheme and various other preparation instructions are common. This clearly suggests the use of an automatic tool to assist in the preparation of the documents, a practice greatly encouraged by the 2167 standard. Many such tools have been developed to support 2167, and Polack, in a paper analyzing the use of CASE tools for DOD projects (Polack 1990), concludes that these tools do indeed save time, and result in a higher quality software system.
Each DID describe the requirements for the preparation of a specific document, but the main emID, which state that other presentation styles, including charts, tables or matrices, are acceptable (e.g. Hatley and Pirbhai (1988) or Ward and Mellor (1986). There is also substantial flexibility in the requirements regarding the content of the documents. The standard provides for considerable tailoring to adapt the standard to the type of project being developed.
Tailoring the standard
Tailoring of standard 2167 is not only encouraged, it is required. The foreword to 2167 states that the standard must be appropriately tailored by the Program Manager to ensure that only cost-effective requirements are cited in defense solicitations and contracts.
The DOD has issued a guide for tailoring that can be used as a reference source for adapting the standards to the type of project being developed. Two basic principles apply to tailoring:
• The tailoring process is the deletion of non-applicable requirements.
• Tailoring of the standard should be carried out by the contracting agency. The first principle means that these modifications can only include the deletion of requirements from the standard (and not changes to the requirements in the standard). The second principle means that the contractor (i.e. the developer) cannot tailor the standard without receiving permission from the contracting agency (i.e. the DOD).
Tailoring of the 2167 standard must be completed as early as possible. This is best performed either during contract negotiations or as one of the initial activities as soon as the project begins. The following is a description of the basic procedure for tailoring standard 2167:
1. Review all standard 2167 requirements, including;
• reviews and audits
175 © Copyright Virtual University of Pakistan
• testing activities
• quality assurance activities
• configuration control activities
• other required development activities
2. Identify the requirements that are not applicable, justifiable or reasonable for the project being developed. For example, the Firmware Support Manual will not be required if no firmware is being developed: or two design reviews (POR and COR) may not be necessary for a small project.
3. Prepare a list of requests for deletions from the standard. This may include:
• exclusion of documents
• exclusion of sections in documents
• exclusion of activities.
• exclusion of parts of activities
4. Prepare a written description of the justifications for each item that is requested to be tailored out.
5. Submit the tailoring request, together with the justification, as early as possible (preferably before the project begins).
In order to be able to differentiate between forgotten items and tailored items, all tailored items must be clearly referenced. When submitting a list of documents for a formal review or milestone, all documents tailored out should be listed together with a statement to that effect. Within a document, when a paragraph is tailored out a statement to that effect will appear directly after the paragraph number. If a paragraph and all of its subparagraphs are tailored out, only the highest level paragraph number need be included.
The list of the DID s together with the list of tailoring approvals are an integral part of the project deliverables. Until tailoring approval has been granted, the developer is obligated to provide the full list of Dills, with all their inclusions. This is the reason why tailoring should be concluded as early as possible. 6. The software configuration management plan (SCMP)
The software configuration management plan (SCMP) is part of the project's software development plan. The SCMP may appear as a separate document or as a section within the project development plan.
The SCMP documents the resources that are needed, how they are to be used, and which standards and procedures will be applied during the project.
176 © Copyright Virtual University of Pakistan
The SCMP then becomes the mandate for the configuration control group during project development. The issuance of this plan is the responsibility of the project manager, though in large projects it may be delegated to the configuration Control manager.
Table 4 contains a list of the main subjects covered in the SCMP. When any of these subjects is covered elsewhere (e.g. in the software quality assurance plan), it can be omitted from the SCMP and replaced by a pointer to the document in which it is covered. Though most of the subjects in Table 1 are self-descriptive, the following are some guidelines:
Configuration status accounting describes the way in which status information flows:
From the developers to the configuration management organization (audits and reviews)
From the configuration management organization to project management (status reporting procedures)
Configuration identification describes the method for designating development items as SCCI s. This is part of the high level decomposition of the system into major development components.
The section on identification methods describes the way in which each component generated by the project is marked for unique identification. Security, restricted access and classification refer to the secure development of sensitive products (such as documents, software, patents, military classified information etc.). It is often convenient to assign many of these tasks to configuration control because of the need to be involved in the review and classification of documents and other related activities that are associated with security.
Subcontractors, vendors and suppliers mayor may not implement their own
configuration management plan. It is the project manager's responsibility to assure that either subcontractors or external developers submit a CMP for review, or that the project's configuration manager assumes responsibility for their work.
The SCMP may also include diagrams and flow charts to describe procedures for submitting change requests, or for reporting problems.