Tutorial: System and Software SizingSoftware Sizing
USC-CSSE
Outline
Sizing methods and tools
Nature and Value of Sizing
Definitions and general characteristics
Value provided by sizing
University of Southern California
Size: Bigness/Bulk/Magnitude
Measured in ???
Sizing Characteristics
Often weighted by complexity
Requirements, function points
software project effort and cost:
(effort, cost) = f(size, factors)
Often easier to go directly to estimating effort
Imprecise size parameters
When size is a dependent variable
Time-boxing with prioritized features
University of Southern California
Sizing Challenges
Cone of uncertainty
Brooks’ Factor of 9 for Programming System Product
A
Program
A
Programming
System
A
Programming
Product
A
Programming
Systems
Product
x3
x3
System: Handles interoperability, data management, business management
Telecom: 1/6 basic call processing; 1/3 off-nominals; 1/2 billing
Adapted from Brooks, 1995
University of Southern California
The Cost and Size Cone of Uncertainty
If you don’t know what you’re building, it’s hard to estimate its size or cost
Boehm et al. 2000
University of Southern California
Outline
Sizing methods and tools
Basic Methods, Strengths, and Weaknesses
(Adapted from Boehm, 1981)
Absolute size of benchmark must be known
Expert judgment
No better than participants Biases, incomplete recall
Analogy
Bottom-up
University of Southern California
Comparison with Previous Projects
Pair-wise comparisons
Differential functionality
Group Consensus
Wideband Delphi
Anonymous estimates
Iterative process
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
Divergence is discussed
Ensures everyone participates
University of Southern California
Probabilistic Methods
3 estimates: optimistic, most likely, pessimistic
Expected Size = optimistic + 4 * (most likely) + pessimistic
Std. Dev. = (pessimistic – optimistic) / 6
Easy to use
Ratio reveals uncertainty
Why Do People Underestimate Size?
(Boehm, 1981)
Generally not familiar with the entire software job
University of Southern California
Outline
Sizing methods and tools
Sizing Metrics vs. Time and Degree of Detail
(Stutzke, 2005)
Process Phase
Possible Measures
Primary Aids
Function Points
Product Vision, Analogies
Sizing Metrics and Methodologies
Module (file) Count
Counting Artifacts
Often weighted by relative difficulty
Easy to count at initial stage
Estimates may differ based on level of detail
University of Southern California
Cockburn Use Case Level of Detail Scale
(Cockburn, 2001)
Function Point Analysis - 1
FPA measures the software size by quantifying functionality of the software provided to users
Five function types
Transactions
Each function is weighted by its complexity
Total FP is then adjusted using 14 general systems characteristics (GSC)
MS Word
Function Point Analysis - 2
Can be measured early in project lifecycle
Can be applied consistently across projects and organizations
Disadvantages
Difficult to count size of maintenance projects
University of Southern California
COSMIC FP
COSMIC measures functionality of the software thru the movement of data (exit, entry, read, write) cross logical layers
Advantages
Require detailed architecture
University of Southern California
Use Case Point
UCP counts functional size of the software by measuring the complexity of use cases
Advantages
Can be measured early in project lifecycle
Easier to count than FPA
Disadvantages
University of Southern California
CK Object-Oriented Metrics
Weighted Methods Per Class (WMC)
Depth of Inheritance Tree (DIT)
Number of Children (NOC)
Lack of Cohesion in Methods (LCOM)
Advantages
Disadvantages
University of Southern California
Source Lines of Code (SLOC)
SLOC measures software size or length by counting the logical or physical number of source code lines
Physical SLOC = number of physical lines in code
Logical SLOC = number of source statements
Advantages
Can be automated easily using tools (e.g., USC’s CodeCount)
Easy to understand for customers and developers
Reflect the developer’s view of software
Supported by most of cost estimation models
Disadvantages
Difficult to estimate early
University of Southern California
SLOC Counting Rules
- Based on SEI definition checklist from CMU/SEI-92-TR-20
- Modified for COCOMO II
(
(
(
Relationship Among Sizing Metrics
Implementation-specific e.g. Source Lines of Code (SLOC)
Implementation-independent e.g. Function Points (FP)
Need to relate the two categories
e.g. SLOC/FP backfire ratios
University of Southern California
SLOC/FP Backfiring Table
University of Southern California
Multisource Estimation
Advantage: implementation-independent
Good for productivity comparisons when using VHLLs, COTS, reusable components
Weakness: implementation-independent
Gives same estimate when using VHLLs, COTS, reusable components, 3GL development
Multisource estimation reduces risk
University of Southern California
Outline
Sizing methods and tools
Sizing in Reuse and Maintenance
Acquired Code
Calculating Total Equivalent SLOC - 1
Formulas:
DM = % design modified, CM = % code modified, IM = % integration and test needed
University of Southern California
Calculating Total Equivalent SLOC - 2
University of Southern California
Adaptation Adjustment Modifier (AAM)
Relative Cost
Old AAM formula
New AAM formula
Old AAM formula
New AAM formula
Vu Nguyen: Using the exact formula of calculating the percentage
Vu Nguyen: Using the approximate formula
University of Southern California
Conclusions
Size plays an important role in estimation and project management activities
Software estimation is a “garbage in garbage out” process
Bad size in; bad cost out
A number of challenges make estimation of size difficult
Different sizing metrics
FP, COSMIC FP (cfu), Use Case Points, SLOC, CK OO metrics
A plethora of sizing methods exists each method has strengths and weaknesses
University of Southern California
References
Books
Boehm, Barry W., Software Engineering Economics, Prentice Hall, 1981.
Boehm, Barry W., et al., Software Cost Estimation With COCOMO II, Prentice Hall, 2000.
Brooks, Jr., Frederick P., The Mythical Man-Month, Addison-Wesley, 1995.
Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 2001.
Cohn, M., Agile Estimating and Planning, Prentice Hall, 2005.
Jones, C., Applied Software Measurement: Assuring Productivity and Quality, McGraw-Hill, 1996.
Stutzke, Richard D., Estimating Software-Intensive Systems, Addison-Wesley, 2005.
Journals
Chidamber, S. and C. Kemerer, 1994, “A Metrics Suite for Object Oriented Design,” IEEE Transactions on Software Engineering.
Putnam, L.H., and Fitzsimmons, A., 1979. Estimating software costs. Datamation.
Tutorials/Lectures/Presentations
Boehm, Barry W., and Malik, Ali A., COCOMO Forum Tutorial, “System & Software Sizing”, 2007.
Boehm, Barry W., CSCI 577a Lecture, “Cost Estimation with COCOMO II”, 2004.
Madachy, Ray, CSCI 510 Lecture, “COCOMO II Overview”, 2005.
Valerdi, Ricardo, INCOSE Presentation, “The Constructive Systems Engineering Cost Model”, 2005.
ü
ü
ü
Relative # of interfaces