Page History
...
| id | tabs-1 |
|---|
1.Requirement
5.1.5.1 The Software Assurance Plan(s) shall be developed and documented per NASA-STD-8739.8, Software Assurance Standard. [SWE-106]
1.2 Notes
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.3 Applicability Across Classes
...
| f | 1 |
|---|---|
| g | 1 |
| h | 0 |
| ansc | 1 |
| asc | 1 |
| bnsc | 1 |
| csc | 1 |
| bsc | 1 |
| esc | 1 |
| cnsc | 1 |
| dnsc | 0 |
| dsc | 1 |
| ensc | 0 |
...
| id | tabs-2 |
|---|
2. Rationale
...
The Software Assurance Plan (SAP) represents an agreement between the project, the software developers, and the software assurance personnel. It describes the activities, roles, and responsibilities of software assurance on the project. As with any task, a plan helps ensure that the team performs all necessary and required tasks. Development of the plan provides the opportunity for stakeholders to give input and assist with the documentation and tailoring of the planned activities for the project.
...
| id | tabs-3 |
|---|
3. Guidance
| Floatbox | ||
|---|---|---|
| ||
NPR 7150.2, section 5.1.5, states that: "The Software Assurance Plan details the procedures, reviews, and audits required to accomplish software assurance. The project office should coordinate with the Office of Safety and Mission Assurance for help in scoping and adapting the effort appropriately, and to designate the individual responsible for software assurance on the project." |
For projects that involve contracted work, both the acquirer and the provider (subcontractor) need SAPs, and those plans must work together to accomplish the required level of software assurance. The preliminary acquirer plan is developed at the same time that the Request for Proposal (RFP) or Memorandum of Agreement/Memorandum of Understanding (MOA/MOU) is created. Both acquirer and provider plans are to be completed by the time the contract is awarded, though an update of the provider plan is expected at the Software Requirements Review (SwRR).
As with many project plans, the SAP may be a separate document or may be combined with another project plan such as the Software Development Plan (SDP). However, the independent software assurance organization of the acquirer Safety and Mission Assurance (SMA) Office needs to have sign-off authority on the content no matter into what document the SAP contents may be incorporated. The SAP is a joint agreement between acquirer SMA and the project/facility for software assurance activities.
...
Acquirer SAP:
...
Provider SAP:
...
- 6.2.2.1 - The [safety] analysis methodology [for software design] shall be recorded in an appropriate document (e.g., software safety plan or software assurance plan).
- 6.3.2.1 - The [safety] analysis methodology [for software implementation, e.g., code] shall be recorded in an appropriate document (e.g., software safety plan or software assurance plan).
Before writing a SAP, it is recommended that the team review the following material as preparation:
- Software assurance lessons learned from similar projects.
- Existing software assurance processes, standards, procedures, etc.
- Software assurance deliverables (records, reports, etc.) for similar projects.
...
Other content elements to consider include:
- Software assurance organization and management structure and responsibilities.
- Software assurance planning activities.
- Software classification and safety criticality.
- Software assurance implementation activities covering all five assurance disciplines:
- Software Quality (includes software quality assurance, software quality engineering, and software quality control).
- Software Safety.
- Software Reliability.
- Software Verification and Validation.
- Independent Verification and Validation.
- Standards and processes to be used, including those used for:
- Software assurance implementation activities, such as reviews, audits, etc.
- Problem reporting and tracking.
- Risk management.
- Software assurance metrics, e.g., planned versus actual reviews, audits, assessments; open versus closed issues; number of identified risks.
- Record creation, review, and maintenance.
- Training for software assurance personnel.
- Resources, including tools, personnel, and facilities.
- Identification of products and processes to be reviewed or audited.
- Identification of deliverables (records) to be created and maintained.
- Schedule.
Ensure that the SAP is reviewed prior to implementation and at appropriate life cycle reviews by personnel with sufficient software assurance knowledge to identify omissions, inadequacies, and other issues. Include stakeholders affected by the plan in the reviews for awareness of planned activities and so that their suggestions can be addressed within the bounds of the project's required level of software assurance. Any identified issues need to be corrected before plan implementation or before carrying out affected software assurance activities in the next life-cycle phase.
...
Any changes to the baselined SAP (typically baselined at PDR (Preliminary Design Review)) need to be made via the appropriate formal change request process (internal to the project for the acquirer SAP or via NASA's formal change request process for the provider SAP) and be accompanied by a risk analysis to ensure the project's level of software assurance is not compromised.
The acquirer software assurance personnel are responsible for ensuring the provider software assurance personnel are meeting the contents of the provider SAP. The acquirer SAP describes how this will be done (based on software size, software class, safety criticality, and other factors that may be specific to a project).
Guidance related to software assurance and to be considered for inclusion in the SAP may be found in the following related requirements in this Handbook:
...
...
Software Plans
...
...
Software Classification
...
...
Software Assurance
...
...
Independent Software Classification Assessment
...
...
Software Safety Determination
...
| id | tabs-4 |
|---|
4. Small Projects
...
| id | tabs-5 |
|---|
5. Resources
...
| toolstable |
|---|
...
| id | tabs-6 |
|---|
6. Lessons Learned
...
The NASA Lesson Learned database contains the following lessons learned related to software assurance planning:
...
