The Mistake of Measuring Everything
I recently participated in a seminar with Larry Dribin of Pearl Street Group. Larry did a beautiful job with a talk called something like “You Get What You measure” Afterwards I added the corollary “If you measure everything you get nothing”
I have seen a number of organizations that just start measuring everything. They figure they will do something with the measurements sometime. Measurement becomes a burden with no ROI. And people can’t respond by doing the best job on what they are measured against. Read more
Step Nine: Document Estimate and Lessons Learned
Each time you complete an estimate and again at the end of the software development, you should document the pertinent information that constitutes the estimate and record the lessons you learned. By doing so, you will have evidence that your process was valid and that you generated the estimate in good faith, and you will have actual results with which to calibrate your estimation models. Be sure to document any missing or incomplete information and the risks, issues, and problems that the process addressed and any complications that arose. Also document all the key decisions made during the conduct of the estimate and their results and the effects of the actions you took. Finally, describe and document the dynamics that occurred during the process, such as the interactions of your estimation team, the interfaces with your clients, and trade-offs you had to make to address issues identified during the process. Cost models, which are based on the actual costs of past projects, can be calibrated and their accuracy can be demonstrated by comparing the costs of your current estimates with both past project data and the actual costs of your completed project, thereby adjusting the model input parameters to improve future accuracy.
Step Eight: Generate A Project Plan
The process of generating a project plan includes taking the estimate and allocating the cost and schedule to a function and task-oriented work breakdown structure. Models such as SEER Client for Microsoft perform this function automatically. The eight major software development phases
are: (1) concept, (2) acquisition, (3) requirements, (4) design, (5) code and unit test, (6) integration, (7) acceptance, and (8) post deployment.
Determining Costs from Effort Estimates
At this point in the estimation process, you should have a reasonably accurate projection of your project’s size and required effort, that is, an estimate of the number of person-hours by component and a sum of these projections, and you can now begin to price the estimate. As software estimation models generally account only for costs related directly to development, you may need to translate the required effort to a cost and finalize the estimate by adding in essential nonlabor costs. You can do so by answering the following questions:
What types of individuals do I need and when do I need them?
Identify the specific personnel requirements by task area (direct software management, software systems engineering, design, programming, configuration management, quality assurance, etc.). Develop a strawman schedule from the work breakdown structure or a staffing plan such as the one produced by SEER-SEM.
How experienced do they have to be? Assign specific staff levels to the task requirements and identify the level of experience required to satisfy the task. Some of the automated cost models will identify the tasks and develop a task-based schedule, which will minimize but not eliminate all of the work required to produce the software development plan.
Step Seven: Estimate Validation and Review
Step Seven: Estimate Validation and Review
At this point in the process, your estimate should already be reasonably good-but it may not be as good as you think. It is important to verify your methods and your results in a step called validation, which is simply a systematic confirmation of the integrity of an estimate. By validating the estimate, you can be more confident that your data is sound, your methods are effective, your results are accurate, and your focus is properly directed.
It may be tempting to skip this review due to a lack of time, personnel or budget, and there is the unappealing possibility that a close examination may reveal faults in the logic of your process. Nevertheless, the costs involved in performing a proper validation will be dramatically less than the cost overruns that are likely to develop during a poorly managed software project.
There are many ways to validate an estimate. Both the process used to build the estimate and the estimate itself must be evaluated. Ideally, the validation should be performed by someone who was not involved in generating the estimate itself, who can view it objectively. The analyst validating an estimate should employ different methods, tools and separately collected data than were used in the estimate under review.
Step Five: Prepare Baseline Estimate
Budget and schedule are derived from estimates, so if an estimate is not accurate, the resulting schedules and budgets are likely to be inaccurate also. Given the importance of the estimation task, developers who want to improve their software estimation skills should understand and embrace some basic practices. First, trained, experienced, and skilled people should be assigned to size the software and prepare the estimates. Second, it is critically important that they be given the proper technology and tools. And third, the project manager must define and implement a mature, documented, and repeatable estimation process.
To prepare the baseline estimate there are various approaches that can be used, including guessing (which is not recommended), using existing productivity data exclusively, the bottom-up approach, expert judgment, and cost models.
Software Productivity Laws
These laws of software productivity help explain the dynamics of an engineering development project, and they illustrate some of the reasons that just using productivity to estimate is inadequate.
Law 1 - Smaller teams are more efficient. The smaller the team, the higher the productivity of each individual person.
Law 2 - Some schedule compression can be bought. Adding people to a project, to a point, decreases the time and increases the cost as larger teams work together.
Law 3 - Every project has a minimum time. There is an incremental person who consumes more energy than he or she produces. Team size beyond this point decreases productivity and increases time. (Law 3 is also known as Brooks’ law.)
1990 IEEE Article On Measurement
I forgot about this article published on IEEE in 1990.. sizing, metrics, measurement.. lessons learned and forecasting the future… The Ada programming language may be only a memory but some things never change. Viewing the article requires electronic access to the IEEE library. I loook forward to comparing these lessons learned with the 2008 lessons learned briefing from Galorath (Bob Hunt Author)
| Ada sizing, metrics and measures-learning from the past andforecasting the future Galorath, D.D. McRitchie, K. Rampton, J.C. Galorath Associates Inc., Marina del Rey, CA; This paper appears in: Instrumentation and Measurement Technology Conference, 1990. IMTC-90. Conference Record., 7th IEEE |
 |
