Comment:
Migration of unmigrated content due to installation of a new plugin
Tabsetup
1. The Requirement
1. The Requirement
1
2. Rationale
2
3. Guidance
3
4. Small Projects
4
5. Resources
5
6. Lessons Learned
Div
id
tabs-1
1. Requirements
3.5.5 The project shall deliver to the customer the as-built documentation to support the operations and maintenance phase of the software life cycle.
1.1 Notes
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 Applicability Across Classes
Classes F and G are labeled with "X (not OTS)." This means that this requirement does not apply to off-the-shelf software for these classes.
applicable
f
*
g
*
h
0
ansc
1
asc
1
bnsc
1
csc
1
bsc
1
esc
1
cnsc
1
dnsc
0
dsc
1
ensc
0
Div
id
tabs-2
2. Rationale
The goal of software development is to provide a software product to the customer. To ensure proper understanding, use, and maintenance of the delivered product, the project team needs to provide as-built documentation, i.e., documentation that matches the delivered product, to the customer.
NPR 7150.2 includes another, similar, requirement for delivered documentation. SWE-077 applies to almost all classes (see the guidance for SWE-077 in this Handbook) and has a lot of leeway regarding what documentation exists. This requirement, SWE-078, is oriented toward the higher classes and specifies as-built or final documentation.
Div
id
tabs-3
3. Guidance
Panel
It is important that the Version Description Document (VDD), user documentation, and design documentation, in particular, describe the as-built and delivered software.
Documentation delivered to support operation and maintenance of a software product needs to match the actual delivered product, keeping in mind the documentation requirements for the classification of that software (SWE-020). The delivered product may not always be the designed product due to factors such as evolution of requirements, reworked code, unanticipated problems, etc. Regardless of any issues that alter the product during the development life cycle, the delivered documentation needs to be accurate and reflect the released version of the software. The VDD, in particular, describes the delivered product for the customer and provides other information to identify a specific release of software
sweref
276
276
.
Once the project team establishes the set of documentation to be delivered with the software, the team keeps documents up-to-date throughout the project life cycle to avoid any delays in delivery. Near the end of the project life cycle the team updates any inconsistent documentation to ensure it includes the information needed to maintain the software in the future.
Before software delivery, "a physical examination is made of the configuration item (CI) to verify that ... [it] conforms as-built to its technical documentation."
sweref
212
212
When mismatches occur this close to software delivery, the project team updates the documentation to match the delivered software prior to delivery to the customer.
The project team needs to fully describe in the contract the delivery package content requirements for a contracted software provider to ensure the acquirer receives all critical information, including as-built documentation, required to operate and maintain the software.
Note
Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to delivery of as-built software documentation.
Additionally, guidance related to software delivery, including as-built software documentation, may be found in the following related requirements in this Handbook: