Chemuturi Consultants – Do it well or not at all
Criteria for selecting a Software Estimation Tool
Murali Chemuturi
I Introduction
Software estimation includes the following four elements –
i.
Software size
ii.
Software Cost
iii.
Software Effort
iv.
Software delivery schedule
A plethora of tools are available in the market to choose from and it is often difficult to
arrive at an educated decision on which tool to purchase. As usual the vendors always
claim that their tool is better ad the most scientific and suited to any type of software
project and any organization.
This paper attempts to educate the professionals in making an educated choice while
buying a software estimation tool.
II Units of measure for Software Size
It is a known fact that there is no agreement on the unit of measure for software. There
are many reasons for this –
i.
The programming platforms differ widely
ii.
There is a difference of opinion on what constitutes a Line of Code –
variable declaration, comments, length of an LOC bear different
connotations to different perspectives – a vendor would like to count all –
a buyer would not like to include all those.
iii.
GUI programming added one more dimension and there is confusion on
how to measure size of GUI
iv.
Several projects are not full life cycle projects – such as Software
Maintenance projects, Testing projects – there is confusion on how to
measure the size of such projects
Therefore Criteria number one for selecting a software estimation tool is
 The tool must allow multiple units of measures for software size
In other words, the tool must have provision for using different popular techniques for
software size measurement.
III Common unit of measure for Software Size
Now the question comes, if the size measurement is carried out using different measures,
how does the organization measure its productivity? Measurement of organization’s
software development productivity is possible only when the software size is measured
using one unit of measure.
32-78/3 Sainik Nagar Rama Krishna Puram, Secunderabad - 500056
+001-347-394-3138 & +91-40-2722 0771 - www.chemuturi.com - murali@chemuturi.com
Dt. 28th April 2006
Chemuturi Consultants – Do it well or not at all
Therefore, the second criteria for selecting a software estimation tool is
 The tool must enable conversion of multiple units of measure into
one unit of measure for software size to achieve standardization
for the organization
IV Software Cost Estimation
There are no differences when we talk of software costing – every one agrees that it must
be measured in currency of the country – be it Dollars or Euros or Rupees. While
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 maintenance of cost items (add, modify and delete of cost
items data). It is also likely that the person day costs also vary from project to project.
Therefore third, fourth and fifth criteria for selecting a software estimation tool is –
 The tool must allow software cost estimation
 The tool must provide for parameterization of person day cost
 The tool must provide for maintenance of cost items
V Scheduling the software Project
Basically effort is estimated for three reasons –
1. Commit a delivery schedule to the client/management/users
2. Estimate the resources required to execute the project
3. Estimate the cost of the project for funds allocation or pricing the
project with objectives of cost / profit optimization
We have already enumerated that the tool caters to reasons 2 and 3. While so, the first
reason of developing a schedule for committing to stakeholders is by no means an
insignificant one. Scheduling is a creative task and an activity that calls for human
ingenuity that cannot be fully automated. Equally important is the fact that there is no
accepted and standard way of apportioning so much percentage of project effort to a
given phase/activity. The objectives of achieving a schedule from estimate ought to be –




It should be quick
It should cater to allocation of resources
It should allow for allocating effort PD to different phases
It should generate a schedule of sufficient detail and must be
exportable to an intermediate file from which it can be taken into a
full-fledged PERT/CPM packages like MS-Project and Primavera
32-78/3 Sainik Nagar Rama Krishna Puram, Secunderabad - 500056
+001-347-394-3138 & +91-40-2722 0771 - www.chemuturi.com - murali@chemuturi.com
Dt. 28th April 2006
Chemuturi Consultants – Do it well or not at all
Therefore sixth to eleventh criteria for selecting software estimation tool is –




The tool must provide for scheduling the project
The schedule must be derived from the estimated effort
It 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 popular intermediate file such as MS-Excel
 When we honestly estimate the effort in person days and then schedule
it, the PD overshoots the estimated PD due to loss of time in personnel
allocation, idle time, and finish–start relationships. Therefore the tool
must be based on estimated PD but allow for scheduled PD to be
different from the estimated PD
VI Estimation for Part-life-cycle projects
There are several significant projects, which are not full-life-cycle such as software
maintenance, ERP implementation and testing projects. The tool has to cater to these
projects too using a technique like task based estimation that is parameterized so that
different project types can be defined and used by the organization.
Therefore twelfth criteria for selecting software estimation tool is –
 The tool must cater to part-life-cycle project estimation too
VII Usability
Any software needs to be built with users in mind. An expert can work with any tool but
the main distinguishing characteristic of a good tool is that it can produce an expertquality output even from a person of average expertise. This can be achieved by
building a tool with an intuitive interface that makes the requirement of training on the
usage of a tool to a minimum. This is possible with availability of GUI tools. It is also
possible to use wrong controls that instead of making usage easier put a strain on the
user. The tool must care more for functionality that to jazziness. A simple UI is always
the better UI.
Therefore sixth to thirteenth criteria for selecting software estimation tool is –
 The tool must be built with usability in mind with intuitive interface
