3.4 Documenting the Project's Defined Software Process

3.4.1 Documenting the Tailoring Decisions in a Compliance Agreement

A compliance agreement typically is used within an organization to document a project's defined software process. This agreement documents the tailoring decisions derived through the process described in Paragraph 3.3. In general, compliance statements document tailoring decisions by exception using statements of the form: "Project X will conform with the organization's standard software process except for the following provisions."

A waiver is generated when required building blocks are deleted from the project's defined software process, when the contents of any building block(s) are modified in significant ways (as defined for each organization), or when new or previously unapproved building blocks are used in a project's defined software process.[7] When reviewing waiver requests, it is important to ensure that measurement is not deleted from the project's defined software process. Measurement helps ensure that the organization will have visibility into the software project for project oversight, product tracking, and process compliance.

The compliance agreement is reviewed and approved by managers who have the authority to grant tailoring decisions for the organization's standard software process and/or, typically, the SEPG. The compliance agreement then forms the process-related foundation for the software development plan.

3.4.2 Documenting the Project's Defined Software Process in a Plan

The final step in documenting the project's defined software process is to record the process in a software development plan. Both military and commercial standards provide templates for software development plans. An organization usually chooses (or develops) a software development plan template and uses the template as a standard outline.[8]

Three items that help with the plan are Work Breakdown Structures (WBSs), schedules, and activity networks. These items support the evolution of the plan, and ultimately become part of it. When the work is identified and defined in the WBS, schedule, and activity network, the software development plan can be completed based on the work definitions, the process to be implemented, and the resource plan for project completion.

3.4.2.1 Organizing the Work

The work to be done usually is organized into work packages that are mapped into a WBS [LAKE93]. A WBS traditionally was used as a cost-reporting structure, but it is more effective when used as a road map for managing a project. A WBS has two parts: a product part and a process part. The product part is defined through the breakdown of a system into subsystems, configuration items, and other subelements of the system. The product is usually defined top down through the WBS. Processes are defined to support each level of the product breakdown. The processes usually are shown as an activity-based decomposition of the product at a level that will be defined and managed as a project. Each level of the WBS shows more detail concerning parts of the product and the processes that will be executed to produce (or support) the product (from the system level down to the smallest subelement identified on the WBS). When shown as a block diagram, as in the simplified example in Figure 3-3, the WBS can provide a decomposition of the products and processes at whatever level is required to develop, produce, and support a system. Guidelines for building a software project WBS follow (derived from [LAKE93]):

a. Show all software project work at a level that can be used for software project tracking and reporting. The WBS must provide the information that allows the project manager to extract progress measurement (technical, cost, and schedule) for the project's required status reporting.

b. Include products, events (e.g., reviews and audits), and processes (e.g., software qualification) that will show visibility into software development, testing, deployment, training, and life cycle support (as required).

c. Assign WBS elements so that they can support risk assessment, engineering change proposal evaluation, contract change evaluation, interface management, data management, and configuration control.

d. Provide the ability to extract costs for separate types of software work effort (e.g., prototype, full scale development, maintenance).

e. Ensure that the WBS is compatible with the available project resources (e.g., staff) and organization (e.g., independent qualification testing).

Additional guidance on constructing and using a WBS can be found in MIL-STD-881B.

Figure 3-3. Simplified example software WBS.

3.4.2.2 Documenting the Schedule

The most popular representation of a project schedule is in the form of a Gantt chart. This form provides a visual description of the duration and sequence of project activities. (Figure 3-4 shows a Gantt chart that reflects the WBS presented in Figure 3-3.) Schedules like this one depict the time ordering of events but lack the ability to show interrelationships and dependencies explicitly. When kept updated with progress information, the project schedule provides inputs for specific forms of project tracking such as earned value and the Cost and Schedule Status Report (CSSR).

Figure 3-4. Example software schedule with WBS elements.

3.4.2.3 Developing the Activity Network

