1.

Table of Contents What is Costs Estimation?.....................................................................................................................................2 1.1. Types of Cost Estimate .................................................................................................................................2 Conceptual Estimate............................................................................................................................2 Detailed Estimate ................................................................................................................................2

1.1.1. 1.1.2. 2. 3.

Why Costs Estimation? .........................................................................................................................................2 How to Make Cost Estimation? .............................................................................................................................4 3.1. Non-algorithmic Methods ............................................................................................................................5 Analogy costing: ..................................................................................................................................5 Expert judgment: .................................................................................................................................6 Parkinsons Method ............................................................................................................................6 Price-to-Win Model .............................................................................................................................6 The Definitive Estimate (or bottom-up estimate) ...............................................................................7 The Budget Estimate (or top-down estimate) .....................................................................................7 Reserve Analysis: .................................................................................................................................7

3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.1.5. 3.1.6. 3.1.7. 3.2.

Algorithmic methods ....................................................................................................................................7 Cost factors ..........................................................................................................................................8 Linear models ......................................................................................................................................8 Power function models .......................................................................................................................8 COCOMO 1 ..........................................................................................................................................8 COCOMO 2 ........................................................................................................................................11

3.2.1. 3.2.2. 3.2.3. 3.2.4. 3.2.5. 4. 5. 6.

Effort Estimation? ...............................................................................................................................................13 Why Effort Estimation? .......................................................................................................................................13 How Effort Estimating? .......................................................................................................................................13 6.1. 6.2. Deductive or Top-down Methods ..............................................................................................................15 Inductive or Bottom-up Methods ..............................................................................................................15 Factor Analysis:..................................................................................................................................15 Multiplication Method: .....................................................................................................................15 Analogy Method: ...............................................................................................................................15 Function Point Method: ....................................................................................................................16 Delphi Method: .................................................................................................................................16

6.2.1. 6.2.2. 6.2.3. 6.2.4. 6.2.5.

Page 1 of 16

1. What is Costs Estimation?

In a book 'How to be a Better Project Manager', Trevor L Young defines estimating as; "A decision about how much time and resource are required to carry out a piece of work to acceptable standards of performance." And Cost Estimate as; The process of forecasting a future result in terms of cost, based upon information available at the time." Projects normally have a budget, and continual cost estimation is necessary to ensure that spending is in line with the budget. Accurate software cost estimates are critical to both developers and customers. It answers the questions what are the costs associated with the effort required to produce each major deliverables, what are the costs associated with hardware and software, what other non-labor costs need to be considered, and what operating costs need to be considered and identified.

1.1.Types of Cost Estimate

Cost estimates fall into two groups: conceptual estimates and detailed estimates. Each can be broadly defined as follows:

1.1.1. Conceptual Estimate

Conceptual estimating or parametric estimating is the process of establishing a projects cost, often before any graphical representation of a facility has been developed.

1.1.2. Detailed Estimate

The detailed construction estimate is the product of a process whereby the cost of a proposed construction project is predicted. The estimate is prepared by breaking down the items of work in an orderly and logical basis, determining the cost of each item from experience, and summarizing the total.

2. Why Costs Estimation?

IT suffers from a universal law: the first-time, first-use penalty. The concept of the first-time, first-use penalty is that it's next to impossible to accurately estimate the cost of something that has never been attempted. IT is so unique, so multifaceted, and has so many fronts that the constant movement of its variables creates a love-hate relationship for any organization trying to create an IT cost estimate. Management asks, "Would you like more time?" We respond, "Thank you, no. I'll take some M-O-N-E-Y." Customers offer, "Would you like to reduce the scope?" We answer, "Thank you, no. I'll take some M-ON-E-Y." Sponsors demand a speedier schedule. We respond, "Thank you, no. I'll take some M-O-N-E-Y."

Page 2 of 16

From IT to construction, most projects have to purchase materials: routers and cables, shingles and cement, and so on. We almost always must buy some things to complete the project work. Regardless of scope or schedule, projects need funds to complete the work. Technically, even projects that use only labor have funds attached to them; someone, somewhere is paying for that labor. What happens if you don't have the correct amount of funds to complete the project scope? Your project is doomed.

