H.1 Scope. This appendix provides guidance to the acquirer on the deliverables to be required on a software development project. This appendix is not a mandatory part of this standard. The information provided is intended for guidance only.
H.2 Applicable documents. This section is not applicable to this appendix.
H.3 Ordering deliverables. MIL-STD-498 has been worded to differentiate between the planning/engineering activities that make up a software development project and the generation of deliverables. A key objective of this wording is to eliminate the notion that the acquirer must order a given deliverable in order to have planning or engineering work take place. Under MIL-STD-498, the planning and engineering work takes place regardless of which deliverables are ordered, unless a given activity is tailored out of the standard. In addition, joint technical reviews have been included to review the results of that work in its natural form, without the generation of deliverables. Deliverables should be ordered only when there is a genuine need to have planning or engineering information transformed into a deliverable, recognizing that this transformation requires time and effort that would otherwise be spent on the engineering effort. Block 3 of each DID provides information helpful in deciding whether the corresponding deliverable should be ordered.
H.4 Scheduling deliverables. MIL-STD-498 has been structured to support a variety of program strategies and to provide the developer flexibility in laying out a software development process that will best suit the work to be done. All of this flexibility can be canceled by rigid scheduling of deliverables on the CDRL. If the CDRL lays out a strict "waterfall" sequence of deliverables, little room is left to propose innovative development processes. If the CDRL forces all CSCIs into lock-step with each other, little room is left to develop the CSCIs in an optimum order. To the maximum extent possible, the CDRL should avoid such pre-determination, leaving the door open for incremental delivery of software products, staggered development of CSCIs, and other variations to optimize the software development effort. The developer's software development plan will lay out a proposed schedule that meets the constraints in the CDRL. Final agreement on scheduling can take place at that time.
H.5 Format of deliverables. Traditional deliverables take the form of paper documents exactly following DID formats. While this form works well for some deliverables, it is not the only form, and alternatives should be considered. One variation from paper documents is word processing files containing those documents. This format saves paper, but still requires the developer to format the information as required by the DID. Another variation is specifying that a paper or word processor document is to include all DID contents but may be in the developer's format. Yet another variation is allowing deliverables to take forms that are not traditional documents at all, such as data in computer-aided software engineering (CASE) tools. These variations in required format can be specified on the CDRL, minimizing the time spent transforming actual work products into deliverables.
H.6 Tailoring the DIDs. Tailoring the DIDs consists of deleting requirements for unneeded information and making other changes that do not increase the required workload, such as combining two documents under one cover. DID tailoring for deliverables is specified in Block 16 of the CDRL.