1. Introduction1.1 Activity ConceptCurrently the SWEHB is a collection of pages: - SWEs - Requirements from NPR 7150.2D along with Rationale, Guidance, Small Projects, Resources, Lessons Learned and Software Assurance, if applicable
- Topics - Additional guidance for appropriate for some SWEs
- PATs - Process Asset Templates - derived from SWEs and Topics
- Other pages - such as Document Contents, FAQs, etc.
Pages include links to other pages based on the relevance of the content on those pages. The notion of Activity is a natural way to bring together pages from the existing SWEHB into a collection of pages that have a common purpose, an Activity.
1.2 Activity SequenceSoftware Engineering activities are conducted in a predictable sequence. This sequence may be a once through / "waterfall" cycle. Or, it may be an iterative or evolutionary series of cycles which build toward a final product. Regardless of the model chosen, individual activities in all these cycles are very similar. The major activity groupings here give you a quick way to find guidance in the SWEHB to help you satisfy the needs of the development project while also satisfying the requirements of NPR 7150.2. The activities associated with Software Development are listed in the tabs of this page. Each tab takes you to a list of links to pages where the activity is is explained in more detail. At the lowest level, there is a list of links to specific pages in the SWEHB where details of the activity are explained and more guidance is provided. In some cases, templates or other Process Assets are included to further help you in conducting the activity.
1.1 Activity GroupingsThe tabs in this page initially will contain all of the activities in Ch 2 through 5 of NPR 7150.2. This is done to ensure that all SWEs are accounted for. As the page matures, Topics, PATs, and other resources will be distributed to enrich the content of the activities. |
2. Institutional ActivitiesThe Institutional Activities include activities associated with OCE, OSMA, and Centers as well as Software Development Project teams. Each activity contains several requirements (from NPR 7150.2D chapter 2) ensuring that higher levels of management establish certain means and infrastructure for projects to use in their projects. In some cases, requirements for Project teams are included describing the use of the management provided resources in their projects. For example: Management is responsible for providing training for engineers who develop software. Project teams are responsible for ensuring that team members have had this training (in addition to other training on project specific systems and software) so that they may produce high quality software. 2.1 OCE and OSMA Software Engineering InitiativeAgency Level Activities are intended to provide "enabling support" to project teams. These activities include direction, guidance and support to project teams. The requirements describing these activities are found in NPR 7150.2D Chapter 2. The full activity includes some requirements from Chapters 3 through 5 which are the responsibility of the project teams to satisfy. Many of the names for these Activities come directly from NPR 7150.2D. In a few cases, the names are changed to better express the full scope of the Activity. | Activity Name | Activity Components |
|---|
| OCE and SMA benchmarking and determining the capability and maturity of software development groups. Benchmarking techniques derived from CMMI best practices. | | Training at all levels from Agency (engineering practices and related training) down to project needs (training for personnel on using development tools). | | Development of repeatable processes and practices for OCE, SMA and Center development activities. | | Determining the applicability of NPR 7150.2 requirements to a particular project. Includes requirements necessary for particular software classifications. Includes SWEs from section 3.5 Software Classification Assessments. | | Suggested measurements and practices for software projects.
Software measurement is a primary tool for managing software processes and evaluating the quality of software products. Analysis of measures provides insight into the capability of the software organization and identifies opportunities for software process and product improvements. Software measurement programs at multiple levels are established to meet measurement objectives. The requirements below are designed to reinforce the use of measurement at the project, Center software organization, and NASA Chief Engineer levels to assist in managing projects, assuring quality, and improving software engineering practices. |
| | The NASA OCE shall maintain an Agency-wide process asset library of applicable best practices and process templates for all size projects |
| | Requirements related to the licensing, sharing and reuse of some or all of software products. |
|
3. ActivitiesThe Software and Assurance activities associated with Software Development Projects are listed as links below. Each page will contain an activity description and contain links to all the associated SWEs, Topics, PATs, and other pages in the SWEHB that are associated with the activity. 3.1 Software Activity PagesLinks go to existing pages. Underlined (Red in edit mode) links have not yet been created. All activity pages to be children of the Software Project Activities page. Content structure is contained in the Activity Template. Project Software Activities| Activity Name | Activity Components |
|---|
| Life Cycle Planning | Software life cycle planning covers the software aspects of a project from inception through retirement. The software life cycle planning is an organizing process that considers the software as a whole and provides the planning activities required to ensure a coordinated, well-engineered process for defining and implementing project activities. These processes, plans, and activities are coordinated within the project. At project conception, software needs for the project are analyzed, including acquisition, supply, development, operation, maintenance, retirement, decommissioning, and supporting activities and processes. The software effort is scoped, the development processes defined, measurements defined, and activities are documented in software planning documents. |
| | Software Peer Reviews and Inspections | Software peer reviews and inspections are the in-process technical examination of work products by peers to find and eliminate defects early in the life cycle. Software peer reviews and inspections are performed following defined procedures covering the preparation for the review, the review itself is conducted, results are recorded, results are reported, and completion criteria is certified. When planning the composition of a software peer review or inspection team, consider including software testing, system testing, software assurance, software safety, software cybersecurity, and software IV&V personnel. |
| | Used when software is acquired or secured from outside sources. | | Used for monitoring progress and keeping the project under control through minor adjustments | | Used for establishing cost of development of the software products. It includes multiple models and parameters, direct and indirect costs, for the work so that tracking can be effectively done. | | Used for establishing and maintaining the development and delivery schedule. Takes into account dependencies on other projects and programs. Includes time for reviews and tracking of issues to resolution, | | Ensures that the project follows established processes and practices. Includes audits and corrective actions. | | Independent testing and evaluation of software against requirements and performance criteria. Applicable to certain categories of projects. Includes planning, execution of tests and tracking issues and risks to closure. | | Includes determining of software is considered safety-critical, and implementing additional requirements to ensure safety of the software product. | |
| | Evaluation of software requirements and planning for their realization in the final software products. | | Experience confirms that the quality and longevity of a software-reliant system is primarily determined by its architecture. The software architecture underpins a system’s software design and code; it represents the earliest design decisions, ones that are difficult and costly to change later. The transformation of the derived and allocated requirements into the software architecture results in the basis for all software development work. |
| | Software design is the process of defining the software architecture, components, modules, interfaces, and data for a software system to satisfy specified requirements. The software architecture is the fundamental organization of a system embodied in its components, their relationships to each other and the environment, and the principles guiding its design and evolution. The software architectural design is concerned with creating a strong overall structure for software entities that fulfill the allocated system and software-level requirements. Typical views captured in an architectural design include the decomposition of the software subsystem into design entities, computer software configuration items, definitions of external and internal interfaces, dependency relationships among entities and system resources, and finite state machines. The design should be further refined into lower-level entities that permit the implementation by coding in a programming language. Typical attributes that are documented for lower-level entities include the identifier, type, purpose, function, constraints, subordinates, dependencies, interface, resources, processing, and data. Rigorous specification languages, graphical representations, and related tools have been developed to support the evaluation of critical properties at the design level. Projects are encouraged to take advantage of these improved design techniques to prevent and eliminate errors as early in the life cycle as possible. Software, developed or purchased, has additional requirements to comply with from Section 508 of the Rehabilitation Act, as defined in NPR 2800.2. |
| | Software implementation consists of implementing the requirements and design into code, data, and records. Software implementation also consists of following coding methods and standards. Unit testing is also usually a part of software implementation (unit testing can also be conducted during the testing phase). |
| | Includes integration of modules into a final deliverable package and testing of that package to determine if it is ready for delivery. The purpose of testing is to verify the software functionality and remove defects. Testing verifies the code against the requirements and the design to ensure that the requirements are implemented. Testing also identifies problems and defects that are corrected and tracked to closure before product delivery. Testing also validates that the software operates appropriately in the intended environment. Please note for Class A software there are additional software test requirements and software integration requirements as defined in NPR 8705.2. |
| | Final determination of the readiness of the software for release. Includes acceptance testing, and other readiness criteria. | | Addresses any ongoing maintenance considerations for the software products. Planning for operations, maintenance, and retirement are typically considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement. |
| | Addresses any ongoing operations considerations for the software products Planning for operations, maintenance, and retirement are typically considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement. |
| | Addresses any retirement or replacement considerations for the software products Planning for operations, maintenance, and retirement are typically considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement. |
| | Includes control over software products during development along with any associated work products. Software Configuration Management (SCM) is the process of applying configuration management throughout the software life cycle to ensure the completeness and correctness of software configuration items. SCM applies technical and administrative direction and surveillance to identify and record the functional and physical characteristics of software configuration items, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. SCM establishes and maintains the integrity of the products of a software project throughout the software life cycle. Use of standard Center or organizational SCM processes and procedures is encouraged where applicable. |
| | Planning, monitoring and controlling risks which could impact the software products. Record, analyze, plan, track, control, and communicate all of the software risks and mitigation plans. |
| | Identification and tracking of non-conforming products and software. Includes ensuring that defects are removed or fixed. | | Includes the closing of projects and dispositioning work products that may need to be used in subsequent projects related to the software products. Planning for operations, maintenance, and retirement are typically considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement. |
|
3.2 Software Assurance ActivitiesMany of the activities of Software Assurance run parallel to Software Development Activities. In fact, development activities that have specific SA participation have a tab in the SWE specifically for Software Assurance participation. To further this relationship, the activities below draw on the SA requirements and tasks from NASA-STD-8739.8B and are associated with the SWEs in NPR 7150.2D. | Activity Name | Activity Components |
|---|
| Planning of Software Assurance activities in a Software Development Project are done in a collaborative fashion along with the Software Development team. It includes cost estimates and schedules. | | Software Assurance tasks found in Development Activities which audit the processes and work products associated with individual SWEs. | - SA SW Requirements Analysis
| Software Assurance Analysis tasks in Software Requirements and related activities which further improve the quality of the Software Requirements. Reducing requirement ambiguity, defects, and associated re-work in the of the software. | | Software Assurance Analysis tasks in Software Design and related activities which further improve the quality of the Software Design. Reducing defects and associated re-work in the design of the software. | - SA SW Source Code Analysis
| Software Assurance Analysis tasks in Software Source Code and related activities which further improve the quality of the Software Source Code. Reducing defects and associated re-work in the of the software. | | Software Assurance Analysis tasks in Software Testing and related activities which further improve the quality of the Software Testing. Improving test coverage, reducing test defects and associated re-work in the of the software. | | Software Assurance Analysis tasks in Software Reporting and related activities which further improve the overall Software Development Processes. Improving the Development Processes reduces defects and associated re-work in the of the software. | | Independent testing and evaluation of software against requirements and performance criteria. Applicable to certain categories of projects. Includes planning, execution of tests and tracking issues and risks to closure. | - SA Safety and Hazard Analysis
|
| | SA Test Witnessing |
|
|
4. Distribution of SWEHB pagesThis tab contains a distribution of SWEs into Activities. Each SWE in the SWEHBVD is in the table. The table lists the Primary Activity in which the SWE is located. Also, for those SWEs that are associated with other activities, the associated activities are listed. This table will be used to distribute the SWEs into activities ensuring that none are lost in the distribution process. Under Construction in separate spreadsheet. This table will be updated periodically as the spreadsheet is completed. 4.1 SWE pages| SWE | NPR para | Primary Activity | Associated Activity |
|---|
| SWE-002 - Software Engineering Initiative | 2.1.1.1 | Process Definition |
| | SWE-004 - OCE Benchmarking | 2.1.1.2 | Benchmarking and Appraisals |
| | SWE-152 - Review Requirements Mapping Matrices | 2.1.1.3 | Requirement Mapping and Tailoring |
| | SWE-129 - OCE NPR Appraisals | 2.1.1.4 | Benchmarking and Appraisals |
| | SWE-100 - Software Training Funding | 2.1.1.5 | Training | | | SWE-098 - Agency Process Asset Library | 2.1.1.6 | Process Library |
| | SWE-208 - Advancing Software Assurance and Software Safety Practices | 2.1.2.2 | Process Definition |
| | SWE-209 - Benchmarking Software Assurance and Software Safety Capabilities | 2.1.2.3 | Benchmarking and Appraisals |
| | SWE-212 - NASA-STD-8739 Mapping Matrices | 2.1.2.4 | Requirement Mapping and Tailoring |
| | SWE-221 - OSMA NPR Appraisals | 2.1.2.5 | Benchmarking and Appraisals |
| | SWE-222 - Software Assurance Training | 2.1.2.6 | Training | | | SWE-223 - Tailoring IV&V project selections | 2.1.2.7 | Requirement Mapping and Tailoring |
| | SWE-003 - Center Improvement Plans | 2.1.5.2 | Process Definition |
| | SWE-005 - Software Processes | 2.1.5.3 | Process Definition |
| | SWE-140 - Comply with Requirements | 2.1.5.4 | Requirement Mapping and Tailoring |
| | SWE-095 - Report Engineering Discipline Status | 2.1.5.5 | Process Definition |
| | SWE-006 - Center Software Inventory | 2.1.5.6 | Process Definition |
| | SWE-091 - Establish and Maintain Measurement Repository | 2.1.5.7 | Measurements and Metrics |
| | SWE-092 - Using Measurement Data | 2.1.5.8 | Measurements and Metrics |
| | SWE-142 - Software Cost Repositories | 2.1.5.10 | Measurements and Metrics |
| | SWE-144 - Software Engineering Process Assets | 2.1.5.11 | Process Library |
| SWE-153 - ETA Define Document Content | 2.1.5.12 | Process Library |
| SWE-215 - Software License Rights | 2.1.5.13 | Licensing, Sharing and Reuse |
| | SWE-216 - Internal Software Sharing List | 2.1.5.14 | Licensing, Sharing and Reuse |
| | SWE-217 - List of All Contributors and Disclaimer Notice | 2.1.5.15 | Licensing, Sharing and Reuse |
| | SWE-214 - Internal Software Sharing and Reuse | 2.1.5.16 | Licensing, Sharing and Reuse |
| SWE-218 - Contracting Officers | 2.1.7 | Licensing, Sharing and Reuse |
| | SWE-126 - Tailoring Considerations | 2.1.8.2 | Requirement Mapping and Tailoring |
| | SWE-150 - Review Changes To Tailored Requirements | 2.2.7 | Requirement Mapping and Tailoring |
| | SWE-021 - Transition to a Higher Class | 2.2.8 | Requirement Mapping and Tailoring |
| | SWE-033 - Acquisition vs. Development Assessment | 3.1.2 | Acquisition | - Life Cycle Planning
- Software Assurance Planning
| | SWE-013 - Software Plans | 3.1.3 | Life Cycle Planning | - Software Assurance Planning
| | SWE-024 - Plan Tracking | 3.1.4 | Monitor and Control | - Life Cycle Planning
- Software Assurance Planning
| | SWE-034 - Acceptance Criteria | 3.1.5 | Acceptance and Release | - Life Cycle Planning
- Software Assurance Planning
| | SWE-036 - Software Process Determination | 3.1.6 | Life Cycle Planning | - Software Assurance Planning
| | SWE-037 - Software Milestones | 3.1.7 | Life Cycle Planning | - Software Assurance Planning
| | SWE-039 - Software Supplier Insight | 3.1.8 | Acquisition | - Life Cycle Planning
- Software Assurance Planning
| | SWE-040 - Access to Software Products | 3.1.9 | Life Cycle Planning | - Software Assurance Planning
| | SWE-042 - Source Code Electronic Access | 3.1.10 | Life Cycle Planning | - Software Assurance Planning
| | SWE-139 - Shall Statements | 3.1.11 | Requirement Mapping and Tailoring | - Life Cycle Planning
- Software Assurance Planning
| | SWE-121 - Document Tailored Requirements | 3.1.12 | Life Cycle Planning | - Software Assurance Planning
| | SWE-125 - Requirements Compliance Matrix | 3.1.13 | Life Cycle Planning | - Software Assurance Planning
| | SWE-027 - Use of Commercial, Government, and Legacy Software | 3.1.14 | Life Cycle Planning | - Software Assurance Planning
| | SWE-015 - Cost Estimation | 3.2.1 | Software Cost Estimation | - Software Assurance Planning
| | SWE-151 - Cost Estimate Conditions | 3.2.2 | Software Cost Estimation | - Software Assurance Planning
| | SWE-174 - Software Planning Parameters | 3.2.3 | Software Cost Estimation |
| | SWE-016 - Software Schedule | 3.3.1 | Software Schedules | - Software Assurance Planning
| | SWE-018 - Software Activities Review | 3.3.2 | Software Schedules |
| | SWE-046 - Supplier Software Schedule | 3.3.3 | Software Schedules | - Software Assurance Planning
| | SWE-017 - Project and Software Training | 3.4.1 | Training | | | SWE-020 - Software Classification | 3.5.1 | Requirement Mapping, Tailoring, and Classification | - Software Assurance Planning
| | SWE-176 - Software Records | 3.5.2 | Requirement Mapping, Tailoring, and Classification |
| | SWE-022 - Software Assurance | 3.6.1 | Software Assurance |
| | SWE-141 - Software Independent Verification and Validation | 3.6.2 | IV&V |
| | SWE-131 - Independent Verification and Validation Project Execution Plan | 3.6.3 | IV&V |
| | SWE-178 - IV&V Artifacts | 3.6.4 | IV&V |
| | SWE-179 - IV&V Submitted Issues and Risks | 3.6.5 | IV&V |
| | SWE-205 - Determination of Safety-Critical Software | 3.7.1 | Safety-Critical Software |
| | SWE-023 - Software Safety-Critical Requirements | 3.7.2 | Safety-Critical Software |
| | SWE-134 - Safety-Critical Software Design Requirements | 3.7.3 | Safety-Critical Software |
| | SWE-219 - Code Coverage for Safety Critical Software | 3.7.4 | Safety-Critical Software |
| | SWE-220 - Cyclomatic Complexity for Safety-Critical Software | 3.7.5 | Safety-Critical Software |
| | SWE-146 - Auto-generated Source Code | 3.8.1 | Automatic Generation of Software Source Code |
| | SWE-206 - Auto-Generation Software Inputs | 3.8.2 | Automatic Generation of Software Source Code |
| | SWE-032 - CMMI Levels for Class A and B Software | 3.9.2 | Benchmarking and Appraisals |
| | SWE-147 - Specify Reusability Requirements | 3.10.1 | Licensing, Sharing and Reuse |
| | SWE-148 - Contribute to Agency Software Catalog | 3.10.2 | Licensing, Sharing and Reuse |
| | SWE-156 - Evaluate Systems for Security Risks | 3.11.2 | Software Cybersecurity |
| | SWE-154 - Identify Security Risks | 3.11.3 | Software Cybersecurity |
| | SWE-157 - Protect Against Unauthorized Access | 3.11.4 | Software Cybersecurity |
| | SWE-159 - Verify and Validate Risk Mitigations | 3.11.5 | Software Cybersecurity |
| | SWE-207 - Secure Coding Practices | 3.11.6 | Software Cybersecurity |
| | SWE-185 - Secure Coding Standards Verification | 3.11.7 | Software Cybersecurity |
| | SWE-210 - Detection of Adversarial Actions | 3.11.8 | Software Cybersecurity |
| | SWE-052 - Bidirectional Traceability | 3.12.1 | Software Requirements |
| | SWE-050 - Software Requirements | 4.1.2 | Software Requirements |
| | SWE-051 - Software Requirements Analysis | 4.1.3 | Software Requirements |
| | SWE-184 - Software-related Constraints and Assumptions | 4.1.4 | Software Requirements |
| | SWE-053 - Manage Requirements Changes | 4.1.5 | Software Requirements |
| | SWE-054 - Corrective Action for Inconsistencies | 4.1.6 | Software Requirements |
| | SWE-055 - Requirements Validation | 4.1.7 | Software Requirements |
| | SWE-057 - Software Architecture | 4.2.3 | Software Architecture |
| | SWE-143 - Software Architecture Review | 4.2.4 | Software Architecture |
| | SWE-058 - Detailed Design | 4.3.2 | Software Design |
| | SWE-060 - Coding Software | 4.4.2 | Software Implementation |
| | SWE-061 - Coding Standards | 4.4.3 | Software Implementation |
| | SWE-135 - Static Analysis | 4.4.4 | Software Implementation |
| | SWE-062 - Unit Test | 4.4.5 | Software Implementation |
| | SWE-186 - Unit Test Repeatability | 4.4.6 | Software Implementation |
| | SWE-063 - Release Version Description | 4.4.7 | Software Implementation |
| | SWE-136 - Software Tool Accreditation | 4.4.8 | Software Implementation |
| | SWE-065 - Test Plan, Procedures, Reports | 4.5.2 | Software Testing |
| | SWE-066 - Perform Testing | 4.5.3 | Software Testing |
| | SWE-187 - Control of Software Items | 4.5.4 | Software Testing |
| | SWE-068 - Evaluate Test Results | 4.5.5 | Software Testing |
| | SWE-070 - Models, Simulations, Tools | 4.5.6 | Software Testing |
| | SWE-071 - Update Test Plans and Procedures | 4.5.7 | Software Testing |
| | SWE-073 - Platform or Hi-Fidelity Simulations | 4.5.8 | Software Testing |
| | SWE-189 - Code Coverage Measurements | 4.5.9 | Software Testing |
| | SWE-190 - Verify Code Coverage | 4.5.10 | Software Testing |
| | SWE-191 - Software Regression Testing | 4.5.11 | Software Testing |
| | SWE-192 - Software Hazardous Requirements | 4.5.12 | Software Testing |
| | SWE-193 - Acceptance Testing for Affected System and Software Behavior | 4.5.13 | Software Testing |
| | SWE-211 - Test Levels of Non-Custom Developed Software | 4.5.14 | Software Testing |
| | SWE-075 - Plan Operations, Maintenance, Retirement | 4.6.2 | Life Cycle Planning |
| | SWE-077 - Deliver Software Products | 4.6.3 | Acceptance and Release |
| | SWE-194 - Delivery Requirements Verification | 4.6.4 | Acceptance and Release |
| | SWE-195 - Software Maintenance Phase | 4.6.5 | Maintenance |
| | SWE-196 - Software Retirement Archival | 4.6.6 | Retirement |
| | SWE-079 - Develop CM Plan | 5.1.2 | Software Configuration Management |
| | SWE-080 - Track and Evaluate Changes | 5.1.3 | Software Configuration Management |
| | SWE-081 - Identify Software CM Items | 5.1.4 | Software Configuration Management |
| | SWE-082 - Authorizing Changes | 5.1.5 | Software Configuration Management |
| | SWE-083 - Status Accounting | 5.1.6 | Software Configuration Management |
| | SWE-084 - Configuration Audits | 5.1.7 | Software Configuration Management |
| | SWE-085 - Release Management | 5.1.8 | Software Configuration Management |
| | SWE-045 - Project Participation in Audits | 5.1.9 | Software Configuration Management |
| | SWE-086 - Continuous Risk Management | 5.2 | Software Risk Management |
| | SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures | 5.3.2 | Software Peer Reviews and Inspections |
| | SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking | 5.3.3 | Software Peer Reviews and Inspections |
| | SWE-089 - Software Peer Reviews and Inspections - Basic Measurements | 5.3.4 | Software Peer Reviews and Inspections |
| | SWE-090 - Management and Technical Measurements | 5.4.2 | Measurements and Metrics |
| | SWE-093 - Analysis of Measurement Data | 5.4.3 | Measurements and Metrics |
| SWE-094 - Reporting of Measurement Analysis | 5.4.4 | Measurements and Metrics |
| | SWE-199 - Performance Measures | 5.4.5 | Measurements and Metrics |
| | SWE-200 - Software Requirements Volatility Metrics | 5.4.6 | Measurements and Metrics |
| | SWE-201 - Software Non-Conformances | 5.5.1 | Software Non-conformance or Defect Management |
| | SWE-202 - Software Severity Levels | 5.5.2 | Software Non-conformance or Defect Management |
| | SWE-203 - Mandatory Assessments for Non-Conformances | 5.5.3 | Software Non-conformance or Defect Management |
| | SWE-204 - Process Assessments | 5.5.4 | Software Non-conformance or Defect Management |
|
4.2 Topic PagesIncludes Recommended Content pages from some of the topic pages. | Topic # | Activity | Associated Activities | | 6.1 - Design for Safety Checklist | SA Safety and Hazard Analysis |
| | 6.2 - Checklist for General Software Safety Requirements | SA Safety and Hazard Analysis |
| | 6.3 - Checklist for Choosing a Real Time Operating System (RTOS) | Implementation and Unit Testing |
| | 6.4 - Checklist for Choosing Off-The Shelf Software (OTS) | Implementation and Unit Testing |
| | 6.5 - Checklist for C Programming Practices | Implementation and Unit Testing |
| | 6.6 - Checklist for C++ Programming Practices | Implementation and Unit Testing |
| | 6.7 - Checklist for Ada Programming Practices | Implementation and Unit Testing |
| | 6.8 - Checklist for Fortran Programming Practices | Implementation and Unit Testing |
| | 6.9 - Checklist for Generic (Non-Language-Specific) Programming Practices | Implementation and Unit Testing |
| | 6.10 - Checklist for General Good Programming Practices | Implementation and Unit Testing |
| | 6.11 - Examples of Programming Practices for Exception Handling | Implementation and Unit Testing |
| | 7.1 - History and Overview of the Software Process Improvement (SPI) Effort | Process Definition |
| | 7.2 - Classification and Safety-Criticality | Requirement Mapping, Tailoring, and Classification |
| | 7.3 - Acquisition Guidance | Acquisition |
| | 7.4 - Flowdown of NPR Requirements on Contracts and to Other Centers in Multi-Center Projects | Life Cycle Planning | Acquisition | | 7.5 - Work Breakdown Structures That Include Software | Software Scheduling | Cost Estimation | | 7.6 - Software Test Estimation and Testing Levels | Software Scheduling | Cost Estimation | | 7.7 - Software Architecture Description | Software Architecture |
| | 7.8 - Maturity of Life-Cycle Products at Milestone Reviews | Software Scheduling | Life Cycle Planning | | 7.9 - Entrance and Exit Criteria | Software Scheduling | Life Cycle Planning | | 7.10 - Peer Review and Inspections Including Checklists | Peer Reviews and Inspections |
| | 7.11 - SWE History | n/a |
| | 7.12 - Retired | n/a |
| | 7.13 - Transitioning to a Higher Class | Requirement Mapping, Tailoring, and Classification |
| | 7.14 - Implementing Measurement Requirements and Analysis for Projects | Measurements and Metrics |
| | 7.15 - Relationship Between NPR 7150.2 and NASA-STD-7009 | Software Architecture | Software Design | | 7.16 - Appendix C. Requirements Mapping and Compliance Matrix | Requirement Mapping, Tailoring, and Classification |
| | 7.17 - 7150.2C Appendices (Definitions, References, etc.) | n/a |
| | 7.18 - Documentation Guidance | n/a |
| | CR-PR - Software Change Request - Problem Report | Non-Conformance and Defect Management |
| | IDD - Interface Design Description | Software Architecture | Software Design | | Inspect - Software Inspection, Peer Reviews, Inspections | Peer Reviews and Inspections |
| | Maint - Software Maintenance Plan | Maintenance |
| | Metrics - Software Metrics Report | Measurements and Metrics |
| | SCMP - Software Configuration Management Plan | Configuration Management |
| | SDD - Software Data Dictionary | Software Design |
| | SDP-SMP - Software Development - Management Plan | Life Cycle Planning |
| | SRS - Software Requirements Specification | Software Requirements |
| | STP - Software Test Plan | Integration and Testing |
| | STR - Software Test Report | Integration and Testing |
| | SUM - Software User Manual | Operations | Acceptance and Release | | SwDD - Software Design Description | Software Design |
| | Test - Software Test Procedures | Integration and Testing |
| | Train - Software Training Plan | Training |
| | VDD - Version Description Document | Acceptance and Release |
| | 7.19 - Software Risk Management Checklists | Risk Management |
| | 7.20 - Assessing - Meets the Intent | Risk Management |
| | 7.21 - Multi-condition Software Requirements | Integration and Testing | Safety-Critical Software | | 8.1 - Off Nonimal Testing | SA Design Analysis | SA SW Testing Analysis | | 8.2 - Software Reliability | SA Design Analysis |
| | 8.3 - Organizational Goals of Software Assurance Metrics | Measurements and Metrics |
| | 8.4 - Additional Requirements Considerations for Use with Safety-Critical Software | SA Safety and Hazard Analysis |
| | 8.5 - SW Failure Modes and Effects Analysis | SA SW Requirements Analysis | SA Safety and Hazard Analysis | | 8.6 - IV&V Surveillance | IV&V | Acquisition | | 8.7 - Software Fault Tree Analysis | SA Safety and Hazard Analysis |
| | 8.8 - COTS Software Safety Considerations | SA Safety and Hazard Analysis |
| | 8.9 - Software Safety Analysis | SA Safety and Hazard Analysis |
| | 8.10 - Facility Software Safety Considerations | SA Safety and Hazard Analysis |
| | 8.11 - Auto-Generated Code | Implementation and Unit Testing |
| | 8.12 - Basics of Software Auditing | SA Auditing |
| | 8.13 Test Witnessing | SA SW Testing Analysis | SA Auditing | | 8.14 SA Tasking for NPR 7150.2B | ? |
| | 8.15 - SA Tasking Checklist Tool | ? |
| | 8.16 - SA Products | n/a |
| | Audit Reports | SA Reporting |
| | Checklists and Guidance Lists | n/a |
| | IV&V Program Execution Plan | SA Planning | IV&V | | Objective Evidence | All SA Activities |
| | Software Assurance Plan | SA Planning |
| | Software Assurance Status Reports | SA Reporting |
| | Software Design Analysis | SA Design Analysis |
| | Software Requirements Analysis | SA SW Requirements Analysis |
| | Software Safety and Hazard Analysis | SA Safety and Hazard Analysis |
| | Source Code Quality Analysis | SA SW Source Code Analysis |
| | Testing Analysis | SA SW Testing Analysis |
| | 8.17 - Software Safety Audit Checklists | SA Auditing |
| | 8.18 - SA Suggested Metrics | Measurements and Metrics |
| | 8.19 - Dead / Dormant Code and Safety Critical Software | Licensing, Sharing and Reuse | SA Safety and Hazard Analysis | | 8.20 - Safety Specific Activities in Each Phase | SA Safety and Hazard Analysis |
| | 8.21 - Software Hazard Causes | SA Safety and Hazard Analysis |
| | 8.22 - Hazardous Commands | SA Safety and Hazard Analysis |
| | 8.23 - Software Contents of a Certification of Flight Readiness | Acceptance and Release |
| | Software Design Principles | Software Design | SA Design Analysis | | Software Safety and Design Principles | SA Design Analysis | Software Design | | Coding Standards | Software Design | SA Design Analysis | | Command Receipt Acknowledgement | Software Design | SA Design Analysis | | Data Interface Integrity | Software Design | SA Design Analysis | | Dead Code Exclusion | Software Design | SA Design Analysis | | Fault Detection and Response | Software Design | SA Design Analysis | | Flight Software Modification | Software Design | SA Design Analysis | | Incorrect Memory Use or Access | Software Design | SA Design Analysis | | Initialization - Safe Mode | Software Design | SA Design Analysis | | Invalid Data Handling | Software Design | SA Design Analysis | | Resource Margins | Software Design | SA Design Analysis | | Resource Oversubscription | Software Design | SA Design Analysis | | Resource Usage Measurement | Software Design | SA Design Analysis | | Safe Transitions | Software Design | SA Design Analysis | | Thread Safety | Software Design | SA Design Analysis |
4.3 PAT Pages4.4 Other Pages
Add page/groups from 8739.8B - SA Tasks
- IV&V Overview and Requirements
- SA Tailoring Standard Requirements
|
|
5. Activity Page StructureWe will need to decide how to consistently display information about activities. Since we have two groups involved with the Activity pages. There are multiple ways of displaying the information related to an Activity. 5.1 Common Elements in the Activity Structure| Tab | Title | Content | | 1 | Introduction | Brief description of the activity and its scope. If applicable, a quote from the NPR or STD is used to amplify the description. | | 1.1 | Inputs | List of some of the inputs from other activities that are necessary for the activity to begin. | | 1.2 | Predecessor Activities | List of some of the other activities that must be started (not necessarily completed) so that this activity may begin. | | 1.3 | Outputs | List of some of the outputs or work products of the activity. These are typically used as inputs by the downstream activity. In some cases there is a supporting SWE associated with the work product. | | 1.4 | Successor Activities | Links to Activities which might be started or supported by this activity. | | 1.5 | Activity Repetition | Describe what conditions determine if the activity needs to be repeated, such as re-planning after a change in requirements or schedule constraints. - How much of the activity needs to be repeated
| | 1.6 | Center Resources from SPAN | Add links to SPAN activity pages that are appropriate for this activity. Use links from the Activity section of the SPAN front page. SPAN. This further differentiates SWEHB from SPAN in the sense that PATs are templates derived from SWEHB guidance, SPAN assets and templates are Center defined and developed resources. | | 2 | Defining the Activity | This tab contains the links to pages in the SWEHB that are at the heart of the activity. | | 2.1 | SWEs | This section contains the links to SWE pages that form the heart of the activity. | | 2.2 | Topics and other Supporting Materials | This section is for SWEHB pages, other than SWEs, that directly support the activity. This section contains Topics, document content pages, PATs, and other pages. | | 2.3 | Other Associated SWEs, Topics, etc. | Includes other SWEHB pages that are indirectly associated with the activity. May include SWEs, Topics, document definition pages, PATs, etc. They may have been mentioned in the guidance of another page. |
5.1 Combined FormatIn the combined format, Activities that are closely related such as Planning may have a combined format. Tab 2 information is associated with both Software Engineering and Software Assurance content. An additional tab is provided to include SA tasks (from the included SWEs) that apply to the activity. A risk associated with this way of displaying Activity information is that it may be difficult to easily pick out the SA pieces from the Engineering pieces of an activity. It will be critical to specify who is involved in each element of the activity. An example of this can be found in Planning where the Engineering and Assurance elements of the activity run in parallel and have considerable overlap. Engineering will plan certain processes and then Assurance will plan the auditing of those processes. 
5.2 Separate Formats In separate formats, there is only one template. The indication of who is performing the activity is indicated in the title of the Activity. In this example, SA activities include the SA Task lists from the associated SWEs. Software Engineering Activities would not have SA Tasks displayed in section 2.1.
|
|