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-075} {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.2

The

project

shall

plan

software

operations,

maintenance,

and

retirement

activities.

h2. {color:#003366}{*}

1.1

Notes{*}{color} NPR

Notes

NPR 7150.2

does not include any notes for this requirement. h2.

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

1.2

Applicability

Across

Classes

Class

G

is

labeled

as

"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 Marshall Space Flight Center's "Software Development Process Description Document", "The Software Operation phase spans the time from execution of the software product in the target environment to software retirement. The Software Maintenance phase of the software life cycle begins after successful completion of formal test and delivery of the software product to the customer. This Software Maintenance phase overlaps the Software Operation phase and continues until software retirement or discontinuation of software support."{sweref:001} As with any activity that builds on and relies on previous activities, software operations, maintenance, and retirement requires planning before implementation. The team documents and review those plans before they are implemented to allow its members to consider all the tasks, personnel, methods, tools, facilities and related criteria needed to perform those activities. {div3} {div3:id=tabs-3} h1. 3. Guidance The results of planning for operations, maintenance and retirement of software are captured in the Software Maintenance Plan for implementation. In addition to the required contents for the Software Maintenance Plan ([SWE-105|SWE-105]) and the items listed in this handbook's guidance for requirement [SWE-074|SWE-074], consider the following items for each phase of planning, keeping in mind that operations and maintenance are most often conducted in parallel: +Operations+ * Software team support of operations, including help desk activities, as applicable * Documentation required for operations support (e.g., as-built documentation, user's manual, source code, operations notes) * Tools required for operations support (e.g., email systems, servers) * Availability of problem reporting and corrective action (PRACA) system during operations * Participation in mission debriefs, as appropriate{sweref:001} * Capturing of lessons learned during operations * Software assurance, including software safety, monitoring activities * Operational backups (e.g., hot backups for critical systems), including identification and planning of approach +Maintenance+ * Modification of software after delivery * Updates to system and software documentation to align with/reflect these modifications * Availability and use of a configuration management system for documenting, reviewing, analyzing modifications to code, documentation, and hardware test configurations * Tools required for maintenance activities (e.g., issue tracking systems, analysis tools, configuration control systems, compilers) * Other resources required to perform maintenance activities such as documentation, development environment, test environment * Testing of modifications (including pre\- and post-delivery) * Delivery and installation of modifications, including generation of associated documentation such as version description documents (VDD) * Capture of maintenance metrics{sweref:001} * Maintenance transition plan * Software assurance and software safety activities for updates +Retirement+ * Archival of software products, including capture in a configuration management system{sweref:001} * Retention period for retired software products{sweref:001} * Tools needed to complete retirement activities (e.g., configuration management system) * Security measures for access to and use of retired software products * Transition plans for functionality and data if software being retired is being replaced by another software product The following personnel roles need to be considered for involvement in the planning of operations, maintenance, and retirement activities: * Software project lead * Software team * Project manager * Software quality engineer (not involved in planning, but in checking on planned activities) * Configuration management officer (role may not exist on all projects) Planning for maintenance activities, in particular, need to begin very early in the software development life cycle so that the software is designed for maintainability{sweref:276}. For NPR 7120.5 projects, this Handbook provides the recommended maturity of the Software Maintenance Plan at major milestone reviews (see [Maturity of Life cycle Products at Milestone Reviews|http://nasa7150.onconfluence.com/display/7150/7.4+-+Maturity+of+Life+Cycle+Products+at+Milestone+Reviews]). The lifetime of use for software is not always known, so maintenance becomes easier if the software is designed with maintenance in mind. If there are specific design features that facilitate easier maintenance, those may be candidates for referencing in the Software Maintenance Plan. {note}Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to planning operations, maintenance, and retirement. {note} Additionally, guidance related to operations, maintenance, and retirement planning may be found in the following requirements in this handbook: | [SWE-074|SWE-074] | Document Maintenance Plan | | [SWE-076|SWE-076] | Implement Operations, Maintenance, and Retirement Activities | | [SWE-105|SWE-105] | Software Maintenance Plan | {div3} {div3:id=tabs-4} h1. 4. Small Projects There is currently no guidance specific to small projects for this requirement. {div3} {div3:id=tabs-5} h1. 5. Resources {refstable} \\ {toolstable} {div3} {div3:id=tabs-6} h2. 6. Lessons Learned The NASA Lesson Learned database contains the following lessons learned related to maintenance planning: * *Benefits of Maintainability on NASA Programs. Lesson Number 0835:* "Maintainability requirements for programs that require ground and/or in-space maintenance and anomaly resolution have to be established early in the program to be cost effective. Lack of management support to properly fund maintainability activities up-front can result in increased program risk. Including maintainability in the design process will greatly reduce the number of operational problems associated with system maintenance, improve the availability of the system, and reduce program costs." [(http://www.nasa.gov/offices/oce/llis/0835.html)|http://www.nasa.gov/offices/oce/llis/0835.html] * *Software Design for Maintainability. Lesson Number 0838:* "Because of increases in the size and complexity of software products, software maintenance tasks have become increasingly more difficult. Software maintenance should not be a design afterthought; it should be possible for software maintainers to enhance the product without tearing down and rebuilding the majority of code." [(http://www.nasa.gov/offices/oce/llis/0838.html)|http://www.nasa.gov/offices/oce/llis/0838.html] {div3} {tabclose}


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



Div
idtabs-2

2. Rationale

Per Marshall Space Flight Center's Software Development Process Description Document (EI32-0I-001), "The Software Operation phase spans the time from execution of the software product in the target environment to software retirement. The Software Maintenance phase of the software life cycle begins after successful completion of formal test and delivery of the software product to the customer. This Software Maintenance phase overlaps the Software Operation phase and continues until software retirement or discontinuation of software support."

sweref
001
001

As with any activity that builds on and relies on previous activities, software operations, maintenance, and retirement requires planning before implementation. The team documents and reviews those plans before they are implemented to allow its members to consider all the tasks, personnel, methods, tools, facilities and related criteria needed to perform those activities.


Div
idtabs-3

3. Guidance

The results of planning for operations, maintenance and retirement of software are captured in the Software Maintenance Plan for implementation. In addition to the required contents for the Software Maintenance Plan (SWE-105) and the items listed in this Handbook's guidance for retirement SWE-074, consider the following items for each phase of planning, keeping in mind that operations and maintenance are most often conducted in parallel:

Operations

  • Software team support of operations, including help desk activities, as applicable.
  • Documentation required for operations support (e.g., as-built documentation, user's manual, source code, operations notes).
  • Tools required for operations support (e.g., email systems, servers).
  • Availability of problem reporting and corrective action (PRACA) system during operations.
  • Participation in mission debriefs, as appropriate.
    sweref
    001
    001
  • Capturing of lessons learned during operations.
  • Software assurance, including software safety, monitoring activities.
  • Operational backups (e.g., hot backups for critical systems), including identification and planning of approach.

Maintenance

  • Modification of software after delivery.
  • Updates to system and software documentation to align with/reflect these modifications.
  • Availability and use of a configuration management system for documenting, reviewing, analyzing modifications to code, documentation, and hardware test configurations.
  • Tools required for maintenance activities (e.g., issue tracking systems, analysis tools, configuration control systems, compilers).
  • Other resources required to perform maintenance activities such as documentation, development environment, test environment.
  • Testing of modifications (including pre- and post-delivery).
  • Delivery and installation of modifications, including generation of associated documentation such as version description documents (VDDs).
  • Capture of maintenance metrics.
    sweref
    001
    001
  • Maintenance transition plan.
  • Software assurance and software safety activities for updates.

Retirement

  • Archival of software products, including capture in a configuration management (CM) system.
    sweref
    001
    001
  • Retention period for retired software products.
    sweref
    001
    001
  • Tools needed to complete retirement activities (e.g., CM system).
  • Security measures for access to and use of retired software products.
  • Transition plans for functionality and data if software being retired is being replaced by another software product.

The following personnel roles need to be considered for involvement in the planning of operations, maintenance, and retirement activities:

  • Software project lead.
  • Software team.
  • Project manager.
  • Software quality engineer (not involved in planning, but in checking on planned activities).
  • CM officer (role may not exist on all projects).

Planning for maintenance activities, in particular, needs to begin very early in the software development life cycle so that the software is designed for maintainability

sweref
276
276
. For NPR 7120.5 projects, this Handbook provides the recommended maturity of the Software Maintenance Plan at major milestone reviews (see 7.8 - Maturity of Life Cycle Products at Milestone Reviews). The lifetime of use for software is not always known, so maintenance becomes easier if the software is designed with maintenance in mind. If there are specific design features that facilitate easier maintenance, those may be candidates for referencing in the Software Maintenance Plan.


Note

Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to planning operations, maintenance, and retirement.


Additionally, guidance related to operations, maintenance, and retirement planning may be found in the following related requirements in this Handbook:


SWE-074

Document Maintenance Plan

SWE-076

Implement Operations, Maintenance, and Retirement Activities

SWE-105

Software Maintenance Plan



Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.


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:

  • Benefits of Implementing Maintainability on NASA Programs. Lesson Number 0835:  Impact of Non-Practice states: "Maintainability requirements for programs that require ground and/or in-space maintenance and anomaly resolution have to be established early in the program to be cost effective. Lack of management support to properly fund maintainability activities up-front can result in increased program risk. Including maintainability in the design process will greatly reduce the number of operational problems associated with system maintenance, improve the availability of the system, and reduce program costs."
    sweref
    525
    525
  • Software Design for Maintainability. Lesson Number 0838:  Impact of Non-Practice states: "Because of increases in the size and complexity of software products, software maintenance tasks have become increasingly more difficult. Software maintenance should not be a design afterthought; it should be possible for software maintainers to enhance the product without tearing down and rebuilding the majority of code."
    sweref
    526
    526