You are on page 1of 20

A Time Estimation Approach for Software Projects

Darren Pruitt
TEPM 6301
3/10/2006
A Time Estimation Approach for Software Projects

Table of Contents

Table of Contents ........................................................................................................................................... 2


Introduction .................................................................................................................................................... 3
Estimating Software Size ............................................................................................................................... 4
Measuring the Size of Software.................................................................................................................. 4
Source Lines of Code ................................................................................................................................. 4
Function Points........................................................................................................................................... 4
Estimating Software Work Effort................................................................................................................... 9
Work Effort ................................................................................................................................................ 9
Units of Measure ........................................................................................................................................ 9
Schedule Tables.......................................................................................................................................... 9
International Software Benchmarking Standard Group.............................................................................. 9
Calibrating Historical Data....................................................................................................................... 10
COCOMO ................................................................................................................................................ 11
Estimating Schedules.................................................................................................................................... 12
Overview .................................................................................................................................................. 12
Initial Estimate.......................................................................................................................................... 12
Jones First-Order Estimation Practice ...................................................................................................... 12
Tracking Project Metrics .............................................................................................................................. 13
What to Track........................................................................................................................................... 13
Scan Source Control for Historical Data .................................................................................................. 13
Issues to Overcome....................................................................................................................................... 14
Web Projects............................................................................................................................................. 14
Management Support................................................................................................................................ 14
Developer Support.................................................................................................................................... 14
The Little Things ...................................................................................................................................... 14
Not Silver Bullet....................................................................................................................................... 15
Conclusion.................................................................................................................................................... 16
References .................................................................................................................................................... 17

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

Estimating Software Size

Measuring the Size of Software


How big is a program? Is it the number of bytes it gets compiled to, or is the total number of lines of code
it took to write it? To be able to predict how long it will take to create a software project then the size must
be measured.
There are two common measures for software: Source Lines of Code and Function Points.

Source Lines of Code


Source Lines of Code (SLOC) is a common way to measure the size of a program. SLOC for an existing
program is easy to resolve, however when trying to estimate the size of a new program SLOC is difficult to
accurately predict.
There is no common definition for SLOC. Should SLOC include test code? Should it include re-used
code? Is there a way to compare SLOC between languages such as Assembly, C# , or Ruby? Because of
these questions and other unresolved issues SLOC will not be used in the document to determine software
size.

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.

Function Point Counting


There are approximately five steps to perform for Function Point Counting:
1. Determine the Project Scope
2. Identify the Application Boundary
3. Count the Function Points
4. Evaluate the Function Point Complexity
5. Calculate the Value Adjustment Factor

Determine the Project Scope


The FP count can be for a new development project, an enhancement to a previous project or a count of an
existing application. By determining the scope each FP to be counted is identified.
If a project is broken up into phases then the FP sizing should be created for each phase. It is important to
identify exactly what the scope is for each FP count.

Page 4 of 20
A Time Estimation Approach for Software Projects

Identify Application Boundary


In order to identify the FP elements the boundary of the application needs to be established. This is
determined by identifying what data the application is responsible for maintaining and what interactions it
will have with the environment.
IFPUG defines the application boundary as the border between the software being measured and the user
domain.3 It should be noted that the term users refers to people as well as other applications or “things”
that could interact with the software.
The application boundary could encompass several platforms and, as such, it should not be drawn solely
based on the hardware or systems the application runs on. The boundary should be viewed “in terms of
how an experienced user would view the software.”3

Count the Function Points


Once the scope has been determined and the application boundary established each FP element should be
self-evident so each is identified and counted. There are five different types of FP elements and they are
inputs, outputs, queries, data files, and interfaces.
FP elements reflect a Database Centric view of the world and as such they are conceptually easy to
recognize. Figure 1 shows the context diagram for the IFPUG Function Point Elements.3

Figure 1 - Function Point Elements3

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

Evaluate the Function Point Complexity


Each Function Point Element can be classified by its complexity as Simple, Medium or High. A
complexity of Simple indicates the FP has few unique data types, minimal user interaction or limited
access. A complexity of High indicates that the FP has a large number of unique data types, extensive user
interaction or a large amount of access. A complexity of Medium applies to FPs that are more complex
then Simple but not as complex as High.3
This classification is used to apply a numerical weighted value to the FP count as given in Table 1.
Function Point Complexity Multipliers1
Function Point Element Low Medium High
External Inputs x3 x4 x6
External Outputs x4 x5 x7
External Queries x3 x4 x6
Internal Logical Files x7 x 10 x 15
External Interface Files x5 x7 x 10
Table 1 - Function Point Multipliers

