190 likes | 313 Views
Software Project Management. Estimating development effort (ii). A taxonomy of estimating methods. Expert opinion Bottom-up - activity based Parametric e.g. function points Analogy artificial neural networks - a view of the future? Parkinson – based on available staff ‘price to win’.
E N D
Software Project Management Estimating development effort (ii)
A taxonomy of estimating methods • Expert opinion • Bottom-up - activity based • Parametric e.g. function points • Analogy • artificial neural networks - a view of the future? • Parkinson – based on available staff • ‘price to win’
Top-down versus Bottom-up • Top-down • 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 40% i.e. 40 days 30% i.e. 30 days
Parametric models - the need for historical data • simplistic model for an estimate estimated effort = (system size) / productivity rate • e.g. system size = lines of code productivity = lines of code per day
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), e.g. printer • external inquiries (EQ), e.g. screen display • Each occurrence is judged simple,averageor complex
Albrecht FP weightings type simple average complex ILF 7 10 15 EIF 5 7 10 EI 3 4 6 EO 4 5 7 EQ 3 4 6 Disadvantage: The weights are assigned subjectively.
Parametric (or algorithmic) models • COCOMO (lines of code) and function points are examples of these • Problem with COCOMO etc: guess algorithm estimate but what is desired is system characteristic algorithm estimate
COCOMO models • Developed by Barry Boehm. • Stands for COstructiveCostModel • Can be used in other area than IS • The model was built around the equation effort = c x sizek In kdsi (thousands of delivered source code instruction) in person-months = 152 working hrs
Up to the technical nature Organic mode: relatively small team in a highly familiar in-house envi Or when the system is small and i/f requirements are flexible Embedded mode: The product has to operate in very tight constraints Changes to the system were very costly. Semi-detached mode: Combined elements of the formers Or had characteristics that came b/w the two. COCOMO constants System type c k Organic 2.4 1.05 Embedded 3.6 1.20 Semi-detached 3.0 1.12
COCOMO • See example in Excel sheet • Since the poor performance of prediction, the intermediate version of COCOMO introduced: • Account for 15 cost drivers. • A nominal effort estimate (pmnom) is derived as: pmest = pmnom x dem Development effort Multiplier, based on the 15 drivers
Intermediate cost drivers(p.98) • 3 Product attributes: • Required SW quality, etc. • 4 Computer attributes: • Execution time constraints, etc. • 5 Personnel attributes: • Analyst capability, etc. • 3 Project attributes: • Use of SW tools, etc.
Example • Assuming the product, computer and project attributes do not change from one project to another and are given a multiplier of 1.0. • Only personnel attributes differ as follows: • The analyst is regarded as of exceptionally high quality. • The programmers are of high quality but have little experience of the particular application area and are going to use a programming language that is new to them. • They are familiar with the OS environment • Find the dem for this project • If nominal estimate was 4 person-months, what would be the final estimate?
COCOMO II (2002) • Introduce a database containing the performance details from actual projects that is updated periodically • Include a wider range of process models • Separate the estimation for different stages in the system life cycle. • Application composition • Design of external feature to users (prototype) • Early design • Design of fundamental SW structures/architecture • Post architecture • The design SW structures undergo final construction, modification and tuning.
Calculating effort using COCOMO II • For application composition • Counting of the object points • For early design stage • FPs are recommended • Convert FPs into SLOC • The model to estimate person-months: pm = A x sizesf x em1 x em2 x … x emn • A is constant = 2.45 (in 1998) • Size is in SLOC • sf = 0.91 + 0.01 x ∑(exponent driver ratings)
Exponent drivers • Precedentedness • Novelty ↑, uncertainty ↑, value ↑ • Development flexibility • The way to meet requirement ↑, vaule ↓ • Architecture/risk resolution • The certainty of requirement ↑, value ↓ • Team cohesion • The degree of dispersion ↑, value ↑ • Process maturity • The structure and well-organized ↑, the value ↓
Example • A new project has ‘average’ novelty for the SW house that is going to execute it and is thus given a 3 rating on this account for precedentedness. Development flexibility is high to the extent that this generates a zero rating, but requirements might change radically and so the risk resolution exponent is rated at 4. The team is very cohesive and this generates a rateing of 1, but the SW house as a whole tends to be very informal in its standards and procedures and the process maturity driver has therefore been given a value of 4. • What would be the scale factor, sf, that would be applicable in this case?