Software Development Estimation

Software Development Estimation Model
Software Development Estimation Tools
Software Development Cost Estimation Template

Using the best online project management software for the job is a huge help, but knowing the methods and learning how to do them well is how you become a great estimator. There are a number of estimation methodologies to choose from—and here we’re going to look at five tried-and-trusted ones that work for all types of projects. Building Software is a Process of Discovery. One thing that sets software development apart from other engineering related disciplines is how much room there is for requirements to evolve as the project progresses. This is, in large part, thanks to the intangible nature of a software product.

The four basic steps in Software Project Estimation are − Estimate the size of the development product. Estimate the effort in person-months or person-hours. Estimate the schedule in calendar months. Estimate the project cost in agreed currency. Observations on Estimation. Estimation need not be a one-time task in a project. It can take place. In order to successful software project & proper execution of task, the Estimation Techniques plays vital role in software development life cycle. The technique which is used to calculate the time required to accomplish a particular task is called Estimation Techniques. To estimate a task different.

In software development, effort estimation is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.^[1]^[2]

State-of-practice[edit]

Published surveys on estimation practice suggest that expert estimation is the dominant strategy when estimating software development effort.^[3]

Software estimation is the process of predicting the time and effort required to accomplish development or maintenance tasks. Estimates are generally used to help customers (this could be your own organization) make decisions. This will be an overly simple example to illustrate the process without getting tied up in a lot of detail. This process, originally designed for estimating software development, is not limited to software projects. Although the example in this post is a fictional software product, you can use this process for any type of project. Estimates are typically a necessary evil in software development. Unfortunately, people tend to assume that writing new software is like building a house or fixing a car, and that as such the contractor or mechanic involved should be perfectly capable of providing a reliable estimate for the work to be done in advance of the.

Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. For a review of effort estimation error surveys, see.^[4] However, the measurement of estimation error is problematic, see Assessing the accuracy of estimates.The strong overconfidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or “almost sure” to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70%.^[5]

Currently the term “effort estimate” is used to denote as different concepts such as most likely use of effort (modal value), the effort that corresponds to a probability of 50% of not exceeding (median), the planned effort, the budgeted effort or the effort used to propose a bid or price to the client. This is believed to be unfortunate, because communication problems may occur and because the concepts serve different goals.^[6]^[7]

History[edit]

Software researchers and practitioners have been addressing the problems of effort estimation for software development projects since at least the 1960s; see, e.g., work by Farr ^[8]^[9] and Nelson.^[10]

Most of the research has focused on the construction of formal software effort estimation models. The early models were typically based on regression analysis or mathematically derived from theories from other domains. Since then a high number of model building approaches have been evaluated, such as approaches founded on case-based reasoning, classification and regression trees, simulation, neural networks, Bayesian statistics, lexical analysis of requirement specifications, genetic programming, linear programming, economic production models, soft computing, fuzzy logic modeling, statistical bootstrapping, and combinations of two or more of these models. The perhaps most common estimation methods today are the parametric estimation models COCOMO, SEER-SEM and SLIM. They have their basis in estimation research conducted in the 1970s and 1980s and are since then updated with new calibration data, with the last major release being COCOMO II in the year 2000. The estimation approaches based on functionality-based size measures, e.g., function points, is also based on research conducted in the 1970s and 1980s, but are re-calibrated with modified size measures and different counting approaches, such as the use case points^[11] or object points in the 1990s.

Estimation approaches[edit]

California license plate placement law. There are many ways of categorizing estimation approaches, see for example.^[12]^[13] The top level categories are the following:

Expert estimation: The quantification step, i.e., the step where the estimate is produced based on judgmental processes.^[14]
Formal estimation model: The quantification step is based on mechanical processes, e.g., the use of a formula derived from historical data.
Combination-based estimation: The quantification step is based on a judgmental and mechanical combination of estimates from different sources.

Below are examples of estimation approaches within each category.

Estimation approach	Category	Examples of support of implementation of estimation approach
Analogy-based estimation	Formal estimation model	ANGEL, Weighted Micro Function Points
WBS-based (bottom up) estimation	Expert estimation	Project management software, company specific activity templates
Parametric models	Formal estimation model	COCOMO, SLIM, SEER-SEM, TruePlanning for Software
Size-based estimation models^[15]	Formal estimation model	Function Point Analysis,^[16]Use Case Analysis, Use Case Points, SSU (Software Size Unit), Story points-based estimation in Agile software development, Object Points
Group estimation	Expert estimation	Planning poker, Wideband delphi
Mechanical combination	Combination-based estimation	Average of an analogy-based and a Work breakdown structure-based effort estimate^[17]
Judgmental combination	Combination-based estimation	Expert judgment based on estimates from a parametric model and group estimation