Calculate the Value Adjustment Factor


The Value Adjustment Factor (VAF) is based on the evaluation of fourteen non-functional General Systems
Characteristics (GSC) (see Table 2) and ranges in value from 0.65 to 1.35.3 The formula for VAF is:

VAF ≡ 0.65 + 0.01 * ∑ GSC


The specific value for the GSC is determined by how much influence the characteristic has on the system
(see Table 3).

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

Value Degree of Influence Examples


0 Non-existent • The application does use this characteristic.
1 Insignificant • Simple addition/subtraction
• Simple logical algorithms
• Simple data relationships
2 Moderate • Many calculations, including multiplication/division in
series
• More complex, nested algorithms
• Multidimensional data relationships
3 Average • Significant number of calculations typically contained
in payroll/actuarial/rating/scheduling applications
• Complex, nested algorithms
• Multidimensional and relational data relationships with
significant number of attributive and associative
relationships
4 Significant • Differential equations typical
• Fuzzy Logic
• Extremely complex, logical, and mathematical
algorithms typically seen I
military/telecommunications/real-time/automated
process control/navigation systems.
• Extremely complex data
5 Strong • Online, continuously available, critically timed
• Event-driven outputs that occur simultaneously with
inputs
• Buffer area or queue determines processing priorities
• Memory, timing, and communication constraints
• The most advanced applications developed
Table 3 - GSC Degrees of Influence4,5

Function Point Counting Example


In Figure 2 there are thirteen data elements so the FP count would be 13. Element number 2 is considered
an EO since it cannot be edited directly. Elements 1 and 3 thru 12 are EI as they are input items. All items
1 thru 12 should appear in an ILF which element 13 would save to. This would indicate that within the
applications boundary there is a flat file or relational database table with the elements 1 thru 12 in it.
Table 4 has the detailed breakdown of the FP counting. The complexity of the system is Low and there are
only four General System Characteristics that apply:
• Data Communication
• Performance
• End User Efficiency
• Operational Ease

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

FP Element Raw Count Complexity FP Count


EI 11 x3 22
EO 1 x4 4
EQ 0 0
ILF 1 x7 7
EIF 0 0
Unadjusted FP Count 33
VAF x 0.69
Adjusted FP Count (rounded up) 23
Table 4 - FP Counting Breakdown

Figure 2 - Function Point Counting

Page 8 of 20
A Time Estimation Approach for Software Projects

Estimating Software Work Effort

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.

International Software Benchmarking Standard Group


The International Software Benchmarking Standard Group (ISBSG) is a not-for-profit organization that
maintains two repositories of software development metrics. One is for Software Development and
Enhancement and the other is for Software Maintenance and Support.7
There are several ways to estimate Work Effort using the data from the ISBSG repository. Three common
ways are by using Regression Equations, using Project Comparison, or by using Project Analogy.3
Regression Equations generate a ballpark estimate by plugging values into specific equations. The
estimates generated though are not accurate enough to be used for actually managing the project.3
With Project Comparison the ISBSG data is mined for projects that have similar FP size (expressed as a
range) as the target project. The resulting projects attributes are then compared to the target project to find
those that are somewhat similar to the target project. These attributes include the language used,
application type, architecture, methodology used, etc. For each of these projects the optimistic, most likely,
and conservative values for the project delivery rate (PDR) and speed of delivery (SD) are calculated. The

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.

Project Analogy Example


In Practical Project Estimation: A Toolkit for Estimating Software Development Effort and Duration,
Second Edition by Peter R. Hill there is an example of using Project Analogy to estimate a projects effort.
The project used is a student and staff record management system for a university. The computed
functional size of the program is 540 FP. The following information was used to query the ISBSG
repository:
Project Matching ISBSG Projects
Functional Size 540 250 - 750 function points
Development platform Midrange Midrange
Development type New development New development

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

Project work effort PWECE = PDRCE i * Size


PWECE optimistic = 3,305 hours
PWECE likely = 5,565 hours
PWECE conservative = 13,276 hours

