Software Project Management
190 likes | 326 Vues
This document explores various methods of estimating development effort in software projects. It categorizes approaches such as expert opinion, bottom-up, parametric, and analogy-based estimation. Key techniques like COCOMO and function points are discussed alongside top-down versus bottom-up strategies. The text highlights the importance of historical data, project types, and the influence of personnel attributes on effort estimates. The evolving nature of estimation practices is considered, emphasizing advancements that improve accuracy in software development effort prediction.
Software Project Management
E N D
Presentation Transcript
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?
