Project Management Estimation

LOC and FP Estimation –Lines of code and function points were described as basic data from which productivity metrics can be computed. –LOC and FP data are used in two ways during software project estimation:  as estimation variables that are used to "size" each element of the software, and  as baseline metrics collected from past projects and used in conjunction with estimation variables to develop cost and effort projections.

–The LOC and FP techniques differ in the level of detail required for decomposition. –With LOC, decomposition must be taken to extremes; with FP less detail is required because the data required to estimate function points are more macroscopic. –Note that LOC is estimated directly, FP indirectly.

Expected value? –Regardless of whether LOC or FP is used, the planner provides a range of values for each decomposed function. Using historical data (or intuition) the planner estimates an optimistic, most likely, and pessimistic LOC or FP for each function. –The expected value for LOC or FP is then computed as a weighted average of the three.

For example, E = (a + 4m + b) / 6 gives greatest credence to the most likely estimate and follows a beta probability distribution. Once the expected value has been determined, productivity data are applied.

COCOMO Boehm, in his 1981 book "Software Engineering Economics", introduced a hierarchy of software estimation models called COCOMO, COnstructive COst MOdel. (Version 2 in 1995)  Basic COCOMO,  Intermediate COCOMO,  Advanced COCOMO,  COCOMO is a well developed model which takes project, product, hardware and personnel attributes into account. It also includes means of estimating development schedules. A disadvantage is that it depends on historical data which may not always be available.

Basic COCOMO  a static single-valued model that computes software development effort (and cost) as a function of program size expressed in lines of code.

Intermediate COCOMO  computes software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes.

Advanced COCOMO  incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design,...) of the software engineering process.

COCOMO & 3 classes of project organic mode –relatively small, simple software projects in which small teams with good application experience work to a set of less than rigid requirements –(e.g., a thermal analysis program developed for a heat transfer group);

COCOMO & 3 classes of project semi-detached mode –an intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements –(e.g., a transaction processing system with fixed requirements for terminal hardware and database software);

COCOMO & 3 classes of project embedded mode –a software project that must be developed within a set of tight hardware, software, and operational constraints (e.g., flight control software for aircraft).

Extensions The basic model is extended to consider a set of "cost driver attributes" that can be grouped into four major categories: –Product attributes –Hardware attributes –Personnel attributes –Project attributes

Product attributes Required software reliability Size of application database Complexity of the product

Hardware attributes Runtime performance constraints Memory constraints Volatility of the virtual machine environment Required turnaround time

Personnel attributes Analyst capability Software engineer capability Applications experience Virtual machine experience Programming language experience

Project attributes Use of software tools Application of software engineering methods Required development schedule

Effort Adjustment Factors –Each of the 15 attributes is rated on a 6-point scale that ranges from "very low" to "extra high" (in importance or value). Based on the rating, an effort multiplier is determined from tables published by Boehm, and the product of all effort multipliers results is an effort adjustment factor (EAF.) –Typical values for EAF range from 0.9 to 1.4.

But... –Boehm's own comments about COCOM0 (and by extension all models) should be heeded: –"Today, a software cost estimation model is doing well if it can estimate software development costs within 20% of actual costs, 70% of the time, and on its own turf (that is, within the class of projects to which it has been calibrated).... This is not as precise as we might like, but it is accurate enough to provide a good deal of help in software engineering economic analysis and decision making."

Example... estimated LOC estimated project cost $656,680 estimated effort (PM) and the table of coefficients earlier, and using the semi- detached model, we get E = 3.0 (KLOC) exp(1.12) = 3.0(33.3) 1.12 = 152 person-months

Example contd... To compute project duration, D = 2.5(E) exp(0.35) = 2.5(152) 0.35 = 14.5 months The recommended number of people for the project is therefore, N= E/D = 152/14.5 = 11 people

Automated Estimation Tools –These tools allow the planner to estimate cost and effort and to perform “what if” analyses for important project variables such as delivery date or staffing. –Those based on COCOMO all require the user to provide a preliminary LOC estimate. –They all conduct a dialog with the planner, obtaining appropriate project and supporting information and producing both tabular and graphical output.

Automated Estimation Tools –When a number of tools were applied to the same project, a relatively large variation in estimated results was found, and predicted values were sometimes very different from actual values. –Output from estimation tools should be used as one “data point” from which estimates are derived - not as the only source for an estimate.

Jones’s First-Order Estimation Take the function-point total and raise it to the power chosen from the following table bestaverageworst –Systems –Business –Shrink-wrap The exponents are based on analysis of a database of several thousand projects

Jones’s “kinds of projects” –Systems = operating systems, device drivers, compilers, embedded software, firmware, real- time systems, … –Business = in-house systems for an organisation, payroll, stock control, accounting systems, IS, IT, MIS software, … –Shrink-wrap = packaged and sold commercially

e.g. If FP=350 and project is “shrink-wrap” in an average organisation then = , giving a rough schedule of 12 calendar months. In a best-in-class organisation giving a schedule of 10 months.