Transcription
Lecture 17: Chapter 26!n Estimation for Software Projects!Slide Set to accompanySoftware Engineering: A Practitioner’s Approach, 7/e"by Roger S. PressmanSlides copyright 1996, 2001, 2005, 2009 by Roger S. PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunctionwith Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use isprohibited without the express written permission of the author.All copyright information MUST appear if these slides are posted on a website for studentuse.1!
Software Project Planning!The overall goal of project planning is toestablish a pragmatic strategy for controlling,tracking, and monitoring a complex technicalproject.!!Why?!So the end result gets done on time, with quality!!2!
Project Planning Task Set-I!n n n Establish project scope!Determine feasibility!Analyze risks!n n Risk analysis is considered in detail in Chapter 25.!Define required resources!n n n Determine require human resources!Define reusable software resources!Identify environmental resources!3!
Project Planning Task Set-II!n Estimate cost and effort!n n n n Decompose the problem!Develop two or more estimates using size, functionpoints, process tasks or use-cases!Reconcile the estimates!Develop a project schedule!n Scheduling is considered in detail in Chapter 27.! Establish a meaningful task set!Define a task network!Use scheduling tools to develop a timeline chart!Define schedule tracking mechanisms!4!
Estimation!n Estimation of resources, cost, and schedule fora software engineering effort requires !n n n n experience!access to good historical information (metrics)!the courage to commit to quantitative predictionswhen qualitative information is all that exists!Estimation carries inherent risk and this riskleads to uncertainty!5!
Write it Down!!Project Scope!Estimates!Risks!Schedule!Control strategy!Software!Project!Plan!6!
To Understand Scope .!n n n n n n Understand the customers needs!understand the business context!understand the project boundaries!understand the customer’s motivation!understand the likely paths for change!understand that .!Even when you understand,!nothing is guaranteed!!7!
What is Scope?!n Software scope describes !n n n n n the functions and features that are to be delivered toend-users!the data that are input and output!the “content” that is presented to users as aconsequence of using the software!the performance, constraints, interfaces, andreliability that bound the system. !Scope is defined using one of two techniques:!n n A narrative description of software scope isdeveloped after communication with all stakeholders.!A set of use-cases is developed by end-users.!8!
mponentspart.-experiencecomponents9!
Project Estimation!n n n n n Project scope must beunderstood!Elaboration (decomposition) isnecessary!Historical metrics are very helpful!At least two different techniquesshould be used!Uncertainty is inherent in theprocess!10!
Estimation Techniques!n n n Wait till the end!!!Past (similar) project experience!Conventional estimation techniques!n n n n task breakdown and effort estimates!size (e.g., Function Points) estimates!Empirical models!Automated tools!11!
Estimation Accuracy!n Predicated on !n n n n the degree to which the planner has properlyestimated the size of the product to be built!the ability to translate the size estimate into humaneffort, calendar time, and dollars (a function of theavailability of reliable software metrics from pastprojects)!the degree to which the project plan reflects theabilities of the software team!the stability of product requirements and theenvironment that supports the software engineeringeffort.!12!
Conventional Methods:LOC/FP Approach!n n n n compute lines of code (LOC) usingestimates of information domain values!Computes function points (FP),information domain values!use historical data to build estimates forthe project!Example: Computer-Aided Designapplication for mechanical components!n Apply LOC and FP to this software!13!
Example: LOC Approach!Average productivity for systems of this type 620 LOC/pm. !Burdened labor rate 8000 per month, the cost per line ofcode is approximately 13. !Based on the LOC estimate and the historical productivitydata, the total estimated project cost is 33,200*620 431,000and the estimated effort is 54 person-months.!14!
Example: FP Approach!The estimated number of FP is derived:!!!FPestimated count-total * [0.65 0.01 * S (Fi)]!!!FPestimated 375!organizational average productivity 6.5 FP/pm. !burdened labor rate 8000 per month, approximately 1230/FP. !Based on the FP estimate and the historical productivity data, total estimatedproject cost is 461,000 and estimated effort is 58 person-months.!!15!
Process-Based Estimation!Obtained from “process framework”framework activities!applicationfunctionsEffort required toaccomplish!each frameworkactivity for eachapplication function!16!
Process-Based Estimation CFDAMTotals0.250.250.253.5020.50% effort1%1%1%8%45%10%46.0036%CC customer communication CE customer evaluationBased on an average burdened labor rate of 8,000 permonth, the total estimated project cost is 368,000 and theestimated effort is 46 person-months.!17!
Estimation with Use-Cases!use cases scenarios pagese subsystem6106User upgroup10208Infrastructuresubsystemgroupe subsystem group565Total LOC estimatestimatescenarios pages LOC LOC Using 620 LOC/pm as the average productivity for systemsof this type and a burdened labor rate of 8000 per month, thecost per line of code is approximately 13. Based on the usecase estimate and the historical productivity data, the totalestimated project cost is 42,568*13 552,000 and theestimated effort is 68 person-months.!18!
Empirical Estimation Models!General form:!exponent!effort tuning coefficient * size!usually derived!as person-months!of effort required!either a constant or!a number derived based !on complexity of project!empirically!derived!usually LOC but!may also be!function point!19!
COCOMO-II!n COCOMO II is actually a hierarchy ofestimation models that address the followingareas:! Application composition model. Used during the earlystages of software engineering, when prototyping ofuser interfaces, consideration of software and systeminteraction, assessment of performance, andevaluation of technology maturity are paramount.! Early design stage model. Used once requirementshave been stabilized and basic software architecturehas been established.! Post-architecture-stage model. Used during theconstruction of the software.!n Empirical model that relies on size information!20!
The Software Equation!A dynamic multivariable model"!!!E [LOC x B0.333/P]3 x (1/t4)!!!where !!E effort in person-months or person-years!!t project duration in months or years!!B “special skills factor”!!P “productivity parameter”!!!21!
Estimation for OO Projects-I!n n n n Develop estimates using effort decomposition, FP analysis,and any other method that is applicable for conventionalapplications.!Using object-oriented requirements modeling (Chapter 6),develop use-cases and determine a count. !From the analysis model, determine the number of key classes(called analysis classes in Chapter 6).!Categorize the type of interface for the application and developa multiplier for support classes:!n n n n n Interface type!No GUI!!Text-based user interfaceGUI!!Complex GUI!!!!!!!Multiplier!! 2.0!! 2.25!2.5!! 3.0!22!
Estimation for OO Projects-II!n n n Multiply the number of key classes (step 3) by themultiplier to obtain an estimate for the number of supportclasses.!Multiply the total number of classes (key support) bythe average number of work-units per class. Lorenz andKidd suggest 15 to 20 person-days per class.!Cross check the class-based estimate by multiplying theaverage number of work-units per use-case!23!
Estimation for Agile Projects!n n n Each user scenario (a mini-use-case) is considered separatelyfor estimation purposes.!The scenario is decomposed into the set of softwareengineering tasks that will be required to develop it.!Each task is estimated separately. Note: estimation can bebased on historical data, an empirical model, or “experience.”!n n Estimates for each task are summed to create an estimate forthe scenario.!n n Alternatively, the ‘volume’ of the scenario can be estimated inLOC, FP or some other volume-oriented measure (e.g., use-casecount).!Alternatively, the volume estimate for the scenario is translated intoeffort using historical data.!The effort estimates for all scenarios that are to be implementedfor a given software increment are summed to develop the effortestimate for the increment.!24!
The Make-Buy Decision!simple (0.30)builddifficult (0.70)minor changes(0.40)system Xreuse 380,000 450,000 275,000 310,000simple (0.20)buycontractmajorchanges(0.60)complex (0.80)minor changes(0.70)major changes (0.30)without changes (0.60) 490,000 210,000 400,000 350,000 500,000with changes (0.40)25!
Computing Expected Cost!expected cost !(path probability) x (estimated path cost) !i!i!For example, the expected cost to build is:!!! 0.30 ( 380K) 0.70 ( 450K) !! expected costbuild!! ! 429 K!!!similarly,!!!!!!expected cost 382K!reuse!!!expected cost 267K!buy!!expected cost 410K!contr!26!
information domain values!! use historical data to build estimates for the project!! Example: Computer-Aided Design application for mechanical components!! Apply LOC and FP to this software! 14! Example: LOC Approach! Average productivity for systems of this type 620 LOC/pm. ! Burdened labor rate 8000 per month, the cost per line of code is approximately 13. ! Based on the LOC estimate .
