Before we continue with on-demand application generators, lets look at something completely different, but related.  Software size and effort estimation (read: cost estimation).

 

There are several formal methods for estimating software size, complexity, effort and cost.  Function Point Analysis, Lines of Code, tools like CoCoMo, SLIM, etc., including the most common technique called Wideband Delphi Estimating where senior programmers, architects, etc., base their estimates on real world experiences while following a formal estimating process.

 

Why do we do estimate?  Every customer I have come across always asks, how much? And shortly followed up with, and when can I get it? And finally, can you make it a fixed price estimate? 

 

Its like getting a building constructed, you need a blueprint to estimate a price for the construction, whether the blueprint is custom designed or "off the shelf". Regardless, the customer had to spend money on acquiring the blueprint. The blueprint puts in scope whether it is a house the customer wants or maybe it turns out to be an apartment complex or skyscraper that the customer really wants, hence the blueprint.  Constructing software is no different, you need a blueprint.  The blueprint we require are Use Case scenarios in order to provide an accurate cost estimate.
 
If we had the use case scenarios written down at this stage, then it would be much easier to come up with an accurate estimate.  However, the customer typically does not understand, that the level of detail we need is way more than the customer has supplied.  Almost always.  And the level of detail is down to documenting use case scenarios, usually a dozen to two dozen scenarios on smaller projects.  The quantifiable output is usually represented as written documentation with an average of 3 pages written per use case scenario, which in our example, means roughly 15 use cases x 3 pages each = 45 pages of  use case documentation.  Based on 15 years in the biz, I can count on one hand where I actually got enough detailed and documented use case scenarios from the customer to come up with an accurate cost estimate, as is.  For people that know me, I usually get requirements written on a cocktail napkin.  Funny, but not enough detail to be sure.

 

Geri Schneider and Jason Winters wrote an excellent book called, Applying Use Cases: A Practical Guide  In the book is a cost estimation model based on using the number of use cases and the complexity rating for each use case as input to the estimation model.  The model outputs effort estimates, with upper and lower bounds and by project phase and iterations of phases, in person days along with the ability to put in labor rates, which then outputs a cost, which then you can apply a contingency factor and out comes the final price estimate.

 

You can calibrate the use case estimation model as you use it over time, based on comparing estimates to actuals.  You can adjust estimating factors around skill sets and culture, plus the ability to calibrate around toolsets employed.  Whats great about it is that it works!  My team and I have used it successfully on a number of projects of varying size and complexity. After several iterations of comparing actual to the estimates, we got our estimation model calibrated within 10 to 20% differential between estimates and actual.

 

How does this tie in with on-demand application generators?  Next post.