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 (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 7150.2 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 which meets a non-empty subset of the full requirement can be used to achieve this requirement. Classes C thru 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 which 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 Per Chapter 5 of NPR 7150.2A, "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 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=tabs-3} h1. 3. Guidance Per Chapter 5 of NPR 7150.2A, "For the Software Maintenance Plan, provide separate volumes for each system element (e.g., ground operations, flight operations, mission operations, and spacecraft)." The NPR 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.  {note}This NPR 7150.2 requirement is important to consider during the earliest phases of a project when the Request for Proposals (RFP), the Statement of Work (SOW), and the contract are being developed. {note} *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: * Prior to delivery and installation * To "determine the integrity of the modified system"^7^ * To obtain approvals "for the satisfactory completion of the modification as specified in the contract"^7^ *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{^}5^; and running parallel operations in both the old and new environments during the migration, as needed{^}7^ *Software Retirement* -- processes and procedures for retiring software (i.e., decommissioning, disposing, withdrawal of active support{^}5^, 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"^7^ * internal documentation to formally retire the software * assessment of retirement impact on other systems and databases{^}5^ * transition to new * replacement software{^}5^, 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 the [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130] and the [NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126]: * Assuring "the transfer and maintenance of any licenses, simulators, models, and test suites from the developer to NASA, or the designated maintenance contractor"^3^ * Assuring "that any metrics collected on the software, along with any trending and reliability data, are transferred to the maintenance organization and maintained"^3^ * Assuring that software engineering and management prepare, approve, and execute a Software Maintenance Plan that includes retirement activities{^}3^ * Performing or assisting with impact analysis for proposed changes, including safety impact analyses and impact analysis of COTS changes{^}4^ * Witnessing regression testing{^}4^ *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 lifecycle phases (may be linked to or part of the "Problem and modification analysis" procedures listed above) {floatbox:width=full}Per the [NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126], "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."^4 ^ {floatbox} *Development and tracking of required upgrade intervals, including implementation plan* \--software may have planned upgrades built in to the overall life cycle; the maintenance plan addresses how those upgrades will be developed, tested, tracked, delivered, 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 were those releases 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) is 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 prior to operational use)* -- processes, procedures, resources, needed to develop, test (including regression testing{^}4^), 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{^}1^ *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 should include: * Provider notification methods, schedules for patches, new versions, upgrades{^}4^ * Compatibility of software upgrades with previous versions{^}4^ * Access to developers and other technical support{^}4^ * Support for previous software versions{^}4^ *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 which 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 # 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]", EI32-OI-001, Revision R, 2010. # Software Engineering Division, Goddard Space Flight Center, "[Requirements for Minimum Contents of Software Documents|http://software.gsfc.nasa.gov/AssetsApproved/PA1.0.0.2.doc]", 580-STD-077-01, 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 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. # IEEE Computer Society, "[IEEE Standard for Software and System Test Documentation|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4578383&tag=1]", IEEE Std 829-2008, 2008. 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. # "[Systems and software engineering -- Software life cycle processes|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4475826&tag=1]", ISO/IEC 12207, IEEE Std 12207-2008, 2008.  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. # Software Engineering Institute, "[CMMI for Development, Version 1.3|http://www.sei.cmu.edu/reports/10tr033.pdf]", CMU/SEI-2010-TR-033, 2010. # Software Engineering Division, ""[In-house Software Development and Maintenance|http://software.gsfc.nasa.gov/AssetsApproved/PA1.0.2.doc]", GPR 7150.2, 2009. # International Standards Organization (ISO), "[Software Engineering -- Software Life Cycle Processes -- Maintenance|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1703974&tag=1]", ISO/IEC 14764:2006, 2006. 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. \\ {toolstable}\\ {div3} {div3:id=tabs-6} h2. 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}

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.


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.


Div
idtabs-3

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.


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

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
278
and NASA-GB-8719.13, NASA Software Safety Guidebook
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
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
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.