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

Using SWE-058 as an example, we see 5 tasks assigned to SA: 

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. 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 

For the new tab 4 content we might consider the following: 

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 - Combined 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 - Combined, 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 - Combined page, I may have too much detail in section 3.2 where I go down to the task level on the 8.55 - Software Design Analysis page. 
• Conversely, there may not be enough detail in the activity to cover other tabs in the 8.55 - 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
• Activity - Software Peer Reviews and Inspections - Combined

6.7.1 Removing Metrics From The Template

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. In both tabs 2 and 3 the metrics detail is gone. It  was deleted because there was too much detail and it made the presentation of the activity too confusing. 

6.7.2 Addition of "Clarifying Statement" 

Note the addition of "Another clarifying statement to further describe the SWE" in tab 1. This was added because the excerpt for a SWE page is the requirement. It does not contain any "reusable text" describing the purpose of the page. In the case of the Peer Review SWEs, reworking the guidance tabs made it clear why the three SWEs were needed: 

• SWE-087 - Establishes the Peer Review Process to be used in the project
• SWE-088 - Establishes individual Peer Review content for each of the documents to be reviewed
• SWE-089 - Establishes Metrics for the Process as well as the individual reviews

This distinction between the SWEs was not brought out in the Rationale statements. Expressing them in the activity add some clarity for the user. 

6.7.3 Summarizing the Combined Activity Structure

There are several features of the combined structure. whether they are net positives or net negatives will be for us to debate. We need to consider several questions for each. Some of these items imply a significant amount of work to get the SWEs and Topics ready for the reorganization. There is a lot of work remaining to get the PATs configured and made available.  

1. Combining the Development and Assurance activities 
   1. Does it reinforce the concept of "working together" 
   2. Are the tasks for Development and Assurance so different that they lead to confusion or do they serve to bring the work to a logical conclusion?
2. Omitting Metrics from the Combined Activity page
   1. Since Metrics are in the SWE page, tab 4 and 7, they are unnecessary clutter in the Activity page?
   2. Are a few of the key metrics desirable to have in the Activity to ensure that the whole reason for having Metrics is not lost?
3. Clarifying statements and Tab 2 in the SWEs
   1. Should the clarifying statements be consolidated in the Tab 1 to explain why there are so many SWEs on this subject?
   2. Should the rationale statements in the SWEs be updated to explain how the collection of related SWEs work together? 
4. Updating in Tab 3 - adding subheadings to clarify tasks. Much of the content is well organized, this is just adding subheadings that make the tasking more obvious
   1. Is it appropriate to say that Development teams have "tasking" imposed on them by the NPR? Is that a Center responsibility through their Asset Libraries and SEPG organizations?
5. Updating in Tab 4 - Adding Tasking, Work Products, and Metrics
   1. Is it okay to leave the Small Projects content in at the top of the page? 
   2. Should Small Projects be move elsewhere? Does it need it's own sub-heading
6. Divergence through content coming out of 8.16 topics 
   1.  Is there a close alignment of all the 8.16 topics with the development requirements of the SWEs.
   2. Some of the 8.16 topics span a wide range of SWEs as in "Topic 8.16 - Software Design Analysis", tasks reach out beyond Design. 
7. Completing the creation of PATs - there are just over 30 now, There are probably as many as a hundred total depending on how we want to break out some of the SWE content that is currently in bulleted lists in tabs. 
   1. Should we prioritize the creation of PATs over the creation of activities? 
   2. Are the Activities more important than the PATs? 
   3. Are they of equal importance - build PATS as the content in Tab 3s are updated? 
8. Rollout of Activity in the reorganization
   1. Should it be done all at once, individually, or in some sort of logical groupings? 
   2. How should the Activity reorganization be coordinated with other things like Blog postings - Blog postings could be the announcement mechanism for letting the community know about the various updates. 

6.7.4 Key Points for the Presentation at KSC in February

1. What are the key things that we want to keep in the new structure?
2. What are the things that we need to rethink? 
3. How much should we be reveling to the SWWG at the meeting in February?  
4. What things are we needing input on from the SWWG to  influence the changes to the SWEHB? 
5. What items can we say we are rolling out at the meeting? 
   1. Blogs
   2. Reorganization of the Requirements buttons
   3. Creation of the Activity button
   4. Reorganization of Topics - uniform numbering of topics 
   5. Updating Acronyms and Terms in accordance with NPR 7150.2 and NASA-STD-8739.8