bannerd

A. Introduction

B. Institutional Requirements

C. Project Software Requirements

D. Topics

E. Tools, References, and Terms

F. SPAN
(NASA Only)

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 50 Next »

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. 

Activity - Software Design - Combined

1. Introduction


NPR 7150.2B para 4.3.1

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.

Inputs, Outputs, and Predecessor Activities

Activity graphical representation of Inputs, Outputs, Predecessor and Successor Activities as appropriate. Not meant to be exhaustive, but representative of a typical project. 

1.1 Inputs

Examples: 

1.2 Predecessor Activities

Examples: 

Predecessor Activities are performed before Design. These activities produce the work products that will be reviewed. 

1.3 Outputs


Output Work ProductUsed by Downstream Activity
  • Implementation and Unit Testing
  • Preliminary at Preliminary Design Review
  • Baselined at Critical Design Review
  • Updated at Test Readiness Review
  • Implementation and Unit Testing
  • Preliminary at Preliminary Design Review
  • Baselined at Critical Design Review
  • Updated at Test Readiness Review
  • Implementation and Unit Testing
  • Baselined at Operational Readiness Review

1.4 Successor Activities

  • Implementation and Unit Testing - Implements the Design into one or more code modules. 
  • Preliminary Design Review
  • Critical Design Review
  • Test Readiness Review
  • Operational Readiness Review

1.5 Activity Repetition

  • Design is always done once. It should be peer reviewed and analyzed by Software Assurance. 
  • Design 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 design
    • Customer changes to requirements require changes to the design

1.6 Center Resources From SPAN

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

ActivityDescription

Design

Assets for use during product design

2. Software Engineering

2.1 SWEs

SWE-058 - Detailed Design with new tab 4

Link to SWE-058 - Copy of SWE-058 - Detailed Design with new tab 4

Class Applicability: A B C

SWE-058 Requirement

4.3.2 The project manager shall develop, record, and maintain a software design based on the software architectural design that describes the lower-level units so that they can be coded, compiled, and tested.

Tasking

  1. Assess Design Readiness - including suggested checklist items for preparing for a Preliminary Design Review (PDR)
  2. Establish Coding Standards and Processes
  3. Establish Project Specific Design Considerations
  4. Establish Detailed Design Documentation and Progress Reviews
  5. Establish Design Maintenance Processes and Mechanisms

Work Products

  1. SwDD - Software Design Description 
  2. IDD - Interface Design Description
  3. SUM - Software User Manual

Other SWE-058 Relevant Work Products

  1. What is to be performed and produced in each phase of the design process (see SDP-SMP) 
  2. List of design components including when they are expected to be available - as input to Development Schedule
  3. List of methods, tools, standards, and guidelines for your project (see SWE-061)
  4. Applicable and efficient design methods being implemented on your project
  5. Well-documented software development process (see SWE-036)
  6. Systems Requirements Specification (see SRS)
  7. Developers trained and experienced in the chosen development process and methods (see SWE-017)
  8. Software reuse being considered throughout the development effort (see SWE-027)
  9. Off-the-shelf software being considered for use on the project (see SWE-027)
  10. Analysis of alternatives 
  11. Selection of architecture and design methods based on system operational characteristics
  12. Characteristics of all data elements identified (type, format, size, units, and others important to the project) (see SDD)
  13. Configuration control process (see SCMP)
  14. CASE tools being used to assist and document the design effort (see SWE-136)
  15. Requirements traceable to design elements (see SWE-052)
  16. Design elements traceable to specific requirements


2.2 Topics and other Supporting Materials

2.2.1 Topics

SWE-058 Relevant Topics 

2.2.2 Supporting Materials

SWE-058 Supporting Materials

2.3 Other Associated SWEs, Topics, etc.


3. Software Assurance

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. 

SWE-058 - Detailed Design with new tab 4

Link to SWE-058 - Copy of SWE-058 - Detailed Design with new tab 4

SWE-058 Requirement

4.3.2 The project manager shall develop, record, and maintain a software design based on the software architectural design that describes the lower-level units so that they can be coded, compiled, and tested.

Tasking From NASA-STD-8739.8B

1. Assess the software design against the hardware and software requirements and identify any gaps.

2. Assess the software design to verify that the design is consistent with the software architectural design concepts and that the software design describes the lower-level units to be coded, compiled, and tested. 

3. Assess that the design does not introduce undesirable behaviors or unnecessary capabilities.

4. Confirm that the software design implements all of the required safety-critical functions and requirements. 

5. Perform a software assurance design analysis.

SA Work Products

  1.  Software Design Analysis
  2.  Results of software assurance design analysis, including assessments in Tasks 1, 2, and 3. 
  3.  List of any identified design risks and issues.


3.2 Topics and Other Supporting Materials

3.2.1 Topics

  • SWE-034 - Acceptance Criteria
    • 1. Confirm software acceptance criteria are defined and assess the criteria based on guidance in the NASA Software Engineering Handbook, NASA-HDBK-2203.
  • SWE-134 - Safety-Critical Software Design Requirements
    • 1. Analyze the software requirements and the software design and work with the project to implement NPR 7150.2 requirement items "a" through "l."
    • 4. Analyze the software design to ensure the following:
         a. Use of partitioning or isolation methods in the
               design and code,
         b. That the design logically isolates the safety-critical
               design elements and data from those that are
               non-safety-critical.
    • 5. Participate in software reviews affecting safety-critical software products.
    • 6. Ensure the SWE-134 implementation supports and is consistent with the system hazard analysis.
  • SWE-057 - Software Architecture
    • 1. Assess that the software architecture addresses or contains the software structure, qualities, interfaces, and external/internal components.
    • 2. Analyze the software architecture to assess whether software safety and mission assurance requirements are met.
  • SWE-143 - Software Architecture Review
    • 1. Assess the results of or participate in software architecture review activities held by the project.
  • SWE-080 - Track and Evaluate Changes
    • 1. Analyze proposed software and hardware changes to software products for impacts, particularly safety and security.
  • SWE-081 - Identify Software CM Items
    • 2. Assess that the software safety-critical items are configuration-managed, including hazard reports and safety analysis.
  • SWE-203 - Mandatory Assessments for Non-Conformances
    • 2. Assess the impact of non-conformances on the project software's safety, quality, and reliability.

3.2.2 Process Asset Templates

Unable to render {include} The included page could not be found.

3.3 Other Associated SWEs, Topics, etc.





  • No labels

0 Comments

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