UNDER CONSTRUCTION

New in SWEHB

1. Introduction

Software Engineering activities are conducted in a predictable sequence. This sequence may be a once through / "waterfall" cycle. Or, it may be an iterative  or evolutionary series of cycles which build toward a final product. Regardless of the model chosen, individual activities in all these cycles are very similar. 

The major activity groupings here give you a quick way to find guidance in the SWEHB to help you satisfy the needs of the development project while also satisfying the requirements of NPR 7150.2. 

The activities associated with Software Development are listed in the tabs of this page. Each tab takes you to a list of links to pages where the activity is is explained in more detail. At the lowest level, there is a list of links to specific pages in the SWEHB where details of the activity are explained and more guidance is provided. In some cases, templates or other Process Assets are included to further help you in conducting the activity. 


1.1 Activity Groupings

The tabs in this page initially will contain all of the activities in Ch 2 through 5 of NPR 7150.2. This is done to ensure that all SWEs are accounted for. 

As the page matures, Topics, PATs, and other resources will be distributed to enrich the content of the activities. 

SWEs from NPR 7150.2 are reproduced in a floatbox on the right to ensure that all SWEHB content is accounted for somewhere in the view. 


2. Institutional Activities

The Institutional Activities include activities associated with OCE, OSMA, and Centers as well as Software Development Project teams. Each activity contains several requirements ensuring that higher levels of management establish certain means and infrastructure for projects to use in their projects. Project teams then have requirements to use these management provides resources in their projects.  For example. Management is responsible for providing training for engineers who develop software. Project teams are responsible for ensuring that team members have had this training (in addition to other training on project specific systems and software) so that they may produce high quality software. 

2.1 OCE  and OSMA Software Engineering Initiative

Agency Level Activities are intended to provide "enabling support" to project teams. These activities include direction, guidance and support to project teams. The requirements describing these activities are found in NPR 7150.2D Chapter 2. The full activity includes some requirements from Chapters 3 through 5 which are the responsibility of the project teams to satisfy. 

Activity NameActivity Components
OCE and SMA benchmarking and determining the capability and maturity of software development groups. Benchmarking techniques derived from CMMI best practices. 
Training at all levels from Agency (engineering practices and related training) down to project needs (training for personnel on using development tools). 
Development of repeatable processes and practices for OCE, SMA and Center development activities. 

Determining the applicability of NPR 7150.2 requirements to a particular project. Includes requirements necessary for particular software classifications. 

Includes SWEs from section 3.5 Software Classification Assessments. 

Suggested measurements and practices for software projects. 


Software measurement is a primary tool for managing software processes and evaluating the quality of software products. Analysis of measures provides insight into the capability of the software organization and identifies opportunities for software process and product improvements. Software measurement programs at multiple levels are established to meet measurement objectives. The requirements below are designed to reinforce the use of measurement at the project, Center software organization, and NASA Chief Engineer levels to assist in managing projects, assuring quality, and improving software engineering practices.

The NASA OCE shall maintain an Agency-wide process asset library of applicable best practices and process templates for all size projects

Requirements related to the licensing, sharing and reuse of some or all of software products. 

3. Activities

The Software and Assurance activities associated with Software Development Projects are listed as links below. 

Each page will contain an activity description and contain links to all the associated SWEs, Topics, PATs, and other pages in the SWEHB that are associated with the activity. 

3.1 Activity Pages

Links go to existing pages. Underlined (Red in edit mode)  links have not yet been created. All activity pages to be children of the Software Project Activities page.

Content structure is contained in the Activity Template. 

Project Software Activities

Activity NameActivity Components
Life Cycle Planning

Software life cycle planning covers the software aspects of a project from inception through retirement. The software life cycle planning is an organizing process that considers the software as a whole and provides the planning activities required to ensure a coordinated, well-engineered process for defining and implementing project activities. These processes, plans, and activities are coordinated within the project. At project conception, software needs for the project are analyzed, including acquisition, supply, development, operation, maintenance, retirement, decommissioning, and supporting activities and processes. The software effort is scoped, the development processes defined, measurements defined, and activities are documented in software planning documents.

