4.4.1 Documenting the Tailoring Decisions
The changes to the organization's standard software process are relatively minor for this project. As discussed in Paragraph 3.4.1, the deviations can be documented by exception in a compliance agreement. In this case, the following tailoring is applicable:
a. Choose the waterfall model from the three available software life cycles.
b. Delete the allocated baseline (SRS and IRS) from the SCM practices and refer to internal control processes.
c. Add external control of the software development plan to the SCM practices.
d. Modify review requirements to reflect only in-process reviews with the acquirer.
e. Modify the metrics practices to add external distribution of metrics data to the acquisition organization.
In practice, these modifications need to be made with references to the document names and paragraph numbers that will need to be modified or deleted to reflect the tailoring. Additions can be made through descriptions of the changes and document references.
4.4.2 Incorporating the Project's Defined Software Process in a Plan
4.4.2.1 Organizing the Work
The first step in developing the software development plan is to examine the system WBS and determine the level of detail needed to identify the processes that will be employed to run the project. In the case of the GPS/CDU Upgrade program for XDEVEL, program's products can be decomposed as shown in Figure 4-2 to get to the GPS Interface and Communications Software Project, which is the project name for the example presented in this section.[11]
The software project then is decomposed into the processes that will be employed to run the project. In this case the major processes are project management, software development support, software development, software qualification, and post-development support. Then these processes are broken down into their respective elements to show more detail in how the project will be run. For example, the software development and qualification items show a decomposition that is consistent with the waterfall life cycle chosen for this project, as discussed in Paragraphs 4.3 and 4.4.1. The WBS decomposition is complete when it is determined that resource allocation, costs, and schedules can be tracked based on the work definitions shown in the WBS and an associated work breakdown description.
4.4.2.2 Documenting the Schedule
At this point, a schedule estimate needs to be documented based on the WBS. Figure 4-3 is a Gantt chart based on the WBS decomposition of the GPS Interface and Communications Software Project (starting with WBS element 1222).
4.4.2.3 Developing the Activity Network
When the schedule is completed, the activity network can be documented to show the dependencies among the activities identified in the WBS. Figure 4-4 is a simplified activity network based on the WBS and schedule provided in Figures 4-2 and 4-3.
The final planning steps are to record the processes, activities, and plans in the software development plan as discussed in Paragraph 4.4.2.4.
4.4.2.4 Completing the Software Development Plan
Paragraph 3.4.2.4 discussed the options for documenting the modifications to the building blocks in the software development plan. For the GPS Interface and Communications Software Project, three building blocks will be modified and a fourth will use one of the three life cycle options documented in the XDEVEL organization's standard software process. All other building blocks will be used as is.
Figure 4-2. GPS Interface and Communications Project WBS.
Figure 4-3. GPS Interface and Communications Project Gantt chart.
To document the project's defined software process in a software development plan using the outline identified in Table 3-3, the tailoring for the XDEVEL building blocks can be documented in the following ways:
a. Reference to the life cycle adopted for this project from the standard building blocks could be made in the software development plan, Paragraphs 3.3 or 4.1 (or their subparagraphs).
b. Modifications to the SCM practices to cover deletion of the allocated baseline and addition of external configuration control for the software development plan should be documented in the software development plan, Paragraph 5.14 (or its subparagraphs).
Figure 4-4. GPS Interface and Communications Project activity network.
c. Modifications to the review requirements to reflect only in-process reviews should be documented in Paragraph 5.18 (or its subparagraphs).
d. Modifications to the metrics practices for external distribution of metrics data should be documented in the subparagraphs for Paragraph 5.19 that deal with metrics.
Where no building block exists to cover a specific process area in the software development plan, that information will need to be generated. For example, XDEVEL does not have a process building block for establishing the software development environment; this will need to be documented in Paragraph 5.2 of the software development plan. Building blocks used as is should be referenced from the appropriate paragraphs in the software development plan (e.g., the SQA practices will be referenced from Paragraph 5.16 rather than repeated).
The WBS, schedule, and activity network provide inputs for Paragraphs 3.4, 4.2, and Section 6. The remainder of the plan is developed specifically to address the unique requirements of this project, e.g., the overview of the work and constraints on it that are covered in the paragraphs of Section 3 and the organization information presented in Section 7.
The plan, when completed, defines the work to be done, constraints on the work, and the processes used to complete the work. This information then is used to manage the project and to provide the foundation for measuring project progress, process conformance, and selected product measures.
No comments:
Post a Comment