Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
01. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned

1. Requirements

Excerpt For Class A, B, and C software projects, each Center Director, or designee, shall establish and maintain software cost repository(ies) that contains at least the following measures:

    1. Planned and actual effort and cost.
    2. Planned and actual schedule dates for major milestones.
    3. Both planned and actual values for key cost parameters that typically include software size, requirements count, defects counts for maintenance or sustaining engineering projects, and cost model inputs.
    4. Project descriptors or metadata that typically includes software class, software domain/type, and requirements volatility.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

titleClick here to view the history of this requirement: SWE-142 History

Include Page
SITE:SWE-142 History
SITE:SWE-142 History


2. Rationale

A cost repository is a tool for capturing and maintaining the historical project data useful for generating project estimates. Establishing, maintaining, and using a cost repository enables projects and programs to develop credible software cost estimates. 


3. Guidance

Software organizations and those supporting the cost estimation process should maintain a historical record of the data used to generate the cost estimates as well as the actual costs associated with those projects.  Comparing the actual costs to the estimated costs and determining the basis for the differences allows for improved accuracy in future estimations.  Additionally, data in cost repositories can help determine project cost growth over time and deviation between estimates and actuals.

Cost repositories are useful during all levels of planning: proposals, concept studies, feasibility studies, detailed task planning, as well as independent cost assessments. Cost repositories should be populated during the cost estimation process and updated throughout the process so that the data in the repository accurately reflects the data used as the basis for the cost estimate.  The data need to be “sufficient to break them down to the lower levels needed to estimate various [work breakdown structure] (WBS) elements.”

 Additionally, cost model inputs should have a pedigree associated with them.  (Information on cost model input pedigree can be found in NASA-STD-7009
 and NASA-HDBK-7009

Cost repositories should contain technical, schedule, program, and cost data in a format that allows meaningful data roll-up and comparison across multiple projects.  The recommended minimum data set includes:

  • Planned and actual effort.
  • Planned and actual schedule dates (e.g., start, major milestones, completion).
  • Planned and actual cost.
  • Planned and actual values for key cost parameters such as:
    • Software size (e.g., lines of new, reused, and modified-reused code).
    • Requirements count.
    • Defects count for maintenance or sustaining engineering projects.
    • Cost model inputs (e.g., complexity, requirements volatility).
  • Project descriptors or metadata that typically includes software class, software domain/type, and requirements volatility.

Additional repository data could include:

  • Project name, organization.
  • Platform.
  • Software language.
  • Software classification.
  • Safety-criticality.
  • Constraints (e.g., resources, budget, schedule).

A cost repository could be a simple spreadsheet or a database depending on the amount of data to be stored and maintained for the organization as well as the number of stakeholders who need to access, use, and maintain the data.  The implementation tool could also depend upon the type of analysis that will be performed on the data and whether there is the benefit of having the tool perform some of that analysis.

Data in cost repositories should be reported to or accessible by organizational and Center-level data systems for organizational or Center-level analysis, measurements, and process improvements.

NASA-specific software cost estimation process information is available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook. 

Additional guidance related to software cost repositories may be found in the following related requirements in this Handbook:


4. Small Projects

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


5. Resources

5.1 References

Show If
titleVisible to editors only

Enter the necessary modifications to be made in the table below:

SWEREFs to be addedSWEREFS to be deleted

SWEREFs NOT called out in text but listed as germane: none

SWEREFs called out in the text: 272, 419, 460, 567

5.2 Tools

Include Page
Tools Table Statement
Tools Table Statement


6. Lessons Learned

6.1 NASA Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to cost estimation:

  • Know-How Your Software Measurement Data Will Be Used. Lesson Number 1772
    When software measurement data used to support cost estimates is provided to NASA by a project without an understanding of how NASA will apply the data, discrepancies may produce erroneous cost estimates that disrupt the process of project assessment and approval. Major flight projects should verify how NASA plans to interpret such data and use it in their parametric cost estimating model, and consider duplicating the NASA process using the same or a similar model prior to submission.

6.2 Other Lessons Learned

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