Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Darren Pruitt
TEPM 6301
3/10/2006
A Time Estimation Approach for Software Projects
Table of Contents
Page 2 of 20
A Time Estimation Approach for Software Projects
Introduction
There is not a project manager or developer out there that has not had someone come to them and say “I
have this simple form, how long will it take to make it?” And it is always the case that, six months later,
that project manager or developer swears they will never give a quick estimate again.
Estimating how long it will take to complete a software project is not an easy task. There are untold
numbers of reasons as to why this is. The industry is still young. Projects are driven not by engineering
principles but by marketing concerns. The technology is constantly changing. And the list goes on.
What is needed is a systematic approach to software estimation that transcends some of these issues. An
approach that applies to as many types of projects and as varied amount of platforms as currently exists.
When someone asks how long it will take to complete a software project they may not really understand
what it is they are really asking for. What they are really meaning to ask is:
1. How big is the project going to be?
2. How much effort is it going to take to complete it?
3. When will it be completed?
In this paper I will explain how to use Function Point Analysis to estimate the project size, the work effort
involved and generate an initial project schedule. I will also explain the need to maintain historical project
metrics and how to apply them to improve software size and schedule estimations.
Page 3 of 20
A Time Estimation Approach for Software Projects
Function Points
A Function Point (FP) is “a synthetic measure of program size”1 which is easier to understand and derive
from requirement specifications than SLOC.
Function Points were initial used by IBM and have since become an industry standard. The International
Function Point User Group (IFPUG) is a non-profit organization that promotes the use Function Points for
software development and maintenance.2
Function Point measurements differ from SLOC measurements in that the SLOC is dependant on the
language used where as a Function Point is independent of the language. Once an organization has enough
historical data on project Function Points and SLOC then the two can be converted between each other
easily through the use of backfiring tables.
Function Point Analysis (FPA) is the method used to determine the size of a project based on the number of
Function Point Elements. FPA requires an organization to maintain accurate historical project metrics.
These metrics are used to further refine project size measurements.
Page 4 of 20
A Time Estimation Approach for Software Projects
External Inputs (EI) are ways that end-users or other programs can change a programs data. Changing data
includes updates, deletes and additions. EIs can be application forms, message calls or even dialog boxes.1
External Outputs (EO) are ways that the program can let the end-user or other programs know what the
programs current data is. Types of outputs are reports, forms, graphs or messages. 1
External Queries (EQ) are input / output combinations in which an end-user or program submits a simple
input to the program and receives a simple output. This is directly analogous to querying a relational
database system.1 This could also include online searches.
Internal Logical Files (ILF) refers to end-user data or control information that is manufactured and stored
within the application. Examples include single flat files or a single entity in a relational database. 1
External Interface Files (EIF) refers to data which is managed and controlled by other programs but is
required to be used by the application being created. EIF are better known as interfaces to other systems
and includes web services and flat files produced by other systems and imported into the current
application. 1
Page 5 of 20
A Time Estimation Approach for Software Projects
Characteristic Name
Data Communication
Distributed Data Processing
Performance
Heavily Used Configuration
Transaction Rate
On-Line Data Entry
End User Efficiency
On-Line Update
Complex Processing
Reusability
Installation Ease
Operational Ease
Multiple Sites
Facilitate Change
Table 2 - General Systems Characteristics
Page 6 of 20
A Time Estimation Approach for Software Projects
The Degree of Influence for each of these GSC’s is 1 so the VAF is:
VAF = 0.65 + 0.01 * 4 = 0.69
Page 7 of 20
A Time Estimation Approach for Software Projects
Page 8 of 20
A Time Estimation Approach for Software Projects
Work Effort
Work Effort is “the amount of human work associated with a project.”6 It is used to help determine the
project schedule as well as accurately identify how many people will be needed for the project.
Units of Measure
Work Effort is measured in units of time. Typically for projects with less than 1,000 Function Points the
units used are hours. For projects on the scale of 10,000 Function Points or more it would be more
appropriate to use units of days, weeks or even months.6
Converting Work Effort from hours to days will not give an accurate measure. A standard work day in the
United States is defined to be eight hours long. This however does not take into account coffee breaks or
meetings and on average the effective work time is six hours.6 Saying that a task will take eight hours does
not automatically translate to taking one day.
For scheduling purposes it should be noted that number of work days per year averages out to be 220 days.
This is taking into account holidays, vacation and sick time.
Schedule Tables
Schedule Tables are used to convert software size estimates in Function Points to Work Effort estimates.
Schedule Tables can initially be derived from industry standards then as real project metrics are obtained
they will need to be updated. Different types of schedules that are used are: Shortest Possible, Efficient, and
Nominal Schedules.1
The Shortest Possible Schedule is the shortest schedule obtainable given a perfect development
environment. This schedule is compressed as far as possible and is based the most optimistic conditions
possible. This schedule is not realistic but is used as a way of establishing the absolute minimum effort that
must be used for the project.
The Efficient Schedule assumes that most work is done correctly and that the project team is drawn from
the top 25 percent of the available pool.1 This schedule makes the same assumptions about development
conditions but the schedule is not compressed.
The Nominal Schedule use less optimistic assumptions about the project and assumes that the project team
is drawn from the top 50 percent of the available pool.1 This schedule is based on historically average
projects.
Appendix A – Schedule Tables contains three examples of schedule tables used in the book Rapid
Development by Steve McConnell.
Page 9 of 20
A Time Estimation Approach for Software Projects
average of the PDR and SD are calculated to determine the target project delivery rate (PDRCE) and the
speed of delivery (SDCE). The project work effort and project duration are then found by:3
Project Work Effort PWECE = PDRCE * Project Size
Project Duration PDCE = Project Size / SDCE
Project Analogy is similar to Project Comparison with the exception that instead of finding a group of
projects that match the target project a single matching project is used. The ISBSG data is mined for the
project that most resembles the target project and using its actual values for PDR and SD to calculate the
project work effort and project duration.3
The Project Analogy method is more prone to errors in projecting work effort and duration since the odds
of picking a project that does not actually match the target project is high.
This resulted in the projects list in Table 5 - ISBSG Results to be returned. After reviewing the results two
projects were determined not to be applicable and were removed from the list. These projects were the
‘Maximum Team Size’ and the ‘User base – locations’.
The Project Delivery Rates (PDR) and the Speed of Delivery (SD) were calculated as follows:
Project delivery rate PDRCE i = mean of optimistic / likely / conservative project delivery rates
PDRCE optimistic = 6.1 hours per function point
PDRCE likely = 10.3 hours per function point
PDRCE conservative = 24.6 hours per function point
Page 10 of 20
A Time Estimation Approach for Software Projects
COCOMO
COCOMO is a model that uses lines of code (SLOC) to determine a software projects work effort, cost and
schedule. In order to use COCOMO with FP analysis backfiring tables must be created to convert FP size
to SLOC.
COCOMO allows the project manager to quickly perform what-if scenarios and is useful in comparing to
Schedule Tables and ISBSG derived estimates.
Using COCOMO is, however, beyond the scope of this document.
Page 11 of 20
A Time Estimation Approach for Software Projects
Estimating Schedules
Overview
Once the size of the project and the work effort involved is determined the next logical step is to come up
with an initial schedule. It should be cautioned that this initial schedule is just that, an initial estimation of
when the project can be completed. There are several factors that must be taken into account before a final
schedule is developed. This is mentioned because it is common that when an initial project schedule is
presented to the stake holders or management they have a tendency to hold the PM to that schedule.
Initial Estimate
Calculating the initial time a project should take is simple6:
Initial Time = Work Effort / Staff
For example, if you previously calculated that a project will take 10 man-months to complete and you have
two people working on the project then the project should be completed in five months.
5 Months = 10 man-months / 2 people
1
Another equation also used is:
Schedule in months = 3.0 * man-months ^1/3
This rule of thumb is used to determine the initial estimate then can be used to estimate the optimum team
size. For example if you have a project that will take 65 man months then:
12 Months = 3.0 * 65^1/3
And the team size is given by:
5 people = 65 man-months / 12 months
For example if you have an average shrink-wrap project that has been estimated to have 350 Function
Points then the estimated schedule time would be:
12 Months = 350 0.42
Page 12 of 20
A Time Estimation Approach for Software Projects
What to Track
To effectively project the size, effort and schedule of future projects the lessons learned from previous
projects must be documented and analyzed. By monitoring project metrics the confidence level in future
project predictions is increased.
Some categories to track are:
• Progress information
• Work Effort
• Cost
• Productivity
• Trouble Reports
The planned value for these categories should be compared to the actual value during the course of a
project. This will provide the means during the project to refine the project plan to more accurately
determine the completion time.
Productivity can be measured with Function Points. This measurement can then be used to determine the
Schedule tables or to calibrate the ISBSG data for future projects.
Page 13 of 20
A Time Estimation Approach for Software Projects
Issues to Overcome
Web Projects
Donald Reifer argues that estimating web projects is different from that of a more typical, i.e. desktop,
project. 8 Reifer states that because of the smaller size of the projects and the faster pace required for
completing the projects that new sizing metrics need to be established.
In addition to Function Points Reifer states that following needs to be added to the sizing estimate:
• Number of Web Links
• Multimedia Files
• Scripts
• Web building blocks
He also states that process employed and the estimating process used is more ad hoc than traditional
software development. Job costing, if done, is performed by the developers who are building the system.
Unfortunately developers tend to be overly optimistic when it comes to predicting the size or work effort
involved with their projects.8
I would argue that this is more of an indication of the immaturity of the web development community.
This is a community that is driven more by marketing and developers who are keen on writing the latest
tricks, yet neither group tends to study any realistic project management styles.
Management Support
Management must be educated on the finer points of software scheduling. Granted this is easier said then
done but the effort will eventually pay off. It must be made clear that initial estimates could vary wildly (in
the range of +75% to -25%) but that as the planning moves forward these estimates will become more
accurate.
Management also has to buy into maintaining the project metrics. As the repository of project information
grows the estimation of the project scope, cost and time will become more realistic. This in turn will lead
them have more confidence in the IT process. And when management starts pushing the metrics program
then the developers will have to start maintaining them.
Developer Support
It has been my experience that developers are lazy, especially when it comes to paper work or, horror of
horrors, Status Reports. It is a fact of life though that it is the developers who know how the project is
really going and how much effort is really being spent on it.
In order for developers to support updating the project metrics two things must be in place. First,
management has to support the process. If no one with authority backs the process then the developer will
not do it. Second, the process of obtaining the information should be as painless a possible. It would be an
even better benefit if the process actually helped the developer during his daily work.
If the process of obtaining metrics from the developer becomes onerous then odds are they will create some
process to automatically update the data. When this happens then the metrics are actually becoming
detrimental to the estimation process.
Page 14 of 20
A Time Estimation Approach for Software Projects
Page 15 of 20
A Time Estimation Approach for Software Projects
Conclusion
Estimating how long it will take to design and build a software solution is not a trivial task. If it were easy
then the industry would not be lauded for all the schedule overruns and the multi-million dollar projects
that have failed.
A solution for developing accurate estimations is to use Function Point Analysis (FPA) to accurately
predict the size of the project. The FP Count is a count of the five FP Elements, input, output, query,
internal data files, and interfaces, that make up the application. These FP elements can be determined by
using the project scope and the application boundary. The count of these elements is then adjusted based
on the complexity of the system and the influence of the systems characteristics.
Once the size of the project has been determined the Work Effort required to execute the project can be
determined. Effort estimations can be created using Schedule Tables and industry standard repositories
compared to the project size and type. In order for a company to obtain accurate work effort projections it
should maintain historical metrics and use them to calibrate the industry standard data.
Software programs can also be used to estimate the work effort.
With the project size and work effort the initial schedule can be determined.
As noted this process is not trivial and takes some amount of time and effort to perform it. Project
Managers and Developers should resist the urge to give off the cuff estimates; they should do the do
diligence and come up with an as accurate projection as possible.
Page 16 of 20
A Time Estimation Approach for Software Projects
Page 17 of 20
A Time Estimation Approach for Software Projects
Page 18 of 20
A Time Estimation Approach for Software Projects
Page 19 of 20
A Time Estimation Approach for Software Projects
References
1
McConnell, Steve. Rapid Development, Microsoft Press, 1996.
2
http://www.ifpug.org
3
Hill, Peter R. Practical Project Estimation: A Toolkit for Estimating Software Development Effort and
Duration, Second Edition, ISBSG 2005
4
Bennatan, E.M. On Time Within Budget: Software Project Management Practices and Techniques, Third
Edition, John Wiley & Sons 2000
5
Garmus, David and Herron, David. Estimating Software Earlier and More Accurately, CrossTalk, The
Journal of Defense Software Engineering, June 2002
6
Jones, Capers. Software Cost Estimation in 2002, CrossTalk, The Journal of Defense Software
Engineering, June 2002.
7
http://www.isbsg.org
8
Reifer, Donald J. Estimating Web Development Costs: There Are Differences, CrossTalk, The Journal of
Defense Software Engineering, June 2002.
Page 20 of 20