Selection of estimation approaches[edit]

The evidence on differences in estimation accuracy of different estimation approaches and models suggest that there is no “best approach” and that the relative accuracy of one approach or model in comparison to another depends strongly on the context.^[18] This implies that different organizations benefit from different estimation approaches. Findings^[19] that may support the selection of estimation approach based on the expected accuracy of an approach include:

Expert estimation is on average at least as accurate as model-based effort estimation. In particular, situations with unstable relationships and information of high importance not included in the model may suggest use of expert estimation. This assumes, of course, that experts with relevant experience are available.
Formal estimation models not tailored to a particular organization’s own context, may be very inaccurate. Use of own historical data is consequently crucial if one cannot be sure that the estimation model’s core relationships (e.g., formula parameters) are based on similar project contexts.
Formal estimation models may be particularly useful in situations where the model is tailored to the organization’s context (either through use of own historical data or that the model is derived from similar projects and contexts), and it is likely that the experts’ estimates will be subject to a strong degree of wishful thinking.

The most robust finding, in many forecasting domains, is that combination of estimates from independent sources, preferable applying different approaches, will on average improve the estimation accuracy.^[19]^[20]^[21]

It is important to be aware of the limitations of each traditional approach to measuring software development productivity.^[22]

In addition, other factors such as ease of understanding and communicating the results of an approach, ease of use of an approach, and cost of introduction of an approach should be considered in a selection process.

Assessing the accuracy of estimates[edit]

The most common measure of the average estimation accuracy is the MMRE (Mean Magnitude of Relative Error), where the MRE of each estimate is defined as:

MRE = ${displaystyle {frac {|{text{actual effort}}-{text{estimated effort}}|}{text{actual effort}}}}$

This measure has been criticized ^[23]^[24]^[25] and there are several alternative measures, such as more symmetric measures,^[26] Weighted Mean of Quartiles of relative errors (WMQ)^[27] and Mean Variation from Estimate (MVFE).^[28]

MRE is not reliable if the individual items are skewed. PRED(25) is preferred as a measure of estimation accuracy. PRED(25) measures the percentage of predicted values that are within 25 percent of the actual value.

A high estimation error cannot automatically be interpreted as an indicator of low estimation ability. Alternative, competing or complementing, reasons include low cost control of project, high complexity of development work, and more delivered functionality than originally estimated. A framework for improved use and interpretation of estimation error measurement is included in.^[29]

Psychological issues[edit]

There are many psychological factors potentially explaining the strong tendency towards over-optimistic effort estimates that need to be dealt with to increase accuracy of effort estimates. These factors are essential even when using formal estimation models, because much of the input to these models is judgment-based. Factors that have been demonstrated to be important are: Wishful thinking, anchoring, planning fallacy and cognitive dissonance. A discussion on these and other factors can be found in work by Jørgensen and Grimstad.^[30]

It's easy to estimate what you know.
It's hard to estimate what you know you don't know. (known unknowns)
It's very hard to estimate things that you don't know you don't know. (unknown unknowns)

Humor[edit]

The chronic underestimation of development effort has led to the coinage and popularity of numerous humorous adages, such as ironically referring to a task as a 'small matter of programming' (when much effort is likely required), and citing laws about underestimation:

Ninety-ninety rule:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.^[31]

— Tom Cargill, Bell Labs

Hofstadter's law:

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

— Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid^[32]

Fred Brooks' law:

What one programmer can do in one month, two programmers can do in two months.

Adding to the fact that estimating development efforts is hard, it's worth stating that assigning more resources doesn't always help.

Comparison of development estimation software[edit]

