TechnoPark Corp. Adopts a New Model of Software Development Estimation, Delivers Accuracy
When it comes to developing software, accurate projections are 80% of the challenge. In an effort to improvement its internal budgeting and to further reduce surprises to clients, TechnoPark Corp. went on a quest to find the most successful method of estimating project cost and duration at the start of each project.
Naples, FL, May 16, 2007 --(PR.com)-- In 2007, a modified Cocomo II model went into operation at TechnoPark Corp. Read on to learn more on the secrets of effective project estimation as revealed by this successful U.S.-based outsourcing software development firm.
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.
Since the 1970s, there have been many attempts to attain this dream of accurate pre-sales estimations of projects. None however have stood up to the rigors of real world challenges and client expectations.
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.
Requirements-based estimation however is not the solution either according to the new model by TechnoPark Corp. Pre-sales estimation needs a general understanding of the project but also needs to account for the details, an area where requirements-based modeling comes up short.
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.
TechnoPark Corp. has adapted the COCOMO II approach to client costing with great success.
“With COCOMO II, we have helped the company reduce losses caused by understated estimations by almost 70%,” Malinovskaya said.
About the company
TechnoPark Corp. is an outsourcing software development firm headquartered in Naples, Florida, USA. Its software development center is based in the Ukraine, Eastern Europe. TechnoPark Corp.'s areas of expertise are Online Payments, VoIP Technologies, Enterprise Application Integration (EAI), and Data Warehousing.
The company develops in Microsoft .Net, Java, Ajax, Flex/Flash, C++ and LAMP, among others.
###
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.
Since the 1970s, there have been many attempts to attain this dream of accurate pre-sales estimations of projects. None however have stood up to the rigors of real world challenges and client expectations.
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.
Requirements-based estimation however is not the solution either according to the new model by TechnoPark Corp. Pre-sales estimation needs a general understanding of the project but also needs to account for the details, an area where requirements-based modeling comes up short.
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.
TechnoPark Corp. has adapted the COCOMO II approach to client costing with great success.
“With COCOMO II, we have helped the company reduce losses caused by understated estimations by almost 70%,” Malinovskaya said.
About the company
TechnoPark Corp. is an outsourcing software development firm headquartered in Naples, Florida, USA. Its software development center is based in the Ukraine, Eastern Europe. TechnoPark Corp.'s areas of expertise are Online Payments, VoIP Technologies, Enterprise Application Integration (EAI), and Data Warehousing.
The company develops in Microsoft .Net, Java, Ajax, Flex/Flash, C++ and LAMP, among others.
###
Contact
TechnoPark Corp.
Victoria Malinovskaya
(239) 243 0206
www.technoparkcorp.com
sales@technoparkcorp.com
Victoria Malinovskaya
(239) 243 0206
www.technoparkcorp.com
sales@technoparkcorp.com
Contact
Categories