2.2.3 The project shall establish, document, and maintain at least one software cost estimate and associated cost parameter(s) that satisfies the following conditions: 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. 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. Class A_SC A_NSC B_SC B_NSC C_SC C_NSC D_SC D_NSC E_SC E_NSC F G H Applicable? P(C) P(C) Key: A_SC = Class A Software, Safety-Critical | A_NSC = Class A Software, Not Safety-Critical | ... | - Applicable | - Not Applicable Credible software cost estimates are a key activity performed as part of a project and software life cycle management (NPR 7150.2, NASA Software Engineering Requirements, Section 2.2) with regular updates made throughout the entire life cycle. 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 result in staffing and budgeting decisions that could impair effective use of resources. The key parts of the requirement that need to be addressed are: 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 percent to over a 100 percent are typically identified as a contributing factor in post development lessons learned. Barry Boehm's 136 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, 30 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 is performed as a part of 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: Scope the job The project team determines the scope of the software task, including what the task is and is not, and what it covers. Scoping is not requirements writing – requirements are generally developed after initial planning and estimating is completed. The goal is to identify clearly and in sufficient detail the entire set of software products and activities for producing a good cost estimate. This includes understanding the intended concept of operations and operating environment to fully characterize the complexity of the work. The project team also identifies 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 (BOE) 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: Estimate Software Size Model-Based Estimates Model-based estimates are estimates made using parametric cost models. Parametric cost models have been in use at NASA for over 20 years. The two most used parametric software cost models are COCOMO II and SEER-SEM. SCAT is a probabilistic version of COCOMO II and can be found on the NASA Software PAL. (Refer to the
Resources tab for additional information on these tools.) Cost models can be used as a primary estimate early in the life cycle, as a secondary backup estimate for validation, and to help you reason about the cost and schedule implications of software decisions you may need to make. Cost models require an estimate of the size of the system and a set of inputs describing the system and development environment; these items are referred to as cost drivers or effort multipliers. Effort multipliers characterize the product, platform, personnel, and project attributes of the software project under development. Risk The purpose of this step is to identify common software risks, assess their impact on the cost estimate, and make revisions to the estimate based on these impacts. A risk is an event that has the potential to cause significant impact on technical, cost and/or schedule performance. Compile known major risks. As you generate the software risk list, consider the following: Risk can be estimated and analyzed in various ways: Monte Carlo methods use random numbers to obtain numerical solutions when analytical methods are too difficult to use. When using Monte Carlo methods with cost models, they are used to simulate the estimated cost distribution. The project team may add the results of the expected risk impact or identified mitigations to the bottom up estimate. The cost models have Monte Carlo algorithms which produce a cost distribution and the identified risks are used to determine which model inputs will be entered with a wider range. Validation and Reconciliation The purpose of this step is to review the validated estimates with respect to the project-imposed budget and schedule, and to resolve the differences. If an inconsistency arises, there is a tendency to incorrectly address the issue as only a problem of incorrect estimation. However, in most cases, the real solution is to reduce scope or functionality, and then to reduce scope again, until the task fits the budget. Do not reduce costs by eliminating reserves and making optimistic and unrealistic assumptions, especially with respect to the amount of code inheritance. Review and Approve the Estimates The purpose of this step is to review the software estimates and to obtain stakeholder approval. The project team conducts a peer review with the following objectives: The stakeholders, which include the software manager, software estimators, line management, and project management, approve the software estimates after the review is complete and problems have been resolved. Remember that costs cannot be reduced without reducing functionality. Additional guidance related to software cost estimation may be found in the following related requirements in this Handbook: The basic estimation techniques apply to small as well as large tasks but they are tailored or scaled to fit the size and scope of the task. One area of concern is with the cost models, as they tend to be calibrated to medium size and larger projects. It is recommended that that a greater reliance be placed upon analogy-based cost estimates unless the model being used can be verified for use on small tasks in your local environment. 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. The NASA Lessons Learned database contains the following lessons learned related to cost estimation: Other Lessons Learned from experience (Hihn, Jairus M. JPL. 818.354.1248) and the JPL Cost Estimation Handbook 366 include the following concepts: In addition to these Lessons Learned, Chapter 12 of the GAO Cost Estimating and Assessment Guide, Best Practices for Developing and Managing Capital Program Costs (GAO-09-3SP) 419, discusses problems with underestimating software costs, include this excerpt from a case study, "The original estimate for the Space Based Infrared System for nonrecurring engineering, based on actual experience in legacy sensor development and assumed software reuse, was significantly underestimated. Nonrecurring costs should have been two to three times higher, according to historical data and independent cost estimators. Program officials also planned on savings from simply rehosting existing legacy software, but those savings were not realized because all the software was eventually rewritten. It took 2 years longer than planned to complete the first increment of software."
See edit history of this section
Post feedback on this section
1. Requirements
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.2 Applicability Across Classes
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures2. Rationale
3. Guidance
4. Small Projects
5. Resources
5.1 Tools
6. Lessons Learned
SWE-015 - Cost Estimation
Web Resources
View this section on the websiteUnknown macro: {page-info}
0 Comments