bannerd

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Notes on needed updates

Content updates needed on this page: 

  1. " 

SWEHBDOC Features And Tools

1. Introduction

The Features and Tools pages contain detailed instructions on implementing the features and using the tools associated with the SWEHB. 

The tabs in this page are come from the introductions to each of the features and tools. The full details come from the pages listed below: 

Error rendering macro 'children'

null

2. References

SWEHBDOC References in SWEHB  explains how references are used and maintained in SWEHB. 

Any document, NASA document or external document,  that is referred to in a SWEHB page should be treated as reference.

Most references are called out specifically in the content of a page and include a document ID or title and a link to the Resources tab where a link to the reference can be found. Some references may not be directly called out in the text of the SWE page. These are "implied references. 

3. Activity View

Activity View was first rolled out in 2025, in SWEHBVD of the Handbook. It organizes and presents the SWEs and Topics in the SWEHB in a two ways: 

  • By Development Phase - This is for all content that is part of a phase in the Software Life Cycle. 
  • By Organizational Structure - This is for Software Assurance and Institutional content that is distributed throughout the Life Cycle or is supportive of the Life Cycle. 

In the A.00 Activity View page of SWEHBVD, there is a "Software Development Life Cycle" diagram with links to all the Activity pages in the view. 

Each Activity page has one or more sections devoted to a phase of the Life Cycle. Some of the more complex phases have multiple tabs to group related content. The next level down contains: 

  • Brief explanation of the work that is included. 
  • Frequency of This Activity - statements of when the activity is initially performed and may need to be performed again.
  • Links to SWEHB pages - These are organized by: 
    • Related SWEs - the requirements that are performed in this activity.
    • Related Work Products  - the Work Products that are generated by satisfying the requirement. 
    • Related Process Asset Templates - the PATs that are available to be used 
    • Related Topics - this Supplementary Material provides additional guidance in support of the requirement. 
    • Related SPAN Links - link(s) to SPAN pages with links to pages in Center Process Asset Libraries having helpful templates and content. 

All pages in the SWEHB are reviewed and have links pointing to Related SWEs and Supplementary Materials which are listed in the Guidance tabs or Resources tabs. This cross-referencing extends to Activities and provides Bi-directional traceability among the Activities, Requirements, and Supplementary Materials. See the Crosslinking Tab for more details. 

4. SWE History



5. Quotes


6. User Macros


7. Terms


8. Tools


9. Blog


10. Sticky Headers


11. Crosslinking

All pages in the SWEHB are reviewed and have links pointing to Related SWEs and Supplementary Materials which are listed in the Guidance tabs or Resources tabs. This cross-referencing extends to Activities and provides Bi-directional traceability among the Activities, Requirements, and Supplementary Materials. See the Crosslinking Tab for more details. 

11.1 General Crosslinking 

The concept of Crosslinking comes from the application of Bi-directional Traceability. A requirement from NPR 7150.2 is a simple statement of something that must be done in a Software Development Project. When it is enhanced in the Handbook, information is added such as

  • Rationale - Why the requirement should be done i.e. what is the value to the project of performing the requirement.
  • Guidance - How to satisfy the requirement. This can include multiple ways to satisfy it, some of which might be complex. 
  • Small Projects - Discussion on alternatives for how small projects might satisfy the requirement. 
  • Resources - References and other helpful information about the requirement.
  • Lessons Learned - Information about problems that have occurred or were avoided by satisfying the requirement. 
  • Software Assurance Guidance  - How SA supports and assists in the satisfying of the requirement. 

It is up to the author to identify the crosslinking that is appropriate on a page. This is based on the content. For example, in a SWE page Guidance tab there may be a statement about how a Topic provides a technique that can be used to satisfy the requirement. A link to the Topic page would be included in the text of the tab. It would be appropriate to also have a link in the Topic that points back to the SWE acknowledging that the topic can be used to satisfy the requirement. Additionally, Since all SWEs are a part of one or more Activities, it would be appropriate for the SWE to point to the appropriate Activity. From the point of view of the Activity, the Activity should include the SWE in its list of related  SWEs and the Topic in its list of Related SM (Supplementary Materials). 

To support this concept, each SWE, and Topic has several child pages. For example, SWE-020 - Software Classification would have the following children: 

By reviewing the "Page Information" for a page it is possible to see the incoming and outgoing links 

11.2 Crosslinking in SWEs


11.3 Crosslinking in Supplementary Materials 


11.4 Crosslinking in Activities


11.5 Additional Guidance Sections


  • No labels