Project duration SDCE = Size / SDCE i


PDCE optimistic = 5.1 months
PDCE likely = 7.9 months
PDCE conservative = 10.5 months

Speed of delivery SDCE i = mean of optimistic/likely/conservative speeds of delivery


SDCE optimistic = 104.9 function points per month
SDCE likely = 68.1 function points per month
SDCE conservative = 51.3 function points per month

Page 10 of 20
A Time Estimation Approach for Software Projects

Table 5 - ISBSG Results


Project delivery rate Speed of delivery
(hours per function point) (function points per month)
Number
Optim Likely Conserv Conserv Likely Optim
of
(25th%) (median) (75th%) (25th%) (median) (75th%)
Attribute Value matches
Business area Personnel 0
type
Application Management 2 3.3 4.9 6.6 64.5 86.3 108.2
type information
system
Maximum 5-8 1 7.9 7.9 7.9 51.8 51.8 51.8
team size
Language type 3GL 16 6.8 9.1 15.4 69.2 104.9 146.8
Primary C++ 3 4.5 7.9 27.4 45.8 51.8 108.7
programming
language
User base - 2-5 3 8.0 8.2 26.4 41.1 42.6 47.2
business units
User base - 2-5 1 44.6 44.6 44.6 39.6 39.6 39.6
locations
User base - >5 4 6.6 26.4 45.2 39.7 41.2 64.5
concurrent
users
Used CASE No 18 6.7 9.1 15.9 66.6 99.2 134.8
Used Yes 8 3.6 8.0 20.3 41.9 62.1 138.9
methodology
How Developed 7 4.8 8.2 28.4 41.2 51.8 101.1
methodology inhouse
acquired
Architecture Client server 5 8.2 12.1 44.6 39.8 42.6 72.3
Web Yes 11 8.6 9.1 15.7 63.5 98.2 126.6
development

Calibrating Historical Data


Most companies have not taken the time or effort needed to analysis their projects in order to come up with
any work effort or rate of delivery data. This is why having industry standard data, as the ISBSG
repository, is useful. However, this data can really only establish a ballpark value for work effort.
As a company performs more projects they can maintain metrics of the project and use these metrics to
calibrate the repository data to match their needs. The long-term success of any estimation program is
dependant on accurate measurement of historical data.1
Since most companies use some type of source control for the program files an analysis of these files could
help with an initial calibration of the work effort data.

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

Jones First-Order Estimation Practice


Capers Jones developed a practice called First-Order Estimation. It is based on his analysis of his database
of several thousand projects.1 He created a series of exponents that can be used on the FP size calculations
to calculate a rough schedule estimate.
Kind of Software Best in Class Average Worst in Class
Systems 0.43 0.45 0.48
Business 0.41 0.43 0.46
Shrink-wrap 0.39 0.42 0.45
Table 6 - Exponents for Computing Schedules from FP1

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

Tracking Project Metrics

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.

Scan Source Control for Historical Data


A source for project metrics is the company’s source control repository. This repository has all the code
actually written for different projects, who wrote it, what changed and when it changed. This information
can be analyzed to determine productivity and to create backfire tables for SLOC to FP conversions.

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.

The Little Things


Often common tasks are omitted when performing project estimations.1 Tasks such as data conversion,
installations, customization, generating documentation, or even managing the beta testing are often just
plain missed in the estimations.
As these items come up in the project they should be noted and the project estimation adjusted.

Page 14 of 20
A Time Estimation Approach for Software Projects

Not Silver Bullet


No one project estimation process is full proof. To establish an accurate projection of project size and
effort more than one process should be used.
If available, software estimation tools should be used and the results compared to hand generated
estimations. Function Points should be backfired into Source Lines of Code and that value plugged into the
COCOMO analysis.
And above all do the idiot check: Do the results make sense? If not then reevaluate the inputs.

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

Appendix A – Schedule Tables


The following Schedule Tables are taken from the book Rapid Development.1

Table 7 - Shortest Possible Schedules

Systems Products Business Products Shrink-Wrap Products


