1. Requirements

2.4.2 The project shall establish, document, and maintain at least one software cost estimate and associated cost parameter(s) that satisfies the following conditions
     a. Covers the entire software life cycle.
     b. Is based on selected project attributes (e.g., assessment of the size, functionality, complexity, criticality, and risk of the software processes and products).
     c. Is based on the cost implications of the technology to be used and the required maturation of that technology.

1.1 Notes">1.1 Notes

In the event there is a decision to outsource, it is a best practice that both the acquirer (NASA) and the provider (contractor/sub) should develop software cost estimates and negotiate to arrive at an acceptable estimate.

1.2 Applicability Across Classes

Class D non-Safety Critical and Class E non-Safety Critical are labeled with "P(Center)". This means that a non-null set of local requirements or procedures describe cost estimation sufficiently to meet the intent of this requirement.

Key:    A_SC = Class A Software, Safety-Critical | A_NSC = Class A Software, Not Safety-Critical | ... | - Applicable | - Not Applicable
^X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

2. Rationale

Credible software cost estimates are a key activity performed as part of a project and software lifecycle management (NPR 7150.2, Section 2.2) with regular updates made throughout the entire lifecycle. Credible software cost estimates are required to meet NASA policies. The reliability of project cost estimates at every stage in the project development process is necessary for responsible fiscal management. Unreliable cost estimates result in severe problems in planning and budgeting which then results in staffing and budgeting decisions that could impair effective use of resources.

3. Guidance

The key parts of the requirement that need to be addressed are:

• Establish a software cost estimation process, preferably a project will use a industry standard process or tool like COCOMO or SEER SIM tailored for the organization performance and parameters.
• Document the process, parameters and results of the software estimations, maintain records of the software estimates and data associated with uncertainly and assumptions for the given estimate
• Document and maintain all associated software cost parameters. The ability to reproduce the software estimate and understand the risk associated with the estimate is generally contained in the software cost model parameters
• The cost estimate covers the entire life cycle given the starting point of the estimate.
• Cost estimates are developed and maintained over the software life cycle including any time the schedule or resource allocations change or requirements change.
• Maintain all assumptions and data associated with the technology to be used on the software project, maintain good data and records of associated with any cost saving identified from the use of software technology
• Make sure that your software estimate maintains data showing cost required for maturation of any planned use of new technology. New technology can be defined as any new software development environments or tools or software development associated with a new or unproven technology.
• Different software cost estimates are developed for the different classes of software on a project and for different organizations developing software on a project. Software cost parameters are maintained for each software cost estimate.

As software's importance in missions has grown, the focus on its overall performance both technically and programmatically has also increased. As a result, software has been blamed for launch slips, mission failures, and contributing to major project cost growth. Estimation errors resulting in software cost growth rates of 50% to over a 100% are typically identified as a contributing factor in post development lessons learned. Barry Boehm's1 seminal chart shown below captures one of the main reasons why estimation is difficult. The figure illustrates that, estimation uncertainty is so large in the early stages of the life cycle, that estimates can be off by a factor of four.

Fortunately, thirty years of cost estimation and modeling research and practice have identified methods for addressing these known issues. These are reflected in the process described in this SWE.

Software cost estimates are a key activity performed as part of Software Life cycle Planning (NPR 7150.2, Section 2.2) with regular updates made throughout the entire life cycle. This activity should be performed by software tasks of all sizes and all classes with the primary difference being the level of detail and amount of review of the estimates. While only one estimate is required it is highly recommended that additional model-based and analogy estimates be completed as verification or backup to the primary estimate, which is typically a bottom-up estimate. Multiple estimates are especially important due to the extensive estimation uncertainty that exists in the early part of the life cycle. Most models provide a method for expressing the estimate uncertainty that the project team can use as part of the basis of estimate.

The key elements of the process are the development of the following:

• two estimates, one of which is a model based estimate
• a software size estimate and other key planning parameters
• a risk list with mitigations
• a documented basis of estimate (BOE) that can be revised as plans are updated

Scope the job

The project team should determine the scope of the software task, including what the task is and is not, and what it covers.

The goal is to identify clearly and in sufficient detail the entire set of software products and activities for producing a good cost estimate. The project team should also identify values for key planning parameters, including the systems schedule, risk posture, new technology assumptions, expected inheritance, and complexity.

Typically, the scope of a software development effort includes all activities associated with software management, software engineering, programming, and software test engineering over the software life cycle. Included in this effort are software requirements analysis, software design, software implementation, and software integration and testing.

Bottom-Up Estimate

When developing the bottom-up cost estimate, the first step is to develop the work breakdown structure (WBS). A critical aspect of developing the WBS is ensuring that it is easily mapped to other key task breakdowns, including the functional or object decomposition and schedule elements. It is important to be able to quickly modify the cost, schedule and functional design as changes occur to keep them consistent.

A recommended sequence of steps for the bottom-up estimate is the following:

• Define a WBS
• Estimate size and/or effort for each element
• If available map analogous size, effort and/or costs into current WBS
• Adjust baseline for your mission and document how and why it was adjusted as part of the BOE
• Lay it out over time
• Use approved tool to get costs
• Use reference data to assist in effort estimate or to check distribution of effort

Estimate Software Size

1. Software size is a required input for the use of a cost model and can also be used as part of a bottom-up estimate. Estimating software size is one the most complicated estimation activities. Software size can be measured in various ways but the most common measure is to count lines of code (LOC). The most used LOC metrics are physical lines (carriage returns excluding comments and blanks) and logical lines which counts logical delimiters such as terminal semi-colons in C along with preprocessor directives and terminal close-braces. The accuracy of size estimate is greatly improved when anchored by actual code counts from similar software products or similar software components, which require a code counter such as Source Lines Counter (SLiC), found on the NASA Software PAL. It is also required to distinguish between new, reused and modified-reused code as the cost of developing a code is very different for each type of code. For more information and a detailed description of how handle the different types of code, consult Software Engineering Economics, by Boehm^1^, Software Cost Estimation with COCOMO II, by Boehm, et. al.², and the Handbook for Software Cost Estimation by Lum, et. al.³, also listed in the Resource tab of this SWE.

4. Small Projects

add

5. Resources

1. add
2. add

5.1 Tools

add

6. Lessons Learned

add