The ultimate goal of cost estimation is to determine the amount of fixed and variable costs so that a cost equation can be used to predict future costs. The function that represents the equation of a line will appear in the format of:

y=mx+b
Where y = total cost m = the slope of the line, i.e., the unit variable cost x = the number of units of activity b = the y-intercept, i.e., the total fixed costs

To avoid project cost overruns. Minimizing the differences between preliminary project planning cost estimates and final project design cost estimates. Accurate cost estimation is important because It can help to classify and prioritize development projects with respect to an overall business plan.

Page 3 of 16

3. How to Make Cost Estimation?

The actual cost estimation process involves seven steps: 1) Establish cost-estimating objectives 2) Generate a project plan for required data and resources 3) Pin down software requirements 4) Work out as much detail about the software system as feasible 5) Use several independent cost estimation techniques to capitalize on their combined strengths 6) Compare different estimates and iterate the estimation process 7) After the project has started, monitor its actual cost and progress, and feedback results to project management No matter which estimation model is selected, users must pay attention to the following to get best result. Many techniques, books and software packages exist to help with estimating project costs. A few simple rules will also help ensure you create an accurate and realistic estimate. Assume resources will only be productive for 80 percent of their time. Resources working on multiple projects take longer to complete tasks because of time lost switching between them. People are generally optimistic and often underestimate how long tasks will take. Make use of other people's experiences and your own. Get an expert view. Include management time in any estimate. Always build in contingency for problem solving, meetings and other unexpected events. Cost each task in the Work Breakdown Structure to arrive at a total, rather than trying to cost the project as a whole. Agree a tolerance with your customer for additional work that is not yet defined. Communicate any assumptions, exclusions or constraints you have to your customer. Provide regular budget statements to your customer, copying your team, so they are always aware of the current position.

Page 4 of 16

These are some of the common mistakes that can lead to inaccurate estimates. Not understanding what is involved to complete an item of work. Starting with an amount of money and making the project cost fit it. Assigning resources at more than 80 percent utilization. Failing to build in contingency. Failing to adjust the estimate following changes in scope. Dividing tasks between more than one resource. Providing estimates under pressure in project meetings. Giving single-data-point estimates rather than range estimates.

There are two major types of cost estimation methods: algorithmic and non-algorithmic. Algorithmic models vary widely in mathematical sophistication. Some are based on simple arithmetic formulas using such summary statistics as means and standard deviations. Others are based on regression models and differential equations. To improve the accuracy of algorithmic models, there is a need to adjust or calibrate the model to local circumstances. These models cannot be used off-the-shelf. Even with calibration the accuracy can be quite mixed. We first give an overview of non-algorithmic methods.

3.1.Non-algorithmic Methods
3.1.1. Analogy costing:
An analogy costing model is a non-algorithmic costing model that estimates the cost of a project by relating it to another similar completed project. Estimation by analogy can be done either at the total project level or at subsystem level. The total project level has the advantage that all cost components of the system will be considered while the subsystem level has the advantage of providing a more detailed assessment of the similarities and differences between the new project and the completed projects. Take a completed project, similar in scope, size, structure, environment, constraints, and functions to the current project as its benchmark. Use reasoning and analogy to relate the actual costs incurred for elements of the completed project to similar elements in the current project. Such estimation may be conducted either top-down or bottom-up. This method has the advantage of assessing costs based on actual project experience rather than theoretical assumptions. Success, however, depends on the extent to which the previous project bears resemblance to the current project, and such relation remains subjective.

Page 5 of 16

A related method is the parametric estimation model, or taking historical information as the base, making assumptions regarding changes, and extrapolating the information to the preset project

3.1.2. Expert judgment:

The expert judgment costing model makes the assessment of costs by leveraging the experience of one or more subject matter experts (SME). A common expert judgment model is the Delphi technique, which involves constituting an expert panel, conducting a survey where each expert states their opinion, followed by discussion, and repeating the exercise multiple rounds until all the experts develop a consensus to identify a common cost estimate. Agile projects rely on the experience of people who actually undertake the work and remain familiar with actual costs, rather than theoretical or boardroom experts detached from the actual operations. Expert judgment methods are grounded in practical realities but remain highly subjective. Success depends wholly on the skills and competence of the experts chosen.

