Search

The DoD’s new software acquisition pathway prioritizes speed of delivery, advocating agile software processes. Estimating the cost and schedule of agile software projects is critical at an early phase to establish baseline budgets and to select competitive bidders. The challenge is that common ag-ile sizing measures such as story points and user stories are not practical for early estimation as these are often reported after contract award in DoD. This study provides a set of parametric effort and schedule estimation models for agile projects using a sizing measure that is available before proposal evaluation based on data from 36 DoD agile projects. The results suggest that initial software requirements, defined as the sum of functions and external interfaces, is an effective sizing measure for early estimation of effort and schedule of agile projects. The models’ accuracy improves when application domain groups and peak staff are added as inputs.

Estimating the cost and schedule of agile software projects is critical at an early phase to establish baseline budgets and schedules for the selection of competitive bidders. The challenge is that common agile sizing measures such as story points and user stories are not practical for early estimation as these are often reported after contract award in DoD. This study provides a set of effort and schedule estimation models for agile projects using a sizing measure that is available before proposal evaluation based on data from 36 DoD agile projects. The results suggest that initial software requirements, defined as the sum of functions and external interfaces, is an effective sizing measure for early estimation of effort and schedule of agile projects. The models’ accuracy improves when application domain groups and peak staff are added as inputs.

In this presentation, Dr. Boehm proposes a model for estimating the effort that will be needed to complete Agile software development projects. Previous estimation capabilities often require information such as function points, story points, or lines of code that are not available early for agile projects. For this work the team used initial and final Software Resource Data Reports from the Cost Assessment Data Enterprise or CADE (of the Office of the Secretary of Defense (OSD) Cost Assessment and Program Evaluation (CAPE) initiative) to tie actual effort and processes to initial estimates. The proposed Agile Effort Estimation Model uses a combination of three variables to provide estimates, including the number of software requirements at contract start, an initial estimate of peak staffing, and which “super-domain” the project fits within.

Background: Software effort estimates are necessary and critical at an early phase for decision makers to establish initial budgets, and in a government context to select the most competitive bidder for a contract. The challenge is that estimated software requirements is the only size information available at this stage, compounded with the newly increasing adoption of agile processes in the US DoD. Aims: The objectives are to improve cost estimation by investigating available sizing measures, and providing practical effort estimation models for agile software development projects during the contract bidding phase or earlier. Method: The analysis explores the effects of independent variables for product size, peak staff, and domain on effort. The empirical data for model calibration is from 20 industrial projects completed recently for the US DoD, among a larger dataset of recent projects using other lifecycle processes. Results: Statistical results showed that initial software requirements is a valid size metric for estimating agile software development effort. Prediction accuracy improves when peak staff and domain are added as inputs to the cost models. Conclusion: These models may be used for estimates of agile projects, and evaluating software development contract cost proposals with inputs available during the bidding phase or earlier.

Context: An effort estimation model with more than 20 parameters is not very useful at early conceptual phase if you don’t have a logical approach for specifying the input values.

This is the 2nd of two reports that were created for research on this topic funded through SERC. SERC-TR-2013-032-2 (current report), included the Software Cost Estimation Metrics Manual. This constitutes the 2012-2013 Final Technical Report of the SERC Research Task Order 0024, RT-6: Software Intensive Systems Cost and Schedule Estimation. Estimating the cost to develop a software application is different from almost any other manufacturing process. In other manufacturing disciplines, the product is developed once and replicated many times using physical processes. Replication improves physical process productivity (duplicate machines produce more items faster), reduces learning curve effects on people and spreads unit cost over many items. Whereas a software application is a single production item, i.e. every application is unique. The only physical processes are the documentation of ideas, their translation into computer instructions and their validation and verification. Production productivity reduces, not increases, when more people are employed to develop the software application. Savings through replication are only realized in the development processes and on the learning curve effects on the management and technical staff. Unit cost is not reduced by creating the software application over and over again., Software Cost Estimation Metrics Manual. The original document contains color images.

This is the 2nd of two reports that were created for research on this topic funded through SERC. SERC-TR-2013-032-2 (current report), included the "Software Cost Estimation Metrics Manual." This constitutes the 2012-2013 Final Technical Report of the SERC Research Task Order 0024, RT-6: Software Intensive Systems Cost and Schedule Estimation. Estimating the cost to develop a software application is different from almost any other manufacturing process. In other manufacturing disciplines, the product is developed once and replicated many times using physical processes. Replication improves physical process productivity (duplicate machines produce more items faster), reduces learning curve effects on people and spreads unit cost over many items. Whereas a software application is a single production item, i.e. every application is unique. The only physical processes are the documentation of ideas, their translation into computer instructions and their validation and verification. Production productivity reduces, not increases, when more people are employed to develop the software application. Savings through replication are only realized in the development processes and on the learning curve effects on the management and technical staff. Unit cost is not reduced by creating the software application over and over again.

In the dynamic software field there are major challenges in adapting metrics and cost estimation methods to continuing changes. There is a need to assess emerging trends and re-interpret software size measures and estimation models for new processes. Future trends of software systems are overviewed with implications for software sizing and cost estimation capabilities. Methods are shown to handle some of these effects, but many software variabilities remain uncovered., 15th Annual Practical Systems and Software Measurement (PSM) Users' Group Conference, Mystic, CT, 11-15 July 2011.

General software cost parameters such as size, effort distribution, and productivity are necessarily imprecise due to variations by domain. To improve this situation, empirical software cost analysis using the primary US DoD cost database has been segmented by domain. This analysis supports a software cost estimation metrics manual for improvements in acquisition policies, procedures and tools. We have addressed the challenges of consistent data definitions and taxonomies across diverse stakeholder communities, data integrity, data formats, and others. We highlight example analysis results from an application domain demonstrating cost estimating relationships, benchmarks on reuse parameters and effort distributions for estimators to use.