Costing and Estimation with USE Case Points

1. Group Members
• Hasnain Nawaz FA19-RSE-017
• Babar Shehzad FA19-RSE-011
• Rana Asad FA19-RSE-037
• Mehboob Ali Bukhari FA19-RSE-054
1

2. Estimating Software Development Effort
Based on Use Cases Experiences From
Industry

3. Agenda
 Introduction
 Use Case Points Method
 Tools for Use Case Estimation
 Comparison b/w Use Case points and Function Points
 Data Collection from Industry
 Results
 Conclusion
3

4. Introduction
4

5. Introduction
Use Case point (UCP) is a software estimation technique used
to measure the software size with use cases. Based on work by
Gustav Karner in 1993.
Estimates software development effort during early phase of
software.
The number of UCPS in the project is based on the following
 The number and complexity of use cases in the system.
 The number and complexity of actors in the system.
5

6. Use Case Points Method
Use Case Points method analyzes the use case actors, scenarios and
various technical and environmental factors and abstract them into
an equation.
The equation is composed of four variables
 Technical Complexity Factor (TCF).
 Environment Complexity Factor (ECF).
 Unadjusted Use Case Points (UUCP).
 Productivity Factor (PF).
6

7. Use Case Points Method
Each variable is defined and computed separately, using
perceived values and various constants.
The complete equation is:
 UCP=TCF * ECF * UUCP * PF
 TCF=0.6+(.01*Total Factor)
 ECF=1.4+(-0.03*Total Factor)
7

8. Use Case Points Method
The necessary steps to generate the estimate based on the UCP
method are:
1) Determine and compute the Technical Factors.
2) Determine and compute the Environmental Factors.
3) Compute the Unadjusted Use Case Points.
4) Determine the Productivity Factor.
8

9. Technical Factors
9
Technical Factor Description Weight
T1 Distributed system 2
T2 Performance 1
T3 End User Efficiency 1
T4 Complex internal Processing 1
T5 Reusability 1
T6 Easy to install 0.5
T7 Easy to use 0.5
T8 Portable 2
T9 Easy to change 1
T10 Concurrent 1
T11 Special security features 1
T12 Provides direct access for third
parties
1
T13 Special user training facilities are
required
1

10. Calculating Technical Factors
C
10
Technical
Factor
Description Weight Perceived
Complexity
Calculated Factor
(weight*perceived
complexity)
T1 Distributed System 2 5 10
T2 Performance 1 4 4
T3 End User Efficiency 1 2 2
T4 Complex internal Processing1 4 4
T5 Reusability 1 2 2
T6 Easy to install 0.5 5 2
T7 Easy to use 0.5 3 2
T8 Portable 2 3 6
T9 Easy to change 1 3 3
T10 Concurrent 1 2 2
T11 Special security features 1 2 2
T12 Provides direct access for
third parties
1 5 5
T13 Special user training
facilities are required
1 3 3
Total Factor 47

11. CAL Environmental Complexity Factors
11
Environmental
Factor
Description Weight Perceived
Impact
Calculated Factor
(weight*perceived
complexity)
E1 Familiarity with UML 1.5 4 6
E2 Application Experience 0.5 2 1
E3 Object Oriented Experience 1 5 5
E4 Lead analyst capability 0.5 2 1
E5 Motivation 1 1 1
E6 Stable Requirements 2 5 10
E7 Part-time workers -1 0 0
E8 Difficult Programming language 2 1 2
Total
Factor
26

12. Calculating Unadjusted Use Case Weight
12
Use Case Type Description Weight Number of Use
Cases
Result
Simple A simple user interface and touches
only a single database entity; its
success scenario has 3 steps or less;
its implementation involves less than 5
classes.
5 8 40
Average More interface design and touches 2 or
more database entities; between 4 to 7
steps; its implementation involves
between 5 to 10 classes.
10 12 120
Complex Involves a complex user interface or
processing and touches 3 or more
database entities; over seven steps; its
implementation involves more than 10
classes.
15 4 60
Total UUCW 220

13. Calculating Unadjusted Actor Weight
In a similar manner, the Actors are classified as Simple,
Average or Complex based on their interactions
13
Actor Type Description Weight Number of Actors Result
Simple The Actor represents another
system with a defined API
1 8 8
Average The Actor represents another
system interacting through a
protocol, like TCP/IP
2 12 24
Complex The Actor is a person interacting
via an interface.
3 4 12
Total UAW 44

14. Calculating UUCP
Finally, the UUCP is computed by adding the UUCW and the
UAW.
UUCP=UUCW+UAW
UUCP=220+44
UUCP=264
14

15. Productivity Factor
The Productivity Factor (PF) is a ratio of the number of man
hours per use case point based on past projects.
Schneider and Winters recommend that
 If the total of environmental factor is 2 or less use 20 staff
hours /UCP
 If the total of environmental factor is 3 or 4 use 28 staff
hours /UCP
 If the total of environmental factor exceeds from 4 use
36 staff hours /UCP
15

16. Final Calculation
UCP = TCP * ECF * UUCP * PF
For the sample values used in this article:
UCP = 1.07 * 0.62 * 264 * 20 = 3502.752 or 3503 hours.
Dividing the UCP by 40 hours (for one man work week) = 88
man-weeks. Therefore, for the sample values in this article, it
would take one developer 88 weeks (or about 22 months) to
complete the application.
16

17. Tools For Use Case Estimation
Optimize is a tool that provides estimates based on use case
models.
Optimize measures the size of the problem counting and
classifying scope elements in a project.
The set of use cases in the project’s use case model is one kind
of scope element.
Other possible scope elements are the project’s classes,
components and web-pages.
17

18. Comparison b/w Use Case and Function Points
Use Case points are Based on the Use Case Models due to that
reason it is easier to develop estimation tools that automatically
count use case points.
While in counting Function Points much effort and skill
required.
There are international standards on how to count function
points.
The concept of use case points, on the other hand, has not yet
reached the level of standardization.
18

19. Data Collection From Industry
Table 3 shows some characteristics of the three software
development projects used in our case studies.
19

20. Data Collection From Industry
Our research project was conducted in parallel with project A
during a period of seven months.
Projects B and C, on the other hand, were finished before the
start of our research.
Data from project A was collected from the project documents.
Data from project B was collected from project documents,
and from e-mail communication.
Data from project C was collected from project
documents, including a requirements specification
20

21. Results
The use case estimates are fairly close to the estimates
produced by the experts.
21

22. Results
In projects A and C, the use case estimate ended up only
slightly below the expert estimate but a bit below the actual
effort.
The use case estimate for project B is close to actual effort and
somewhat higher than the expert estimate.
The first use case estimate for project B is higher than expert
estimates and even than actual effort estimate.
Because in this trivial actors also counted such as printer.
22

23. Advantages of Use Case Points
 UCPs are based on use cases and can be measured very
early in the project life cycle.
 UCP (size estimate) will be independent of the size, skill,
and experience of the team that implements the project.
 UCP based estimates are found to be close to actuals when
estimation is performed by experienced people.
23

24. Conclusions
 With the help of generalization between actors the
precision of the estimate will be increased.
 Karner recommend that Included and extending use cases
should not be counted because it effect on precision.
 Use case estimates should not substitute expert estimates
while it seems sensible to combine models and human
judgment.
 The results indicate that this method can be used
successfully since the use case estimates were close to the
expert estimates in our three case studies.
24

25. 25
Thanks!
Any questions?