estimating with use cases extracts from the lamri use case survival guide™ mark aked managing...
Post on 15-Jan-2016
219 Views
Preview:
TRANSCRIPT
Estimating with Use CasesExtracts from the Lamri Use Case Survival Guide™
Mark Aked
Managing Consultant
For more information visit www.lamri.com or email marketing@lamri.com
Copyright 2003
Copyright 2003
Agenda
Why Estimates are not Accurate
What Use Cases bring to Estimating
What a Difference a Phase makes!
Estimating MethodsUse Case Points – a worked exampleHow Use Cases can be mapped to function points
Summary
Questions
Copyright 2003
The Typical Estimating Process
Architecture
ScheduleNeeds
Budget
Copyright 2003
Why Estimates are not Accurate
Copyright 2003
Why Estimates are not Accurate
Copyright 2003
Why Estimates are not Accurate
Copyright 2003
Why Estimates are not Accurate
Copyright 2003
Why Estimates are not Accurate
Technical and Process Issues are uncovered and the uncertainty increases
The uncertainty blip
Copyright 2003
Agenda
Why Estimates are not Accurate
What Use Cases bring to Estimating
What a Difference a Phase makes!
Estimating MethodsUse Case Points – a worked exampleHow Use Cases can be mapped to function points
Summary
Questions
Copyright 2003
Do Use Cases Improve Estimates?
Use Cases provide a mechanism for articulating the product scope from the user’s point of view
Size and Complexity can be attributed to each Use Case, but are really based upon the artefacts derived from Use Cases
Copyright 2003
Product Complexity and Size
Product complexity is driven by architecture
Architecture is represented in many models!
Product Size is measured through artefacts derived from a Use Case
Copyright 2003
Architecture Exposes Complexity
Copyright 2003
Do Use Cases Improve Estimates?
An approximate answer to the right question is worth a good deal more than
the exact answer to an approximate problem.John Tukey
“”
Use Cases help us ensure the right question is being answered and provide the basis
for the approximate answer.
Copyright 2003
The Waterfall Process Prevents Accurate Estimates
The waterfall process leaves technical risks unexposed for too long
Technical risks may be considered but are not actively mitigated by proving (i.e. actually building and integrating software)
Copyright 2003
The Waterfall Process Prevents Accurate Estimates
When technical risks become issues the cost and schedule have to be extended invalidating the budget forecast
Adding Use Cases to a waterfall process improves the articulation and management of scope but the estimate will still hit the ‘uncertainty blip’ too late
Copyright 2003
Agenda
Why Estimates are not Accurate
What Use Cases bring to Estimating
What a Difference a Phase makes!
Estimating MethodsUse Case Points – a worked exampleHow Use Cases can be mapped to function points
Summary
Questions
Copyright 2003
Remember this?
Copyright 2003
What a Difference A Phase Makes!
Copyright 2003
What a Difference A Phase Makes!
Copyright 2003
What a Difference A Phase Makes!
Copyright 2003
What a Difference A Phase Makes!
Copyright 2003
What a Difference A Phase Makes!
Copyright 2003
What a Difference A Phase Makes!
Copyright 2003
What a Difference A Phase Makes!
Copyright 2003
Your SDLC Constrains Your Ability to Estimate
Inserting a technical risk phase into your software development lifecycle (SDLC) will have a significant contribution to your estimating accuracy
Pulls the uncertainty blip forward
Encourages you to do the hard stuff first
Enables you to assess whether you can actually deliver
Provides real metrics to improve the estimate
Enables you to carry out an Engineering Forecast
Copyright 2003
Agenda
Why Estimates are not Accurate
What Use Cases bring to Estimating
What a Difference a Phase makes!
Estimating MethodsUse Case Points – a worked exampleHow Use Cases can be mapped to function points
Summary
Questions
Copyright 2003
Estimating Methods We Can Use
Analogy - Compare the proposed project to previously completed similar projects where project development information is known.
Bottom-up - Identify and estimating each individual component separately, then combining the results to produce an estimate of the entire project.
Top-down - Project is partitioned into lower-level components and life cycle phases beginning at the highest level.
Expert Judgement - Human ‘experts’ consulted to provide an estimate based upon their experience and understanding of a proposed project.
Algorithmic - Use of equations from research and historical data to perform software estimates.
Copyright 2003
Which Methods Do We Apply?
We tend to use Expert Judgement
We should use a blend of methods at the appropriate time
The method that is least used or avoided (but craved for) is the algorithmic method
Copyright 2003
The Recommended Approach
E = Expertise
Copyright 2003
The Recommended Approach
E = Expertise A = Algorithm
Copyright 2003
The Recommended Approach
E = Expertise A = Algorithm
Copyright 2003
The Recommended Approach
Algorithms provide the repeatable basis that supplement the Risk Focused approach
E = Expertise A = Algorithm
Copyright 2003
Using Algorithms with Use Cases
A worked example of Use Case Points
How use cases can be mapped to function points
A few points about algorithmsAll based upon knowledge of the scope
Require a feedback mechanism for tuning
Differentiator is the currency they use for scope / risks
Copyright 2003
Use Case PointsDeveloped by Gustav Karner of Objectory in 1993
Derived from Function Points
Uses weighting on Actors and Use Cases to assess scope
Uses Environmental and Technology factors to assess Risk
Applicable to small team, < 5 month development
Quick and dirty but can be accurate
Copyright 2003
Use Case Points Process
Copyright 2003
Weight Actors (AW)
Copyright 2003
Weight Actors (AW)
Each Actor (interface) is
weighted based on Actor Type
Actor Weighting (AW) = ∑Actor Weights
Copyright 2003
Weight Use Cases (UCW)
Copyright 2003
Weight Use Cases (UCW)
Use Case Weighting Factor is
based on the Number of Use
Case Flows
Use Case Weighting (UCW) = ∑Use Case Weights
Copyright 2003
Apply Technical Factors (TCF)The Technical Complexity Factor (TCF) is
derived by assigning a value to each technical factor on a scale of 0 to 5. 0 = Factor is
irrelevant for this project5 = Factor is essential.
Total Weighted Factor = ∑(Extended Value)
Extended Value =
Assigned Value x Weight
TCF = 0.6+(0.01*Total Weighted Value)
Copyright 2003
Apply Environmental Factors (ECF)The Environmental Factors (EF) considers the experience level of the people on the project derived from rating each factor from 0 to 5. 0
= factor is irrelevant for this project 5 = factor is essential for this project
Total Weighted Factor = ∑(Extended Value)
Extended Value =
Assigned Value x Weight
EF = 1.4+(-0.03 x Total Weighted Value)
Copyright 2003
Apply Environmental Factors (ECF)
How many > 3?
How many < 3?
Person Hours Factor (PHF)If total <= 2, PHF = 20
If total = 3 or 4, PHF = 28 hours.Above this…big risk!!!
Copyright 2003
Apply Environmental Factors (ECF)
PHF = 4, so 28 Person Hours
How many > 3?
How many < 3?
Person Hours Factor (PHF)If total <= 2, PHF = 20
If total = 3 or 4, PHF = 28 hours.Above this…big risk!!!
Copyright 2003
Calculate Effort and Schedule
Use Case Points = (AW + UCW) x TCF x EF
Use Case Points = (8 + 35) x 0.93 x 0.905 = 36.19
Copyright 2003
Analysis of Use Case Points
Take Use Cases as the natural currency
Provides an effort estimate
Additional work required on the resource and SDLC process profile
Assume all team have same competence
Copyright 2003
Analysis of Use Case Points
Don’t really get ‘inside’ the Use Case to incorporate other scope elements
Little scope for tuning the results of what we know more
Not a widely used metric for size
Copyright 2003
Function Points
Provides a unit of software size calculated from functional requirements.
Are independent of technology or method.
Developed for business systems, not scientific or real-time based systems
2 flavoursFunction Points – US developed
MK II Function Points – UK developed
Copyright 2003
Function Point Analysis
Copyright 2003
Function Point Analysis
Copyright 2003
Function Point Analysis
Number of Input
Attributes
Number of Entities
Referenced
Number of Output Attributes
Copyright 2003
Function Point Analysis
UFP = (0.58*Number of Input Attributes) + (1.66*Number of Entities Referenced) + (0.26*Number of Output Attributes)
Number of Input
Attributes
Number of Entities
Referenced
Number of Output Attributes
Copyright 2003
Function Point Analysis
UFP = (0.58*Number of Input Attributes) + (1.66*Number of Entities Referenced) + (0.26*Number of Output Attributes)
Number of Input
Attributes
Number of Entities
Referenced
Number of Output Attributes
Copyright 2003
Use Cases and Function Points
Copyright 2003
Use Cases and Function Points
A Use Case flow contains one or more Functional
Transactions
Copyright 2003
Use Cases and Function Points
Logical Transactions found by studying the Use
Case Flow
A Use Case flow contains one or more Logical
Transactions
Copyright 2003
Use Case and Function Point Process
Copyright 2003
Use Case and Function Point Process
Copyright 2003
Use Case and Function Point Process
Copyright 2003
Use Case and Function Point Process
Copyright 2003
Use Case and Function Point Process
Copyright 2003
Function Point Guidelines
CCTA Guidelines for Function Point Estimation
Copyright 2003
Use Case and Function Point Process
UFP = (0.58*Number of Input Attributes) + (1.66*Number of Entities Referenced)+ (0.26*Number of Output Attributes)
UFPSystem = ∑(UFP1 + UFP2 + … + UFPn)
Copyright 2003
Use Case and Function Point Process
System Characteristics
Data CommunicationsDistributed Data ProcessingPerformanceHeavily Use ConfigurationTransaction RateOn-line Data EntryEnd-User EfficiencyOn-line UpdateComplex ProcessingRe-useabilityEase of InstallationEase of OperationMultiple SitesFacilitate Change
Copyright 2003
Analysis of Function Points
Take Logical Transactions the natural currency
Mapping can be made to Use Cases
Can be used as the input into various algortihmic methods (e.g. COCOMOII)
Widely used
Copyright 2003
Analysis of Function Points
Only applicable to business systems
Require good understanding of counting rules and so trained counters
Copyright 2003
Summary
Use Cases provide a close approximation of project scope that provides an estimate that is extremely useful for high-level project planning.
We need a process that respects technical and project risk (capability) so that it naturally becomes part of the planning and estimation process.
Copyright 2003
Summary
Remember the Cone of UncertaintyAdding a phase that addresses technical risk will have a significant impact upon the confidence of your estimate
Use a blend of estimating methods but include an algorithmic approach
Copyright 2003
Summary
All algorithmic approaches are all based upon knowledge of the scope Garbage IN Garbage OUT
Require a feedback mechanism for tuning Need to be applied at the organisation level in order to gain comparison and past project data
Differentiator is The currency they use for scope / risks
top related