Software	Schedule estimate	Cost estimate	Cost Models	Input	Report Output Format	Supported Programming Languages	Platforms	Cost	License
AFCAA REVIC^[33]	Yes	Yes	REVIC	KLOC, Scale Factors, Cost Drivers	proprietary, Text	any	DOS	Free	Proprietary Free for public distribution
Seer for Software^[34]	Yes	Yes	SEER-SEM	SLOC, Function points, use cases, bottoms-up, object, features	proprietary, Excel, Microsoft Project, IBM Rational, Oracle Crystal Ball	any	Windows, Any (Web-based)^[35]	Commercial	Proprietary
SLIM^[36]	Yes	Yes	SLIM	Size (SLOC, Function points, Use Cases, etc.), constraints (size, duration, effort, staff), scale factors, historical projects, historical trends	proprietary, Excel, Microsoft Project, Microsoft PowerPoint, IBM Rational, text, HTML	any	Windows, Any (Web-based)^[37]	Commercial	Proprietary
TruePlanning^[38]	Yes	Yes	PRICE	Components, Structures, Activities, Cost drivers, Processes, Functional Software Size (Source Lines of Code (SLOC), Function Points, Use Case Conversion Points (UCCP), Predictive Object Points (POPs) etc.)	Excel, CAD	any	Windows	Commercial	Proprietary

References[edit]

^'What We do and Don't Know about Software Development Effort Estimation'.
^'Cost Estimating And Assessment Guide GAO-09-3SP Best Practices for developing and managing Capital Program Costs'(PDF). US Government Accountability Office. 2009.
^Jørgensen, M. (2004). 'A Review of Studies on Expert Estimation of Software Development Effort'. Journal of Systems and Software. 70 (1–2): 37–60. doi:10.1016/S0164-1212(02)00156-5.
^Molokken, K. Jorgensen, M. (2003). 'A review of software surveys on software effort estimation'. 2003 International Symposium on Empirical Software Engineering, 2003. ISESE 2003. Proceedings. pp. 223–230. doi:10.1109/ISESE.2003.1237981. ISBN978-0-7695-2002-5.CS1 maint: multiple names: authors list (link)
^Jørgensen, M. Teigen, K.H. Ribu, K. (2004). 'Better sure than safe? Over-confidence in judgement based software development effort prediction intervals'. Journal of Systems and Software. 70 (1–2): 79–93. doi:10.1016/S0164-1212(02)00160-7. Archived from the original on 2009-08-19.CS1 maint: multiple names: authors list (link)
^Edwards, J.S. Moores (1994). 'A conflict between the use of estimating and planning tools in the management of information systems'. European Journal of Information Systems. 3 (2): 139–147. doi:10.1057/ejis.1994.14.
^Goodwin, P. (1998). Enhancing judgmental sales forecasting: The role of laboratory research. Forecasting with judgment. G. Wright and P. Goodwin. New York, John Wiley & Sons: 91-112. Hi
^Farr, L. Nanus, B. 'Factors that affect the cost of computer programming, volume I'(PDF).CS1 maint: multiple names: authors list (link)
^Farr, L. Nanus, B. 'Factors that affect the cost of computer programming, volume II'(PDF).CS1 maint: multiple names: authors list (link)
^Nelson, E. A. (1966). Management Handbook for the Estimation of Computer Programming Costs. AD-A648750, Systems Development Corp.
^Anda, B. Angelvik, E. Ribu, K. (2002). Improving Estimation Practices by Applying Use Case Models. Lecture Notes in Computer Science. 2559. pp. 383–397. CiteSeerX10.1.1.546.112. doi:10.1007/3-540-36209-6_32. ISBN9783540002345-9783540362098 Check |isbn= value: length (help).CS1 maint: multiple names: authors list (link)
^Briand, L. C. and Wieczorek, I. (2002). Resource estimation in software engineering. Encyclopedia of software engineering. J. J. Marcinak. New York, John Wiley & Sons: 1160-1196.
^Jørgensen, M. Shepperd, M. 'A Systematic Review of Software Development Cost Estimation Studies'.CS1 maint: multiple names: authors list (link)
^'Custom Software Development Services - Custom App Development - Oxagile'.
^Hill Peter (ISBSG) - Estimation Workbook 2 - published by International Software Benchmarking Standards Group ISBSG - Estimation and Benchmarking Resource Centre
^Morris Pam — Overview of Function Point Analysis Total Metrics - Function Point Resource Centre
^Srinivasa Gopal and Meenakshi D'Souza. 2012. Improving estimation accuracy by using case based reasoning and a combined estimation approach. In Proceedings of the 5th India Software Engineering Conference (ISEC '12). ACM, New York, NY, USA, 75-78. DOI=https://dx.doi.org/10.1145/2134254.2134267
^Shepperd, M. Kadoda, G. (2001). 'Comparing software prediction techniques using simulation'. IEEE Transactions on Software Engineering. 27 (11): 1014–1022. doi:10.1109/32.965341.CS1 maint: multiple names: authors list (link)
^ ^a^bJørgensen, M. 'Estimation of Software Development Work Effort:Evidence on Expert Judgment and Formal Models'.
^Winkler, R.L. (1989). 'Combining forecasts: A philosophical basis and some current issues Manager'. International Journal of Forecasting. 5 (4): 605–609. doi:10.1016/0169-2070(89)90018-6.
^Blattberg, R.C. Hoch, S.J. (1990). 'Database Models and Managerial Intuition: 50% Model + 50% Manager'. Management Science. 36 (8): 887–899. doi:10.1287/mnsc.36.8.887. JSTOR2632364.CS1 maint: multiple names: authors list (link)
^BlueOptima. 'Identifying Reliable, Objective Software Development Metrics'.
^Shepperd, M. Cartwright, M. Kadoda, G. (2000). 'On Building Prediction Systems for Software Engineers'. Empirical Software Engineering. 5 (3): 175–182. doi:10.1023/A:1026582314146.CS1 maint: multiple names: authors list (link)
^Kitchenham, B. Pickard, L.M. MacDonell, S.G. Shepperd. 'What accuracy statistics really measure'.CS1 maint: multiple names: authors list (link)
^Foss, T. Stensrud, E. Kitchenham, B. Myrtveit, I. (2003). 'A Simulation Study of the Model Evaluation Criterion MMRE'. IEEE Transactions on Software Engineering. 29 (11): 985–995. CiteSeerX10.1.1.101.5792. doi:10.1109/TSE.2003.1245300.CS1 maint: multiple names: authors list (link)
^Miyazaki, Y. Terakado, M. Ozaki, K. Nozaki, H. (1994). 'Robust regression for developing software estimation models'. Journal of Systems and Software. 27: 3–16. doi:10.1016/0164-1212(94)90110-4.CS1 maint: multiple names: authors list (link)
^Lo, B. Gao, X. 'Assessing Software Cost Estimation Models: criteria for accuracy, consistency and regression'.CS1 maint: multiple names: authors list (link)
^Hughes, R.T. Cunliffe, A. Young-Martos, F. (1998). 'Evaluating software development effort model-building techniquesfor application in a real-time telecommunications environment'. IEE Proceedings - Software. 145: 29. doi:10.1049/ip-sen:19983370.CS1 maint: multiple names: authors list (link)
^Grimstad, S. Jørgensen, M. (2006). 'A Framework for the Analysis of Software Cost Estimation Accuracy'.CS1 maint: multiple names: authors list (link)
^Jørgensen, M. Grimstad, S. 'How to Avoid Impact from Irrelevant and Misleading Information When Estimating Software Development Effort'.CS1 maint: multiple names: authors list (link)
^Bentley, Jon (1985). 'Programming pearls'. Communications of the ACM(fee required)|format= requires |url= (help). 28 (9): 896–901. doi:10.1145/4284.315122. ISSN0001-0782.
^Gödel, Escher, Bach: An Eternal Golden Braid. 20th anniversary ed., 1999, p. 152. ISBN0-465-02656-7.
^AFCAA Revic 9.2 manual Revic memorial site
^Seer for Software Datasheet Galorath site
^'SEER for Software Estimation - Technical Features'.
^'SLIM Suite Overview'. Qsm.com. Retrieved 2019-08-27.
^'SLIM-WebServices'. Qsm.com. Retrieved 2019-08-27.
^TruePlanning Integrated Cost Models PRICE Systems site

