1. Requirements

2.1.5.11 Each Center Director, or designee, shall contribute applicable software engineering process assets in use at his/her Centers to the Agency-wide process asset library. 

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

2. Rationale

This requirement ensures that software engineering expertise, best practices, tools, templates, methodologies, lessons learned, and other process-related artifacts developed or used by individual NASA Centers are shared across the agency. By contributing to the Agency-wide Process Asset Library (PAL) (see SWE-098 - Agency Process Asset Library), NASA can foster collaboration, standardization, continuous improvement, and increased efficiency in software engineering across missions and Centers.

The aim of this requirement is to ensure that Centers do not operate in silos and that the collective knowledge and resources developed at one Center are accessible to enhance the capabilities of all Centers agency-wide.

2.1 Key Rationale for the Requirement

1. Promotes Knowledge Sharing and Collaboration Across NASA Centers

• Centers often develop unique process assets in response to the specific challenges or missions they address, leading to valuable innovations in software engineering methodologies and workflows.
• Sharing these assets in the Agency-wide PAL enables other Centers to adopt, adapt, or improve upon these processes, eliminating duplication and encouraging cross-Center collaboration.
• A centralized repository ensures that the Agency benefits from the collective wisdom of its diverse teams, leading to higher-quality software development across NASA.

Example: A new requirements management process developed by one Center for handling complex, volatile requirements could save significant time and effort for another Center working on a similar challenge.

2. Drives Process Consistency Across the Agency

• Software engineering often involves cross-Center coordination for large-scale projects, such as multi-disciplinary missions. A consistent understanding of processes, tools, and assets increases alignment, reduces miscommunication, and avoids inefficiencies when collaborating across Centers.
• Maintaining consistency in reusable processes and assets strengthens NASA’s ability to meet technical and programmatic standards (e.g., NPR 7150.2 ⁰⁸³, SWE-053 - Manage Requirements Changes) and ensures compliance with software engineering practices.

Example: Standardizing testing processes, code review templates, or risk management methodologies across Centers facilitates integrated testing and clear expectations during multi-Center collaborations.

3. Facilitates Reuse of Proven Processes, Saving Time and Resources

• Contributing assets to the Process Asset Library allows for the reuse of processes, tools, and templates that have been validated in other projects. Instead of starting from scratch, engineers can leverage existing resources to meet project needs more efficiently.
• Reuse not only reduces development time and costs but also mitigates risk, as reused processes have been tested and proven in real-world scenarios.

Example: A Center developing software for a CubeSat mission could reuse configuration management templates or automated test scripts created for a similar mission at another Center, saving time and lowering the risk of errors.

4. Encourages Continuous Improvement of Processes

• By contributing assets to the Agency-wide PAL, Centers create opportunities for feedback, refinement, and enhancement. Other Centers and experts who use contributed assets may identify improvement areas, provide suggestions, or adapt the processes for broader application.
• This dynamic and iterative sharing leads to the ongoing improvement of NASA’s software engineering practices across the Agency.

Example: A defect tracking process contributed by one Center could be enhanced with additional metrics by another Center, resulting in a more robust process being shared agency-wide.

5. Preserves Institutional Knowledge

• Centers often develop and adopt new software engineering practices and tools to address challenges. Without a mechanism to share and document these processes, institutional knowledge can remain localized or, worse, be lost due to staff turnover or organizational changes.
• The Agency-wide Process Asset Library acts as a living repository for preserving institutional knowledge, ensuring processes endure and are available to future projects, even as personnel and missions evolve.

Example: A tool and methodology developed for risk assessment in AI-based software systems at one Center could provide a valuable baseline for future AI projects across NASA, preventing the loss of expertise in this domain.

6. Supports NASA’s Mission of Innovation and Excellence

• NASA strives to innovate and deliver high-quality, safe, and reliable software. Contributing to the PAL ensures that lessons learned, cutting-edge practices, and process innovations are showcased and made available to all Centers, enhancing the agency’s ability to tackle pioneering challenges.
• The collective improvement of software engineering processes elevates NASA’s overall technical maturity and reinforces its reputation for excellence.

Example: An innovative agile development process for rapid prototyping contributed by one Center could improve NASA’s ability to adapt quickly to evolving needs and constraints in other projects.

7. Reduces Redundancy and Waste

