Counting Use Case Points

1
Counting Use Case Points

• Peter Bink
• December 7th, 2006

2
The history of and rationale behind use case
points

• Initiated by Capgemini US and UK in 2000
• to determine functional size in an early stage.
• NL involved since 2001
• Not a global standard way of counting functional
• size.
• Requirements Quantifying the functional size
• Correlation with FPs and SLOCs
• Connected to RUP
• Easy to count
• UCP is now used for
• Most of our top down estimates
• All project closure evaluations
• For .NET, JAVA and BI projects

3
Where are Use Case Points based on?

• Flows
• Main flow
• Alternative flows
• Errorflows
• Boundary classes
• Screens
• Interface messages
• Reports
• Business rules

4
Flows
Alternative
Main
Error
5
Boundary classes
High correlation with functional size
Screens
Reports
Interfaces
6
Business rules
Business rules
7
Correlation between UCP and FP

• Remarks
• Dutch and English projects
• For UK projects FP are backfired from SLOCs

8
Advantages
Early sizing by experienced analyst Intuitive
approach that analysts can use if they are
familiar with use cases. The concept of use
cases is persistent throughout a project Use
case sizing is easy/cheap Easy to use with new
techniques, such as SOA, Buss. Intell. Can be
used for calculations The approach works well.
There may be more accurate sizing approaches but
none that we have found so far are as cheap,
flexible, intuitive and easy to use up front.
9
Challenges
Find the right level of aggregation
Versus
Not an accepted standardised method
Not documented in detail (like NESMA PFA)
Cannot be used easily by other companies, because
there are some undocumented features
10
Tips tricks
Preferably use more than one sizing
method. Dont mix between size and
productivity Translate complexity in
productivity Size is uniquely
quantified Calibrate regularly between people
that count UCPs
11
More info
peter.bink_at_capgemini.com