External links[edit]

Mike Cohn's Estimating With Use Case Points from article from Methods & Tools: http://www.methodsandtools.com/archive/archive.php?id=25
Resources on Software Estimation from Steve McConnell: https://web.archive.org/web/20080501183154/http://www.construx.com/Page.aspx?nid=297

Retrieved from 'https://en.wikipedia.org/w/index.php?title=Software_development_effort_estimation&oldid=918672139'

26 Dec 2013CPOL

Estimate size, effort and schedule for a software product

Introduction

“When will you or your team be able to complete this project or software or feature?” How often you listen above phrase from your bosses or project leads or managers? I do here them a lot and it’s always an annoying experience for me to give an estimate just by judgment or without any preparation. I always tried to find the answers in the books but estimation is difficult subject to understand. Estimation is science as well as an art.

Estimation is huge subject but in this article I only cover some of the most important aspects of the estimation. This article is for the people who are starting to put their foot steps into the estimation world. This article is for those people who want to answer their bosses about an estimate of the project they are going to develop based on the science and proven principles of estimation not by sole judgement.

By reading this article one will be able to estimate size, effort and schedule for future projects. A second objective of this article is to enable the reader to develop one’s organization/group projects matrices. In this article I first discuss the challenges or the problems which one can face during estimation then estimation purpose and some misconception about estimation. After that I will discuss the benefits of estimation and then discuss what constitute an estimate. After that I will discuss briefly the kind techniques one can use for estimation. Next I will discuss my estimation experience and walk you through the estimation for two of my past projects. Finally I discuss about the matrices and historical data.