• Without a shared repository of process assets, Centers may unknowingly invest resources in developing solutions that already exist elsewhere. This duplication wastes time, effort, and funding.
• Contributing to the PAL ensures that Centers can easily discover and access existing resources, preventing redundant efforts and allowing NASA to focus its resources on mission-critical activities.

Example: A documentation standard or automated testing suite developed by one Center could eliminate the need for another Center to develop an equivalent solution independently, saving significant resources.

8. Establishes a Foundation for Training and Onboarding

• Process assets contributed to the PAL can serve as educational resources for new hires, contractors, or teams unfamiliar with NASA’s software engineering practices.
• Providing access to these standardized processes accelerates onboarding, reduces the learning curve, and promotes adherence to NASA-wide best practices.

Example: A junior software engineer could quickly learn NASA’s approach to requirements verification by accessing contributed templates, training materials, or tools in the PAL.

9. Ensures Alignment with Agency Standards and Policies

• Contributions to the PAL play a critical role in ensuring process compliance with NASA standards, such as NPR 7150.2: Software Engineering Requirements.
• Assets contributed to the library are more likely to align with NASA’s overall policies, technical standards, and quality assurance goals, fostering clear expectations and reducing non-compliance risks.

Example: An asset related to software safety analysis could ensure compliance with NASA’s safety-critical software development standards and processes.

2.2 Benefits for Software Engineering Across NASA

2.3 Conclusion

This requirement is central to NASA's goal of building a unified, efficient, and innovative software development community. By contributing software engineering process assets to the Agency-wide Process Asset Library:

1. NASA ensures shared learning and collaboration between Centers.
2. It improves efficiency by enabling reuse of proven processes and tools.
3. It preserves and promotes institutional knowledge for the entire agency.
4. It supports standardization and compliance with NASA's policies.

In short, this requirement ensures NASA maximizes its collective expertise, fosters continuous process improvement, and enables the delivery of high-quality, dependable software systems to support its missions.

3. Guidance

3.1 Agency Process Asset Library

3.1.1  Agency-Wide Process Asset Library Overview

The Agency-wide Process Asset Library (PAL) is a centralized repository of processes, procedures, templates, tools, training materials, job aids, best practices, and other process-related assets, designed to empower and guide successful software engineering practices across NASA Centers. (See SWE-098 - Agency Process Asset Library.) The PAL is a critical resource for fostering collaboration, standardization, process improvement, and knowledge sharing across the agency.

To ensure the PAL reflects the breadth and depth of expertise across NASA, all Centers are required to contribute their applicable process assets regularly. Contributions should represent high-quality, vetted, and relevant artifacts that facilitate NASA’s software development goals and align with its policies. A well-maintained PAL supports the agency's commitment to efficiency, innovation, and excellence in software development.

3.1.2  Guidance for Contributing to the Agency-Wide PAL

The following guidance describes how Centers should select, prepare, and submit process assets to the PAL, providing clarity and consistency in contribution practices:

3.1.2.1  Select High-Quality, Relevant Process Assets

When contributing to the PAL, prioritize the inclusion of process assets that provide substantial value, address common challenges, or represent best practices.

Contributors should use the following criteria as guides when selecting items for submission:

• Clarity and Usability: Select assets that are clear, well-documented, and actionable (e.g., artifacts that describe "what to do" or "how to do something").
• Best Examples: Contribute mature, refined, and demonstrably valuable examples of processes, tools, and templates in real-world applications.
• Relevance: Focus on assets that align with NASA’s policies, software lifecycle activities, and engineering objectives.
• Breadth of Application: Where possible, prefer assets that are general enough to be adapted across multiple Centers or projects but detailed enough to deliver actionable insights.

3.1.2.2  Vet Contributions Prior to Submission

Before submitting process assets to the PAL, ensure they are reviewed and approved by the appropriate Center authority or subject matter experts (SMEs). This ensures that the contributions meet high-quality standards and align properly with organizational and agency priorities.

• Center-Level Review: Contributions should be vetted by a relevant authority at the contributing Center, such as a Division, Branch, or process management group. Centers already performing process quality appraisals, such as CMMI® (Capability Maturity Model Integration) evaluations, may have established review mechanisms for this purpose.
• External Review and Approval: For assets subject to approval by external entities (e.g., the Office of the Chief Engineer (OCE), the Office of Safety and Mission Assurance (OSMA)), or assets presented externally (such as at industry conferences by Software Working Group (SWG) members), ensure appropriate discussions and approvals occur before submission.
• Documentation of Approval: Keep a record of the review and approval process to ensure traceability and demonstrate due diligence to the receiving body in the PAL.

