Basics of Estimating - How to be a Successful Technical Architect for J2EE Applications

Basics of Estimating

Many technical people consider estimating difficult, and indeed, at this stage, it is definitely as much art as it is science. This chapter presents a method of determining a gross estimate based on information you should have from the use-case analysis and the prototypes. I make no claims that my way of estimating is the only way. If you have an approach you're comfortable with, stay with it.

Estimates formed at the beginning of a project should be revisited periodically and refined after more detailed planning and designing are done. After defining the external interfaces and completing object and data modeling, you will be in a better position to make more accurate estimates. Estimates you make now should be detailed enough that you can use them in estimating any combination of use cases. Ideally, the business side looks at cost/benefit comparisons when deciding on scope.

Estimate in terms of the slowest resource on the team. We all know that some people take less time on development tasks than do others. I would rather deliver a project early than have to explain why it's going to be late.

Estimates should be proportionally balanced. I have found that a typical development team spends about one-third of its resource budget planning and designing, one-third coding and unit testing, and one-third supporting system-and user-testing activities. Keep in mind that some portion of the planning and design budget was spent performing the use-case analysis described in the previous chapter (I usually assume that planning and design is 50 percent complete at this point). These ratios apply to the entire life of the project.

Consider the time needed to set up the development, testing, and production environments. Most companies provide established environments at the enterprise level. For example, many companies have a central administration team to establish environments for development, testing, and production of new applications. If your company has such a team, time allocated to environment setup will be low and not usually material for preliminary estimates. If this isn't the case at your company, you should add an estimate for setting up environments.

Developers are more successful at estimating coding and unit-testing tasks than anything else. If you can get a reasonable coding and unit-testing estimate, you can extrapolate the rest using the ratios mentioned previously and get a ballpark estimate. Note that to extrapolate a total estimate based on those ratios, you just multiply the coding and unit-testing estimate by 2.5, assuming that planning and design is 50 percent complete at the time you estimate.