When the schedule is related to the WBS, as in Figure 3-4, the schedule sequence begins to show possible relationships and dependencies among project activities. These relationships and dependencies are shown explicitly in an activity network like the one shown in Figure 3-5. Activity networks are an outgrowth of the Project Evaluation and Review Technique (PERT) and the Critical Path Method (CPM) which, in addition to showing time dependencies, highlight sequence dependencies on a critical path. The value of showing an activity network with the critical path is that activities that rely on other activities for completion and/or have special time or resource limitations are highlighted for management tracking and oversight.

3.4.2.4 Completing the Software Development Plan

Section 3.3 identified four options for using individual process building blocks for a specific project. For each option, the following rules should be applied to document the project's defined software process in the software development plan:

a. When using a building block as is, reference it from the plan rather than repeating it to ensure the project's consistency with the organization's standard software process.

b. When a building block needs to be tailored, apply the specific guidance from the compliance agreement, and either

1. Document the exceptions to the building block in the plan, or

2. Rewrite the building block in the plan and explicitly mark the modifications.

Also, reference the compliance agreement in the plan.

Figure 3-5. Example activity network.

c. When a building block is waived, note in the applicable paragraph of the plan that the building block is "not applicable" and reference the compliance agreement.[9]

d. When a building block is replaced by a nonstandard building block, write the replacement building block in the plan at the applicable paragraph or reference the replacement building block.[10] Also, reference the compliance agreement in the plan.

The project's defined software process is documented or referenced in the software development plan. In general, software development plans present software process information in a logical order. Table 3-3 is a two-level table of contents for a software development plan based on the requirements of MIL-STD-498. This software development plan is organized as follows:

a. An introduction to the system and the document. (Section 1)

b. References. (Section 2)

c. Project information, constraints, and external requirements. (Section 3)

d. An overview of the software process and general plans for the project. (Section 4)

e. Detailed process descriptions for the software project, i.e., the project's defined software process. (Section 5)

f. Details of the schedule and activity network. (For clarity, the schedule and activity networks should be tied to the WBS.) (Section 6)

g. Project organization and resource information, e.g., organization charts, personnel, facilities, etc. (Section 7)

Table 3-3. Example SDP Table of Contents.

1. SCOPE 1.1 Identification 1.2 System Overview 1.3 Document Overview 1.4 System Overview 2. REFERENCE DOCUMENTS 2.1 Government Documents 2.2 Non-Government Documents 3. OVERVIEW OF REQUIRED WORK 3.1 System and Software Requirements and Constraints 3.2 Project Documentation Requirements and Constraints 3.3 Project Position in the System Life Cycle 3.4 Selected Program/Acquisition Strategy or Associated Requirements and Constraints 3.5 Project Schedule and Resource Requirements and Constraints 3.6 Other Requirements and Constraints 4. PLANS FOR PERFORMING GENERAL SOFTWARE DEVELOPMENT ACTIVITIES 4.1 Software Development Process 4.2 General Plans for Software Development 5. PLANS FOR PERFORMING DETAILED SOFTWARE DEVELOPMENT ACTIVITIES 5.1 Project Planning and Oversight 5.2 Establishing a Software Development Environment 5.3 System Requirements Analysis 5.4 System Design 5.5 Software Requirements Analysis 5.6 Software Design 5.7 Software Implementation and Unit Testing 5.8 Unit Integration and Testing 5.9 CSCI Qualification Testing 5.10 CSCI/HWCI Integration Testing 5.11 System Qualification Testing 5.12 Preparing for Software Use 5.13 Preparing for Software Transition 5.14 Software Configuration Management 5.15 Software Product Evaluation 5.16 Software Quality Assurance 5.17 Corrective Action 5.18 Joint Technical and Management Reviews 5.19 Other Software Development Activities 6. SCHEDULES AND ACTIVITY NETWORK 7. PROJECT ORGANIZATION AND RESOURCES 7.1 Project Organization 7.2 Project Resources

The WBS, schedule, and activity network show the process relationships and the implementation sequence to be used for the project, as shown in Figures 3-3 through 3-5; they provide the basis for measuring project progress in relationship to the project plans. In its totality, the software development plan provides the foundation for measuring project progress, processes, and products.