UNDER CONSTRUCTION

Project Software Activities

In

SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures

, the guidance does not have subsections in it to clearly identify tasks. Many SWEs would have to be updated to contain clear identification of tasks in the guidance.
In SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking

, the guidance needs to be revised to clearly identify the tasks (the current version contains the breakdown but could be more clear in its alignment with the requirement.
In SWE-089 - Software Peer Reviews and Inspections - Basic Measurements , tab 3 could be a little clearer in terms of tasks.

In general, a cleanup like this of the Guidance tabs would give the whole SWEHB a more polished look and make it easier to find things. Tab 7 for SA already looks very clean and functional for the assurance folks. Tabs 1, 5, and 6 in all the SWEs have already had such a make over:

Tab 1 had consistent numbering of subsections implemented when the SWE History section was added.
Tab 5 had some cleanup when the Tools section wording was changed and the PATs added to some SWEs.
Tab 6 was reformatted to account for NASA and NON-NASA Lessons Learned.

Software Non-conformance or Defect Management

Tabsetup

0	1. Introduction
1	2. Institutional Activities
2	3. Activities
3	4. Distribution of SWEsSWEHB Pages
4	5. Activity Page Structure
5	6. Alternative Activity Styles
6	7. Other Considerations

2. Institutional Activities

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

Management activities are typically conducted by those in leadership roles. Supervisors, managers and team leads are involved to varying degrees. Some activities even involve Support, Assurance and Safety roles. Interactions are explained in the activities.

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.

Process Definition

Requirement Mapping and Tailoring

Measurements and Metrics

Benchmarking and Appraisals

Training

Process Library

Licensing, Sharing and Reuse

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.

Institutional Activities

Div

id	tabs-1

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.

1.1 Activity Concept

Currently the SWEHB is a collection of pages:

SWEs - Requirements from NPR 7150.2D along with Rationale, Guidance, Small Projects, Resources, Lessons Learned and Software Assurance, if applicable
Topics - Additional guidance for appropriate for some SWEs
PATs - Process Asset Templates - derived from SWEs and Topics
Other pages - such as Document Contents, FAQs, etc.

Pages include links to other pages based on the relevance of the content on those pages.

The notion of Activity is a natural way to bring together pages from the existing SWEHB into a collection of pages that have a common purpose, an Activity.

Image Added

1.2 Activity Sequence

Software Engineering activities are conducted in a predictable sequence. This sequence may be a once through or "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 The activities associated with Software Engineering 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.

Image Removed

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.

Div

id	tabs-2

Excerpt Include

SWE-002 - Software Engineering Initiative

Excerpt Include

SWE-208 - Advancing Software Assurance and Software Safety Practices

Excerpt Include

SWE-003 - Center Improvement Plans

Excerpt Include

SWE-005 - Software Processes

Excerpt Include

SWE-095 - Report Engineering Discipline Status

Excerpt Include

SWE-006 - Center Software Inventory

Excerpt Include

SWE-152 - Review Requirements Mapping Matrices

Excerpt Include

SWE-212 - NASA-STD-8739 Mapping Matrices

Excerpt Include

SWE-223 - Tailoring IV&V project selections

Excerpt Include

SWE-140 - Comply with Requirements

Excerpt Include

SWE-126 - Tailoring Considerations

Excerpt Include

SWE-150 - Review Changes To Tailored Requirements

Excerpt Include

SWE-021 - Transition to a Higher Class

Excerpt Include

SWE-091 - Establish and Maintain Measurement Repository

Excerpt Include

SWE-092 - Using Measurement Data

Excerpt Include

SWE-142 - Software Cost Repositories

Excerpt Include

SWE-004 - OCE Benchmarking

Excerpt Include

SWE-129 - OCE NPR Appraisals

Excerpt Include

SWE-221 - OSMA NPR Appraisals

Excerpt Include

SWE-209 - Benchmarking Software Assurance and Software Safety Capabilities

Excerpt Include

SWE-032 - CMMI Levels for Class A and B Software

Excerpt Include

SWE-100 - Software Training Funding

Excerpt Include

SWE-222 - Software Assurance Training

Excerpt Include

SWE-098 - Agency Process Asset Library

Excerpt Include

SWE-144 - Software Engineering Process Assets

Excerpt Include

SWE-153 - ETA Define Document Content

Excerpt Include

SWE-215 - Software License Rights

Excerpt Include

SWE-216 - Internal Software Sharing List

Excerpt Include

SWE-217 - List of All Contributors and Disclaimer Notice

Excerpt Include

SWE-214 - Internal Software Sharing and Reuse

Excerpt Include

SWE-218 - Contracting Officers

Excerpt Include

SWE-147 - Specify Reusability Requirements

Excerpt Include

SWE-148 - Contribute to Agency Software Catalog

Div

id	tabs-3

Activity Name

Activity Components

Benchmarking and Appraisals

OCE and SMA benchmarking and determining the capability and maturity of software development groups. Benchmarking techniques derived from CMMI best practices.

Training

Training at all levels from Agency (engineering practices and related training) down to project needs (training for personnel on using development tools).

Process Definition

Development of repeatable processes and practices for OCE, SMA and Center development activities.

Requirement Mapping, Tailoring and Classification

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

The diagram below is a visual representation of the activities in a project. Participation by groups such as Institutional Support and Center Support span the whole of the project. the smaller activity boxes represent things that go on for shorter periods of time and as part of a logical sequence. For example, Requirements, Architecture and Design would come before Implementation and Unit Testing. Some activities take place multiple times over the life of a project and occur as needed such as Configuration Management and Peer Reviews. Finally, certain Reviews occur during the life of the project and they are represented at the bottom of the diagram. A timeline is not fixed to this diagram because it varies to suit the needs of the project. The positioning of activities is notional and is, in many cases, repeating. This repetition is accounted for in the project schedule and its updates.

Image Added

1.3 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.

1.4 What Activities ARE and ARE NOT

Activities bring together SWEHB materials that have something in common. In doing this, the activity page brings together links to pages that contain valuable information and guidance about the business of the activity. Activities represent a way of organizing work to make sure that it is performed in a way to ensure the best results. That means, satisfying requirements and achieving mission goals.

It is NOT:

a list of things that you MUST do - all of the things in an activity such as tasks and work products are suggestions. They are meant to be representative of how you might accomplish the requirements of NPR 7150.2 and the guidance in the Software Engineering Handbook.
a set of templates and forms that must be filled out -
extra things that you must do IN ADDITION to the work in your project (requirements, and mission objectives)

Div

id	tabs-2

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 (from NPR 7150.2D chapter 2) ensuring that higher levels of management establish certain means and infrastructure for projects to use in their projects. In some cases, requirements for Project teams are included describing the use of the management provided 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. Many of the names for these Activities come directly from NPR 7150.2D. In a few cases, the names are changed to better express the full scope of the Activity.

Activity Name

Activity Components

Benchmarking and Appraisals

OCE and SMA benchmarking and determining the capability and maturity of software development groups. Benchmarking techniques derived from CMMI best practices.

Training

Training at all levels from Agency (engineering practices and related training) down to project needs (training for personnel on using development tools).

Process Definition

Development of repeatable processes and practices for OCE, SMA and Center development activities.

Requirement Mapping, Tailoring and Classification

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.

Measurements and Metrics

Suggested measurements and practices for software projects.

Panel

borderColor	blue
title	NPR 7150.2D para 5.4.1

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.

Process Library

Panel

title	NPR 7150.2D para 2.1.1.6

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

Licensing, Sharing and Reuse

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

Div

id	tabs-3

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 Software 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 Name

Activity Components

Life Cycle Planning

Panel

borderColor	blue
title	NPR 7150.2D para 3.1.1

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.

Activity - Software Peer Reviews and Inspections

Panel

borderColor	blue
title	NPR 7150.2D para 5.3.1

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.

Acquisition

Used when software is acquired or secured from outside sources.

Project Monitor and Control

Used for monitoring progress and keeping the project under control through minor adjustments

Software Cost Estimation

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.

Software Schedules

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,

Software Assurance Planning

Ensures that the project follows established processes and practices. Includes audits and corrective actions.

IV&V

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.

Old Activity Ideas

Includes determining of software is considered safety-critical, and implementing additional requirements to ensure safety of the software product.

Software Cybersecurity

Software Requirements

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

Software Architecture

Panel

borderColor	blue
title	NPR 7150.2D para 4.2.1

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

Panel

borderColor	blue
title	NPR 7150.2D para 4.3.1

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 and unit testing

Panel

borderColor	blue
title	NPR 7150.2D para 4.4.1

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).

