Software Project Estimation:

Software Project EstimationJerrid GimenezFeb. 7, 2013Software Estimation: WhatSoftware Estimation estimation of the software size, development effort, software development cost, and software development schedule for a specified project in a specified environment, using defined methods, tools, and techniques -Murali ChemuturiAuthor: Software Estimation Best Practices, Tools & TechniquesRead Quote

Many Variables

Intimidating2SE: What - Cont.What do we get out of the estimate?ComponentsSizeEffort neededCostTimeRiskData for future improvements

To better define Components-helps to learn what will be neededEffort-person hours/-how many peopleCost-For customer how much will it run?-Budget for supplierRisk-Is it worth taking the job?Data-Extremely beneficial-3Software Estimation: WhoRecommended: Project LeadPerson responsible for completion of estimated taskOften: You!

Software Estimation: WhyEstimation gives the Customer:BudgetQuote to compare withEstimation gives the Supplier:Budgetchance to evaluate the risks/rewards of a projectway to keep track of progressWhy is this Important to You?It will be a part of our job as Software Engineers!

Software Estimation: WhenBefore DevelopmentWhen project is acquired from customerFollowing project Approval for internal projects.During DevelopmentDecreases Uncertainty(See Uncertainty Later)Estimating After Development?Not as common - but very beneficialCompare actual cost size time to estimated valuesImproves knowledge for future estimations

The ChallengesMany variables SizingDevelopment EnvironmentSupport EnvironmentStaff (how much/how talented)

Challenges: Size EstimationNot done as often as Estimating Effort.Why do we do it?Drives Scheduling and Cost EstimationsSize -> Effort -> CostHow do we size Software?Sizing cont.Experiment: How many lines of code(LOC)?//Function Population(string town) returns count of //people in personList who live in the input townPublic int Population(string town){ int count = 0;for(int i = 0; i < personList.length(); i++) if(personList[i].Town == town) count++; return count;}Size Estimation: Lines of CodeOrginal method of estimating sizeProgram Size = LOC needed for functionalityHow many LOC from the experiment?The world may never know

Calculating the LOC EstimateModule 1 Estimated LOCFunctionalityMin LOCMax. LOCLikely LOCEstimated LOCF1100150125140F295120105105TOTAL245LOC Pros / ConsProsBeneficial for Real Time/Embedded ApplicationsCan be used to create Historical data for future estimatesEasy to countConsNo defined LineDoesnt promote code optimizationsSize Estimation: Function PointsWhat are they?Points used to quantify functionality given to the userMost popular size measureDeveloped late 1970s Allan J. Albrecht of IBMInternational Function Point Users GroupMaintains FP standardsCertificationsTrainingFunction Points cont.Function Point Analysis Counts:External InputsExternal OutputsExternal InquiryInternal Logical FileExternal Interface FileEach has 3 complexity possibilities to come up with FP countFunction Points Pros / ConsPros:Very well definedBenchmarkingUsed to show ProductivityCons:Not IntuitiveMust train / find well trained countersNeed user perspective Estimating the EffortPerson Hours/Months/[Unit of time]Derives Schedule, Cost

Methods: AnalogyHow its done:Use knowledge of previous projects to come up with estimatesWhat is needed for success:Company must keep recordsSimilar Projects must have been made

Analogy cont.Parameters for AnalyzingProject TypeFull life cycleImplementationConversionPortMigrationClient InformationApplication DomainSize of clients organizationNumber of client locations Development PlatformAnalogy: Strengths / WeaknessesStrengths:ReliableInuitiveEstimation Data can be purchasedWeaknessesPoor Record Keeping = bad estimatesNot the best for new organizationsTime consumingMethods: Expert Judgment(Delphi) How its done:Work with Subject Matter Experts (SMEs) to formulate estimatesIf a small team of SMEs is used, a common estimate is derived.Works well because:No historical data neededIf proper SME is chosen - Extremely accurateQuickInaccurate because:SME can be biased / inconsistent / overconfident

Delphi: Converging EstimatesExpert Estimates must be ConvergedSimple averageSwap extremesMethods: Activity and Work Decomposition