3.1.2.3  Timing of Contributions

To ensure regular, effective updates to the PAL, contributions should be integrated into key project or Center workflows to make submission part of regular activities.

• Annual Review Process: Schedule an annual review of process assets at each Center preceding the NASA Software Working Group (SWG) meetings. This ensures contributions reflect the latest practices and process improvements.
• Project Closure Contributions: Include contributions as part of a project’s post-mortem or retrospective activities. For example, after completing a project, analyze which processes, templates, or tools were particularly effective and submit these items to the PAL.

3.1.2.4  Exclude Inappropriate or Restricted Content

Certain types of content are not suitable for inclusion in the PAL. Ensure the following materials are excluded:

• Sensitive But Unclassified (SBU): Do not submit assets containing sensitive or operationally critical information that could expose vulnerabilities.
• Proprietary Data: Avoid sharing materials protected by intellectual property laws or agreements with contractors or third parties.
• International Traffic in Arms Regulations (ITAR): Confirm that assets containing sensitive technologies or data under ITAR restrictions are not included in the PAL.

Contributors are responsible for ensuring their submissions adhere to these restrictions and that sensitive information is appropriately redacted or excluded.

3.1.3  Examples of Assets to Contribute

The PAL focuses on a broad range of software engineering and process-related assets. The following examples demonstrate the types of materials to contribute:

3.1.3.1  Processes and Procedures

Contribute assets that align with NASA’s policies and standards across all aspects of software engineering and project management:

• Management Processes: Estimation, class transition, planning, monitoring and control, risk and issue management, configuration management, and change management.
• Engineering Processes: Requirements engineering, design, coding and integration, peer reviews, verification and validation, release processes, sustaining engineering, and retirement planning.
• Support Processes: Software assurance activities, safety practices, decision-making frameworks, metrics collection, and process improvement.
• Acquisition Processes: Assets related to software purchasing, contracting, and third-party/vendor management.

3.1.3.2  Process-Driven Assets

Contributions should also include tools and materials that support process implementation:

• Templates, Checklists, and Forms: Ready-made templates for project artifacts such as requirements review checklists, risk registers, or test case documentation.
• Training Materials: Resources for onboarding teams, including training guides, workshops, and step-by-step tutorials.
• Standards and Guidelines: Documentation on how to meet NASA’s technical and programmatic standards for software engineering.
• Logs and Databases: Examples of tools for tracking project data (e.g., defect logs, test logs).

3.1.3.3  Examples and Project Artifacts

Assets that demonstrate real-world application or lessons learned can provide significant value:

• Case Studies: Examples of how projects implemented specific processes or overcame significant challenges.
• Metrics and Reports: Examples of project reports demonstrating the use of collected metrics (e.g., cost/schedule growth, defect trends).
• Tools and Software Utilities: Scripts, software utilities, or other tools frequently used in software development efforts.
• Milestone Review Materials: Iterative design materials shared during Preliminary Design Reviews (PDRs) or Critical Design Reviews (CDRs).

3.1.4  Submission Processes

1. Identify Key Contributions
   Conduct reviews of current and historical projects to identify new or updated process assets suitable for inclusion.
2. Prepare Contributions for Submission
   • Ensure clarity and completeness of submitted assets.
   • Remove any restricted or sensitive information.
   • Verify adherence to proper documentation and process formatting.
3. Submit to the PAL
   Submit reviewed and approved contributions via the NASA Engineering Network (SPAN tab) or through designated Center processes for PAL updates.

3.1.5  Benefits of Contributing to the PAL

By contributing high-quality process assets, Centers strengthen the collective knowledge and capabilities of NASA’s software engineering teams. Key benefits include:

• Knowledge Sharing: Enabling other Centers to leverage proven methods and tools.
• Process Standardization: Reducing variability across Centers and promoting consistent excellence.
• Efficiency and Reuse: Saving time and resources by making reusable assets accessible agency-wide.
• Continuous Improvement: Learning from shared lessons and innovations to drive process enhancements.

3.1.6 Conclusion

The Agency-wide Process Asset Library (PAL) is a foundational resource for improving NASA’s software engineering practices. Centers are responsible for ensuring their contributions are meaningful, vetted, and aligned with the agency’s mission. By leveraging the PAL, NASA can reduce inefficiencies, improve collaboration, and foster innovation across its diverse portfolio of projects.

