bannerd


SWE-036 - Software Process Determination

1. Requirements

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.

1.1 Notes

A list of typical software engineering products or electronic data products used on a software project is contained in Chapter 6 of this directive. The software activities should include plans for software product verification and validation activities, software assurance, methods, environments, and criteria for the project.

1.2 History

SWE-036 - Last used in rev NPR 7150.2D

RevSWE Statement
A

2.5.5 The project shall determine which software processes, activities, and tasks are required for the project.

Difference between A and B

Added to list of required items to be determined by the PM; Added software supplier to the scope.

B

3.12.5 The project manager shall determine which software processes, software documents, electronic products, software activities, and tasks are required for the project and software suppliers.

Difference between B and C

Changed "determine" to "establish and maintain"; Expanded the scope of required items for the project to include software documentation plans, list of developed electronic products, deliverables, and list of tasks for the software development; Added requirement to list the action required of the Government upon receipt of each of the deliverables.

C

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.

Difference between C and DNo change
D

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.



1.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable


2. Rationale

Projects evaluate the environment (e.g., organization, funding, size, personnel) in which they plan to develop software. From this evaluation, they choose an appropriate set of processes, tasks, and activities to develop software that meets their needs. The planning down to the activity and task levels assures that only the appropriate processes are selected from the ones available to the project. Further evaluation of these processes will determine the level of software resources that the project team needs to include in the planning documentation and funding requests.

3. Guidance

3.1 Software Process

The formulation phase in the life cycle includes the selection and execution of planning activities that are necessary for the successful initiation of a project. During this phase of the project, the project team defines customer needs, system-level requirements, make-versus-buy strategies, overall project and software management plans, a work breakdown structure (WBS), software safety assessments, and primary project deliverables and work products, including, but not limited to, software documents and electronic products.

The project develops planning documents to account for the above and for use in managing the software development efforts. The core set of software plans includes: 

The planning may be recorded in a single document or standalone documents, depending on project size and requirements.

The selections of the processes to support and execute the above planning and definition activities typically are based on an analysis of the desired software work products and their characteristics, and on a determination of which activities and tasks are needed to produce these work products. The selected processes must meet the requirements of the NPR 7150.2 082 that apply to the project.

Other SWEs addressing process establishment and maintenance: 

3.2 Process Resources

Projects may find it helpful to review the following sources of listed processes when planning their project implementation:

  • Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook,  and Center PALs that can be used to locate and select processes and activities that apply to software development activities. See section 3.4 Center Process Asset Libraries below. 
  • The processes and best practices described in the Capability Maturity Model Integration for Development (CMMI Institution)The CMMI-Dev describes the applicability of its process areas for developing software work products.
  • NPR 7123.1 041, establishes a core set of common Agency-level technical processes and requirements needed to define, develop, realize, and integrate the quality of the system's products created and acquired for NASA. The set of common processes in the NPR may be supplemented or tailored to achieve specific project requirements.
  • AS9100C 372, which provides a process-based quality management system for aerospace applications. "The application of a system of processes within an organization...can be referred to as the 'process approach'. An advantage of the process approach is the ongoing control that it provides over the linkage between the individual processes within the system of processes, as well as over their combination and interaction." 372

The processes that are selected and/or tailored to apply to the project will be accomplished by the project and software suppliers through the execution of the activities and tasks that compose the process. Specifically, NPR 7123.1, NASA Systems Engineering Processes and Requirements, describes the activity as a set of tasks that describe the technical effort needed to accomplish a process and to help generate the expected outcomes. Software processes are generally reviewed during the software development life cycle, and revised and modified as needed. The appropriate planning and scheduling of these tasks and activities enable the successful execution of the planned processes. The successful placement of the applicable and tailored processes, activities, and tasks on the project development schedule will complete the determination process.

The Agency Software Manager can be used as a resource for requirement confirmation.

3.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.4 Center Process Asset Libraries

SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki  197

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

