wissel.net

Estimating software project cost and duration seems to have parallels with the local weather reports: You simply can't rely on them. Waterfall project approaches are partly to blame. Estimating the amount of work units for a requirement is another. How much work is "The system needs to be user friendly"? For the sake of this post lets us presume your have a magic box, typically labeled experience, either explicit or implicit, that gives you an insight how much code you need. Once you know how much code (a.k.a. LOC or "lines of code") you need to write, estimation becomes manageable. A good tool to estimate is COCOMOII. With the LOC, COCOMOII and your average hourly cost you can estimate the cost easily (Thanks Mitch).
However using a visual development environment (Visual Studio, Eclipse, Adobe Studio, Domino Designer) makes things a little more complicated. A form or a view you draw is not a line of code. The UML model you paint (that will turn into a database schema and code classed via generation) is not a line of code. So you need to expand your mental estimation model slightly. There are two new terms to get familiar with:

• LOC_TE = "Lines of Code - Time Equivalent": The time for painting one form is equivalent to writing how many lines of code?
• LOC_AL = "Lines of Code - Avoided Lines": When you paint one form how many lines of code can you avoid to write? The whole promise of any visual environment is, that LOC_AL > LOC_TE. This probably varies from platform to platform and makes an excellent subject for a bar brawl between competing developer camps. I guess you won't find much information about that ratio since nobody ourdays would afford to build a system twice.

Where does that leave you for Notes or Domino estimations? You need to find your magic number for LOC_TE for the various design elements (see graphic below) and then apply the COCOMOII estimation. Of course you could simply use time estimates (by revisiting your past projects), then however you need to calculate your own project variance based on project complexity and team experience. Neglecting experience and complexity are the great fallacies happily endulged in by project planners with too little experience in software project estimations. The difference for a similar sized project can be 500% from "very experienced team working on a low complexity project" to "unexperienced team working on a high complexity project". Even if you just consider experience you will still have to shell out more than double the money (230%), 70% more people and 40% more calendar time for an inexperienced team.

The orange boxes are most likely what you will get out of the discussion with the business users, including some of the yellow boxes. For the red ones you can directly insert lines of code. How do you estimate your projects?