1. Activities and Their SWEHB Components

This is a working page to build the list of activities and the SWEs and topics that define them. 

The table below was built from the activity descriptions in NPR 7150.2D chapters 3 thru 5. These are highlighted in yellow. The activity name includes the numbering that came from the NPR. Once we are sure that we know what activities we want to use, we should renumber the activities in a way that seems appropriate. 

Additional activities were derived from chapter 2. These chapter 2 activities were then copied into the activities highlighted in yellow where they seemed most likely to belong. See the subheading "SWEs from Ch 2 - Institutional Requirements". 

Distribution Of SWEs Into Activities

• All SWEs in NPR 7150.2D are represented in an activity in the yellow group. SWEs that come from chapter 2 represent things that are done at the Institutional level to enable projects to perform a SWE at the project level. In a sense, they are enabling SWEs.

Distribution Of Topics And PATs Into Activities

• All topics are represented in at least one activity.
• Some topics are associated with multiple SWEs and may appear in more than one activity. For example, topic 8.5 - SW Failure Modes and Effects Analysis deals with design as well as has safety related considerations as well. It appears in both the 3.7 Safety-Critical Software and 4.3 Software Design activities. 
• All PATs are represented in at least one activity. Some PATs may appear in multiple activities depending on the same criteria as topics.

Topics That Don't Fit Into Activities

• There are a few topics that don't fit into the activity scheme. They are listed in the next to last row in the red highlight. 

Activities That Are Not Represented In This Model

• There are a few topics that are not represented in this activity model. They are listed in the last row in the green highlight. If we want this activity model to match more closely with the way projects do their work, it may be necessary to add these activities into the model and move the appropriate SWEs, Topics, PATs, etc. into them. 

Additional Considerations Moving Forward

• 3.8 Automatic Generation of Software Source Code content might be better to put into the activity 4.3 Software Design or 4.4 Software Implementation
• 3.12 Software Bi-Directional Traceability has only one SWE and no other topics or other materials associated with it. It may be more appropriate to put this SWE under 4.1 Software Requirements
• 4.2 Software Architecture and 4.3 Software Design might be better to consider as a single activity. 

COLUMNS 1 AND 2 BELOW ARE SUPERCEEDED BY TAB 4 - "ACTIVITY GROUPINGS" DEFINITION

2. Definitions

In the context of this view of the SWEHB, some definitions are in order. These are ideas for helping partition the information so it can be organized in a way to make finding things easier. 

2.1 Activity

General name for a set of processes, performed by one or more groups of stakeholders in the development life cycle of a software product. Activity names may align with project phases in some cases depending on the development process or life cycle chosen for the project. Some activities are performed in a sequence. Others may be started and continue while others start up later and run in parallel with other activities. An example of this is coding and testing. These activities may appear to run together while different portions or releases of the code are being developed. 

An activity is composed of:

• SWEs - requirements that are satisfied during the conducting of the activity, and
• Supplementary Materials - Other work described in the other SWEHB components such as Topics, Checklists, PATs, Document Contents, etc. 

2.2 "SWE" Components

Each SWE requirement is composed of one or more objectives that represent an industry best practice that OCE expects projects (on the agency in the case of Institutional Requirements) to perform. How these objectives are achieved is at the discretion of the group satisfying the requirement. Each SWE page lists some tasks that would accomplish the requirement, and guidance on how they might be completed. 

Tasks for the Software Engineering (tab 3? - to be defined) as well as Software Assurance (tab 7) are listed. In cases where additional support or more in depth guidance is available, the reader is referred to a Topic. 

2.3 "Supplementary Materials" Other SWEHB Components

Any page in the SWEHB that contains guidance on performing a process, such as

• creating a document,
• implementing a development tool,
• preparing for or conducting a review, or
• other related topic supporting the work of an activity. 

The SWEHB Topics page could be expanded to organize and present more groupings of topics. Numbering of topics allows existing reference management macros to be used in the Resources tab of the topic. 

2.4 Topics and Topic Numbers

In the first SWEHB (space: 7150) there was only a topic group of 7.xx. The topics were all oriented for Software Engineering. Anything that was not a SWE page was a Topic page and numbered appropriately.

