Page History

...

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, chapters 3 through 5, for Software Development, there are some tasks for Software Assurance to accomplish. The organization of tab 7 is: 

...

The Guidance for SWE-058 contains information which could be interpreted as tasks for Software Development team members.  After putting appropriate subheadings into tab 3, we have the following collection:  

• 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 

...

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: 

...

 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

...

A similar disparity can be seen with the Work products for the two areas: 

...

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. 

This tasking was derived using

• The headings from the guidance in tab 3 for the tasks
• Three of the work products are mentions specifically and have minimum document structure topics to work from. These documents also have specific points in the life cycle where they are needed for reviews. All of that detail is delineated here. 
• Some of the other 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: 

A similar disparity can be seen with the Work products for the two areas: 

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 activity "Software Design" was selected because it has only one SWE associated with it. Only one SWE is needed to show how it develops in the sections of the activity. It is more straight forward that trying to develop an activity like "Life Cycle  Planning" which has many SWEs. 

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)
  • Below the SWE title is a list of the tasks. Tasks are derived from the guidance on the SWE page. In some cases, this is simple because the tasks come from the subheadings in the guidance. In other cases, they may need to be derived from a review of the guidance text. 
•  2.2 Topics and Other Supporting Materials - this section contains links to other pages in the SWEHB that contain material relevant to the activity.
  • In both the Topics and Supporting Materials sub-sections, the title is presented as a link to the page. 
    • Some are obvious by their titles, like, 7.7 - Software Architecture Description.  Others are less obvious.
    • Some may even apply to multiple activities. For example, a checklist for building a work product for an activity may also be used in performing a peer review of that work product. 
    • Some are links to document structures (most of these are collected under in topic 7.18)
    • Some are Process Asset Templates (PATs) - these are prototype assets built from the SWE guidance and intended to serve as a starting point for projects to use. Projects are encouraged to improve upon the content of the template to help their project. 
  • Below the title link is the page excerpt. Most pages have an excerpt which describes in a sentence or two what the page is all about. 
•  2.3 Other Associated SWEs, Topics, etc. - this is a catchall for other pages which are indirectly associated with the activity. In some SWEHB pages other SWEs are referenced and may be helpful to be included here. 

6.5.3 Tab 3 Software Assurance Activity

This tab brings out the relationship between Software Development and Software Assurance for the activity. Where tab 3 in the SWE provides guidance for Software Developers on how to satisfy the requirement, tab 7 provides guidance for Software Assurance on how to satisfy the requirement.

•  3.1 Software Assurance Tasks from SWEs - Tasking in tab 7 of the SWEs comes directly from NASA-STD-8739.8B. It is reproduced in this section of the tab for each SWE. 
  • The title of the SWE is listed as a link to the page. 
    • Tasking from tab 7 (NASA-STD-8739.8B) is listed. 
    • Software Assurance Products are listed
    • Metrics are listed
•  3.2 Topics and Other Supporting Materials - other SWEHB pages that describe Software Assurance activities. 
  • The title of the topic page is given as a link
    • The excerpt from the topic page is displayed
  • For PATs, the title of the PAT is given as a link to the page
    • The excerpt from the page is displayed. For a PAT, this is n image of the first page of the PAT. The image is linked to the PAT template document. 
  • There are some applicable topic pages that differ in their content. These are associated with topic 8.16. They contain content very similar to an activity in that it brings together tasks from multiple SWEs.
    • The title of the page is given as a link
      • The excerpt from the page is displayed
      • Related SWEs are listed along with tasking

•  3.3 Other Associated SWEs, Topics, etc. - this is a catchall for other pages which are indirectly associated with the activity. In some SWEHB pages other SWEs are referenced and may be helpful to be included here. It may be added if needed. 

6.6 Special Topics Pages That Seem To Mimic Activities

In building the third Activity example, Activity - Software Design, It became apparent that there are some new pages in the SWEHB tat are different from the typical SWE or Topic. In the latter days of SWEHBVC some work was done on a small number of pages in the 7.18 - Documentation Guidance. They were moved into Topic 8.16 - SA Products. As these pages developed further, they became more than just a "minimum content" description. They blossomed into very detailed guidance pages, looking somewhat like activity descriptions. 

These pages have sections for: 

• Listings of SA tasking from multiple SWEs
• Guidance for performing the tasks. Including:
  • checklists and PATs for the tasks
  • descriptions of interfaces with other entities such as SARB
  • descriptions of various reviews 
  • techniques
  • recommended content for various types of reports 
• Guidance for performing Safety Analysis, Hazard Analysis, etc.
• Analysis Reporting Content
• Safety related content
• Tasks needing Objective Evidence

Certainly, all of these pages and content are valuable as topics for providing guidance on performing all types of work related activities. It may be somewhat of a challenge to accurately represent all of this content in the Activity format. Part of the concern is that it is currently under development and changes to the content will require that the Activities which point to them will need maintenance to keep up with the development in these areas. We will have to look carefully at these topics and come up with a way to include their content in Activities without getting too exhaustive in the Activity. Case in point,

• In my attempt to be inclusive in my Activity - Software Design page, I may have too much detail in section 3.2 where I go down to the task level on the Software Design Analysis page. 
• Conversely, there may not be enough detail in the activity to cover other tabs in the Software Design Analysis page such as:
  •  Safety Analysis During Design 
  • Analysis Reporting Content 

6.7 Reworking Peer Reviews into the Combined Activity Format

