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 40

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.

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

Should we have a high level diagram on the top level activity page? 

Decision: Open - will continue to develop Tim's diagram with activity links, etc. 

Is every SWE accounted for in one or more Activities? 

Question: who wants to come up with the rationale statements?

Is every Topic and other appropriate SWEHB page accounted for in one or more Activities? 

Question: who wants to come up with the rationale statements? 

Currently being updated in all SWEs (tab 3) and many Topics

Decision: Preference is to have a single column in tabs 3 and 7 with just links (no other excerpts or requirements). Tab 5 Resources would have a table with 2 columns, one for link table from tab 3, the other with the link table from tab 7. 

This would free up a tab for other use

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


Activity NameSWEs SWEHB ComponentsActivity NameSWEs SWEHB Components: Related Topics, Document Structures, 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 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

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. 

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

In the table below, I have organized it in Topic Series number order. Rows in green highlight are currently in use. Components 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
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).
Software Engineering Topics7.xxIn depth guidance on Software Engineering topics. 
Software Assurance Topics8.xxIn depth guidance on Software Assurance topics.
Software Design Principles9.xxSoftware Design Principles. 
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. 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.
Div
idtabs-3

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.

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

4. Activity Groupings

In this tab I will construct the new table of Activities based on the input from all of you. 

  • 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. They have the chapter and location number so we wont get confused. 

4.1 Fred's Initial Rough Cut Of Activity Groupings

The last column is used for SWEs that apply to the "SWEHB Activity" regardless of the "NPR Activity Grouping" that it belongs to. 

Tim's Activities

Software Assurance and Software Safety

Software Assurance
and Software Independent Verification & Validation

Safety-Critical Software

Software Development
Processes and Practices

Related Institutional Requirements

Software Testing

Software Cybersecurity (testing part)

Software Non-conformance
or Defect Management (Testing part)

Software Configuration Management (SCM)

Software Risk Management

Software Peer Reviews
and Inspections

Software Measurements

Software Non-conformance
or Defect Management (all non-testing parts)

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. 

Div
idtabs-7

7. Design Decisions

Edit: 7. Design Decisions

Include Page
7. Design Decisions
7. Design Decisions

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

7.18 - Train - Software Training Plan

Div
idtabs-4
SWEHB ActivityNPR Activity Groupings Specific SWEs That Apply1Planning

3.1 Software Life Cycle Planning

3.2 Software Cost Estimation

3.3 Software Schedules

3.4 Software Training

3.5 Software Classification
Assessments

2Monitor and Control

5.5 Software Non-conformance
or Defect Management

SWE-024 - Plan Tracking
3Requirements Management

4.1 Software Requirements

3.12 Software Bi-Directional Traceability

4Architecture and Design

4.2 Software Architecture

4.3 Software Design

3.10 Software Reuse

5Implementation and Coding

4.4 Software Implementation

3.8 Automatic Generation of
Software Source Code

6Testing4.5 Software Testing7IV&V3.6 Software Assurance
and Software Independent
Verification & Validation		8Release, Operations,
Maintenance, and Retirement		4.6 Software Operations,
Maintenance, and Retirement		9Software Assurance3.6 Software Assurance
and Software Independent
Verification & Validation		10Software Development
Processes and Practices		3.9 Software Development
Processes and Practices		11Safety-Critical Software3.7 Safety-Critical Software12Cybersecurity3.11 Software Cybersecurity13Configuration Management5.1 Software Configuration
Management (SCM)		14Risk Management5.2 Software Risk Management15Peer Reviews and Inspections5.3 Software Peer Reviews
and Inspections		16Measurements and Metrics5.4 Software MeasurementsSWEHB ActivityNPR Activity Groupings Specific SWEs From Ch 2 That Apply1Software Life Cycle Planning

Software Life Cycle Planning

Software Cost Estimation

Software Schedules

Software Training

Software Classification
Assessments

Software Cybersecurity (using secure coding guidelines part)

Software Development
Processes and Practices

Related Institutional Requirements 

2Software Assurance and Software Safety3Software Requirements

Software Requirements

Software Cybersecurity (requirements part)

Software Bi-Directional Traceability

4Software Design

4.2 Software Architecture

4.3 Software Design

5Software Implementation 

Software Implementation

Automatic Generation of
Software Source Code

6Software Testing7Release, Operations,
Maintenance, and Retirement

Software Operations,
Maintenance, and Retirement

Software Reuse

Related Institutional Requirements

8Full Life Cycle Activities9NASA Institutional Requirements

Benchmarking and Appraisals Related

Library Related

Classification Related

Process Definition Related

Measurements and Metrics Related

Mapping Matrix and Classification Related

Training Related 

Div
idtabs-5
Gliffy Diagram
size900
displayNameDevelopment Life Cycle
nameDevelopment Life Cycle
pagePin3

5.2 Tim's Activities in a Diagram

Gliffy Diagram
size900
displayNameTims Activities
nameTims Activities
pagePin3

Div
idtabs-6
Activity in SPANDescriptionHas Counterpart in SWEHB
Project PlanningProject planning and scheduling assets