Software Peer Reviews and Inspections

Software peer reviews and inspections are the in-process technical examination of work products by peers to find and eliminate defects early in the life cycle. Software peer reviews and inspections are performed following defined procedures covering the preparation for the review, the review itself is conducted, results are recorded, results are reported, and completion criteria is certified. When planning the composition of a software peer review or inspection team, consider including software testing, system testing, software assurance, software safety, software cybersecurity, and software IV&V personnel.

Used when software is acquired or secured from outside sources. 
Used for monitoring progress and keeping the project under control through minor adjustments 
Used for establishing cost of development of the software products. It includes multiple models and parameters, direct and indirect costs, for the work so that tracking can be effectively done. 
Used for establishing and maintaining the development and delivery schedule. Takes into account dependencies on other projects and programs. Includes time for reviews and tracking of issues to resolution,  
Ensures that the project follows established processes and practices. Includes audits and corrective actions. 
Independent testing and evaluation of software against requirements and performance criteria. Applicable to certain categories of projects. Includes planning, execution of tests and tracking issues and risks to closure.   
Includes determining of software is considered safety-critical, and implementing additional requirements to ensure safety of the software product. 

Evaluation of software requirements and planning for their realization in the final software products. 

Experience confirms that the quality and longevity of a software-reliant system is primarily determined by its architecture. The software architecture underpins a system’s software design and code; it represents the earliest design decisions, ones that are difficult and costly to change later. The transformation of the derived and allocated requirements into the software architecture results in the basis for all software development work.

Software design is the process of defining the software architecture, components, modules, interfaces, and data for a software system to satisfy specified requirements. The software architecture is the fundamental organization of a system embodied in its components, their relationships to each other and the environment, and the principles guiding its design and evolution. The software architectural design is concerned with creating a strong overall structure for software entities that fulfill the allocated system and software-level requirements. Typical views captured in an architectural design include the decomposition of the software subsystem into design entities, computer software configuration items, definitions of external and internal interfaces, dependency relationships among entities and system resources, and finite state machines. The design should be further refined into lower-level entities that permit the implementation by coding in a programming language. Typical attributes that are documented for lower-level entities include the identifier, type, purpose, function, constraints, subordinates, dependencies, interface, resources, processing, and data. Rigorous specification languages, graphical representations, and related tools have been developed to support the evaluation of critical properties at the design level. Projects are encouraged to take advantage of these improved design techniques to prevent and eliminate errors as early in the life cycle as possible. Software, developed or purchased, has additional requirements to comply with from Section 508 of the Rehabilitation Act, as defined in NPR 2800.2.

Software implementation consists of implementing the requirements and design into code, data, and records. Software implementation also consists of following coding methods and standards. Unit testing is also usually a part of software implementation (unit testing can also be conducted during the testing phase).

Includes integration of modules into a final deliverable package and testing of that package to determine if it is ready for delivery. 

The purpose of testing is to verify the software functionality and remove defects. Testing verifies the code against the requirements and the design to ensure that the requirements are implemented. Testing also identifies problems and defects that are corrected and tracked to closure before product delivery. Testing also validates that the software operates appropriately in the intended environment. Please note for Class A software there are additional software test requirements and software integration requirements as defined in NPR 8705.2.

  • Acceptance and Release
Final determination of the readiness of the software for release. Includes acceptance testing, and other readiness criteria. 
  • Maintenance

Addresses any ongoing maintenance considerations for the software products. 

Planning for operations, maintenance, and retirement are typically considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement.

  • Operations

Addresses any ongoing operations considerations for the software products

Planning for operations, maintenance, and retirement are typically considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement.

  • Retirement

Addresses any retirement or replacement considerations for the software products

Planning for operations, maintenance, and retirement are typically considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement.

Includes control over software products during development along with any associated work products. 

