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

six months later. how long will it take to make it?” And it is always the case that. 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. that project manager or developer swears they will never give a quick estimate again. The industry is still young. What is needed is a systematic approach to software estimation that transcends some of these issues. Page 3 of 20 . And the list goes on. An approach that applies to as many types of projects and as varied amount of platforms as currently exists. Estimating how long it will take to complete a software project is not an easy task.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. 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. How big is the project going to be? 2. Projects are driven not by engineering principles but by marketing concerns. What they are really meaning to ask is: 1. How much effort is it going to take to complete it? 3. The technology is constantly changing. I will also explain the need to maintain historical project metrics and how to apply them to improve software size and schedule estimations. There are untold numbers of reasons as to why this is.

It is important to identify exactly what the scope is for each FP count.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. C# . Page 4 of 20 . Function Point Analysis (FPA) is the method used to determine the size of a project based on the number of Function Point Elements. Determine the Project Scope 2. however when trying to estimate the size of a new program SLOC is difficult to accurately predict. Identify the Application Boundary 3. Calculate the Value Adjustment Factor Determine the Project Scope The FP count can be for a new development project. Evaluate the Function Point Complexity 5. Function Points were initial used by IBM and have since become an industry standard. SLOC for an existing program is easy to resolve. Source Lines of Code Source Lines of Code (SLOC) is a common way to measure the size of a program. If a project is broken up into phases then the FP sizing should be created for each phase. 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. or Ruby? Because of these questions and other unresolved issues SLOC will not be used in the document to determine software size. By determining the scope each FP to be counted is identified.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. 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. Function Point Counting There are approximately five steps to perform for Function Point Counting: 1. There is no common definition for SLOC. Count the Function Points 4. Should SLOC include test code? Should it include re-used code? Is there a way to compare SLOC between languages such as Assembly. an enhancement to a previous project or a count of an existing application. FPA requires an organization to maintain accurate historical project metrics. These metrics are used to further refine project size measurements. The International Function Point User Group (IFPUG) is a non-profit organization that promotes the use Function Points for software development and maintenance. There are two common measures for software: Source Lines of Code and Function Points. 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.

data files.1 External Outputs (EO) are ways that the program can let the end-user or other programs know what the programs current data is. EIs can be application forms. FP elements reflect a Database Centric view of the world and as such they are conceptually easy to recognize. it should not be drawn solely based on the hardware or systems the application runs on. 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. This is determined by identifying what data the application is responsible for maintaining and what interactions it will have with the environment.1 This could also include online searches. message calls or even dialog boxes. graphs or messages.Function Point Elements3 External Inputs (EI) are ways that end-users or other programs can change a programs data. outputs. 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. 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.3 Figure 1 .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. IFPUG defines the application boundary as the border between the software being measured and the user domain. Figure 1 shows the context diagram for the IFPUG Function Point Elements. Changing data includes updates. The application boundary could encompass several platforms and.”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. Internal Logical Files (ILF) refers to end-user data or control information that is manufactured and stored within the application. Types of outputs are reports. This is directly analogous to querying a relational database system. deletes and additions. The boundary should be viewed “in terms of how an experienced user would view the software. queries.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. and interfaces. forms. 1 Page 5 of 20 . Examples include single flat files or a single entity in a relational database. as such. There are five different types of FP elements and they are inputs.

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 .3 The formula for VAF is: VAF ≡ 0.3 This classification is used to apply a numerical weighted value to the FP count as given in Table 1.65 to 1.General Systems Characteristics Page 6 of 20 . A complexity of High indicates that the FP has a large number of unique data types.A Time Estimation Approach for Software Projects Evaluate the Function Point Complexity Each Function Point Element can be classified by its complexity as Simple.01 * ∑ GSC The specific value for the GSC is determined by how much influence the characteristic has on the system (see Table 3).35.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. Medium or High. extensive user interaction or a large amount of access. minimal user interaction or limited access. 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 . A complexity of Medium applies to FPs that are more complex then Simple but not as complex as High. A complexity of Simple indicates the FP has few unique data types.65 + 0.

