bannerd

A. Introduction

B. Institutional Requirements

C. Project Software Requirements

D. Topics

E. Tools, References, and Terms

F. SPAN
(NASA Only)

Versions Compared

Old Version 7

changes.mady.by.user Haigh, Fred

Saved on

compared with

New Version Current

changes.mady.by.user Haigh, Fred

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

UNDER CONSTRUCTION


Note

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. 

Tabsetup
01. Introduction
12. Make, Buy, ReuseDefining the Activity
23. Code Generation
34. Reuse
45. Coding
56. Unit Test
67. Integration
Software Assurance

2. Make / Buy / Reuse

This is one of the early decisions that must be made early in a project. Once the product requirements are settled, at least at a high level, the project team must decide how the code will be obtained. 

  • Making code is always attractive among talented coders who are excited to create code from scratch. The advantage of this is that the code is highly customized and may be fixed using the project team's talent. This presumes that these talented individuals will always be available to do additional development and fix problems. 
  • Buying code is attractive for smaller project teams where the coding talent is not readily available. Third party coders may solve problems with talent availability but this code my be carefully monitored to ensure it performs as required. 
  • Reusing code may provide an attractive starting point for many project teams. It can be used to jumpstart a development effort when large portions of the reused code is adapted to the new needs. If the reused code is not up to current standards, it can be a challenge to cleanup to the projects needs and standards. 

2.1 Related NPR 7150.2 SWEs

2.2 Related Topics and Process Assets

Div
idtabs-1

1. Introduction

Note

This section includes a brief introduction of what coding is.

In the "Related Activities" in the list, comments explain how this activity is affected by each of the other activities. 

Software coding activities occur at the throughout the project. They may include prototyping and development of some throw-away code to experiment with approaches. The final code must be carefully produced and traced to prevent unforeseen problems from occurring after release.   

A project may be for the creation of a new product, or the enhancement of an existing product. It may even involve the merging of capabilities from multiple products into a new, more capable product.

Coding includes the creation of code, unit testing, and integration testing to form a complete usable product. 

The activities on this page include links to pages in the SWEHB that cover requirements from NPR 7150.2 as well as related Topics on techniques and Process Assets that may be used to help you in your project. 

1.1 Related Activities

  • SE-Initiation and Planning - Coding activities are planned. They are dependent on a whole host of other project activities.  
  • SE-Estimation - Estimates are made and tracked for coding activities. Coding must be measured and controlled. 
  • SE-Schedules - Coding Activities are scheduled and tracked to completion. Code is a deliverable what must fit into the timeline of other products and missions.  
  • SE-Training - Coders are trained in coding methods, the use of coding tools, and related subjects. 
  • SE-Scope Management - Requirements, defect management, change management, Non-conformance and Defect Management. Coding must be closely tied to requirements to avoid wasting time building something that is not wanted.
  • SE-Architecture and Design - Code lives and operates within the architecture. It interfaces with humans and other equipment. 
  • SE-Testing - including V&V
  • SE-Operations, Maintenance and Retirement
  • SE-Configuration Mgmt - including builds and releases
  • Peer Reviews - including code reviews
  • Measurements - related to coding
Div
idtabs-2
Div
idtabs-3

3. Automatic Code Generation

Defining the approach to be used for the automatic generation of software source code allows projects to review and verify their plans for the use and management of auto-generated software before implementation to ensure the development approach and the resulting software will meet the expectations and goals of the project without introducing unacceptable levels of risk. 

Auto-generated software is the result of translating a model of the system behavior into different software languages through the use of a code generator. It is important to capture the approach used for the automatic generation of software because issues can exist with auto-generated software and projects need to be prepared to address them.

Model-based software development uses a model as the centerpiece of the development process. Software engineers create a model of the system behavior that can then be translated into different languages such as C or Ada by the appropriate code generator. The model is continually refined throughout the development process and can even be executable. For maximum benefit, the generated code should not be modified by software engineers; when changes are desired, the model is revised, and code is generated from the revised model.

3.1 Related NPR 7150.2 SWEs

3.8 Automatic Generation of Software Source Code

SWE-146 - Auto-generated Source Code 
SWE-206 - Auto-Generation Software Inputs

3.2 Related Topics and Process Assets

8.11 - Auto-Generated Code - 

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. 

Panel
borderColorblue
titleNPR 7150.2B 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.

Panel
borderColorblack
borderWidth2
titleInputs, 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

Note

List of some of the inputs from other activities that are necessary for the activity to begin. 

Examples: 

  • Planning - Peer Reviews are planned activities. They appear in the plans and schedules for the project
  • Requirements - These are the things that are Peer Reviewed
  • Architecture Items - These are the things that are Peer Reviewed
  • Design items - These are the things that are Peer Reviewed
  • Test Plans and Procedures - These are the things that are Peer Reviewed

1.2 Predecessor Activities

Note

List of some of the other activities that must be started (not necessarily completed) so that this activity may begin. 

Examples: 

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

  • Life Cycle Planning - plans, schedules, estimates, etc.
  • Software Architecture 
  • Software Design
  • Software Testing - plans and procedures

