A Time Estimation Approach For Software Projects
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View A Time Estimation Approach For Software Projects as PDF for free.
More details
- Words: 5,586
- Pages: 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. 2. 3. 4. 5.
Determine the Project Scope Identify the Application Boundary Count the Function Points Evaluate the Function Point Complexity 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 0 1
Degree of Influence Non-existent Insignificant
2
Moderate
3
Average
4
Significant
5
Strong
Examples • The application does use this characteristic. • Simple addition/subtraction • Simple logical algorithms • Simple data relationships • Many calculations, including multiplication/division in series • More complex, nested algorithms • Multidimensional data relationships • 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 • 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 • 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
ILF
1
EIF
0
0 x7
7 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: Functional Size Development platform Development type
Project 540 Midrange New development
Matching ISBSG Projects 250 - 750 function points Midrange 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 PDRCE optimistic PDRCE likely PDRCE conservative
= mean of optimistic / likely / conservative project delivery rates = 6.1 hours per function point = 10.3 hours per function point = 24.6 hours per function point
Project work effort
PWECE PWECE optimistic PWECE likely PWECE conservative
= PDRCE i * Size = 3,305 hours = 5,565 hours = 13,276 hours
Project duration
SDCE PDCE optimistic PDCE likely PDCE conservative
= Size / SDCE i = 5.1 months = 7.9 months = 10.5 months
Speed of delivery
SDCE i SDCE optimistic SDCE likely SDCE conservative
= mean of optimistic/likely/conservative speeds of delivery = 104.9 function points per month = 68.1 function points per month = 51.3 function points per month
Page 10 of 20
A Time Estimation Approach for Software Projects
Table 5 - ISBSG Results Project delivery rate (hours per function point)
Speed of delivery (function points per month)
Optim (25th%)
Likely (median)
Conserv (75th%)
Conserv (25th%)
Likely (median)
Optim (75th%)
Attribute
Value
Number of matches
Business area type Application type
Personnel
0
Management information system 5-8
2
3.3
4.9
6.6
64.5
86.3
108.2
1
7.9
7.9
7.9
51.8
51.8
51.8
3GL C++
16 3
6.8 4.5
9.1 7.9
15.4 27.4
69.2 45.8
104.9 51.8
146.8 108.7
2-5
3
8.0
8.2
26.4
41.1
42.6
47.2
2-5
1
44.6
44.6
44.6
39.6
39.6
39.6
>5
4
6.6
26.4
45.2
39.7
41.2
64.5
No Yes
18 8
6.7 3.6
9.1 8.0
15.9 20.3
66.6 41.9
99.2 62.1
134.8 138.9
Developed inhouse
7
4.8
8.2
28.4
41.2
51.8
101.1
Client server Yes
5 11
8.2 8.6
12.1 9.1
44.6 15.7
39.8 63.5
42.6 98.2
72.3 126.6
Maximum team size Language type Primary programming language User base business units User base locations User base concurrent users Used CASE Used methodology How methodology acquired Architecture Web 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 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 Systems 0.43 0.45 Business 0.41 0.43 Shrink-wrap 0.39 0.42 Table 6 - Exponents for Computing Schedules from FP1
Worst in Class 0.48 0.46 0.45
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 (lines of code)
Schedule (months)
Effort (manmonths)
Schedule (months)
Effort (manmonths)
Schedule (months)
Effort (manmonths)
10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 50,000 60,000 70,000 80,000 90,000 100,000 120,000 140,000 160,000 180,000 200,000 250,000 300,000 400,000 500,000
6 7 8 9 9 10 11 11 11 12 13 14 14 15 16 17 18 19 20 22 24 27 30
25 40 57 74 110 130 170 195 230 285 350 410 480 540 680 820 960 1,100 1,250 1,650 2,100 2,900 3,900
3.5 4.1 4.6 5.1 5.5 5.8 6 6 7 7 8 8 9 9 10 10 10 11 11 13 14 15 17
5 8 11 15 22 26 34 39 46 57 71 83 96 110 140 160 190 220 250 330 420 590 780
4.2 4.9 5.6 6 7 7 7 8 8 9 9 10 10 11 11 12 13 13 14 15 16 19 20
8 13 19 24 37 44 57 66 79 98 120 140 170 190 240 280 335 390 440 580 725 1,000 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 of code)
Schedule (months)
Effort (manmonths)
Schedule (months)
Effort (manmonths)
Schedule (months)
Effort (manmonths)
10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 50,000 60,000 70,000 80,000 90,000 100,000 120,000 140,000 160,000 180,000 200,000 250,000 300,000 400,000 500,000
8 10 11 12 13 14 15 16 16 18 19 20 21 22 23 25 26 28 29 32 34 38 42
24 38 54 70 97 120 140 170 190 240 290 345 400 450 560 670 709 910 1,300 1,300 1,650 2,350 3,100
4.9 5.8 7 7 8 8 9 9 10 10 11 12 12 13 14 15 15 16 17 19 20 22 25
5 8 11 14 20 24 30 34 40 49 61 71 82 93 115 140 160 190 210 280 345 490 640
5.9 7 8 9 9 10 10 11 11 12 13 14 15 15 16 17 18 19 20 22 24 27 29
8 12 18 23 32 39 49 57 67 83 100 120 140 160 195 235 280 320 360 470 590 830 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 System Size (lines of code)
Systems Products Schedule Effort (man(months) months)
Business Products Schedule Effort (man(months) months)
Shrink-Wrap Products Schedule Effort (man(months) months)
10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 50,000 60,000 70,000 80,000 90,000 100,000 120,000 140,000 160,000 180,000 200,000 250,000 300,000 400,000 500,000
10 12 14 15 16 17 18 19 20 21 23 24 25 26 28 30 32 34 35 38 41 47 51
6 7 8 9 9 10 10 11 11 12 13 14 15 15 16 17 18 19 20 22 24 27 29
7 8 9 10 11 12 13 13 14 15 16 17 17 18 20 21 22 23 24 26 29 32 35
48 76 110 140 185 220 270 310 360 440 540 630 730 820 1,000 1,200 1,400 1,600 1,900 2,400 3,000 4,200 5,500
9 15 21 27 37 44 54 61 71 88 105 125 140 160 200 240 280 330 370 480 600 840 1,100
15 24 34 44 59 71 88 100 115 145 175 210 240 270 335 400 470 540 610 800 1,000 1,400 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
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. 2. 3. 4. 5.
Determine the Project Scope Identify the Application Boundary Count the Function Points Evaluate the Function Point Complexity 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 0 1
Degree of Influence Non-existent Insignificant
2
Moderate
3
Average
4
Significant
5
Strong
Examples • The application does use this characteristic. • Simple addition/subtraction • Simple logical algorithms • Simple data relationships • Many calculations, including multiplication/division in series • More complex, nested algorithms • Multidimensional data relationships • 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 • 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 • 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
ILF
1
EIF
0
0 x7
7 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: Functional Size Development platform Development type
Project 540 Midrange New development
Matching ISBSG Projects 250 - 750 function points Midrange 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 PDRCE optimistic PDRCE likely PDRCE conservative
= mean of optimistic / likely / conservative project delivery rates = 6.1 hours per function point = 10.3 hours per function point = 24.6 hours per function point
Project work effort
PWECE PWECE optimistic PWECE likely PWECE conservative
= PDRCE i * Size = 3,305 hours = 5,565 hours = 13,276 hours
Project duration
SDCE PDCE optimistic PDCE likely PDCE conservative
= Size / SDCE i = 5.1 months = 7.9 months = 10.5 months
Speed of delivery
SDCE i SDCE optimistic SDCE likely SDCE conservative
= mean of optimistic/likely/conservative speeds of delivery = 104.9 function points per month = 68.1 function points per month = 51.3 function points per month
Page 10 of 20
A Time Estimation Approach for Software Projects
Table 5 - ISBSG Results Project delivery rate (hours per function point)
Speed of delivery (function points per month)
Optim (25th%)
Likely (median)
Conserv (75th%)
Conserv (25th%)
Likely (median)
Optim (75th%)
Attribute
Value
Number of matches
Business area type Application type
Personnel
0
Management information system 5-8
2
3.3
4.9
6.6
64.5
86.3
108.2
1
7.9
7.9
7.9
51.8
51.8
51.8
3GL C++
16 3
6.8 4.5
9.1 7.9
15.4 27.4
69.2 45.8
104.9 51.8
146.8 108.7
2-5
3
8.0
8.2
26.4
41.1
42.6
47.2
2-5
1
44.6
44.6
44.6
39.6
39.6
39.6
>5
4
6.6
26.4
45.2
39.7
41.2
64.5
No Yes
18 8
6.7 3.6
9.1 8.0
15.9 20.3
66.6 41.9
99.2 62.1
134.8 138.9
Developed inhouse
7
4.8
8.2
28.4
41.2
51.8
101.1
Client server Yes
5 11
8.2 8.6
12.1 9.1
44.6 15.7
39.8 63.5
42.6 98.2
72.3 126.6
Maximum team size Language type Primary programming language User base business units User base locations User base concurrent users Used CASE Used methodology How methodology acquired Architecture Web 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 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 Systems 0.43 0.45 Business 0.41 0.43 Shrink-wrap 0.39 0.42 Table 6 - Exponents for Computing Schedules from FP1
Worst in Class 0.48 0.46 0.45
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 (lines of code)
Schedule (months)
Effort (manmonths)
Schedule (months)
Effort (manmonths)
Schedule (months)
Effort (manmonths)
10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 50,000 60,000 70,000 80,000 90,000 100,000 120,000 140,000 160,000 180,000 200,000 250,000 300,000 400,000 500,000
6 7 8 9 9 10 11 11 11 12 13 14 14 15 16 17 18 19 20 22 24 27 30
25 40 57 74 110 130 170 195 230 285 350 410 480 540 680 820 960 1,100 1,250 1,650 2,100 2,900 3,900
3.5 4.1 4.6 5.1 5.5 5.8 6 6 7 7 8 8 9 9 10 10 10 11 11 13 14 15 17
5 8 11 15 22 26 34 39 46 57 71 83 96 110 140 160 190 220 250 330 420 590 780
4.2 4.9 5.6 6 7 7 7 8 8 9 9 10 10 11 11 12 13 13 14 15 16 19 20
8 13 19 24 37 44 57 66 79 98 120 140 170 190 240 280 335 390 440 580 725 1,000 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 of code)
Schedule (months)
Effort (manmonths)
Schedule (months)
Effort (manmonths)
Schedule (months)
Effort (manmonths)
10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 50,000 60,000 70,000 80,000 90,000 100,000 120,000 140,000 160,000 180,000 200,000 250,000 300,000 400,000 500,000
8 10 11 12 13 14 15 16 16 18 19 20 21 22 23 25 26 28 29 32 34 38 42
24 38 54 70 97 120 140 170 190 240 290 345 400 450 560 670 709 910 1,300 1,300 1,650 2,350 3,100
4.9 5.8 7 7 8 8 9 9 10 10 11 12 12 13 14 15 15 16 17 19 20 22 25
5 8 11 14 20 24 30 34 40 49 61 71 82 93 115 140 160 190 210 280 345 490 640
5.9 7 8 9 9 10 10 11 11 12 13 14 15 15 16 17 18 19 20 22 24 27 29
8 12 18 23 32 39 49 57 67 83 100 120 140 160 195 235 280 320 360 470 590 830 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 System Size (lines of code)
Systems Products Schedule Effort (man(months) months)
Business Products Schedule Effort (man(months) months)
Shrink-Wrap Products Schedule Effort (man(months) months)
10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 50,000 60,000 70,000 80,000 90,000 100,000 120,000 140,000 160,000 180,000 200,000 250,000 300,000 400,000 500,000
10 12 14 15 16 17 18 19 20 21 23 24 25 26 28 30 32 34 35 38 41 47 51
6 7 8 9 9 10 10 11 11 12 13 14 15 15 16 17 18 19 20 22 24 27 29
7 8 9 10 11 12 13 13 14 15 16 17 17 18 20 21 22 23 24 26 29 32 35
48 76 110 140 185 220 270 310 360 440 540 630 730 820 1,000 1,200 1,400 1,600 1,900 2,400 3,000 4,200 5,500
9 15 21 27 37 44 54 61 71 88 105 125 140 160 200 240 280 330 370 480 600 840 1,100
15 24 34 44 59 71 88 100 115 145 175 210 240 270 335 400 470 540 610 800 1,000 1,400 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
Related Documents
A Time Estimation Approach For Software Projects
August 2019 19
Software Estimation Techniques Review
May 2020 14
Software Estimation Technique 1
April 2020 6
Software Project Estimation
May 2020 7
Software Projects Failure 1
December 2019 7
555_delay Time Projects
November 2019 11More Documents from ""
A Time Estimation Approach For Software Projects
August 2019 19
Why Use Technology
May 2020 13
Curriculum Vitae Up To Date.doc
May 2020 11
My Space Guide For Parents
August 2019 38
Amw Hrpolicydetails 9mobile Reimbursement Policy
July 2020 3