TechnoPark Corp. Adopts a New Model of Software Development Estimation, Delivers Accuracy

May 14, 2007 - PRLog -- Pre-sales estimation of project costs and durations has been a software dilemma that started with the profession itself. Despite all good intentions, Murphy’s Law seems to leave everyone room to be unhappy about something. Customers expect accuracy and often are disappointed even by what software companies consider minor post-sales adjustments. IT project managers dread giving pre-sales estimates because they know that just about every project has hidden work.

The burning question has been, “Is it possible to make an accurate estimation before the project architecture is built?”

The dream answer of “YES” is all the more desirable for outsourcing software firms, such as TechnoPark Corp., because accuracy is also related to trust and reputation, the cornerstone qualities of any outsourcing company.

Today, TechnoPark Corp. shares its successful experience in the fine art of pre-sales estimation.

First, let’s review the basis of the estimation process. There are some common mistakes and some important issues ignored by many estimators.

A common initial mistake by software development companies is that they estimate the project as if everything will go “just right.” However, it shall not. It is best to estimate the reality of the process, and not some Pollyannaish scenario. Risks ought to be the first things analyzed. Any estimation not based on analysis of all probable risks, in conjunction with a company’s true capabilities, inevitably will result in an estimation of one’s hopes and wishes and not probability.

According to the new model by TechnoPark Corp. a requirements-based model is the most suitable for pre-sales estimation. The source lines of code (SLOC) model, popular in the 1980s-90s, proves to not be effective any longer as coding is significantly more complex and interactive than the number of lines of a program. The SLOC model admittedly still helps with measuring the efforts of a completed project, but that doesn’t help much with estimating before the coding begins.  

Requirements-based estimation, on the other hand, accounts in advance for a project’s features, risks and complexity. Analysis of the requirements provides an estimator with a more abstract but accurate vision, as the estimator views the whole project.

Another golden rule of estimating reads: Estimate the diapason or range, not the precise figure. It usually is impossible to count the precise size of efforts and get a correct estimation at the pre-sales phase. It is better to estimate the spectrum of possibilities and set aside more precise estimation for detailed examination of the project.  
 
In order to get the diapason, three figures for each task are needed: Worst Case (WC) is the maximum amount of person-hours needed to implement the feature and depicts the situation when everything is going wrong; Best Case (BC) is an optimistic estimation providing minimum amount of person-hours; and Most Likely (ML) depicts the situation which is the most probable in an estimators’ assessment, which may be close to either the worst or best case.

“At TechnoPark Corp., we involve three developers each time estimation is facilitated. Two of them provide their versions of WC, BC and ML estimations, and the third one estimates complexity and function points. When counting the diapason of person-hours, we use a number of additional coefficients such as maturity of process, required software reliability, programming language experience, etcetera. After all necessary data are entered, automated counting is implemented by the system based on COCOMO II”, explains Victoria Malinovskaya, the estimation facilitator at TechnoPark Corp.

COCOMO II, or the Constructive Cost Model, is growing in popularity as an estimation model. Its first version, COCOMO 81, was introduced in 1981 by Barry Boehm. The model is used for estimating the number of person-hours and person-months it will take to develop a software product. The first version was based on SLOC counting. COCOMO II appeared in the 1990s.

The power behind COCOMO II is that it is based on function points instead of SLOC. A function point is a rough estimate of a unit of delivered functionality of a software project. To calculate the number of function points for a software project, one counts all of the user inputs, user outputs, user inquiries, number of files and number of external interfaces, dividing them all into simple, average and complex categories.

COCOMO II coefficients and formulas are clear and useful for software development companies, both big and small. The model offered by TechnoPark Corp. is based on COCOMO II with only small fluctuations making it more suitable for outsourcing software development companies.

“With COCOMO II, we have helped the company reduce losses caused by understated estimations by almost 70%,” Malinovskaya said.

Website: www.technoparkcorp.com