1University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 9:Estimation and Prioritization Project planning Estimating Effort Prioritizing Stakeholder’s needs Trade-offs between stakeholder goalsUniversity of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2Project PlanningGiven:A list of customer requirementsE.g. a set of use cases, a set of change requests, etc.Estimate:How long each one will take to implement (cost)How important each one is (value)Plan:Which requests should be included in the next releaseComplication:Customers care about other stuff to: quality, performance, security, usability,…2University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3Principles of ManagementA manager can control 4 things:Resources (can get more dollars, facilities, personnel)Time (can vary the schedule, delay milestones, etc.)Product (can vary the amount of functionality - e.g. scrub requirements)Risk (can decide which risks are acceptable)Approach (applies to any management)Understand the goals and objectivesquantify them where possibleUnderstand the constraintsif there is uncertainty, use probability estimatesPlan to meet the objectives within the constraintsMonitor and adjust the planPreserve a calm, productive, positive work environmentNote:You cannot control what you cannot measure!University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4StrategiesFixed Product1. Identify customer requirements2. Estimate size of software needed to meet them3. Calculate time required to build this much software4. Get customer to agree to the cost & scheduleFixed schedule (a.k.a. Timeboxing)1. Fix a date for next release2. Obtain prioritized list of requirements3. Estimate effort for each requirements4. Select requirements off the list until the “box” is fullFixed Cost1. Agree with customer how much they wish to spend2. Obtain prioritized list of requirements3. Estimate cost of each requirement4. Select requirements off the list until the “cost” is used up3University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5Estimating Effort: COCOMOCOnstructive COst Model (COCOMO)Used to predict cost of a project from a measure of size (lines of code)Basic model is:E = aLbModeling processEstablish type of project (organic, semidetached, embedded)this gives sets of values for a and bIdentify the component modules, and estimate L for each moduleAdjust L according to how much is reusedCOCOMO has a model for adjusting according to how much design, code andintegration data is reusedCompute effort for each module using E = aLbAdjust E according to difficulty of the projectCOCOMO identifies 15 effort multipliers to take into accountProduct attributes: eg required reliability, complexity, database sizeComputer attributes: eg execution time constraints, storage constraints, etc.Personnel attributes: eg capability & experience of analysts and programmers,Project attributes: eg use of CASE tools, programming language, scheduleCompute time using T = cEdc and d provided for different project types like a and b wereeffortlines of codeproject specific factorsSource: Adapted from van Vliet, 1999, section 7.3.2University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6Estimating Size: Function PointsFunction Pointsused to calculate size of software from a statement of the problemtries to address variability in lines of code estimates used in models such asCOCOMOe.g. because SLOC varies with different languagesOriginally for information systems, although other variants existBasic model is:FP = a1I + a2O + a3E + a4L + a5FExampleSets of weightings (ai) provided for different types of projectMeasure properties of the problem statement:I = number of user inputs (data entry)O = number of user outputs (reports, screens, error messages)E = number of user queriesL = number of filesF = number of external interfaces (to other devices, systems)Example calculation:FP = 4I + 5O + 4E + 10L + 7Fweighting factor for this metricmetric from problem statementSource: Adapted from van Vliet, 1999, section 7.3.54University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Agile EstimatingEstimation in Practice:People tend to underestimate effort neededMost estimates are made to please the {boss, customer, …}Easier to estimate small chunks of work than large onesThree-point estimatingGets much better estimates than just asking for a rangew = worst possible casem = most likely caseb = best possible case…and don’t forget: effort < duration !!! E =wi+ 4mi+ bi6i"University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8A Cost-Value ApproachPerform Triage:Some requirements *must* be includedSome requirements should definitely be excludedThat leaves a pool of “nice-to-haves”, which we must select from.Cost (percent)Value (percent)Low priorityMediumpriorityHighpriority5 10 15 20 25 3051015202530Source: Adapted from Karlsson & Ryan 19975University of TorontoDepartment of Computer Science© 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9Some complicationsHard to quantify differenceseasier to say “x is more important than y”……than to estimate by how much.Not all requirements comparableE.g. different level of abstractionE.g. core functionality vs. customer enhancementsRequirements may not be independentNo point selecting between X and Y if they are mutually dependentStakeholders may not be consistentE.g. If
View Full Document
Unlocking...