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".
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.
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 SoftwareDesign might be better to consider as a single activity.
Activity Name
SWEs
SWEHB Components: Related Topics, Document Structures, Principles, Checklists, and PATs
Acquisition - found in existing activities such as Planning and Architecture
Monitor and Control - found in Planning and 5.5 SoftwareNon-conformance or Defect Management
Div
id
tabs-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 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 requirements that are satisfied during the conducting of the activity, and
Other work described in the other SWEHB components.
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 ?) 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 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 Type
Topic Series
Component Description
Process
1.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:
Triggers that cause the process to be initiated
Inputs
Process Steps which may be performed in a sequence or simultaneously
Outputs
Follow up actions, e.g. defects that need to be fixed
Cybersecurity Topics
2.xx
In depth guidance on Software Cybersecurity topics.
Software Safety Topics
3.xx
In depth guidance on Software Safety topics.
Review
4.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 Content
5.xx
Describes the minimum content expected in a particular document
Checklist
6.xx
List 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 Topics
7.xx
In depth guidance on Software Engineering topics.
Software Assurance Topics
8.xx
In depth guidance on Software Assurance topics.
Software Design Principles
9.xx
Software Design Principles.
PAT (Process Asset Template)
PAT-xxx
List 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.
Activities
A.xx
SWEHB 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
id
tabs-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 Name
SWEs
SWEHB Components: Related Topics, Document Structures, Principles, Checklists, and PATs
"Benchmarking and Appraisals"
Moved to 3.9 Software Development Processes and Practices
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.
Gliffy Diagram
size
900
displayName
Development Life Cycle
name
Development Life Cycle
pagePin
3
5.2 Tim's Activities in a Diagram
Gliffy Diagram
size
900
displayName
Tims Activities
name
Tims Activities
pagePin
12
Div
id
tabs-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.
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
Activity Grouping in NPR
How it is accounted for in SPAN
3.11 Software Cybersecurity
Not currently accounted for in SPAN
Div
id
tabs-7
7. Design Decisions
The following questions and decisions by the group will steer the design of the Activity View of the SWEHB.
#
Design Element
Question
Design Requirement
1
Activity Names
What is the list of Activity Names that will be used in the Activity View of SWEHB?
Decision:
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 SWEHB Hierarchy
1.1
Diagram
Should we have a high level diagram on the top level activity page?
Decision:
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.
2
SWE Pages
Is every SWE accounted for in one or more Activities?
Question: who wants to come up with the rationale statements?
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.
3
Topic and other pages
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?
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.
4
Related Link Tables
Currently being updated in all SWEs (tab 3) and many Topics