3.1.3. Parkinsons Method

Parkinsons Law holds that work expands to fill the available volume or time. Using this percept, cost estimation is based on identifying available resources rather than any objective assessment or estimates. For instance, the cost estimate for a software project with a timeframe of 12 months and personnel requirement of five entails direct calculation of the wages of five people for 12 months. This method, though simple and straightforward, may create unrealistic estimates and may not cover all bases. Although it sometimes gives good estimation, this method is not recommended as it may provide very unrealistic estimates. Also, this method does not promote good software engineering practice.

3.1.4. Price-to-Win Model

The price-to-win model estimates cost based on the customers budget rather than internal resources or capabilities, and by extension depends on the product pricing, which in turn depends on market forces. This is a practical approach, for ultimately the net cost is what the customer pays, minus profits, and any excess scope or size invariably gets toned down to match customer budgets. For instance, if a software project was estimated at 500 person-months, it would invariably be toned down to 300 person-months if the customer could afford only that much. On the flip side, this approach does not consider the possibility of projects incurring loss owing to scope creep or any other reason. This is again not a good practice since it is very likely to cause a bad delay of delivery or force the development team to work overtime.

Page 6 of 16

3.1.5. The Definitive Estimate (or bottom-up estimate)

It is the most accurate of the estimate types, but takes the most time to create. The definitive estimate requires a work breakdown structure (WBS). A WBS is not a list of activities. A WBS is a deliverables-oriented decomposition of the project scope. That's decomposition of the deliverables that your project will create for the customer. Then each component of the software system is separately estimated and the results aggregated to produce an estimate for the overall system. The requirement for this approach is that an initial design must be in place that indicates how the system is decomposed into different components

3.1.6. The Budget Estimate (or top-down estimate)

It is a bit more accurate. Formulated fairly early in the project's planning stage, the budget estimate is most often based on analogous estimating, taking budget lessons learned from a similar project and applying them to the current project. Do a little maths magic and we've got ourselves a budget estimate. With the budget estimate, we start at the top and work our way down into the project details. This estimate should include conditions, a range of variance, and any assumptions that went into your calculations. A budget estimate is quick, but not very accurate. The range of variance on the budget estimate is from -10 percent to +25 percent. This approach is more suitable for cost estimation at the early stage.

3.1.7. Reserve Analysis: The method deals with unforeseen circumstances in a project environment, which necessitates the establishment of reserves for the project activities. These reserves are also called contingency allowances that are utilized for reducing risks, and countering threats. Characteristics of a cost estimating system are to ensure that the cost estimates are accurate. If the funds are not adequate, then the reserves are used for the project activities.

3.2.Algorithmic methods
The algorithmic methods are based on mathematical models that produce cost estimate as a function of a number of variables, which are considered to be the major cost factors. Any algorithmic model has the form: Effort = f(x1, x2, , x) where {x1, x2, , xn}

Denote the cost factors. The existing algorithmic methods differ in two aspects: the selection of cost factors, and the form of the function f. We will first discuss the cost factors used in these models, then characterize the models according to the form of the functions and whether the models are analytical or empirical.

Page 7 of 16

3.2.1. Cost factors

Besides the software size, there are many other cost factors. The most comprehensive set of cost factors are proposed and used by Boehm et al in the COCOMO II model. These cost factors can be divided into four types: Product factors: required reliability; product complexity; database size used; required reusability; documentation match to life-cycle needs; Computer factors: execution time constraint; main storage constraint; computer turnaround constraints; platform volatility; Personnel factors: analyst capability; application experience; programming capability; platform experience; language and tool experience; personnel continuity; Project factors: multisite development; use of software tool; required development schedule. The above factors are not necessarily independent, and most of them are hard to quantify. In many models, some of the factors appear in combined form and some are simply ignored. Also, some factors take discrete values, resulting in an estimation function with a piece-wise form.

3.2.2. Linear models

Linear models have the form:

Where,a1,a2..,an are selected according to the project information. work of Nelson belongs to this type of models [26]. We agree with Boehm's comment that "there are too many nonlinear interactions in software development for a linear model to work well.

3.2.3. Power function models