Challenges in estimation

When estimating any software project we omit a lot of factors which may affect one’s overall estimate. Therefore before giving an estimate one should consider these factors.

Personnel experience

Individuals involve in the projects effect the estimate. Most experience developers perform better than junior developers. Therefore knowing the persons who will actually work or perform the task during the project execution is of very importance while estimating.

Project size and type of project

Project size also affects the estimation process. One cannot simply use the previous experience of small projects to estimate the large projects. Studies have shown effort does not scale up linearly but exponentially. This is because larger projects require more integration effort between the components. In large project we need larger teams and the size of the team also affects the total effort because in large teams we have to deal with the problem of communication among the team members. Hence in larger teams new efforts such as communication and coordination are added which increases the total effort require to complete the project.

Type of the project is another important factor. If an organization have experience developing desktop application they will take more time to complete a web application. Therefore when you develop matrices or historical data and making estimation do take into account the type of the project.

Level of uncertainty

In every project there are many phases or stages during the development. These are from inception to final production output. These stages may be inception, requirements, design, development, testing and then delivery to production environment. Now in the very start of the project there is too much uncertainty about the final product or what will be the end product. Because requirements may change during any stage of the development or new parameter or new problems can arrive at any stage of the development. Due to this phenomena during estimation process if you estimate about the project at the start of the project that estimate will be less accurate when compare to the estimate at the later stages or final stages.

Uncertainty level decreases as the project progresses from inception phase to implementation phase. If one re-estimates their project during the later stages of the development they can get a better estimate than their initial estimates.

Different Assumptions

Another factor to take into consideration is programming language used because some programming supports a large eco-system. For some programming languages there are many tools available which are not available for others. If you choose a programming language that is supported by a large community then you will have more tools available and more help is readily available. This community support greatly enhance the productivity of the development team.

Similarly when estimating the project one must take into consideration the time available for the developers. In one project when we estimate we must take into account either developer are available the whole time or they will be engaged in other projects during the development.

Estimation Purpose and Approaches

There are two situations in which one has to estimate the project. First situation is that your boss come to you and gives you a feature list or requirements list. After that you are asked to give the total time required to implement all of these features. You estimate the project and give your estimates to your boss. Boss take these estimate and put into a larger sub-total for a large project. In this situation when you are estimating you do not have any time limit. In this estimate you are not kept under-pressure for deadline. This type situation happens very rarely.

In second situation you have a deadline and a list of features to implement. Your task is to develop an estimate for all the features that you can give before the deadline. We face most of the time this second situation. There may be times when with all resources available one cannot deliver the output on or before the deadline. In this situation one has to negotiate either the deadline or the number of features for implementation.

Estimation alone cannot guarantee you the project completion at the committed date. One need project control and good project management skills to complete the project according to the estimate. Therefore in software project management estimation is just one part and just help out in planning.

Benefit from Estimation

When you have the estimation you have a framework to control the project. One can measure their performance at any time during the project. Estimation allows for better resource allocation. Estimation allows basic foundation to develop plans upon. Good estimation provides the basis for better risk management and high project progress visibility.

What we do in estimation?

When one is given the task for estimation one has to estimate three things size, effort and schedule. One can adopt one or many techniques to calculate of each of these estimates. It is a better idea to go for many techniques while estimating. This will help you to sanity check your estimates. Because if two techniques give estimates which are very distant from each another then it means there is some wrong assumption on which one is making estimates.

In estimation first we estimate the size. This is because most of the effort or schedule equations require providing them with the size parameter. Size can either be in LOC (Lines of Code) or in function points. These are two major units for calculating the software size. Since at the start of the project one cannot have the LOC therefore Function Points calculation is used. From function points we can estimate the LOC required for implementing function points. Function points to LOC calculation is based upon the programming language you are using. For example to implement one function point in C# one needs 40 to 80 Lines of code or 55 Lines of code as median value. There are other units for calculating the size estimation and examples of these are: no of user stories, no of use cases and no of web pages.