Software Integration and Testing

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

Panel

borderColor	blue
title	NPR 7150.2D para 4.5.1

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.

Panel

borderColor	blue
title	NPR 7150.2D para 4.6.1

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

Panel

borderColor	blue
title	NPR 7150.2D para 4.6.1

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

Panel

borderColor	blue
title	NPR 7150.2D para 4.6.1

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.

Software Configuration Management

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

Panel

borderColor	blue
title	NPR 7150.2D para 5.1.1

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.

Software Risk Management

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

Panel

borderColor	blue
title	NPR 7150.2D para 5.2

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

Software Non-Conformance of Defect Management

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.

Panel

borderColor	blue
title	NPR 7150.2D para 4.6.1

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.

3.2 Software Assurance Activities

Panel

borderColor	blue
title	NASA-STD-8739.8B Para 4.1

Include Page

	8739.8B Para 4.1
	8739.8B Para 4.1

Many of the activities of Software Assurance run parallel to Software Development Activities. In fact, development activities that have specific SA participation have a tab in the SWE specifically for Software Assurance participation.

To further this relationship, the activities below draw on the SA requirements and tasks from NASA-STD-8739.8B and are associated with the SWEs in NPR 7150.2D.

Activity Name	Activity Components
Software Assurance Planning	Planning of Software Assurance activities in a Software Development Project are done in a collaborative fashion along with the Software Development team. It includes cost estimates and schedules.
SA Auditing	Software Assurance tasks found in Development Activities which audit the processes and work products associated with individual SWEs.
SA SW Requirements Analysis	Software Assurance Analysis tasks in Software Requirements and related activities which further improve the quality of the Software Requirements. Reducing requirement ambiguity, defects, and associated re-work in the of the software.
SA Design Analysis	Software Assurance Analysis tasks in Software Design and related activities which further improve the quality of the Software Design. Reducing defects and associated re-work in the design of the software.
SA SW Source Code Analysis	Software Assurance Analysis tasks in Software Source Code and related activities which further improve the quality of the Software Source Code. Reducing defects and associated re-work in the of the software.
SA SW Testing	Software Assurance Analysis tasks in Software Testing and related activities which further improve the quality of the Software Testing. Improving test coverage, reducing test defects and associated re-work in the of the software.
SA Reporting	Software Assurance Analysis tasks in Software Reporting and related activities which further improve the overall Software Development Processes. Improving the Development Processes reduces defects and associated re-work in the of the software.
IV&V	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.
SA Safety and Hazard Analysis
SA Test Witnessing

Div

id	tabs-4

4. Distribution of SWEHB pages

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.

Under Construction in separate spreadsheet. This table will be updated periodically as the spreadsheet is completed.

4.1 SWE pages

