This appendix identifies three of the program strategies used by DoD and shows how MIL-STD-498 can be applied under each of these strategies and on a project involving reengineering. This appendix is not a mandatory part of the standard. The information provided is intended for guidance only.
Documents cited in this appendix are as follows:
a. DODI 5000.2, Defense Acquisition Management Policies and Procedures
b. DODI 8120.2, Automated Information System Life-Cycle Management Process, Review, and Milestone Approval
DODI 8120.2 describes three basic program strategies plus a generic strategy called "other," encompassing variations, combinations, and alternatives to the three. DODI 5000.2 identifies similar strategies, called acquisition strategies. The three basic strategies are summarized below and in Figure 7.
a. Grand design. The "grand design" strategy (not named in DODI 5000.2 but treated as one strategy) is essentially a "once-through, do-each-step-once" strategy. Simplistically: determine user needs, define requirements, design the system, implement the system, test, fix, and deliver.
b. Incremental. The "incremental" strategy (called "Preplanned Product Improvement" in DODI 5000.2) determines user needs and defines the system requirements, then performs the rest of the development in a sequence of builds. The first build incorporates part of the planned capabilities, the next build adds more capabilities, and so on, until the system is complete.
c. Evolutionary. The "evolutionary" strategy (called "evolutionary" in both DOD Instructions) also develops a system in builds, but differs from the incremental strategy in acknowledging that the user need is not fully understood and all requirements cannot be defined up front. In this strategy, user needs and system requirements are partially defined up front, then are refined in each succeeding build.
The program strategy is selected by the acquirer, but may be proposed by prospective or selected developers. Figure 8 illustrates a risk analysis approach for selecting an appropriate strategy. The approach consists of listing risk items (negatives) and opportunity items (positives) for each strategy; assigning each item a risk or opportunity level of High, Medium, or Low; and making a decision on which strategy to use based on a trade-off among the risks and opportunities. The fill-ins shown are sample considerations only. An actual analysis may use others. The "DECISION" entry on the bottom line shows which strategy was selected.
The program strategy usually applies to the overall system. The software within the system may be acquired under the same strategy or under a different one, such as requiring that all software be finalized in the first build of the system. Figures 9, 10, and 11 show how MIL-STD-498 might be applied under each of the program strategies identified in G.3. Figure 12 shows how MIL-STD-498 might be applied on a reengineering project. All four figures are, by necessity, simplified. For example, they show MIL-STD-498 activities in sequence when they might actually be ongoing, overlapping, or iterative; they show each software product as a single entity, without depicting early drafts or updates; and they represent each software product by the name of the corresponding DID, when the actual software product is the information called for by the DID, not necessarily in the form of a hard-copy document.
Planning the software builds on a project and tailoring MIL-STD-498 for each build may be accomplished in several ways. The acquirer might, for example, select an overall program strategy and tailor the standard for the overall contract, leaving it to the developer to lay out the software builds and propose the tailoring for each build. Alternatively, the acquirer might lay out the software builds and specify the tailoring for each as part of the contract. The approach selected will be project-dependent. The paragraphs below provide guidelines for planning the builds and tailoring the standard without attempting to divide these activities between the acquirer and developer.
The first step in software build planning is to lay out a series of one or more builds and to identify the objectives of each build. The top part of Figure 13 illustrates such planning. In the example, the system/subsystem specification (SSS) already exists and fulfillment of its requirements is divided into four builds, two of which will be prototypes delivered to a selected set of users, and two of which will actually be fielded. A further objective of Build 4 is transitioning the software to the designated support agency. An actual project would expand on these objectives.
The next step in build planning is identifying which MIL-STD-498 activities apply in each build and determining the extent to which they apply. The lower part of Figure 13 shows the start of such planning. Listed on the left are the paragraphs of MIL-STD-498. The worksheet entries indicate in which builds each activity is to be performed and include any notes regarding the nature of each activity in each build. For example, the figure shows that each build will include software development planning (5.1.1), but that the nature of that planning changes in each build. Some activities will not apply at all in a given build, some will apply identically in all builds, and some will apply differently in different builds. Since some aspects of the project, such as number and type of CSCIs, may not have been identified at the time the worksheet is being filled out, completion of the worksheet may itself be incremental. The following guidelines apply:
a. Different decisions will apply to different types of software on a project. These differences can be shown within the entries of one worksheet or by using different worksheets for different types of software on a project.
b. If early builds are devoted to experimentation, developing "throw-away" software to arrive at a system concept or system requirements, it may be appropriate to forgo certain formalities, such as coding standards, that will be imposed later on the "real" software. If the early software will be used later, such formalities may be appropriate from the start. These decisions are project-dependent.
Tailoring decisions made by the acquirer before the project begins are specified in the Statement of Work. Tailoring proposed by the developer may be communicated via feedback on draft solicitations, proposals written in response to solicitations, the software development plan, joint reviews during the project, or by other means of communication. Refinements to the tailoring decisions may be ongoing as the project proceeds. Those involving contractual changes should be handled accordingly.
Another important step in build planning is scheduling the activities in each build. As with tailoring, the acquirer may set forth general milestones and have the developer provide specifics or may provide specific schedules. The following guidelines apply:
a. A common mistake is to treat all CSCIs as though they must be developed in "lock-step," reaching key milestones at the same time. Allowing CSCIs to be on different schedules can result in more optimum development.
b. A similar mistake is to treat software units as though they must be developed in "lock-step," all designed by a certain date, implemented by a certain date, etc. Flexibility in the scheduling of software units can also be effective.
c. The activities in MIL-STD-498 need not be performed sequentially. Several may be taking place at one time, and an activity may be performed continually or intermittently throughout a build or over multiple builds. The activities in each build should be laid out in the manner that best suits the work to be done.
Translator: Simon Wright simon@pogner.demon.co.uk
Last updated: 22.iii.99