65 + 0. logical. and communication constraints • The most advanced applications developed Table 3 . • Extremely complex data 5 Strong • Online. nested algorithms • Multidimensional and relational data relationships with significant number of attributive and associative relationships 4 Significant • Differential equations typical • Fuzzy Logic • Extremely complex.69 Page 7 of 20 . Elements 1 and 3 thru 12 are EI as they are input items.01 * 4 = 0. 1 Insignificant • Simple addition/subtraction • Simple logical algorithms • Simple data relationships 2 Moderate • Many calculations. and mathematical algorithms typically seen I military/telecommunications/real-time/automated process control/navigation systems. continuously available.GSC Degrees of Influence4. Table 4 has the detailed breakdown of the FP counting. nested algorithms • Multidimensional data relationships 3 Average • Significant number of calculations typically contained in payroll/actuarial/rating/scheduling applications • Complex. critically timed • Event-driven outputs that occur simultaneously with inputs • Buffer area or queue determines processing priorities • Memory.A Time Estimation Approach for Software Projects Value Degree of Influence Examples 0 Non-existent • The application does use this characteristic.5 Function Point Counting Example In Figure 2 there are thirteen data elements so the FP count would be 13. timing. 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. including multiplication/division in series • More complex. 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. Element number 2 is considered an EO since it cannot be edited directly.

FP Counting Breakdown Figure 2 .Function Point Counting Page 8 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 .

Different types of schedules that are used are: Shortest Possible. One is for Software Development and Enhancement and the other is for Software Maintenance and Support.3 Regression Equations generate a ballpark estimate by plugging values into specific equations. This however does not take into account coffee breaks or meetings and on average the effective work time is six hours. A standard work day in the United States is defined to be eight hours long. Schedule Tables Schedule Tables are used to convert software size estimates in Function Points to Work Effort estimates. most likely.000 Function Points or more it would be more appropriate to use units of days. This is taking into account holidays. For scheduling purposes it should be noted that number of work days per year averages out to be 220 days.1 The Shortest Possible Schedule is the shortest schedule obtainable given a perfect development environment. application type. etc. Units of Measure Work Effort is measured in units of time.6 Converting Work Effort from hours to days will not give an accurate measure. The Page 9 of 20 . Three common ways are by using Regression Equations. 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. 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.7 There are several ways to estimate Work Effort using the data from the ISBSG repository. The resulting projects attributes are then compared to the target project to find those that are somewhat similar to the target project.1 This schedule makes the same assumptions about development conditions but the schedule is not compressed. Appendix A – Schedule Tables contains three examples of schedule tables used in the book Rapid Development by Steve McConnell. For projects on the scale of 10. These attributes include the language used.3 With Project Comparison the ISBSG data is mined for projects that have similar FP size (expressed as a range) as the target project. or by using Project Analogy. and conservative values for the project delivery rate (PDR) and speed of delivery (SD) are calculated. vacation and sick time. Schedule Tables can initially be derived from industry standards then as real project metrics are obtained they will need to be updated. and Nominal Schedules. Efficient. The estimates generated though are not accurate enough to be used for actually managing the project.1 This schedule is based on historically average projects. weeks or even months.000 Function Points the units used are hours. methodology used.6 Saying that a task will take eight hours does not automatically translate to taking one day. For each of these projects the optimistic. This schedule is not realistic but is used as a way of establishing the absolute minimum effort that must be used for the project. This schedule is compressed as far as possible and is based the most optimistic conditions possible. 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. architecture. Typically for projects with less than 1. using Project Comparison.”6 It is used to help determine the project schedule as well as accurately identify how many people will be needed for the project.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.

