2. DefinitionsIn 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 ActivityGeneral 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" ComponentsEach 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 ComponentsAny 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 NumbersIn 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. 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 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
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 Content | 5.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. | | Checklist | 6.xx | List 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 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. 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. | | 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. | | 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 Series | Action | Progress |
|---|
| 7.1 - 7.9 to 7.01 - 7.09 | Cleanup in SWEHBVD | Done 5/19/2023 |
| Cleanup in SWEHBVC | Working 5/19 |
| Cleanup in SWEHBVB |
|
| Cleanup in 7150 |
| | 8.1 - 8.9 to 8.01 - 8.09 | Cleanup in SWEHBVD |
|
| Cleanup in SWEHBVC |
| | Design Principles 9.01 - 9.17 | Cleanup in SWEHBVD | Done 5/19/2023 |
| Cleanup in SWEHBVC | Done 5/19/2023 | | Activities A.01 - A.13 | Implemented in SWEHBVD | Done 5/19/2023 | | Checklists 6.01 - 6.09 | Cleanup in SWEHBVD |
|
| Cleanup in SWEHBVD |
|
|
|
|
|