1.3 Outputs

Note

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. 

Examples: 


The activities that initiated the Peer Review, receive the findings from Peer Reviews, Those activities then use those findings to to fix defects and implement improvements uncovered in the reviews. 

Output Work ProductUsed by Downstream Activity
  • Peer Review Findings
  • Life Cycle Planning
  • Software Architecture 
  • Software Design
  • Software Testing
  • Configuration Management
  • Coding


1.4 Successor Activities

Note

Links to Activities which might be started or supported by this activity. 


1.5 Activity Repetition

Note

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

Note

Add links to SPAN activity pages that are appropriate for this activity. Use links from the Activity section of the front page. 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). 


Div
idtabs-2

2. Defining the Activity

Note

This tab contains the links to pages in the SWEHB that are at the heart of the activity. 

2.1 SWEs

Note

This section contains the links to SWE pages that form the heart of the activity. 

  • Link to the SWE goes here
    • Excerpt include for the SWE goes here (Remove Surrounding Panel)

2.2 Topics and other Supporting Materials

Note

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. 

  • Link to the Topic or page goes here
    • Excerpt include for the Topic or page goes here (Remove Surrounding Panel)

2.3 Other Associated SWEs, Topics, etc.

Note

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. 

  • Include page for the PAT page goes here


4. Software Reuse

Software systems are often designed using existing components from other systems. It is recognized that reusing existing software components can help achieve the resulting system more quickly and at a lower cost. However, for software components to be truly reusable, reusability needs to be part of the planned initial development of those components.

With the focus on software reuse increasing, projects need to plan for future reuse of developed software by specifying requirements that facilitate software reuse in the future.  These requirements enhance the benefits of reuse and address the known pitfalls of reuse where that is possible.  These requirements, which should be captured as early in the life cycle as possible, address development processes as well as project technical requirements and are captured in project documentation such as the software development/management plan for processes, project coding standards, and the requirements document or repository for technical requirements.  The software reuse-related requirements are included as a part of the normal software requirements review process and verification & validation process.

Reusing software can have many benefits for the Agency, including, but not limited to, cost savings.  For this reason, software project managers consider future reuse of software components created for their projects and make those selected components available to future projects through an Agency repository. When evaluating software for potential reuse, remember to consider single components as well as entire software products.

4.1 Related NPR 7150.2 SWEs

3.10 Software Reuse

SWE-147 - Specify Reusability Requirements
SWE-148 - Contribute to Agency
                   Software Catalog

4.2 Related Topics and Process Assets

5. Coding

5.1 Related NPR 7150.2 SWEs

SWE-060 - Coding Software
SWE-061 - Coding Standards
SWE-135 - Static Analysis

4.2 Related Topics and Process Assets

6. Unit Test

6.1 Related NPR 7150.2 SWEs

SWE-062 - Unit Test
SWE-186 - Unit Test Repeatability

6.2 Related Topics and Process Assets

Div
idtabs-3

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

Software Assurance Tasks are included in many of the SWEs in this activity. 

Note

For each of the SWEs in this activity (see tab 2 .1 SWEs) populate the table below with the SWE, Requirement, and SA Tasks.

  • The first column is for the SWE number
  • The second column is for the requirement - using the Excerpt Include macro to pull in the Excerpt from the SWE page (excerpt includes the text of the requirement)
  • The third column is for the SA Tasks using the Include Page macro - Each of the SA Tasks for a SWE are child pages under SITE:NASA-STD-8739.8B page 

SWE-034 is used below only as an example of how to populate the table. The example below, using SWE-034, should be replaced by the actual SWEs in this activity. 

SWERequirementSA Tasks

034

Excerpt Include
SWEHBVD:SWE-034 - Acceptance Criteria
SWEHBVD:SWE-034 - Acceptance Criteria
nopaneltrue

Include Page
SWE-034 - SA Task1
SWE-034 - SA Task1

Div
idtabs-4
Div
idtabs-5
Div
idtabs-6
Div
idtabs-7

7.  Integration

Integration is the assembly of discrete code components into a deliverable product that can be installed and used as a finished product. Code is typically used to monitor and control some other machine or device.

The deliverable product of coding must be tested in an environment that replicates the environment in which it will operate in service. See SE-Testing. 

 A software version description document (VDD) is used to identify and record the exact version of software to be delivered to a user, support, or other sites. 

Software development tools contain software defects.  Commercial software development tools do have software errors.  Validation and accreditation of the critical software development and maintenance tools ensure that the tools being used during the software development life cycle do not generate or insert errors in the software executable components.  This requirement reduces the risk in the software development and maintenance areas of the software life cycle by assessing the tools against defined validation and accreditation criteria.  The likelihood that work products will function properly is enhanced and the risk of error is reduced if the tools used in the development and maintenance processes have been validated and accredited themselves. This is particularly important for flight software (Classes A and B) which must work correctly with its first use if critical mishaps are to be avoided.

7.1 Related NPR 7150.2 SWEs

SWE-063 - Release Version Description
SWE-136 - Software Tool Accreditation

7.2 Related Topics and Process Assets

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
______________________________________________________________________________