610 likes | 856 Views
Successful IT Projects By Darren Dalcher & Lindsey Brodie. Chapter 6. www.thomsonlearning.co.uk/fasttrack. Lecture 6:. Cost Management. Learning outcomes. Understand the place of cost management within project management Outline a process for cost estimation
E N D
Successful IT ProjectsByDarren Dalcher & Lindsey Brodie Chapter 6 www.thomsonlearning.co.uk/fasttrack
Lecture 6: Cost Management
Learning outcomes • Understand the place of cost management within project management • Outline a process for cost estimation • Describe COCOMO II and other methods used for cost estimation • Explain the use of earned value management (EVM) for cost control
Software costs • Direct costs for developing and maintaining software • Indirect costs • Operating costs
Direct costs • Creating and updating the software requirements specification and design specification • Carrying out the coding and testing • Ensuring software quality (for example reviews and inspections) • Software maintenance • Purchasing bought-in software artefacts • Project management
Indirect costs • Development and test platforms (hardware, system software and software tooling) • Communications and collaboration platforms (e-mail and intranets) • Office space and administrative facilities
Operating costs • The operating platform (hardware and system software) • Software costs (for the developed software) • Installation and upgrade costs • Training costs • User costs (for example data entry) • Quality costs (for example business costs due to software errors)
Software users Project Development funding Development & maintenance costs - direct costs - indirect costs Operating costs • Transfer cost • software • training • installation On-going costs for using software & maintenance Relationship regarding costs between project and users
Managing project funding The project manager must: • Produce credible plans showing funding requirements • Ensure stakeholders are not surprised with major changes to plans or costs • Keep stakeholders informed of progress at regular intervals • Alert stakeholders to any difficulties as early as possible
Contracts The project manager must ensure: • Financial commitments by various stakeholders are clearly stated • Appropriate measures for dealing with non-payment are present • Where payments depend on deliveries, the deliverables are well-defined with responsibility and procedure for approving them clearly stated
Cost management processes Cost management Cost estimation Cost budgeting Cost control
Overview of how cost management fits into the project processes Feasibility study Business case Software process monitoring Requirements & scope Benchmarking Technology considerations Planning funding & budget Contract/ Service negotiation Cost estimation Cost budgeting Project execution Work monitoring Cost control Contract/ Service monitoring
The cost estimation steps Work breakdown structure (WBS) Cost breakdown structure Software design Software task Software cost Software size Software effort Software cost Step 1 Step 2 Step 3
Step 1: Software size Software size measured by: • Code size • Some aspect related to required functionality
Software size using code size • Count the lines of code (LOC) • There are different ways of counting lines. For example: • Source lines of code (SLOC) counts only the source lines that are delivered (not test drivers, etc.) • Delivered source instructions (DSI). An if-then-else statement would be one SLOC but several DSI
Software size using code size Problems: • Comparing or aggregating different programming languages • New software development methods For example: • Use of models • Automatic code generation • Reuse
Software size based on functionality Types of functionality-based metric What gets counted? Function points Inputs, outputs, files and inquiries Object points/Application points Screens, reports and modules Use case points Use cases
Function point analysis (1) First identify instances of the following function types: • Internal logical files: any file created or updated by the software • External interface files: any file only read by the software • External inputs: a process allowing data to enter the software, for example an input screen • External outputs: a process allowing data to exit the software, for example a report or display screen • External inquiries: reads data from internal and external files with no updating
Function point analysis (2) Then decide the complexity of each instance From Boehm et al (2000c)
Function point analysis (3) Add the number of instances in each category and then multiply by the relevant complexity weight So if for the function type of ‘external inputs’ there are 3 instances of low, 4 of average and 6 of high complexity, then (5 x 3) + (7 x 4) + (10 x 6) = 15 + 28 + 60 = 103 Add together with all the values for the other function types to get the unadjusted function point (UFP) value
Function point analysis (4) Adjust the UFP with a value adjustment factor (VAF). A VAF reflects the overall complexity of the project and is calculated from 14 system characteristics (such as multiple sites and reusability). Each system characteristic is given a score from 0 to 5. These are added together to give a total degrees of influence (TDI) value. VAF = (TDI x 0.01) + 0.65
Function point analysis (5) Total function points (FP) = VAF x UFP Function points can be converted into development effort in two ways: • Directly using productivity rates • Via conversion rates to lines of code
Productivity rates You determine the productivity rates by experience. You need to know the rate at which your organisation can code function points. Then you can calculate software effort* Software Effort = FP / Productivity Rate For example:FP = 300 Rate = 6 FP/person-month Then Effort = FP / Rate = 300/6 = 50 person-months Multiply by the cost of a person-month to determine the financial cost* *Note software effort and software cost are Steps 2 and 3, so this slide is leaping ahead somewhat, but it’s important to understand the two ways in which FP is used! (See previous slide)
Conversion rates for FP to SLOC (SLOC being a measure of software size) (Boehm et al 2000c quoting figures from Jones 1996)
Application points and use case points • Application points (formerly known as object points) count higher level software items such as screens, reports and modules. Otherwise similar to function points • Use case points are relatively new and due to their wide range of interpretation there are difficulties extending beyond “a relatively uniform group of applications and practitioners” (Boehm et al 2000c)
Step 2: Software Effort “If 2 pretzel makers can make 444 pretzels in 6 hours, how long does it take 5 pretzel makers to make 88 pretzels?” (Enzensberger 2006)
Software effort calculation As we have just seen using productivity rates with function points: Software Effort = FP / Productivity Rate Or to express this more generally: Software Effort = Software Size / Productivity Rate
Effort and Productivity • Units for effort can be person-hours, person-weeks, person-months or person-years • Productive time. Have to allow for other things (for example holidays, weekends, lunch, sick days, training and travelling time) • Overheads: How are management and administrative tasks accounted for? • People productivity varies: • Some people more productive • Experts in a task tend to be more productive than novices • People have different levels of sickness and absenteeism • Some tasks more difficult than others
Complexity • Try using multiple categories to cater for the different skill levels and different tasks • Even further complexity due to ‘diseconomy of scale’. Large projects will require more communication and organisation. However component-based development could require less… • Solutions to these problems have been to use: • Expert opinion • WBS-based costing (or activity-based costing) • Algorithmic approaches
Step 3: Software cost • Once you have effort, then converting into cost is a matter of knowing the standard cost • However: • People are on different pay scales (for example, project manager, programmer and systems architect) • Rates for the same job can vary due to industry and/or location • New recruits will require money to be spent on support and training • If we assume the more expensive workers are the more productive, then there is some offset
Software estimation techniques Software estimation techniques Composite-Bayesian COCOMO II Parametric model -based COCOMO 81 SLIM Checkpoint SEER Expertise -based Wideband Delphi Rule-based WBS-based Learning -orientated Neural Case-based (Analogy) Dynamics -based Abel- Hamid- Madnick Regression -based OLS Robust
Wideband Delphi • Expertise-based cost estimation • Introduced by Barry Boehm in 1970s • Iterative • Gather a group of experts • The experts each give their estimate • The results are tabulated. • The experts discuss the tabulated results (Such discussion only occurs with Wideband Delphi variant) • The experts again each give their estimate • And so on, iterating until there is a convergence of views on an estimated value
WBS-based costing • Sometimes known as activity-based costing • Each task/activity in a WBS is individually costed • Bottom-up technique starting from the lowest levels of the WBS and aggregating upwards • Can aggregate by using two types of WBS: • Product WBS: aggregating according to the different product modules • Process WBS: aggregating according to the type of process. For example aggregating by processes such as testing and coding
COCOMO II • Constructive Cost Model • A parametric or algorithmic model • Developed by Barry Boehm • COCOMO 81 (COCOMO I) in 1981 for Waterfall model • COCOMO II in 2000 for “evolutionary, incremental and spiral models” (Boehm et al 2000c) • COCOMO II also caters for very high level languages (VHLLs), commercial off-the-self (COTS) software and reuse through various extension models
COCOMO II extension models • (Boehm et al 2000c) • COPSEMO: phase schedule and effort estimation • CORADMO: rapid application development estimation • COCOTS: COTS integration estimation • COQUALMO: quality estimation (concerned with defect introduction and defect removal) • COPROMO: productivity estimation • Expert COCOMO: risk assessment
COCOMO II’s three basic models • Choice of model depends on the development stage: • Application composition: for software developed using prototyping usually in early stages of development. Uses application points • Early design: used during early stages when little is known about the system design. It uses KSLOC or UFPs • Post architecture: used during actual development and maintenance of software. Uses SLOC or FP
Cost drivers and scale factors • COCOMO II sets out a series of cost drivers and scale factors impacting cost • Values (known as effort multipliers (EM)) for the various cost drivers and scale factors differ for the different models. Default EM values are given by COCOMO II, but should be calibrated by an organisation using feedback obtained from their own project experience • Cost driver and scale factor EM values are inserted into the COCOMO II equations
EM values for cost drivers for ‘early design’ model (Boehm et al 2000c)
EM values for scale factors for ‘early design’ and ‘post-architecture’ models (Boehm et al 2000c)
COCOMO II effort equation for ‘early design’ and ‘post architecture’ models Effort = A x EAF x (KSLOC)E where • Effort is measured in person-months (PM) • A is a productivity constant and is calibrated to 2.94 for COCOMO II.2000 • KSLOC is an estimate of software project size, measured in thousands of SLOC • EAF is the effort adjustment factor derived from the EM values of the cost drivers. How many EMs there are depends on which model is being used. EAF is calculated by multiplying the EMs together • E is an exponent derived from the five scale factors. E = B + (0.01 x sum of the scale factors) where B is calibrated to 0.91 for COCOMO II.2000 (Boehm et al 2000c)
COCOMO II duration equationfor ‘early design’ and ‘post architecture’ models Duration = C x (Effort)SE where • Effort is the effort from the COCOMO II.2000 effort equation • C is a constant and is calibrated to 3.67 for COCOMO II.2000 • SE is the schedule equation exponent derived from the five scale factors (Boehm et al 2000c)
Cost estimation tools • Many cost estimation tools exist: • COCOMO II • CoStar • CostModeler • CostXpert • KnowledgePlan • PRICE S • SEER • SLIM • SoftCost Caper Jones (2005)
Cost estimation tools “The commercial software estimating tools are far from perfect and they can be wrong, too. But automated estimates often outperform human estimates in terms of accuracy, and always in terms of speed and cost effectiveness. However, no method of estimation is totally error-free. The current best practice for software cost estimation is to use a combination of software cost estimating tools coupled with software project management tools, under the careful guidance of experienced software project managers and estimating specialists.” Capers Jones (2005)
Software costs - accuracy of estimates (Boehm et al 2000c) 4X 2X 1.5X 1.25X Relative Size Range X 0.5X 0.25X Requirements Specification Detailed Design Specification Feasibility Study Design Specification Accepted Software Milestones
Cost measurement • Metrication within organisations • Historical data • Calibration • Use of feedback
Cost Control:Earned value management (EVM) In EVN, ‘value’ is linked to achievement of planned, scheduled work defined in terms of cost • How much work has been accomplished? • How does it compare to the plan? Typically need an underlying WBS defining the project work - allows budget to be allocated against work
EVM Planned value (PV) Earned value (EV) Plot against Time Actual costs (AC) Scheduled variance (SV) SV = EV - PV Cost variance (CV) CV = EV - AC
EVM performance reporting See http://evm.nasa.gov/overview.html/ (NASA EVM 2006) Reporting to date Projected slippage Estimated cost at completion Money Estimated budget overrun Total budget Contingency budget AC PV CV EV SV Time
Summary Cost management • Cost estimation • Establish software size (SLOC and FP) • Establish effort (productivity rates) • Calculate software costs • Cost budgeting (PV) • Cost control (EV and AC against PV)
Needs, Opportunities & Requested Changes Overview of the cost management process and related processes Requirements Specification Functional Specification Requirements Specification Create/Modify WBS Stakeholder Value/ Potential Benefits Functional Specification Step 1 Step 2 Software Tasks Software Process information Establish Software Size Establish Effort Cost Estimation Step 3 All Tasks Effort Quantity/ Software Size Calculate Software Costs Resource Availability Software Cost Estimates Actual Costs (AC) Report Create/Modify Schedule Other Costs Cost Control Cost Budgeting Add Cost Estimates into Schedule Planned Schedule Revised Cost Estimates, Earned Value (EV) information, Corrective Actions, & Updates to Software Process information Monitor & Control Costs / Review Costs Planned Total Budget & Cost Baseline with Planned Value (PV) information