System Size Schedule Effort (man- Schedule Effort (man- Schedule Effort (man-
(lines of code) (months) months) (months) months) (months) months)
10,000 6 25 3.5 5 4.2 8
15,000 7 40 4.1 8 4.9 13
20,000 8 57 4.6 11 5.6 19
25,000 9 74 5.1 15 6 24
30,000 9 110 5.5 22 7 37
35,000 10 130 5.8 26 7 44
40,000 11 170 6 34 7 57
45,000 11 195 6 39 8 66
50,000 11 230 7 46 8 79
60,000 12 285 7 57 9 98
70,000 13 350 8 71 9 120
80,000 14 410 8 83 10 140
90,000 14 480 9 96 10 170
100,000 15 540 9 110 11 190
120,000 16 680 10 140 11 240
140,000 17 820 10 160 12 280
160,000 18 960 10 190 13 335
180,000 19 1,100 11 220 13 390
200,000 20 1,250 11 250 14 440
250,000 22 1,650 13 330 15 580
300,000 24 2,100 14 420 16 725
400,000 27 2,900 15 590 19 1,000
500,000 30 3,900 17 780 20 1,400
Sources: Derived from data in Software Engineering Economics (Boehm 1981), "An Empirical Validation of Software Cost
Estimation Models" (Kemerer 1987), Applied Software Measurement (Jones 1991), Measures for Excellence (Putnam and Myers
1992), and Assessment and Control of Software Risks (Jones 1994).

Page 17 of 20
A Time Estimation Approach for Software Projects

Table 8 - Efficient Schedules

Systems Products Business Products Shrink-Wrap Products


System Size (lines Schedule Effort (man- Schedule Effort (man- Schedule Effort (man-
of code) (months) months) (months) months) (months) months)
10,000 8 24 4.9 5 5.9 8
15,000 10 38 5.8 8 7 12
20,000 11 54 7 11 8 18
25,000 12 70 7 14 9 23
30,000 13 97 8 20 9 32
35,000 14 120 8 24 10 39
40,000 15 140 9 30 10 49
45,000 16 170 9 34 11 57
50,000 16 190 10 40 11 67
60,000 18 240 10 49 12 83
70,000 19 290 11 61 13 100
80,000 20 345 12 71 14 120
90,000 21 400 12 82 15 140
100,000 22 450 13 93 15 160
120,000 23 560 14 115 16 195
140,000 25 670 15 140 17 235
160,000 26 709 15 160 18 280
180,000 28 910 16 190 19 320
200,000 29 1,300 17 210 20 360
250,000 32 1,300 19 280 22 470
300,000 34 1,650 20 345 24 590
400,000 38 2,350 22 490 27 830
500,000 42 3,100 25 640 29 1,100
Sources: Derived from data in Software Engineering Economics (Boehm 1981), "An Empirical Validation of Software Cost
Estimation Models" (Kemerer 1987), Applied Software Measurement (Jones 1991), Measures for Excellence (Putnam and Myers
1992), and Assessment and Control of Software Risks (Jones 1994).

Page 18 of 20
A Time Estimation Approach for Software Projects

Table 9 - Nominal Schedules

Systems Products Business Products Shrink-Wrap Products


System Size (lines Schedule Effort (man- Schedule Effort (man- Schedule Effort (man-
of code) (months) months) (months) months) (months) months)
10,000 10 48 6 9 7 15
15,000 12 76 7 15 8 24
20,000 14 110 8 21 9 34
25,000 15 140 9 27 10 44
30,000 16 185 9 37 11 59
35,000 17 220 10 44 12 71
40,000 18 270 10 54 13 88
45,000 19 310 11 61 13 100
50,000 20 360 11 71 14 115
60,000 21 440 12 88 15 145
70,000 23 540 13 105 16 175
80,000 24 630 14 125 17 210
90,000 25 730 15 140 17 240
100,000 26 820 15 160 18 270
120,000 28 1,000 16 200 20 335
140,000 30 1,200 17 240 21 400
160,000 32 1,400 18 280 22 470
180,000 34 1,600 19 330 23 540
200,000 35 1,900 20 370 24 610
250,000 38 2,400 22 480 26 800
300,000 41 3,000 24 600 29 1,000
400,000 47 4,200 27 840 32 1,400
500,000 51 5,500 29 1,100 35 1,800
Sources: Derived from data in Software Engineering Economics (Boehm 1981), "An Empirical Validation of Software Cost
Estimation Models" (Kemerer 1987), Applied Software Measurement (Jones 1991), Measures for Excellence (Putnam and Myers
1992), and Assessment and Control of Software Risks (Jones 1994).

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