Software Configuration Management (SCM) is the process of applying configuration management throughout the software life cycle to ensure the completeness and correctness of software configuration items. SCM applies technical and administrative direction and surveillance to identify and record the functional and physical characteristics of software configuration items, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. SCM establishes and maintains the integrity of the products of a software project throughout the software life cycle. Use of standard Center or organizational SCM processes and procedures is encouraged where applicable.

Planning, monitoring and controlling risks which could impact the software products. 

Record, analyze, plan, track, control, and communicate all of the software risks and mitigation plans.

Identification and tracking of non-conforming products and software. Includes ensuring that defects are removed or fixed. 

  • Project Closeout

Includes the closing of projects and dispositioning work products that may need to be used in subsequent projects related to the software products. 

Planning for operations, maintenance, and retirement are typically considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement.

4. Distribution of SWEs

This tab contains a distribution of SWEs into Activities. Each SWE in the SWEHBVD is in the table. The table lists the Primary Activity in which the SWE is located. Also, for those SWEs that are associated with other activities, the associated activities are listed. This table will be used to distribute the SWEs into activities ensuring that none are lost in the distribution process. 


SWENPR paraPrimary ActivityAssociated Activity
SWE-002 - Software Engineering Initiative2.1.1.1Process Definition
[SWE-004 - OCE Benchmarking]2.1.1.2Benchmarking and Appraisals
[SWE-152 - Review Requirements Mapping Matrices]2.1.1.3Requirement Mapping and Tailoring
[SWE-129 - OCE NPR Appraisals]2.1.1.4Benchmarking and Appraisals
SWE-100 - Software Training Funding]2.1.1.5Training
  • Life Cycle Planning
SWE-098 - Agency Process Asset Library]2.1.1.6Process Library
SWE-208 - Advancing Software Assurance and Software Safety Practices]2.1.2.2Process Definition
SWE-209 - Benchmarking Software Assurance and Software Safety Capabilities]2.1.2.3Benchmarking and Appraisals
SWE-212 - NASA-STD-8739 Mapping Matrices]2.1.2.4Requirement Mapping and Tailoring
SWE-221 - OSMA NPR Appraisals]2.1.2.5Benchmarking and Appraisals
SWE-222 - Software Assurance Training]2.1.2.6Training
SWE-223 - Tailoring IV&V project selections]2.1.2.7Requirement Mapping and Tailoring
SWE-003 - Center Improvement Plans]2.1.5.2Process Definition
SWE-005 - Software Processes]2.1.5.3Process Definition
SWE-140 - Comply with Requirements]2.1.5.4Requirement Mapping and Tailoring
SWE-095 - Report Engineering Discipline Status]2.1.5.5Process Definition
SWE-006 - Center Software Inventory]2.1.5.6Process Definition
SWE-091 - Establish and Maintain Measurement Repository]2.1.5.7Measurements and Metrics
SWE-092 - Using Measurement Data]2.1.5.8Measurements and Metrics
SWE-142 - Software Cost Repositories]2.1.5.10Measurements and Metrics
SWE-144 - Software Engineering Process Assets]2.1.5.11Process Library
SWE-153 - ETA Define Document Content]2.1.5.12Process Library
SWE-215 - Software License Rights]2.1.5.13Licensing, Sharing and Reuse
SWE-216 - Internal Software Sharing List]2.1.5.14Licensing, Sharing and Reuse
SWE-217 - List of All Contributors and Disclaimer Notice]2.1.5.15Licensing, Sharing and Reuse
SWE-214 - Internal Software Sharing and Reuse]2.1.5.16Licensing, Sharing and Reuse
SWE-218 - Contracting Officers]2.1.7Licensing, Sharing and Reuse
SWE-126 - Tailoring Considerations]2.1.8.2Requirement Mapping and Tailoring
SWE-150 - Review Changes To Tailored Requirements]2.2.7Requirement Mapping and Tailoring
SWE-021 - Transition to a Higher Class]2.2.8Requirement Mapping and Tailoring
SWE-033 - Acquisition vs. Development Assessment]3.1.2AcquisitionLife Cycle Planning
SWE-013 - Software Plans]3.1.3Life Cycle Planning
SWE-024 - Plan Tracking]3.1.4Monitor and ControlLife Cycle Planning
SWE-034 - Acceptance Criteria]3.1.5