|
|
| Abstract It is noted that Ada has met with mixed successes owing to both differences in the technology applied to the program and differences in line counting and productivity measurement. The authors discuss the various technologies attributed to Ada and demonstrate methods of Ada size and productivity measurement that are appropriate for Ada and consistent with past data |
|
|
|
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/105/2373/00066027.pdf?arnumber=66027
Step Four: Software Sizing
Size is generally the most significant (but certainly not the only) cost and schedule driver. Overall scope of a software project is defined by identifying not only the amount of new software that must be developed, but also must include the amount of preexisting, COTS, and other software that will be integrated into the new system. In addition to estimating product size, you will need to estimate any rework that will be required to develop the product, which will generally be expressed as source lines of code (SLOC) or function points, although there are other possible units of measure. To help establish the overall uncertainty, the size estimate should be expressed as a least-likely-most range.
Predicting Size
Whenever possible, start the process of size estimation using formal descriptions of the requirements such as the customer’s request for proposal or a software requirements specification. You should reestimate the project as soon as more scope information is determined. The most widely used methods of estimating product size are:
Ten-step Project Estimation Process
Software Estimation Concepts
Many project managers and project management offices have unrealistic expectations about estimates. The definition of the verb estimate is to produce a statement of the approximate value of some quantity. Estimates are based upon incomplete, imperfect knowledge and assumptions about the future. For these reasons, many estimates of software costs tend to be too low due to omissions of important product functions and project activities. Most importantly, however, all estimates have uncertainty. There is no such thing as a precise, single-value estimate. Managers should always ask how large the uncertainty of an estimate is! A manager can use the size of this uncertainty in conjunction with other factors such as perceived risks, funding constraints, and business objectives to make decisions about a project.
How can projects address the uncertainty of poor estimates? How can the risks associated with initial estimates be identified, managed, and controlled? The answer is straightforward: by defining, establishing, planning, and applying a consistent, repeatable, and effective estimation process.
A software estimation process that is integrated with the software development process can help projects establish realistic and credible plans to implement the project requirements and satisfy commitments. It also can support other management activities by providing accurate and timely planning information. Realistic plans will also describe how the resources that are required to undertake the initiative in accordance with the schedule will be secured. The planning process, as critical as it is, is difficult and takes time to perform correctly. Managers often truncate the planning process by using “easily available” information that is often inadequate; by employing whoever has the time, even if those individuals are not qualified to perform the estimate; and by using only one estimation method to save time.
Successful software engineering requires the application of engineering principles guided by informed management. The principles must them-selves be rooted in sound theory. While it is tempting to search for miracles and panaceas, it is unlikely that they will appear. The best course of action is to stick to age-old engineering principles. There simply are no silver bullets.
Cost estimates are projections of required effort, time, and staffing levels. Because all estimates, particularly those made at the beginning of a project, are based on assumptions, they should be considered probabilistic. Cost estimates in particular should provide a range with an indication of accuracy, i.e., least, probable, and most, with the least and most values representing the upper and lower bounds of the projected cost.
Project Estimation Process
Ideally an estimate should be produced using the ten-step process.
During October we will cover each step on this blog.
Figure 1 Ten-step project estimation process
- Establish estimate scope
- Establish technical baseline, ground rules & assumptions
- Collect data
- Size software
- Prepare baseline estimates
- Quantify risks & risk analysis
- Review, verify, validate estimate
- Generate a project plan
- Document estimate & lessons learned
- Track project throughout development
Barriors to Adopting Estimation Technology & Applications
A reader requested I chime in on The biggest barriers I see to adopting estimation technologies and tools. So here goes the first draft.
- Not Invented Here: Some people think that their environment is so unique that it cant be estimated… or that estimation applications like SEER can’t handle their unique scenarios. I have never seen a case where this was true once the organization tried. Or sometimes an expert has their own spreadsheet and they don’t want to let go of that control.
- Don’t Want To Know: Sometimes the answers from estimation technology are longer or more costly than stakeholders want to hear. Read more
Lines of Code Versus Functon Points Versus Use Cases For Sizing
I, along with many others, have written about the virtues of one size metric versus another. Some attempt to make their measure look better by bashing the others (a curious approach used by too many, in my opinion)