SWE	NPR para	Primary Activity	Associated Activity
SWE-002 - Software Engineering Initiative	2.1.1.1	Process Definition
SWE-004 - OCE Benchmarking	2.1.1.2	Benchmarking and Appraisals
SWE-152 - Review Requirements Mapping Matrices	2.1.1.3	Requirement Mapping, Tailoring, and Classification
SWE-129 - OCE NPR Appraisals	2.1.1.4	Benchmarking and Appraisals
SWE-100 - Software Training Funding	2.1.1.5	Training	Life Cycle Training
SWE-098 - Agency Process Asset Library	2.1.1.6	Process Library
SWE-208 - Advancing Software Assurance and Software Safety Practices	2.1.2.2	Process Definition
SWE-209 - Benchmarking Software Assurance and Software Safety Capabilities	2.1.2.3	Benchmarking and Appraisals
SWE-212 - NASA-STD-8739 Mapping Matrices	2.1.2.4	Requirement Mapping, Tailoring, and Classification
SWE-221 - OSMA NPR Appraisals	2.1.2.5	Benchmarking and Appraisals
SWE-222 - Software Assurance Training	2.1.2.6	Training	Life Cycle Training
SWE-223 - Tailoring IV&V project selections	2.1.2.7	Requirement Mapping, Tailoring, and Classification
SWE-003 - Center Improvement Plans	2.1.5.2	Process Definition
SWE-005 - Software Processes	2.1.5.3	Process Definition
SWE-140 - Comply with Requirements	2.1.5.4	Requirement Mapping, Tailoring, and Classification
SWE-095 - Report Engineering Discipline Status	2.1.5.5	Process Definition
SWE-006 - Center Software Inventory	2.1.5.6	Process Definition
SWE-091 - Establish and Maintain Measurement Repository	2.1.5.7	Measurements and Metrics
SWE-092 - Using Measurement Data	2.1.5.8	Measurements and Metrics
SWE-142 - Software Cost Repositories	2.1.5.10	Measurements and Metrics
SWE-144 - Software Engineering Process Assets	2.1.5.11	Process Library
SWE-153 - ETA Define Document Content	2.1.5.12	Process Library
SWE-215 - Software License Rights	2.1.5.13	Licensing, Sharing and Reuse
SWE-216 - Internal Software Sharing List	2.1.5.14	Licensing, Sharing and Reuse
SWE-217 - List of All Contributors and Disclaimer Notice	2.1.5.15	Licensing, Sharing and Reuse
SWE-214 - Internal Software Sharing and Reuse	2.1.5.16	Licensing, Sharing and Reuse
SWE-218 - Contracting Officers	2.1.7	Licensing, Sharing and Reuse
SWE-126 - Tailoring Considerations	2.1.8.2	Requirement Mapping, Tailoring, and Classification
SWE-150 - Review Changes To Tailored Requirements	2.2.7	Requirement Mapping, Tailoring, and Classification
SWE-021 - Transition to a Higher Class	2.2.8	Requirement Mapping, Tailoring, and Classification
SWE-033 - Acquisition vs. Development Assessment	3.1.2	Acquisition	Life Cycle Planning Software Assurance Planning SA Reporting
SWE-013 - Software Plans	3.1.3	Life Cycle Planning	SA Planning SA Auditing
SWE-024 - Plan Tracking	3.1.4	Monitor and Control	Life Cycle Planning Software Assurance Planning SA Reporting SA Auditing
SWE-034 - Acceptance Criteria	3.1.5	Acceptance and Release	Life Cycle Planning Software Assurance Planning SA Design Analysis SA SW Source Code Analysis SA Reporting
SWE-036 - Software Process Determination	3.1.6	Life Cycle Planning	Software Assurance Planning
SWE-037 - Software Milestones	3.1.7	Life Cycle Planning	Software Assurance Planning SA Reporting
SWE-039 - Software Supplier Insight	3.1.8	Acquisition	Life Cycle Planning Software Assurance Planning SA Auditing
SWE-040 - Access to Software Products	3.1.9	Life Cycle Planning	Software Assurance Planning
SWE-042 - Source Code Electronic Access	3.1.10	Life Cycle Planning	Software Assurance Planning
SWE-139 - Shall Statements	3.1.11	Requirement Mapping, Tailoring, and Classification	Life Cycle Planning SA Planning SA Reporting SA Auditing
SWE-121 - Document Tailored Requirements	3.1.12	Life Cycle Planning	SA Planning
SWE-125 - Requirements Compliance Matrix	3.1.13	Life Cycle Planning	SA Planning
SWE-027 - Use of Commercial, Government, and Legacy Software	3.1.14	Life Cycle Planning	Software Assurance Planning
SWE-015 - Cost Estimation	3.2.1	Software Cost Estimation	Software Assurance Planning
SWE-151 - Cost Estimate Conditions	3.2.2	Software Cost Estimation	SA Planning SA Reporting
SWE-174 - Software Planning Parameters	3.2.3	Software Cost Estimation
SWE-016 - Software Schedule	3.3.1	Software Schedules	SA Planning SA Reporting SA Auditing
SWE-018 - Software Activities Review	3.3.2	Software Schedules
SWE-046 - Supplier Software Schedule	3.3.3	Software Schedules	SA Planning
SWE-017 - Project and Software Training	3.4.1	Training	Life Cycle Planning
SWE-020 - Software Classification	3.5.1	Requirement Mapping, Tailoring, and Classification	SA Planning
SWE-176 - Software Records	3.5.2	Requirement Mapping, Tailoring, and Classification
SWE-022 - Software Assurance	3.6.1	Software Assurance
SWE-141 - Software Independent Verification and Validation	3.6.2	IV&V
SWE-131 - Independent Verification and Validation Project Execution Plan	3.6.3	IV&V
SWE-178 - IV&V Artifacts	3.6.4	IV&V
SWE-179 - IV&V Submitted Issues and Risks	3.6.5	IV&V
SWE-205 - Determination of Safety-Critical Software	3.7.1	Safety-Critical Software	SA Reporting
SWE-023 - Software Safety-Critical Requirements	3.7.2	Safety-Critical Software
SWE-134 - Safety-Critical Software Design Requirements	3.7.3	Safety-Critical Software	SA Design Analysis SA SW Requirements Analysis SA SW Source Code Analysis SA Reporting
SWE-219 - Code Coverage for Safety Critical Software	3.7.4	Safety-Critical Software
SWE-220 - Cyclomatic Complexity for Safety-Critical Software	3.7.5	Safety-Critical Software
SWE-146 - Auto-generated Source Code	3.8.1	Implementation and Unit Testing	SA Reporting
SWE-206 - Auto-Generation Software Inputs	3.8.2	Implementation and Unit Testing	Acquisition
SWE-032 - CMMI Levels for Class A and B Software	3.9.2	Benchmarking and Appraisals	SA Reporting SA Auditing
SWE-147 - Specify Reusability Requirements	3.10.1	Licensing, Sharing and Reuse
SWE-148 - Contribute to Agency Software Catalog	3.10.2	Licensing, Sharing and Reuse
SWE-156 - Evaluate Systems for Security Risks	3.11.2	Software Cybersecurity
SWE-154 - Identify Security Risks	3.11.3	Software Cybersecurity
SWE-157 - Protect Against Unauthorized Access	3.11.4	Software Cybersecurity
SWE-159 - Verify and Validate Risk Mitigations	3.11.5	Software Cybersecurity	SA SW Source Code Analysis
SWE-207 - Secure Coding Practices	3.11.6	Software Cybersecurity	SA SW Source Code Analysis
SWE-185 - Secure Coding Standards Verification	3.11.7	Software Cybersecurity
SWE-210 - Detection of Adversarial Actions	3.11.8	Software Cybersecurity	SA SW Requirements Analysis
SWE-052 - Bidirectional Traceability	3.12.1	Software Requirements	SA SW Requirements Analysis
SWE-050 - Software Requirements	4.1.2	Software Requirements
SWE-051 - Software Requirements Analysis	4.1.3	Software Requirements	SA SW Requirements Analysis
SWE-184 - Software-related Constraints and Assumptions	4.1.4	Software Requirements	SA SW Requirements Analysis
SWE-053 - Manage Requirements Changes	4.1.5	Software Requirements
SWE-054 - Corrective Action for Inconsistencies	4.1.6	Software Requirements	SA Reporting
SWE-055 - Requirements Validation	4.1.7	Software Requirements
SWE-057 - Software Architecture	4.2.3	Software Architecture	SA Design Analysis
SWE-143 - Software Architecture Review	4.2.4	Software Architecture	SA Reporting
SWE-058 - Detailed Design	4.3.2	Software Design	SA Design Analysis
SWE-060 - Coding Software	4.4.2	Software Implementation
SWE-061 - Coding Standards	4.4.3	Software Implementation	SA SW Source Code Analysis
SWE-135 - Static Analysis	4.4.4	Software Implementation	SA SW Source Code Analysis
SWE-062 - Unit Test	4.4.5	Software Implementation
SWE-186 - Unit Test Repeatability	4.4.6	Software Implementation
SWE-063 - Release Version Description	4.4.7	Software Implementation
SWE-136 - Software Tool Accreditation	4.4.8	Software Implementation
SWE-065 - Test Plan, Procedures, Reports	4.5.2	Software Testing
SWE-066 - Perform Testing	4.5.3	Software Testing
SWE-187 -Control of Software Items	4.5.4	Software Testing
SWE-068 - Evaluate Test Results	4.5.5	Software Testing
SWE-070 - Models, Simulations, Tools	4.5.6	Software Testing
SWE-071 - Update Test Plans and Procedures	4.5.7	Software Testing
SWE-073 - Platform or Hi-Fidelity Simulations	4.5.8	Software Testing
SWE-189 - Code Coverage Measurements	4.5.9	Software Testing
SWE-190 - Verify Code Coverage	4.5.10	Software Testing
SWE-191 - Software Regression Testing	4.5.11	Software Testing	SA Reporting
SWE-192 - Software Hazardous Requirements	4.5.12	Software Testing
SWE-193 - Acceptance Testing for Affected System and Software Behavior	4.5.13	Software Testing
SWE-211 - Test Levels of Non-Custom Developed Software	4.5.14	Software Testing
SWE-075 - Plan Operations, Maintenance, Retirement	4.6.2	Operations	SA Reporting
SWE-077 - Deliver Software Products	4.6.3	Acceptance and Release	SA Auditing
SWE-194 - Delivery Requirements Verification	4.6.4	Acceptance and Release
SWE-195 - Software Maintenance Phase	4.6.5	Maintenance	SA Auditing
SWE-196 - Software Retirement Archival	4.6.6	Retirement
SWE-079 - Develop CM Plan	5.1.2	Software Configuration Management	SA Reporting SA Auditing
SWE-080 - Track and Evaluate Changes	5.1.3	Software Configuration Management	SA Design Analysis SA SW Requirements Analysis SA SW Source Code Analysis
SWE-081 - Identify Software CM Items	5.1.4	Software Configuration Management	SA Design Analysis SA SW Requirements Analysis SA SW Source Code Analysis SA Reporting
SWE-082 - Authorizing Changes	5.1.5	Software Configuration Management
SWE-083 - Status Accounting	5.1.6	Software Configuration Management
SWE-084 - Configuration Audits	5.1.7	Software Configuration Management	SA Auditing
SWE-085 - Release Management	5.1.8	Software Configuration Management	SA Auditing
SWE-045 - Project Participation in Audits	5.1.9	Software Configuration Management	SA Reporting SA Auditing
SWE-086 - Continuous Risk Management	5.2	Software Risk Management	SA Reporting SA Auditing
SWE-087 - Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures	5.3.2	Software Peer Reviews and Inspections	SA SW Requirements Analysis
SWE-088 - Software Peer Reviews and Inspections - Checklist Criteria and Tracking	5.3.3	Software Peer Reviews and Inspections	SA Auditing
SWE-089 - Software Peer Reviews and Inspections - Basic Measurements	5.3.4	Software Peer Reviews and Inspections
SWE-090 - Management and Technical Measurements	5.4.2	Measurements and Metrics	SA Reporting
SWE-093 - Analysis of Measurement Data	5.4.3	Measurements and Metrics	SA Reporting
SWE-094 - Reporting of Measurement Analysis	5.4.4	Measurements and Metrics
SWE-199 - Performance Measures	5.4.5	Measurements and Metrics	SA Reporting
SWE-200 - Software Requirements Volatility Metrics	5.4.6	Software Measurements	SA Reporting
SWE-201 - Software Non-Conformances	5.5.1	Software Non-conformance or Defect Management
SWE-202 - Software Severity Levels	5.5.2	Software Non-conformance or Defect Management	SA Reporting
SWE-203 - Mandatory Assessments for Non-Conformances	5.5.3	Software Non-conformance or Defect Management	SA Design Analysis SA SW Requirements Analysis SA SW Source Code Analysis
SWE-204 - Process Assessments	5.5.4	Software Non-conformance or Defect Management	SA Reporting