3.2 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.3 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

For small projects with limited scope, resources, or duration, this requirement may seem challenging due to time constraints or the perception that their processes or outputs do not offer value to the wider agency. However, small projects often yield insights, simplified approaches, or lightweight assets that are highly beneficial for sharing, especially for similar-sized efforts or constrained environments. This guidance offers a tailored approach to help small projects contribute to the PAL effectively and efficiently.

4.1 Guidance for Small Projects

4.1.1  Key Considerations for Small Projects

While small projects have streamlined processes and minimal artifacts, their contributions to the PAL remain vital. Here’s why:

• Efficient and Lightweight Practices: Small projects often develop simplified approaches (e.g., agile workflows, lean templates) that can be valuable to teams seeking a more efficient framework.
• Innovative Problem-Solving: With limited resources, small projects often craft creative solutions to solve unique challenges, which can benefit other projects.
• Scalability of Solutions: Assets developed for small-scale efforts, such as compact checklists, reusable scripts, or one-page templates, can often be scaled up or adapted for larger projects.

Takeaway: Even small contributions, when streamlined and applicable, can deliver high value to other teams or Centers.

4.1.2  Identify Process Assets Suitable for Submission

Small projects should focus on identifying assets that highlight efficient, practical solutions for the software engineering lifecycle. Contributions don’t have to be comprehensive—valuable assets could include even single elements of a process.

Examples of Small Project Contributions:

1. Templates and Checklists:
   • Lean deliverables such as a lightweight test plan template, defect tracking logs, or code review checklists.
   • Examples: “Condensed Agile Sprint Checklist,” “Lightweight Requirements Traceability Matrix.”
2. Scripts and Tools:
   • Reusable automation scripts for testing, code validation, or configuration management.
   • Examples: “Python Script for Automated Code Formatting,” “Lightweight Build Pipeline Setup Guide.”
3. Best Practices for Small Teams:
   • Practical guides for handling challenges faced by small, resource-constrained teams.
   • Examples: “Effective Risk Management for Small Software Projects,” “Rapid Prototyping Workflow for Agile Teams.”
4. Training and Guides:
   • Succinct training documents or step-by-step job aids geared toward small projects.
   • Examples: “Quick Start Guide: Version Control for 3-Person Teams,” “Test Case Prioritization for Small Projects.”
5. Lessons Learned and Examples:
   • Share examples of project artifacts or post-mortem findings that embody lightweight innovations or notable successes.
   • Examples: “Case Study: Managing Requirements on a 4-Month Timeline,” “How We Mitigated Scope Creep on a Budget.”
6. Small-Scale Agile or Hybrid Methodologies:
   • Documentation of adapted agile or hybrid methods tailored for small projects.
   • Examples: “Agile/Waterfall Hybrid for Limited Development Resources.”

Tip: Keep contributions concise and focused. Single documents or small resources can have significant impact if they’re clear, actionable, and relevant.

4.1.3  Simplified Submission Workflow for Small Projects

Small projects often lack the time or resources to manage intensive approval or contribution processes. To streamline efforts, small projects should follow a practical, minimalistic submission process:

Step 1: Identify Opportunities for Sharing

• • During Project Execution: Document any new or improved processes, tools, or lessons developed that stand out.
  • Post-Project Retrospective: Review successes, challenges, and artifacts during the project’s closeout for assets that are widely applicable.

Step 2: Refine and Generalize

• • Simplify Language: Adjust process descriptions, templates, or examples for broader applicability. Avoid specific jargon or niche constraints that may limit its use.
  • Redact Proprietary or Limited Data: Ensure sensitive, proprietary, or SBU/ITAR-restricted content is removed or anonymized.

Step 3: Vet Submission Efficiently

• • Identify a small set of reviewers from your Center (e.g., team leads, process SMEs, or QA staff) who can validate the contribution’s quality, clarity, and compliance with organizational needs.
  • For very small teams, the project lead or software engineer may coordinate an informal review of the submission before escalation.

Step 4: Submit to Center PAL Representative

• • Consolidate the contribution and forward it to the Center designee responsible for process asset submissions to the Agency-wide PAL.
  • Include a brief summary of the asset (e.g., purpose, intended audience, suggested use cases) to aid other teams in evaluating its relevance.

Tip: Center-level representatives can assist with final alignment, formatting, or follow-up reviews for PAL-wide submissions, easing the administrative burden on small projects.