Effort is directly calculated from the size of the software. There are many models for calculating the effort. Effort is time required for one person to complete the project. Effort can be calculated in staff-month, staff-week or person-hour. Here week and month are dependent upon the company policy. For example in my organization there are 32 hours in each week. If there are more than one person in the team then you have to account for that too because it will definitely reduce the schedule.

After the estimation one can devise up the schedule for completing the project. There are also models and techniques for estimating the schedule for a software project. Schedule is calculated in either months or weeks. There is one major point when working on schedule estimation. One can ask how much we compress the schedule by adding more and more resources. But in software project estimation one cannot compress to infinite. Take for example if 4 people require 4 month to complete a project therefore 40 people require 1 month to complete the project similarly in this way 800 people can complete the project in one day! This is not possible. Hence one cannot compress the schedule beyond a certain point. That point and beyond is called the impossible zone. According to a research one cannot compress the schedule beyond 25% of its nominal schedule. The reason for this schedule compression limit is that in order to reduce the schedule one has to increase the number of developers and this will increase communication problem among the team members. Another reason is inn shorter amount of time one have complete the tasks in parallel and if that task depend upon each other then error produce in dependent task will propagate the error.

Now let's discuss the estimation process or flow. For the sake of simplicity the flow of the estimation is:

Size ---> Effort ---> Schedule

Software Development Estimation Model

First estimate the size and based on the size one can estimate the effort and then from effort one can easily calculate the schedule. The reader see the application for this process in the upcoming examples.

What are different types of techniques?

There are two categories of techniques for estimation. Techniques in the first category are based upon the scientific methods such as COCOMO. In scientific methods we have the mathematical equations and from those equations one calculates the effort and schedule. Second category is based upon the empirical methods. Examples are expert judgment and informal comparison to past projects. Software based tools used scientific methods and used historical data for calibration of these scientific methods.

Some techniques are good for sequential and some estimation techniques are good for iteration based development model. Similarly some techniques are tuned for use in the start of the project and other is used late in the project. Some techniques also depend upon the size of the project different techniques for large project, medium project and other for small projects. Since description of these techniques are out of bound for this article therefore it is leftover to reader to explore.

Example estimation for Two Projects

To better understand the estimation process and some estimation concepts I take two of my previous projects. One good thing about these projects is that I have maintained the log of each project. For example for each project I have a log file like this:

Software Development Estimation Tools

Date, Time given to project, Project related task description

e.g:30th April, 2 hours, implement file parsing for project A (Name of the project)

I record all this log in my personal log journal.

Software Development Cost Estimation Template

With the help of this log I can easily calculate the total time to complete up the project.

I take two projects and from the description of their features I calculate the total function points to complete the project. I used function points because it is easier to drive function points from the features list and requirements document. From these function points I calculate the expected number of lines to implement these function points using C#. After that I compare it with the actual no of lines to complete the project.

In this way I estimate the size and then compare it with the actual size in SLOC(Source lines of code). I found very astonishing similarities. In this way I estimate the effort and schedule and then compare it with the actual effort and schedule to complete the project. This study gives me a lot of awareness for the estimation techniques.

Therefore I am sharing my experience for each project here. For protecting organization data I cannot disclose the real name of the projects here therefore I have used two other names: Project A and Project B.

(1) Estimation for Project A

Now I will estimate the size, effort and schedule from the requirements or feature list of the project A. After that I will compare this estimate with the actual size, effort and schedule. In this way I will show the reader that how the estimation work and how you can compare it after you have completed the project.

SIZE for Project A

As discussed earlier I have used function points for estimating the size. Briefly Project A is a data acquisition and processing software. It displays acquired data on the screen.

In function points estimation we have to take into accounts all external inputs, external outputs, internal logical files, external interface file and external queries. Now for project A

10. Untouchables - (featuring Sheek / Syleena Johnson / InfaRed / Drag-On). Dmx songs download free mp3.

External Inputs	Complexity
Data Stream	High
Configuration files	Low
User Selection	Medium
User Input	Low

As you can see each parameter is assigned a complexity value which is either high, low or medium. One can give this value by determining the complexity that will be tackle when writing the code for that particular parameter. Similarly we estimate the external output

External Output	Complexity
Telemetry Data1 screen	Medium
Telemetry timing screen	Low
Telemetry Data2 Screen	Medium
Status Screen	Medium

