SOFTWARE COST ESTIMATION techniques (Sommerville's list): ALGORITHMIC COST MODELLING A model is developed using historical cost information which relates some software metric (usually size) to project cost. An estimate is made of that metric and the model predicts the effort required. EXPERT JUDGEMENT Several experts on the proposed techniques and the application domain are consulted. They each estimate, then compare and iterate until agreement. ✔ cheap, fast, and can account for factors no model captures ✘ very inaccurate if no expert has experience of this kind of project ESTIMATION BY ANALOGY The cost of a project is computed by comparing it to a similar completed project in the same application domain. ✔ accurate when a genuinely comparable project exists ✘ impossible if no comparable project has been done PARKINSON'S LAW The project costs whatever resources are available. "Work expands to fill the time available." ✔ no overspend ✘ the system is usually unfinished — this is not an estimating method, it is a description of what happens without one PRICING TO WIN The project costs whatever the customer has to spend. ✔ you get the contract ✘ the probability that the customer gets the system they want is small. Costs do not accurately reflect the work required. TOP-DOWN vs BOTTOM-UP, which cuts across the above: TOP-DOWN start at the system level, assess overall functionality and how it is delivered through subsystems. ✔ accounts for integration, configuration management and documentation — the costs bottom-up estimates always miss ✘ can underestimate low-level technical difficulty BOTTOM-UP start with component-level estimates and sum. ✔ accurate when the components are understood ✘ systematically misses system-level costs, and it is why "just add up the tasks" estimates come in low USE SEVERAL TECHNIQUES. If they produce widely different answers, you do not have enough information to estimate — and saying so is the correct professional response. THE FUNDAMENTAL DIFFICULTY: all algorithmic models need an estimate of SIZE, and size is exactly what you do not know at the start. The model converts one uncertain number into another, with the uncertainty preserved and sometimes amplified by the exponent.

COCOMO — the COnstructive COst MOdel (Boehm, 1981). Its general algorithmic form: EFFORT = A × Size^B × M where A a constant reflecting organisational practices Size the estimated size, in KLOC or function points B an exponent, usually 1 to 1.5, reflecting the DISPROPORTIONATE effort for large projects M a multiplier from process, product and development attributes THE EXPONENT B IS THE MODEL'S MOST IMPORTANT FEATURE. Because B > 1, effort grows FASTER THAN LINEARLY with size — doubling the code more than doubles the work, because of the communication and integration overhead you met as n(n−1)/2 in the design concepts topic. COCOMO 81 — BASIC MODEL. Three project classes: MODE a b c d description ───────────────────────────────────────────────────────── ORGANIC 2.4 1.05 2.5 0.38 small teams, familiar problem, flexible requirements SEMI-DETACHED 3.0 1.12 2.5 0.35 mixed experience, mixed rigidity of requirements EMBEDDED 3.6 1.20 2.5 0.32 tight hardware, software and operational constraints EFFORT E = a × (KLOC)^b person-months DURATION D = c × E^d months STAFF N = E / D people (average) PRODUCTIVITY P = KLOC×1000 / E LOC per person-month THE FULL TABLE, computed — learn how to produce it, and notice the pattern: mode KLOC effort(pm) duration(mo) staff LOC/pm ────────────────────────────────────────────────────────────── organic 10 26.93 8.74 3.08 371.4 organic 50 145.93 16.61 8.79 342.6 organic 100 302.14 21.90 13.80 331.0 semi-detached 10 39.55 9.06 4.37 252.9 semi-detached 50 239.87 17.02 14.09 208.5 semi-detached 100 521.34 22.33 23.34 191.8 embedded 10 57.06 9.12 6.26 175.3 embedded 50 393.61 16.92 23.27 127.0 embedded 100 904.28 22.08 40.96 110.6 WHAT THE TABLE TELLS YOU — three readings that matter more than the arithmetic: 1. PRODUCTIVITY FALLS AS SIZE RISES, within every mode. Organic goes 371 → 343 → 331 LOC/pm; embedded goes 175 → 127 → 111. This is the b > 1 exponent made visible, and it is the reason "we did 10 KLOC in 3 months so 100 KLOC will take 30" is wrong. 2. MODE MATTERS MORE THAN SIZE. At 100 KLOC, embedded needs 904 pm against organic's 302 — a 3× difference for identical size. The CONSTRAINTS on a project dominate its scale. 3. DURATION IS REMARKABLY INSENSITIVE. From 10 to 100 KLOC — a 10× size increase — organic duration goes only 8.74 → 21.90 months, about 2.5×. The extra effort is absorbed by STAFF (3.08 → 13.80), not by calendar time. That is the model telling you something true and important, which the next topic develops. WORKED, step by step — a semi-detached project of 32 KLOC: E = 3.0 × 32^1.12 ln 32 = 3.46574; 1.12 × 3.46574 = 3.88163; e^3.88163 = 48.50 E = 3.0 × 48.50 = 145.5 person-months D = 2.5 × 145.5^0.35 ln 145.5 = 4.98011; 0.35 × 4.98011 = 1.74304; e^1.74304 = 5.714 D = 2.5 × 5.714 = 14.3 months N = 145.5 / 14.3 = 10.2 people P = 32,000 / 145.5 = 220 LOC per person-month (carry full precision through the intermediate steps — rounding ln 32 early shifts E by a person-month) INTERMEDIATE COCOMO adds 15 COST DRIVERS, each rated very low to very high, multiplied together into M: PRODUCT required reliability, database size, product complexity COMPUTER execution time constraint, main storage constraint, virtual machine volatility, turnaround time PERSONNEL analyst capability, applications experience, programmer capability, virtual machine experience, language experience PROJECT modern programming practices, software tools, required development schedule E = a × KLOC^b × Π(cost drivers) THE LARGEST SINGLE DRIVER, in Boehm's data, is PERSONNEL CAPABILITY — the ratio between the best and worst ratings for analyst and programmer capability spans a factor of several. The model is saying, quantitatively, that WHO does the work matters more than almost any technical choice. COCOMO II (1995 onwards) modernises this with four sub-models used at different stages, as more is known: APPLICATION COMPOSITION for prototypes built with scripting and reuse; based on object points EARLY DESIGN after requirements are agreed; based on function points, 7 cost drivers REUSE for integrating reusable components, including the cost of understanding code you did not write POST-ARCHITECTURE once the architecture is designed; 17 cost drivers, the most detailed It also makes the exponent B VARIABLE rather than mode-selected, computed from five scale factors including process maturity and team cohesion.

THE PROBLEM WITH KLOC: you cannot count lines of code that do not exist yet, and the count depends on the language — the same functionality is far fewer lines in Python than in C, which would make the "more productive" language look like a smaller project. FUNCTION POINT ANALYSIS (Albrecht) sizes the FUNCTIONALITY instead, from the specification, and is therefore language-independent. FIVE COUNTED ELEMENTS, each weighted simple / average / complex: EI EXTERNAL INPUTS data entering from outside (weights 3 / 4 / 6) EO EXTERNAL OUTPUTS reports, screens, messages out (weights 4 / 5 / 7) EQ EXTERNAL INQUIRIES an input/output pair with no processing (weights 3 / 4 / 6) ILF INTERNAL LOGICAL logical data groups maintained FILES inside (weights 7 / 10 / 15) EIF EXTERNAL INTERFACE data groups used but maintained FILES elsewhere (weights 5 / 7 / 10) UFP = Σ (count × weight) unadjusted function points THEN ADJUST for 14 general system characteristics (data communications, distributed processing, performance, heavily used configuration, transaction rate, online data entry, end user efficiency, online update, complex processing, reusability, installation ease, operational ease, multiple sites, facilitate change), each rated 0–5: TDI = Σ ratings (0 to 70) VAF = 0.65 + 0.01 × TDI (0.65 to 1.35) FP = UFP × VAF Note the range: the adjustment can swing the answer by ±35% — so VAF is not a rounding detail. WORKED — the licence system, sized from its specification: element count weight product ───────────────────────────────── EI 22 4 88 EO 16 5 80 EQ 9 4 36 ILF 7 10 70 EIF 3 7 21 ───────────────────────────────── UFP 295 General system characteristics rated, TDI = 41 VAF = 0.65 + 0.01 × 41 = 1.06 FP = 295 × 1.06 = 312.7 ≈ 313 function points CONVERTING TO KLOC (backfiring), using published language-productivity figures: Java 53 LOC/FP → 312.7 × 53 = 16,573 ≈ 16.57 KLOC C 128 LOC/FP → 312.7 × 128 = 40,026 ≈ 40.03 KLOC Python 27 LOC/FP → 312.7 × 27 = 8,443 ≈ 8.44 KLOC SAME SYSTEM, 4.7× SPREAD IN CODE SIZE. This is exactly why KLOC is a poor size measure and function points exist. FEEDING THE JAVA FIGURE INTO SEMI-DETACHED COCOMO: E = 3.0 × 16.57^1.12 = 69.6 person-months D = 2.5 × 69.6^0.35 = 11.04 months N = 69.6 / 11.04 = 6.31 people → roughly a 6-person team for about 11 months. AND NOW THE CRITICISM THAT MATTERS: if we had chosen C, the same functionality gives 40.03 KLOC, hence E = 3.0 × 40.03^1.12 = 187.4 pm — 2.7× the effort for the SAME SYSTEM, purely from a language choice fed through a lines-of-code model. Part of that difference is real (C genuinely takes longer per unit of function) and part is an artefact of using KLOC as the size driver at all. A model's output inherits every assumption in its input, and this is the clearest demonstration of it. THE HONEST LIMITATIONS OF ALGORITHMIC MODELS: · they require historical data from YOUR organisation to calibrate; using Boehm's 1981 constants unchanged on a modern project is not calibration, it is decoration · the size estimate they depend on is the least reliable number in the project · they cannot model the things that actually sink projects: requirements churn, staff turnover, a key dependency changing, an organisational reorganisation · the arithmetic is precise, which makes the output look more certain than it is. THE CORRECT OUTPUT OF AN ESTIMATE IS A RANGE WITH A CONFIDENCE, not a single number. · used honestly, they are most valuable for COMPARING OPTIONS ("this option is about twice the other") rather than for predicting absolutes.