6.2 Existing Structure in SWEs with Tab 7 Software Assurance
SWEs that are from Chapters 3 through 5 of NPR 7150.2D have a Tab 7 for Software Assurance content. The tab 7 information defines a structure for providing guidance to Software Assurance team members for satisfying a SWE. This tab brings into focus the parallel nature of Software Assurance and Software Development work. For every requirement in NPR 7150.2 for Software Development, there are some tasks for Software Assurance to accomplish. The organization of tab 7 is:
- Tasking for Software Assurance - one or more tasks derived from the NPR 7150.2 Requirement and specifically included in NASA-STD-8739.8.
- Software Assurance Products - one or more work products created as a result of accomplishing the tasking.
- Metrics - example metrics that could be collected (including some that must be collected) as a result of accomplishing the tasking.
- Guidance - Additional information regarding how the tasks could be accomplished. In some cases, the guidance includes step by step instructions on accomplishing the tasks.
Using SWE-058 as an example, we see 5 tasks assigned to SA:
1. Assess the software design against the hardware and software requirements and identify any gaps.
2. Assess the software design to verify that the design is consistent with the software architectural design concepts and that the software design describes the lower-level units to be coded, compiled, and tested.
3. Assess that the design does not introduce undesirable behaviors or unnecessary capabilities.
4. Confirm that the software design implements all of the required safety-critical functions and requirements.
5. Perform a software assurance design analysis.
6.3 Expanding the Notion of Tasking into the SWE Structure
For this example, we will work with the page: Copy of SWE-058 - Detailed Design with new tab 4 .
If we consider expanding the notion of Tasks into the current SWEs, we would have to look for a place to put them. Without a major restructuring of the tabs, we could consider putting them into tab 4. This would require renaming this tab from "Small Projects" to something like "Project Tasks". Initially, we may leave the existing text in tab 4 and just add to it. The preamble for this tab might be:
"Project Tasks are recommended for projects where this SWE is applicable. They are derived from the requirement. Suggestions for completing the tasks and producing the recommended work products are based on the guidance in tab 3."
The Guidance for SWE-058 contains information which could be interpreted as tasks for Software Development team members.
- 3.1 Design Readiness - including suggested checklist items for preparing for a Preliminary Design Review (PDR)
- 3.2 Coding Standards and Processes
- 3.3 Design Considerations
- 3.4 Detailed Design Documentation and Progress Reviews
- 3.5 Design Maintenance
For the new tab 4 content we might consider the following:
4.1 Tasking for Software Development
Guidance for each task is available in tab 3.
- Assess Design Readiness
- Establish Coding Standards and Processes
- Establish Project Specific Design Considerations
- Establish Detailed Design Documentation and Progress Reviews
- Establish Design Maintenance Processes and Mechanisms
4.2 Software Development Work Products
- Software Development Process - which includes details on the Design Process to be followed.
- List of design components including when they are expected to be available - as input to Development Schedule
- List of methods, tools, standards, and guidelines for your project.
- List of training and experience required by team members to perform the design and development work.
4.3 Metrics
Suggested metrics are listed below. Items in bold are strongly recommended for implementation in order to provide benefit for tracking and assessing completion of the work.
- # of architectural issues identified vs. number closed.
- # of design issues found versus the number of design issues resolved.
- # of requirement issues (Open, Closed) over time.
- # of non-conformances identified by life cycle phase over time.
- # of software work product Non-Conformances identified by life cycle phase over time
This tasking was derived using
- The headings from the guidance in tab 3 for the tasks
- Some of the work products found in tab 3 (not an exhaustive list here, just enough to represent the concept)
- Metrics are taken from 7.3 (SA Metrics) and reworded slightly (again, not an exhaustive list here, just enough to represent the concept)
6.4 Comparing Tasks
Looking at the Development Tasks above, it is clear that there is not a one to one correspondence between Development Tasks and Assurance Tasks. The table below demonstrates this:
| Development Task | Assurance Task |
|---|---|
1. Assess Design Readiness 2. Establish Coding Standards and Processes 3. Establish Project Specific Design Considerations 4. Establish Detailed Design Documentation and Progress Reviews 5. Establish Design Maintenance Processes and Mechanisms | 1. Assess the software design against the hardware and software requirements and identify any gaps. 2. Assess the software design to verify that the design is consistent with the software architectural design concepts and that the software design describes the lower-level units to be coded, compiled, and tested. 3. Assess that the design does not introduce undesirable behaviors or unnecessary capabilities. 4. Confirm that the software design implements all of the required safety-critical functions and requirements. 5. Perform a software assurance design analysis. |
A similar disparity can be seen with the Work products for the two areas:
| Development Work Products | Assurance Work Products |
|---|---|
|
|
When building the Combined activity it will be necessary to have tabs for both Development and Assurance.
6.5 Activity View of Software Design Activity
One approach to this might be to combine the Development and Assurance elements into a single activity to reinforce the notion that the two groups are expected to work in a coordinated way even though not in a closely coupled way. To show this, look at the Activity - Software Design page. This page shows the combination of Development Tasks and Assurance Tasks in a single activity.
The content for each tab is listed here. in order to avoid duplicating a lot of text, the existing SWEs and Topics are referenced and linked as much as possible. A minimal amount of text is copied into the Activity page. In many cases, excerpts are used to bring text in. This will minimize the original authoring of a lot of text.
6.5.1 Tab 1 Introduction
This section contains a quote from NPR 7150.2D to describe what the activity is all about. If a quote is not available (it was not defined in the NPR) then new text must be provided to describe the activity.
- Inputs, Outputs and Predecessor Activities - this introduces the flow chart for the activity. The flow chart is notional and not intended to be exhaustive in describing ALL of the possible inputs, outputs, and Predecessors. Currently the charts are derived from the master chart showing the overall flow of a Software Development project. It is contained in a PowerPoint presentation and images are saved as .PNG files. These files are then attached to the activity so that they may be displayed on the activity page.
- 1.1 Inputs - provides a section for listing the major inputs to the activity. They represent documents, plans, etc. that are used in the activity. They may not need to be completed inputs but need to be complete enough so that meaningful progress on the activity can take place.
- 1.2 Predecessor Activities - These are other major activities that must have at least started before the activity can be started.
- 1.3 Outputs - These are some of the major work products that will come out of the activity. Many of these work products will go through peer review cycles prior to use in subsequent activities.
- 1.4 Successor Activities - These are some of the activities that will be started after the activity is at least started. Some of these activities depend on one or more of the work products listed in the Outputs.
- 1.5 Activity Repetition - This section describes how often the activity is performed. All activities are performed once. Many are performed additional times depending on certain triggers such as requirements changes, budget changes, technology changes, etc.
- 1.6 Center Resources from SPAN - This section acknowledges the role of the Centers in providing libraries of process assets aimed at facilitating the performance of these activities. SWEHB builds asset prototypes from guidance on satisfying requirements, The Center assets are built on experience in satisfying the requirements on actual projects. Links to the appropriate asset pages in SPAN are provided.
6.5.2 Tab 2 Software Development Activity
This section focuses on SWEHB components aimed as supporting the Software Development Community. It organizes components into groups of page types.
- 2.1 SWEs - in NPR 7150.2D many of the SWEs are grouped together in activities. These groupings are preserved here and in some cases expanded upon. Planning, Peer Reviews, and Software Design are some examples of activities right from the NPR. In this section, each SWE is listed including:
- The title of the SWE (as a link to the SWE page)