that makes it easier for average skilled person to quickly master it
VIII Usage of popular techniques
Software estimation is perhaps as old as software development itself. Some estimation
techniques have become popular and are used by many organizations. Especially popular
32-78/3 Sainik Nagar Rama Krishna Puram, Secunderabad - 500056
+001-347-394-3138 & +91-40-2722 0771 - www.chemuturi.com - murali@chemuturi.com
Dt. 28th April 2006
Chemuturi Consultants – Do it well or not at all
are the LOC (Lines of Code), FPA (Function Point Analysis) technique and Use Case
Points Technique. There are others like Object Points, Feature Points etc.
Therefore sixth to fourteenth criteria for selecting software estimation tool is –
 The tool must provide for as many popular software estimation
techniques as feasible
IX Auditability
Two heads are better than one is a well-known dictum and forms the basis of software
inspections / reviews / walkthroughs. Therefore, it is superfluous to say that the estimated
made by one person, however diligent and expert he may be, it needs to be reviewed by
one more person of peer capacity. The tool must provide for making the estimate in detail
so that it can be reviewed and improved upon. This detail also assists in reconciling with
actuals spent on the project to draw lessons for the experience and improve the process of
estimation in the subsequent projects.
Therefore sixth to fifteenth criteria for selecting software estimation tool is –
 The tool must provide for making estimates that are auditable
X Reporting capability
The end result of estimating is to submit to the client/management/user. These reports
should be hiding the unnecessary details but present sufficient details. Therefore, the tool
must provide a summary report and a detailed report for every estimate made.
Therefore sixth to Sixteenth criteria for selecting software estimation tool is –
 The tool should provide for generation of summary report and detailed
report for every estimate made as well as a summary report of all
estimations made on the tool
XI Estimator Productivity
It is extremely important to keep in mind the pressures on the estimators who are
normally either project leaders or project managers. The tool must facilitate selection
than typing as much as possible. It is also likely that projects in an organization are
similar in nature but certainly not identical. Therefore, the tool must also provide for
copying an existing estimate and modify it to generate a new estimate – this will save
immense time of the estimators and therefore money to the organization.
Therefore sixth to seventeenth criteria for selecting software estimation tool is –
 The tool must provide for selection from a list of choices as much as
possible
 The tool must provide for “copy-modify-generate a new estimate
32-78/3 Sainik Nagar Rama Krishna Puram, Secunderabad - 500056
+001-347-394-3138 & +91-40-2722 0771 - www.chemuturi.com - murali@chemuturi.com
Dt. 28th April 2006
Chemuturi Consultants – Do it well or not at all
XII Summary
Software estimation is a critical activity for an organization engaged in software
development. A tool helps in generating a professional quality estimate from an average
skilled person. There are a plethora of tools available for estimation. The following
criteria help in making an educated choice of the appropriate tool for software estimation.
1. The tool must allow multiple units of measures for software size
2. The tool must enable conversion of multiple units of measure into one unit of
measure for software size to achieve standardization for the organization
3. The tool must allow software cost estimation
a. The tool must provide for parameterization of person day cost
b. The tool must provide for maintenance of cost items
4. The tool must provide for scheduling the project
a. The schedule must be derived from the estimated effort
b. It must automate schedule generation to the extent feasible
c. The tool must allow for human intervention when creating the schedule
d. The generated schedule must have adequate detail and must be exportable
to a popular intermediate file such as MS-Excel
e. When we honestly estimate the effort in person days and then schedule it,
the PD overshoots the estimated PD due to loss of time in personnel
allocation, idle time, and finish–start relationships. Therefore the tool must
be based on estimated PD but allow for scheduled PD to be different from
the estimated PD
5. The tool must cater to part-life-cycle project estimation too
6. The tool must be built with usability in mind with intuitive interface that makes it
easier for average skilled person to quickly master it
7. The tool must provide for as many popular software estimation techniques as
feasible
8. The tool should provide for generation of summary report and detailed report for
every estimate made as well as a summary report of all estimations made on the
tool
9. The tool must provide for selection from a list of choices as much as possible
10. The tool must provide for “copy-modify-generate a new estimate
*********************************************************************
Your feedback is gratefully solicited – please email your feedback to the author
murali@chemuturi.com
*********************************************************************
32-78/3 Sainik Nagar Rama Krishna Puram, Secunderabad - 500056
+001-347-394-3138 & +91-40-2722 0771 - www.chemuturi.com - murali@chemuturi.com
Dt. 28th April 2006