bannerd

A. Introduction

B. Institutional Requirements

C. Project Software Requirements

D. Topics

E. Tools, References, and Terms

F. SPAN
(NASA Only)

UNDER CONSTRUCTION

Life Cycle Planning

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. 

NPR 7150.2B 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.


1.1 Inputs

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

  • Documents and orders that initiate the Planning Activity
  • High level requirements that define the scope of the software product
  • Time and budget constraints that further define the scope of the project

1.2 Predecessor Activities

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

The predecessor activities include planning, architecture and design activities from other projects and systems where the concept for the software product is defined. Examples include: 

  • New, or changed, hardware system that requires new software to monitor or control it.

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. 

Outputs from Planning include a variety of documents, plans, and other work products that are used by downstream activities

Output Work ProductUsed by Downstream ActivitySupporting SWE or Topic
  • Project Plan
  • Monitor and Control
  • Software Requirements
  • Software Architecture
  • Software Design

1.4 Successor Activities

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

  • Monitor and Control
  • Software Requirements
  • Software Architecture
  • Software Design

1.5 Repetition

Describe what conditions determine if the activity needs to be repeated.

  • How much of the activity needs to be repeated
  • Frequency of repetition

Life Cycle Planning is done in the early stages of a Software Project. Other work may be started before the planning is actually completed. 

During the life of the project there may be multiple times when significant changes to things like requirements, budget, schedule, technology, which make re-planning necessary. Re-planning is covers the same areas of the original planning to make sure that all changes are accounted for in the new plans. Re-planning is done as often as necessary to keep the project under control. 


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


2. Defining the Activity

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

Life Cycle Planning is a large activity that impacts the whole of the project. The SWEs listed below are included in the NPR 7150.2 under 3.1 Software Life Cycle Planning. 

  • Determinations are made regarding whether the software should be developed using related, existing software, secured by a separate acquisition from another supplier, or built from scratch. In some cases it may be a combination of all these approaches. 
  • Project plans are developed to account for all aspects of the development of the software. 
  • Plans for tracking the progress of the development project are put into place for use in the Monitor and Control activity. 
  • Acceptance Criteria are reviewed and made a part of the plan. These will be used together with Requirements to ensure that the right software is developed and delivered. 
  • The processes to be used in the development effort are selected and coordinated with the Requirement Mapping and Tailoring activity. 
  • Milestones are determined and planned into the project. These are coordinated in the Software Scheduling activity. 
  • Access to developed components is planned for and coordinated with the Configuration Management activity among others. 
  • Software Requirements are 

2.1 SWEs

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

SWEs from NPR 7150.2D section 3.1 Software Life Cycle Planning

  • SWE-033 - Acquisition vs. Development Assessment
    • 3.1.2 The project manager shall assess options for software acquisition versus development.
  • SWE-013 - Software Plans
    • 3.1.3 The project manager shall develop, maintain, and execute software plans, including security plans, that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring.
  • SWE-024 - Plan Tracking - Also see Monitor and Control activity
    • 3.1.4 The project manager shall track the actual results and performance of software activities against the software plans.
        1. Corrective actions are taken, recorded, and managed to closure.
        2. Changes to commitments (e.g., software plans) that have been agreed to by the affected groups and individuals are taken, recorded, and managed.
  • SWE-034 - Acceptance Criteria
    • 3.1.5 The project manager shall define and document the acceptance criteria for the software. 
  • SWE-036 - Software Process Determination
    • 3.1.6 The project manager shall establish and maintain the software processes, software documentation plans, list of developed electronic products, deliverables, and list of tasks for the software development that are required for the project’s software developers, as well as the action required (e.g., approval, review) of the Government upon receipt of each of the deliverables.
  • SWE-037 - Software Milestones
    • 3.1.7 The project manager shall define and document the milestones at which the software developer(s) progress will be reviewed and audited. 
  • SWE-039 - Software Supplier Insight
    • 3.1.8 The project manager shall require the software developer(s) to periodically report status and provide insight into software development and test activities; at a minimum, the software developer(s) will be required to allow the project manager and software assurance personnel to:
        1. Monitor product integration.
        2. Review the verification activities to ensure adequacy.
        3. Review trade studies and source data.
        4. Audit the software development processes and practices.
        5. Participate in software reviews and technical interchange meetings.
  • SWE-040 - Access to Software Products
    • 3.1.9 The project manager shall require the software developer(s) to provide NASA with software products, traceability, software change tracking information, and non-conformances in electronic format, including software development and management metrics.
  • SWE-042 - Source Code Electronic Access
    • 3.1.10 The project manager shall require the software developer(s) to provide NASA with electronic access to the source code developed for the project in a modifiable format.
  • SWE-139 - Shall Statements
    • 3.1.11 The project manager shall comply with the requirements in this NPR that are marked with an “X” in Appendix C consistent with their software classification.
  • SWE-121 - Document Tailored Requirements
    • 3.1.12 Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and deployment of the affected software.
  • SWE-125 - Requirements Compliance Matrix
    • 3.1.13 Each project manager with software components shall maintain a requirements mapping matrix or multiple requirements mapping matrices against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements. 
  • SWE-027 - Use of Commercial, Government, and Legacy Software
    • 3.1.14 The project manager shall satisfy the following conditions when a COTS, GOTS, MOTS, OSS, or reused software component is acquired or used: 

      a. The requirements to be met by the software component are identified.

      b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions).

      c. Proprietary rights, usage rights, ownership, warranty, licensing rights, transfer rights, and conditions of use (e.g., required copyright, author, and applicable license notices within the software code, or a requirement to redistribute the licensed software only under the same license (e.g., GNU GPL, ver. 3, license)) have been addressed and coordinated with Center Intellectual Property Counsel. 

      d. Future support for the software product is planned and adequate for project needs.

      e. The software component is verified and validated to the same level required to accept a similar developed software component for its intended use.

      f. The project has a plan to perform periodic assessments of vendor reported defects to ensure the defects do not impact the selected software components.

SWEs from NPR 7150.2D section 3.4 Software Training

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


  • No labels
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
______________________________________________________________________________