4.1.4  Timing and Triggers for Submission

Including contributions as part of regular project workflows ensures they are submitted without requiring additional significant effort or delays.

Recommended Points for Contribution:

1. Post-Project Closeout
   • After the project, submit refined versions of lessons learned, templates, or best practices.
   • Example: “Simplified Peer Review Template developed during the XYZ module’s deployment.”
     
     
2. Annual Review Cycles
   • Coordinate with your Center to submit artifacts during annual Center PAL reviews or preceding the NASA Software Working Group Meeting.
   • Example: “Checklist from a defect triage process used effectively during the past year on two small projects.”
     
     
3. After Process/Tool Development
   • Submit process assets immediately after new tools, scripts, or lightweight methods are developed and verified to work.
   • Example: “Python script for small test coverage validation during integration testing.”

4.1.5  Best Practice Recommendations for Small Projects

1. Focus on Usability
   Small projects don’t need to contribute highly detailed assets or full process documents—keep submissions lightweight and easy for others to adopt or adapt.
   
   
2. Document Lessons Learned Efficiently
   Capture lessons as they emerge during the project lifecycle or in a brief closeout session. Even small lessons from daily practices or challenges can have broader applicability.
   
   
3. Collaborate with Center Support Staff
   Teams with limited resources should leverage Center-level PAL representatives or process groups for help refining, reviewing, or formatting contributions.
   
   
4. Leverage Historical and Existing Assets
   If possible, small projects can adapt and reuse materials from the PAL to create project-specific assets, then refine and resubmit them back to the library after enhancing or tailoring them.
   
   
5. Use Familiar Tools to Capture Contributions
   Stick with simple tools like spreadsheets, lightweight word processors, or scripts to document contributions that do not require recreating artifacts unnecessarily.

4.1.6  Simplified Examples of Small Project Contributions

Example 1: Checklists

• Before Submission: “Checklist for Agile Sprint Planning for Small Teams”
• After Submission: Include sample scenarios (e.g., projects with 3-5 developers) to demonstrate usability.

Example 2: Lessons Learned

• Before Submission: Notes from retrospective identifying successful testing approach.
• After Submission: “Guidelines for Lightweight Integration Testing (Small Teams)—based on lessons learned from Project ABC.”

Example 3: Scripts/Tools

• Before Submission: A custom script developed to automate test execution reporting.
• After Submission: “Automation Script for Test Execution Reporting with Basic Instructions for Use.”

4.1.7  Benefits of Small Project Contributions

• Value for Similar Projects: Other small or resource-constrained projects can save time and effort by repurposing lightweight processes or tools.
• Visibility and Recognition: Contributions showcase innovation and practical solutions, highlighting the project's impact across Centers.
• Cultural Impact: Sharing encourages collaboration and sets a precedent for knowledge transfer.

4.2 Conclusion

Although small projects operate with fewer resources, their creative, practical, and focused contributions can provide immense value to NASA’s Agency-wide PAL. By leveraging lightweight, scalable, and efficient processes, small projects can significantly impact how other teams approach software development challenges, fostering a culture of collaboration, reuse, and continuous improvement.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

The purpose of this requirement is to ensure that all Centers collaborate to build a shared repository of vetted software engineering processes, templates, tools, and artifacts, facilitating continuous improvement, knowledge transfer, and process standardization across NASA. Below is a curated selection of lessons learned from NASA’s Lessons Learned Information System (LLIS) that directly support this requirement.

6.1.1  Relevant NASA Lessons Learned

1. Knowledge Sharing Promotes Mission Success

• Lesson Title: Importance of Knowledge Transfer Between Projects
• Lesson Number: 2257
• Summary:
  • NASA projects often fail to take full advantage of existing knowledge due to limited collaboration between teams or inability to access relevant materials from earlier missions. The failure to share lessons learned and process documentation across Centers leads to inefficiencies, repeated mistakes, and missed opportunities to leverage proven approaches.
• Relevance to Requirement:
  • This lesson reinforces the importance of creating a centralized repository (such as the PAL) that ensures process assets and lessons learned from different Centers are shared agency-wide. Contributing assets to the PAL helps future projects avoid redundant efforts and fosters stronger collaboration between Centers.
• Key Takeaway:
  • Encourage every project to document and submit reusable process assets—such as templates or tools—at closeout to mitigate knowledge loss and improve mission efficiency.