Power function models have the general form: Effort = aSb Where S is the code-size, and a, b are (usually simple) functions of other cost factors. This class contains two of the most popular algorithmic models in use, as follows:

3.2.4. COCOMO 1
The most popular algorithmic cost estimation model for software projects is the Constructive Cost Model (COCOMO II), developed by Barry Boehm and Ellis Harrowitz in 2000. 3.2.4.1. The basic COCOMO'81 It is a simple static model that considers the software development cost as a function of a program's size expressed in estimated lines of code.

Page 8 of 16

It computes software development effort (and cost) as a function of program size expressed in estimated lines of code (LOC). The basic COCOMO estimation model is given by the following expressions: Effort = a * (KLOC)b PM Tdev = 2.5 * (Effort)c Months here KLOC is the estimated size of the software product expressed in Kilo Lines of Code a, b, c are constants for each category of software products Tdev is the estimated time to develop the software, expressed in months Effort is the total effort required to develop the software product, expressed in person months (PMs) The effort estimation is expressed in units of person-months (PM). The value of the constants a, b, c are given below: Software project Organic Semi-detached Embedded a 2.4 3.0 3.6 b 1.05 1.12 1.20 c 0.38 0.35 0.32

3.2.4.2. The intermediate COCOMO'81 model It computes software development cost as a function of program size and a set of four subjective cost drivers: product factors, computer factors, constraints, and personnel factors. Product factors include aspects such as required reliability, complexity, usability, size of database, and more. Computer factors include constraints such as execution time, storage, turnaround, and platform volatility. Personnel factors include capability of the analyst, application, language, and tool experience, personnel continuity, and more. Project factors include multi-site development, software tools and more. The basic COCOMO model assumes that effort and development time are functions of the product size alone. However, many other project parameters apart from the product size affect the development effort and time required for the product. Therefore, in order to obtain an accurate estimation of the effort and project duration, the effect of all relevant parameters must be taken into account.

Page 9 of 16

The intermediate COCOMO model recognizes this fact and refines the initial estimate obtained using the basic COCOMO expressions by using a set of 15 cost drivers (multipliers) based on various attributes of software development. For example, if modern programming practices are used, the initial estimates are scaled downward by multiplication with a cost driver having a value less than 1. Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to "extra high" (in importance or value) as shown below. An effort multiplier from the table below [i] applies to the rating. The product of all effort multipliers results in an Effort Adjustment Factor (EAF).

EAF is used to refine the estimates obtained by basic COCOMO as follows: Effort|corrected = Effort * EAF Tdev|corrected = 2.5 * (Effort|corrected) c 3.2.4.3. The detailed COCOMO'81 model It incorporates all characteristics of the intermediate version and also incorporates an assessment of the cost drivers impact on each step of the software engineering process.

Page 10 of 16

Regardless of the cost estimation model chosen, success depends on a good understanding of how the model works and how to apply it to determine project costs. A project manager is better off adopting a familiar yet limited albeit suitable model rather than another model, which may enjoy better industry recognition but which the project manager remains incompetent to handle. The following development project can be considered as an example application of the complete COCOMO model. A distributed Management Information System (MIS) product for an organization having offices at several places across the country can have the following sub-components: Database part Graphical User Interface (GUI) part Communication part Of these, the communication part can be considered as embedded software. The database part could be semidetached software, and the GUI part organic software. The costs for these three components can be estimated separately, and summed up to give the overall cost of the system.

3.2.5. COCOMO 2
Cocomo 2 consists of two models; the Early Design Model and the Post-Architecture model. The Early design model is a high-level model and can be used in the architectural design stage to explore architectural alternatives or incremental development strategies. This model is closest to the original COCOMO. The Post-Architectural model on the other hand is a more detailed model that can be used for the actual development stage and maintenance stage. It is the most detailed version of COCOMO 2. Both the early Design model and the Post-Architecture model use the same formula to estimate the amount of effort required to develop a software project. Besides these two models also the Application Composition model is described by B. Bohem. The Application Composition model can be used as sizing metric for application composition; and the estimation is based on the number of screens, reports and 3GL components.

Page 11 of 16

Formula:

Page 12 of 16

4. Effort Estimation?
Effort can be measured in staff-hours or staff-months (Used to be known as man-hours or man-months). Effort estimation is answering two basic questions about testing: I. What will be done? How much effort would it take?

