Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38108/01/14 ©USC-CSSE 1University of Southern CaliforniaCenter for Systems and Software EngineeringSoftware SizingAli Afzal Malik & Vu NguyenPresented by Marilee Wheaton USC-CSSECSCI 510108/01/14 ©USC-CSSE 2University of Southern CaliforniaCenter for Systems and Software EngineeringOutline•Nature, value, and challenges of sizing•Sizing methods and tools •Sizing metrics•Maintenance sizing•Conclusions and references108/01/14 ©USC-CSSE 3University of Southern CaliforniaCenter for Systems and Software EngineeringNature and Value of Sizing•Definitions and general characteristics•Value provided by sizing•When does sizing add less value?108/01/14 ©USC-CSSE 4University of Southern CaliforniaCenter for Systems and Software EngineeringSize: Bigness/Bulk/MagnitudeMeasured in gallonsMeasured in usable square feetMeasured in ???108/01/14 ©USC-CSSE 5University of Southern CaliforniaCenter for Systems and Software EngineeringSizing Characteristics•Generally considered additive–Size (A U B) = Size (A) + Size (B)•Often weighted by complexity–Some artifacts “heavier” to put in place–Requirements, function points108/01/14 ©USC-CSSE 6University of Southern CaliforniaCenter for Systems and Software EngineeringSoftware Size is an Important Metric•A key metric used to determine –software project effort and cost: (effort, cost) = f(size, factors)–time to develop –staff–quality –productivity108/01/14 ©USC-CSSE 7University of Southern CaliforniaCenter for Systems and Software EngineeringWhen Does Sizing Add Less Value?•Often easier to go directly to estimating effort–Imprecise size parameters•GUI builders; COTS integration–Familiar, similar-size applications•Analogy to previous effort: “yesterday’s weather”•When size is a dependent variable–Time-boxing with prioritized features108/01/14 ©USC-CSSE 8University of Southern CaliforniaCenter for Systems and Software EngineeringSizing Challenges•Brooks’ factors: software system, product•Cone of uncertainty108/01/14 ©USC-CSSE 9University of Southern CaliforniaCenter for Systems and Software EngineeringBrooks’ Factor of 9 for Programming System ProductAProgramAProgrammingSystemAProgrammingProductAProgrammingSystemsProductx3x3Product: Handles off-nominal cases, testing; well-documentedSystem: Handles interoperability, data management, business managementTelecom: 1/6 basic call processing; 1/3 off-nominals; 1/2 billingAdapted from Brooks, 1995108/01/14 ©USC-CSSE 10University of Southern CaliforniaCenter for Systems and Software EngineeringThe Cost and Size Cone of Uncertainty•If you don’t know what you’re building, it’s hard to estimate its size or costBoehm et al. 2000108/01/14 ©USC-CSSE 11University of Southern CaliforniaCenter for Systems and Software EngineeringOutline•Nature, value, and challenges of sizing•Sizing methods and tools •Sizing metrics•Maintenance sizing•Conclusions and references108/01/14 ©USC-CSSE 12University of Southern CaliforniaCenter for Systems and Software EngineeringBasic Methods, Strengths, and Weaknesses(Adapted from Boehm, 1981)Method Strengths WeaknessesPair-wise comparison•Accurate assessment of relative size•Absolute size of benchmark must be knownExpert judgment•Assessment of representativeness, interactions, exceptional circumstances•No better than participants•Biases, incomplete recallAnalogy•Based on representative experience•Representativeness of experienceParkinson•Correlates with some experience•Reinforces poor practicePrice to win•Often gets the contract•Generally produces large overrunsTop-down •System level focus•Efficient•Less detailed basis•Less stableBottom-up•More detailed basis•More stable•Fosters individual commitment•May overlook system level costs•Requires more effort108/01/14 ©USC-CSSE 13University of Southern CaliforniaCenter for Systems and Software EngineeringComparison with Previous Projects•Comparable metadata: domain, user base, platform, etc.•Pair-wise comparisons•Differential functionality–analogy; yesterday’s weather108/01/14 ©USC-CSSE 14University of Southern CaliforniaCenter for Systems and Software EngineeringGroup Consensus•Wideband Delphi–Anonymous estimates–Facilitator provides summary–Estimators discuss results and rationale–Iterative process–Estimates converge after revision in next rounds–Improves understanding of the product’s nature and scope–Works when estimators are collocated•Planning Poker (Cohn, 2005)–Game: deck of cards–Moderator provides the estimation-item–Participants privately choose appropriate card from deck–Divergence is discussed–Iterative – convergence in subsequent rounds–Ensures everyone participates–Useful for estimation in agile projects108/01/14 ©USC-CSSE 15University of Southern CaliforniaCenter for Systems and Software EngineeringProbabilistic Methods•PERT (Putnam and Fitzsimmons, 1979)–3 estimates: optimistic, most likely, pessimistic–Expected Size = optimistic + 4 * (most likely) + pessimistic–Std. Dev. = (pessimistic – optimistic) / 6–Easy to use–Ratio reveals uncertainty–Example6Component aimibiEiδiSALES 6K 10K 20K 11K 2.33KDISPLAY 4 7 13 7.5 1.5INEDIT 8 12 19 12.5 1.83TABLES 4 8 12 8 1.33TOTALS 22 37 64 39 δ E = 3.6108/01/14 ©USC-CSSE 16University of Southern CaliforniaCenter for Systems and Software EngineeringWhy Do People Underestimate Size?(Boehm, 1981)•Basically optimistic and desire to please•Have incomplete recall of previous experience•Generally not familiar with the entire software job108/01/14 ©USC-CSSE 17University of Southern CaliforniaCenter for Systems and Software EngineeringOutline•Nature, value, and challenges of sizing•Sizing methods and tools •Sizing metrics•Maintenance sizing•Conclusions and references108/01/14 ©USC-CSSE 18University of Southern CaliforniaCenter for Systems and Software EngineeringSizing Metrics vs. Time and Degree of Detail(Stutzke, 2005)Process PhasePossible MeasuresPrimary AidsConcept Elaboration ConstructionIncreasing Time and DetailSubsystems Key FeaturesUser Roles, Use CasesScreens, Reports, Files, Application