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 (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).

1.1

Notes

NPR 7150.2.

NASA

Software

Engineering

Requirements,

does

not

include

any

notes

for

this

requirement.

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.

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.

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.

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

);

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

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

• 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,

NASA

Software

Safety

Guidebook

• 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.)

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

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.

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