2. Institutional Activities

The Institutional Activities include activities associated with OCE, OSMA, and Centers as well as Software Development Project teams. Each activity contains several requirements (from NPR 7150.2D chapter 2)  ensuring that higher levels of management establish certain means and infrastructure for projects to use in their projects. In some cases, requirements for Project teams are included describing the use of the management provided resources in their projects. 

For example: Management is responsible for providing training for engineers who develop software. Project teams are responsible for ensuring that team members have had this training (in addition to other training on project specific systems and software) so that they may produce high quality software. 

2.1 OCE  and OSMA Software Engineering Initiative

Agency Level Activities are intended to provide "enabling support" to project teams. These activities include direction, guidance and support to project teams. The requirements describing these activities are found in NPR 7150.2D Chapter 2. The full activity includes some requirements from Chapters 3 through 5 which are the responsibility of the project teams to satisfy. Many of the names for these Activities come directly from NPR 7150.2D. In a few cases, the names are changed to better express the full scope of the Activity. 

3. Activities

The Software and Assurance activities associated with Software Development Projects are listed as links below. 

Each page will contain an activity description and contain links to all the associated SWEs, Topics, PATs, and other pages in the SWEHB that are associated with the activity. 

3.1 Activity Pages

Links go to existing pages. Underlined (Red in edit mode)  links have not yet been created. All activity pages to be children of the Software Project Activities page.

Content structure is contained in the Activity Template. 

Project Software Activities

3. Activities

The Software and Assurance activities associated with Software Development Projects are listed as links below. 

Each page will contain an activity description and contain links to all the associated SWEs, Topics, PATs, and other pages in the SWEHB that are associated with the activity. 

3.1 Software Activity Pages

Links go to existing pages. Underlined (Red in edit mode)  links have not yet been created. All activity pages to be children of the Software Project Activities page.

Content structure is contained in the Activity Template. 

Project Software Activities

3.2 Software Assurance Activities

Many of the activities of Software Assurance run parallel to Software Development Activities. In fact, development activities that have specific SA participation have a tab in the SWE specifically for Software Assurance participation. 

To further this relationship, the activities below draw on the SA requirements and tasks from NASA-STD-8739.8B and are associated with the SWEs in NPR 7150.2D. 

4. Distribution of SWEHB pages

This tab contains a distribution of SWEs into Activities. Each SWE in the SWEHBVD is in the table. The table lists the Primary Activity in which the SWE is located. Also, for those SWEs that are associated with other activities, the associated activities are listed. This table will be used to distribute the SWEs into activities ensuring that none are lost in the distribution process. 

Under Construction in separate spreadsheet. This table will be updated periodically as the spreadsheet is completed. 

4.1 SWE pages

4. Distribution of SWEs

This tab contains a distribution of SWEs into Activities. Each SWE in the SWEHBVD is in the table. The table lists the Primary Activity in which the SWE is located. Also, for those SWEs that are associated with other activities, the associated activities are listed. This table will be used to distribute the SWEs into activities ensuring that none are lost in the distribution process. 

4.2 Topic Pages

Includes Recommended Content pages from some of the topic pages. 

4.3 PAT Pages

4.4 Other Pages

5. Activity Page Structure

We will need to decide how to consistently display information about activities. Since we have two groups involved with the Activity pages. There are multiple ways of displaying the information related to an Activity. 

5.1 Common Elements in the Activity Structure

5.1 Combined Format

In the combined format, Activities that are closely related such as Planning may have a combined format. Tab 2 information is associated with both Software Engineering and Software Assurance content.  An additional tab is provided to include SA tasks (from the included SWEs) that apply to the activity. 

A risk associated with this way of displaying Activity information is that it may be difficult to easily pick out the SA pieces from the Engineering pieces of an activity. It will be critical to specify who is involved in each element of the activity. An example of this can be found in Planning where the Engineering and Assurance elements of the activity run in parallel and have considerable overlap. Engineering will plan certain processes and then Assurance will plan the auditing of those processes. 

Image Added

5.2 Separate Formats 

In separate formats, there is  only one template. The indication of who is performing the activity is indicated in the title of the Activity. In this example, SA activities include the SA Task lists from the associated SWEs. Software Engineering Activities would not have SA Tasks displayed in section 2.1. 

Image Added

6. Alternative Activity Styles

The Activity is a new concept for organizing content in SWEHB. In this tab, we explore various ways to display activity content while keeping several requirements in mind: 

• minimize the creation of new content by reusing existing content as much as possible. 
• minimize training necessary to use the activity, it should be obvious how to use the activity and its information
• make the activity inclusive so that Software Developers and Software Assurance and others can use it easily

6.1 Initial Reactions to First Two Templates

At our 12/13/2023 meeting, there was some discussion about the organization and content of the two templates reviewed. It was not clear how these templates would accomplish the inclusivity requirement above. In this tab, we will explore some alternatives to these first two templates to attempt to get an Activity organization that satisfies all of the requirements. 

7. Other Considerations For Activities

7.1 Readiness Reviews in Activities

Topic 7.09 - Entrance and Exit Criteria covers a number of reviews that occur at the completion of certain activities.

• Should these reviews be accounted for in the activities? 
• Are they activities by themselves? 
• Do we need PATS for each of these reviews?
  • Could be a single PAT for each review or 3 PATS (Entrance Criteria, Materials for Review, Exit Criteria) for each review. 

7.2 Life Cycle Products

Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews covers maturity of certain life cycle work products at the times of readiness reviews. Currently they are mentioned in the Inputs and Outputs sections of activity tab 1. 

• Should these Work Products be accounted for in the activities in greater depth? Currently I list the docs that are in 7.18. Maybe this should be expanded to cover the docs in NPR 7150.2D, Chapter 6?
• Some docs in Chapter 6 are not broken out in 7.18. They exist as sections of the docs (like Software Development Plan). Should these be mentioned in the appropriate activity?

7.3 Software Engineering Products 

From NPR 7150.2D, Chapter 6, there are some products in the list that are not in Topic 7.18 Documentation Guidance (Minimum Document Content):

• w. Programmer’s/Developer’s Manual

Does this require another Topic? 

7.4 Reformatting of Guidance in SWEs

In the Copy of SWE-058 - Detailed Design with new tab 4 the guidance in tab 3 was already formatted into tasks. This permitted the Tasks to be quickly identified in the new tab 4.  Also, there were clear references to several documents (SwDD, IDD, and SUM) that made building the Work Products section of the activity easier and clearer. Metrics were adapted from those in tab 7 in the example. 

In other SWEs, there may be a need to reformat some things and build out others to get clear tasks, work products, and metrics. For example, the SWEs relating to Peer Reviews need some revisions: 

• In SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures, the guidance does not have subsections in it to clearly identify tasks. Many SWEs would have to be updated to contain clear identification of tasks in the guidance. 
• In SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking, the guidance needs to be revised to clearly identify the tasks (the current version contains the breakdown but could be more clear in its alignment with the requirement. 
• In SWE-089 - Software Peer Reviews and Inspections - Basic Measurements , tab 3 could be a little clearer in terms of tasks. 

In general, a cleanup like this of the Guidance tabs would give the whole SWEHB a more polished look and make it easier to find things. Tab 7 for SA already looks very clean and functional for the assurance folks. Tabs 1, 5, and 6 in all the SWEs have already had such a make over: 

• Tab 1 had consistent numbering of subsections implemented when the SWE History section was added. 
• Tab 5 had some cleanup when the Tools section wording was changed and the PATs added to some SWEs. 
• Tab 6 was reformatted to account for NASA and NON-NASA Lessons Learned.