bannerd

A. Introduction

B. Institutional Requirements

C. Project Software Requirements

D. Topics

E. Tools, References, and Terms

F. SPAN
(NASA Only)

Versions Compared

Old Version 21

changes.mady.by.user Haigh, Fred

Saved on

compared with

New Version Current

changes.mady.by.user Haigh, Fred

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Tabsetup
01. Activities and Their SWEHB Components
12. Definitions
23. Chapter 2 SWE Distribution
34. Activity Groupings
45. Activity Diagram
56. Activities used in SPAN
67. Design Decisions
Div
idtabs-1

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

Tablink2
tab4
linktextActivity Groupings
- it contains the activity names that were decided on)

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".   (See

Tablink2
tab4
linktextActivity Groupings
- it contains the activity names that were decided on)

Note

At this point, all SWEs and Topics are

Note

At this point, all SWEs and Topics are represented "somewhere" in this scheme. It does not mean that they are in all of the appropriate places. Once we decide that the activity names should be, adding and deleting as appropriate, we will need to make sure that all of the SWEs, Topics and other pages are represented in the appropriate Activities. 

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.  (See
    Tablink2
    tab4
    linktextActivity Groupings
    - activities contain all the 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 05 - 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
COLUMN 3 WILL BE DISTRIBUTED INTO SWES AS APPROPRIATE TO ENSURE THAT CROSS LINKING IS COMPLETE


 SWEHB Components: Related Topics, Document Structures
Activity NameSWEs SWEHB Components: Related Topics, Document StructuresActivity NameSWEs, Principles, Checklists, and PATs
3.1 Software Life Cycle Planning

3.2 Software Cost Estimation

3.3 Software Schedules

3.4 Software Training

SWEs from Ch 2 - Institutional Requirements

3.5 Software Classification
Assessments


SWEs from Ch 2 - Institutional Requirements
3.6 Software Assurance
and Software Independent
Verification & Validation


3.7 Safety-Critical Software
3.8 Automatic Generation of
Software Source Code
3.9 Software Development
Processes and Practices

SWEs from Ch 2 - Institutional Requirements

3.10 Software Reuse

SWEs from Ch 2 - Institutional Requirements

3.11 Software Cybersecurity
3.12 Software Bi-Directional Traceability
4.1 Software Requirements
4.2 Software Architecture
4.3 Software Design
4.4 Software Implementation
4.5 Software Testing
4.6 Software Operations,
Maintenance, and Retirement
5.1 Software Configuration
Management (SCM)
5.2 Software Risk Management 
5.3 Software Peer Reviews
and Inspections
5.4 Software Measurements

SWEs from Ch 2 - Institutional Requirements

5.5 Software Non-conformance
or Defect Management


  • 7.18 - 
5.01 - CR-PR - Software Change Request - Problem Report
Other SWEHB pages that don't fit into the "activity" model

Other Other Activities for consideration: 

  • Acquisition - found in existing activities such as Planning and Architecture
  • Monitor and Control - found in Planning and 5.5 Software Non-conformance or Defect Management

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.

Div
idtabs-2

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 lifecycle of 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:

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

Components include: 

Component TypeTopic SeriesComponent Description
Document Content5.xxDescribes the minimum content expected in a particular document
Checklist6.xxList of things to consider when performing some development or assurance task in a project. Checklists are frequently designed as a Process Asset Template (PAT).
PAT (Process Asset Template)PAT-xxxList of things to do or consider when performing a development or assurance task in a project. These may be used in any of the other Topic series
Review4.xx

List of things to do or consider when performing a development or assurance task in a project. Usually includes Items for:

  • Preparing for the review
  • Actions taken during the review
  • Actions taken after the review
Process1.xx

Regularly performed set of actions with an expected set of outcomes. An example might be a generic Peer Review Process. A process usually contains: 

  1. Triggers that cause the process to be initiated
  2. Inputs
  3. Process Steps which may be performed in a sequence or simultaneously
  4. Outputs
  5. Follow up actions, e.g. defects that need to be fixed
Software Engineering Topics7.xxIn depth guidance on Software Engineering topics. 
Software Assurance Topics8.xxIn depth guidance on Software Assurance topics.
Software Safety Topics3.xxIn depth guidance on Software Safety topics.
Software Design Principles9.xxSoftware Design Principles. 
Cybersecurity Topics2.xxIn depth guidance on Software Cybersecurity topics.
Note
titleSignificance of the Topic Number Format

The significance of the numbering was to provide a "hook" for the References Table. Any reference that needed to appear on a Topic page was tagged in the References Table with the 7.xx number for the page. A macro parsed out these characters from the page name and used that as the lookup key for finding references. 

There are 3 macros used for building the references list on pages. Each has specific code for finding and using the "key" for finding references. 

  • refstable - Uses the first 7 characters of the page title to derive the search key for references: SWE-xxx
  • refstable-topic - Uses the first 4 characters of the page title to derive the search key for references: x.xx
  • refstable-into - Uses a hardcoded key of "Intro" 

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: 

Component TypeTopic SeriesComponent Description
Process1.xx

Regularly performed set of actions with an expected set of outcomes. An example might be a generic Peer Review Process. A process usually contains: 

  1. Triggers that cause the process to be initiated
  2. Inputs
  3. Process Steps which may be performed in a sequence or simultaneously
  4. Outputs
  5. Follow up actions, e.g. defects that need to be fixed
Cybersecurity Topics2.xxIn depth guidance on Software Cybersecurity topics. 
Software Safety Topics3.xxIn depth guidance on Software Safety topics.
Review4.xx

List of things to do or consider when performing a development or assurance task in a project. Usually includes Items for:

  • Preparing for the review
  • Actions taken during the review
  • Actions taken after the review

This would initially be populated by taking apart topic 7.09 - Entrance and Exit Criteria with each tab (review) becoming a numbered page. This would allow individual pages to be included in a SWEHB Activity without pulling in the whole of 7.9. We could keep 7.9 and pull in all of the new pages if needed to keep topic 7.9 in its place. 

This would allow for the documenting other types of Reviews beyond just those in 7.9. 

Document Content5.xx

Describes the minimum content expected in a particular document.

This would get us back to the concept of "minimum content of a document" like in the original SWEHB version (space 7150). Each document would be represented by an individually number page in this series. Individual pages could be also be included in other topics as necessary.

This is a numbering sequence that needs to be implemented so that hardcoding of references tables can be eliminated. 

Checklist6.xxList of things to consider when performing some development or assurance task in a project. Checklists are frequently also built into a Process Asset Template (PAT). The PAT is included in the Checklist page so there is only one place to update the Checklist. 
Software Engineering Topics7.xxIn depth guidance on Software Engineering topics. 
Software Assurance Topics8.xxIn depth guidance on Software Assurance topics.
Software Design Principles9.xx

Software Design Principles. This is a numbering sequence that needs to be implemented so that hardcoding of references tables can be eliminated. 

5/9/2023 - Implementation in SWEHBVD complete

?? - Implementation in SWEHBVC?

PAT (Process Asset Template)PAT-xxx

List of things to do or consider when performing a development or assurance task in a project. PATs are formatted into documents that can be downloaded by projects and used or tailored for use in a project.

These may be used and included in any of the other Topic series. This series number format will allow using the "refstable" macro to select references if we allow references to be assigned to a PAT. 

ActivitiesA.xxSWEHB Activity View series. This series number format will allow using the "refstable-topic" macro to select references if we allow references to be assigned to an Activity.
Other Series
The use of a 4 character key for pages is what would allow for building unique search keys for finding references and building the reference list for pages. once we run out of numbers for the first character, we can move on to alpha characters. Using A for Activities is the first use of this technique. For more series, we could move on to "B.xx", "C.xx", ..., "Z.xx". 

2. Topic Renumber Tracking

Topic SeriesActionProgress
7.1 - 7.9 to 7.01 - 7.09Cleanup in SWEHBVDDone 5/19/2023

Cleanup in SWEHBVCWorking 5/19

Cleanup in SWEHBVB

Cleanup in 7150
8.1 - 8.9 to 8.01 - 8.09Cleanup in SWEHBVD

Cleanup in SWEHBVC
Design Principles  9.01 - 9.17Cleanup in SWEHBVDDone 5/19/2023

Cleanup in SWEHBVCDone 5/19/2023
Activities A.01 - A.13Implemented in SWEHBVDDone 5/19/2023
Checklists 6.01 - 6.09Cleanup in SWEHBVD

Cleanup in SWEHBVD



Div
idtabs-3

3. Distribution of Chapter 2 SWEs - Complete - See 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. 

Activity NameInstitutional SWEs 

A.01 Software Life Cycle Planning

SWE-152 - Review Requirements Mapping Matrices

SWE-098 - Agency Process Asset Library

SWE-214 - Internal Software Sharing and Reuse

SWE-218 - Contracting Officers

SWE-126 - Tailoring Considerations

SWE-153 - ETA Define Document Content

SWE-215 - Software License Rights

SWE-021 - Transition to a Higher Class

A.02 Software Assurance and Software Safety 

SWE-212 - NASA-STD-8739 Mapping Matrices

A.07 Software Release, Operations, Maintenance, and Retirement 

SWE-216 - Internal Software Sharing List

SWE-217 - List of All Contributors and Disclaimer Notice

A.13 NASA Institutional Requirements 

"Benchmarking and Appraisals"

SWE-004 - OCE Benchmarking

SWE-129 - OCE NPR Appraisals

SWE-209 - Benchmarking Software Assurance
and Software Safety Capabilities

SWE-221 - OSMA NPR Appraisals

"Process Library"

SWE-144 - Software Engineering Process Assets

Process Definition Related

SWE-002 - Software Engineering Initiative

SWE-208 - Advancing Software Assurance and Software Safety Practices

SWE-003 - Center Improvement Plans

SWE-005 - Software Processes

SWE-095 - Report Engineering Discipline Status

SWE-006 - Center Software Inventory

"Measurements and Metrics"

SWE-091 - Establish and Maintain Measurement Repository

SWE-092 - Using Measurement Data

SWE-142 - Software Cost Repositories

Matrix and Classification Related

SWE-223 - Tailoring IV&V project selections

SWE-140 - Comply with Requirements

SWE-150 - Review Changes To Tailored Requirements

Training Related

SWE-100 - Software Training Funding

SWE-222 - Software Assurance Training

Div
idtabs-4

4. Activity Groupings

This tab contains 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. 
  • The content of the Supplementary Materials column for each SWE if taken from the SWEs Related SM child page. 
    • The SWEs Related SM child page is built from: 
      • Related links to Supplementary Materials in the SWE Guidance (tabs 3 and 7)
      • Research from tab 1 of "Activities and Composition" page where all Topics, checklists, PATs, etc. were distributed to the SWEs that seemed to be relevant. 
    • The SWE will be updated to call out all of the relevant materials.
  • The example in SWE-013 comes from a current idea in development regarding how links are listed. 

4.1 Activity Pages - Built from the Group's list

See A.00 Activity View in SWEHBVD for the list of activities

4.2 Activities based on Tim's Email

See A.00 Activity View in SWEHBVD for the list of activities


Div
idtabs-5

5. Activity Diagram - See Diagram in "A.00 Activity View page

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 Diagram in A.00 Activity View

Diagram with live links is in the page A.00 Activity View tab 1. 

Image Added

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


Gliffy Diagram
size900
displayNameDevelopment Life Cycle
nameDevelopment Life Cycle
pagePin3


5.3 Tim's Activities in a Diagram

Gliffy Diagram
size900
displayNameTims Activities
nameTims Activities
pagePin3

Div
idtabs-6

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. 

6.1 Bi-directional Traceability - Between SWEHB and SPAN

  • Each Activity in SWEHB will have a subsection containing a link to the appropriate page in SPAN containing links to Center pages with assets. 

This is a list from SPAN of Activities used in various Center Process Asset Libraries. Each of the SPAN Activity pages contains a link to the SPAN Library page where Links to Center libraries are listed that are relevant to the activity. Each Center maintains their libraries. Each Center library contains only those assets which the Center has decided to share outside of the Center. 

The description of the page, includes a brief statement of the contents, the requirement group from NPR 7150.2 which is applicable, and the applicable SWEHB Activity.  

Include Page
SPAN Library Include Pages
SPAN Library Include Pages

6.2 Activity Groupings in NPR 7150.2 but not explicitly in SPAN

Activity Grouping in NPRHow it is accounted for in SPAN
3.11 Software CybersecurityNot currently accounted for in SPAN

7.1 - History and Overview of the Software Process Improvement (SPI) Effort

7.18 - Train - Software Training Plan

Div
idtabs-7

7. Design Decisions

Edit: 7. Design Decisions

Include Page
7. Design Decisions
7. Design Decisions

Div
idtabs-3

3. Distribution of Chapter 2 SWEs

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. 

Activity NameSWEs SWEHB Components: Related Topics, Document Structures, Principles, Checklists, and PATs

"Benchmarking and Appraisals"

Moved to 3.9 Software Development
Processes and Practices

SWE-004 - OCE Benchmarking

SWE-129 - OCE NPR Appraisals

SWE-209 - Benchmarking Software Assurance
and Software Safety Capabilities

SWE-221 - OSMA NPR Appraisals

8.12 - Basics of Software Auditing

"Licensing, Sharing and Reuse"

Moved to 3.10 Software Reuse

SWE-215 - Software License Rights

SWE-216 - Internal Software Sharing List

SWE-217 - List of All Contributors and Disclaimer Notice

SWE-214 - Internal Software Sharing and Reuse

SWE-218 - Contracting Officers

8.8 - COTS Software Safety Considerations

"Measurements and Metrics"

Moved to 5.4 Software Measurements

SWE-091 - Establish and Maintain Measurement Repository

SWE-092 - Using Measurement Data

SWE-142 - Software Cost Repositories

7.14 - Implementing Measurement Requirements and Analysis for Projects

7.18 - Metrics - Software Metrics Report

"Process Definition"

Moved to 3.9 Software Development
Processes and Practices

SWE-002 - Software Engineering Initiative

SWE-208 - Advancing Software Assurance and Software Safety Practices

SWE-003 - Center Improvement Plans

SWE-005 - Software Processes

SWE-095 - Report Engineering Discipline Status

SWE-006 - Center Software Inventory

"Process Library"

Moved to 3.9 Software Development
Processes and Practices

SWE-098 - Agency Process Asset Library

SWE-144 - Software Engineering Process Assets

SWE-153 - ETA Define Document Content

"Requirement Mapping, Tailoring,
and Classification"

Moved to 3.5 Software Classification
Assessments 

SWE-152 - Review Requirements Mapping Matrices

SWE-212 - NASA-STD-8739 Mapping Matrices

SWE-223 - Tailoring IV&V project selections

SWE-140 - Comply with Requirements

SWE-126 - Tailoring Considerations

SWE-150 - Review Changes To Tailored Requirements

SWE-021 - Transition to a Higher Class

7.2 - Classification and Safety-Criticality

7.13 - Transitioning to a Higher Class

7.16 - Appendix C. Requirements Mapping and Compliance Matrix

"Training"

Moved to 3.4 Software Training

SWE-100 - Software Training Funding

SWE-222 - Software Assurance Training


Page Editor: Tim Crumbley
NASA Official: Tim Crumbley
Accessibility
NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer
NASA Privacy Statement
______________________________________________________________________________