4.2 Topic Pages

Includes Recommended Content pages from some of the topic pages.

Topic #	Activity	Associated Activities
6.1 - Design for Safety Checklist	SA Safety and Hazard Analysis
6.2 - Checklist for General Software Safety Requirements	SA Safety and Hazard Analysis
6.3 - Checklist for Choosing a Real Time Operating System (RTOS)	Implementation and Unit Testing	Licensing, Sharing and Reuse Software Design
6.4 - Checklist for Choosing Off-The Shelf Software (OTS)	Implementation and Unit Testing	Licensing, Sharing and Reuse Software Design
6.5 - Checklist for C Programming Practices	Implementation and Unit Testing
6.6 - Checklist for C++ Programming Practices	Implementation and Unit Testing
6.7 - Checklist for Ada Programming Practices	Implementation and Unit Testing
6.8 - Checklist for Fortran Programming Practices	Implementation and Unit Testing
6.9 - Checklist for Generic (Non-Language-Specific) Programming Practices	Implementation and Unit Testing
6.10 - Checklist for General Good Programming Practices	Implementation and Unit Testing
6.11 - Examples of Programming Practices for Exception Handling	Implementation and Unit Testing
7.1 - History and Overview of the Software Process Improvement (SPI) Effort	Process Definition
7.2 - Classification and Safety-Criticality	Requirement Mapping, Tailoring, and Classification
7.3 - Acquisition Guidance	Acquisition
7.4 - Flowdown of NPR Requirements on Contracts and to Other Centers in Multi-Center Projects	Life Cycle Planning	- Acquisition - Requirement Mapping, Tailoring, and Classification
7.5 - Work Breakdown Structures That Include Software	Software Scheduling	Cost Estimation
7.6 - Software Test Estimation and Testing Levels	Software Scheduling	- Cost Estimation - Implementation and Unit Testing - Integration and Testing
7.7 - Software Architecture Description	Software Architecture
7.8 - Maturity of Life-Cycle Products at Milestone Reviews	Software Scheduling	Life Cycle Planning
7.9 - Entrance and Exit Criteria	Software Scheduling	Life Cycle Planning
7.10 - Peer Review and Inspections Including Checklists	Peer Reviews and Inspections
7.11 - SWE History	n/a
7.12 - Retired	n/a
7.13 - Transitioning to a Higher Class	Requirement Mapping, Tailoring, and Classification
7.14 - Implementing Measurement Requirements and Analysis for Projects	Measurements and Metrics
7.15 - Relationship Between NPR 7150.2 and NASA-STD-7009	Software Architecture	- Software Design -Integration and Testing
7.16 - Appendix C. Requirements Mapping and Compliance Matrix	Requirement Mapping, Tailoring, and Classification
7.17 - 7150.2C Appendices (Definitions, References, etc.)	n/a
7.18 - Documentation Guidance	n/a
CR-PR - Software Change Request - Problem Report	Non-Conformance and Defect Management
IDD - Interface Design Description	Software Architecture	Software Design
Inspect - Software Inspection, Peer Reviews, Inspections	Peer Reviews and Inspections
Maint - Software Maintenance Plan	Maintenance
Metrics - Software Metrics Report	Measurements and Metrics
SCMP - Software Configuration Management Plan	Configuration Management
SDD - Software Data Dictionary	Software Design
SDP-SMP - Software Development - Management Plan	Life Cycle Planning
SRS - Software Requirements Specification	Software Requirements
STP - Software Test Plan	Integration and Testing
STR - Software Test Report	Integration and Testing
SUM - Software User Manual	Operations	Acceptance and Release
SwDD - Software Design Description	Software Design
Test - Software Test Procedures	Integration and Testing
Train - Software Training Plan	Training
VDD - Version Description Document	Acceptance and Release
7.19 - Software Risk Management Checklists	Risk Management
7.20 - Assessing - Meets the Intent	Risk Management
7.21 - Multi-condition Software Requirements	Integration and Testing	Safety-Critical Software
8.1 - Off Nonimal Testing	SA SW Testing Analysis	SA SW Testing Analysis
8.2 - Software Reliability	SA SW Testing Analysis
8.3 - Organizational Goals of Software Assurance Metrics	Measurements and Metrics
8.4 - Additional Requirements Considerations for Use with Safety-Critical Software	SA Safety and Hazard Analysis
8.5 - SW Failure Modes and Effects Analysis	SA SW Requirements Analysis	SA Safety and Hazard Analysis
8.6 - IV&V Surveillance	IV&V	Acquisition
8.7 - Software Fault Tree Analysis	SA Safety and Hazard Analysis
8.8 - COTS Software Safety Considerations	SA Safety and Hazard Analysis
8.9 - Software Safety Analysis	SA Safety and Hazard Analysis
8.10 - Facility Software Safety Considerations	SA Safety and Hazard Analysis
8.11 - Auto-Generated Code	Implementation and Unit Testing
8.12 - Basics of Software Auditing	SA Auditing
8.13 Test Witnessing	SA SW Testing Analysis	SA Auditing
8.14 SA Tasking for NPR 7150.2B	?
8.15 - SA Tasking Checklist Tool	?
8.16 - SA Products	n/a
Audit Reports	SA Reporting
Checklists and Guidance Lists	n/a
IV&V Program Execution Plan	SA Planning	IV&V
Objective Evidence	All SA Activities
Software Assurance Plan	SA Planning
Software Assurance Status Reports	SA Reporting
Software Design Analysis	SA Design Analysis
Software Requirements Analysis	SA SW Requirements Analysis
Software Safety and Hazard Analysis	SA Safety and Hazard Analysis
Source Code Quality Analysis	SA SW Source Code Analysis
Testing Analysis	SA SW Testing Analysis
8.17 - Software Safety Audit Checklists	SA Auditing
8.18 - SA Suggested Metrics	Measurements and Metrics
8.19 - Dead / Dormant Code and Safety Critical Software	Licensing, Sharing and Reuse	- SA Safety and Hazard Analysis - Software Design
8.20 - Safety Specific Activities in Each Phase	SA Safety and Hazard Analysis
8.21 - Software Hazard Causes	SA Safety and Hazard Analysis
8.22 - Hazardous Commands	SA Safety and Hazard Analysis
8.23 - Software Contents of a Certification of Flight Readiness	Acceptance and Release
Software Design Principles	Software Design	SA Design Analysis
Software Safety and Design Principles	SA Design Analysis	Software Design
Coding Standards	Software Design	SA Design Analysis
Command Receipt Acknowledgement	Software Design	SA Design Analysis
Data Interface Integrity	Software Design	SA Design Analysis
Dead Code Exclusion	Software Design	SA Design Analysis
Fault Detection and Response	Software Design	SA Design Analysis
Flight Software Modification	Software Design	SA Design Analysis
Incorrect Memory Use or Access	Software Design	SA Design Analysis
Initialization - Safe Mode	Software Design	SA Design Analysis
Invalid Data Handling	Software Design	SA Design Analysis
Resource Margins	Software Design	SA Design Analysis
Resource Oversubscription	Software Design	SA Design Analysis
Resource Usage Measurement	Software Design	SA Design Analysis
Safe Transitions	Software Design	SA Design Analysis
Thread Safety	Software Design	SA Design Analysis

