UNDER CONSTRUCTION
Notes in this template provide guidance to authors on how the section if to be completed. Once the section is populated, the Note may be deleted. Notes are not intended to be left in the completed page.
View this section on the website
See edit history of this section
Post feedback on this section
1. Introduction
Typically starts with a definition of the activity. Additional descriptive material is meant to help define the activity but not be so detailed that it pulls in all of the guidance from the SWEs in the activity.
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.
Activity graphical representation of Inputs, Outputs, Predecessor and Successor Activities as appropriate. Not meant to be exhaustive, but representative of a typical project.
1.1 Inputs
List of some of the inputs from other activities that are necessary for the activity to begin.
Examples:
- Planning - Peer Reviews are planned activities. They appear in the plans and schedules for the project
- Requirements - These are the things that are Peer Reviewed
- Test Plans and Procedures - These are the things that are Peer Reviewed
1.2 Predecessor Activities
List of some of the other activities that must be started (not necessarily completed) so that this activity may begin.
Examples:
Predecessor Activities are performed before Peer Reviews. These activities produce the work products that will be reviewed.
- Life Cycle Planning - plans, schedules, estimates, etc.
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.
Examples:
The activities that initiated the Peer Review, receive the findings from Peer Reviews, Those activities then use those findings to to fix defects and implement improvements uncovered in the reviews.
| Output Work Product | Used by Downstream Activity |
|---|---|
|
|
1.4 Successor Activities
Links to Activities which might be started or supported by this activity.
- SA Auditing
- SA SW Requirements Analysis
- SA SW Source Code Analysis
- SA SW Testing Analysis
- SA Reporting
- SA Design Analysis
- SA Safety and Hazard Anaysis
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
- Frequency of repetition
This activity is done in the early stages of a Software Project. Other work may be started before the planning is actually completed.
During the life of the project there may be multiple times when significant changes to things like requirements, budget, schedule, technology, which make re-planning necessary. Re-planning is covers the same areas of the original planning to make sure that all changes are accounted for in the new plans. Re-planning is done as often as necessary to keep the project under control.
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 front page. SPAN
Several Centers Process Asset Libraries have materials related to this activity. Related Processes, templates, and other resources may be found in the following Activities in SPAN (available to NASA only).
2. Defining the Activity
This tab contains the links to pages in the SWEHB or excerpts from the NASA-STD-8739.8B 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. In the case of Software Assurance, copy in the task table from each of the tab 7.1 from appropriate SWEs.
Link to the SWE goes here
- Excerpt include for the SWE goes here (Remove Surrounding Panel)
| SWE | Requirement | SA Tasks |
|---|---|---|
3.1.2 The project manager shall assess options for software acquisition versus development. | 1. Confirm that the options for software acquisition versus development have been evaluated. 2. Confirm the flow down of applicable software engineering, software assurance, and software safety requirements on all acquisition activities. (NPR 7150.2 and NASA-STD-8739.8). 3. Assess any risks with acquisition versus development decision(s). | |
| SWE-013 - Software Plans | 3.1.3 The project manager shall develop, maintain, and execute software plans, including security plans, that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring. | 1. Confirm that all plans, including security plans, are in place and have expected content for the life cycle events, with proper tailoring for the classification of the software. 2. Develop and maintain a Software Assurance Plan following the content defined in NASA-HDBK-2203 for a software assurance plan, including software safety. |
3.1.4 The project manager shall track the actual results and performance of software activities against the software plans.
| 1. Assess plans for compliance with NPR 7150.2 requirements, NASA-STD-8739.8, including changes to commitments. 2. Confirm that closure of corrective actions associated with the performance of software activities against the software plans, including closure rationale. 3. Confirm changes to commitments are recorded and managed. | |
3.1.5 The project manager shall define and document the acceptance criteria for the software. | 1. Confirm software acceptance criteria are defined and assess the criteria based on guidance in the NASA Software Engineering Handbook, NASA-HDBK-2203. | |
3.1.6 The project manager shall establish and maintain the software processes, software documentation plans, list of developed electronic products, deliverables, and list of tasks for the software development that are required for the project’s software developers, as well as the action required (e.g., approval, review) of the Government upon receipt of each of the deliverables. | 1. Confirm the following are approved, implemented, and updated per requirements: a. Software processes, including software assurance, software safety, and IV&V processes, b. Software documentation plans, c. List of developed electronic products, deliverables, and d. List of tasks required or needed for the project’s software development. 2. Confirm that any required government actions are established and performed upon receipt of deliverables (e.g., approvals, reviews). | |
3.1.7 The project manager shall define and document the milestones at which the software developer(s) progress will be reviewed and audited. | 1. Confirm that milestones for reviewing and auditing software developer progress are defined and documented. 2. Participate in project milestones reviews. | |
3.1.8 The project manager shall require the software developer(s) to periodically report status and provide insight into software development and test activities; at a minimum, the software developer(s) will be required to allow the project manager and software assurance personnel to:
| 1. Confirm that software developer(s) periodically report status and provide insight to the project manager. 2. Monitor product integration. 3. Analyze the verification activities to ensure adequacy. 4. Assess trade studies, source data, software reviews, and technical interchange meetings. 5. Perform audits on software development processes and practices at least once every two years. 6. Develop and provide status reports. 7. Develop and maintain a list of all software assurance review discrepancies, risks, issues, findings, and concerns. 8. Confirm that the project manager provides responses to software assurance and software safety submitted issues, findings, and risks and that the project manager tracks software assurance and software safety issues, findings, and risks to closure. | |
3.1.9 The project manager shall require the software developer(s) to provide NASA with software products, traceability, software change tracking information, and non-conformances in electronic format, including software development and management metrics. | 1. Confirm that software artifacts are available in electronic format to NASA. | |
3.1.10 The project manager shall require the software developer(s) to provide NASA with electronic access to the source code developed for the project in a modifiable format. | 1. Confirm that software developers provide NASA with electronic access to the source code generated for the project in a modifiable form. | |
3.1.11 The project manager shall comply with the requirements in this NPR that are marked with an “X” in Appendix C consistent with their software classification. | 1. Assess that the project's software requirements, products, procedures, and processes are compliant with the NPR 7150.2 requirements per the software classification and safety criticality for software. | |
3.1.12 Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and deployment of the affected software. | 1. Confirm that any requirement tailoring in the Requirements Mapping Matrix has the required approvals. 2. Develop a tailoring matrix of software assurance and software safety requirements. | |
3.1.13 Each project manager with software components shall maintain a requirements mapping matrix or multiple requirements mapping matrices against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements. | 1. Confirm that the project maintains a requirements mapping matrix (matrices) for all requirements in NPR 7150.2. 2. Maintain the requirements mapping matrix (matrices) for requirements in NASA-STD-8739.8. | |
3.1.14 The project manager shall satisfy the following conditions when a COTS, GOTS, MOTS, OSS, or reused software component is acquired or used: a. The requirements to be met by the software component are identified. b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions). c. Proprietary rights, usage rights, ownership, warranty, licensing rights, transfer rights, and conditions of use (e.g., required copyright, author, and applicable license notices within the software code, or a requirement to redistribute the licensed software only under the same license (e.g., GNU GPL, ver. 3, license)) have been addressed and coordinated with Center Intellectual Property Counsel. d. Future support for the software product is planned and adequate for project needs. e. The software component is verified and validated to the same level required to accept a similar developed software component for its intended use. f. The project has a plan to perform periodic assessments of vendor reported defects to ensure the defects do not impact the selected software components. | 1. Confirm that the conditions listed in "a" through "f" are complete for any COTS, GOTS, MOTS, OSS, or reused software that is acquired or used. | |
| SWE-151 - Cost Estimate Conditions | 3.2.2 The project manager’s software cost estimate(s) shall satisfy the following conditions: a. Covers the entire software life cycle. | 1. Assess the project's software cost estimate(s) to determine if the stated criteria listed in "a" through "f" are satisfied. |
| SWE-016 - Software Schedule | 3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:
| 2. Develop a software assurance schedule, including software assurance products, audits, reporting, and reviews. |
| SWE-046 - Supplier Software Schedule | 3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested. | 1. Confirm the project's schedules, including the software assurance’s/software safety’s schedules, are updated. |
| SWE-020 - Software Classification | 3.5.1 The project manager shall classify each system and subsystem containing software in accordance with the highest applicable software classification definitions for Classes A, B, C, D, E, and F software in Appendix D. | 1. Perform a software classification or concur with the engineering software classification of software per the descriptions in NPR 7150.2. |
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.
- Include page for the PAT page goes here
0 Comments