The title of this page has been changed. If you are using a bookmark to get here, please updated it.
You should be redirected to https://swehb.nasa.gov/display//SWEHBVD/7.09+-+Entrance+and+Exit+Criteria. If you do not get there in 2 seconds, click the link to go there.
View this section on the website
See edit history of this section
Post feedback on this section
- 1. Entrance and Exit Criteria
- 2. MCR
- 3. SRR
- 4. SwRR
- 5. MDR
- 6. SDR
- 7. PDR
- 8. CDR
- 9. PRR
- 10. SIR
- 11. TRR
- 12. SAR
- 13. ORR
- 14. FRR
- 15. Resources
1. Entrance and Exit Criteria
1.1 Background
This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.This topic describes the recommended best practices for entrance and success criteria for the software life cycle and technical reviews required by NASA. The guidelines are regardless of whether the review is accomplished in a one-step or two-step process. The entrance and items reviewed criteria do not provide a complete list of all products and their required maturity levels. Additional programmatic products may also be required by the appropriate governing NPRs for the project/program.
Tailoring and customizing are expected for projects and programs. The entrance and success criteria and products required for each review will be tailored and customized appropriately for the particular program or project being reviewed and the classification of the software. The decisions made to tailor and customize life-cycle review criteria should be justified to both the Engineering and SMA TA.
To facilitate this tailoring a Process Asset Template (PAT) is provided for each review. It may be downloaded and modified as necessary to reflect the tailoring changes made for the review.
The recommended criteria in the following tables are focused on demonstrating acceptable software technical maturity, adequacy of software technical planning, and credibility of budget, software schedule, risks (as applicable), and software readiness to proceed to the next phase. Customized or tailored criteria developed by programs or projects for life-cycle reviews should also be focused on assessing these factors. The software entrance and exit criteria guidance is a collection of material from the following core documents:
The expected level of completeness for each document at each review point is shown in Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews.
2. MCR - Mission Concept Milestone Review
The Mission Concept Review (MCR) exit criteria, outlined in NASA-HDBK-2203, Topic 7.09, focus on ensuring that the mission concept, including software objectives, scope, and feasibility, is well-defined, properly aligned with project goals, and ready to proceed to more detailed system and software requirements definition. The MCR evaluates the overall feasibility of achieving mission objectives and ensures that software elements are integrated into the early mission planning phase.
2.1 Key Purpose of Software MCR Exit Criteria
The MCR exit criteria ensure that the software's role in the mission concept:
- Is clearly defined and feasible within the project's constraints.
- Aligns with mission objectives and high-level system requirements.
- Addresses early risks associated with software design, development, and integration.
- Sets a strong foundation for progressing to detailed system and software requirements definition.
Meeting the Software MCR Exit Criteria confirms that the mission concept incorporates sound, feasible plans for software development and integration. By addressing these criteria, NASA ensures the project’s readiness to proceed to the next phase, minimizing risks and aligning software objectives with mission priorities and system requirements.
2.2 Process Asset Template for MCR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
3. SRR - Software Systems Requirements Milestone Review
The Software Systems Requirements Review (SRR) exit criteria outlined in NASA-HDBK-2203, Topic 7.09, ensure that the software-related requirements derived from the system-level objectives are complete, consistent, achievable, and clearly documented. The SRR verifies that the software requirements align with mission objectives, system-level requirements, and stakeholder needs and provides a solid foundation for software design and development.
3.1 Key Purpose of Software SRR Exit Criteria
The SRR exit criteria ensure that the software requirements are properly defined and ready to proceed to the design phase. They aim to:
- Confirm that software requirements align with mission and system-level goals.
- Ensure requirements are clear, feasible, and traceable.
- Minimize risks due to incomplete or poorly defined requirements.
- Provide stakeholder confidence that the software development process is starting on a solid foundation.
Meeting the Software SRR Exit Criteria is essential to ensure the success of NASA projects. By achieving these criteria, the project team confirms that the software requirements are well-defined, complete, and consistent with mission objectives, allowing the development process to advance confidently to the design phase. This reduces the risk of late-stage issues and promotes efficient and effective software development.
3.2 Process Asset Template for SRR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
4. SwRR - Software Requirements Milestone Review
The Software Requirements Review (SwRR) exit criteria detailed in NASA-HDBK-2203, Topic 7.09, are designed to ensure that the software requirements for a project are fully defined, documented, traceable, and ready for the next phase of design and development. The SwRR verifies that the requirements align with mission objectives, system-level requirements, and stakeholder expectations. Meeting these criteria reduces the risk of design errors and ensures a solid foundation for software development.
4.1 Key Purpose of Software SwRR Exit Criteria
The SwRR exit criteria ensure that the project has a clear and agreed-upon set of software requirements, providing the foundation for subsequent phases such as design, implementation, and testing. Specifically, the SwRR:
- Confirms that requirements are complete, consistent, feasible, and traceable.
- Reduces downstream risks caused by incomplete or incorrect requirements.
- Ensures stakeholder alignment and buy-in for the project's scope and goals.
- Prepares the project team to proceed confidently into design and development.
The SwRR exit criteria are critical for establishing the baseline requirements for software development. By thoroughly addressing these criteria, NASA ensures that the project begins with a strong foundation, minimizing risks and ensuring that the software will meet mission objectives efficiently and effectively.
4.2 Process Asset Template for SwRR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
5. MDR - Mission Definition Milestone Review
The Mission Definition Review (MDR) exit criteria outlined in NASA-HDBK-2203, Topic 7.09, evaluate whether the mission's objectives, requirements, and system approach—including software-related aspects—are well-defined, achievable, and ready to proceed to detailed preliminary and system design. The MDR ensures that the foundational mission framework is established and that software considerations are integrated into the overall system design and management approach.
5.1 Key Purpose of Software MDR Exit Criteria
The MDR exit criteria ensure that:
- The software requirements and defined role align with the broader mission goals and system design.
- Critical software-related risks and challenges have been identified early, with mitigation strategies planned.
- Stakeholders have confidence in the project's ability to proceed to detailed system and software preliminary design phases.
By meeting these criteria, the software component of the mission is fully integrated into the mission definition and ready for further development planning.
The Software MDR Exit Criteria confirm that the preliminary software planning and definitions effectively support mission objectives and system design. By addressing these criteria, NASA ensures a structured and well-considered approach to software development, minimizing risks and setting the stage for successful software design and implementation in subsequent phases.
5.2 Process Asset Template for MDR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
6. SDR - Software System Design Milestone Review
The Software System Design Review (SDR) exit criteria outlined in NASA-HDBK-2203, Topic 7.09, ensure that the software's high-level architectural design is well-defined, feasible, and aligned with system-level goals and requirements. The SDR verifies that the software design provides a solid architecture for implementation and that all risks, trade-offs, and requirements are carefully considered.
6.1 Key Purpose of Software SDR Exit Criteria
The Software SDR ensures that the high-level software design:
- Is feasible and aligns with mission and system-level requirements.
- Provides a robust foundation for detailed design and implementation.
- Anticipates and mitigates risks associated with architecture and design decisions.
- Aligns with safety, security, and performance requirements.
By meeting the SDR exit criteria, the project team ensures that the architectural framework is mature enough to proceed to the next stage of development with minimal risk.
The Software SDR Exit Criteria ensure the feasibility, completeness, and quality of the software's high-level architecture. Successfully addressing these criteria prepares the project to transition seamlessly into the detailed design phase with confidence that the software structure will meet mission objectives, requirements, and constraints.
6.2 Process Asset Template for SDR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
7. PDR - Preliminary Design Milestone Review
The PDR demonstrates that the Preliminary Design meets all system requirements with acceptable risk and within the cost and schedule constraints and establishes the basis for proceeding with Detailed Design. It shows that the correct design option has been selected, interfaces have been identified, and verification methods have been described. Full baseline costs and schedules, as well as risk assessments, management systems, and metrics, are presented. (NPR 7120.5 082)
7.1 Key Purpose of PDR
The Software PDR exit criteria ensure that the design phase starts without critical gaps or unresolved issues, reducing the risk of downstream problems like coding errors, testing failures, or delays. Meeting these criteria gives stakeholders confidence that the software architecture and early design:
- Is robust and well-documented.
- Adheres to requirements and project goals.
- Is safe and reliable for deployment.
- Is adequately prepared for implementation and testing phases.
By meeting these exit criteria, NASA projects can ensure a smooth and risk-managed transition from Preliminary Design Review into software development and integration.
7.2 Process Asset Template for PDR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to view the template. From the viewer you may download a usable copy.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
8. CDR - Software Critical Design Milestone Review
The Software Critical Design Review (CDR) exit criteria outlined in NASA-HDBK-2203, Topic 7.09, are key checkpoints to ensure the software design is mature, meets project requirements, and is ready to move into implementation and testing phases. These exit criteria serve to verify the completeness, correctness, and readiness of the software design while assessing risks before proceeding further.
8.1 Key Purpose of Software CDR Exit Criteria
The Software CDR exit criteria ensure that the design phase wraps up without critical gaps or unresolved issues, reducing the risk of downstream problems like coding errors, testing failures, or delays. Meeting these criteria gives stakeholders confidence that the software design:
- Is robust and well-documented.
- Adheres to requirements and project goals.
- Is safe and reliable for deployment.
- Is adequately prepared for implementation and testing phases.
By meeting these exit criteria, NASA projects can ensure a smooth and risk-managed transition from Critical Design Review into software development and integration.
8.2 Process Asset Template for CDR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
9. PRR - Software Production Readiness Milestone Review
The Software Production Readiness Review (PRR) exit criteria outlined in NASA-HDBK-2203, Topic 7.09, ensure that software development is complete, and the software is ready for release to begin production, deployment, or operational use. The PRR evaluates whether all components, processes, tests, and documentation are complete, consistent, and meet mission requirements. This review focuses on the readiness of the software for sustained operation or mass reproduction.
9.1 Key Purpose of Software PRR Exit Criteria
The PRR ensures:
- The software is fully developed, tested, configured, and documented according to mission requirements.
- Processes are in place for production, deployment, and sustained operation.
- Stakeholders approve the software as ready to move forward, minimizing risks and ensuring readiness for long-term use.
The Software PRR Exit Criteria confirm that the software is complete, meets all requirements, and is ready for production or operational deployment with proper systems, documentation, and processes in place. By meeting these criteria, NASA ensures confidence in the reliability, safety, and usability of the software for its intended mission or operational environment.
9.2 Process Asset Template for PRR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
10. SIR - Software Integration Milestone Review
The Software Integration Review (SIR) exit criteria outlined in NASA-HDBK-2203, Topic 7.09, focus on ensuring that the software has been successfully integrated with its target system (e.g., hardware, other software components, or external interfaces) and is ready to proceed to verification testing or operational testing. The SIR evaluates the readiness and functionality of the integrated software in the context of the system or mission environment, highlighting any issues related to compatibility, interoperability, and performance.
10.1 Key Purpose of Software SIR Exit Criteria
The SIR ensures that:
- The software is fully integrated with its target systems and is functioning as intended in the mission or operational environment.
- Compatibility, interoperability, and interface issues are addressed prior to advancing to further testing or operational evaluations.
- The integrated configuration supports mission objectives and is approved by all relevant stakeholders.
The Software SIR Exit Criteria confirm that the software is successfully integrated and meets system-level requirements within the mission environment. By addressing these criteria, NASA ensures that the software is ready for subsequent verification and validation activities or operational deployment, minimizing risks and ensuring seamless function within the integrated system.
10.2 Process Asset Template for SIR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
11. TRR - Software Test Readiness Milestone Review
The Software Test Readiness Review (TRR) exit criteria, as outlined in NASA-HDBK-2203, Topic 7.09, lay out the necessary conditions that must be met before software testing can begin. The TRR ensures that all preparations for testing—such as software, hardware, test environments, and documentation—are complete and that the team is ready to proceed with testing activities. The focus is on validating that the planned tests will address requirements, identify defects, and measure performance and functionality effectively.
11.1 Key Purpose of Software TRR Exit Criteria
The TRR exit criteria ensure that the project team has completed all necessary preparations to begin software testing with confidence. Meeting these criteria validates that:
- The testing process is planned and executable.
- The software and test setup are stable and ready.
- All requirements are adequately covered by test cases.
- Stakeholders are confident in proceeding to the testing phase.
By thoroughly addressing the TRR exit criteria, NASA ensures that testing will be efficient, minimize risk, and provide meaningful results to validate the software's readiness for deployment.
11.2 Process Asset Template for TRR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
12. SAR - Software Acceptance Milestone Review
The Software Acceptance Review (SAR) exit criteria outlined in NASA-HDBK-2203, Topic 7.09, evaluate whether the developed software meets all requirements, complies with relevant standards, has been fully tested, and is ready for formal delivery to the customer or integration into the system. The SAR verifies that the software is complete, acceptable for operational use, and properly documented for transfer and support.
12.1 Key Purpose of Software SAR Exit Criteria
The SAR ensures that:
- The software is fully developed, tested, and validated to meet all requirements and is ready for handoff to the customer or operational teams.
- Stakeholders and end-users have confidence in the software's quality, reliability, and operational readiness.
- Proper documentation, training, and ongoing support plans are in place to ensure successful deployment and use of the software.
The Software SAR Exit Criteria confirm the software's readiness for formal acceptance and delivery, validating that it satisfies all requirements and can be successfully integrated into the system or operational environment. By meeting these criteria, NASA ensures that the software is robust, reliable, and capable of achieving mission objectives while providing long-term support and maintainability.
12.2 Process Asset Template for SAR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
13. ORR - Operational Readiness Milestone Review
The Operational Readiness Review (ORR) exit criteria outlined in NASA-HDBK-2203, Topic 7.09, ensure that the software is tested, verified, validated, and ready for operational use in support of the mission or system. The ORR evaluates whether the software is capable of reliably performing its intended functions and interacting with hardware, systems, and operational environments, with all risks mitigated, documentation prepared, and users trained.
13.1 Key Purpose of Software ORR Exit Criteria
The ORR exit criteria ensure that:
- The software is rigorously tested, validated, and integrated, capable of performing its intended functions in the operational environment.
- All operational risks are mitigated, and users are properly trained.
- The software is ready to transition to full mission operations with stakeholder confidence in its reliability and performance.
The Software ORR Exit Criteria confirm operational readiness, ensuring that the software can perform successfully under real-world mission conditions. By addressing these criteria, NASA ensures that the software will support mission objectives effectively, minimizing operational risks and providing the tools necessary for sustained mission success.
13.2 Process Asset Template for ORR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
14. FRR - Software Flight Readiness Milestone Review
The Software Flight Readiness Review (FRR) exit criteria, as outlined in NASA-HDBK-2203, Topic 7.09, focus on verifying that the software is ready for operational use in the mission or system it is part of. The FRR ensures that all critical aspects of the software, including testing, validation, and integration, have been successfully completed and that the software can safely and reliably perform its intended functions in the flight or operational environment.
14.1 Key Purpose of Software FRR Exit Criteria
The FRR exit criteria ensure that the software has reached a level of maturity and stability required for successful integration into the mission environment. By meeting these criteria, the project team verifies that:
- The software can perform safely and reliably in flight or the operational environment.
- All testing and validation activities have been satisfactorily completed, addressing critical risks and defects.
- Mission stakeholders are confident in approving the software for operational use.
The Software FRR exit criteria serve as the final major checkpoint to ensure the software achieves flight readiness. By rigorously validating functionality, safety, and compatibility, NASA ensures mission success, reduces risks, and builds confidence in the software's performance under operational conditions.
14.2 Process Asset Template for FRR
The PAT can be used for as a checklist for :
- Verifying Entrance Criteria and preparation for the review - each document is identified in BOLD Blue text and the objectives of the review are clearly stated. Ensure that all evidence is collected and available for review.
- Verifying Success Criteria during the review - columns are included to note, during the review, if the success criteria is met along with comments as appropriate. May be used as evidence of the review and tracking of open items to be resolved post review.
The PAT is downloadable in MS Word format and may be tailored as needed for the project. It may be saved and reused for subsequent reviews in the project. It may be used as evidence of the review in project records.
Click on the image to preview the file. From the preview, click on Download to obtain a usable copy.
15. Resources
15.1 References
- (SWEREF-041) NPR 7123.1D, Office of the Chief Engineer, Effective Date: July 05, 2023, Expiration Date: July 05, 2028
- (SWEREF-082) NPR 7120.5F, Office of the Chief Engineer, Effective Date: August 03, 2021, Expiration Date: August 03, 2026,
- (SWEREF-083) NPR 7150.2D, Effective Date: March 08, 2022, Expiration Date: March 08, 2027 https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2D Contains link to full text copy in PDF format. Search for "SWEREF-083" for links to old NPR7150.2 copies.
- (SWEREF-172) Defense Acquisition University, Production Date:16-September-2013. Retrieved from https://at.dod.mil/sites/default/files/documents/DefenseAcquisitionGuidebook.pdf.
- (SWEREF-197) Software Processes Across NASA (SPAN) web site in NEN SPAN is a compendium of Processes, Procedures, Job Aids, Examples and other recommended best practices.
- (SWEREF-278) NASA-STD-8739.8B, NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A"
15.2 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
| Related Links |
|---|
15.3 Center Process Asset Libraries
SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki 197
See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).
| SPAN Links |
|---|
