bannerd

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

6.2 Existing Structure in SWEs with Tab 7 Software Assurance

The tab 7 information defines a structure for providing guidance on satisfying a SWE for a the Software Assurance team members on the development project. SWEs that are from Chapters 3 - through 5 of NPR 7150.2 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 set of requirements requirement in NPR 7150.2 for Software Development, there are some tasks for Software Assurance to accomplish. The format organization of tab 7 is: 

  1. Tasking for Software Assurance - one or more tasks derived from the NPR 7150.2 Requirement and specifically included in NASA-STD-8739.8. 
  2. Software Assurance Products - one or more work products created as a result of accomplishing the tasking. 
  3. Metrics - example metrics that could be collected (including some that must be collected) as a result of accomplishing the tasking. 
  4. Guidance - Additional information regarding how the tasks could be accomplished. In some cases, the guidance includes step by step instructions on accomplishing the tasks. 

Looking at  as Using SWE-058 as an example. We , we see 5 tasks assigned to SA for this SWE.

Panel
borderColorblue
titleFrom NASA-STD-8739.8B

Include Page
SWE-058 - SA Task1
SWE-058 - SA Task1

Include Page
SWE-058 - SA Task2
SWE-058 - SA Task2

Include Page
SWE-058 - SA Task3
SWE-058 - SA Task3

Include Page
SWE-058 - SA Task4
SWE-058 - SA Task4

Include Page
SWE-058 - SA Task5
SWE-058 - SA Task5

6.3 Expanding the Notion of Tasking into the SWE Structure

In For this section example, we will work with the page: Copy of SWE-058 - Detailed Design with new tab 4 . This page has the elements discussed below

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:

...

  • 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 Work ProductsAssurance Work Products
  1. Software Development Process - which includes details on the Design Process to be followed. 
  2. List of design components including when they are expected to be available - as input to Development Schedule
  3. List of methods, tools, standards, and guidelines for your project. 
  4. List of training and experience required by team members to perform the design and development work. 
  1. Software Design Analysis
  2. Results of software assurance design analysis, including assessments in Tasks 1, 2, and 3. 
  3. List of any identified design risks and issues.


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 . An attempt is made here to 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)