4.3 PAT Pages

PAT #	Activity	Associated Activities
PAT-001 - FCA Checklist	Software Configuration Management
PAT-002 - PCA Checklist	Software Configuration Management
PAT-003 - Functional Requirements Checklist	Peer Reviews and Inspections	SA SW Requirements Analysis
PAT-004 - Safety Requirements Analysis Checklist	SA SW Requirements Analysis
PAT-005 - Software Component Design Analysis Checklist	SA Design Analysis
PAT-006 - Design Practices for Safety	SA Design Analysis	SA Safety and Hazard Analysis
PAT-007 - Checklist for General Software Safety Requirements	SA Safety and Hazard Analysis
PAT-008 - Safety Considerations for Design Peer Reviews Checklist	SA Safety and Hazard Analysis	Peer Reviews and Inspections
PAT-009 - Software Safety Process Audit	SA Safety and Hazard Analysis
PAT-010 - Software Safety Activities for Internal Audit	SA Safety and Hazard Analysis
PAT-011 - ISO 27001-2013 Audit Checklist
PAT-012 - Detection of Adversarial Actions	Software Cybersecurity
PAT-013 - Software Requirements Checklist	Software Requirements	Peer Reviews and Inspections
PAT-014 - Architecture Design Checklist	Software Architecture	Peer Reviews and Inspections
PAT-015 - Detailed Design Checklist	Software Design	Peer Reviews and Inspections
PAT-016 - Functional Design Checklist	Software Design	Peer Reviews and Inspections
PAT-017 - C Code Inspection Checklist	Integration and Testing	Peer Reviews and Inspections
PAT-018 - Test Plan Checklist	Integration and Testing	- Implementation and Unit Testing - Peer Reviews and Inspections
PAT-019 - Test Procedure Checklist	Integration and Testing	- Implementation and Unit Testing - Peer Reviews and Inspections
PAT-020 - Examples of Interface Problems	SA Design Analysis
PAT-021 - SADESIGN Checklist	SA Design Analysis
PAT-022 - Programming Practices Checklist	Implementation and Unit Testing
PAT-023 - Preparing for a SARB Checklist	Software Architecture	SA Design Analysis
PAT-024 - Checklist for Choosing Off-The Shelf Software	Acquisition
PAT-025 - Checklist for Choosing a Real Time Operating System (RTOS)	Acquisition
PAT-026 - Test Review Checklist For Test Leads	Integration and Testing	SA SW Testing Analysis
PAT-027 - Test Review Checklist For Review Teams	Integration and Testing	SA SW Testing Analysis
PAT-028 - NPR 7150.2D Compliance Matrix	Requirement Mapping, Tailoring, and Classification
PAT-029 - Software Architecture Review Board Checklist	Software Architecture	SA Design Analysis
PAT-030 - SARB Review Checklist with Guidance	Software Architecture	SA Design Analysis