Hill there is an example of using Project Analogy to estimate a projects effort.6 hours per function point Project work effort PWECE = PDRCE i * Size PWECE optimistic = 3.9 function points per month SDCE likely = 68. 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. Project Analogy Example In Practical Project Estimation: A Toolkit for Estimating Software Development Effort and Duration.565 hours PWECE conservative = 13.3 function points per month Page 10 of 20 .750 function points Development platform Midrange Midrange Development type New development New development This resulted in the projects list in Table 5 . Second Edition by Peter R.276 hours Project duration SDCE = Size / SDCE i PDCE optimistic = 5.9 months PDCE conservative = 10. The computed functional size of the program is 540 FP.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.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.305 hours PWECE likely = 5. The following information was used to query the ISBSG repository: Project Matching ISBSG Projects Functional Size 540 250 .3 hours per function point PDRCE conservative = 24. After reviewing the results two projects were determined not to be applicable and were removed from the list.1 months PDCE likely = 7.1 function points per month SDCE conservative = 51. The project used is a student and staff record management system for a university.ISBSG Results to be returned. 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.5 months Speed of delivery SDCE i = mean of optimistic/likely/conservative speeds of delivery SDCE optimistic = 104. These projects were the ‘Maximum Team Size’ and the ‘User base – locations’.

6 locations User base .9 62.1 15.8 42.4 69.1 44.6 47.7 programming language User base .8 101.1 138.4 45. as the ISBSG repository. 2-5 3 8.8 51.6 26. 2-5 1 44.2 12.2 104.8 9.0 8.9 146.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.1 15.2 28.6 9. Using COCOMO is.8 108.8 Primary C++ 3 4.1 42.2 type information system Maximum 5-8 1 7. is useful.2 64.5 98. however.3 4.7 9.8 team size Language type 3GL 16 6.5 7.8 51.5 86.4 41.2 126.4 41.4 45.2 39.2 business units User base .6 44. cost and schedule.8 8.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. The long-term success of any estimation program is dependant on accurate measurement of historical data.6 8.9 51. However. >5 4 6. 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.6 39. Page 11 of 20 .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.8 Used Yes 8 3.3 Web Yes 11 8.9 7.1 methodology inhouse acquired Architecture Client server 5 8.6 44.A Time Estimation Approach for Software Projects Table 5 .9 6.7 41.5 concurrent users Used CASE No 18 6.2 26. In order to use COCOMO with FP analysis backfiring tables must be created to convert FP size to SLOC.6 39. This is why having industry standard data.6 99.3 108.9 methodology How Developed 7 4.6 64.6 72. COCOMO allows the project manager to quickly perform what-if scenarios and is useful in comparing to Schedule Tables and ISBSG derived estimates.6 39.2 51.9 7.2 134. COCOMO COCOMO is a model that uses lines of code (SLOC) to determine a software projects work effort.9 27.1 15.7 63.8 51.3 41. beyond the scope of this document.6 39.0 20.9 66.

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.1 He created a series of exponents that can be used on the FP size calculations to calculate a rough schedule estimate. It is based on his analysis of his database of several thousand projects.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.43 0.42 Page 12 of 20 .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. 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. an initial estimation of when the project can be completed.45 0.48 Business 0. For example if you have a project that will take 65 man months then: 12 Months = 3.39 0.46 Shrink-wrap 0.43 0. Initial Estimate Calculating the initial time a project should take is simple6: Initial Time = Work Effort / Staff For example. 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. It should be cautioned that this initial schedule is just that.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.45 Table 6 .42 0. There are several factors that must be taken into account before a final schedule is developed. 5 Months = 10 man-months / 2 people 1 Another equation also used is: Schedule in months = 3.41 0. Kind of Software Best in Class Average Worst in Class Systems 0.

Page 13 of 20 . 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. By monitoring project metrics the confidence level in future project predictions is increased.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. Scan Source Control for Historical Data A source for project metrics is the company’s source control repository. 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. This repository has all the code actually written for different projects. This information can be analyzed to determine productivity and to create backfire tables for SLOC to FP conversions. who wrote it. This will provide the means during the project to refine the project plan to more accurately determine the completion time. what changed and when it changed.

