Software Estimation BlogInformation on Cost Estimation & Software Estimating

Hey, welcome to 2009! It’s taken a while, but we’re finally at the point where we can go ahead and make our first estimate.

But first, a recap of the first four steps in software estimation process.

• Understanding the problem – not just what you want to estimate, but why you want to estimate it.
• Know the rules – Estimates are bound by rules and measurements, and you need to know what you’re measuring before you rush off and start.
• Data Collection – Make use of organized work sheets so that you can keep everything organized. If you need to know what to put on said worksheet, look back to steps 1 and 2.
• Identify Work Already Done – Sometimes, it’s more cost effective to look elsewhere for solutions.

By the time you get here, to step number 5, you’ve already done a great deal of work regarding your estimate. You’ve pondered, you’ve measured, you scribbled down numbers, you’ve looked at the entirety of the problem and you’ve broken it down into measureable parts. Now, it’s time to plug it all into a machine.

If you haven’t already, it’s a good idea to have a familiar set of eyes look over your work before handing it off to the computer, just to weed out any potential for human error. If you’re working on a project for a client, show them the numbers too.

After that, it’s time to run your first software estimation, establishing the baseline from which all other estimates and changes will be measured.

Keeping up with the idea that we’re doing software estimating to create a software package, let’s go ahead and give a long look at our intended project. The first question you’re going to have to ask yourself is how big is this project going to be?

If this is code, how much is necessary? How much can be recycled?

If you’re writing new software, one of the key determining factors for all other estimates is going to be the sheer size of the project as measured in Source Lines of Code (SLOC). This sounds like an obvious place to start, but whether your under the influence of inspiration or the crush of deadlines, a project can easily bloat out of control.

Though you’re likely going to want to restrain your SLOC to the lowest number of lines possible, you’re going to want to give yourself a cushion in your initial SLOC estimate. One popular estimation method is to draw up three numbers, the least possible number of lines, the probable or likely number, and the outside largest number.

Once you know the likely sizes of your project, you can then start to whittle down the involved labor. Is there Commercial-off-the-shelf  (COTS) software that can be incorporated to help achieve the desired solution? Have you developed prior pieces of code, modules that can be incorporated? These pre-existing solutions will have an impact on your SLOC, but also the cost and time of the project, proving that while SLOC might grow or contract, the relationship between SLOC and the total cost of the software is not a solely dependent relationship.

Coming up with these answers ahead of time helps to prepare the overall software estimate by providing a more complete picture of the desired project. Understanding the source before you start it, and determining the best courses of action regarding COTS, FOSS, and pre-existing code solutions is a good method for creating shortcuts and cost savings well ahead of when they’ll actually be needed. Doing so is a lot like plotting a vacation on a map before you start the trip. Even though you have never been where you’re going, you’ll have a fleshed out idea of where you’re going, how long the trip is going to take, and whether anyone has been nice enough to already build bridges for you.

And, once you have that knowledge, you’re much better suited to answer the proverbial question, “Are we there yet?”