As we built the next version, SWEHBVB, there were still only Software Engineering topics in the 7.xx group. The Topic 7.18 was built to account for a number of SWEs related to minimum document content being retired. While the SWE was retired, the document and its minimum content was retained. All 19 pages now had to be assigned search keys for references and the code for building the reference lists had to be hard coded. 

When SWEHBVC was built, the Topics page was expanded to contain several more groups of topics: 

• 7.xx - Engineering Topics
• 8.xx - Assurance and Safety Topics
• Software Design Principles - brought over from the Goddard list of Golden Principles. The list was never properly numbered and all of the references on all the pages had to be manually hardcoded. 
• 9.xx Programming Checklists

Additionally, topic 8.16 was built. Some of the document contents from 7.18 were migrated over to 8.16. All of these document pages had search keys and hardcoded reference table code. Adding to the complexity of the problem, these pages were expanded to contain more than just the minimum document content. For example: 

• Software Assurance Plan page contained minimum content for the SAP and then expanded to contain minimum content for the Safety Plan content. 
• IV&V Project Execution Plan page contains minimum content for the IPEP and some guidance for the RBA and PBRA. 
• Software Requirements Analysis page contains content description for the Software Requirements Report as well as detailed guidance on " SW Requirements Analysis Techniques" and "Safety Analysis During Requirements" 

Topic 8.16 is growing and branching out to contain a collection of different elements: Minimum Contents of Documents, Analysis Techniques. 

We need to look at how Topics (or Supplementary Materials) are being built and ensure that they stay focused while still allowing flexibility in how they are designed and built.

In the table below, I have organized it in Topic Series number order. Rows in green highlight are currently in use. There are several added number series to account for specific types of topics. We may not implement all of these but a few may be necessary in the short run. 

Components might include: 

3. Distribution of Chapter 2 SWEs - REPLACED BY TAB 4

The SWEs from NPR 7150.2D chapter 2 are the Institutional Requirements. Initially, I grouped them into 7 "activities" to make sure that they didn't fall out of the overall activity scheme. The table below is the result of that work. 

SWEs that come from chapter 2 represent things that are done at the Institutional level to enable projects to perform a SWE at the project level. In a sense, they are enabling SWEs.

Additional activities were derived from chapter 2 and are highlighted blue below as the first 7 activities. These chapter 2 activities were then copied into the activities in tab 1, highlighted in yellow, where they seemed most likely to belong. 

4. Activity Groupings

In this tab I will construct the new table of Activities based on our agreement with Tim's input. 

• SWEHB Activity will be the name of the activity we use going forward.  
• NPR Activity Groupings reflects the names of the groups of SWEs found in the NPR. 
• Rows have been added for each SWE so that Supplementary Materials can be associated with the appropriate SWEs. 
• Supplementary Materials may appear in multiple SWEs, primarily from links in the Guidance tab or the SA tab in the SWE. 
• The example in SWE-013 comes from a current idea in development regarding how links are listed. 

4.1 Activity Pages

4.2 Activities based on Tim's Email

5. Activity Diagram

This activity Diagram represents the SWEHB Activities and their layout on a timeline. The timeline is notional and only represents the predecessors and successors and not any iterations that might be necessary in the real world. 

5.1 - Fred's Initial Rough Cut Of Activity Groupings In A Diagram

Gliffy diagrams plugin has been fixed. One of the greatest benefits of Gliffy diagrams is the ability to embed a link in the diagram. I will use this diagram to experiment with Gliffy capabilities. Eventually, a diagram similar to this one will be used to give users a visual representation of the Activity View of SWEHB. 

5.2 Tim's Activities in a Diagram

6. Activities used in SPAN

One element that should probably be in each activity is a link to the SPAN page where more information about the Activity from the Center perspective can be seen. 

This is a list from SPAN of Activities used in various Center Process Asset Libraries. 

6.2 Activity Groupings in NPR but not explicitly in SPAN

7. Design Decisions

The following questions and decisions by the group will steer the design of the Activity View of the SWEHB.