Acceptance and Release

Life Cycle Planning
SWE-036 - Software Process Determination]3.1.6Life Cycle Planning
SWE-037 - Software Milestones]3.1.7Life Cycle Planning
SWE-039 - Software Supplier Insight]3.1.8Acquisition
SWE-040 - Access to Software Products]3.1.9Life Cycle Planning
SWE-042 - Source Code Electronic Access]3.1.10Life Cycle Planning
SWE-139 - Shall Statements]3.1.11Requirement Mapping and TailoringLife Cycle Planning
SWE-121 - Document Tailored Requirements]3.1.12Life Cycle Planning
SWE-125 - Requirements Compliance Matrix]3.1.13Life Cycle Planning
SWE-027 - Use of Commercial, Government, and Legacy Software]3.1.14Life Cycle Planning
SWE-015 - Cost Estimation]3.2.1Software Cost Estimation
SWE-151 - Cost Estimate Conditions]3.2.2Software Cost Estimation
SWE-174 - Software Planning Parameters]3.2.3Software Cost Estimation
SWE-016 - Software Schedule]3.3.1Software Schedules
SWE-018 - Software Activities Review]3.3.2Software Schedules
SWE-046 - Supplier Software Schedule]3.3.3Software Schedules
SWE-017 - Project and Software Training]3.4.1Training
  • Life Cycle Planning
