Overview
In this activity, a work breakdown structure (WBS) is created for the software project. A WBS is a product-oriented tree identifying the hardware, software, studies, services, and other tasks required to achieve an end objective [WBS Student Guide, 1995, p. 12]. The WBS is extremely useful in organizing, budgeting, and scheduling the project, and is continually maintained throughout the software project’s life.
Roles and Responsibilities
The project software manager creates the WBS.
Controls
The Project Plan containing the project-level WBS.
Inputs
The identified computer software configuration items (CSCI).
The Software Configuration Management Plan (SCMP) and the Software Test Plan (STP) (see Appendix E for both plans) for the software project (if available).
The defined software engineering environment (if available).
Procedures
The WBS is iteratively developed. As more information about the software products becomes available, the WBS is updated. The first attempts at building the WBS focus on the products to be delivered, grouped under the CSCIs to be developed. The WBS is updated as plans (e.g., SCMP, STP(s)) are completed, and the software engineering and test environments are identified.
1) The project software manager first reviews the identified CSCIs and the products associated with each of them. The project software manager also reviews the project-level WBS from the Project Plan to determine how the software CSCIs should fit into it.
2) The software WBS is developed (see WBS Student Guide, 1995). The upper-level WBS items should be as product-oriented as possible, showing the CSCIs to be developed and any other products identified for delivery. At lower levels, the internal software products (i.e., to be produced/acquired by and for the software development effort, but not for the customer) are added into the WBS as may be level-of-effort activities. At the low WBS levels, the project software manager may wish to include elements for which a specific job or service is required (e.g., configuration management (CM) of products, software project tracking and oversight). For additional information on WBS development, see [McDermid, 1993, pp. 27/20 - 27/21]. The following is an example of a detailed WBS.
Example:
WBS
1. Project X Software
1.1 Flight Software CSCI
1.1.1 Software Requirements
1.1.2 Software Design (Preliminary)
1.1.3 Software Design (Detailed)
1.1.4 Flight Code
1.1.5 Software Tests
1.2 Ground Support Software CSCI
1.2.1 Software Requirements
1.2.2 Software Design (Preliminary)
1.2.3 Software Design (Detailed)
1.2.4 Code
1.2.5 Software Tests
1.3 Mission Operations CSCI
1.3.1 Software Requirements
1.3.2 Software Design (Preliminary)
1.3.3 Software Design (Detailed)
1.3.4 Code
1.3.5 Software Tests
1.4 Post-mission Data Analysis CSCI
1.4.1 Software Requirements
1.4.2 Software Design (Preliminary)
1.4.3 Software Design (Detailed)
1.4.4 Code
1.4.5 Software Tests
1.5 Software Project Management
1.5.1 Software Project Plans
1.5.1.1 Software Development Plan
1.5.1.2 Software Configuration Management Plan
1.5.1.3 Software Quality Assurance Plan
1.5.1.4 Software Test Plan
1.5.2 Product Configuration Management
1.6 Software Development Tools
1.6.1 Compilers
1.6.2 Test Tools
1.6.3 Management Tools
1.6.4 CASE Tools
1.6.5 Development Platform/Maintenance
3) The detailed WBS is then documented in an appendix of the SDP.
Outputs
The WBS documented in an appendix to the SDP.