A Manager's Checklist for Validating Software Cost and Schedule Estimates
Robert E. ParkCMU/SEI-95-SR-004
January 1995
[Abstract]
Acknowledgments
The following people have contributed to this work, either as reviewers of earlier versions or as part of the team that helped generate ideas and material for the checklist.
|
Edward Averill Dinah Beres Reg Burd Anita Carleton John P. Chihorek Lyle Cocking Cenap Dada Joe Dean Leonard Flens Judy Galorath Gary Gaston Wolfhart Goethert
Jim Hart Will Hayes Joseph F. Lipari Reed Little |
Colonel Russell Logan
Joan Lovelace John MacDonald Jordan B. Matejceck
Barbara Meyers Thomas E. Moulds Paul Oliver Bill Peterson Joseph L. Podolsky
Michael Rissman Jim Rozum Dick Stutzke Ed Tilford, Sr. Bob Verge Todd Webb Roy Williams |
|
[Abstract]
1 Introduction
When
you—or your boss or customer—receive
a cost or schedule estimate
for a software project, what
do you look for to determine
your willingness to rely on
that estimate?
This report provides a checklist
to help you address and evaluate
a number of issues that are
key to estimates we can trust.
The checklist guides you
through the seven questions
in this table:
|
Seven
Questions to Ask When
Assessing Your Willingness
to Rely On a Cost and
Schedule Estimate
|
|
| 1 |
Are the objectives of the estimate clear and correct? |
| 2 | Has the task been appropriately sized? |
| 3 | Are the estimated cost and schedule consistent with demonstrated accomplishments on other projects? |
| 4 | Have the factors that affect the estimate been identified and explained? |
| 5 | Have steps been taken to ensure the integrity of the estimating process? |
| 6 | Is the organization's historical evidence capable of supporting a reliable estimate? |
| 7 | Has the situation changed since the estimate was prepared? |
Each question is illustrated with elements of evidence that, if present, support the credibility of the estimate. The answers you receive should help you judge the extent to which you can safely use the estimate for planning, tracking, or decision making. The checklist can be used also to motivate and guide organizations toward improving their software estimating processes and practices.
[Abstract]
We present the checklist for
validating software cost and
schedule estimates on the pages
that follow. You may make,
use, or distribute as many
copies as you wish, so long
as you reproduce the entire
checklist, including the copyright
notice.
The purpose of the checklist
is not to impose criteria,
but to arm you with questions
to ask when deciding whether
or not to rely on a particular
estimate. Only you can determine
which questions to ask and
whether or not the answers
you get provide sufficient
evidence to satisfy your
requirements for using the
estimate.
Although we prepared this
checklist to help you evaluate
estimates for software
costs and schedules, almost
everything in it applies
equally to hardware and systems
engineering projects. If
you have responsibilities
for developing hardware or
integrated systems, you may
find that altering the word
'software' wherever it appears
will make the checklist applicable
to estimates for these systems
as well.
The checklist in this report
was produced as part of the
SEI's Software Cost Estimating
Improvement Initiative [Park
94]. Please let us know if
you find it helpful, or if
you have suggestions for
improving its usefulness
for your organization. For
related checklists that can
help you evaluate the processes
used for making software
estimates, please see the
SEI report Checklists
and Criteria for Evaluating
the Cost and Schedule Estimating
Capabilities of Software
Organizations [Park
95].
A
Manager's Checklist for Validating
Software Cost and Schedule
Estimates
This checklist is designed to help managers assess the credibility of software cost and schedule estimates. It identifies seven issues to address and questions to ask when determining your willingness to accept and use a software estimate. Each question is associated with elements of evidence that, if present, support the credibility of the estimate.
| Issue 1 |
Are
the objectives of the
estimate clear and
correct? |
|
|
| The objectives of the estimate are stated in writing. |
O
|
||
| The life cycle to which the estimate applies is clearly defined. |
O
|
||
| The tasks and activities included in (and excluded from) the estimate are clearly identified. |
O
|
||
| The tasks and activities included in the estimate are consistent with the objectives of the estimate. |
O
|
||
| Issue 2 |
Has
the task been appropriately
sized? |
|
|
| A structured process has been used to estimate and describe the size of the software product. |
O
|
||
| A structured process has been used to estimate and describe the extent of reuse. |
O
|
||
| The processes for estimating size and reuse are documented. |
O
|
||
| The descriptions of size and reuse identify what is included in (and excluded from) the size and reuse measures used. |
O
|
||
| The measures of reuse distinguish between code that will be modified and code that will be integrated as-is into the system. |
O
|
||
| The definitions, measures, and rules used to describe size and reuse are consistent with the requirements (and calibrations) of the models used to estimate cost and schedule. |
O
|
||
|
The size estimate was checked by relating it to measured sizes of other software products or components. |
O
|
||
| The size estimating process was checked by testing its predictive capabilities against measured sizes of completed products. |
O
|
||
| Issue 3 |
Are
the estimated cost
and schedule consistent
with demonstrated accomplishments
on other projects?
|
|
|
| The organization has a structured process for relating estimates to actual costs and schedules of completed work. |
O
|
||
|
• The process is documented. |
O
|
||
|
• The process was followed. |
O
|
||
|
The cost and schedule models that were used have been calibrated to relevant historical data.
|
O
|
||
|
The cost and schedule models quantify demonstrated organizational performance in ways that normalize for differences among software products and projects.
|
O
|
||
|
The consistency achieved when fitting the cost and schedule models to historical data has been measured and reported. |
O
|
||
|
The values used for cost and schedule model parameters appear valid when compared to values that fit the models well to past projects. |
O
|
||
|
The calibration of cost and schedule models was done with the same versions of the models that were used to prepare the estimate. |
O
|
||
|
The methods used to account for reuse recognize that reuse is not free.
|
O
|
||
|
Extrapolations from past projects account for differences in application technology.
|
O
|
||
|
Extrapolations from past projects account for observed, long-term trends in software technology improvement.
|
O
|
||
|
Extrapolations from past projects account for the effects of introducing new software technology or processes.
|
O
|
||
|
Work-flow schematics have been used to evaluate how this project is similar to (and how it differs from) projects used to characterize the organization's past performance. |
O
|
||
| Issue 4 |
Have
the factors that affect
the estimate been identified
and explained? |
|
|
|
A written summary of parameter values and their rationales accompanies the estimate. |
O
|
||
| Assumptions have been identified and explained. |
O
|
||
| A structured process such as a template or format has been used to ensure that key factors have not been overlooked. |
O
|
||
| Uncertainties in parameter values have been identified and quantified. |
O
|
||
|
A risk analysis has been performed, and risks that affect cost or schedule have been identified and documented.
|
O
|
||
| Issue 5 |
Have
steps been taken to
ensure the integrity
of the estimating process?
|
|
|
|
Management reviewed and agreed to the values for all descriptive parameters before costs were estimated. |
O
|
||
|
Adjustments to parameter values to meet a desired cost or schedule have been documented. |
O
|
||
|
If a dictated schedule has been imposed, the estimate is accompanied by an estimate of |
O
|
||
|
• The normal schedule. |
O
|
||
|
• The additional expenditures required to meet the dictated schedule. |
O
|
||
|
Adjustments to parameter values to meet a desired cost or schedule are accompanied by management action that makes the values realistic. |
O
|
||
|
More than one cost model or estimating approach has been used, and the differences in results have been analyzed and explained. |
O
|
||
|
People from related but different projects or disciplines were involved in preparing the estimate. |
O
|
||
|
At least one member of the estimating team is an experienced estimator, trained in the cost models that were used. |
O
|
||
|
Estimators independent of the performing organization concur with the reasonableness of the parameter values and estimating methodology. |
O
|
||
|
The groups that will be doing the work accept the estimate as an achievable target. |
O
|
||
|
Memorandums of agreement have been completed and signed with the other organizations whose contributions affect cost or schedule. |
O
|
||
| Issue 6 |
Is
the organization's
historical evidence
capable of supporting
a reliable estimate?
|
|
|
|
The estimating organization has a method for organizing and retaining information on completed projects (a historical database). |
O
|
||
|
The database contains a useful set of completed projects. |
O
|
||
|
Elements included in (and excluded from) the effort, cost, schedule, size, and reuse measures in the database are clearly identified.
|
O
|
||
|
Schedule milestones (start and finish dates) are described in terms of criteria for initiation or completion, so that work accomplished between milestones is clearly bounded. |
O
|
||
|
Records for completed projects indicate whether or not unpaid overtime was used. |
O
|
||
|
Unpaid overtime, if used, has been quantified, so that recorded data provide a valid basis for estimating future effort. |
O
|
||
|
Cost models that were used for estimating have been used also to provide consistent frameworks for recording historical data.
|
O
|
||
|
The data in the historical database have been examined to identify inconsistencies, and anomalies have been corrected or explained.
|
O
|
||
|
The organization has a structured process for capturing effort and cost data from ongoing projects. |
O
|
||
|
The producing organization holds postmortems at the completion of its projects. |
O
|
||
|
• To ensure that recorded data are valid. |
O
|
||
|
• To ensure that events that affected costs or schedules get recorded and described while they are still fresh in people's minds. |
O
|
||
|
Information on completed projects includes • The life-cycle model used, together with the portion covered by the recorded cost and schedule. |
O
|
||
|
• Actual (measured) size, cost, and schedule. |
O
|
||
|
• The actual staffing profile. |
O
|
||
|
• An estimate at completion, together with the values for cost model parameters that map the estimate to the actual cost and schedule. |
O
|
||
|
• A work breakdown structure or alternative description of the tasks included in the recorded cost. |
O
|
||
|
• A work-flow schematic that illustrates the software process used. |
O
|
||
|
• Nonlabor costs. |
O
|
||
|
• Management costs. |
O
|
||
|
• A summary or list of significant deliverables (software and documentation) produced by the project. |
O
|
||
|
• A summary of any unusual issues that affected cost or schedule. |
O
|
||
|
Evolution in the organization's work-flow schematics shows steady improvement in the understanding and measurement of its software processes. |
O
|
||
| Issue 7 |
Has
the situation changed
since the estimate
was prepared? |
| |
|
The estimate has not been invalidated by recent events, changing requirements, or management action (or inaction). |
O
|
||
|
The estimate is being used as the basis for assigning resources, deploying schedules, and making commitments. |
O
|
||
| The estimate is the current baseline for project tracking and oversight. |
O
|
||
[Abstract]
References
| [Goethert 92] |
Goethert, Wolfhart B., et al. Software Effort Measurement: A Framework for Counting Staff-Hours (CMU/SEI-92-TR-021, ADA258279). Pittsburgh, Pa: Software Engineering Institute, Carnegie Mellon University, September 1992.
|
|
| [Park 92] |
Park,
Robert E., et al. Software
Size Measurement: A
Framework for Counting
Source Statements
(CMU/SEI-92-TR-020,
ADA258304). Pittsburgh,
Pa: Software Engineering
Institute, Carnegie
Mellon University,
September 1992.
|
|
| [Park 94] |
Park, Robert E., Goethert, Wolfhart B., and Webb, J. Todd. Software Cost and Schedule Estimating: A Process Improvement Initiative (CMU/SEI-94-SR-003). Pittsburgh, Pa: Software Engineering Institute, Carnegie Mellon University, May 1994.
|
|
| [Park 95] | Park, Robert E. Checklists and Criteria for Evaluating the Cost and Schedule Estimating Capabilities of Software Organizations (CMU/SEI-95-SR-005). Pittsburgh, Pa: Software Engineering Institute, Carnegie Mellon University, January 1995. | |
[Abstract]
|
REPORT DOCUMENTATION PAGE |
Form Approved OMB No. 0704-0188 |
||||||
|
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503. |
|||||||
|
1.
agency use only |
2. report
date January
1995 |
3. report type and dates covered Final |
|||||
|
4.
title and subtitle |
5. funding numbers C — F19628-95-C-0003 |
||||||
|
6. author(s) |
|||||||
|
7. performing organization name(s) and address(es) Software
Engineering Institute |
8. performing
organization |
||||||
|
9. sponsoring/monitoring agency name(s) and address(es) HQ
ESC/XPK |
10. sponsoring/monitoring
|
||||||
|
11. supplementary
notes |
|||||||
|
12.a distribution/availability statement Unclassified/Unlimited, DTIC, NTIS |
12.b distribution
code |
||||||
|
13. abstract
(maximum 200 words) |
|||||||
checklists, software cost estimates, software estimating process, software process improvement, software schedule estimates |
15. number
of pages |
||||||
|
16. Price
Code |
|||||||
|
17. security
classification UNCLASSIFIED |
18. security classification of this page UNCLASSIFIED |
19. security classification of abstract UNCLASSIFIED |
20. limitation
of abstract UL |
||||
|
NSN 7540-01-280-5500 |
Standard
Form 298 (Rev. 2-89) |
||||||
[Abstract]
This report was prepared for the
SEI
Joint Program Office
HQ ESC/DIB
5 Eglin Street
Hanscom AFB, MA 01731-2116
The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange.
FOR THE COMMANDER
[signature on file]
Thomas
R. Miller, Lt Col., USAF
SEI Joint Program Office
Copyright 1995 by Carnegie Mellon University.
NO WARRANTY
THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.
Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.
Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works.
External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent.
This work was created in the performance of Federal Government Contract Number F19628-95-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 52.227-7013.
For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site (http://www.sei.cmu.edu/publications/pubweb.html).
[Abstract]