horror of horrors. yet neither group tends to study any realistic project management styles. This in turn will lead them have more confidence in the IT process. First. Job costing. if done. This is a community that is driven more by marketing and developers who are keen on writing the latest tricks. cost and time will become more realistic. generating documentation. installations. As these items come up in the project they should be noted and the project estimation adjusted. is performed by the developers who are building the system. especially when it comes to paper work or. It would be an even better benefit if the process actually helped the developer during his daily work.8 I would argue that this is more of an indication of the immaturity of the web development community. Status Reports. the process of obtaining the information should be as painless a possible. If the process of obtaining metrics from the developer becomes onerous then odds are they will create some process to automatically update the data. Unfortunately developers tend to be overly optimistic when it comes to predicting the size or work effort involved with their projects. Second. 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. As the repository of project information grows the estimation of the project scope. project. customization. Granted this is easier said then done but the effort will eventually pay off.1 Tasks such as data conversion. When this happens then the metrics are actually becoming detrimental to the estimation process. i. or even managing the beta testing are often just plain missed in the estimations. 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. desktop.e. In order for developers to support updating the project metrics two things must be in place. Management also has to buy into maintaining the project metrics. The Little Things Often common tasks are omitted when performing project estimations. Management Support Management must be educated on the finer points of software scheduling. management has to support the process. If no one with authority backs the process then the developer will not do it.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. 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. Page 14 of 20 . 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. 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.

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

A solution for developing accurate estimations is to use Function Point Analysis (FPA) to accurately predict the size of the project. Software programs can also be used to estimate the work effort. The FP Count is a count of the five FP Elements. input. As noted this process is not trivial and takes some amount of time and effort to perform it. internal data files. and interfaces. that make up the application. query. Effort estimations can be created using Schedule Tables and industry standard repositories compared to the project size and type. they should do the do diligence and come up with an as accurate projection as possible. Project Managers and Developers should resist the urge to give off the cuff estimates. These FP elements can be determined by using the project scope and the application boundary. 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. 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. Once the size of the project has been determined the Work Effort required to execute the project can be determined. The count of these elements is then adjusted based on the complexity of the system and the influence of the systems characteristics.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. Page 16 of 20 . output. With the project size and work effort the initial schedule can be determined.

100 14 420 16 725 400.1 Table 7 .000 11 170 6 34 7 57 45.8 26 7 44 40.000 14 480 9 96 10 170 100.Shortest Possible Schedules Systems Products Business Products Shrink-Wrap Products System Size Schedule Effort (man.000 11 230 7 46 8 79 60.000 20 1. and Assessment and Control of Software Risks (Jones 1994).1 8 4.6 19 25.000 15 540 9 110 11 190 120.A Time Estimation Approach for Software Projects Appendix A – Schedule Tables The following Schedule Tables are taken from the book Rapid Development.100 11 220 13 390 200.000 17 820 10 160 12 280 160.000 18 960 10 190 13 335 180.000 13 350 8 71 9 120 80. Schedule Effort (man.000 10 130 5.000 22 1.5 22 7 37 35. Page 17 of 20 . Applied Software Measurement (Jones 1991).2 8 15. Schedule Effort (man- (lines of code) (months) months) (months) months) (months) months) 10.000 19 1. "An Empirical Validation of Software Cost Estimation Models" (Kemerer 1987).900 15 590 19 1.000 27 2.900 17 780 20 1.000 7 40 4.000 16 680 10 140 11 240 140.000 30 3.000 24 2.000 11 195 6 39 8 66 50.400 Sources: Derived from data in Software Engineering Economics (Boehm 1981).000 12 285 7 57 9 98 70.9 13 20.000 9 74 5.1 15 6 24 30.000 8 57 4.000 14 410 8 83 10 140 90.5 5 4.000 9 110 5.000 6 25 3.000 500.650 13 330 15 580 300.250 11 250 14 440 250. Measures for Excellence (Putnam and Myers 1992).6 11 5.

