1. Requirements

2.2.15 The project shall ensure that changes to commitments (e.g., software plans) are agreed to by the affected groups and individuals.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement. 

2. Rationale

Whenever baselined software plans ((e.g., Software Development/Management Plan, Software Test Plan, Software Independent Verification and Validation (IV&V) Plan)) are changed, previous commitments and agreements are likely to be impacted.  Affected parties, whether they are stakeholders or other interested parties, ⁰⁴¹ need to be solicited for their concurrence with the new plan. With concurrence comes the commitment to support the revised work plan.  Without commitment, the risk arises that not all elements of the work plan will be performed or completed in a timely manner. The risk may also occur that customers and stakeholders will not accept the final software work products because they no longer meet customer needs and expectations.

3. Guidance

The planning and requirements documentation developed during the early phases of the project guides the development of software work products (e.g., SWE-013, SWE-014, SWE-102, SWE-106, SWE-109,and SWE-131). Project management and the software lead(s) work together to construct software plans that are logical and achievable in the allotted time. The schedules, activities, and applicable resources estimates that result from these plans are submitted for approval and commitment by the relevant stakeholders and the performing organizations.

During the course of the software development life cycle, results can deviate from expectations, and funding or workforce levels may be altered. Baselined requirements (see Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews in this Handbook for phases of the Space Flight Project life cycle at which software plans typically become baselined) changes and work plan revisions become necessary based on these and other factors. Once it becomes clear that plans need to be changed, and/or schedules need to be altered, the software development lead and the relevant stakeholders recommit to these revised plans. The new commitments assure availability of resources and unified expectations regarding the revised project.  

Several avenues exist to obtain formal commitment to changes in plans. First, the change control process requires formal evaluation and agreement and signoff by relevant parties. The software development team must involve all the relevant stakeholders and other interested parties through the exercise of its configuration management change control system (see SWE-082). Less formal methods may be used, e.g., jointly written and signed memos of understanding between or among the various parties involved. The concurrence and signature to these documents is usually sufficient to provide binding commitments. Finally, organizational policies can also provide the required formality. Software development team organizational charters may require the team to automatically support any changes, subject to resource availability, because of Center, Agency, or national priorities. It is still important for the project and software development teams to strive for concurrence and commitment by the customers and stakeholders to mitigate risks engendered by unhappy and dysfunctional team members.

4. Small Projects

Smaller projects may consider using a work tracking system or configuration management tool that provides automatic notification and tracking when updates to documentation occur and rebaselining is necessary. Several small projects have begun using wikis to create and maintain project documentation. Use of a wiki allows those working on the project to be notified of changes as they occur.

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

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.

6. Lessons Learned

 No Lessons Learned have currently been identified for this requirement.