Use Case Point Estimation

Use Case Point Estimation:

Use case modeling is a popular and widely used technique for capturing and describing the functional requirements of a software system.

The designers of UML recommend that developers follow a use case driven development process where the use case model is used as input to design, and as a basis for verification, validation and other forms of testing.

A use case model defines the functional scope of the system to be developed. The functional scope subsequently serves as a basis for top-down estimates.

An important prerequisite for applying a use case based estimation method is that the use cases of the system under construction have been identified at a suitable level of detail and the division of the functional requirements into the use case. The use case model may be structured with a varying number of actors and use cases. These numbers will affect the estimates.

The steps of the use case point method as follows:

The first step is to classify actors as simple, average or complex to determine the UAW (Unadjusted Actor weight).

The following example provided for how to classifying the actors:

Actor Classification	Examples	Weighting Factor	Number of Classification in Sample Project	UAW (Weighting Factor * Number of classification)
Simple	Simple actors are those which communicate to system through API.	1	3	3
Average	Average actors are recognized if they have the following properties: Actors who are interacting with the system through some protocol (HTTP, FTP, or probably some user defined protocol). Actors which are data stores (Files, RDBMS).	2	2	4
Complex	Complex actor is interacting normally through GUI.	3	1	3
Total (UAW)				10

The second step is to count the use cases and assign weights depending on number of scenarios and number of transactions to determine number of UUCW (Unadjusted Use case Weight)

The following example provided for how to classifying the use case types:

Use Case Type	Examples	Weighting Factor	Number of Use case types in Sample Project	UUCW (Weighting Factor * Number of use case types)
Simple	Greater than or equal to 3 transactions	5	3	15
Average	Between 4 to 7 transactions	10	2	20
Complex	Greater than 7 transactions	15	1	15
Total(UUCW)				50

UUCP (Unadjusted Use Case Point):

The third step is to calculate the UUCP (Unadjusted Use Case Point).

Total UUCP = Total UAW + Total UUCW.

Total UUCP = 10 + 50 = 60.

The fourth step is computing technical factor and TCF.

The following example provided for how to classifying the technical factors:

No	Technical factor	Weight	Description	Weight for sample project
t1	Distributed System	2	Is the system having distributed architecture or centralized architecture?	2
t2	Response time	1	Does the client need the system to fast? Is time response one of the important criteria?	0
t3	End user efficiency	1	How's the end user's efficiency?	1
t4	Complex internal processing	1	Is the business process very complex? Like complicated accounts closing, inventory tracking, heavy tax calculation etc.	0
t5	Reusable code	1	Do we intend to keep the re-usability high? So will increase the design complexity.	0
t6	Installation ease	0.5	Is client looking for installation ease?	0.5
t7	Easy use	0.5	Is user friendliness a top priority?	0.5
t8	Portable	2	Is the customer also looking for cross platform implementation?	0
t9	Easy to change	1	Is the customer looking for high customization in the future? That also increases the architecture design complexity and hence this factor.	0
t10	Concurrent	1	Is the customer looking at large number of users working with locking support? This will increase the architecture complexity and hence this value.	1
t11	Security objectives	1	Is the customer looking at having heavy security like SSL? Or do we have to write custom code logic for encryption?	0
t12	Direct access to third parties	1	Does the project depend in using third party controls?	0
t13	User training facilities	1	Will the software from user perspective be so complex that separate training has to be provided? So this factor will vary accordingly.	0

Equation for Tfactor = sum(T1....T13)

TCF (Technical Complexity Factor): TCF = 0.6 + (0.01 * Tfactor).

Based on our sample project:

Tfactor = 5

TCF = 0.6 + (0.01 * 5) = 0.65

The fifth step is computing environmental factor (EF).

The following example provided for how to classifying the environmental factors:

No	Environmental Factor	Weight	Description	Weight for sample project
e1	Familiarity with project	1.5	Are all the people working in the project familiar with domain and technical details of the project? Probably you will spend most of your time in explaining them all know-how's.	1.5
e2	Application experience	0.5	How much is the application experience?	0.5
e3	Object-oriented programming experience	1	As use-case documents are inputs to object oriented design, it's important that people on the project should have basic knowledge of OOP concepts.	1
e4	Lead analyst capability	0.5	How is the analyst who is leading the project? Does he have enough knowledge of the domain?.	0
e5	Motivation	1	Are the programmers motivated for working on the project?	0
e6	Stable requirements	2	Is the client clear of what he wants?	0
e7	Part-time Staff	-1	Are there part-time staff in projects, like consultants etc.?	0
e8	Difficult programming language	-1	How much is the language complexity, Assembly, VB 6.0, C++, C etc.	0

Efactor = SUM(e1...e8)

Environmental Factor = EF = 1.4 + (-0.03 * Efactor)

Based on our sample project:

Efactor = 3

Environmental Factor = EF = 1.4 + (-0.03 * 3) = 1.31

The sixth step is calculating AUCP (Adjusted Use Case Points).

AUCP = UUCP * TCF * EF

Based on our sample project:

AUCP = 60 * 0.65 * 1.31 = 51.09

The seventh step is to calculate project duration.

Total effort estimation for the sample project, for proposed a factor of 20 staff hours per Use Case point for a project estimate.

Total effort = AUCP * Staff hours per Use Case point

Based on our sample project:

Total effort = 51.09 * 20 = 1021.8 (hrs)

Assuming 8 working hours/day Total effort = 178 man-days

Taking into account the average effort involved in the SDLC phases, we can now calculate the following:

Phases	% Effort	Estimated duration (man-days)
Business Analysis	30	53.4
System Analysis	20	35.6
Design	10	17.8
Construction	25	44.5
Testing	10	17.8
Roll-out	5	8.9
Total (man-days)		178

Acronyms and Abbreviation:

Advantage of using use case points:

Automation: Use Case document if structured properly for a company (uniformly), we can use automation tools. In case of FP, this is difficult.

Disadvantage of using use case points:

Cannot be used during initial phase: Estimations are normally done at earlier stage of projects. When we say earlier, it means during the first and second meetings with the client. Use Case documents are mostly prepared after the project sign off. So during earlier stage, this document will not be available. Preparing Use Case document during first and second meeting with the client means wasting your resources in case you do not get the project.

No Standard Use Case Document: The document structure of use is not standard still. It varies not only from company to company but also from project to project. So the estimation has significant variance according to the structure of Use Case documents. Even the writing matters to a large extent. And also, how one identifies Use-Case and the transaction associated with it. Free textual descriptions may lead to ambiguous specifications.

Maintenance estimation problems: Function point failed for maintenance projects. It will be difficult from Use Case Points to do maintenance estimation.

Actor identification need technical details: In order that the actor be classified, we need to know technical details like which protocol the actor will use. So estimation can be done by technical guys. FP is not technical dependent.