2. Lessons Learned from Previous Projects Enable Process Improvement

• Lesson Title: Effective Use of Historical Process Data for Continuous Improvement
• Lesson Number: 1793
• Summary:
  • When historical process data is accessible, teams are better equipped to refine existing software practices, predict risks, and estimate realistic costs and schedules. However, without a formal mechanism to gather and share these insights, such data is often siloed within specific teams or Centers, preventing broad adoption of improved methodologies.
• Relevance to Requirement:
  • This lesson illustrates the value of contributing software process assets to the PAL as a means of capturing historical practices, lessons, and process refinements for agency-wide use. By consistently contributing assets, Centers support continuous process improvement while elevating the overall maturity level of NASA's software engineering practices.
• Key Takeaway:
  • Ensure key process artifacts are uploaded to the PAL, along with accompanying context, to enable other Centers to understand their applicability and adapt them for new projects.

3. Standardization Improves Collaboration Across Centers

• Lesson Title: Need for Consistent Practices in Multi-Center Projects
• Lesson Number: 1462
• Summary:
  • Differences in process standards and tools used across NASA Centers have caused coordination challenges on large, multi-Center projects. When Centers use inconsistent templates, methods, or milestone definitions, integration becomes difficult and errors increase. Standardization of processes at an agency level is necessary for seamless collaboration.
• Relevance to Requirement:
  • By contributing to the PAL, Centers help NASA standardize software engineering practices. Shared process assets enable alignment and reduce friction during multi-Center collaborations, ensuring projects can rely on consistent workflows, definitions, and expectations.
• Key Takeaway:
  • Focus submissions on process assets that facilitate standardization, including widely applicable templates, review criteria, and guidelines for cross-Center activities.

4. Process Improvements Are Ineffective When Not Shared ⁵⁵²

• Lesson Title: Failure to Disseminate Process Improvements Leads to Stagnation
• Lesson Number: 1384
• Summary:
  • Process improvements created in specific projects were often retained locally, with few efforts made to disseminate them broadly across NASA. The lack of shared process improvement mechanisms resulted in missed opportunities to elevate the agency’s practices and avoid repeated inefficiencies.
• Relevance to Requirement:
  • This lesson highlights the necessity of requiring contributions to the PAL to capture and distribute process improvements agency-wide. Without centralized sharing, innovations are lost or duplicated unnecessarily.
• Key Takeaway:
  • Encourage the submission of improved processes or methodologies to the PAL immediately after validation to ensure they reach other Centers promptly.

5. Insights from Small Projects Are Valuable

• Lesson Title: Lessons Learned from Small, Agile Projects Scale Across NASA
• Lesson Number: 2031
• Summary:
  • Small projects operating under resource constraints often develop innovative, agile methodologies that later benefit large, complex projects. However, these insights are often overlooked because small teams may not document or share their practices formally.
• Relevance to Requirement:
  • This lesson addresses the importance of encouraging small teams and small-class projects to contribute lightweight process solutions to the PAL. Even small contributions, such as compact checklists or agile workflows, can deliver significant value to other projects, particularly those with similar constraints.
• Key Takeaway:
  • Ensure small teams understand the agency-wide importance of their practices and submit their lightweight solutions through the Center PAL representative.

6. Cross-Center Collaboration Motivates Process Asset Submission

• Lesson Title: Successes in Knowledge Transfer Enhance Collaboration
• Lesson Number: 2178
• Summary:
  • Centers were more likely to contribute process assets to shared repositories when they saw direct examples of successful collaboration and reuse of those assets across projects. Visible benefits, such as improved outcomes on key missions, motivated continued engagement with agency-wide resources.
• Relevance to Requirement:
  • Highlighting success stories from PAL contributions—such as examples of assets being reused effectively—can motivate further submissions by demonstrating direct benefits to NASA’s software engineering efforts.
• Key Takeaway:
  • Include examples of successful PAL reuse in internal communications to encourage more frequent contributions.

7. Cost and Time Benefits from Reuse of Process Assets

• Lesson Title: Reuse of Templates and Tools Saves Significant Resources
• Lesson Number: 1157
• Summary:
  • Projects that reused templates, tools, or guidelines from prior efforts were able to reduce development costs and shorten schedules by avoiding redundant work. However, without reliable repositories of reusable assets, teams often needlessly reinvent solutions.
