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.
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.
No comments:
Post a Comment