UNDER CONSTRUCTION
Notes in this template provide guidance to authors on how the section if to be completed. Once the section is populated, the Note may be deleted. Notes are not intended to be left in the completed page.
View this section on the website
See edit history of this section
Post feedback on this section
1. Introduction
Typically starts with a quote from the NPR that helps define the activity. Additional descriptive material is meant to help define the activity but not be so detailed that it pulls in all of the guidance from the SWEs in the activity.
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 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.
Activity graphical representation of Inputs, Outputs, Predecessor and Successor Activities as appropriate. Not meant to be exhaustive, but representative of a typical project.
Diagram here →
1.1 Inputs
List of some of the inputs from other activities that are necessary for the activity to begin.
Examples:
- bullet list of input documents (links to doc contents pages if applicable)
1.2 Predecessor Activities
List of some of the other activities that must be started (not necessarily completed) so that this activity may begin.
Examples:
- bullet list of links to other activities
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.
| Output Work Product | Used by Downstream Activity |
|---|---|
1.4 Successor Activities
Links to Activities which might be started or supported by this activity.
Examples:
- bullet list of activities (links)
- Reviews
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
- ACTIVITY is always done once. Ideally it will be peer reviewed and analyzed by Software Assurance.
- ACTIVITY may be reviewed and re-analyzed as often as there are significant changes in architecture or requirements. For example,
- Technology changes to the architecture requires changes to the ACTIVITY
- Customer changes to requirements require changes to the ACTIVITY
1.6 Center Resources From SPAN
Leave links to SPAN activity pages that are appropriate for this activity. Links from the Activity section of the front page of SPAN. All of the links to SPAN activities are provided. Delete the ones that do not apply.
Several Centers Process Asset Libraries have materials related to this activity. Related Processes, templates, and other resources may be found in the following Activities in SPAN (available to NASA only).
| Activity | Description |
| Project Planning | Project planning and scheduling assets |
| Process Selection | Selecting processes using the Compliance Matrix |
| Classification | Classification of Software Process |
| Estimation | Estimation processes and related assets |
| Project Monitoring and Control | Monitoring and control assets |
| Risk Management | Risk Management assets |
| Closure | Assets used when closing a project |
| Requirements | Assets for recording and tracking requirements and change control |
| Design | Assets for use during product design |
| Code and Integration | Coding and software integration assets |
| Peer Review | Review processes and follow up activities |
| Verification and Validation | Verification and Validation assets |
| Release, Sustain and Retire | Assets used during product release, Sustaining activities, and Retirement |
| Configuration Management | Configuration management and change control assets |
| Metrics | Metrics assets |
| Decision Making | Decision making processes and templates |
| Improvement | Process Improvement activities including SEPG |
| Software Quality Assurance | Software Quality Assurance and Audit assets |
| Safety | Safety |
| Purchasing | Assets used in purchasing software |
| Contracting | Assets used when contracting software development |
| Training | General Training |
2. 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. For each SWE, the related tasks from tab 4 are listed.
SWE TITLE in h4 style
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.
2.2.1 Topics
2.2.2 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. Software Assurance Activity
Software Assurance is integral to the performance of all Software Development activities. It includes Process Monitoring as well as Process Analysis.
Process Monitoring - addresses the question, "Is the development team following their processes and producing the expected work products?"
Process Analysis - addresses the question, "Are there better ways of performing the processes that would result in the early discovery of defects?"
3.1 Software Assurance Tasks from SWEs
Software Assurance Tasks are included in tab 7 of the SWEs in this activity.
SWE-999 Title
3.2 Topics and Other Supporting Materials
3.2.1 Topics
TITLE/LINK for each Topics
- EXCERPT
- Other details from Topic as appropriate - Tasking
3.2.2 Process Asset Templates
TITLE/LINK for PAT table category
- Include Page of the category
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.
