bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin


{alias:SWE-074} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1. Requirements
Wiki Markup
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned


Div
idtabs-1

1. Requirements

3.5.1

The

project

shall

document

the

software

maintenance

plans

in

a

Software

Maintenance

Plan

document.

h2. {color:#003366}{*}

1.1

Notes{*}{color} The requirement for the content of a Software Maintenance Plan is defined in Chapter 5 \[of NPR 7150.2\] h2. 1.2 Applicability Across Classes Class G is labeled with

Notes

The requirement for the content of a Software Maintenance Plan is defined in Chapter 5 [of NPR 7150.2, NASA Software Engineering Requirements, Section 5.1.4].

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.

{applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=1|dnsc=0|esc=1|ensc=0|f=1|g=p|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale Per NPR 7150.2, "Planning for operations, maintenance, and retirement must be considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement...The Software Maintenance Plan provides insight into the method, approach, responsibility, and processes to be followed for maintenance of software and its associated documentation." {div3} {div3:id=tabs-3} h1. 3. Guidance The software maintenance plan describes operations, maintenance, and retirement activities (see the guidance in this handbook for [SWE-075|display/7150/SWE-075]).  The maintenance plan is typically a separate plan, but may be part of another project document such as the Software Management Plan (SMP). For existing processes that may be used during operations, maintenance, and retirement, the maintenance plan may simply reference existing project documents that describe those processes. One key goal of the software maintenance plan is to document the plans for maintaining a piece of software, especially in the case that an organization assumes responsibility for maintaining a piece of software developed by another organization.   The maintenance plan is not intended, however, to require updates to other planning documents from the software development life cycle, such as the software development plan.  The maintenance plan becomes the planning document for the maintenance phase of the software life cycle. See [SWE-105|display/7150/SWE-105] in this handbook for guidance on required maintenance plan contents, but consider the following topics as well when developing the maintenance plan, as appropriate for the particular project: +Operations+ * Mission support procedures for troubleshooting software problems{^}1^ * Test of ground displays and software during mission sequence tests or other end-to-end tests{^}1^ * Software support as required by the operations support facility{^}1^ * Software safety (if not addressed in the software safety plan)^4^ * Performance assessments, as applicable{^}7^ * Training for replacement operators and maintainers{^}7^ +Maintenance+ * Corrective maintenance for software defects{^}1^ * Adaptive maintenance for "software changes necessitated by other changes, usually to the hardware" ^1^ * Changing requirements maintenance{^}1^ * Operational data maintenance to support system configuration changes needed to use the software{^}1^ * Maintenance after new revisions of the software are released * Software safety (if not addressed in the software safety plan) ^4^ * Updates to operations and user manuals, traceability matrices{^}5^ * User notification of updates{^}6^ +Retirement+ * Archival of project software products{^}1^ * Archival of project metrics data{^}1^ * Software safety (if not addressed in the software safety plan) ^4^ * User notification of retirement{^}6^ * Decommissioning and disposal{^}7^ * Capture of Lessons Learned{^}7^ +Other+ * Disposition of COTS components (source code, licenses, etc.)^2^ * Support, if required from a contracted developer (established via contract or other agreement) * Support tools required for operations, maintenance, retirement activities, including how to address obsolescence of any such tools over the operational life of the project * Allocation of responsibilities for operations support, maintenance, retirement activities{^}7^ Once the maintenance plan is created, it should be peer reviewed and reviewed at project milestone reviews such as the Mission Concept Review (MCR), Software Requirements Review (SwRR), Mission Definition Review (MDR), etc. (see section [7.4 - Maturity of Lifecycle Products at Milestone Reviews|display/7150/7.4+-+Maturity+of+Lifecyle+Products+at+Milestone+Reviews] in this handbook).   {panel}Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to documenting the maintenance plan. {panel} Additionally, guidance related to maintenance plans may be found in the following requirements in this handbook: | [SWE-075|display/7150/SWE-075] | Plan operations, maintenance, and retirement | | [SWE-076|display/7150/SWE-076] | Implement Operations, Maintenance and Retirement Activities | | [SWE-105|display/7150/SWE-105] | Software Maintenance Plan | \\ {div3} {div3:id=tabs-4} h1. 4. Small Projects For projects with limited staff or budgets, consider adapting a maintenance plan from a similar project making sure to update the plan to reflect the current project's operations, maintenance, and retirement plans.  The contents of a maintenance plan can also be addressed as sections in another project document and is not required to be in a separate document. {div3} {div3:id=tabs-5} h1. 5. Resources # Flight and Ground Software Division, MSFC, "\[Software Development Process Description Document\|[https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499471%2FSDPDD_Rev%2BQ_080207.pdf|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499471%2FSDPDD_Rev%2BQ_080207.pdf]\]", EI32-OI-001, Revision R, 2010. # Software Engineering Division (SED), Goddard Space Flight Center, "[Checklist for the Contents of Software Critical Design Review (CDR)|http://software.gsfc.nasa.gov/AssetsApproved/PA2.3.2.5.doc]", 580-CK-008-02, 2010. # NASA Technical Standard, [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130], NASA-STD-8739.8, 2004. # NASA Technical Standard, "[NASA Software Safety Standard|https://standards.nasa.gov/documents/detail/3314914]", NASA-STD-8719.13B, 2004. # NASA Technical Standard, "[NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126]", NASA-GB-8719.13, 2004. # IEEE Computer Society, "[IEEE Standard for Software Verification and Validation|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1488512]", Chapter 7, IEEE STD 1012-2004, 2004.  This link requires an account on the NASA START (AGCY NTSS) system ([http://standards.nasa.gov|http://standards.nasa.gov/]).  Once logged in, users can access Standards Organizations, IEEE and then search to get to authorized copies of IEEE standards. # NASA Scientific and Technical Information (STI), NASA Center for AeroSpace Information, "[NASA Systems Engineering Handbook|http://www.ap233.org/ap233-public-information/reference/20080008301_2008008500.pdf]", NASA/SP-2007-6105, Rev1, 2007. # Boeing, "\[Software Maintenance\|[https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499403%2FBoeing_333.doc|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499403%2FBoeing_333.doc]\]", Houston Procedure, HOU-EGP-333, 2002. h2. 5.1 Tools {panel}Tools relative to this SWE may be found in the table above. If no tools are listed, none have been currently identified for this SWE. You may wish to reference table XYZ i 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.* {panel} {div3} {div3:id=tabs-6} h2. 6. Lessons Learned The NASA Lesson Learned database contains the following lessons learned related to maintenance planning: * *Computer Hardware-Software/Software Development Tools/Maintenance*: "NASA concurs with the finding that no program-wide plan exists addressing the maintenance of COTS software development tools. A programmatic action has been assigned to develop the usage requirements for COTS/ modified off-the-shelf software including the associated development tools. These guidelines will document maintenance and selection guidelines to be used by all of the applicable program elements."  ([http://www.nasa.gov/offices/oce/llis/1128.html|http://www.nasa.gov/offices/oce/llis/1128.html]) * *Maintenance Agreements*: "Solidify long-term source code maintenance and incident investigation agreements for all software being developed by the International Partners as quickly as possible, and develop contingency plans for all operations that cannot be adequately placed under NASA's control." ([http://www.nasa.gov/offices/oce/llis/1153.html|http://www.nasa.gov/offices/oce/llis/1153.html])\\ {div3} {tabclose}

applicable
f1
gp
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnsc0
dsc1
ensc0
 



Div
idtabs-2

2. Rationale

Per NPR 7150.2, "Planning for operations, maintenance, and retirement must be considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement...The Software Maintenance Plan provides insight into the method, approach, responsibility, and processes to be followed for maintenance of software and its associated documentation."


Div
idtabs-3

3. Guidance

The software maintenance plan describes operations, maintenance, and retirement activities (see the guidance in this Handbook for SWE-075). The maintenance plan is typically a separate plan, but may be part of another project document such as the Software Management Plan (SMP). For existing processes that may be used during operations, maintenance, and retirement, the maintenance plan may simply reference existing project documents that describe those processes.

One key goal of the software maintenance plan is to document the plans for maintaining a piece of software, especially in the case that an organization assumes responsibility for maintaining a piece of software developed by another organization. The maintenance plan is not intended, however, to require updates to other planning documents from the software development life cycle, such as the software development plan. The maintenance plan becomes the planning document for the maintenance phase of the software life cycle.

The maintenance plan generally has minimal content at the beginning of a project and becomes more complete and mature as the software life-cycle proceeds. This handbook provides the recommended maturity of the maintenance plan at major milestone reviews (see 7.8 - Maturity of Life Cycle Products at Milestone Reviews).

See SWE-105 in this Handbook for guidance on required maintenance plan contents, but consider the following topics as well when developing the maintenance plan, as appropriate for the particular project:

Operations

  • Mission support procedures for troubleshooting software problems.
    sweref
    001
    001
  • Test of ground displays and software during mission sequence tests or other end-to-end tests.
    sweref
    001
    001
  • Software support as required by the operations support facility.
    sweref
    001
    001
  • Software safety (if not addressed in the software safety plan).
    sweref
    271
    271
  • Performance assessments, as applicable.
    sweref
    273
    273
  • Training for replacement operators and maintainers.
    sweref
    273
    273

Maintenance

  • Corrective maintenance for software defects.
    sweref
    001
    001
  • Adaptive maintenance for "software changes necessitated by other changes, usually to the hardware."
    sweref
    001
    001
  • Changing requirements maintenance.
    sweref
    001
    001
  • Operational data maintenance to support system configuration changes needed to use the software.
    sweref
    001
    001
  • Maintenance after new revisions of the software are released.
  • Software safety (if not addressed in the software safety plan).
    sweref
    271
    271
  • Updates to operations and user manuals, traceability matrices.
    sweref
    276
    276
  • User notification of updates.
    sweref
    209
    209

Retirement

  • Archival of project software products.
    sweref
    001
    001
  • Archival of project metrics data.
    sweref
    001
    001
  • Software safety (if not addressed in the software safety plan).
    sweref
    271
    271
  • User notification of retirement.
    sweref
    209
    209
  • Decommissioning and disposal.
    sweref
    273
    273
  • Capture of Lessons Learned.
    sweref
    273
    273

Other

  • Disposition of Commercial Off the Shelf (COTS) components (source code, licenses, etc.).
    sweref
    072
    072
  • Support, if required from a contracted developer (established via contract or other agreement).
  • Support tools required for operations, maintenance, retirement activities, including how to address obsolescence of any such tools over the operational life of the project.
  • Allocation of responsibilities for operations support, maintenance, retirement activities.
    sweref
    273
    273

Once the maintenance plan is created, it is peer reviewed and reviewed at project milestone reviews such as the Mission Concept Review (MCR), Software Requirements Review (SwRR), Mission Definition Review (MDR), etc. (see Topic 7.8 - Maturity of Life Cycle Products at Milestone Reviews in this Handbook).  

Note

Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to documenting the maintenance plan.

Additionally, guidance related to maintenance plans may be found in the following related requirements in this handbook:

SWE-075

Plan Operations, Maintenance, Retirement

SWE-076

Implement Operations, Maintenance and Retirement Activities

SWE-105

Software Maintenance Plan



Div
idtabs-4

4. Small Projects

For projects with limited staff or budgets, consider adapting a maintenance plan from a similar project making sure to update the plan to reflect the current project's operations, maintenance, and retirement plans. The contents of a maintenance plan can also be addressed as sections in another project document and is not required to be in a separate document.


Div
idtabs-5

5. Resources

refstable
 

Toolstable

 


Div
idtabs-6

6. Lessons Learned

The NASA Lesson Learned database contains the following lessons learned related to maintenance planning:

  • Computer Hardware-Software/Software Development Tools/Maintenance. Lesson Number 1128: "NASA concurs with the finding that no program-wide plan exists addressing the maintenance of Commercial Off the Shelf (COTS) software development tools. A programmatic action has been assigned to develop the usage requirements for COTS/modified off-the-shelf software including the associated development tools. These guidelines will document maintenance and selection guidelines to be used by all of the applicable program elements."
    sweref
    540
    540
     
  • International Space Station (ISS) Program/Computer Hardware-Software/International Partner Source Code (Maintenance Agreements.) Lesson Number 1153:  The Recommendation states to "Solidify long-term source code maintenance and incident investigation agreements for all software being developed by the International Partners as quickly as possible, and develop contingency plans for all operations that cannot be adequately placed under NASA's control."
    sweref
    543
    543