Small projects may want to use a standard set of processes that have been tailored for their development environment, and type of project. These processes may have been developed by people in the same organization that may have done similar developments.

5. Resources

5.1 References

5.2 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN). 

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN. 

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool.  The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

6.1 NASA Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

  • Flight Software Engineering Lessons. Lessons Learned 2218 572: "The engineering of flight software is a major consideration in establishing JPL project total cost and schedule because every mission requires a significant amount of new software to implement new spacecraft functionality. Constraints to the development and testing of software concurrent to engineering the rest of the flight system have led to flight software errors, including the loss of some missions. The findings of several JPL studies and flight mishap investigations suggest several recommendations for mitigating software engineering risk."

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

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.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Confirm the following are approved, implemented, and updated per requirements:
     a. Software processes, including software assurance,
         software safety, and IV&V processes,
     b. Software documentation plans,
     c. List of developed electronic products, deliverables, and
     d. List of tasks required or needed for the project’s
         software development.

2. Confirm that any required government actions are established and performed upon receipt of deliverables (e.g., approvals, reviews).

7.2 Software Assurance Products

  • The defined software assurance, software safety, and IV&V processes for the activities on the project per the requirements in the Software Assurance and Software Safety Standard (NASA-STD-8739.8.)
  • Any risks or issues discovered are brought to the attention of management


    Objective Evidence

    • Evidence that all confirmations in Task1a, 1b, 1c, 1d, and Task 2, including existence, approvals, reviews, maintenance, and usage of listed items have occurred.

    Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

    • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
    • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
    • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
    • Signatures on SA reviewed or witnessed products or activities, or
    • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
      • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
      • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
    • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

          Note: For full context of the metrics, refer to the Topic 8.18 to see other requirements that contribute to this metric.

  • # of software components (e.g., programs, modules, routines, functions, etc.) planned vs. # released in each build

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

Guidance for the SA tasks

Confirm the following are approved, implemented, and updated (when necessary) per requirements:

  1. Software processes - Confirm that the software development organizations have documented processes for phases of the software development process.  Use the software practices contained in the CMMI model to determine if the development organization's processes meet or exceed the CMMI model practices.  Use the CMMI V2.0 model practices, see https://cmmiinstitute.com for the model practices.
  2. Software documentation plans - review document content against the documentation guidelines contained in 7.18 - Documentation Guidance or in the Contract Data Requirements Documents (see the contract statement of work).
  3. List of developed electronic products, and deliverables - Confirm that all of the required products are available.  What Needs To Be Accessible? Each project may have a different list of required products that can typically be found in the project requirements and deliverables.

The Agency Software Manager can be used as a resource for requirement confirmation.

A sample list is below:

•Software, executable, and source code
•Models and simulations
•Programmable Logic Device logic and software
•Trade study data, including software tools, used to help formulate an analysis of alternative results if any scenarios need to be re-run later
•Prototype software, including prototype architectures/designs
•Data definitions and data sets
•Software ground products
•Software build products
•Build tools

•Software documentation, including data presented during any early design reviews
•Metric data
•Software cost data and parameters
•Software database(s)
•Software development environment
•Software Test Scripts and the results of software testing
•Results of software static analysis activities
•Bi-directional traceability for the software products
•Software analyses and compliance data

    1. List of tasks for the software development required for the project’s software developers - look at the software development schedule milestones (see 7.08 - Maturity of Life Cycle Products at Milestone Reviews), software products required, and software processes used.
  • Confirm that any required Government actions (approvals, reviews) are established and maintained upon receipt of deliverables - look at the software development schedule milestones (see 7.08 - Maturity of Life Cycle Products at Milestone Reviews, software products delivery requirements, and software processes used.
  • Develop software assurance processes, plans, products, risks, and tasks lists as defined in the software assurance plans for the project - Develop or use/tailor pre-existing standard software assurance and software safety processes needed to perform the tasks and generate the products described in the SA plan for the project.  Establish a SA process for tracking and reporting products, risks, and task lists.

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:


  • No labels