bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)


SWE-026 - Commitment Change Agreements

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. 

Class

  A_SC 

A_NSC

  B_SC 

B_NSC

  C_SC 

C_NSC

  D_SC 

D_NSC

  E_SC 

E_NSC

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

   

    P(C)

   

Key:    A_SC = Class A Software, Safety Critical | A_NSC = Class A Software, Not Safety Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

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, 041 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.8 - 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 relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

6. Lessons Learned

 No Lessons Learned have currently been identified for this requirement.

0 Comments