Background

The application and development team that I'm going to estimate has the following characteristics:

1. A formal requirements specification has been written by an experienced business analyst that I trust. The specification includes light use cases, a database design, and screen prototypes for at least the most difficult UI concepts.
2. I counted the Function Points in the application, and the count is 750 FPs. (Function Points are a way to determine the size of an application, like calculating the square feet of a house.)
3. It is a web application.
4. It is a business-to-business application.
5. It's being written to support only one speaking language (English).
6. The application will need to support less than 1,000 simultaneous users.
7. The application will be written in Java.
8. Two new technologies are being used in application development, Hibernate for database interaction, and some AJAX UI elements.
9. Except for one person, the developers on the team all have five or more years experience, and they have all worked together before. There is one new person on the team with two years of Java programming experience, but he used Swing and has not worked on web applications.
10. The testing team members are also familiar, and we have worked together on previous projects.
11. The project sponsor and other "customers" for this application have worked on software development projects previously.

As you can see from that list, I think all of these variables are important when making an estimate. Project specifications vary from one business analyst to another. No two development teams are the same. Customers that haven't worked on software development projects need to be "trained" (for lack of a better term). New technologies affect productivity.

Size of the project is also very important. Small projects are easy, longer projects much harder, and I don't mean linearly harder. At some point trying to tackle too much all at once makes complexity increase more exponentially than linearly. Think of all the recent delays with Windows Vista, and you'll know what I mean. Even Steve Ballmer said they will never try to change so many things at one time ever again.

Finally, I will also add that if you don't have a formal requirements specification, I don't think you can really estimate a project. How can you estimate what you don't know? At the end of this tutorial I will show you one "back of the envelope" approach I have used when first discussing business application during the conceptual phase, but that's as close as I can imagine to estimating a given project without a proper requirements document.

Up: Cost-Estimating Previous: Introduction Next: Estimating using FPA and   Contents