Activity and Work Decomposition cont.How its done:Outline the needed tasks involved for the projectShould be done by person who ensures the tasks are accomplished.Use knowledge of needed work and skill set of the implementers to derive time estimates.Pros:Estimator is knowledgeable of the work at handNo explicit sizing such as Lines of Code count is neededLimitations:Subjective accuracy is up to the estimators opinionNo sizingMethods: Top-Down How its done:Decomposition of system into smaller componentsWorks well because:Estimates are linked to requirementsInaccurate when:Good requirements arent availableBias may lead to underestimation

Methods: Bottom-UpHow its done:Individuals evaluate each component of the entire system.Sum to formulate project estimateWorks well because:Can be very accurate detailedBuilds responsibilityIssues:Time consuming processDetails may not be availableBias can lead to underestimationCan miss integration costs

Methods: Design to CostHow its done:Work with SMEs to find out how much we can give the customer for given budgetWorks well because:The price is right!Issues:Need knowledge of functionality costMethods: Parametric ModelsHow its done:Estimate by use of design parameters and mathematic formulasWorks well because:FastEase of useCan be re-useable Issues:Models need to fit the billCan end up being very inaccurate through poor choice of parameters

Parametric Method: COCOMODeveloped by: Dr. Barry BoehmStudied historical data63 projects: 2,000 100,000 LOCLarge following3 Types:BasicIntermediateProduct AttributesHardware AttributesPersonnel AttributesProject AttributesAdvancedIntermediate + Phase approach

Basic COCOMO3 Classes of Projects Used for FormulaOrganicSmall teamMore experiencedLess rigid requirements / constraintsSemi-detachedMixed teams / experiencesMixed rigidity of requirements / constraintsEmbeddedTight constraints

Basic COCOMO CalculationsCOCOMO CoefficientsabcdOrganic2.41.052.50.38Semi-detached3.01.122.50.35Embedded3.61.202.50.32ExampleOrganic Mode - We have estimated:15 KLOC minumum17.5 KLOC likely22 KLOC maximum

Estimating Uncertainty?

32The Cone of Uncertainty400% to 25% !?Current studies show closer to +100% / -50% at feasibility stageStrong tendency to underestimate

33Acknowledging UncertaintyAlternatives to giving a single numberBetween X and Y person monthsX% chance it will be under Y person monthsUse the pX approachX = X% chance of NOT exceeding the estimateExample Youre on a project and your estimate is 8 person months. Youve researched that 10% of similar projects have been under budget.p10 estimate = 7 staff months 10% chance of being under, 90% being overDealing with UncertaintiesCommunicate in a way that makes them known, such as the pX method.Methodology > Gut FeelingsWork pressure drives over confidenceRe-EstimateFeasibility Stage - Ball ParkRequirements Stage More DetailedDesign Stage - RefinedAgile Environments:Expect higher uncertainty

Why Estimates Fail A recap.Little / Misused historical dataRecord estimates + actual dataMake sure data fits the billOver-Optimistic / Hopeful managementAvoid gut feelings use the methodsAvoid over-confidenceNot using the estimate!Dont Confuse targets with estimatesNot updating the estimateAcknowledge uncertainty in estimationEstimate often it will become more accurateQuestions?ReferencesChemuturi, M. (2009). Software estimation best practices, tools & techniques. Fort Lauderdale, FL: J. Ross Publishing, Inc..

FAQs. (n.d.). International function point users group. Retrieved February 4, 2013, from http://www.ifpug.org/?page_id=12

Galorath, D. D., & Evans, M. W. (2006). Software sizing, estimation, and risk management when performance is measured performance improves. Boca Raton, FL: Auerbach Publications.

Laird, L., & Brennan, M. (2006). Software measurement and estimation: a practical approach. Hoboken, NJ: John Wiley & Sons, Inc..

Pressman, R. (n.d.). A brief summary of the original cocomo model. McGraw hill higher education. Retrieved February 4, 2013,from www.mhhe.com/engcs/compsci/pressman/information/olc/COCOMO.html