Estimates and Scheduling

For a variety of reasons, software development schedules are notoriously inaccurate. In some cases the problem can be attributed to poor management practices. The managers don't factor in all the things they should, fail to schedule tasks based on a critical path, don't keep track of progress, and often have no metrics of earlier projects to guide them in making estimates. Thus, an estimate of the project's completion is no more than a wild guess. (I heard a manager at a large, well-known software company once say that it's all "magic" anyway. With that type ofattitude, I doubt that he will ever ship a product on schedule.) Although some schedule problems are inherent in the way we develop software, estimating software schedules can be improved by using more accurate estimating techniques.

Early Estimates Are Inaccurate

One problem we have is that the estimates are usually made near the start of the development project. Usually an estimate must be provided around the time the requirements are completed. However, at that point in time the development team still only has a general idea of the amount of work needed. Formal measurements of estimated time versus actual time of the project show that estimates made when only the requirements are available are usually 50-100 incorrect. This has led to the standard industry practice of simply doubling the estimates made by the team members in order to get a better overall estimate.

Including Overhead

A second problem is that developers usually base their estimate on the amount of code they think they will need to write and fail to include time for non-coding tasks, or overhead. Overhead includes setup time for new equipment, team meetings, preparing status reports, research and training, vacations, holidays and sick days, etc. In many cases a developer will be pulled away from work on the current projectto make an emergency fix to an older project. Furthermore, the more members there are on the team the more time is used for communications between team members. Some of the overhead is a one-time event, while some of it is ongoing throughout the project. The overhead can add up to 20-40 of the project time. Unless it is added in the estimated schedule will be significantly wrong.

Estimate Actual Activities

In my opinion, the typical problems in estimating software schedules arise because we estimate the wrong thing. The design process steps through the levels of abstraction described in an earlier chapter. Every software process I have ever seen mixes the concepts of level of abstraction and activity. For example, the requirements phase involves a certain level of abstraction and the activity of preparing a document. These methodologies base estimates on the amount of time allocated to each level of abstraction. However, the design process does not really describe the activities of a developer. The list below is a more accurate description of the activities of a software developer.

  • Research
  • Prototyping
  • Implementation
  • Verification
  • Review and revise

We can map each activity to abstraction levels in order to get a better estimate of the amount of time needed. For example, if the developer is familiar with the system, he may need very little time for research and prototyping. However, if the developer must learn a new library or API, additional time will show up under the "Research" category. By analysing each level of abstraction in terms of the activities we can allow for a fine-grain analysis of the amount of time the developer needs. This method also automatically includes time for testing, another area that is usually ignored. When combined with a realistic estimate of overhead this method should provide a much more accurate estimate.

Abstraction Research Prototyping Implementation Verification Review and Revise
Concept Market analysis, customer interviews Initial proposal, possibly informal Preparation of concept document and project plan Comparison of proposal with research Review of proposal and project plan, post mortem review of project.
Requirements Customer interviews Draft document, boilerplate requirements Preparation of requirements document Comparison of requirements with concept. Requirements review, modify and sign-off; system test.
Design Study available technology, libraries, OTS software, patterns, algorithms, etc. Prototype design Design document Comparison of design with requirements. Design review and revision, module test.
Code Libraries, API, protocol. Small programs to exercise a library, API, interface, etc. in or to better understand how to use it. Write code Unit test of code, code review. Correct errors.

Links: