Software Estimation Dror Feitelson Software Engineering Hebrew University

Necessary Tradeoff? ScheduleScope QualityBudget

Common Approaches Estimation is useful – Given desired scope, estimate cost and schedule – Needed early to draw contracts Traditional: commit to scope (features) – Schedule and budget may slip – Quality may be sacrificed Agile: commit to time-boxing and quality – Set the budget (staffing) – Scope may be adjusted in agreement with client

Estimation Estimation is required for Setting schedule Deciding on staffing Together this dictates cost / budget But hard to do, often optimistic Schedule may be unrealistic Staffing may be inadequate

Traditional Cost/Time Estimation size difficulty effort productivity work rate cost LoC, fp mm (ideal) mm $ $/mm time

Modeling Simple functional shape – e.g. – Based on general observations Very many parameters Calibration based on past experience Speculative due to high uncertainty Not very accurate

But how should we measure (and estimate) the size of a software project?

LoC What is a line? What is code? Typically count statements Exclude comments Exclude blank lines What about marcos? What about temporary code, e.g. testing? Depends on language – handled in other part of model How do you estimate LoC from requirements? size difficulty effort product. work rate cost

Function Points (fp) Estimate the functional content of the project – Based on requirements – Mainly external aspects of the system (black box) – Can be used early in the life cycle Invented at IBM in 1970s Geared towards information systems Several variants, e.g. used by SPR (Capers Jones’s company) Translation of fp to LoC depends on language – fp itself independent of language size difficulty effort product. work rate cost

Function Points (fp) How is it done? Based on counting 4-7 parameters Multiplying them by weighting factors Summing up the weighted counts Multiplying by a complexity adjustment factor size difficulty effort product. work rate cost

fp Spreadsheet ParameterCountWeightResult Number of inputs_____x 4 =_____ Number of outputs_____x 5 =_____ Number of queries_____x 4 =_____ Number of data files_____x 10 =_____ Number of interfaces_____x 7 =_____ Unadjusted total_____ Complexity adjustment_____ Adjusted fp total_____ size difficulty effort product. work rate cost

fp Spreadsheat ParameterCountWeightResult Number of inputs_____X 4 =_____ Number of outputs_____X 5 =_____ Number of queries_____X 4 =_____ Number of data files_____X 10 =_____ Number of interfaces_____X 7 =_____ Unadjusted total_____ Complexity adjustment_____ Adjusted fp total_____ size difficulty effort product. work rate cost Controls (what to do) Internal (e.g. index) With other programs Screens Records / fields

fp Spreadsheat ParameterCountWeightResult Number of inputs_____x 4 =_____ Number of outputs_____x 5 =_____ Number of queries_____x 4 =_____ Number of data files_____x 10 =_____ Number of interfaces_____x 7 =_____ Unadjusted total_____ Complexity adjustment_____ Adjusted fp total_____ size difficulty effort product. work rate cost Can have different weights for “simple”, “average”, or “complex”

Complexity Adjustment Data communications Distributed functions Performance objectives 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 size difficulty effort product. work rate cost Rate each on a scale of 0 to 5 Sum them up Divide by 100 Add 0.65 This gives a factor in the range (  35%)

Complexity Adjustment Data communications Distributed functions Performance objectives 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 size difficulty effort product. work rate cost Rate each on a scale of 0 to 5 Sum them up Divide by 100 Add 0.65 This gives a factor in the range (  35%) 0 = no influence 1 = insignificant influence 2 = moderate influence 3 = average influence 4 = significant influence 5 = strong influence

Complexity Adjustment Data communications Distributed functions Performance objectives 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 size difficulty effort product. work rate cost Rate each on a scale of 0 to 5 Sum them up Divide by 100 Add 0.65 This gives a factor in the range (  35%)

fp Spreadsheat ParameterCountWeightResult Number of inputs_____x 4 =_____ Number of outputs_____x 5 =_____ Number of queries_____x 4 =_____ Number of data files_____x 10 =_____ Number of interfaces_____x 7 =_____ Unadjusted total_____ Complexity adjustment factor (  35%) _____ Adjusted function point total_____ size difficulty effort product. work rate cost

