bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Link
Leave blank if none exists

Unknown macro: {div}

https://standards.nasa.gov/standard/nasa/nasa-gb-871913

Title
This is the text which will be hyperlinked, if a link exists

NASA Software Safety Guidebook,

SWE or Topic

SWE-023, SWE-027, SWE-044, SWE-049, SWE-050, SWE-051, SWE-052, SWE-055, SWE-056, SWE-059, SWE-062, SWE-063, SWE-064, SWE-065, SWE-066, SWE-068, SWE-069, SWE-072, SWE-074, SWE-075, SWE-077, SWE-078, SWE-079, SWE-080, SWE-081, SWE-082, SWE-083, SWE-085, SWE-086, SWE-087, SWE-103, SWE-104, SWE-105, SWE-109, SWE-111, SWE-113, SWE-118, SWE-130, SWE-131, SWE-133, SWE-134, SWE-138, SWE-146, SWE-147, SWE-186, SWE-187, SWE-192, Topic 5.01, Topic 5.04, Topic 5.06, Topic 5.09, Topic 5.10, Topic 5.11, Topic 7.4, Topic 7.04, Topic 7.5, Topic 7.05, Topic 7.11, Topic 5.13, Topic 7.18, Topic 8.58, CR-PR, Maint, SCMP, SRS, STP, STR,

Citation
This contains additional information, which will appear after the title, separated by a comma

NASA-GB-8719.13, NASA, 2004.

Notes
More specific directions where to look in the resource for relevant content

Access NASA-GB-8719.13 directly: https://swehb-pri.msfc.nasa.gov/download/attachments/16450020/nasa-gb-871913.pdf?api=v2

Example Reference as it will appear to end user:

  1. Title, Citation

where:


Quotes used in SWEs and Topics

6.4.3 Requirements Change Management
"The actual process of making changes should be a structured, defined process. This process should describe how a proposed change is submitted, evaluated, decided upon, and incorporated into the requirements baseline. Usually, a change control board, consisting of people from various disciplines and perspectives, will review potential changes and either approve or reject them. A requirements management tool can help manage the changes made to many individual requirements, maintain revision histories, and communicate changes to those affected by them.

Part of the change management process should be an evaluation of the impact the change will have on the system and other requirements. Traceability information is an important tool in this evaluation."

4.3.5 Testing
"Testing serves several purposes: to find defects; to validate the system or an element of the system; and to verify functionality, performance, and safety requirements. The focus of testing is often on the verification and validation aspects. However, defect detection is probably the most important aspect of testing. While you cannot test quality into the software, you can certainly work to remove as many defects as possible."

4.3.5  Testing
"Some basic principles of testing are:

  • All tests need to be traceable to the requirements, and all requirements need to be verified by one or more methods (e.g., test, demonstration, inspection, analysis).
  • Tests need to be planned before testing begins. Test planning can occur as soon as the relevant stage has been completed. System test planning can start when the requirements document is complete.
  • The "80/20" principle applies to software testing. In general, 80 percent of errors can be traced back to 20 percent of the components. Anything you can do ahead of time to identify components likely to fall in that 20 percent (e.g., high risk, complex, many interfaces, demanding timing constraints) will help focus the testing effort for better results.
  • Start small and then integrate into the larger system. Finding defects deep in the code is difficult to do at the system level. Such defects are easier to uncover at the unit level.
  • You can't test everything. However, a well-planned testing effort can test all parts of the system. Missing logic paths or branches may mean missing important defects, so test coverages need to be determined.
  • Testing by an independent party is most effective. It is hard for developers to see their bugs. While unit tests are usually written and run by the developer, it is good to have a fellow team member review the tests. A separate testing group will usually perform the other tests. An independent viewpoint helps find defects, which is the goal of testing.

Scheduling testing phases is always an art and depends on the expected quality of the software product. Relatively defect-free software passes through testing within a minimal time frame. An inordinate amount of resources can be expended testing buggy software. Previous history, either of the development team or similar projects, can help determine how long testing will take. Some methods (such as error seeding and Halstead's defect metric) exist for estimating defect density (number of defects per unit of code) when historical information is not available."

Software Configuration Management Plan.
"All software products, which includes far more than just code, must be configuration managed. Old files in a software build are a notorious problem, as are lost updates and other problems with changed files. The plan specifies what will be under configuration management (CM), what CM system will be used, and the process for moving an item into or out of the CM system."

Configuration Management (CM).
"The discipline of CM (configuration management) is vital to the success of any software effort. CM is an integrated process for identifying, documenting, monitoring, evaluating, controlling, and approving all changes made during the life cycle of the program for information that is shared by more than one individual or organization."

4.5.4 Defect Tracking
"Having defect information from previous projects can be a big plus when debugging the next project. ...Recording the defects allows metrics to be determined. One of the easiest ways to judge whether a program is ready for serious safety testing is to measure its defect density---the number of defects per line of code."

4.5.3 Status Accounting
"While the status information can be compiled by hand, it can be a tedious process. Many tools exist that provide an integrated configuration management system for all kinds of documents, including source code, and that can generate the status reports when requested. Some of these tools are free or low-priced."

6.5.5 Peer Reviews of Software Requirements
"Peer Reviews have the most impact when applied early in the life of a project, especially the requirements specification and definition stages of a project. Impact means that the defects are found earlier when it's cheaper to fix them... Peer Reviews greatly improves the communication within a project and enhances understanding of the system while scrubbing out many of the major errors and defects."


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