000 34 1.000 15 140 9 30 10 49 45.000 12 70 7 14 9 23 30.000 20 345 12 71 14 120 90.100 25 640 29 1.000 23 560 14 115 16 195 140.000 14 120 8 24 10 39 40.300 19 280 22 470 300.000 8 24 4. Schedule Effort (man.000 13 97 8 20 9 32 35.000 26 709 15 160 18 280 180.300 17 210 20 360 250.000 25 670 15 140 17 235 160. Page 18 of 20 . and Assessment and Control of Software Risks (Jones 1994). "An Empirical Validation of Software Cost Estimation Models" (Kemerer 1987).000 16 190 10 40 11 67 60.000 16 170 9 34 11 57 50.000 29 1.000 28 910 16 190 19 320 200.000 11 54 7 11 8 18 25.A Time Estimation Approach for Software Projects Table 8 .000 42 3. Applied Software Measurement (Jones 1991). Schedule Effort (man- of code) (months) months) (months) months) (months) months) 10.000 19 290 11 61 13 100 80.9 8 15.000 10 38 5.000 18 240 10 49 12 83 70. Measures for Excellence (Putnam and Myers 1992).000 32 1.9 5 5.100 Sources: Derived from data in Software Engineering Economics (Boehm 1981).Efficient Schedules Systems Products Business Products Shrink-Wrap Products System Size (lines Schedule Effort (man.350 22 490 27 830 500.000 22 450 13 93 15 160 120.650 20 345 24 590 400.000 38 2.000 21 400 12 82 15 140 100.8 8 7 12 20.

Schedule Effort (man.000 38 2.000 25 730 15 140 17 240 100.000 47 4.000 28 1.Nominal Schedules Systems Products Business Products Shrink-Wrap Products System Size (lines Schedule Effort (man.400 18 280 22 470 180.800 Sources: Derived from data in Software Engineering Economics (Boehm 1981).000 10 48 6 9 7 15 15.000 14 110 8 21 9 34 25.000 21 440 12 88 15 145 70.000 16 185 9 37 11 59 35.000 20 360 11 71 14 115 60.200 17 240 21 400 160.000 32 1.000 51 5.000 34 1.000 400.900 20 370 24 610 250.000 18 270 10 54 13 88 45.000 24 630 14 125 17 210 90.A Time Estimation Approach for Software Projects Table 9 .000 41 3. Schedule Effort (man- of code) (months) months) (months) months) (months) months) 10.000 24 600 29 1. and Assessment and Control of Software Risks (Jones 1994).000 30 1.000 23 540 13 105 16 175 80.000 26 820 15 160 18 270 120.000 16 200 20 335 140. "An Empirical Validation of Software Cost Estimation Models" (Kemerer 1987).400 500. Measures for Excellence (Putnam and Myers 1992).000 35 1.100 35 1.000 12 76 7 15 8 24 20.000 19 310 11 61 13 100 50.000 15 140 9 27 10 44 30.000 17 220 10 44 12 71 40.400 22 480 26 800 300. Applied Software Measurement (Jones 1991).200 27 840 32 1. Page 19 of 20 .500 29 1.600 19 330 23 540 200.

The Journal of Defense Software Engineering.M. Third Edition. CrossTalk.org 3 Hill. The Journal of Defense Software Engineering. Software Cost Estimation in 2002. Donald J. Practical Project Estimation: A Toolkit for Estimating Software Development Effort and Duration.isbsg. Microsoft Press. CrossTalk. Second Edition. June 2002. 2 http://www. Rapid Development. The Journal of Defense Software Engineering. Steve. Estimating Web Development Costs: There Are Differences. David and Herron. CrossTalk.org 8 Reifer. Estimating Software Earlier and More Accurately. Page 20 of 20 . ISBSG 2005 4 Bennatan. David. On Time Within Budget: Software Project Management Practices and Techniques. June 2002. E.ifpug. 7 http://www. June 2002 6 Jones. Capers.A Time Estimation Approach for Software Projects References 1 McConnell. John Wiley & Sons 2000 5 Garmus. 1996. Peter R.