and now internal Logical Files

Internal Logical Files	Complexity
Storage file	Medium
Intermediate buffer	High
Intermediate Result	Low
Channel Files	Low

Windows 98 download. Now the external interface files

External Interface Files	Complexity
External Interface for Data2	Low

External Queries

Not Any.

Now as you can see that all of this files and inputs grading is only possible when you have carefully analyze the specification or requirements. If one miss any of the important parameter then that will result in an error in the estimate. Therefore function points estimates are more accurate when performed by an experience developer.

After identifying all possible parameters one can calculate the function points as follows:

Parameters	Low	Medium	High
External Inputs	2*3=6	1*4=4	1*6=6
External Outputs	1*4=4	3*5=15	0*7=0
External Queries	0*3=0	0*4=0	0*6=0
Internal Logical Files	2*7=14	1*10=10	1*15=15
External Interface Files	1*5=5	0*7=0	0*10=0

Here first number in the multiplication (bold one) is the count parameter in that category and the second number is a fixed number given by the Function Points method itself.

If we add up the result of each we get the value of 79. This is called the un-adjusted FPs value. Either we can take this un-adjusted function point value as size or we adjust it using a multiplier. This multiplier may come from the past project i.e. historical data or from the type of project for which you are estimating. I will try with 3 multipliers as shown below:

Multiplier	Adjusted Function Point
1	79
1.2	94.8
0.8	63.2

Now one can choose any multiplier and then multiply it with the un-adjusted FPs. This will give us the Adjusted function point count.

There is table which can convert the function point’s calculation to Source Lines of Code (SLOC) measure. For each function to implement one need 40 to 80 Lines of C# code and median value is 55.

Adjusted Function Points	Median C# LOC	Range of C# LOC
79	4345	3160 to 6320
94.8	5214	3792 to 7584
63.2	3476	2523 to 5056

Hence in this way I estimated the size of the project A. Now let’s check it with the reality. Are these numbers any closer to reality? Since I have the actual code of the project A software I can count the actual number of lines of code for the software.

I used a utility for LOC calculation. I have not counted the white space and the designer generated code but I do count the comments because a lot of effort was invested in writing good comments. Therefore in actual code I have got 4700 lines of code which is very near to estimated size of 4345. One can see that this estimation is very close to the actual lines of code written.

Hence I consider my Multiplier for adjusting the function points as 1 and make a record of it in my historical data.

EFFORT for Project A

For effort estimation I used the ISBSG(International Software Bench-marking Standards Group ) method. ISBSG takes function points as inputs and number of staff to complete the project and return the effort estimate. Since I have estimated the size of the project A and there is only person doing the job I can estimate the required effort for completing project A.

ISBSG (Using Equation for Desktop software)

In reality from my log register I can calculate the actual effort which is:

Hence one can see there is only 6% error in estimation.

Spss torrent download. It is most used and world-leading statistical software. It has used for ad-hoc analysis and hypothesis and time-saving abilities. Ibm Spss Crack 25 Full Version Free Download TorrentIbm Spss Crack, is a statistical information evaluation and data analysis software program. Spss is effective and finishes a pack of analytic techniques.

SCHEDULE for Project A

One can calculate using basic schedule equation

This 3.0 can be 2.0 or 4.0 based on your organization historical data, but if you don’t have the historical data you can go with the number 3.0.

This Schedule equation mostly works with medium to large projects and for the projects which executes sequentially.

The real effort or the number of actual months in which the project is completed is 3 months which is roughly equal to the schedule equation’s output.

Other methods of estimating the schedule is by comparing to the past projects completed in that area in your own organization. Comparing to the past project gives an highly accurate estimate than any other method.

Using the estimate software will give us the accurate more accurate results but again estimation software mostly require calibration data or your own organization’s past projects data.

(2) Estimation for Project B

Now similar to project A I have complete the same procedure for Project B and estimated the size, effort and schedule and then compare each one of that with the actual size, effort and schedule. I will just go through all the steps with detail description here.

SIZE for Project B

External Inputs	Complexity
Serial data	High
Screen control	Medium
Site Testing Data Files	Low
Tiles	Medium
User Movement control	High
Simulation In File	Medium

External Outputs	Complexity
1)Screen display	High
2)Screen Status	Low

Internal Logical Files	Complexity
1)Tiles Files	High
2)Result in excel	Low

External Interface File	Complexity
1)Tiles downloading	High

External Queries

Not Any