II.

A project manager has to produce: An estimate of the effort. An estimate of the activity durations.

An estimate of effort affects ------- Cost

An estimate of activity durations affects The delivery time

5. Why Effort Estimation?

Estimating the effort of software development is fraught with difficulties, and it is clear that effort should be invested in improving the accuracy and the reliability (consistency) of effort estimates, as well as the assessment of estimate uncertainty. However, it is less clear where to target such improvement efforts.

6. How Effort Estimating?

Effort estimation represents step 3 of the project planning process.

Before we can plan the project schedule we have to estimate effort and duration of all the work packages of the WBS. Effort estimation will generate a lot more information than only effort and duration:

Page 13 of 16

 Who will be responsible for each work package? What is the work package specification? What are the expected results of each work package? How is the achievement of the results measured? What are the prerequisites for the work package? What are the conditions under which the work has to be done? What are the required start and end times? What and how much material is needed for each work package, at what cost? What tools are needed for each work package, at what rates? Obviously, effort estimation needs expertise on a work package specific level to accomplish this transition.

Page 14 of 16

There are two categories of estimating the effort of each work package: deductive and inductive methods.

6.1.Deductive or Top-down Methods

Assume the total cost for the project is given. From there we assign the cost, and thus, the effort of individual work packages based on estimated percentages derived from earlier, similar projects with similar work packages. The advantage of deductive methods is a simple and rapid cost allocation, the disadvantage is that they only work for projects that consist of work packages we already know from earlier, similar projects.

6.2.Inductive or Bottom-up Methods

The basic idea of inductive methods is to start effort estimation with the work packages individually, with support of experts, or knowledge of similar work packages of earlier projects, and then summarize bottom up, following the structure of the WBS.

6.2.1. Factor Analysis:

For a certain work package, we know all the variables or factors, how they influence the work, and how these factors correlate with each other. Then we can calculate the effort based on a mathematical formula which reflects that influences and correlations.
Effort = f (influencing variables, correlation coefficients).

For example, the effort of a work package "Develop hardware control unit" is influenced by the number of people involved, P=4, the number of interfaces, S=5, the number of functional blocks, B=10. From earlier projects with similar control units we might know the correlation coefficients. For example, cP=2.5, cS=2, cB=1.5, cU=2.0. Our formula could look like this Effort = f(P, S, B) = cP*P + cS*S*S + cB*B = = 10 + 50 + 15 = = 75 (working days)

6.2.2. Multiplication Method:

If we can divide a work package into a number of equal parts then, we can estimate the total effort by estimating one part and then multiplying this value by the number of parts. Total Effort = Effort of one part * number of parts

6.2.3. Analogy Method:

This method again applies the knowledge from similar work packages. We interpolate or extrapolate the effort for the work package from a similar one. For example, for the work package Install electrical wiring in an apartment of 100 sqm we could guess the effort by interpolation from similar work for apartments of 150 sqm, 10 working days, and 50 sqm, 6 working days:

Page 15 of 16

Effort(100 sqm) = (10 + 6) / 2 = 8 working days.

6.2.4. Function Point Method:

For IT or software design related work packages we can apply the function point method. The prerequisite is that we need to have a lot of knowledge about the effort of work packages of similar scope and degree of difficulty, based on observation. Then the experts compile this knowledge into so called function curves which we can use to estimate effort for new work packages. In the following example we estimate the effort of work about creating 100, 500, and 800 lines of code. We obtain the effort via the corresponding function points on the function curve, 5, 16, and 33 working days, respectively.

6.2.5. Delphi Method:

For most of our work packages we use the Delphi method. We just ask the experts for each work package for their best guess, normal guess, and worst guess. Thus we obtain three figures for the expected effort: E(optimistic), E(normal), and E(pessimistic), then combine them with this formula Effort = (E(optimistic) + 4*E(normal) + E(pessimistic)) / 6. If we can ask ten or more experts, we could even calculate the mean values and apply mathematical statistics with the concept of standard deviation. Usually, we ask all the experts to join an effort estimation workshop which can be combined with a risk management workshop, of two, three, or more days depending on the number of work packages that have to be estimated.

Page 16 of 16