Software project management (intro) Introduction to estimating development effort

What makes a successful project? Delivering: agreed functionality on time at the agreed cost with the required quality Stages: 1. set targets 2. Attempt to achieve targets BUT what if the targets are not achievable?

Over and under-estimating Parkinson’s Law: ‘Work expands to fill the time available’ An over-estimate is likely to cause project to take longer than it would otherwise Weinberg’s Zeroth Law of reliability: ‘a software project that does not have to meet a reliability requirement can meet any other requirement’

A taxonomy of estimating methods Expert opinion - just guessing? Bottom-up - activity based Parametric e.g. function points Analogy artificial neural networks - a view of the future? Parkinson and ‘price to win’

Heemstra and Kusters survey Expert judgement 25.5% Analogy 60.8% ‘Capacity problem’ 20.8% Price-to-win 8.9% Parametric models 13.7%

Heemstra and Kusters contd. Only 50% kept project data on past projects - but 60.8% used analogy! 35% did not produce estimates 62% used methods based on intuition - only 16% used formalized methods Function point users produced worse estimates!

Top-down versus Bottom-up produce overall estimate based on project cost drivers based on past project data Bottom-up use when no past project data

Top-down estimates Produce overall estimate using effort driver(s) distribute proportions of overall estimate to components Estimate 100 days overall project design code test 30% i.e. 30 days 30% i.e. 30 days 40% i.e. 40 days

Bottom-up estimating 1. Break project into smaller and smaller components [2. Stop when you get to what one person can do in one/two weeks] 3. Estimate costs for the lowest level activities 4. At each higher level calculate estimate by adding estimates for lower levels

Parametric models COCOMO (lines of code) and function points examples of these Problem with COCOMO etc: guess algorithm estimate but what is desired is system characteristic algorithm estimate

Parametric models - continued Examples of system characteristics no of screens x 4 hours no of reports x 2 days no of entity types x 2 days the quantitative relationship between the input and output products of a process can be used as the basis of a parametric model

Parametric models - the need for historical data simplistic model for an estimate estimated effort = (system size) / productivity e.g. system size = lines of code productivity = lines of code per day productivity = (system size) / effort based on past projects

and output transaction types Parametric models Some models focus on task or system size e.g. Function Points FPs originally used to estimate Lines of Code, rather than effort Number of file types model ‘system size’ Numbers of input and output transaction types

Parametric models Other models focus on productivity: e.g. COCOMO Lines of code (or FPs etc) an input System size Estimated effort Productivity factors

COCOMO Based on industry productivity standards - database is constantly updated Allows an organization to benchmark its software development productivity

COCOMO – Examples Boehm simple model E = a * (KLOC)b D = 2.5 (E)d Coefficient table S/W Project ab bb db Organic 2.4 1.05 0.38 Semi detached 3.0 1.12 0.35 Embedded 3.6 1.20 0.32

Estimating by analogy Use effort from source as estimate ????? source cases attribute values effort attribute values effort target case attribute values attribute values ????? effort attribute values effort effort attribute values attribute values effort Select case with closet attribute values

Anchor + adjustment pace distance on a bearing go to tall building FOREST go to tall building by line of sight FOREST You are here: how do you get to red cross?

Estimating by analogy Identify significant attributes (‘drivers’) locate closest match amongst source cases for target adjust for differences between source and target

Machine assistance for source selection (ANGEL) Source A Source B It-Is Number of inputs Ot-Os target Number of outputs Euclidean distance = sq root ((It - Is)2 + (Ot - Os)2 )

Stages: identify Significant features of the current project previous project(s) with similar features differences between the current and previous projects possible reasons for error (risk) measures to reduce uncertainty

System size: function points Based on work at IBM 1979 onwards Albrecht and Gaffney wanted to measure the productivity independently of lines of code has now been developed by the International FP User Group (which is US based) Mark II FPs developed by Simons mainly used in UK

Albrecht function points external interface files internal logical files external inputs external outputs external inquiries

Function points are based on 2 ‘data function’ types internal logical files (ILF) external interface files (EIF) 3 ‘transactional function’ types external inputs (EI) external outputs (EO) external inquiries (EQ) Each occurrence is judged simple, average or complex

Albrecht FP weightings FP = count total * (0.65 + 0.01 *  (Fi)); i = 1 to 14

Taking Complexity into Account 0 (not important) to 5 (very important) Factors are rated on a scale Questions for Complexity Adjustment Values Data communications Backup and recovery Distributed functions Heavily used configurations Transaction rate On-line data entry On-line update End user efficiency Complex processing Installation ease Operational ease Multiple sites Facilitate change Reusable

Example: FP Approach

Some conclusions: how to review estimates Ask the following questions about an estimate What are the task size drivers? What productivity rates have been used? Is there an example of a previous project of about the same size? Are there examples of where the productivity rates used have actually been found?