See edit history of this section
Post feedback on this section
22.214.171.124 Each Center Director shall contribute applicable software engineering process assets in use at their Centers to the Agency-wide process asset library.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
The Agency-wide process asset library (PAL) is a collection of processes, procedures, job aids, examples and other recommended best practices. These assets are intended to facilitate the software development process Agency wide. To make this asset library complete, useful, and representative of all Centers across the Agency, it is necessary for all Centers to contribute assets to the collection.
When choosing items for the Agency-wide PAL use the following concepts to help guide that selection:
- Include documentation and job aids that describe “what to do” or “how to do something”.
- Select the best examples.
- Have those assets reviewed by the appropriate Center authority (organizational group at the Center such as a Division, Branch, or level of the organization where CMMI® appraisals are being done) before submitting for inclusion in the PAL.
- For process assets where the approval level is not the Center (may be the Office of the Chief Engineer (OCE) or the Office of Safety and Mission Assurance (OSMA)) or, in some cases, presentations done by Software Working Group (SWG) members accepted at conferences, these items can be submitted, but there must be some vetting before submission.
- Perhaps make this an annual review preceding a NASA Software Working Group meeting.
- Perhaps include this as part of a project’s post-mortem retrospective.
- Sensitive but Unclassified (SBU) material, proprietary data and International Traffic in Arms Regulations (ITAR) data should not be submitted.
As described on the Software Processes Across NASA (SPAN) website (accessible to NASA users from the SPAN tab in this Handbook), areas of interest include:
- Processes and procedures driven by policies at NASA:
- Management, including estimation, class transition, planning, monitoring and control, risk.
- Engineering, including requirements, design, code and integration, peer reviews, verification and validation, release, sustaining, retirement.
- Support, including software assurance, safety, configuration management, decision making, metrics, process improvement.
- Acquisition, including purchasing and contracting.
- Process related assets:
- Templates, checklists, forms.
- Examples of project artifacts.
- Training documents.
- Standards, guides.
- Logs, databases.
- Reports, metrics.
- Tools frequently used in developing projects.
- Milestone review documents.
Process assets can be submitted at any time, but the preference is that assets be submitted as soon as they are approved by the Center. To submit Center assets to the SPAN website, the SWG representative or the process improvement lead for the Center follows the instructions in the “Submit an Asset to SPAN” section of the Introduction page of the SPAN website.
All process assets approved and submitted by a Center are posted unless the APPS team has concerns that some of the material might be SBU, ITAR, etc. Assets approved by a Center get a designation as assets from that particular Center. A Center can also nominate certain of their assets as best practices or examples and those will be reviewed by the APPS team. If the APPS team agrees that they are best practices or examples, the assets will be posted with a NASA designation.
4. Small Projects
This requirement applies to all projects regardless of size. Process assets from small projects may be useful for other small projects in their efforts to meet the requirements of this NPR.
Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
6. Lessons Learned
There are currently no Lessons Learned identified for this requirement.