• Relevance to Requirement:
  • This lesson underscores the importance of maintaining a comprehensive and diverse PAL populated with reusable process assets. Contributions to the PAL ensure future teams can save time and resources by leveraging existing, proven solutions.
• Key Takeaway:
  • Submit reusable process assets—such as checklists or automated testing scripts—as these have demonstrated significant cost and time-saving potential for other teams.

8. Lesson: Leverage Lessons Learned for Training and Standards

• Lesson Title: Training Assets Can Reduce Onboarding and Compliance Risks
• Lesson Number: 1953
• Summary:
  • Training materials and process templates shared across projects were invaluable for onboarding new staff and ensuring compliance with NASA standards. These assets simplified workflows for new hires and helped experienced teams adhere to agency-wide policies.
• Relevance to Requirement:
  • Contributing training materials, onboarding guides, and process examples to the PAL helps standardize workflows and reduces ramp-up time for new or transitioning staff. It also increases adherence to NASA’s software engineering standards.
• Key Takeaway:
  • Include training guides, how-to tutorials, and quick reference materials in PAL contributions to enhance usability and compliance across projects.

9. Importance of Capturing Post-Mission Retrospective Artifacts

• Lesson Title: Post-Mission Reviews are Essential for Documenting Process Improvements
• Lesson Number: 1298
• Summary:
  • During post-mission reviews, documentation of successful processes or practices was often neglected, resulting in lost opportunities for iterative improvement. Capturing retrospectives systematically ensures that valuable insights are preserved for future use.
• Relevance to Requirement:
  • This lesson emphasizes the role of post-mission retrospectives in contributing process assets to the PAL. Teams should prioritize submitting refined artifacts and lessons learned after project closure.
• Key Takeaway:
  • Include PAL submissions as part of your project’s end-of-life activities to ensure effective documentation of valuable practices.

6.1.2  Conclusion

These lessons emphasize the critical role the Agency-wide Process Asset Library plays in NASA’s ability to continuously improve its software engineering practices. By focusing on collaboration, standardization, efficiency, reuse, and knowledge transfer, process assets submitted by Centers strengthen the agency’s ability to deliver high-quality, reliable software across missions.

Key Actions Supported by Lessons Learned:

1. Encourage regular contributions to the PAL, especially following major project milestones or retrospectives.
2. Ensure small projects understand their contributions are valuable and scalable.
3. Align PAL submissions with processes proven to provide time-saving, cost-saving, or compliance benefits.
4. Demonstrate how PAL contributions facilitate cross-Center collaboration and success.
5. Prioritize reusable assets (e.g., templates, tools, training materials) to maximize the PAL’s practical value.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products 

Software Assurance (SA) products are tangible outputs created by Software Assurance personnel to support oversight, validate compliance, manage risks, and ensure the quality of delivered products. These products are essential to demonstrate that SA objectives are being met, and they serve as evidence of the thoroughness and effectiveness of the assurance activities performed.

No specific deliverables are currently identified.

7.3 Metrics

No standard metrics are currently specified.

7.4 Guidance

7.4.1  Objective of the Guidance

This requirement ensures Centers share their software engineering process assets with NASA’s Agency-wide process asset library (PAL) (see SWE-098 - Agency Process Asset Library). The goal is to promote knowledge sharing, increase consistency across Centers, and build a repository of best practices, tools, templates, and processes to support software engineering activities.

Software Assurance (SA) personnel play a key role in verifying that contributions are relevant, complete, and align with applicable standards. SA ensures these process assets capture best practices while adhering to NASA software assurance policies and guidelines.

7.4.2  Software Assurance Responsibilities

7.4.2.1  Verify Applicable Process Assets Are Identified

1. Understand the Definition of Process Assets
   • Ensure the Center has a clear understanding of what qualifies as a software engineering process asset. Examples include:
     • Software Engineering Standards: Templates, guidelines, or procedures for development, testing, or integration.
     • Process Documentation: Workflows or process maps for activities such as requirements development, coding practices, peer reviews, or V&V (Verification and Validation).
     • Tools or Scripts: Tools used for software metrics collection, defect management, or automation of testing activities.
     • Lessons Learned and Best Practices: Documents capturing insights from previous projects that enhance process efficiency or quality.
2. Identify Assets Used at the Center
   • Work with software engineering and assurance teams to identify process assets currently in use that contribute to software quality and compliance.