The combined format and the reworking of tab 4 in SWEs (to bring out Software Development tasks, work products and metrics) dramatically increased the content in the Design activity. Doing the same thing for Peer Review shows some additional interesting things. 

Copies of the three SWES in the Peer Review Activity were made and the tab 4 in each was expanded after the tab 3 was reworked with sub-headings. Then the combined activity for Peer Review was built. 

• Copy of SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures
• Copy of SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking
• Copy of SWE-089 - Software Peer Reviews and Inspections - Basic Measurements
• Copy of Activity Software Peer Reviews and Inspections - Combined

Tab 1 of the activity did not change much from the previous examples of this activity. Significant changes needed to be made in tabs 2 and 3. 

• Tab 2.1 now has 3 SWEs in it. Each SWE shows 
  • Title as a link
  • Excerpt (the requirement)
  • Another clarifying statement to further describe the SWE
  • Tasks list
  • Work Products list
• Tab 2.2 

...

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 activity "Software Design" was selected because it has only one SWE associated with it. Only one SWE is needed to show how it develops in the sections of the activity. It is more straight forward that trying to develop an activity like "Life Cycle  Planning" which has many SWEs. 

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)
  • Below the SWE title is a list of the tasks. Tasks are derived from the guidance on the SWE page. In some cases, this is simple because the tasks come from the subheadings in the guidance. In other cases, they may need to be derived from a review of the guidance text. 
•  2.2 Topics and Other Supporting Materials - these are other pages in the SWEHB that contain material relevant to the activity.
  • The title of the page is presented as a link to the page
    • Some are obvious by their titles, like, 7.7 - Software Architecture Description.  Others are less obvious.
    • Some may even apply to multiple activities. For example, a checklist for building a work product for an activity may also be used in performing a peer review of that work product. 
    • Some are links to document structures (most of these are collected under in topic 7.18)
    • Some are Process Asset Templates (PATs) - these are prototype assets built from the SWE guidance and intended to serve as a starting point for projects to use. Projects are encouraged to improve upon the content of the template to help their project. 
  • Below the title link is the page excerpt. Most pages have an excerpt which describes in a sentence or two what the page is all about. 
•  2.3 Other Associated SWEs, Topics, etc. - this is a catchall for other pages which are indirectly associated with the activity. In some SWEHB pages other SWEs are referenced and may be helpful to be included here. 

6.5.3 Tab 3 Software Assurance Activity

This tab brings out the relationship between Software Development and Software Assurance for the activity. Where tab 3 in the SWE provides guidance for Software Developers on how to satisfy the requirement, tab 7 provides guidance for Software Assurance on how to satisfy the requirement.

•  3.1 Software Assurance Tasks from SWEs - Tasking in tab 7 of the SWEs comes directly from NASA-STD-8739.8B. It is reproduced in this section of the tab for each SWE. 
  • The title of the SWE is listed as a link to the page. 
    • Tasking from tab 7 (NASA-STD-8739.8B) is listed. 
    • Software Assurance Products are listed
    • Metrics are listed
•  3.2 Topics and Other Supporting Materials - other SWEHB pages that describe Software Assurance activities. 
  • The title of the topic page is given as a link
    • The excerpt from the topic page is displayed
  • For PATs, the title of the PAT is given as a link to the page
    • The excerpt from the page is displayed. For a PAT, this is n image of the first page of the PAT. The image is linked to the PAT template document. 
  • There are some applicable topic pages that differ in their content. These are associated with topic 8.16. They contain content very similar to an activity in that it brings together tasks from multiple SWEs.
    • The title of the page is given as a link
      • The excerpt from the page is displayed
      • Related SWEs are listed along with tasking

•  3.3 Other Associated SWEs, Topics, etc. - this is a catchall for other pages which are indirectly associated with the activity. In some SWEHB pages other SWEs are referenced and may be helpful to be included here. It may be added if needed. 

6.6 Special Topics Pages That Seem To Mimic Activities

In building the third Activity example, Activity - Software Design, It became apparent that there are some new pages in the SWEHB tat are different from the typical SWE or Topic. In the latter days of SWEHBVC some work was done on a small number of pages in the 7.18 - Documentation Guidance. They were moved into Topic 8.16 - SA Products. As these pages developed further, they became more than just a "minimum content" description. They blossomed into very detailed guidance pages, looking somewhat like activity descriptions. 

These pages have sections for: 

• Listings of SA tasking from multiple SWEs
• Guidance for performing the tasks. Including:
  • checklists and PATs for the tasks
  • descriptions of interfaces with other entities such as SARB
  • descriptions of various reviews 
  • techniques
  • recommended content for various types of reports 
• Guidance for performing Safety Analysis, Hazard Analysis, etc.
• Analysis Reporting Content
• Safety related content
• Tasks needing Objective Evidence

Certainly, all of these pages and content are valuable as topics for providing guidance on performing all types of work related activities. It may be somewhat of a challenge to accurately represent all of this content in the Activity format. Part of the concern is that it is currently under development and changes to the content will require that the Activities which point to them will need maintenance to keep up with the development in these areas. We will have to look carefully at these topics and come up with a way to include their content in Activities without getting too exhaustive in the Activity. Case in point,

• In my attempt to be inclusive in my Activity - Software Design page, I may have too much detail in section 3.2 where I go down to the task level on the Software Design Analysis page. 
• Conversely, there may not be enough detail in the activity to cover other tabs in the Software Design Analysis page such as:
•  Safety Analysis During Design 
Analysis Reporting Content