SWE-020 - Software Classification]3.5.1Requirement Mapping, Tailoring, and Classification
SWE-176 - Software Records]3.5.2Requirement Mapping, Tailoring, and Classification
SWE-022 - Software Assurance]3.6.1Software Assurance
SWE-141 - Software Independent Verification and Validation]3.6.2IV&V 
SWE-131 - Independent Verification and Validation Project Execution Plan]3.6.3IV&V 
SWE-178 - IV&V Artifacts]3.6.4IV&V 
SWE-179 - IV&V Submitted Issues and Risks]3.6.5IV&V 
SWE-205 - Determination of Safety-Critical Software]3.7.1Safety-Critical Software
SWE-023 - Software Safety-Critical Requirements]3.7.2Safety-Critical Software
SWE-134 - Safety Critical Software Design Requirements]3.7.3Safety-Critical Software
SWE-219 - Test Coverage for Safety Critical Software Components]3.7.4Safety-Critical Software
SWE-220 - Cyclomatic Complexity Values for Safety Critical Software]3.7.5Safety-Critical Software
SWE-146 - Auto-generated Source Code]3.8.1Automatic Generation of Software Source Code
SWE-206 - Auto-Generation Software Inputs]3.8.2Automatic Generation of Software Source Code
SWE-032 - CMMI Levels for Class A and B Software]3.9.2Benchmarking and Appraisals
SWE-147 - Specify Reusability Requirements]3.10.1Licensing, Sharing and Reuse
SWE-148 - Contribute to Agency Software Catalog]3.10.2Licensing, Sharing and Reuse
SWE-156 - Evaluate Systems for Security Risks]3.11.2Software Cybersecurity
SWE-154 - Identify Security Risks]3.11.3Software Cybersecurity
SWE-157 - Protect Against Unauthorized Access]3.11.4Software Cybersecurity
SWE-159 - Verify and Validate Risk Mitigations]3.11.5Software Cybersecurity
SWE-207 - Secure Coding Practices]3.11.6Software Cybersecurity
SWE-185 - Secure Coding Standards Verification]3.11.7 Software Cybersecurity
SWE-210 - Detection of Adversarial Actions]3.11.8Software Cybersecurity
SWE-052 - Bidirectional Traceability]3.12.1Software Requirements 
SWE-050 - Software Requirements]4.1.2Software Requirements 
SWE-051 - Software Requirements Analysis]4.1.3Software Requirements 
SWE-184 - Software-related Constraints and Assumptions]4.1.4Software Requirements 
SWE-053 - Manage Requirements Changes]4.1.5Software Requirements 
SWE-054 - Corrective Action for Inconsistencies]4.1.6Software Requirements 
SWE-055 - Requirements Validation]4.1.7Software Requirements 
SWE-057 - Software Architecture]4.2.3Software Architecture
SWE-143 - Software Architecture Review]4.2.4Software Architecture
SWE-058 - Detailed Design]4.3.2Software Design
SWE-060 - Coding Software]4.4.2Software Implementation
SWE-061 - Coding Standards]4.4.3Software Implementation
SWE-135 - Static Analysis]4.4.4Software Implementation
SWE-062 - Unit Test]4.4.5Software Implementation
SWE-186 - Unit Test Repeatability]4.4.6Software Implementation
SWE-063 - Release Version Description]4.4.7Software Implementation
SWE-136 - Software Tool Accreditation]4.4.8Software Implementation
SWE-065 - Test Plan, Procedures, Reports]4.5.2Software Testing
SWE-066 - Perform Testing]4.5.3Software Testing
SWE-187 -Control of Software Items]4.5.4Software Testing
SWE-068 - Evaluate Test Results]4.5.5Software Testing
SWE-070 - Models, Simulations, Tools]4.5.6Software Testing
SWE-071 - Update Test Plans and Procedures]4.5.7Software Testing
SWE-073 - Platform or Hi-Fidelity Simulations]4.5.8Software Testing
SWE-189 - Code Coverage Measurements]4.5.9Software Testing
SWE-190 - Verify Code Coverage]4.5.10Software Testing
SWE-191 - Software Regression Testing]4.5.11Software Testing
SWE-192 - Software Hazardous Requirements]4.5.12Software Testing
SWE-193 - Acceptance Testing for Affected System and Software Behavior]4.5.13Software Testing
SWE-211 - Test Levels of Non-Custom Developed Software]4.5.14Software Testing
SWE-075 - Plan Operations, Maintenance, Retirement]4.6.2Life Cycle Planning
SWE-077 - Deliver Software Products]4.6.3Acceptance and Release
SWE-194 - Delivery Requirements Verification]4.6.4Acceptance and Release
SWE-195 - Software Maintenance Phase]4.6.5Maintenance
SWE-196 - Software Retirement Archival]4.6.6Retirement
SWE-079 - Develop CM Plan]5.1.2Software Configuration Management 
SWE-080 - Track and Evaluate Changes]5.1.3Software Configuration Management 
SWE-081 - Identify Software CM Items]5.1.4Software Configuration Management 
SWE-082 - Authorizing Changes]5.1.5Software Configuration Management 
SWE-083 - Status Accounting]5.1.6Software Configuration Management 
SWE-084 - Configuration Audits]5.1.7Software Configuration Management 
SWE-085 - Release Management]5.1.8Software Configuration Management 
SWE-045 - Project Participation in Audits]5.1.9Software Configuration Management 
SWE-086 - Continuous Risk Management]5.2Software Risk Management
SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures]5.3.2Software Peer Reviews and Inspections
SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking]5.3.3Software Peer Reviews and Inspections
SWE-089 - Software Peer Reviews and Inspections - Basic Measurements]5.3.4Software Peer Reviews and Inspections
SWE-090 - Management and Technical Measurements]5.4.2Measurements and Metrics
SWE-093 - Analysis of Measurement Data]5.4.3Measurements and Metrics
SWE-094 - Reporting of Measurement Analysis]5.4.4Measurements and Metrics
SWE-199 - Performance Measures]5.4.5Measurements and Metrics
SWE-200 - Software Requirements Volatility Metrics]5.4.6Measurements and Metrics
SWE-201 - Software Non-Conformances]5.5.1Software Non-conformance or Defect Management
SWE-202 - Software Severity Levels]5.5.2Software Non-conformance or Defect Management
[SWE-203 - Mandatory Assessments for Non-Conformances]5.5.3Software Non-conformance or Defect Management
[SWE-204 - Process Assessments]5.5.4Software Non-conformance or Defect Management