bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Error formatting macro: alias: java.lang.NullPointerException
SWE-026 - Commitment Change Agreements
Unknown macro: {div3}

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">1.1 Notes

NPR 7150.2 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

Unknown macro: {div3}

2. Rationale

Whenever baselined software plans (e.g., Software Development/Management Plan, Software Test Plan, Software IV&V Plan) are changed, previous commitments and agreements are likely to be impacted.  Affected parties, whether they are stakeholders or other interested parties1, 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.

Unknown macro: {div3}

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 section 7.4, Maturity of Lifecycle 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.

Unknown macro: {div3}

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.

Unknown macro: {div3}

5. Resources

  1. NASA Systems Engineering Processes and Requirements with Change 1, NPR 7123.1A, 2009
  2. NASA Software Assurance Standard, NASA STD 8739.8, 2005
  3. NASA Space Flight Program and Project Management Requirements, NPR 7120.5D (NM-7120.81), 2009.
  4. NASA Software Formal Inspection Standard, NASA-STD-2202-93, 1993

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.

">

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.

Unknown macro: {div3}

6. Lessons Learned

No lessons learned have been identified for this requirement.

  • No labels