bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin


{alias:SWE-095} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1. Requirements
Wiki Markup
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned


Div
idtabs-1

1. Requirements

4.4.6

Each

NASA

Mission

Directorate

shall

establish

its

own

software

measurement

system

to

include

the

minimum

reporting

requirements

in

[SWE-091|

SWE-091

]. h2. {color:#003366}{*}

.

1.1

Notes{*}{color} NPR

Notes

NPR 7150.2,

NASA

Software

Engineering

Requirements,

does

not

include

any

notes

for

this

requirement.

h2.

1.2

Applicability

Across

Classes

This

requirement

applies

to

Mission

Directorates

at

NASA

Headquarters.

{applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=1|dnsc=0|esc=1|ensc=0|f=1|g=1|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale The intent of the requirement is for a Mission Directorate to assess and define a software measurement system with reporting requirements necessary to manage and provide insight needed on Mission Directorate projects. The minimum reporting requirements can vary by Mission Directorate project or product line. The projects have metrics requirements and those requirements need to support the Mission Directorate to assess and define a software measurement system with reporting requirements. Software measurement programs are established to meet measurement objectives and goals at multiple levels. The data gained from these measurement programs are used in the management of projects, for assuring safety and quality, and in improving overall software engineering practices. In general, the Mission Directorate/Mission Support Office level measurement systems are designed to meet the following high level goals: * To improve future planning and cost estimation. * To provide realistic data for progress tracking. * To provide indicators of software quality. * To provide baseline information for future process improvement activities. With these high-level goals in mind, Mission Directorates are to establish specific measurement systems for their particular programs and projects to enable reporting on the minimum requirements categories listed in [SWE-091|SWE-091], and repeated here: * Software progress tracking. * Software functionality. * Software quality. * Software requirements volatility. * Software characteristics. Once these software measurement systems are established, the software measures and analysis results that emanate from them enable Directorate-wide assessments of the abilities and skills in the workforce, and potential opportunities for improving the software development. {div3} {div3:id=tabs-3} h1. 3. Guidance Each Mission Directorate develops its own measurement system, tailoring it to its needs and objectives, and basing it on an understanding of its unique development environment used for executing its programs and projects. Software measurement systems have three components: Source of data, technical support, and analysis and packaging. An agreed-to plan for the software measurement system usually accounts for the proper execution of the collection of the data. Data sourcing activities include: * A clear statement of the purpose and goals of the measurement system. * A clear description of all data to be provided/collected. * A clear and precise definition of terms used in the data and measurement system. * Who is responsible for providing which data. * When and to whom the data are to be provided. The data collection efforts conducted by the personnel supporting the Mission Directorate's activities occur more efficiently if the personnel time is minimized, if the volume and extent of the software measurements are properly planned, optimized, and directly related to the Directorate's goals, and the support personnel are properly trained in the software measurement system to perform the work. As listed in [SWE-091|SWE-091], and in the section on rationale above, this requirement calls for measures to be collected for category listings of software progress tracking, software functionality, software quality, software requirements volatility, and software characteristics. Example sets for each of these measures are listed in [SWE-117|SWE-117]. The selected measures are recorded in suitable Mission Directorate guidelines, planning documents, and data repositories. Remember that software measurement is a means to an end, not an end itself. Selected measures are to be obtained to support the achievement of a goal. As the Mission Directorate objectives evolve and mature, the software measurement system is reviewed, and updated, if necessary and beneficial. {div3} {div3:id=tabs-4} h1. 4. Small Projects No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph. {div3} {div3:id=tabs-5} h1. 5. Resources {refstable} {toolstable} {div3} {div3:id=tabs-6} h1. 6. Lessons Learned 1. *Selection and use of Software Metrics for Software Development Projects, Lesson No. 3556*: "The design, development, and sustaining support of Launch Processing System (LPS) application software for the Space Shuttle Program provide the driving event behind this lesson. "Metrics or measurements should be used to provide visibility into a software project's status during all phases of the software development life cycle in order to facilitate an efficient and successful project."  The Recommendation states that "As early as possible in the planning stages of a software project, perform an analysis to determine what measures or metrics will used to identify the 'health' or hindrances (risks) to the project. Because collection and analysis of metrics require additional resources, select measures that are tailored and applicable to the unique characteristics of the software project, and use them only if efficiencies in the project can be realized as a result. The following are examples of useful metrics: * "The number of software requirement changes (added/deleted/modified) during each phase of the software process (e.g., design, development, testing). * "The number of errors found during software verification/validation. * "The number of errors found in delivered software (a.k.a., 'process escapes'). * "Projected versus actual labor hours expended. * "Projected versus actual lines of code, and the number of function points in delivered software. {sweref:577} 2. *Flight Software Engineering Lessons, Lesson No. 2218*: "The engineering of flight software (FSW) for a typical NASA/Caltech Jet Propulsion Laboratory (JPL) spacecraft is a major consideration in establishing the total project cost and schedule because every mission requires a significant amount of new software to implement new spacecraft functionality." The lesson learned Recommendation No. 8 provides this step as well as other steps to mitigate the risk from defects in the {term:FSW} development process: "Use objective measures to monitor FSW development progress and to determine the adequacy of software verification activities. To reliably assess FSW production and quality, these measures should include metrics such as the percentage of code, requirements, and defined faults tested, and the percentage of tests passed in both simulation and test bed environments. These measures should also identify the number of units where both the allocated requirements and the detailed design have been baselined, where coding has been completed and successfully passed all unit tests in both the simulated and test bed environments, and where they have successfully passed all stress tests." {sweref:572} {div3} {tabclose}


applicable
f1
g1
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnsc0
dsc1
ensc0



Div
idtabs-2

2. Rationale

The intent of the requirement is for a Mission Directorate to assess and define a software measurement system with reporting requirements necessary to manage and provide insight needed on Mission Directorate projects. The minimum reporting requirements can vary by Mission Directorate project or product line. The projects have metrics requirements and those requirements need to support the Mission Directorate to assess and define a software measurement system with reporting requirements.

Software measurement programs are established to meet measurement objectives and goals at multiple levels. The data gained from these measurement programs are used in the management of projects, for assuring safety and quality, and in improving overall software engineering practices. In general, the Mission Directorate/Mission Support Office level measurement systems are designed to meet the following high level goals:

  • To improve future planning and cost estimation.
  • To provide realistic data for progress tracking.
  • To provide indicators of software quality.
  • To provide baseline information for future process improvement activities.

With these high-level goals in mind, Mission Directorates are to establish specific measurement systems for their particular programs and projects to enable reporting on the minimum requirements categories listed in SWE-091, and repeated here:

  • Software progress tracking.
  • Software functionality.
  • Software quality.
  • Software requirements volatility.
  • Software characteristics.

Once these software measurement systems are established, the software measures and analysis results that emanate from them enable Directorate-wide assessments of the abilities and skills in the workforce, and potential opportunities for improving the software development.


Div
idtabs-3

3. Guidance

Each Mission Directorate develops its own measurement system, tailoring it to its needs and objectives, and basing it on an understanding of its unique development environment used for executing its programs and projects. Software measurement systems have three components: Source of data, technical support, and analysis and packaging. An agreed-to plan for the software measurement system usually accounts for the proper execution of the collection of the data.

Data sourcing activities include:

  • A clear statement of the purpose and goals of the measurement system.
  • A clear description of all data to be provided/collected.
  • A clear and precise definition of terms used in the data and measurement system.
  • Who is responsible for providing which data.
  • When and to whom the data are to be provided.

The data collection efforts conducted by the personnel supporting the Mission Directorate's activities occur more efficiently if the personnel time is minimized, if the volume and extent of the software measurements are properly planned, optimized, and directly related to the Directorate's goals, and the support personnel are properly trained in the software measurement system to perform the work.

As listed in SWE-091, and in the section on rationale above, this requirement calls for measures to be collected for category listings of software progress tracking, software functionality, software quality, software requirements volatility, and software characteristics. Example sets for each of these measures are listed in SWE-117. The selected measures are recorded in suitable Mission Directorate guidelines, planning documents, and data repositories.

Remember that software measurement is a means to an end, not an end itself. Selected measures are to be obtained to support the achievement of a goal. As the Mission Directorate objectives evolve and mature, the software measurement system is reviewed, and updated, if necessary and beneficial.


Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.


Div
idtabs-5

5. Resources


refstable

toolstable


Div
idtabs-6

6. Lessons Learned

1. Selection and use of Software Metrics for Software Development Projects, Lesson No. 3556: "The design, development, and sustaining support of Launch Processing System (LPS) application software for the Space Shuttle Program provide the driving event behind this lesson.

"Metrics or measurements should be used to provide visibility into a software project's status during all phases of the software development life cycle in order to facilitate an efficient and successful project."  The Recommendation states that "As early as possible in the planning stages of a software project, perform an analysis to determine what measures or metrics will used to identify the 'health' or hindrances (risks) to the project. Because collection and analysis of metrics require additional resources, select measures that are tailored and applicable to the unique characteristics of the software project, and use them only if efficiencies in the project can be realized as a result. The following are examples of useful metrics:

  • "The number of software requirement changes (added/deleted/modified) during each phase of the software process (e.g., design, development, testing).
  • "The number of errors found during software verification/validation.
  • "The number of errors found in delivered software (a.k.a., 'process escapes').
  • "Projected versus actual labor hours expended.
  • "Projected versus actual lines of code, and the number of function points in delivered software.
    sweref
    577
    577

2. Flight Software Engineering Lessons, Lesson No. 2218: "The engineering of flight software (FSW) for a typical NASA/Caltech Jet Propulsion Laboratory (JPL) spacecraft is a major consideration in establishing the total project cost and schedule because every mission requires a significant amount of new software to implement new spacecraft functionality."

The lesson learned Recommendation No. 8 provides this step as well as other steps to mitigate the risk from defects in the FSW development process:

"Use objective measures to monitor FSW development progress and to determine the adequacy of software verification activities. To reliably assess FSW production and quality, these measures should include metrics such as the percentage of code, requirements, and defined faults tested, and the percentage of tests passed in both simulation and test bed environments. These measures should also identify the number of units where both the allocated requirements and the detailed design have been baselined, where coding has been completed and successfully passed all unit tests in both the simulated and test bed environments, and where they have successfully passed all stress tests."

sweref
572
572