Now estimating un-adjusted function points in the following table:

Parameters	Low	Medium	High
External Inputs	1*3=3	3*4=12	2*6=12
External Outputs	1*4=4	0	1*7=7
External Queries	0	0	0
Internal Logical Files	1*7=7	0	1*15=15
External Interface Files	0	0	1*10=10

Here un-adjusted function count is 66.

For adjustment

Multiplier	Adjusted function points
1	66
0.8	52.8
1.2	79.2

Adjusted Function Points	Median C# LOC	Range of C# LOC
66	3630	2640 to 5280
52.8	2904	2112 to 4224
79.2	4354	3168 to 7128

Now as we have estimated the size.

The real size of project B is: 2761 LOC. No automated generated code and no blank lines are counted.

When we look at the multiplier there is 30 % error for multiplier “1” and 5% error for “0.8” multiplier.

Here multiplier 0.8 produces function points and LOC which are very near to the actual. There I make a not of this kind of project in my historical data. For simplicity purpose the reader may choose any and then stick to that multiplier.

Effort for Project B

Now the actual effort in completing the project from my log register is:

One can see there 2.5% error in the original estimate.

Schedule for Project B

Estimating the schedule using Basic Schedule Equation

The actual schedule or time take to complete the project is around 3 Months from my log register.

Historical Data and its Importance

My assumption

Before deep diving into the estimation world I assume that historical data or industry specific data must be of more than 100 projects. But this is not the case in estimation. You only need 2 to 3 project’s data. This amount of data is enough to estimate for the future projects. This amount of data is enough to use in any type calibration software and to calibrate any other estimation technique such as COCOMO. Therefore I encourage the reader of this article to go for collecting there organization data even if they have completed two projects up to now.

There is a difference between industry specific data and an organization data. Industry specific data is collected from organization working in the same type of project. This industry specific data is not very accurate since each and every organization has its own environment which affects the overall the estimate. Organization data or historical data is related to single organization or your organization in which you are currently working. Historical data is of very importance and can be used for getting accurate estimation.

How did I make my historical data?

After understanding the historical data and clearing the confusion for assumption I tried to gather the information for my past projects. Although I have completed many projects in the past I do not have their records or logs. But I do have the records or the logs of the 2 recent projects.

What to collect in order to have some historical data. From past project one can collect size of the project, effort and schedule for each project. Data for 2 to 3 projects will be enough for accurate estimate.

In my Organization I have these parameters:

1 day = 6 men-hour

1 Week = 30 men-hour

1 Month = 132 men-hour

1 Month =22 days

You can adjust these parameters according to your own organization.

Following is the historical data that I collect to use in future projects for estimation. These are related to the two examples that I have discussed in this article previously.

Historical data matrix:

Project Name	Size(LOC)	Size(FPS)	Effort(hours)	LOC/Hour	FP/Hour	Schedule
Project A	5000	79	291	17.18	0.271	3-Months
Project B	2761	52.8	201	13.7363	0.262	3-Months

This historical data is based on two examples which I have discussed in this article above.

Use in Estimation software

One can find a very good COCOMO based estimation software from the USC (University of Southern California website) at this link. Another software is from Construx which is free to use and can be downloaded from here. In both of these software tools you can calibrate using historical data for getting accurate estimates.

Both of these software are very good in estimating the effort and schedule if they are provided with the calibration data also known as historical data. Check these estimation software and see how they can help you.

Productivity matrices

From the historical data one can measure the productivity of their organization. From above two examples I can drive the productivity matrix here.

Productivity Matrix in Person-Day:

Project Name	LOC	FPS
Project A	103.08	1.626
Project B	82.4178	1.572

By using these matrices I can estimate any future project that I will be asked to develop.

To conclude I emphasize everyone collect their historical data. After 2 projects they can use modern techniques such as COCOMO and software based techniques to estimate their future projects.

Conclusion

In this I article I introduced briefly the topic of estimation, what are the challenges that we face during estimation process. I describe the estimation process with the help of two projects and share some of my own experience. I also describe the importance of managing the historical data as well as provide guidelines and example for managing historical data. One can start estimating their future project from the information given in this article straight away. Their starting or initial estimates may contain errors but they will refine their skills after a couple of projects. After all estimation is a science as well as art.

Additional Resources

1) Book, Software Engineering: A Practitioner's Approach by Roger S Pressman

2) Book, Software Estimation: Demystifying the black art by Steve McConnell

Nindeath