COCOMO Stands for COnstructive COst MOdel Published by Barry Boehm in 1981 for waterfall COCOMO II update for modern methodologies published in 2000 Actually three models, with many parameters – Early prototype: checking high-risk issues stage – Early design: architecture development stage – Post-architecture: code development to delivery stage, very detailed

Size in COCOMO II size difficulty effort product. work rate cost Start with function points Translate to KLoC based on language LanguageLoC/fp Assembly320 C128 Fortran Lisp64 Java53 Visual C++34 Perl27

The Model size difficulty effort product. work rate cost MM = man-months of effort KLoC = lines of code (‘000) – Includes model for taking reuse into account – Also estimate factor of increase due to changes SF j = set of scaling factors EM i = set of effort multipliers

The Model size difficulty effort product. work rate cost Note: not the other way around!!!

Calibration The model includes two “top-level” constants – Average productivity of 2.94 and exponent of 0.91 Also dozens of parameters in scaling factors and effort multipliers These are all derived by calibrating the model to data about 161 specific projects from the late 1990s using Bayesian approach Users should calibrate to their own data

The Exponent size difficulty effort product. work rate cost <1 reflects economy of scale – Uncommon – Possible due to fixed startup costs in small projects >1 reflects diseconomy of scale – Due to growth of inter-person communication needs – Due to growth of integration overhead

Scaling Factors size difficulty effort product. work rate cost The project is similar to previous ones Flexibility in achieving goals Risks have been resolved Team is cohesive Process is mature (based on 18-item questionnaire) Each factor has several levels Each level has a score – Scores go down from ~0.07 to 0

Scaling Factors size difficulty effort product. work rate cost The project is similar to previous ones Flexibility in achieving goals Risks have been resolved Team is cohesive Process is mature (based on 18-item questionnaire) Each factor has several levels Each level has a score – Scores go down from ~0.07 to 0 Example: Thoroughly unprecedented = Largely unprecedented = Somewhat unprecedented = Generally familiar = Largely familiar = Thoroughly familiar =

Effort Multipliers size difficulty effort product. work rate cost Each has a scale of possible values All scales include 1.00 as the default Some have only higher values Others have both higher and lower Required reliability Database size Product complexity Intended reusability Suitability of documentation Execution time constrains Main storage constraint Platform volatility Analysts capabilities Programmers capabilities Personnel continuity Applications experience Platform experience Language/tools experience Use of tools Multi-site development Required schedule

Effort Multipliers size difficulty effort product. work rate cost Each has a scale of possible values All scales include 1.00 as the default Some have only higher values Others have both higher and lower Required reliability Database size Product complexity Intended reusability Suitability of documentation Execution time constrains Main storage constraint Platform volatility Analysts capabilities Programmers capabilities Personnel continuity Applications experience Platform experience Language/tools experience Use of tools Multi-site development Required schedule Example: Very low = 0.73 Low = 0.87 Nominal = 1.00 High = 1.17 Very high = 1.34 Extra high = 1.74 Selection based on table with examples for control, data computation, devices, and user interface

Effort Multipliers size difficulty effort product. work rate cost Each has a scale of possible values All scales include 1.00 as the default Some have only higher values Others have both higher and lower Required reliability Database size Product complexity Intended reusability Suitability of documentation Execution time constrains Main storage constraint Platform volatility Analysts capabilities Programmers capabilities Personnel continuity Applications experience Platform experience Language/tools experience Use of tools Multi-site development Required schedule Example: Nominal = 1.00 High = 1.05 Very high = 1.17 Extra high = 1.46 Available storage used:  50% 70% 85% 95%