4.4 Other Pages

Warning

Add page/groups from 8739.8B

SA Tasks
IV&V Overview and Requirements
SA Tailoring Standard Requirements

Div

id	tabs-5

5. Activity Page Structure

We will need to decide how to consistently display information about activities. Since we have two groups involved with the Activity pages. There are multiple ways of displaying the information related to an Activity.

5.1 Common Elements in the Activity Structure

Tab	Title	Content
1	Introduction	Brief description of the activity and its scope. If applicable, a quote from the NPR or STD is used to amplify the description.
1.1	Inputs	List of some of the inputs from other activities that are necessary for the activity to begin.
1.2	Predecessor Activities	List of some of the other activities that must be started (not necessarily completed) so that this activity may begin.
1.3	Outputs	List of some of the outputs or work products of the activity. These are typically used as inputs by the downstream activity. In some cases there is a supporting SWE associated with the work product.
1.4	Successor Activities	Links to Activities which might be started or supported by this activity.
1.5	Activity Repetition	Describe what conditions determine if the activity needs to be repeated, such as re-planning after a change in requirements or schedule constraints. How much of the activity needs to be repeated Frequency of repetition
1.6	Center Resources from SPAN	Add links to SPAN activity pages that are appropriate for this activity. Use links from the Activity section of the SPAN front page. SPAN. This further differentiates SWEHB from SPAN in the sense that PATs are templates derived from SWEHB guidance, SPAN assets and templates are Center defined and developed resources.
2	Defining Software Development Activity	This tab contains the links to pages in the SWEHB that are at the heart of the activity.
2.1	SWEs	This section contains the links to SWE pages that form the heart of the activity.
2.2	Topics and other Supporting Materials	This section is for SWEHB pages, other than SWEs, that directly support the activity. This section contains Topics, document content pages, PATs, and other pages. Topics Document Structures Process Asset Templates Other Supporting Materials
2.3	Other Associated SWEs, Topics, etc.	Includes other SWEHB pages that are indirectly associated with the activity. May include SWEs, Topics, document definition pages, PATs, etc. They may have been mentioned in the guidance of another page. This section may be removed if there is no content for it.
3	Defining SA Activity	This tab contains the links to pages in the SWEHB that are at the heart of the activity.
3.1	SWEs	This section contains the links to SWE pages that form the heart of the activity.
3.2	Topics and other Supporting Materials	This section is for SWEHB pages, other than SWEs, that directly support the SA activity. This section contains Topics, document content pages, PATs, and other pages. Topics Document Structures Process Asset Templates Other Supporting Materials
3.3	Other Associated SWEs, Topics, etc.	Includes other SWEHB pages that are indirectly associated with the activity. May include SWEs, Topics, document definition pages, PATs, etc. They may have been mentioned in the guidance of another page. This section may be removed if there is no content for it.

5.1 Combined Format

In the combined format, Activities that are closely related such as Planning may have a combined format. Tab 2 information is associated with both Software Engineering and Software Assurance content. An additional tab is provided to include SA tasks (from the included SWEs) that apply to the activity.

A risk associated with this way of displaying Activity information is that it may be difficult to easily pick out the SA pieces from the Engineering pieces of an activity. It will be critical to specify who is involved in each element of the activity. An example of this can be found in Planning where the Engineering and Assurance elements of the activity run in parallel and have considerable overlap. Engineering will plan certain processes and then Assurance will plan the auditing of those processes.

Image Added

5.2 Separate Formats

In separate formats, there is only one template. The indication of who is performing the activity is indicated in the title of the Activity. In this example, SA activities include the SA Task lists from the associated SWEs. Software Engineering Activities would not have SA Tasks displayed in section 2.1.

Image Added

Div

id	tabs-6

6. Alternative Activity Styles

The Activity is a new concept for organizing content in SWEHB. In this tab, we explore various ways to display activity content while keeping several requirements in mind:

minimize the creation of new content by reusing existing content as much as possible.
minimize training necessary to use the activity, it should be obvious how to use the activity and its information
make the activity inclusive so that Software Developers and Software Assurance and others can use it easily

6.1 Initial Reactions to First Two Templates

At our 12/13/2023 meeting, there was some discussion about the organization and content of the two templates reviewed. It was not clear how these templates would accomplish the inclusivity requirement above. In this tab, we will explore some alternatives to these first two templates to attempt to get an Activity organization that satisfies all of the requirements.

Include Page

	SPA6 Alternative Activity Structure
	SPA6 Alternative Activity Structure

Suggested measurements and practices for software projects.

Div

id	tabs-7

7. Other Considerations For Activities

7.1 Readiness Reviews in Activities

Topic 7.09 - Entrance and Exit Criteria covers a number of reviews that occur at the completion of certain activities.

Should these reviews be accounted for in the activities?
Are they activities by themselves?
Do we need PATS for each of these reviews?
- Could be a single PAT for each review or 3 PATS (Entrance Criteria, Materials for Review, Exit Criteria) for each review.

7.2 Life Cycle Products

Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews covers maturity of certain life cycle work products at the times of readiness reviews. Currently they are mentioned in the Inputs and Outputs sections of activity tab 1.

Should these Work Products be accounted for in the activities in greater depth? Currently I list the docs that are in 7.18. Maybe this should be expanded to cover the docs in NPR 7150.2D, Chapter 6?
Some docs in Chapter 6 are not broken out in 7.18. They exist as sections of the docs (like Software Development Plan). Should these be mentioned in the appropriate activity?

7.3 Software Engineering Products

From NPR 7150.2D, Chapter 6, there are some products in the list that are not in Topic 7.18 Documentation Guidance (Minimum Document Content):

w. Programmer’s/Developer’s Manual

Does this require another Topic?

7.4 Reformatting of Guidance in SWEs

In the Copy of SWE-058 - Detailed Design with new tab 4 the guidance in tab 3 was already formatted into tasks. This permitted the Tasks to be quickly identified in the new tab 4. Also, there were clear references to several documents (SwDD, IDD, and SUM) that made building the Work Products section of the activity easier and clearer. Metrics were adapted from those in tab 7 in the example.

In other SWEs, there may be a need to reformat some things and build out others to get clear tasks, work products, and metrics. For example, the SWEs relating to Peer Reviews need some revisions:

Measurements and Metrics

Panel

borderColor	blue
title	NPR 7150.2D para 5.4.1

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.

Process Library

Panel

title	NPR 7150.2D para 2.1.1.6

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

Licensing, Sharing and Reuse

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

Activity Name

Activity Components

Life Cycle Planning

Panel

borderColor	blue
title	NPR 7150.2D para 3.1.1

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

Panel

borderColor	blue
title	NPR 7150.2D para 5.3.1

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.

Acquisition

Used when software is acquired or secured from outside sources.

Project Monitor and Control

Used for monitoring progress and keeping the project under control through minor adjustments

