The title of this page has been changed. If you are using a bookmark to get here, please updated it.
You should be redirected to https://swehb.nasa.gov/display/SWEHBVD/7.05+-+Work+Breakdown+Structures+That+Include+Software. If you do not get there in 2 seconds, click the link to go there.
See edit history of this section
Post feedback on this section
1. Purpose
Provide guidance on the development of a work breakdown structure (WBS) for software on projects. The WBS provides a common planning framework to use in estimating the scope of a project.
2. Definition
Per the NASA Systems Engineering Handbook 273 (Section 6.1.2.1), a work breakdown structure is a hierarchical breakdown of the work necessary to complete a project. The WBS can be product- or process-oriented. A product-oriented WBS has work activities grouped by the product or service they support. A process-oriented WBS includes in the appropriate WBS element the work activities associated with the processes being used. 389 The WBS provides the framework to plan, organize, and control a project. 388
Excellent information on the development and usage of the WBS can be found in NASA/SP-2010-3404, NASA Work Breakdown Structure (WBS) Handbook. 390 Additionally, both the NASA Systems Engineering Handbook 273 and the "CMMI for Development, Guidelines for Process Integration and Product Improvement" 388 provide further guidance on the development of WBS structures containing software. The NASA Software Engineering curriculum, especially 389, addresses the use of the WBS for software on projects. These resources are cited in the Resources tab.
3. The Basic WBS
A project's software may be a stand-alone system or exist as part of a larger system or project. For example, for a space flight project, the software may be shown under the Avionics subsystem. For both types, the WBS developer needs to be aware of the responsibilities required of his or her project.
As another example consider the following list-oriented approach to a WBS. Again, the use of NASA/SP-2010-3404, NASA Work Breakdown Structure (WBS) Handbook, 390 will help in the development of the lower levels of the WBS elements.
- SW Management (incl. budget, schedule, contractor mgmt, risk, CM, training, IV&V coordination, lesson learned, etc.)
- SW Requirements Management
- SW Testbed Management
- CSCI Development
- CSCI Test
- CSC Test
- Sustaining Engineering
- Security (physical and IT)
The project's software may also be developed in the context of a product-driven structure. Lower level development of the WBS will include the approach to software development for the individual component or system to be produced in the sub-element. The following figure suggests several approaches for this type of WBS.
The WBS is updated iteratively over the project life cycle. The initial WBS is used for early estimating of cost and schedule. The detailed WBS helps organize and control the work done by populating the project's cost plans and schedule.
A companion WBS dictionary, which is also developed, fully describes the work being done including the title and objective of the element, expected products/services from each element, and the dependencies between elements.
The Software Development Plan (5.08 - SDP-SMP - Software Development - Management Plan) is a place to record the WBS of the life cycle processes and activities.
3.1 Additional Guidance
Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.
4. Common Issues
There are several work activities that are often forgotten in developing the WBS:
- Process planning and monitoring activities - see SWE-013 - Software Plans, SWE-024 - Plan Tracking, SWE-018 - Software Activities Review
- Requirement engineering activities
- Formal review activities - see SWE-037 - Software Milestones
- Development activities
- Stakeholder activities
- Training activities
- Planning, documenting, and tracking of commitments from other organizations see SWE-046 - Supplier Software Schedule.
4.1 Additional Guidance
Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.
5. Resources
5.1 References
- (SWEREF-157) CMMI Development Team (2010). CMU/SEI-2010-TR-033, Software Engineering Institute.
- (SWEREF-273) NASA SP-2016-6105 Rev2,
- (SWEREF-276) NASA-GB-8719.13, NASA, 2004. Access NASA-GB-8719.13 directly: https://swehb.nasa.gov/download/attachments/16450020/nasa-gb-871913.pdf?api=v2
- (SWEREF-388) Chrissis, M.B., et al. (March, 2011). SEI Series in Software Engineering. Addison-Wesley Professional. CMMI-DEV model version 1.3
- (SWEREF-389) Course from APPEL: Academy of Program/Project & Engineering Leadership.
- (SWEREF-390) NASA SP-2010-3404, NASA Headquarters. January 2010.
5.2 Tools
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
5.3 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
Related Links |
---|
5.4 Center Process Asset Libraries
SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki 197
See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).
SPAN Links |
---|
6. Lessons Learned
6.1 NASA Lessons Learned
No Lessons Learned have currently been identified for this requirement.
6.2 Other Lessons Learned
No other Lessons Learned have currently been identified for this requirement.