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-105} {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

5.1.4.1

The

Software

Maintenance

Plan

shall

include:

\[

(SWE-105

\]

)
a.

Plan

information

for

the

following

activities:

   


    (1)

Maintenance

process

implementation.

   


    (2)

Problem

and

modification

analysis.

   


    (3)

Modification

implementation.

   


    (4)

Maintenance

review/acceptance.

   


    (5)

Migration.

   


    (6)

Software

Retirement.

   


    (7)

Software

Assurance.

   


    (8)

Software

Risk

Assessment

for

all

changes

made

during

maintenance

and

operations.


b.

Specific

standards,

methods,

tools,

actions,

procedures,

and

responsibilities

associated

with

the

maintenance

process.

 

  In

addition,

the

following

elements

are

included:

   


    (1)

Development

and

tracking

of

required

upgrade

intervals,

including

implementation

plan.

   


    (2)

Approach

for

the

scheduling,

implementation,

and

tracking

of

software

upgrades.

   


    (3)

Equipment

and

laboratories

required

for

software

verification

and

implementation.

   


    (4)

Updates

to

documentation

for

modified

software

components.

   


    (5)

Licensing

agreements

for

software

components.

   


    (6)

Plan

for

and

tracking

of

operational

backup

software

(e.g.,

backup

flight

software,

backup

to

the

primary

operational

software).

   


    (7)

Approach

for

the

implementation

of

modifications

to

operational

software

(e.g.,

testing

of

software

in

development

laboratory

prior

to

operational

use).

   


    (8)

Approach

for

software

delivery

process,

including

distribution

to

facilities

and

users

of

the

software

products

and

installation

of

the

software

in

the

target \\         environment

target
        environment (including,

but

not

limited

to,

spacecraft,

simulators,

Mission

Control

Center,

and

ground

operations

facilities).

   


    (9)

Approach

for

providing

NASA

access

to

the

software

version

description

data

(e.g.,

revision

number,

licensing

agreement).

h2. {color:#003366}{*}

1.1

Notes{*}{color} NPR

Notes

NPR 7150.2.

NASA

Software

Engineering

Requirements,

does

not

include

any

notes

for

this

requirement.

h2.

1.2

Applicability

Across

Classes

Class

B

and

Class

B

Safety

Critical

are

labeled

with

"P

(Center)+SO."

 

  This

means

that

this

requirement

applies

to

the

safety-critical

aspects

of

the

software

and

that

an

approved

Center-defined

process

that

meets

a

non-empty

subset

of

the

full

requirement

can

be

used

to

achieve

this

requirement.

Classes

C

through

E

and

Safety

Critical

are

labeled

with

"SO."

 

  This

means

that

this

requirement

applies

to

the

safety-critical

aspects

of

the

software.

Class

G

is

labeled

with

"P

(Center)."

 

  This

means

that

an

approved

Center-defined

process

that

meets

a

non-empty

subset

of

the

full

requirement

can

be

used

to

achieve

this

requirement.

\\ {applicable:asc=1|ansc=1|bsc=*|bnsc=*|csc=*|cnsc=0|dsc=*|dnsc=0|esc=*|ensc=0|f=1|g=p|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale NPR 7150.2, section


applicable
f1
gp
h0
ansc1
asc1
bnsc*
csc*
bsc*
esc*
cnsc0
dnsc0
dsc*
ensc0



Div
idtabs-2

2. Rationale

NPR 7150.2, section 5.4.1,

states:

"The

Software

Maintenance

Plan

provides

insight

into

the

method,

approach,

responsibility,

and

processes

to

be

followed

for

maintenance

of

software

and

its

associated

documentation."

 

  Having

planned,

reviewed,

and

approved

activities

for

carrying

out

maintenance,

operations,

and

retirement:

*

  • Helps
  • ensure
  • that
  • the
  • outcome
  • of
  • the
  • activities
  • will
  • meet
  • the
  • expectations
  • of
  • the
  • project.
*
  • Allows
  • for
  • thorough
  • deliberation
  • of
  • tasks,
  • methods,
  • environments,
  • and
  • related
  • criteria
  • before
  • they
  • are
  • implemented.
*
  • Allows
  • the
  • plans
  • to
  • be
  • tailored
  • for
  • a
  • specific
  • project's
  • needs.
{div3} {div3:id=


Div
idtabs-3
} h1.

3.

Guidance

NPR

7150.2A,

section

5.4.1

also

states:

"For

the

Software

Maintenance

Plan,

provide

separate

volumes

for

each

system

element

(e.g.,

ground

operations,

flight

operations,

mission

operations,

and

spacecraft)."

NPR

7150.2A,

section

5.4.1.b,

also

states

that

the

Software

Maintenance

Plan

describes

"specific

standards,

methods,

tools,

actions,

procedures,

and

responsibilities

associated

with

the

maintenance

process."

When

developing

the

Software

Maintenance

Plan,

include

information

for

carrying

out

the

activities

listed

below.

Where

appropriate,

references

to

documents

describing

existing

processes,

such

as

configuration

management,

may

be

included

in

the

Software

Maintenance

Plan,

but

those

documents

and

the

processes

they

describe

will

need

to

be

maintained

for

the

life

of

the

plan(s)

that

reference

them.

Any

operations,

maintenance,

and/or

retirement

activities

that

require

supplier

(software

provider)

support

or

action

will

need

to

be

incorporated

into

the

contract,

because

the

contract

is

the

binding

document

for

contractor

performance

and

deliverables.

 

  In

these

situations,

maintenance

planning

is

limited

to

the

scope

of

the

maintenance

activities

agreed

to

in

the

contract.

{


Note
}

This

NPR

7150.2

requirement

(SWE-105)

is

important

to

consider

during

the

earliest

phases

of

a

project

when

the

Request

for

Proposals

(RFPs),

the

Statement

of

Work

(SOW),

and

the

contract

are

being

developed.

Maintenance

planning

can

be

started

in

these

early

phases

and

completed

once

the

conditions

for

activities,

such

as

software

retirement,

become

known

in

the

later

phases

of

the

project

life

cycle.

{note} *Maintenance process


Maintenance process implementation.

*

Processes

and

procedures

for

performing

software

maintenance,

including

processing

requests

for

new

software

features

and

requests

for

changes

to

address

problems,

anomalies,

or

documentation

changes.

*

Problem

and

modification

analysis

*

.

Processes

and

procedures

for

capturing,

reviewing,

analyzing,

and

identifying

the

causes,

potential

solutions,

and

associated

impact

for

problems

and

issues

found

during

operations

and

maintenance

(see

also

[

SWE-080

|SWE-080]

);

processes

and

procedures

for

analyzing

the

impact

of

new

feature/functionality

requests.

*

Modification

implementation.

*

Processes

and

procedures

for

implementing

approved

updates.

*

Maintenance

review/acceptance

*

.

Processes

and

procedures

for

review

and

acceptance

of

updates:

*

  • Before
  • delivery
  • and
  • installation.
*
  • To
  • "determine
  • the
  • integrity
  • of
  • the
  • modified
  • system."
{sweref:224} * To obtain approvals "for the satisfactory completion of the modification as specified in the contract." {sweref:224} *Migration.* Processes and procedures for moving the software to a new operational environment, including tools needed; data conversion activities, if required; support for the previous environment, user notification {sweref:209}; and running parallel operations in both the old and new environments during the migration, as needed. {sweref:224} *Software Retirement.* Processes and procedures for retiring software, i.e., decommissioning, disposing, withdrawal of active support{sweref:209}, making non-operational, including: * Archival procedures. * Procedures for securing the retired software and documentation, capturing lessons learned and final software metrics. * Customer notification procedures. * "Responsibility for future residual support issues." {sweref:224} * Internal documentation to formally retire the software. * Assessment of retirement impact on other systems and databases. {sweref:209} * Transition to new. * Replacement software {sweref:209}, if applicable. *Software Assurance.* Processes and procedures for carrying out software assurance through the end of life for the software, including but not limited to the following tasks from
  • sweref
    224
    224
  • To obtain approvals "for the satisfactory completion of the modification as specified in the contract."
    sweref
    224
    224

Migration. Processes and procedures for moving the software to a new operational environment, including tools needed; data conversion activities, if required; support for the previous environment, user notification

sweref
209
209
; and running parallel operations in both the old and new environments during the migration, as needed.
sweref
224
224

Software Retirement. Processes and procedures for retiring software, i.e., decommissioning, disposing, withdrawal of active support

sweref
209
209
, making non-operational, including:

  • Archival procedures.
  • Procedures for securing the retired software and documentation, capturing lessons learned and final software metrics.
  • Customer notification procedures.
  • "Responsibility for future residual support issues."
    sweref
    224
    224
  • Internal documentation to formally retire the software.
  • Assessment of retirement impact on other systems and databases.
    sweref
    209
    209
  • Transition to new.
  • Replacement software
    sweref
    209
    209
    , if applicable.

Software Assurance. Processes and procedures for carrying out software assurance through the end of life for the software, including but not limited to the following tasks from NASA-STD-8739.8,

Software

Assurance

Standard,

{sweref:278} and

sweref
278
278
and NASA-GB-8719.13,

NASA

Software

Safety

Guidebook

{sweref:276}: * Assuring "the transfer and maintenance of any licenses, simulators, models, and test suites from the developer to NASA, or the designated maintenance contractor." {sweref:278} * Assuring "that any metrics collected on the software, along with any trending and reliability data, are transferred to the maintenance organization and maintained." {sweref:278} * Assuring that software engineering and management prepare, approve, and execute a Software Maintenance Plan that includes retirement activities. {sweref:278} * Performing or assisting with impact analysis for proposed changes, including safety impact analyses and impact analysis of {term:COTS}changes.{sweref:276} * Witnessing regression testing. {sweref:276} *Software Risk Assessment for all changes made during maintenance and* *operations.* Processes and procedures for assessing risk associated with software changes made during the operations and maintenance life-cycle phases (may be linked to or part of the "Problem and modification analysis" procedures listed above.) {floatbox:width=full}

sweref
276
276
:

  • Assuring "the transfer and maintenance of any licenses, simulators, models, and test suites from the developer to NASA, or the designated maintenance contractor."
    sweref
    278
    278
  • Assuring "that any metrics collected on the software, along with any trending and reliability data, are transferred to the maintenance organization and maintained."
    sweref
    278
    278
  • Assuring that software engineering and management prepare, approve, and execute a Software Maintenance Plan that includes retirement activities.
    sweref
    278
    278
  • Performing or assisting with impact analysis for proposed changes, including safety impact analyses and impact analysis of COTS  changes.
    sweref
    276
    276
  • Witnessing regression testing.
    sweref
    276
    276

Software Risk Assessment for all changes made during maintenance and operations. Processes and procedures for assessing risk associated with software changes made during the operations and maintenance life-cycle phases (may be linked to or part of the "Problem and modification analysis" procedures listed above.)


Floatbox
widthfull

NASA-GB-8719.13

{sweref:276}states

sweref
276
276
states that:

"Software

upgrades,

patches,

and

other

maintenance

can

have

unexpected

and

unwelcome

side

effects...Changes

in

one

part

of

the

software

may

impact

other

areas

of

the

software

system.

Analysis

of

that

impact

needs

to

be

performed

prior

to

initiating

the

change.

In

a

safety-critical

system

it

is

vital

to

make

sure

that

the

latest

fix

or

upgrade

does

not

"break"

any

safety-critical

software

component."

{sweref:276}\\ {floatbox} *Development and tracking of required upgrade intervals, including implementation plan.* Software may have planned upgrades built into the overall life cycle; the maintenance plan addresses how those upgrades will be developed, tested, tracked, delivered, and installed according to the appropriate upgrade schedule. *Approach for the scheduling, implementation, and tracking of software upgrades.* Processes and procedures for capturing the history of upgrades to a software package, including: * Coordinating upgrades with the software user's operations schedule. * Tracking delivery and installation of software packages across the customer base, as appropriate, i.e., which customers have which release of the software and when those releases were delivered and installed. *Updates to documentation for modified software* *components.* Processes and procedures to ensure that development, e.g., design documents, and user documentation, e.g., operations manuals, are updated to match changes in the software and that the updated documentation is delivered with the appropriate software update *Plan for and tracking of operational backup software, e.g., backup flight software, backup to the primary operational software.* Processes and procedures for maintaining backup software (software that takes over when the primary software fails).  The standards, methods, tools, actions, and procedures for maintaining the backup software may be significantly different from the maintenance procedures for the primary software. *Approach for the implementation of modifications to operational software, e.g., testing of software in development laboratory before operational use.* Processes, procedures, resources, needed to develop, test (including regression testing{sweref:276}, and approve changes to operational software, including appropriate data capture, e.g., test results.  *Approach for software delivery process, including distribution to facilities and users of the software products and installation of the software in the target environment, including but not limited to spacecraft, simulators, Mission Control Center, and ground operations facilities.* Processes and procedures for release, delivery, and installation of software updates to customers, including coordinating these activities with the customer's operations schedule, e.g., some customers may be operational 24-7 with only limited planned downtime, and supporting configuration and operational data changes, as appropriate.{sweref:001} *Approach for providing NASA access to the software version description data, e.g., revision number, licensing agreement. * Processes and procedures for NASA's access to identification, content information, licenses, etc. for software updates. *Licensing agreements for software components.* References to agreements with suppliers/providers regarding updates, upgrades, patches, maintenance, etc., particularly, agreements for COTS software. Licensing agreements typically include: * Provider notification methods, schedules for patches, new versions, upgrades. {sweref:276} * Compatibility of software upgrades with previous versions. {sweref:276} * Access to developers and other technical support. {sweref:276} * Support for previous software versions. {sweref:276} *Equipment and laboratories required for software verification and implementation.* Description and identification of equipment and laboratory resources that may need to be retained from the development phases or be accessible during operations and maintenance to perform implementation and verification activities. The project team considers the following general information for inclusion in the Software Maintenance Plan: * Resources required to perform activities described in the plan, e.g., personnel, equipment, documentation, data, tools, facilities. * Identification of maintenance organization(s), including subcontractors. * Schedule for maintenance, if appropriate. * Budget/costs, as appropriate for the plan. * Support procedures, such as configuration management, metrics capture, risk management (may be references to existing plans, processes, procedures that will need to be kept up to date for the life of the plan). * Description of maintenance records and reports to be generated. * Training for maintenance personnel. {note}Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to the Software Maintenance Plan contents. {note} Additionally, guidance related to the Software Maintenance Plan may be found in the following requirements in this Handbook: | *[SWE-074|SWE-074]* | Document Maintenance Plan | | *[SWE-075|SWE-075]* | Plan Operations, Maintenance, Retirement | | *[SWE-076|SWE-076]* | Implement Operations, Maintenance, and Retirement Activities | \\ {div3} {div3:id=tabs-4} h1. 4. Small Projects For projects with limited staff or budgets, consider adapting a Software Maintenance Plan from a similar project, making sure to update the plan to reflect the current project's operations, maintenance, and retirement plans. The maintenance plan may also be included as part of another plan, such as the Software Management/Development Plan. {div3} {div3:id=tabs-5} h1. 5. Resources {refstable} {toolstable}\\ {div3} {div3:id=tabs-6} h1. 6. Lessons Learned The NASA Lesson Learned database contains lessons learned related to maintenance planning that are referenced in [SWE-074|SWE-074] of this Handbook. {div3} {tabclose}

sweref
276
276


Development and tracking of required upgrade intervals, including implementation plan. Software may have planned upgrades built into the overall life cycle; the maintenance plan addresses how those upgrades will be developed, tested, tracked, delivered, and installed according to the appropriate upgrade schedule.

Approach for the scheduling, implementation, and tracking of software upgrades. Processes and procedures for capturing the history of upgrades to a software package, including:

  • Coordinating upgrades with the software user's operations schedule.
  • Tracking delivery and installation of software packages across the customer base, as appropriate, i.e., which customers have which release of the software and when those releases were delivered and installed.

Updates to documentation for modified software components. Processes and procedures to ensure that development, e.g., design documents, and user documentation, e.g., operations manuals, are updated to match changes in the software and that the updated documentation is delivered with the appropriate software update

Plan for and tracking of operational backup software, e.g., backup flight software, backup to the primary operational software. Processes and procedures for maintaining backup software (software that takes over when the primary software fails).  The standards, methods, tools, actions, and procedures for maintaining the backup software may be significantly different from the maintenance procedures for the primary software.

Approach for the implementation of modifications to operational software, e.g., testing of software in development laboratory before operational use. Processes, procedures, resources, needed to develop, test (including regression testing

sweref
276
276
, and approve changes to operational software, including appropriate data capture, e.g., test results. 

Approach for software delivery process, including distribution to facilities and users of the software products and installation of the software in the target environment, including but not limited to spacecraft, simulators, Mission Control Center, and ground operations facilities. Processes and procedures for release, delivery, and installation of software updates to customers, including coordinating these activities with the customer's operations schedule, e.g., some customers may be operational 24-7 with only limited planned downtime, and supporting configuration and operational data changes, as appropriate.

sweref
001
001

Approach for providing NASA access to the software version description data, e.g., revision number, licensing agreement.  Processes and procedures for NASA's access to identification, content information, licenses, etc. for software updates.

Licensing agreements for software components. References to agreements with suppliers/providers regarding updates, upgrades, patches, maintenance, etc., particularly, agreements for COTS(Commercial Off the Shelf) software.

Licensing agreements typically include:

  • Provider notification methods, schedules for patches, new versions, upgrades.
    sweref
    276
    276
  • Compatibility of software upgrades with previous versions.
    sweref
    276
    276
  • Access to developers and other technical support.
    sweref
    276
    276
  • Support for previous software versions.
    sweref
    276
    276

Equipment and laboratories required for software verification and implementation. Description and identification of equipment and laboratory resources that may need to be retained from the development phases or be accessible during operations and maintenance to perform implementation and verification activities.

The project team considers the following general information for inclusion in the Software Maintenance Plan:

  • Resources required to perform activities described in the plan, e.g., personnel, equipment, documentation, data, tools, facilities.
  • Identification of maintenance organization(s), including subcontractors.
  • Schedule for maintenance, if appropriate.
  • Budget/costs, as appropriate for the plan.
  • Support procedures, such as configuration management, metrics capture, risk management (may be references to existing plans, processes, procedures that will need to be kept up to date for the life of the plan).
  • Description of maintenance records and reports to be generated.
  • Training for maintenance personnel.


Note

Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to the Software Maintenance Plan contents.


Additionally, guidance related to the Software Maintenance Plan may be found in the following requirements in this Handbook:


SWE-074

Document Maintenance Plan

SWE-075

Plan Operations, Maintenance, Retirement

SWE-076

Implement Operations, Maintenance, and Retirement Activities




Div
idtabs-4

4. Small Projects

For projects with limited staff or budgets, consider adapting a Software Maintenance Plan from a similar project, making sure to update the plan to reflect the current project's operations, maintenance, and retirement plans. The maintenance plan may also be included as part of another plan, such as the Software Management/Development Plan.


Div
idtabs-5

5. Resources


refstable


toolstable


Div
idtabs-6

6. Lessons Learned

The NASA Lesson Learned database contains lessons learned related to maintenance planning that are referenced in SWE-074 of this Handbook.