Effort Multipliers size difficulty effort product. work rate cost Each has a scale of possible values All scales include 1.00 as the default Some have only higher values Others have both higher and lower Required reliability Database size Product complexity Intended reusability Suitability of documentation Execution time constrains Main storage constraint Platform volatility Analysts capabilities Programmers capabilities Personnel continuity Applications experience Platform experience Language/tools experience Use of tools Multi-site development Required schedule Highest impact on productivity, as assessed by max/min factor: Staff capabilities: 3.53 Project complexity: 2.38 Time constraint: 1.63 All others: range of 1.26 to 1.54

Example size difficulty effort product. work rate cost Assume an estimated size of 100 KLoC Average large project exponent = 1.15 Average project all effort multipliers = 1.00

Use-Case Points Function points are based on information system concepts like queries and transactions Modern systems are not characterized by the same attributes But they can be characterized in terms of use-cases Which are also known in an early phase of the lifecycle

Use-Case Points

UC = Sum of weights for simple, average, and complex use cases TypeStepsClassesWeight Simple 33 55 5 Average complex>7>1015

Use-Case Points A = Sum of weights for simple, average, and complex actors TypecharacteristicsWeight SimpleProgrammatic using API1 AverageProgrammatic using protocol 2 ComplexHuman using GUI3

Use-Case Points TECH = Technical complexity factor Each factor scored from 0 to 5 and Multiplied by weight From table Range: Distributed system0.02 Resp. time requirement0.01 End-user efficiency0.01 Complex processing0.01 Reusable code0.01 Easy to install0.005 Easy to use0.005 Portability0.02 Maintenance0.01 Concurrent/parallel0.01 Security features0.01 Access by third party0.01 End-user training0.01

Use-Case Points ENV = environmental complexity factor Each factor scored from 0 to 5 and Multiplied by weight From table Range: Familiarity with process0.045 Application experience0.015 OO experience0.03 Lead analyst capability0.015 Team motivation0.03 Requirements stability0.06 Part-time staff-0.03 Difficult programming language-0.03

Agile Estimation Approach is to guarantee quality and schedule at possible expense of features User stories broken into tasks of 1-3 “ideal days” Measure velocity = how many ideal days correspond to a real day Plan user stories for next iteration taking velocity into account

Schedule Common approach: Manager decides on schedule Subordinates tell him it will be OK – SNAFU principle: Accurate communication is only possible between equals Engineers don’t have a say Schedule slippage is discovered too late Overwork, hysteria, reduced quality, and late delivery

Brooks’s Law From “The Mythical Man-Month” Adding manpower to a late software project makes it later  Men and months are not interchangeable Attributed to – The need to train new personnel – communication overhead within a larger team – Serial tasks like design, debugging, and integration

Schedule Alternative approach: Manager decides on schedule Subordinates provide estimates – Based on best available input from engineers – Managers may not change this Manager creates feedback loop: disappointing estimates lead to revised resources or tasks for engineers Schedule affects manager’s performance rating but not engineer performance rating

Technical Debt Oftentimes you have two options of how to do something: A clean design OR Quick and dirty The difference between them is the technical debt: It burdens future development (harder to make progress) It accrues interest (you will pay by harder work) You can (and should?) pay off the principal (refactor to achieve a clean design)

Examples Not using classes to separate concerns Partial/no unit testing Using an inefficient algorithm because it’s simpler Not checking inputs Using bad identifier names or not naming constants Using constants instead of settable parameters Skipping documentation Cryptic if any error messages

Examples Not using classes to separate concerns Partial/no unit testing Using an inefficient algorithm because it’s simpler Not checking inputs Using bad identifier names or not naming constants Using constants instead of settable parameters Skipping documentation Cryptic if any error messages Technical debt is a form of risk (albeit risk introduced intentionally) Managing technical debt is risk management

Considerations Take on debt to exploit a business opportunity – e.g. make a release to gain market share Pay off debt to avoid paying interest – Will make future progress more efficient, but.. – Incurs “wasted” time in which we don’t make progress Continue paying interest if it is low enough – e.g. if dirty code is peripheral

Refactoring High level – Create new abstractions (+ information hiding) – Move methods from/to super/sub class Low level – Changing names – Extracting methods – Supported by tools Need to include in schedule