3.1 Software Life Cycle Planning

3.3 Software Schedules

Process SelectionSelecting processes using the Compliance Matrix3.5 Software Classification
Assessments
ClassificationClassification of Software Process3.5 Software Classification
Assessments
EstimationEstimation processes and related assets3.2 Software Cost Estimation
Project Monitoring and ControlMonitoring and control assets5.5 Software Non-conformance
or Defect Management
Risk ManagementRisk Management assets5.2 Software Risk Management
ClosureAssets used when closing a project
RequirementsAssets for recording and tracking requirements and change control

4.1 Software Requirements

3.12 Software Bi-Directional Traceability

DesignAssets for use during product design

4.3 Software Design

3.10 Software Reuse

4.2 Software Architecture

Code and IntegrationCoding and software integration assets

4.4 Software Implementation

3.8 Automatic Generation of
Software Source Code

Peer ReviewReview processes and follow up activities5.3 Software Peer Reviews
and Inspections
Verification and ValidationVerification and Validation assets

3.6 Software Assurance
and Software Independent
Verification & Validation

4.5 Software Testing

Release, Sustain and RetireAssets used during product release, Sustaining activities, and Retirement4.6 Software Operations,
Maintenance, and Retirement
Configuration ManagementConfiguration management and change control assets5.1 Software Configuration
Management (SCM)
MetricsMetrics assets5.4 Software Measurements
Decision MakingDecision making processes and templates
ImprovementProcess Improvement activities including SEPG3.9 Software Development
Processes and Practices
Software Quality AssuranceSoftware Quality Assurance and Audit assets3.6 Software Assurance
and Software Independent
Verification & Validation
SafetySafety3.7 Safety-Critical Software
PurchasingAssets used in purchasing software3.1 Software Life Cycle Planning
ContractingAssets used when contracting software development3.1 Software Life Cycle Planning
TrainingGeneral Training3.4 Software Training
Activity Grouping in NPRHow it is accounted for in SPAN
3.11 Software CybersecurityNot currently accounted for in SPAN
Div
idtabs-7

7. Design Decisions

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

#Design ElementQuestionDesign Requirement
1Activity Names

What is the list of Activity Names that will be used in the Activity View of SWEHB?

Decision: Use Tim's Naming of Activities

  • Each Activity Name will be numbered in the sequence A.00 - A.99
  • Each Activity will have a page with the Activity number and name in the title
  • Each activity will be placed under the Activity View page in the SWEHBVD Hierarchy
  • Since Activities will contain links to SWEs, It will need to be in the SWEHBVD space (not in SITE space)
1.1Diagram
  • Review two candidates
  • Characteristics of diagrams
    • May use colors to group related activities (e.g. SA activities)
    • Numbering of Activities - to simplify use of References in Activities
    • Gliffy diagrams allow using embedded links in diagrams. 
2SWE Pages
  • Every SWE must be in the SWEHB Activity that corresponds to it's NPR 7150.2 activity. 
  • SWEs may be added to other SWEHB Activities and noted as "Related". 
  • Each SWE should have an accompanying statement expressing why it is in the Activity. This statement, "rationale", may appear in the SWEHB Activity. 
3Topic and other pages
  • Every Topic must be in the SWEHB Activity that corresponds to it's function.  
  • Topics may be added to other SWEHB Activities, as appropriate. For example, a topic on Peer Reviews may be included in other Activities that have work products that need to be reviewed. 
  • Each Topic should have an accompanying statement expressing why it is in the Activity. This statement, "rationale", may appear in the SWEHB Activity. Topics currently have an "excerpt" that is used in the Topics page to describe its purpose. These should be reviewed for adequacy in the SWEHB Activity pages. 
4Related Link Tables

See examples in SWE-013 Software Plans - Related Links demo

  • Single table - mixed SWEs and Topics
  • Separate tables
    • Related SWEs
    • Related Supplementary Materials (Topics, PATs, Checklists, ...)
  • Location
    • In tab 3, tab 7 or both?
    • In Resources tab?
  • Build out an example in SWE-013 for review. 
    • child page for each tab's table. 
5Activity page Layout

What information should be displayed on an Activity page? 

  • There must be at least one statement for each SWE, Topic or other SWEHB page describing why it is included in the Activity. 
  • Statements must be reusable and may be in the form of: 
    • Excerpt macros in the SWE, Topic or other page
    • Include page as a child of the SWE, Topic or other page
  • Should we have process-like sections for 
    • Predecessor Activities
    • Successor Activities
    • Inputs - documents, etc.
    • Outputs - Documents, etc.
  • For SWEs, should there be a
    • single list of SWEs in some order
    • groups of related SWEs corresponding to sub-activities
  • For Supplementary Materials, should there be: 
    • single list 
    • groupings of related materials
  • What tabs should be in an activity (standard tabs like in SWEs)
?What to do with SWE tab 4s

Do Small Project tabs belong in SWEs or should Small Projects be the subject of a Topic? 

This would free up a tab for other use. 
?What to do with SWE tab 2s 

Most Rationale statements are small, could they be put on tab 1?


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
______________________________________________________________________________