1. Activity View

Handbook content has been organized into Activities. Activities represent the major groupings of work performed in Software Development Life Cycle phases. They are useful for the work in all Life Cycles including Waterfall, Agile, or other life cycles. Links to the Activities are included in both the Activities Diagram and Activities List below. 

1.1 Activities Diagram

This diagram represents the typical Life Cycle of a Software Development Project. Click on an activity to open a tab to the Activity page in SWEHB.

Each Activity page in SWEHB contains links to all of the SWEs associated with the Activity along with links to all of the Supplementary Materials that support those requirements. 

1.2 Activities List

The list below contains links to all of the Activity pages in the SWEHB. 

• A.00.2 - History of Improvement Efforts — A collection of Institutional Requirements involved in creating the Software Engineering Handbook.  
• A.01 Software Life Cycle Planning — Software Life Cycle Planning is a large activity. It includes a number of related sub-activities that are performed throughout the life of a development project. 
  • A.01.01 Planning the Work
  • A.01.02 Cost Estimation
  • A.01.03 Scheduling the Work
  • A.01.04 Training
  • A.01.05 Monitor and Control
  • A.01.06 Acquisition and Reuse of Software
  • A.01.07 Classification, Tailoring and Waivers
  • A.01.08 Cybersecurity
  • A.01.09 Work Products
• A.02 Software Assurance and Software Safety — The inclusion of content from NASA-STD-8739.8B adds breadth to the Handbook in Software Assurance and Safety areas.  
  • A.02.01 Analysis
  • A.02.02 Auditing
  • A.02.03 IV&V
  • A.02.04 Safety-Critical

• .03 Software Requirements — Requirements are the basis for a software product.
• A.04 Software Design — The Software Design Activity includes both Architecture and Design aspects of the software. While they actually focus on different areas of the software development, they are very closely coupled. A change in one often requires a change in the other. 
  • A.04.01 Architecture
  • A.04.02 Design
• A.05 Software Implementation — Software Implementation is the building of code modules driven by the software requirements. It is shaped by the architecture and design considerations, and by the planning parameters including cost and schedule constraints. 
• A.06 Software Testing — Software testing is required to ensure that the software meets the agreed requirements and design, works as expected, doesn’t contain serious bugs, and meets its intended use as per user expectations. IV&V may be used to expand test coverage and depth. 
  • A.06.01 Testing
  • A.06.02 IV&V
• A.07 Software Release, Operations, Maintenance, and Retirement — Software operations, maintenance, and retirement activities are planned to provide a written or electronic file on how to operate the software, modify and retest the software and provide information on where to archive the software products, the software development environment, and software test environment products and tools.
  • A.07.01 Software Release and Operations
  • A.07.02 Software Maintenance
  • A.07.03 Software Retirement
• A.08 Software Configuration Management — Software Configuration Management planning encompasses the practices and procedures for administering source code, producing software development builds, controlling change, and managing software configurations for all of the software products, tools, data, and components produced by the project.  
• A.09 Software Risk Management — Risk Management is a continuous activity as stated in SWE-086 - Continuous Risk Management. The guidance in this requirement contains a basic process for conducting Risk Management. 
• A.10 Software Peer Reviews and Inspections — Software peer reviews or inspections are performed to ensure product and process quality, add value, and reduce risk through expert knowledge infusion, confirmation of approach, identification of defects, and specific suggestions for product improvements.
  • Work Products That Might Benefit From a Peer Review — Work Products that might benefit from a Peer Review are described in the table below: 
• A.11 Software Measurements — Numerous years of experience on many NASA projects demonstrate the following three key reasons for software measurement activities: (1) to understand and model software engineering processes and products, (2) to aid in assessing the status of software projects, (3) to guide improvements in software engineering processes.
• A.12 Software Non-conformance or Defect Management — To make sure that all software non-conformances are addressed. Managing and tracking non-conformances, software problem reports, or software issues are critical steps to ensuring that software defects are flagged and handled properly.
• A.13 NASA Institutional Requirements — Institutional Requirements are grouped into several sub-activities. 
  • A.13.01 NASA Institutional Requirements
  • A.13.02 Appraisals, Assessments, and Benchmarking
  • A.13.03 Processes
  • A.13.04 Measurement
  • A.13.05 Software Sharing and Reuse
  • A.13.06 Training