Software Cost Estimation

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.

Software Schedules

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,

Software Assurance

Ensures that the project follows established processes and practices. Includes audits and corrective actions.

IV&V

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.

Safety Critical Software

Includes determining of software is considered safety-critical, and implementing additional requirements to ensure safety of the software product.

Software Cybersecurity

Software Requirements

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

Software Architecture

Panel

borderColor	blue
title	NPR 7150.2D para 4.2.1

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

Panel

borderColor	blue
title	NPR 7150.2D para 4.3.1

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 and unit testing

Panel

borderColor	blue
title	NPR 7150.2D para 4.4.1

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).

Software Integration and Testing

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

Panel

borderColor	blue
title	NPR 7150.2D para 4.5.1

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.

Panel

borderColor	blue
title	NPR 7150.2D para 4.6.1

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

Panel

borderColor	blue
title	NPR 7150.2D para 4.6.1

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

Panel

borderColor	blue
title	NPR 7150.2D para 4.6.1

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.

Software Configuration Management

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

Panel

borderColor	blue
title	NPR 7150.2D para 5.1.1

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.

Software Risk Management

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

Panel

borderColor	blue
title	NPR 7150.2D para 5.2

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

Software Non-Conformance of Defect Management

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.

Panel

borderColor	blue
title	NPR 7150.2D para 4.6.1

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.

Div

id	tabs-4

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.

SWE

NPR para

Primary Activity

Associated Activity

SWE-002 - Software Engineering Initiative

2.1.1.1

Process Definition

SWE-004 - OCE Benchmarking

2.1.1.2

Benchmarking and Appraisals

SWE-152 - Review Requirements Mapping Matrices

2.1.1.3

Requirement Mapping and Tailoring

SWE-129 - OCE NPR Appraisals

2.1.1.4

Benchmarking and Appraisals

SWE-100 - Software Training Funding

2.1.1.5

Training

SWE-098 - Agency Process Asset Library

2.1.1.6

Process Library

SWE-208 - Advancing Software Assurance and Software Safety Practices

2.1.2.2

Process Definition

SWE-209 - Benchmarking Software Assurance and Software Safety Capabilities

2.1.2.3

Benchmarking and Appraisals

SWE-212 - NASA-STD-8739 Mapping Matrices

2.1.2.4

Requirement Mapping and Tailoring

SWE-221 - OSMA NPR Appraisals

2.1.2.5

Benchmarking and Appraisals

SWE-222 - Software Assurance Training

2.1.2.6

Training

SWE-223 - Tailoring IV&V project selections

2.1.2.7

Requirement Mapping and Tailoring

SWE-003 - Center Improvement Plans

2.1.5.2

Process Definition

SWE-005 - Software Processes

2.1.5.3

Process Definition

SWE-140 - Comply with Requirements

2.1.5.4

Requirement Mapping and Tailoring

SWE-095 - Report Engineering Discipline Status

2.1.5.5

Process Definition

SWE-006 - Center Software Inventory

2.1.5.6

Process Definition

SWE-091 - Establish and Maintain Measurement Repository

2.1.5.7

Measurements and Metrics

SWE-092 - Using Measurement Data

2.1.5.8

Measurements and Metrics

SWE-142 - Software Cost Repositories

2.1.5.10

Measurements and Metrics

SWE-144 - Software Engineering Process Assets

2.1.5.11

Process Library

SWE-153 - ETA Define Document Content

2.1.5.12

Process Library

SWE-215 - Software License Rights

2.1.5.13

Licensing, Sharing and Reuse

SWE-216 - Internal Software Sharing List

2.1.5.14

Licensing, Sharing and Reuse

SWE-217 - List of All Contributors and Disclaimer Notice

2.1.5.15

Licensing, Sharing and Reuse

SWE-214 - Internal Software Sharing and Reuse

2.1.5.16

Licensing, Sharing and Reuse

SWE-218 - Contracting Officers

2.1.7

Licensing, Sharing and Reuse

SWE-126 - Tailoring Considerations

2.1.8.2

Requirement Mapping and Tailoring

SWE-150 - Review Changes To Tailored Requirements

2.2.7

Requirement Mapping and Tailoring

SWE-021 - Transition to a Higher Class

2.2.8

Requirement Mapping and Tailoring

SWE-033 - Acquisition vs. Development Assessment

3.1.2

Acquisition

Life Cycle Planning

SWE-013 - Software Plans

3.1.3

Life Cycle Planning

SWE-024 - Plan Tracking

3.1.4

Monitor and Control

Life Cycle Planning

SWE-034 - Acceptance Criteria

3.1.5

Acceptance and Release

Life Cycle Planning

SWE-036 - Software Process Determination

3.1.6

Life Cycle Planning

SWE-037 - Software Milestones

3.1.7

Life Cycle Planning

SWE-039 - Software Supplier Insight

3.1.8

Acquisition

SWE-040 - Access to Software Products

3.1.9

Life Cycle Planning

SWE-042 - Source Code Electronic Access

3.1.10

Life Cycle Planning

SWE-139 - Shall Statements

3.1.11

Requirement Mapping and Tailoring

Life Cycle Planning

SWE-121 - Document Tailored Requirements

3.1.12

Life Cycle Planning

SWE-125 - Requirements Compliance Matrix

3.1.13

Life Cycle Planning

SWE-027 - Use of Commercial, Government, and Legacy Software

3.1.14

Life Cycle Planning

SWE-015 - Cost Estimation

3.2.1

Software Cost Estimation

SWE-151 - Cost Estimate Conditions

3.2.2

Software Cost Estimation

SWE-174 - Software Planning Parameters

3.2.3

Software Cost Estimation

SWE-016 - Software Schedule

3.3.1

Software Schedules

SWE-018 - Software Activities Review

3.3.2

Software Schedules

SWE-046 - Supplier Software Schedule

3.3.3

Software Schedules

SWE-017 - Project and Software Training

3.4.1

Training

SWE-020 - Software Classification

3.5.1

Software Classification Assessments

SWE-176 - Software Records

3.5.2

Software Classification Assessments

SWE-022 - Software Assurance

3.6.1

Software Assurance

SWE-141 - Software Independent Verification and Validation

3.6.2

IV&V

SWE-131 - Independent Verification and Validation Project Execution Plan

3.6.3

IV&V

SWE-178 - IV&V Artifacts

3.6.4

IV&V

SWE-179 - IV&V Submitted Issues and Risks

3.6.5

IV&V

SWE-205 - Determination of Safety-Critical Software

3.7.1

Safety-Critical Software

SWE-023 - Software Safety-Critical Requirements

3.7.2

Safety-Critical Software

SWE-134 - Safety Critical Software Design Requirements

3.7.3

Safety-Critical Software

SWE-219 - Test Coverage for Safety Critical Software Components

3.7.4

Safety-Critical Software

SWE-220 - Cyclomatic Complexity Values for Safety Critical Software

3.7.5

