Software development outsourcing has now become commonplace. So, it has become necessary for the outsourcer and the provider to reach an agreement about the size, development effort, cost, and development schedule of the software product being outsourced. This has caused software estimation to move from hunch-based estimation to the use of mature, research-backed estimation techniques. The process of estimation has also moved from manual estimation using spreadsheets to tools.
The stakes in software estimation are high. Underestimation may cause the project to be unprofitable for the vendor; overestimation may cause the project to be lost to the competition. Similarly, the outsourcer may end up paying more if software is overestimated; if underestimated, the outsourcer's budget may be overshot. While software estimation is still a creative endeavor, tools help relieve the mundane aspects of it and allow the estimator to concentrate on the creative aspects of estimation.
Software estimation includes the following four aspects: software size, software cost, software effort, and software delivery schedule.
A plethora of software estimation tools are available to choose from in the market, and it is often difficult to arrive at an educated decision on which tool to purchase. As usual, vendors always claim that their tools are better than the competition's in that they are the most scientific and suited to any type of software project or organization.
This article outlines eighteen criteria for selecting the right software estimation tool, and attempts to educate professionals so that they can make informed choices when buying a software estimation tool.
Units of Measure for Software Size
It is a known fact that there are multiple measures of software size, namely, lines of code (LOC), function points, use case points (UCP), feature points, and so on. And each of these sizing measures has a sizable following. As a result, there is no agreement among information technology (IT) professionals on what the best unit of measure for software size is. There are many reasons for this.
The programming platforms of these measures differ widely—mainframes, midrange, personal computers (PCs), networked applications, and finally, Internet-based software applications. The development platforms range from common business-oriented language (COBOL) to graphical user interface (GUI) tools to Internet programming languages. The application architectures have moved from one tier to multi-tiered applications.
There is a difference of opinion on what constitutes an LOC. Variable declaration, comments, and length of an LOC bear different connotations to different perspectives. A vendor would like to count all, but a buyer would not.
GUI programming, in which a significant code is predeveloped, adds one more dimension to the debate on LOC. This type of programming has moved away from procedure-oriented programming toward event-oriented programming. Now GUI controls are added to LOC, and there is confusion on how to measure the size of GUI.
Several projects, such as those involving software maintenance and testing, are not full development life cycle projects, and there is confusion on how to measure the size of these.
Therefore, criterion number one for selecting a software estimation tool is
* the tool must allow multiple units of measure for software size
In other words, the tool must allow the user to carry out software estimation using multiple, commonly used software size measures.
Common Unit of Measure for Software Size
Now the question becomes—if the size measurement is carried out using different software size measures, how does the organization measure its productivity and capacity? Measurement of an organization's software development productivity is possible only when the software size is measured using one unit of measure.
Therefore, the second criterion for selecting a software estimation tool is
* the tool must enable conversion of multiple units of measure into one unit of measure for the software size to become a standard in the organization
There are no differences in opinion among IT professionals when talking about software costing. Everyone agrees that software costing must be measured in the currency of the country, be it dollars, euros, rupees, etc. While software development effort in person days (PD) is the major cost source, other cost items come into play while estimating the cost of software to be developed. It is likely that the additional cost items vary from organization to organization in terms of variety and unit cost. So, the tool must allow for parameterization and maintenance of cost items (that is, adding, modifying, and deleting of data for cost items). It is also likely that PD costs vary from project to project as well.
Therefore, the third, fourth, and fifth criteria for selecting a software estimation tool are
* the tool must allow software cost estimation
* the tool must provide for parameterization of PD cost
* the tool must provide for maintenance of cost items
Scheduling the Software Project
Effort is estimated for three reasons: (1) to commit to a delivery schedule with the client, management, or users; (2) to estimate the resources required to execute the project; and (3) to estimate the cost of the project to allow for accurate funds allocation or pricing, with the objective of cost and profit optimization.
We have already enumerated that the software estimation tool caters to reasons number 2 and 3 above. While so, developing a schedule for delivery commitment to stakeholders (the first reason) is by no means an insignificant one. Scheduling is a creative task and an activity that calls for human ingenuity; it cannot be fully automated. Equally important is the fact that there is no accepted or standard way of apportioning a percentage of project effort to a given phase or activity.
The advantages of deriving a schedule from estimate ought to be (1) that the schedule is efficient; (2) that the schedule caters to allocation of resources and can be adjusted accordingly; (3) that the schedule allows for allocating effort in PD to different phases; and (4) that the schedule is sufficiently detailed and exportable to an intermediate file from which it can be taken into a full-fledged program evaluation and review technique/critical path method (PERT/CPM) package like MS-Project and Primavera.
Therefore, the sixth to the eleventh criteria for selecting a software estimation tool are
* the tool must provide for scheduling the project
* the schedule must be derived from the estimated effort
* the tool must automate schedule generation to the extent feasible
* the tool must allow for human intervention when creating the schedule
* the generated schedule must have adequate detail and must be exportable to a familiar intermediate program such as MS-Excel
* the tool must be based on estimated PD, but allow for scheduled PD to be different from the estimated PD
This eleventh criterion is so because when we honestly estimate the effort in PD and then schedule it, the scheduled PD overshoots the estimated PD due to loss of time in personnel allocation, fragmentation of work, idle time, and start-to-finish relationships.
Estimation for Part Life Cycle Projects
Significant projects, such as software maintenance, enterprise resource planning (ERP) implementation, and testing projects, are not full software development life cycle (SDLC) projects. The software estimation tool has to cater to these projects too, using such techniques as task-based estimation. Task-based estimation is parameterized so that different project types can be defined and used by the organization.
Therefore, the twelfth criterion for selecting a software estimation tool is
All software should be built with users in mind. An expert can work with any tool, but the main distinguishing characteristic of a good software estimation tool is that it can produce an expert-quality output even from a person of average expertise. This distinction can be achieved by building a tool with an intuitive interface that keeps the need for training on how to use the tool to a minimum. This is possible with the availability of GUI tools. It is also possible to use the wrong controls, which places a strain on the user instead of making usage of the tool easier. Oftentimes, software tools are developed with a focus on making the user interfaces more appealing rather than on being functional, making the tool more complex to use. The tool must be geared more toward functionality and usability than to jazziness. A simple user interface (UI) is always the better UI.
Therefore, the thirteenth criterion for selecting a software estimation tool is
* the tool must be built with usability in mind, and with an intuitive interface that makes it easier for a person with average skills to quickly master the tool
Usage of Popular Software Sizing Techniques
Software estimation is perhaps as old as software development itself. Some estimation techniques have become popular and are used by many organizations. Especially common are the LOC, function point analysis (FPA), and UCP techniques. Two other widely used techniques are object points and feature points.
Therefore, the fourteenth criterion for selecting a software estimation tool is
* the tool must provide for as many commonly used software estimation techniques possible
Auditability
"Two heads are better than one" is a well-known dictum, and it forms the basis of software inspections, reviews, and walkthroughs. Therefore, it is unnecessary to say that the estimate made by one person, however diligent and expert that person may be, needs to be reviewed by one more peer. The software estimation tool must provide for making a detailed estimate so that this estimate can be reviewed and improved upon. This detailed estimate also assists in reconciling with actual effort spent on the project in order to draw lessons from the experience, and improve the process of estimation in subsequent projects.
Therefore, the fifteenth criterion for selecting a software estimation tool is
* The tool must provide for making estimates that are auditable
Reporting Capability
The result obtained by estimating is to be submitted to the client, management, or user. These reports should not include the unnecessary details, but present only the details that are required.
Therefore, the sixteenth criterion for selecting a software estimation tool is
* the tool should generate a summary report and a detailed report for every estimate made, as well as a summary report of all estimation's made on the tool
Estimator Productivity
It is extremely important to keep in mind the pressure that the estimators, who are usually either project leaders or project managers, are under. The software estimation tool must facilitate picking data from a predefined list as much as possible so that estimators are not required to type the data inputs into the tool. It is also likely that projects in an organization are similar in nature, though certainly not identical. Therefore, the tool must also enable the ability to copy an existing estimate and to modify it to generate a new estimate. This saves a great deal of the estimator's time and therefore money for the organization.
Therefore, the final two criteria (seventeenth and eighteenth) for selecting a software estimation tool are
* the tool must provide for selection from a list of choices as much as possible
* the tool must allow the "copy, modify, and generate" process for a new estimate
Summary
Software estimation is a critical activity for an organization engaged in software development. A software estimation tool helps in generating a professional quality estimate from a person with average skills in software estimation. There is a vast selection of software estimation tools available. As is normal, the available software tools come in all "colors and flavors," and range in price from $50 to a few thousand dollars (US). It is not necessarily true that expensive tools are superior to those that are lower in price. Prospective buyers can assess and evaluate the tools under consideration against these eighteen criteria in order to make the selection that is right for their organizations.
The stakes in software estimation are high. Underestimation may cause the project to be unprofitable for the vendor; overestimation may cause the project to be lost to the competition. Similarly, the outsourcer may end up paying more if software is overestimated; if underestimated, the outsourcer's budget may be overshot. While software estimation is still a creative endeavor, tools help relieve the mundane aspects of it and allow the estimator to concentrate on the creative aspects of estimation.
Software estimation includes the following four aspects: software size, software cost, software effort, and software delivery schedule.
A plethora of software estimation tools are available to choose from in the market, and it is often difficult to arrive at an educated decision on which tool to purchase. As usual, vendors always claim that their tools are better than the competition's in that they are the most scientific and suited to any type of software project or organization.
This article outlines eighteen criteria for selecting the right software estimation tool, and attempts to educate professionals so that they can make informed choices when buying a software estimation tool.
Units of Measure for Software Size
It is a known fact that there are multiple measures of software size, namely, lines of code (LOC), function points, use case points (UCP), feature points, and so on. And each of these sizing measures has a sizable following. As a result, there is no agreement among information technology (IT) professionals on what the best unit of measure for software size is. There are many reasons for this.
The programming platforms of these measures differ widely—mainframes, midrange, personal computers (PCs), networked applications, and finally, Internet-based software applications. The development platforms range from common business-oriented language (COBOL) to graphical user interface (GUI) tools to Internet programming languages. The application architectures have moved from one tier to multi-tiered applications.
There is a difference of opinion on what constitutes an LOC. Variable declaration, comments, and length of an LOC bear different connotations to different perspectives. A vendor would like to count all, but a buyer would not.
GUI programming, in which a significant code is predeveloped, adds one more dimension to the debate on LOC. This type of programming has moved away from procedure-oriented programming toward event-oriented programming. Now GUI controls are added to LOC, and there is confusion on how to measure the size of GUI.
Several projects, such as those involving software maintenance and testing, are not full development life cycle projects, and there is confusion on how to measure the size of these.
Therefore, criterion number one for selecting a software estimation tool is
* the tool must allow multiple units of measure for software size
In other words, the tool must allow the user to carry out software estimation using multiple, commonly used software size measures.
Common Unit of Measure for Software Size
Now the question becomes—if the size measurement is carried out using different software size measures, how does the organization measure its productivity and capacity? Measurement of an organization's software development productivity is possible only when the software size is measured using one unit of measure.
Therefore, the second criterion for selecting a software estimation tool is
* the tool must enable conversion of multiple units of measure into one unit of measure for the software size to become a standard in the organization
There are no differences in opinion among IT professionals when talking about software costing. Everyone agrees that software costing must be measured in the currency of the country, be it dollars, euros, rupees, etc. While software development effort in person days (PD) is the major cost source, other cost items come into play while estimating the cost of software to be developed. It is likely that the additional cost items vary from organization to organization in terms of variety and unit cost. So, the tool must allow for parameterization and maintenance of cost items (that is, adding, modifying, and deleting of data for cost items). It is also likely that PD costs vary from project to project as well.
Therefore, the third, fourth, and fifth criteria for selecting a software estimation tool are
* the tool must allow software cost estimation
* the tool must provide for parameterization of PD cost
* the tool must provide for maintenance of cost items
Scheduling the Software Project
Effort is estimated for three reasons: (1) to commit to a delivery schedule with the client, management, or users; (2) to estimate the resources required to execute the project; and (3) to estimate the cost of the project to allow for accurate funds allocation or pricing, with the objective of cost and profit optimization.
We have already enumerated that the software estimation tool caters to reasons number 2 and 3 above. While so, developing a schedule for delivery commitment to stakeholders (the first reason) is by no means an insignificant one. Scheduling is a creative task and an activity that calls for human ingenuity; it cannot be fully automated. Equally important is the fact that there is no accepted or standard way of apportioning a percentage of project effort to a given phase or activity.
The advantages of deriving a schedule from estimate ought to be (1) that the schedule is efficient; (2) that the schedule caters to allocation of resources and can be adjusted accordingly; (3) that the schedule allows for allocating effort in PD to different phases; and (4) that the schedule is sufficiently detailed and exportable to an intermediate file from which it can be taken into a full-fledged program evaluation and review technique/critical path method (PERT/CPM) package like MS-Project and Primavera.
Therefore, the sixth to the eleventh criteria for selecting a software estimation tool are
* the tool must provide for scheduling the project
* the schedule must be derived from the estimated effort
* the tool must automate schedule generation to the extent feasible
* the tool must allow for human intervention when creating the schedule
* the generated schedule must have adequate detail and must be exportable to a familiar intermediate program such as MS-Excel
* the tool must be based on estimated PD, but allow for scheduled PD to be different from the estimated PD
This eleventh criterion is so because when we honestly estimate the effort in PD and then schedule it, the scheduled PD overshoots the estimated PD due to loss of time in personnel allocation, fragmentation of work, idle time, and start-to-finish relationships.
Estimation for Part Life Cycle Projects
Significant projects, such as software maintenance, enterprise resource planning (ERP) implementation, and testing projects, are not full software development life cycle (SDLC) projects. The software estimation tool has to cater to these projects too, using such techniques as task-based estimation. Task-based estimation is parameterized so that different project types can be defined and used by the organization.
Therefore, the twelfth criterion for selecting a software estimation tool is
All software should be built with users in mind. An expert can work with any tool, but the main distinguishing characteristic of a good software estimation tool is that it can produce an expert-quality output even from a person of average expertise. This distinction can be achieved by building a tool with an intuitive interface that keeps the need for training on how to use the tool to a minimum. This is possible with the availability of GUI tools. It is also possible to use the wrong controls, which places a strain on the user instead of making usage of the tool easier. Oftentimes, software tools are developed with a focus on making the user interfaces more appealing rather than on being functional, making the tool more complex to use. The tool must be geared more toward functionality and usability than to jazziness. A simple user interface (UI) is always the better UI.
Therefore, the thirteenth criterion for selecting a software estimation tool is
* the tool must be built with usability in mind, and with an intuitive interface that makes it easier for a person with average skills to quickly master the tool
Usage of Popular Software Sizing Techniques
Software estimation is perhaps as old as software development itself. Some estimation techniques have become popular and are used by many organizations. Especially common are the LOC, function point analysis (FPA), and UCP techniques. Two other widely used techniques are object points and feature points.
Therefore, the fourteenth criterion for selecting a software estimation tool is
* the tool must provide for as many commonly used software estimation techniques possible
Auditability
"Two heads are better than one" is a well-known dictum, and it forms the basis of software inspections, reviews, and walkthroughs. Therefore, it is unnecessary to say that the estimate made by one person, however diligent and expert that person may be, needs to be reviewed by one more peer. The software estimation tool must provide for making a detailed estimate so that this estimate can be reviewed and improved upon. This detailed estimate also assists in reconciling with actual effort spent on the project in order to draw lessons from the experience, and improve the process of estimation in subsequent projects.
Therefore, the fifteenth criterion for selecting a software estimation tool is
* The tool must provide for making estimates that are auditable
Reporting Capability
The result obtained by estimating is to be submitted to the client, management, or user. These reports should not include the unnecessary details, but present only the details that are required.
Therefore, the sixteenth criterion for selecting a software estimation tool is
* the tool should generate a summary report and a detailed report for every estimate made, as well as a summary report of all estimation's made on the tool
Estimator Productivity
It is extremely important to keep in mind the pressure that the estimators, who are usually either project leaders or project managers, are under. The software estimation tool must facilitate picking data from a predefined list as much as possible so that estimators are not required to type the data inputs into the tool. It is also likely that projects in an organization are similar in nature, though certainly not identical. Therefore, the tool must also enable the ability to copy an existing estimate and to modify it to generate a new estimate. This saves a great deal of the estimator's time and therefore money for the organization.
Therefore, the final two criteria (seventeenth and eighteenth) for selecting a software estimation tool are
* the tool must provide for selection from a list of choices as much as possible
* the tool must allow the "copy, modify, and generate" process for a new estimate
Summary
Software estimation is a critical activity for an organization engaged in software development. A software estimation tool helps in generating a professional quality estimate from a person with average skills in software estimation. There is a vast selection of software estimation tools available. As is normal, the available software tools come in all "colors and flavors," and range in price from $50 to a few thousand dollars (US). It is not necessarily true that expensive tools are superior to those that are lower in price. Prospective buyers can assess and evaluate the tools under consideration against these eighteen criteria in order to make the selection that is right for their organizations.
kosala
Said
Interesting blog. It would be great if you can provide more details about it. Thanks you
Function Point Estimation Training in Chennai
Unknown
Said
Thank you. I just wanted to know where to ship it since I know now to keep producing it
Software Estimation Techniques Training in Chennai
Deepakala
Said
Thanks i like your blog very much , i come back most days to find new posts like this!Good effort.I learnt it
ISTQB Training Institute in Chennai