A Time Estimation Approach for Software Projects

A Time Estimation Approach for Software Projects

Darren Pruitt

TEPM 6301

3/10/2006


of 20

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


of 20

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.


of 20

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.


of 20

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 Elements

3

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


of 20

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 x 3 x 4 x 6

External Outputs x 4 x 5 x 7

External Queries x 3 x 4 x 6

Internal Logical Files x 7 x 10 x 15

External Interface Files x 5 x 7 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:

∑+≡ GSCVAF *01.065.0

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


of 20

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


of 20

FP Element Raw Count Complexity FP Count

EI 11 x 3 22

EO 1 x 4 4

EQ 0 0

ILF 1 x 7 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


of 20

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


of 20

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


of 20

Table 5 - ISBSG Results Project delivery rate

(hours per function point)

Speed of delivery

(function points per month)

Attribute Value

Number

of

matches

Optim

(25th%)

Likely

(median)

Conserv

(75th%)

Conserv

(25th%)

Likely

(median)

Optim

(75th%)

Business area

type

Personnel 0

Application

type

Management

information

system

2 3.3 4.9 6.6 64.5 86.3 108.2

Maximum

team size

5 - 8 1 7.9 7.9 7.9 51.8 51.8 51.8

Language type 3GL 16 6.8 9.1 15.4 69.2 104.9 146.8

Primary

programming

language

C++ 3 4.5 7.9 27.4 45.8 51.8 108.7

User base -

business units

2 - 5 3 8.0 8.2 26.4 41.1 42.6 47.2

User base -

locations

2 - 5 1 44.6 44.6 44.6 39.6 39.6 39.6

User base -

concurrent

users

> 5 4 6.6 26.4 45.2 39.7 41.2 64.5

Used CASE No 18 6.7 9.1 15.9 66.6 99.2 134.8

Used

methodology

Yes 8 3.6 8.0 20.3 41.9 62.1 138.9

How

methodology

acquired

Developed

inhouse

7 4.8 8.2 28.4 41.2 51.8 101.1

Architecture Client server 5 8.2 12.1 44.6 39.8 42.6 72.3

Web

development

Yes 11 8.6 9.1 15.7 63.5 98.2 126.6

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.


of 20

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

Another equation also used is:1

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


of 20

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.


of 20

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.


of 20

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.


of 20

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.


of 20

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

(lines of code)

Schedule

(months)

Effort (man-

months)

Schedule

(months)

Effort (man-

months)

Schedule

(months)

Effort (man-

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).


of 20

Table 8 - Efficient Schedules

Systems Products Business Products Shrink-Wrap Products System Size (lines

of code)

Schedule

(months)

Effort (man-

months)

Schedule

(months)

Effort (man-

months)

Schedule

(months)

Effort (man-

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).


of 20

Table 9 - Nominal Schedules

Systems Products Business Products Shrink-Wrap Products

System Size (lines

of code)

Schedule

(months)

Effort (man-

months)

Schedule

(months)

Effort (man-

months)

Schedule

(months)

Effort (man-

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).


of 20

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.

A Time Estimation Approach for Software Projects

Documents

Transcript of A Time Estimation Approach for Software Projects