Safety-Critical Software

SWE-146 - Auto-generated Source Code

3.8.1

Automatic Generation of Software Source Code

SWE-206 - Auto-Generation Software Inputs

3.8.2

Automatic Generation of Software Source Code

SWE-032 - CMMI Levels for Class A and B Software

3.9.2

Benchmarking and Appraisals

SWE-147 - Specify Reusability Requirements

3.10.1

Licensing, Sharing and Reuse

SWE-148 - Contribute to Agency Software Catalog

3.10.2

Licensing, Sharing and Reuse

SWE-156 - Evaluate Systems for Security Risks

3.11.2

Software Cybersecurity

SWE-154 - Identify Security Risks

3.11.3

Software Cybersecurity

SWE-157 - Protect Against Unauthorized Access

3.11.4

Software Cybersecurity

SWE-159 - Verify and Validate Risk Mitigations

3.11.5

Software Cybersecurity

SWE-207 - Secure Coding Practices

3.11.6

Software Cybersecurity

SWE-185 - Secure Coding Standards Verification

3.11.7

Software Cybersecurity

SWE-210 - Detection of Adversarial Actions

3.11.8

Software Cybersecurity

SWE-052 - Bidirectional Traceability

3.12.1

Software Requirements

SWE-050 - Software Requirements

4.1.2

Software Requirements

SWE-051 - Software Requirements Analysis

4.1.3

Software Requirements

SWE-184 - Software-related Constraints and Assumptions

4.1.4

Software Requirements

SWE-053 - Manage Requirements Changes

4.1.5

Software Requirements

SWE-054 - Corrective Action for Inconsistencies

4.1.6

Software Requirements

SWE-055 - Requirements Validation

4.1.7

Software Requirements

SWE-057 - Software Architecture

4.2.3

Software Architecture

SWE-143 - Software Architecture Review

4.2.4

Software Architecture

SWE-058 - Detailed Design

4.3.2

Software Design

SWE-060 - Coding Software

4.4.2

Software Implementation

SWE-061 - Coding Standards

4.4.3

Software Implementation

SWE-135 - Static Analysis

4.4.4

Software Implementation

SWE-062 - Unit Test

4.4.5

Software Implementation

SWE-186 - Unit Test Repeatability

4.4.6

Software Implementation

SWE-063 - Release Version Description

4.4.7

Software Implementation

SWE-136 - Software Tool Accreditation

4.4.8

Software Implementation

SWE-065 - Test Plan, Procedures, Reports

4.5.2

Software Testing

SWE-066 - Perform Testing

4.5.3

Software Testing

SWE-187 -Control of Software Items

4.5.4

Software Testing

SWE-068 - Evaluate Test Results

4.5.5

Software Testing

SWE-070 - Models, Simulations, Tools

4.5.6

Software Testing

SWE-071 - Update Test Plans and Procedures

4.5.7

Software Testing

SWE-073 - Platform or Hi-Fidelity Simulations

4.5.8

Software Testing

SWE-189 - Code Coverage Measurements

4.5.9

Software Testing

SWE-190 - Verify Code Coverage

4.5.10

Software Testing

SWE-191 - Software Regression Testing

4.5.11

Software Testing

SWE-192 - Software Hazardous Requirements

4.5.12

Software Testing

SWE-193 - Acceptance Testing for Affected System and Software Behavior

4.5.13

Software Testing

SWE-211 - Test Levels of Non-Custom Developed Software

4.5.14

Software Testing

SWE-075 - Plan Operations, Maintenance, Retirement

4.6.2

Life Cycle Planning

SWE-077 - Deliver Software Products

4.6.3

Acceptance and Release

SWE-194 - Delivery Requirements Verification

4.6.4

Acceptance and Release

SWE-195 - Software Maintenance Phase

4.6.5

Maintenance

SWE-196 - Software Retirement Archival

4.6.6

Retirement

SWE-079 - Develop CM Plan

5.1.2

Software Configuration Management

SWE-080 - Track and Evaluate Changes

5.1.3

Software Configuration Management

SWE-081 - Identify Software CM Items

5.1.4

Software Configuration Management

SWE-082 - Authorizing Changes

5.1.5

Software Configuration Management

SWE-083 - Status Accounting

5.1.6

Software Configuration Management

SWE-084 - Configuration Audits

5.1.7

Software Configuration Management

SWE-085 - Release Management

5.1.8

Software Configuration Management

SWE-045 - Project Participation in Audits

5.1.9

Software Configuration Management

SWE-086 - Continuous Risk Management

5.2

Software Risk Management

5.3.2

Software Peer Reviews and Inspections

5.3.3

Software Peer Reviews and Inspections

SWE-089 - Software Peer Reviews and Inspections - Basic Measurements

5.3.4

Software Peer Reviews and Inspections

SWE-090 - Management and Technical Measurements

5.4.2

Measurements and Metrics

SWE-093 - Analysis of Measurement Data

5.4.3

Measurements and Metrics

SWE-094 - Reporting of Measurement Analysis

5.4.4

Measurements and Metrics

SWE-199 - Performance Measures

5.4.5

Measurements and Metrics

SWE-200 - Software Requirements Volatility Metrics

5.4.6

Measurements and Metrics

SWE-201 - Software Non-Conformances

5.5.1

Software Non-conformance or Defect Management

SWE-202 - Software Severity Levels

5.5.2

Software Non-conformance or Defect Management

SWE-203 - Mandatory Assessments for Non-Conformances

5.5.3

Software Non-conformance or Defect Management

SWE-204 - Process Assessments

5.5.4

Content

Space Tools

Page History

Versions Compared

Old Version 44

New Version Current

Key

UNDER CONSTRUCTION

1. Introduction

1.1 Activity Concept

1.2 Activity Sequence

1.1 Activity Groupings

2. Institutional Activities

2.1 OCE and OSMA Software Engineering Initiative

Process Definition

Requirement Mapping and Tailoring

Measurements and Metrics

Benchmarking and Appraisals

Training

Process Library

Licensing, Sharing and Reuse

3. Activities

3.1 Activity Pages

Institutional Activities

1.3 Activity Groupings

1.4 What Activities ARE and ARE NOT

2. Institutional Activities

2.1 OCE and OSMA Software Engineering Initiative

3. Activities

3.1 Software Activity Pages

Project Software Activities

3.2 Software Assurance Activities

4. Distribution of SWEHB pages

4.1 SWE pages

4.2 Topic Pages

4.3 PAT Pages

4.4 Other Pages

5. Activity Page Structure

5.1 Common Elements in the Activity Structure

5.1 Combined Format

5.2 Separate Formats

6. Alternative Activity Styles

6.1 Initial Reactions to First Two Templates

7. Other Considerations For Activities

7.1 Readiness Reviews in Activities

7.2 Life Cycle Products

7.3 Software Engineering Products

7.4 Reformatting of Guidance in SWEs

Project Software Activities

4. Distribution of SWEs