Estimation

Notes for Chapter 8 of Rapid Development by Steve McConnell.

1. Tell a story why estimation is difficult

1.a Software and contruction.
It is difficult to know whether u can build the product that the customer wants in the desired time frame until u have a detailed understanding of what he wants.

1.b Software development as a process of refinement
Until each feature is understood in detail, you can't estimate the cost of a program precisely. Software development is a process of making increasingly detailed decisions: product concept->statements of requirment->preliminary design->detailed design->working code. (the uncertainty principle)

At different stage the estimation error is different.

Phase Effort and Size Schedule
Initial Product Concept (0.25, 4.00) (0.60, 1.60)
ApprovedProduct Concept (0.50, 2.00) (0.80, 1.25)
Requirment specification (0.67, 1.50) (0.85, 1.15)
Product design specification (0.80, 1.25) (0.90, 1.10)
Detailed design specification (0.90, 1.10) (0.95, 1.05)

1.c Estimation vs. control

The features and resources have to meet each other, sometimes one bends to meet the other, sometimes both bend to meet in the middle. Like building a house, you can build to budget, or build your dream home.

1.d. Cooperation

Ask the customers the estimation information you need, and give them the update as always. Estimates can be refined over the course of a project. Promise customers that u will provide more refined estimates at each stage.

1.e. Convergence of the estimate and reality
Shortest actual schedule comes from the most acturate estimate, either too optimistic or pessimestic estimate ends up with more cost.

Note: accuracy and precision
40 man-months is accurate, 45 months is more procise, but may not be accurate at all.

2. Estimation process overview

2.a Estimate the size of the product (number of lines of code or function points);
2.b Estimate the effort (man-months)
2.c Estimate the schedule(calendar month)
2.d Provide estimates in ranges and periodically refine the ranges to increase precision as the project progresses.

3. Size estimation

3 ways: algorithm approach, software tools, use a similar project (nearest neighbor?)

Some tips:
1. Avoid off-the-cuff estimates. don't give any estimate when you are not familar with the task.
2. All time for the estimate and plan it.
3. Use data from previous projects.
4. Use developer-based estimates.
5. Estimate by walking-through. Ask team members to estimate pieces of the project individually, and have a walk-through meeting to discuss the each piece until reaching the consensus.
6. Estimate by categories.
7. Estimate at a low level of detail.
8. Don't omit common tasks, such as demo, data conversion, installation, customization, meetings, maintenance, defect corrections, QA, user documentation, reviewing, etc.
9. Use tools;
10. Use several different techniques, and compare them.

Presentation of the estimate
1. Plus/minus qualifiers: 6 +- 3month; (con: reviewer may only look at 6 months)
2. Ranges [3, 9] month
3. Risk quantification

Estimate 6 month +3 month, -2 months
+1 for late delivery of formating system;
+1 for new tools not working;
+0.5 for staff sickness;
+0.5 month for ...
-1 less delay on hiring effort;
-1 tools better than expected.

4. Cases: best case, worse case, planned case, and current case.
5. Coarse dates and time periods
6. Confidence factors
Apr 1: 5%
May 1: 50%
June 1: 95%

4. Effort estimate
Based on size estimation, do the effort estimate:
4.a. Use tools;
4.b. Look up table;
4.c. Historical data;
4.d. Algorithm approach.

5. Schedule estimation

Optimal Schedule in months = 3.0 * power(man-months, 1/3).
Optimal number of members = man-months/optimal scheduled months.

Commitment based scheduling

Pro:

• increase the developers' buy-in to schedules;
• High morale for the period immediately following the commitment;
• Elicit a lot of voluntary overtime from the developers;

Con:

• Developers usually 20~30% optimistic, commitment based scheduling encourages this optimism and create larger estimation errors;
• Commitment based planning is good only if the it is an accurate one, otherwise it may depress the members.

6. Ballpack schedule estimates

Background

3 types of projects:

• System software (not include firmware, real-time embedded software, process control etc)
• Business software
• Shrink-wrap software

Use the combination of those 3 to get the schedule.

I.e: a sw is composed of 60% system sw(5 month), 40% business sw (5 month), total = 0.6*5+5*0.4=5 months.

Schedules (calendar year)

Efforts (man-months)

System sizes

Small projects

The project less than 10K lines is typically assigned to one person, the schedule depends on the person's capability, who is the best to estimate the effort.

Line of code

Accuracy of the estimates

Assumptions to consider in the schedule

• staffing,
• management,
• tool support,
• methodology,
• compression

Two facts of life

• There is a shortest possible schedule, and you cannot beat it;
• Costs increase rapidly when you shorten the schedule blow the norminal.

2 schedules (require different assumptions and cost):

• Shortest schedule;
• Efficinet schedule;
• Norminal schedule

7 Estimate refinement

The accuracy of software estimate depends on the the leve of refinement of the software definition. U have to do the estimate refinement in the work of software project development.

Single point estimation contains tremendous imprecision.

Recalibration

If the milestone is missed, recalibrate the schedule. Options:

1. Make up the lost time;
2. Add the amount of time to the total schedule
3. Multiply the whole schedule by the magnitude factor of the slip.

Some researches show:

1. Projects hardly ever make up lost time.
2. It is rarely true that only the one slips is inaccurate, typically all estimates need to be calibrated.
3. Use option #3