3. Establish Criteria for Contributions
   • Verify that the Center identifies and contributes applicable software engineering process assets that:
     • Are broadly applicable across NASA programs or projects (beyond specific Centers or teams).
     • Enhance engineering, assurance capabilities, or compliance with standards such as NPR 7150.2 ⁰⁸³, NASA-STD-8739.8 ²⁷⁸, or other directives.
     • Are mature, well-documented, and successfully implemented.

7.4.2.2  Verify the Assets Meet Contribution Standards

1. Ensure Completeness and Quality of Assets
   • Verify process assets before they are contributed to the Agency-wide PAL to ensure:
     • Documentation is complete, accurate, and free of unnecessary ambiguities.
     • Related artifacts (e.g., guidelines, examples, or usage instructions) are included to make the asset easier to use.
     • Perform Software Assurance reviews to assess the quality and maintainability of the process asset.
2. Ensure Compliance with NASA Standards
   • Confirm that process assets align with applicable NASA software engineering and assurance standards (e.g., NPR 7150.2, NASA-STD-8739.8).
   • Ensure assets reflect best practices for software safety, reliability, and mission-criticality.

7.4.2.3  Facilitate the Contribution Process

1. Standardize Submission Procedures
   • Work with the Center Director (or designee) to establish procedures for submitting assets to the Agency-wide PAL, including:
   • How assets are selected for contribution.
   • The format and documentation required for submission.
   • Metadata provided with the asset, such as its purpose, scope, and recommended usage.
2. Collaborate with Relevant Teams
   • Ensure software assurance staff works closely with engineering teams to identify, document, and validate process assets.
   • Confirm roles and responsibilities for asset maintenance and ownership are defined before submission, enabling updates if required.
3. Support Asset Documentation
   • Ensure each asset is accompanied by appropriate documentation, including:
     • Intended application/use case.
     • Benefits or improvements achieved through its adoption.
     • Instructions for implementation or integration into a project.

7.4.2.4  Ensure Assets Are Maintained Post-Contribution

1. Monitor Changes to Contributed Assets
   • If the Center updates or improves a process asset in use, ensure the new version is contributed to the PAL.
   • Verify that changes are documented and tracked consistently.
2. Maintain Traceability
   • Ensure a clear record of what process assets have been contributed to the PAL, including submission dates and responsible individuals/teams for maintenance.

7.4.2.5  Promote Use and Adoption of Process Assets

1. Encourage Adoption of PAL Assets
   • Ensure assurance teams evaluate assets contributed by other Centers in the PAL for potential use at the Center.
   • Collaborate with engineering teams to integrate Agency-wide best practices into current workflows and processes.
2. Provide Feedback
   • Work with NASA stakeholders to provide feedback on contributed assets, identifying potential gaps or opportunities for improvement.
   • Share lessons learned from using contributed assets to refine the PAL’s value for all Centers.

7.4.2.6  Monitor Contributions for Compliance

1. Audit Center Contributions and Usage
   • Verify that required contributions are made in a timely and consistent manner.
   • Confirm that process assets meet all quality and compliance standards before submission.
2. Maintain Contribution Metrics
   • Track the number, type, and quality of process assets contributed by the Center to ensure ongoing compliance and alignment with this requirement.

7.4.3  Expected Outcomes

Through proactive application of these responsibilities, Software Assurance personnel will help the Center achieve the following:

1. Complete Contributions:
   • Ensure all applicable software engineering process assets in use at the Center are identified, cleaned up (if necessary), and contributed to the Agency-wide PAL.
2. High-Quality Assets:
   • Contributions meet NASA standards, are well-documented, and provide value to other Centers.
3. Compliance:
   • The Center fulfills its responsibilities under NPR 7150.2, ensuring its process assets are regularly and reliably shared with the Agency-wide PAL.
4. Enhanced Collaboration:
   • Shared process assets facilitate cross-Center knowledge sharing, improvements in software quality, and reduction of redundant efforts across NASA.
5. Continuous Improvement:
   • The PAL is leveraged for both aggregating best practices and integrating valuable assets contributed by other Centers into the Center’s own processes.

7.4.4  Conclusion

Software Assurance (SA) personnel should ensure the Center complies with the requirement to contribute applicable software engineering process assets to the Agency-wide process asset library (PAL). This includes verifying the completeness and quality of contributions, facilitating the submission process, and ensuring ongoing maintenance of assets. By enabling effective sharing and reuse of key process components, SA supports the enhancement of software engineering practices across NASA programs and projects.

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: