Software Project Management 4th Edition - Chapter 5 PDF

Software Project Management 4th Edition Chapter 5 Software effort estimation 1 What makes a successful project? Delivering: Stages: agreed 1. set targets functionality 2....

Software Project Management 4th Edition Chapter 5 Software effort estimation 1 What makes a successful project? Delivering: Stages: agreed 1. set targets functionality 2. Attempt to on time achieve targets at the agreed cost with the required quality BUT what if the targets are not achievable? 2 Over and under- estimating Parkinson’s Law: Weinberg’s ‘Work expands to fill Zeroth Law of the time available’ reliability: ‘a software project that does not An over-estimate is have to meet a likely to cause reliability project to take requirement can longer than it would meet any other otherwise requirement’ 3 A taxonomy of estimating methods Bottom-up - activity based, analytical Parametric or algorithmic models e.g. function points Expert opinion - just guessing? Analogy - case-based, comparative Parkinson and ‘price to win’ 4 Bottom-up versus top- down Bottom-up use when no past project data identify all tasks that have to be done – so quite time-consuming use when you have no data about similar past projects Top-down produce overall estimate based on project cost drivers based on past project data divide overall estimate between jobs to be done 5 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 6 Top-down estimates Estimate Produce overall 100 days overall estimate using project effort driver (s) distribute design code test proportions of 30% 30% 40% overall estimate to i.e. i.e. i.e. 40 days 30 days 30 days components 7 Algorithmic/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 algorithm estimate characteristic 8 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 9 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 10  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 11  Parametric models Other models focus on productivity: e.g. COCOMO Lines of code (or FPs etc) an input Estimated effort System size Productivity factors 12 Function points Mark II Developed by Charles R. Symons ‘Software sizing and estimating - Mk II FPA’, Wiley & Sons, 1991. Builds on work by Albrecht Work originally for CCTA: should be compatible with SSADM; mainly used in UK has developed in parallel to IFPUG FPs 13  Function points Mk II continued For each transaction, #entities count data items input accessed (Ni) data items output (No) entity types #output accessed (Ne) #input items items FP count = Ni * 0.58 + Ne * 1.66 + No * 0.26 14 Function points for embedded systems Mark II function points, IFPUG function points were designed for information systems environments COSMIC FPs attempt to extend concept to embedded systems Embedded software seen as being in a particular ‘layer’ in the system Communicates with other layers and also other components at same level 15 Layered software Higher layers Receives request Supplies service Data reads/ Peer to peer writes communication Persistent peer storage Software component component Makes a request Receives service for a service Lower layers 16  COSMIC FPs The following are counted: Entries: movement of data into software component from a higher layer or a peer component Exits: movements of data out Reads: data movement from persistent storage Writes: data movement to persistent storage Each counts as 1 ‘COSMIC functional size 17  COCOMO81 Based on industry productivity standards - database is constantly updated Allows an organization to benchmark its software development productivity Basic model effort = c x sizek C and k depend on the type of system: organic, semi-detached, embedded Size is measured in ‘kloc’ ie. Thousands of lines of code 18  The COCOMO constants System type c k Organic (broadly, 2.4 1.05 information systems) Semi-detached 3.0 1.12 Embedded 3.6 1.20 (broadly, real- time) k exponentiation – ‘to the power of…’ adds disproportionately more effort to the larger projects takes account of bigger management overheads 19 Development effort multipliers (dem) According to COCOMO, the major productivity drivers include: Product attributes: required reliability, database size, product complexity Computer attributes: execution time constraints, storage constraints, virtual machine (VM) volatility Personnel attributes: analyst capability, application experience, VM experience, programming language experience Project attributes: modern programming 20 practices, software tools, schedule Using COCOMO development effort multipliers (dem) An example: for analyst capability: Assess capability as very low, low, nominal, high or very high Extract multiplier: very low 1.46 low 1.19 nominal 1.00 high 0.80 very high 0.71 Adjust nominal estimate e.g. 32.6 x 0.80 = 26.8 staff months 21 Estimating by analogy Use effort source cases from source as attribute values effort estimate attribute values effort target case attribute values effort attribute values ????? attribute values effort attribute values effort attribute values effort Select case with closet attribute values 22 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 23 Machine assistance for source selection (ANGEL) Source A Source B It-Is Number of Ot-Os inputs target Number of outputs Euclidean distance = sq root ((It - Is)2 + (Ot - Os)2 ) 24 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? 25