Project Estimation with Use Case Points

By RoyClem

An introduction to project estimation with Use Case Points. 

Introduction
Object-oriented applications frequently rely on Use Cases to describe the business processes
of a software application. Since use cases consist of the strategic goals and scenarios that
provide value to a business domain, they can also provide insight into an application’s
complexity. Deriving a reliable estimate of the size and effort an application needs, is
possible by examining the actors and scenarios of a use case. Use Case Points is a project
estimation method that employs a project’s use cases to produce an accurate estimate of a
project’s size and effort.

Use Case Points

Use case modeling is an accepted and widespread technique to capture the business
processes and requirements of a software application. Since they provide the functional
scope of the application, analyzing their contents provides valuable insight into the effort and
size needed to design and implement the application. In general, applications with large,
complicated use cases take more effort to design and implement than small applications with
less complicated use cases. Moreover, the time to complete the application is affected by:
 The number of steps to complete the use case.
 The number and complexity of the actors.
 The technical requirements of the use case such as concurrency, security and
performance.
 Various environmental factors such as the development teams’ experience and
knowledge.

Use Case Points (UCP) is an estimation method that provides the ability to estimate an
application’s size and effort from its use cases. Based on work by Gustav Karner in 1993,
UCP analyzes the use case actors, scenarios and various technical and environmental factors
and abstracts them into an equation.
The equation is composed of four variables:
1. Technical Complexity Factor (TCF).
2. Environment Complexity Factor (ECF).
3. Unadjusted Use Case Points (UUCP).
4. Productivity Factor (PF).

Each variable is defined and computed separately, using perceived values and various
constants. The complete equation is:
UCP = TCP * ECF * UUCP * PF
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.
5. Compute the product of the variables.

Technical Complexity Factors

Thirteen standard technical factors exist to estimate the impact on productivity that
various technical issues have on an application. Each factor is weighted according
to its relative impact. A weight of 0 indicates the factor is irrelevant and the value 5
means that the factor has the most impact.
Technical Factor Description Weight

T1 Distributed system 2

T2 Performance 1

T3 End User Efficiency 1

T4 Complex internal 1
Processing

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 1

third parties

T13 Special user training 1

facilities are required
Figure 1: Technical Factors.
For each project, the technical factors are evaluated by the development team and assigned
a value from 0 to 5 according to their perceived complexity – multithreaded apps. require
more skill and time than single threaded applications, for example, as do reusable apps. A
perceived complexity of 0 means the technical factor is irrelevant for this project; 3 is
average; 5 means it has strong influence.
Each factor’s weight is multiplied by its perceived complexity to produce its calculated factor.
The calculated factors are summed to produce the Total Factor.
So, using sample perceived complexity values, the Technical Total Factor might be computed
as follows:

Technical Description Weight Perceived Calculated Factor

Factor Complexity (weight*perceived
complexity)>

T1 Distributed System 2 5 10

T2 Performance 1 4 4
T3 End User Efficiency 1 2 2

T4 Complex internal 1 4 4
Processing

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 1 5 5

third parties

T13 Special user training 1 3 3

facilities are required

Total Factor 47
Figure 2: Calculating the Technical Total Factor.
In Figure 2, the Total Factor is 47 derived by summing all the calculated factors. To produce
the final TCF, two constants are computed with the Total Factor. The complete formula to
compute the TCF is as follows:
TCF = 0.6 + (.01*Total Factor). For Figure 1, the TCF = 1.07

Environmental Complexity Factors

Environmental Complexity estimates the impact on productivity that various

environmental factors have on an application. Each environmental factor is
evaluated and weighted according to its perceived impact and assigned a value
between 0 and 5. A rating of 0 means the environmental factor is irrelevant for this
project; 3 is average; 5 means it has strong influence.

Environmental Description Weight

Factor

E1 Familiarity with UML 1.5

E2 Application Experience 0.5

E3 Object Oriented Experience 1

E4 Lead analyst capability 0.5

E5 Motivation 1

E6 Stable Requirements 2

E7 Part-time workers -1

E8 Difficult Programming language 2

Figure 3: Example Environmental Factors.
Each factor’s weight is multiplied by its perceived complexity to produce its calculated factor.
The calculated factors are summed to produce the Total Factor.
Using sample values for perceived impact, the Environmental Total Factor might be
computed as:
Calculated Factor
Environmental Description Weight Perceived
Factor Impact (weight*perceived
complexity)

E1 Familiarity with UML 1.5 4 6

E2 Application Experience 0.5 2 1

E3 Object Oriented 1 5 5
Experience

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 2 1 2
language

Total 26
Factor
Figure 4: Calculating the Environmental Total Factor.
In Figure 4, the Total Factor is 26 derived by summing all the calculated factors. To produce
the final ECF, two constants are computed with the Total Factor. The complete formula to
compute the ECF is as follows:
ECF = 1.4 + (-0.03*Total Factor). For Figure 4, the ECF = 0.62

Unadjusted Use Case Points (UUCP)

Unadjusted Use Case Points are computed based on two computations:
1. The Unadjusted Use Case Weight (UUCW) based on the total number of activities (or
steps) contained in all the use case Scenarios.
 2. The Unadjusted Actor Weight (UAW) based on the combined complexity of all the use
cases Actors.

UUCW
Individual use cases are categorized as Simple, Average or Complex, and weighted
depending on the number of steps they contain - including alternative flows.

Use Case Type Description Weight

Simple A simple user interface and touches only a 5

single database entity; its success scenario has
3 steps or less; its implementation involves less
than 5 classes.

Average More interface design and touches 2 or more 10

database entities; between 4 to 7 steps; its
implementation involves between 5 to 10
classes.

Complex Involves a complex user interface or processing 15

and touches 3 or more database entities; over
seven steps; its implementation involves more
than 10 classes.
Figure 5: Use Case Categories.
The UUCW is computed by counting the number of use cases in each category, multiplying
each category of use case with its weight and adding the products.

Use Case Type Description Weight Number of Use Result

Cases

Simple A simple user interface and 5 8 40

touches only a single database
entity; its success scenario has 3
steps or less; its implementation
involves less than 5 classes.

Average More interface design and touches 10 12 120

2 or more database entities;
between 4 to 7 steps; its
implementation involves between 5
to 10 classes.

Complex Involves a complex user interface 15 4 60

or processing and touches 3 or
more database entities; over seven
steps; its implementation involves
more than 10 classes.

Total UUCW 220

Figure 6: Computing UUCW.

UAW
In a similar manner, the Actors are classified as Simple, Average or Complex based
on their interactions.
Actor Type Description Weight

Simple The Actor represents another 1

system with a defined API.

Average The Actor represents another 2

system interacting through a
protocol, like TCP/IP.

Complex The Actor is a person interacting 3

via an interface.
Figure 7: Actor Classifications.
The UAW is calculated by counting the number of actors in each category,
multiplying each total by its specified weighting factor, and then adding the
products.

Actor Type Description Weight Number of Actors Result

Simple The Actor represents 1 8 8

another system with a
defined API

Average The Actor represents 2 12 24

another system
interacting through a
protocol, like TCP/IP

Complex The Actor is a person 3 4 12

interacting via an
interface.

Total UAW 44
Figure 8: Computing UAW.
Finally, the UUCP is computed by adding the UUCW and the UAW. For the sample data used
in the figures, the UUCP = 220 + 44 = 264.

Productivity Factor
The Productivity Factor (PF) is a ratio of the number of man hours per use case point based
on past projects. If no historical data has been collected, a figure between 15 and 30 is
suggested by industry experts. A typical value is 20.

Final Calculation
The Use Case Points is determined by multiplying all the variables:
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.

Caveats
The Use Case Points estimate tends to be high when compared to human experts. This might
be a good thing since many software projects are late, but, the estimate may still be too
high. In order to produce accurate results, the variables in the equation need to be adjusted
and tweaked – especially in the beginning.
 The number of steps in a scenario affects the estimate. A large number of steps in a
use case scenario will bias the result towards complexity and increase the Use Case
Points. A small number of steps will bias it towards simplicity. Sometimes, groups of
steps can be reduced to a fewer number without sacrificing the business process.
Strive for a uniform level of detail but don’t force a use case to conform to the
estimation method.
 Including and extending use cases increases the complexity. Count these as a single
use case.
 The number of actors in a use case also affects the estimate. If possible, generalize
the actors into a single superactor. This reduces the complexity without affecting the
use case. On the other hand, don’t force a generalization where none exists.
 The values for the Technical and Environmental Factors need to be adjusted over
time as actual data is obtained. The more projects that employ Use Case Points for
their estimations will yield more accurate values for the perceived values.
 Compare the Use Case Point estimate with a human expert’s estimate. Where there
is disagreement, err on the side of the human expert and adjust the Use Case Point
factors accordingly.
 The Productivity Factor can only be obtained over time. Track the time spent
designing and implementing the use cases and adjust the Productivity Factor
accordingly.

Conclusion
Use Case Points have the potential to produce reliable results because its estimates are
produced from the actual business processes – the use cases - of a software application.
Additionally, in many traditional estimation methods, influential technical and environmental
factors are often not adequately given enough consideration. Use Case Points includes and
abstracts these subjective factors into an equation. When tweaked, over time, Use Case
Points can provide estimates that are very reliable.

Project Estimation using Use Case Metrics

Enterprise Architect provides a comprehensive project estimation tool that calculates effort
from use case and actor objects, coupled with project configurations defining the complexity
of the work environment. This method is based on Karner's Use Case Points Method, with
several variations noted below. You can also produce a metrics report containing the project
estimation analysis to incorporate into your project documentation. An example is here.

Before estimating project size, you will first need to configure the technical and
environmental factors (see menu item Configuration - Metrics and Estimation Types - TCF
and ECF values). For both TCF (technical complexity factor) and ECF (environment
complexity factor), an editable table contains a list of factors influencing project productivity.
A weight is associated with each factor, reflecting how much that factor relatively affects
productivity; a weight is irrelative to a project. The supplied factors and their associated
weights are defined by the Use Case Points Method, although they may be adjusted to suit a
project's specific needs. For most purposes, the only table column needing adjustment will
be 'Value', which indicates the degree of influence a particular factor holds over the project.
As a suggested gage, a value of '0' indicates no influence, a '3' indicates average influence,
and a '5' indicates strong influence.

As you build your project using UML use cases to describe the proposed functionality, you
should assign a rating to each use case:
  Easy (5 points): The use case is considered a simple piece of work, uses a simple
user interface and touches only a single database entity; its success scenario has
less than 3 steps; its implementation involves less than 5 classes
 Medium (10 points): The use case is more difficult, involves more interface design
and touches 2 or more database entities; its success scenario has between 4 to 7
steps; its implementation involves between 5 to 10 classes
 Complex (15 points): The use case is very difficult, involves a complex user interface
or processing and touches 3 or more database entities; its success scenario has over
seven steps; its implementation involves more than 10 classes

The above are different accepted methods to assign complexities, but serve as rough
guidelines. If you are writing an application with no persistence but complex processing, you
will have to use your judgment to assign complexity ratings.
While building the use cases, note that you can also assign them to Phases (e.g. 1.0, 1.1)
and later filter your estimate based on Phase. You can also enter free text into the Tag field
of a use case and filter the estimate based on tag information (e.g. <URGENT>).
Karner's UCP method also calculates project effort by considering project actors, and their
contributing complexity. There is an option to include actors in the estimation calculation; by
default, only use cases are considered. If project actors are also included, make sure their
complexity has been assigned by some method; rough guidelines to this assignment are
supplied below:
 Easy: The actor represents another system with a defined API
 Medium: The actor represents another system interacting through a protocol, like
TCP/IP
 Complex: The actor is a person interacting via an interface.

Once you have set up the use cases, actors and environment, highlight the package in the
project browser whose contents you would like to estimate; for the entire project, select the
root view. Next, select Project - Use Case Metrics from the menu. The following screen will
appear:
This details the complexity information for your project:
1. The technical complexity factor is calculated from the values you set
2. The environmental complexity is calculated from the values you set
3. The unadjusted use case points (UUCP)= the sum of use case complexity ratings*
4. The UUCP are multiplied together with the TCF and ECF factors to produce a weighted Use
Case Points number (UCP)
5. The resultant number is multipled out with the default hours per UCP to produce a final
estimate
6. The average hours per easy, medium and difficult use case is also displayed
* Although Karner's UCP method recommends excluding included and extending use cases in
this count, Enterprise Architect considers all use cases in its calculation. If these use cases
require functionality to be developed, the effort still exists and should be factored.
A critical factor is the 'Default Hours' variable - which is best defined using experience with
similar projects. Although the EA default is set to 10 hours, this variable could easily exceed
30 hours, depending on the environment.
The best way to accurately configure a new project to your unique environment is by
considering the use cases of completed projects. After configuring a completed project as
instructed above, and running a metrics report, the available factors can be fine-tuned to
yield an estimate matching the actual hours. Then, you can begin using these figures as your
baseline.
Note that a good sanity check is to look at the 'Ave Hours per Use Case' figure: if you believe
you can build an easy use case in the time allowed (including your procedures of design,
testing, documentation, review, etc.) and the medium and difficult likewise, then you are on
the right track.
Don't expect a magic answer to the question 'how much?' or 'how long?' - collect some
statistics and experience to guide estimates of new projects.

Use Case Points Method

The Use Case Points Method (UCPM) is an effort estimation algorithm proposed by Gustav Karner and reported in
[1] that employs Use Cases as a representation of system complexity based on system functionality. The steps in the
application of the UCPM are explained below. This is the method as originally reported. Readers should be aware
that some problems with the original method have been reported, but for completeness it is fully described. For the
purposes of estimation in procurement this method has been simplified.

Learn a lot more about simplifications to this method by downloading the appropriate resource from the literature
survey.

Method summary
• Identify, classify and weight actors

• Identify, classify and weight use cases

• Identify and Weight Technical Factors

• Identify and Weight Environmental Factors

• Converting Points into Time

• Calculate Adjusted Use Case Points

Identify, classify and weight actors

The basic method can be summarised as first requiring the identification of actors
who will interface with the system. Actors are classified as either people or other
systems. Each identified actor is given a weighting from 1-3 that corresponds to
simple, average, and complex. Human actors are always classified as complex and
receive a weighting of 3. Systems to which the new system will interface (legacy
systems) are either simple or average depending on the mechanism by which they
are addressed.

Actor type Definition Factor

Simple Program interface 1
Average Interactive, or protocol-driven interface 2
Complex Graphical interface (Human) 3

The specifier of the system sums the actors in each category and multiplies them by the appropriate factor. The
results are then summed together.

E.g.:
2 simple * 1 = 2

2 average * 2 = 4

3 complex * 3 = 9

Total actor weight = 2 + 4 + 9 = 15

Identify, classify and weight use cases

After calculating the Total actor weight, it is necessary to create a use case model
and to then classify each use case as being either simple, average or complex. The
method specifies ignoring use cases that are associated through the extend or
include stereotypes. There are two suggestions as to how this classification can be
done. Either on the basis of the number of transactions in a use case, or on the
basis of the number of analysis classes into which the use case will resolve. A
transaction is defined according to the standard definition of a set of atomic
activities either entirely performed or abandoned.

Use case type Definition Factor

Simple 3 or fewer transactions 5
or < 5 analysis classes
Average 4 to 7 transactions 10
or 5 – 10 analysis classes
Complex More than 7 transactions 15
or > 10 analysis classes

E.g.:
5 simple * 5 = 25

4 average * 10 = 40

0 complex * 3 = 0

Total use case weight = 25 + 40 + 0 = 65

The Total actor weight and the Total use case weight are then summed to produce the Unadjusted Use Case Points
(UUCP) score.

15 + 65 = 85

UUCP = 85

Identify and Weight Technical Factors

This calculation makes provision for the overall complexity of the project and, to
some extent, the experience level of the staff. To do this it is necessary to go
through the list of possible technical factors and give each one a rating on the scale
of [0 – 5]. A ‘0’ rating means the factor is irrelevant to the project, a ‘5’ rating
means it is essential. Then for each factor it is necessary to multiply its score by its
weight and sum the results. The final result is then substituted into a Technical
Complexity Factor calculation.

Technical Factor Technical Factor Weight Value Weight * Value

Number Description
T1 System will be distributed (released) 2 0 0
T2 Performance objectives 1 3 3
T3 End-user efficiency 1 5 5
T4 Complex internal processing 1 1 1
T5 Code must by reused 1 0 0
T6 Easy to install .5 5 2.5
T7 Easy to use .5 5 2.5
T8 Portable 2 0 0
T9 Easy to change 1 3 3
T10 Concurrent 1 5 5
T11 Includes special security features 1 3 3
T12 Provides direct access for third parties 1 5 5
T13 Special user training facilities are required 1 0 0

E.g.:
TFactor = Sum of Weight * Value column

TFactor = 30

Technical Complexity Factor (TCF) = 0.6 + (0.01 * TFactor)

TCF = 0.9

Identify and Weight Environmental Factors

This calculation makes explicit provision for the experience of the people on the
project. As described in the section on Technical Complexity Factors. Each factor is
rated on a scale from [0-5]. Again, ‘0’ means the factor is irrelevant to the project,
‘5’ means it is essential. Each factor is calculated by multiplying its score by its
weight and producing a sum of the results. The final result becomes the
Environmental Complexity Factor calculation.

Environmental Factor Environmental Factor

Weight Value Weight * Value
Number Description
EF1 Familiar with RUP 1.5 1 1.5
EF2 Application experience 0.5 1 0.5
EF3 Object-oriented experience 1 1 1
EF4 Lead analyst capability 0.5 5 2.5
EF5 Motivation 1 5 5
EF6 Stable requirements 2 5 10
EF7 Part-time workers -1 0 0
EF8 Difficult programming language -2 2 -4

E.g.:
EF-Factor = Sum of (Weight * Value) column

EF-Factor = 16.5

Environmental Complexity Factor (ECF) = 1.4 + (-0.03 * EF-Factor)

ECF = 0.905

Calculate Adjusted Use Case Points

Finally Use Case Points are calculated using this formula:

UCP = UUCP * TCF * ECF

E.g.:
UCP = UUCP * TCF * ECF

UCP = 80 * 0.9 * 0.905

UCP = 65.16 (65)

Converting Points into Time

Schneider and Winter [1] report Karner’s recommendation that each UCP should be converted into 20 hours of work.
They further report a suggested improvement to the method that ranges the amount of time to be allocated per use
case to between 20 and 28 hours.

Using the figure of 20 hours/UCP, a project of 61 UCPs would take 1220 hours. Given a 35 hour working week, this
project would be estimated to take 35 weeks if one person were working on it. Schneider and Winter recommend
following Brooks [2] by adding a contingency to account for the complexity of working in teams that they estimate to
be 25%. They caution that their results are based on a small amount of research, without making that research
explicit, and solicit other researcher’s results in their book.
[1.] Schneider, G. and J. Winters, Applying Use Cases - A Practical Guide. 1998: Addison Wesley Longman, Inc.

[2.] Brooks, F.P., No Silver Bullet. Information Processing, Elsevier Science Publishing, 1986

Problems with the Use Case Points Method

The UCPM can be considered an evolution of earlier methods (COCOMO and FPA). What might have been
appropriate to an earlier generation of programming languages becomes increasingly difficult to justify. Employing
the UCPM implies the system development house has a passing commitment to employing Use Cases and most likely
also to object oriented programming. If this is true, it is difficult to assign any meaningful values to some of the pre-
defined complexity factor modifiers such as “Easy to use” from Technical Factors, or “End-user efficiency” from
Environmental Factors. In fact, it is hard to believe that anyone specifying a new system would state that ease of use
was unimportant, or that the new system should not contribute to end-user efficiency. Given that the answer to many
of these factors is invariably ‘yes – important’ and attracting the corresponding weighting, it is no longer purposeful
to record them. These conclusions are supported by other researchers [1, 2]. Eliminating the need for Technical and
Environmental modifiers immediately simplifies the method and provides a firm break with the approaches that
proceeded the UCPM.
Degrees of Use Case Abstraction
It is not immediately evident from the UCPM as to which Use Cases should count towards an estimate. Schneider and
Winter, perhaps following Karner, suggest that it is unnecessary to count Use Cases associated with extend and
include stereotypes, although it is not made clear why this should be so. The problem is one of abstraction and
representation [3-5] of Use Cases being performed differently by different developers. One developer may represent
Use Cases at a very high level of abstraction, while another may include too much detail, tending to what has been
termed “functional decomposition”. For this reason, two developers modelling the same system could potentially
create identical models, the only difference being the amount of detail (decomposition), but an application of the
UCPM would give very different results. Ivor Jacobson [6] the father of Use Cases, believes they should represent
functionality from the perspective of the end-user, Cockburn [3], develops a good system of classification for Use
Cases, and Kulak [4] discusses the subject of differing degrees of detail in Use Case representations. In “Towards a
Requirements Formalism in Procurement”, Merrick [7] attempts a reconciliation of the contradictions in the
abstraction of Use Case representation, that seeks to resolve the potential contradictions and unforeseen results that
could otherwise result.
Use Case Complexity
The UCPM as it is defined relies on a measure of Use Case complexity being computed either from a transaction
count, or from a count of analysis classes [8]. Neither of these methods are satisfactory. In the first instance, there is
neither a workable definition of what constitutes a transaction, nor is there likely to be the raw data available upon
which a count could be made. Conceivably, transactions could be counted if the use cases were completely
articulated, but this is not the case during the period when an initial effort estimate is being calculated [7]. Another
fundamental problem with this approach is the fact that each Use Case generally represents one single success thread
(although alternative success threads are permissible), which renders this complexity measure unworkable.

Determining complexity on the basis of the number of analysis classes that are produced by each Use Case is also
flawed. At the point where an initial effort estimate is being made, the number of analysis classes is unknown. The
determination of the number of analysis classes is a task undertaken later in the development lifecycle. Apart from
this drawback, counting analysis classes depends on the definition of the transformation that takes Use Cases as an
input and produces analysis classes as an output. This transformation is ill-defined by Jacobson [6, 9] or in the RUP
literature [10]. Therefore it is left to the developer to determine a repeatable process for the transformation of Use
Cases to analysis classes. One sensible approach to this issue is to adopt the Model-View-Controller design pattern,
reported in [11], however adopting this pattern as the basis of the transformation implies the invariable specification
of precisely 3 analysis classes per Use Case, many of which turn out not to be unique. Therefore it is unclear how
adopting the number of analysis classes per Use Cases can be used as a measure of complexity.

In the original UCPM there are considered to be three classifications of Use Case complexity, simple, average, and
complex. In the simplification of the method proposed for early effort estimation, this is reduced to just two
categories; simple and complex.

Modifications and simplifications to the UCPM for the purpose of early effort estimation are discussed in the next
section.

[1.] Ribu, K., Estimating Object-Oriented Software Projects with Use Cases, 2001, University of Oslo, Norway Oslo
http://www.stud.ifi.uio.no/~kribu/oppgave.pdf
[2.] Anda, B., E. Angelvik, and K. Ribu. Improving Estimation Practices by Applying Use Case Models. in 4th
International Conference on Product Focused Software Process Improvement, Rovaniemi, Finland, December 9 - 11,
2002, pp. 383-397, LNCS 2559, Springer-Verlag, 2002. 2002. Profes, Finland
http://www.simula.no/publication_one.php?publication_id=500

[3.] Cockburn, A., Writing Effective Use Cases. 2001, Upper Saddle River, N.J.: Addison Wesley Longman

[4.] Kulak, D. and E. Guiney, Use Cases - Requirements in Context. 2000, Upper Saddle River, N.J.: Addison
Wesley Longman

[5.] Firesmith, D.G., Use Cases: the Pros and Cons, 2002 http://www.ksc.com/article7.htm

[6.] Jacobson, I., Jonsson, P., Christerson, M., Overgaard, G., Object-Oriented Software Engineering - A Use Case
Driven Approach.ACM Press Series. 1992, Upper Saddle River, N.J.: Addison Wesley Longman

[7.] Merrick, P. Towards a Requirements Formalism in Procurement. in UKAIS 2003. 2003. Warwick, England

[8.] Schneider, G. and J. Winters, Applying Use Cases - A Practical Guide. 1998: Addison Wesley Longman, Inc.

[9.] Jacobson, I.E., M.;Jacobson,A;, Object Advantage - Process Re-engineering with Object Technology. 1995:
Addison Wesley

[10.] Kruchten, P., The Rational Unified Process - An Introduction. 2000, Upper Saddle River, N.J.: Addison Wesley
Longman

[11.] Gamma, E., et al., Design Patterns - Elements of reusable object-oriented software. 1995, Upper Saddle River,
N.J.: Addison Wesley Longman

Simplification of the UCPM

There is evidence to suggest the UCPM is too complicated, and perhaps in its original form, unworkable. The
definition of the method owes much to the earlier formulations of COCOMO and of Function Point Analysis. The
objective of simplifying the UCPM is to make it suitable for quick, order of magnitude calculations that are suitable
for use in procurement prior to the commencement of the official software engineering lifecycle. The following
simplifications have been tested in the Learning and Skills Council case study and found to be workable.
Actors
Reduce the number of possible actor types from 3 to 2. Actors can be considered either human (complex) or
interfaces (simple). In studies it has been found that the terminology of Primary (human) actor and Secondary
(interface) actor was more acceptable to the participants, and has been adopted.

Use Case Types

Adopt an approach which ranks Use Cases as being either simple or complex.

A simple Use Case is defined as one that that either creates a new entity instance, searches over an entity and returns
a specific entity instance (or a set of matching entity instances), or one that modifies an entity instance (this includes
deletion). Collectively simple Use Cases are termed NSM, which stands for New, Search, and Modify. This is an
object oriented approach to what have been termed CRUD Use Cases (Create, Read, Update and Delete). Experience
suggests these Use Cases usually exist over every entity (where an entity is considered equivalent to a logical
database table). Problems can arise when this approach is applied to a physical database schema. One quick test to
identify logical entities is whether they refer to things that will be directly manipulated by a Primary actor, and for
which a user interface will be required.

Complex Use Cases are then defined as everything that is not a simple Use Case (not NSM). In simple systems these
are often reporting, or management information Use Cases (Management Information System functionality (MIS))
 Component Weight
Primary actor 3
Secondary actor 1.5
Simple use case 5
Complex use case 10

Initial Calibration of the Simplified UCPM

After a measure of complexity expressed in Use Case Points has been arrived at, it must be multiplied by the number
of hours it is envisaged it will take to build the system. Schneider and Winter have suggested using a figure around 20
hours/UCP, but experience shows that applying the Inflatable Facade approach to Use Case identification this figure
is likely to be far too high.

A simple approach is to contemplate how much the customer expects to pay for the system, and divide this figure (a
‘price to win’ [1]) by the number of UCPs. This approach is crude, but may be sufficient to the task.

The preferred approach is to reverse engineer a system that has already been built using the same rules by which the
new system has been defined. Only the documentation available at the beginning of the project should be used. It is
useful to consult the existing database schema taking care to count only logically significant tables. By this method it
is a prerequisite that the amount of time spent on the original project is known. When this has been done, it is a
simple matter to divide the total time by the UCP measure to arrive at the number of hours needed by the organisation
in question to deliver a single UCP’s functionality. This metric can then be applied to the new project.

It is helpful if the control project was not a project in which a great deal of learning was taking place as this
represents an increased overhead, that presumably will not apply. Ideally, a project should be chosen to reverse
engineer built by the team earmarked to build the new system. This may not always be possible as team composition
changes, but nonetheless it is the ideal. Bigger teams build bigger projects, and bigger teams have more
communication overheads that normally require more formal modelling. The efficiency of a single programmer
working on his own is likely to be greater than that achieved by a larger team. Finally, this approach does not factor
in what code/components can be reused. Code that can be easily reused to satisfy a Use Case that was not available
during the control project will allow the project to be delivered more quickly then would otherwise be the case. This
is not a bad thing, as it is better to err on the side of being quicker rather than slower.

Continuous Calibration
Whichever approach is employed to determine the initial time to Use Case Point satisfaction, it remains to put in
place the mechanism to capture how much time is actually spent and to compare this with the estimate to allow the
figures to be used to calibrate the method for future use. It is tempting to be satisfied with simply collecting time
against a project, but this is not sufficient to ensure the algorithm can be finely adjusted. The algorithm has 5 numbers
that can be adjusted:

• time to UCP satisfaction

• primary actor weight

• secondary actor weight

• simple Use Case weight

• complex Use Case weight

It is recommended that time should be recorded against the following broad categories: programming time, non-
programming time.
Within programming time, the following categories of time recording should be implemented:

Programming time types

• Access/security - time spent creating data and routines that match a user with the functionality to which they are
entitled.
• Interfaces - time spent providing access to legacy systems or external systems like text messaging, email engines or
legacy system interfaces.
• NSM Use Cases to include time spent on database implementation.
• Complex Use Cases (non-NSM)
Recording this information allows the weightings of Primary Actors, Secondary Actors, Simple Use Cases and
Complex Use Cases to be adjusted. Note that the time spent interfacing to Secondary Actors can be volatile
depending on the nature of the specific interface. Special attention should be paid to the implementation of Secondary
Actors.
An organisation following MVC might decide to further break the Simple and Complex Use Cases down into time
spent on Model, View and Controller Components.
Semi-Programming time types
An organisation not implementing MVC will probably benefit from recording time against:
• Static page design - time spent working up templates for static pages. working up templates for dynamic pages.
• Glue - time spent marrying the working prototype with the graphic templates. This may include time to incorporate
static pages with the dynamic model.

Other time types

Analysis and Design - things like creating the paper structural skeleton

Project Management - meetings, discussions, document writing

Environment - setting up databases on production servers, setting up web servers, anything to do with the set up like
liaising with Pipemedia.

Testing - ensuring the system works as expected

Once actual time data is available, during the second iteration of the application of the process, the organisation
should perform a new calculation whereby the total UCPs are compared with the total programming time. Non-
programming time can then be expressed as a function of programming time.

An example is in order:

Company A describes a system that is 100 UCP. They predict it will take 2 hours to build the system. When the
system is built it is found the system has taken 150 hours rather than the predicted 200 hours. It is further found that
of the 150 hours, 75 hours were taken up in programming tasks, and 75 hours taken up in other activities.
The technical architect responsible for effort estimation adjusts the algorithm by using a new figure of .75 hours (45
minutes) per UCP for programming time and a non-programming factor of 100%. The fine tuning factors below are
not adjusted.

• primary actor weight

• secondary actor weight

• simple Use Case weight

• complex Use Case weight

Company A receives a new invitation to tender for a system that is defined as being 150 UCP. The calculation that
ensues is below:

150 x .75 x 2 = 225 hours

This becomes the effort estimate for the new system. By recording programming time types, the fine tuning weights
can be used to further adjust the algorithm.
Note that the estimated time may be made public or kept private in the disclosure of the price to the customer which
may be done for commercial reasons.

[1.] Fenton, N. and S.L. Pfleeger, Software Metrics - A Rigorous & Practical Approach. 1996: Thomson Computer
Press

How to Prepare Quotation Using Use Case Points

By Shivprasad koirala

How to prepare quotation using Use Case Points. 

Introduction

"You can not plan if you can not measure, and if you fail to plan,
you have planned to fail."

Quotation: It's a financial document send from supplier to customer regarding service to be
provided. It's also called as temporary financial document for negotiations. "A statement of
price, terms of sale, and description of goods or services offered by a supplier to a
prospective purchaser, a bid. When given in response to an inquiry, a quotation often is
considered an offer to sell."
Definition reference from here.
Quotation is one of the important aspects of software cycle. Any prediction less or more will
affect the project a lot. Let's look at how basically day to day businesses manage their ways
of handling quotations.
“Mr. Harry gets a contract of delivering 10 tons of steel from place “X” to place “Y”. He has 2
trucks, each can carry 5 tons each. Place “X” and place “Y” are 1 KM (Kilometer) apart.”
So, here’s Harry’s calculations on experience basis. One truck if delivering 5 tons for 1 KM is
500$. So for two trucks, it is 1000$. So the quotation is 1000$. Just wondering, can we do
that with software industry. There are 100 modules, and the company has 5 programmers.
Every programmer can complete 20 modules in 3 months. A programmer's salary is 1000$.
So, 5 X 1000 X 3 = 15000$. The truck quotation calculation is more confident than software
quotation, why?
In trucks' quotation, Harry had followed the following process:
 Harry had measurement of his work: 10 tons to be delivered. 1 KM to be traveled.
 Harry knew what effort will be required: 5 tons/per truck/per KM.
 So the quotation: 1000$.

So basically, Harry had measurement of his work. He knew the volume of what he has to
deliver. That’s a problem with software industry. As software industry output is more in to
logical output, it's difficult to measure linearly the effort required to complete a project and
hence the quotation. Software industry has been struggling for the past 40 years to come to
a standard of measurement, and that’s where all the mess is. Many ideas and measurement
methodologies have been proposed by researchers. Each have there own advantages and
disadvantages. Here are some of the measurement methodologies used:
 McCabe’s Measurement of complexity.
  Henry and Kafura’s Information Flow.
 Halstead measurement of complexity.
 Lines of Code (LOC).
 Function Points. (My old tutorial on function points.)
 Use Case Points.

Do not be tensed by some unheard technology described above, it's only provided for
knowledge base. Links are provided for McCabe's complexity, Henry and Kafura's information
flow, Halstead measurement complexity and LOC. I have just mentioned them as they are
old measurement technologies. If any one wants to explore them, see my References
section. This tutorial will look into Use Case Points methodology, its advantages and
disadvantages. So in this article, we will basically go through Use Case Point theory, and
then take up a practical example of a Use Case, and prepare a quotation according to it.

Acronyms and Abbreviation:

Note: have these acronyms in hand always as they are used throughout the
tutorial. Do not be tensed by the acronyms below. They are for reference sake, and
as you proceed ahead with the tutorial, you will have a more clear picture of what
exactly they are.
Table 1.0
Acronym Full form Definition
Use Case Points method is a software sizing and
UCP Use Case Point
estimation based on Use Case document.
A numeric sum of value of actors after giving the
Unadjusted Actor classification and before multiplying the technical
UAW
Weights complexity factor of the system. (When you go through
steps of how to calculate UAW, this will be more clear.)
A numeric sum of value of Use Cases after classifying
Unadjusted Use and before multiplying the technical complexity factor
UUCW
case Weight of the system. (When you go through steps of how to
calculate UUCW, this will be more clear.)
Unadjusted Use
UUCP Sum of UAW and UUCW
Case Points
Application Application programs used for accessing services
API Programming provided by some lower-level module (such as
Interface operating system).
Graphical User A computer terminal interface, such as Windows, that
GUI
Interface is based on graphics instead of text.
Use Case It's an atomic set of activities that are either performed
Transactions entirely or not at all.
Total of all technical factors. See for more details in
Tfactor Technical Factor
Steps in estimation. See table 4.0 for more details.
Technical Factor which defines the complexity of the project. For
TCF Complexity more details, see steps for UCP estimation. TCF is
Factor calculated from Tfactor.
Environment
EF This is multiplying factor.
Factor
Adjusted Use This is the value obtained after multiplying with Efactor
AUCP
Case Points and Tfactor.
Lines of code is a counting metrics to measure the
LOC Lines of Code
volume of a software product.
A programming technology in which program
Object Oriented
OOP components are put together from reusable building
Programming
blocks known as objects. [Glossary]
 Stands for Unified Modeling Language. UML is a
standard notation and modeling technique for
analyzing real-world objects, developing systems, and
Unified Modeling designing software modules in an object-oriented
UML
Language approach. UML has been fostered and now is accepted
as a standard by the group for creating standard
architecture for object technology, OMG (Object
Management Group). [Definition taken from here]
Unadjusted Use
UUCFP Details are provided in this article.
Case Flow Points
A sizing methodology for software projects based on
FP Function Points
functions of the software.

Assumptions:
1. Readers have basic knowledge of how to write Use Cases. This tutorial does not
cover Use Cases and is only limited to estimation by "Use Cases". So if you are
reading this article with out a clear concept of Actor, Role, Scenarios, it's better not
to read.
2. Use Case structure varies from organization to organization which can seriously
impact the estimation. This tutorial has used Alistair Cockburn's template from
Writing Effective Use Cases (**PRE-PUB. DRAFT#3**): Alistair Cockburn Humans
and technology.

Scope
This tutorial is only till understanding Use Case points and does not get in to details of how
to write Use Cases. This article will not concentrate on how to write Use Cases. There are lots
of tutorials on the Internet. And also in the References section of this article, a list is
provided.

History and Definition of Use Case Points

Working in Ericsson in the late 1960s, Ivar Jacobson devised Use-Case Documents. Thanks
to Ivar Jacobson to come out with such a wonderful way of communication by using Use
Case Documents. Later, Use Case Documents became a subset of UML. In 1994, Alistair
Cockburn constructed the 'Actors and Goals conceptual model' while writing Use Case guides
for the IBM Consulting Group. It provided guidance as to how to structure and write Use
Cases. It’s the document which can stand not only for programmer or architect, but also for
the stake holders. It's a document which stands between the Customer and
Programmers/Architects/Business analysts/etc. It also serves as handover when any new
programmer comes in the project. Use Case Document also serves as a valuable input to the
design of software. In short, it serves in the whole life cycle of software development. Karner
identified that this document can also be used to measure and estimate effort. This tutorial
will make a walk through of Karner's work and give one simple example. So, let’s start with
the definition.
Use Case Point is software sizing and measurement based on Use Case Document. "Use Case
Point" is based on work by Gustav Karner in 1993. It was written as a diploma thesis at the
University of Linkoping. This work is a modification of work by Allen Albrecht on function
points.
Steps for UCP (Use Case Points) Estimation

1. Determine the UAW (Unadjusted Actor weight): The first step is to classify all
the actors in to the following classification. Table 2.0 will give you a clear idea
of how to classify the actors. Second column is the litmus test for making a
decision of which type of actor falls in which category. The last column
provides the factor of complexity:

Table 2.0
Litmus test to recognize
Classification Value/Factor
classifications
Simple actors Simple actors are those which 1
communicate to system through API.
Average actors Average actors are recognized if they 2
have the following properties:
o Actors who are
interacting with the system
through some protocol (HTTP,
FTP, or probably some user
defined protocol).
o Actors which are data
stores (Files, RDBMS).
Complex Complex actor is interacting normally 3
through GUI.
2. Determine number of UUCW (Unadjusted Use case Weight): The second step is to
count Use Cases and assign weights depending on number of scenarios and number
of transactions.

Table 3.0
Use Case
Litmus test to decide the Classification Value/Factor
Type
Simple Greater than or equal to 3 transactions 5
Average Between 4 to 7 transactions 10
Complex Greater than 7 transactions 15
3. Determine Total UUCP (Unadjusted Use Case Point): Total UUCP = Total UAW + Total
UUCW.
4. Computing technical and environmental factor: Final step is to take into account
the technical complexity. All technical factors will be assigned a value from 0 to
5 depending on complexity.

Table 4.0
Technical
  Weight Description
factor
t1 Distributed 2 Is the system having distributed
System architecture or centralized architecture?
Does the client need the system to fast? Is
t2 Response time 1
time response one of the important criteria?
End user
t3 1 How's the end user's efficiency?
efficiency
t4 Complex 1 Is the business process very complex? Like
 internal complicated accounts closing, inventory
processing tracking, heavy tax calculation etc.
Do we intend to keep the reusability high?
t5 Reusable code 1
So will increase the design complexity.
Is client looking for installation ease? By
default, we get many installers which create
packages. But the client might be looking
for some custom installation, probably
depending on modules. One of our client
Installation has a requirement that when the client
t6 0.5
ease wants to install, he can choose which
modules he can install. Is the requirement
such that when there is a new version there
should be auto installation? These factors
will count when assigning value to this
factor.
t7 Easy use 0.5 Is user friendliness a top priority?
Is the customer also looking for cross
t8 Portable 2
platform implementation?
Is the customer looking for high
customization in the future? That also
t9 Easy to change 1
increases the architecture design complexity
and hence this factor.
Is the customer looking at large number of
users working with locking support? This will
t10 Concurrent 1
increase the architecture complexity and
hence this value.
Is the customer looking at having heavy
Security
t11 1 security like SSL? Or do we have to write
objectives
custom code logic for encryption?
Does the project depend in using third party
controls? For understanding the third-party
Direct access
t12 1 controls and studying its pros and cons,
to third parties
considerable effort will be required. So, this
factor should be rated accordingly.
Will the software from user perspective be
User training so complex that separate training has to be
t13 1
facilities provided? So this factor will vary
accordingly.
5. Equation for Tfactor = sum(T1....T13)
6. TCF (Technical Complexity Factor): TCF = 0.6 + (0.01 * Tfactor).
7. EF (Environmental Factor): There are other factors like trained staff, motivation
of programmers etc. which have quiet a decent impact on the cost estimate.

Table 5.0
Environmental
  Weight Description
Factor
e1 Familiarity with 1.5 1.5
project
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.
 e2 Application 0.5 How much is the application experience?
experience
e3 Object-oriented 1 As use-case documents are inputs to object
programming oriented design, it's important that people
experience on the project should have basic knowledge
of OOP concepts.
e4 Lead analyst 0.5 How is the analyst who is leading the
capability project? Does he have enough knowledge of
the domain?.
e5 Motivation 1 Are the programmers motivated for working
on the project? Instability in the project will
always lead to people leaving half way
through their source code. And the hand
over becomes really tough. This factor you
can put according to how software industry
is going on? Example, if the software
market is very good, put this at maximum
value. More good the market, more the jobs
and more the programmers will jump.
e6 Stable 2 Is the client clear of what he wants? I have
requirements seen clients' expectations are the most
important factor in the stability of
requirements. If the client is of highly
changing nature, put this value to
maximum.
e7 Part-time Staff -1 Are there part-time staff in projects, like
consultants etc.?
e8 Difficult -1 How much is the language complexity,
programming Assembly, VB 6.0, C++, C etc.
language
8. Efactor = SUM(e1...e8).
9. Calculating Environmental Factor = EF = 1.4 + (-0.03 * Efactor).
10. AUCP (Adjusted Use Case Points). Finally, calculating the Adjusted Use case points:
AUCP = UUCP * TCF * EF
11. Multiplying by Man/Hours Factor: AUCP * Person/Hours/AUCP.

Karner[13] proposed a factor of 20 staff hours per Use Case point for a project
estimate. While Sharks states that field experience has shown that effort can range
from 15 to 30 hours per Use Case point.

Schneider and Winters proposed number of staff hours per Use Case point depends
on the environmental factors. The number of factors in E1 through E6 that are below
3 are counted and added to the number of factors in E7 through E8 that are above 3.
If the total is 2 or less, the general idea is to use twenty staff hours per UCP; if the
total is 3 or 4, use twenty-eight staff hours per UCP. If the number exceeds 5, it is
usually recommended that changes should be made to the project so the number can
be adjusted, because in this case, the risk is unacceptably high. Another possibility is
to increase the number of staff hours to thirty-six per Use Case points.

Sample project scope (Sample Data Entry Project):

Let's start with a sample fiction project. Here's the scope of the project. TNC company till
now was using manual way of maintaining its customer database and there credit card
information. Data entry operator manually validates credit card information from external
payment gateway. They maintain customer code, customer name, customer address,
customer phone and validated customer credit card information in Customer registry.
Customer code is unique for a customer. So, TNC manually checks for the validations and
enters in the customer registry. TNC wants the data entry project to be automated. TNC is
looking for the following automation:
  Customer code assigned should be checked for uniqueness automatically.
 Customer code should not exceed 8 length.
 Credit card validation should be automatic for the current system. TNC has already
given the API documentation of how to interact with the third party payment system.
 Credit card length should not exceed more than 10 length.
 Data entry operator should be able to add/update/delete customer information.
 The database will be in the TNC head office and only data entry operators will be
allowed to use the data entry software.
 Software should work on Windows platform. At this moment, TNC has Windows 2000
client installed in all computers.

Writing Use Case for Sample Data Entry Project:

I have used Alistair Cockburn's template for the "Use Case point" example. Use Case
template varies from person to person, project to project, and organization to organization. I
found Alistair's template to be complete, so just took it. But there's no hard and fast rule
that you have to follow this template. What will matter is what steps you write in the Use
Case.
Use Case Transactions: It’s an atomic set of activities that are either performed
entirely or not all. What is a Use Case transaction and what’s not: just see if the
transaction is adding any business value or else do not include it as a transaction.
Example: the user switches on the computer, user clicks on add button or any GUI,
are not valid business transaction steps. But the customer code validated for credit
card information is a valid business transaction. Use Case points are heavily
affected by the way the Actors and their transactions are identified. So a Use Case
Document should be written by predefined guidelines, uniformly in a project. Just
take a meeting with the whole project team before starting writing Use Cases. The
depth of the Use Case Document will affect estimation by 40%.

Table 6.0
Use Case # DATAENTRYPROJECTCUST-1009
Use Case name Maintain Customer

Description This Use Case depicts full maintenance of customer from project
"Data Entry".
Scope and level  Data Entry System (Internal)

 Credit Card System (External)

Level User Goal Level (If this property is not understood, look at the
reference for the book Writing Effective Use Cases (**PRE-PUB.
DRAFT#3**): Alistair Cockburn Humans and technology)
Primary and secondary Data Entry operator.
actors
Stakeholders and interests
Trigger Data entry operator clicks on menu: "Add New Customer"
Preconditions  Data entry operator should be logged in.

 Data entry operator should have access to Internet.

Assumptions Customer information received is entered manually. No
automated import routine is in the scope.
Failed End condition  Customer is not added to database and appropriate
error message is displayed.
 Customer code already existing in the customer
database.
  Customer code length limit is exceeded.
 Customer credit card limit is exceeded.

 Customer credit card validation failed with the payment

gateway.
Action Add new customer
Main success scenario (or 1. Data entry operator receives customer information.
basic Flow): 2. Data entry operator enters following information:
o Customer code
o Customer name
o Customer address
o Customer phone
3. Customer code is checked if it exists in Customer table.
o If the customer code is existing then "Duplicate
Customer Code" error is raised.
o If the customer code is more than 8 length, then
"Customer code length limit crossed" error is
raised.
4. After step 3 is passed OK. Data entry operator enters
credit card information. If the credit card length is more
than 10 length, then "Credit card length limit crossed"
error is raised.
5. Credit card information is send to the external payment
gateway. Appropriate APIs of the external payment
gateway will be used for validity.
6. External payment gateway returns "OK" if credit card is
validated or else will return "NOT VALID" flag.

7. Data entry operator then adds the customer in

database.
Alternate scenario Update Existing Customer
(Extensions): 1. Data entry operator enters customer code to retrieve the
customer who has to be updated.
2. Data entry operator makes appropriate changes to the
customer information. All steps and business validation
from 1 to 6 of Add new Customer is repeated.

3. Data Entry operator updates the customer information.

Alternate scenario Delete Existing Customer
(Extensions): 1. Data entry operator enters customer code to retrieve the
customer who has to be deleted.
2. Data entry operator deletes the customer. Data entry
operator is alerted "Are you sure you want to delete the
Customer?”
o If the data entry operator clicks "Yes", then the
customer is deleted from the database.

o If the data entry operator clicks "NO", no action

is taken.
Success Guarantee (Post  Customer is added to Customer database.
conditions):  Customer is updated to Customer database.

 Customer is deleted from Customer database.

Special Requirements  
(including business rules):
Technology and Data If credit card payment gateway API changes, the interaction of
Variations List: the data entry customer module will have to be changed
 accordingly.
Frequency of occurrence:  
Notes and Open Issues:  

Applying Use Case Points:

Let's start applying Use Case Points to the above given document.
 Determining Unadjusted Use Actor Weights (UAW): In this project, we have
identified only one actor “Data Entry Operator”. The upper Actor (data entry
operator) is complex as data entry operator will be interacting through GUI. So
UAW=3 as per Table:2.0.
 Determine number of UUCW (Unadjusted Use case Weight): There are 12
transactions [Adding also the alternative flows] in Table 6.0 Use Case. So the above
Use Case is complex according to Table:3.0. So referring Table:3.0, UUCW=15.
 Now calculating the total UUCP = 15 + 3 = 18.
 Determining the technical factor

Table 7.0
Weighted
  Technical factor Weight Value Explanation
Value
t1 Distributed 2 1 2 Simple two tier architecture is
System decided.
t2 Response time 1 4 4 Speed is of importance as the
data entry operator has to
enter data quiet fast.
t3 End user efficiency 1 3 3 Data entry operator has high
user efficiency.
t4 Complex Internal 1 2 2 Its simple entry screen and
Processing no business process has been
scoped by the client. Only
credit card check and
duplicate customer code is
the business check.
t5 Reusable Code 1 1 1 No reusability as project is
small and customer is not
looking for any further
changes for at least two
years.
t6 Installation Ease 0.5 0 0 TNC has good in house
development team, and
installation problems will be
handled by them. Technology
thought is C#, and .NET
setup wizard will be enough
to make the installation
process easy.
t7 Easy use 0.5 4 2 Yes, data entry operator has
to have user friendly menus
and shortcut keys for fast
entry of data.
t8 Portable 2 1 2 TNC has Windows 2000 client
as specified in the scope
document.
t9 Easy to change 1 0 0 None specified by client.
 t10 Concurrent 1 0 0 Client has not clarified about
this issue as such in the
scope document. So assumed
least concurrent.
t11 Security 1 0 0 None specified by client. Even
objectives credit card information will be
passed with out encryption.
t12 Direct access to 1 3 3 Using the credit card check
third parties API.
t13 User training 1 0 0 The screen is simple, and
facilities data entry operator can
operate without any training.
Total 19
 Depending on the table, calculating the Technical Factor: TCF = 0.6 + (0.01 *
Tfactor) = 0.6 + (0.01 * 19) = 0.79
 Calculating environmental factor

Table 8.0
Environmental Weighted Explanation for the value
  Value Weight
Factor Columns assigned
e1 Familiarity with 5 1.5 7.5 It’s a simple project, so
project familiarity with project is not so
much needed.
e2 Application 5 0.5 2.5 It's a simple application.
experience
e3 Object-oriented 5 1 5 Every one has good OOP
programming knowledge.
experience
e4 Lead analyst 5 0.5 2.5 It's a simple project; no lead
capability analyst needed till now.
e5 Motivation 1 1 1 Motivation is little down as
programmers are reluctant to
work on the project because of
its simplicity.
e6 Stable 4 2 8 Client is very clear with what he
requirements wants?
e7 Part-time Staff 0 -1 0 No part time staff.
e8 Difficult 3 -1 -3 C# will be used. And most of the
programming programming guys are new to
language. C# and .NET technology.
 According to [Kirsten Ribu Master of Science Thesis], Environmental factor plays a
very important role in the estimation. A slight variation will increase the Use Case
point by a very, very drastic amount. Even small adjustments of an environmental
factor, for instance by half a point, can make a great difference to the estimate.
Difference of 3 to 2.5 increased the estimate by 4580 hours, from 10831 to 15411
hours, or 42.3 percent. This means that if the values for the environmental factors
are not set correctly, there may be disastrous results -- Sources [Kirsten Ribu Master
of Science Thesis]. Do see links below.
 Using formulae for calculating EF = 1.4 + (-0.03 * Efactor) = 1.4 + (-0.03 * 23.5) =
0.695.
 Calculating AUCP = UUCP * TCF * EF = 18 X 0.79 X 0.695 = 9.88 approx = 10 Use
Case Points. I have done the approximation as its only creates 3 to 4 hours of
difference.
 Calculating according to Karner, i.e., 20 staff hours per Use Case points = 10 X 20 =
200 hours for the total project.
  If programmer works for 8 hours for a day, then 340/8 = 25 days.
 Calculating according to Schneider and Winters, from e1 to e6 there are only 3
properties that are below 3. And from e7 to e8, there are none whose value is above
3. So the total is 3. We use 28 staff hours. 10 X 28 = 280 hours. If programmer
works for 8 hours, then 35 days. If this step is not understood, look at the steps
defined in theory of Use Case points.

If we apply sixth sense, we will find Karner approach is coming to round about figure.
It really depends what you want to follow: Karner or Schneider approach. Best is that
after two or three projects, whatever is coming accurate from history, take that
approach. Best approach is to use Excel and incorporate formulas properly.

Final Quotation:

So here is the final quotation to the scope defined and the Use Case document.

Table 9.0

XYZ SOFTWARE COMPANY

To:
TNC Limited, Western road 17, California.
Quotation number: 90
Date: 1/1/2004
Customer ID: - 20090DATAENTRY
Quantity Description Discount Taxable Total
Data Entry
1 0% 0% $840
Module
Quotation valid for 100 days
Goods delivery date within 25 days of half payment
Quotation prepared by: XYZ estimation department
Approved by : SPEG department XYZ
In this quotation, I have taken Karner's value, that’s 25 days. One programmer will sit on
the project with around $1000 salary. So his 25 days' salary comes to 840 dollars approx.
The upper quotation format is in its simplest format. Every company has its quotation format
accordingly. So no hard and fast rule for quotation templates. But still if interested, Microsoft
has a good collection of decent templates.

Use-Case Structure Matters:

The structure of Use-Case matters a lot. According to (Bente Anda, Hege Dreiem, Dag I.K
Sjoberg and Magne Jorgensen), the following aspects of structure have an impact:
 The use of generalization between actors: If two actors have 80 percent in
common, put them in generalization relationship and count them only once. This will
increase the accuracy of the estimate.
 The use of included and extending Use Case: Karner recommends that included
and extending Use Case should not be counted. But Bente Anda, Hege Dreiem, Dag
I.K Sjoberg and Magne Jorgensen have a different opinion in their practical
experience. In some Use Cases, they found include and extended Use Cases as
essential functionalities, and reducing them will reduce steps and hence the
estimation.
 The level of detail in the Use Case description (this is dependent on the guy
who writes the Use Case): The level of detail and transaction in Use Case impact
the Use-Case estimation a lot. If you see the Use-Case above, I have written steps
like user switches on the PC etc. The transaction would have increased and hence
estimation. So if that transaction step is not adding business value, do not add it as
transaction step. This will also increase the estimation to a good level.
 Including the above recommendation by Karner and (Bente Anda, Hege Dreiem, Dag
I.K Sjoberg and Magne Jorgensen), here are also my inputs which can be followed to
make an estimate better:

 Use-Case Splitting and Merging: Simple Use-Case masters matter a lot. Writing
Use-Cases, for example “Adding Country Master". User can write three different Use
Cases for Add, Update, Delete; or he can write one Use-Case and put the Update and
Delete in alternate scenarios. If the Update and Delete do not have different business
validations, put them in one Use-Case. During my counting, I had seen that accuracy
increases if for simple master we put them in one Use-Case.

Advantages 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.

Disadvantages 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. For initial phase of project, you can use
“Function points”. For function points, no formal document is needed. My old tutorial
on function points.
 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 [AP98].
 Maintenance estimation problems: Function point [article] 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 [article].

Other General Practical Factors

The below points are not related to Use Case as such, but general while making estimation:
 Change of psychology: Estimator should not be biased. If you are an employee of
the company, do not add extra charge or subtract extra charges. These things will be
handled at the negotiation table between the software company director and the
customer. An estimator's job is to show the real cost of the software to the company.
In short, an estimator should not be bothered about negotiation phase and whether
the company gets this project or not? Leave that work to the company's director.
And if you are the director of the company, think about that thing after the
estimation is over.
 Sixth Sense Approach: Any of the software measurement ways (Use Case,
Function points, LOC etc.) are evolving and under practice. After looking at the
figure, try to give sixth sense based on your past experience. Some times,
estimation will be fair if going the ad hoc way.
 Modular Estimation: In huge projects with 100s of modules, it's better to estimate
module wise. Example, if a client is asking for a customer module, supplier module
and accounts module, estimate them differently so that on negotiation table with
client, you can show him the complete break up. Second, this approach is very useful
for phase wise estimation. Client can decide either to not take the module (due to
financial concerns) or move it to phases.
  Information Creep and Grey Areas: Estimation is normally done at the initial
phase itself. Probably with one or two meetings with the client, we have to give the
estimation. But naturally, in many of the areas there can be creep. The best way for
such situations is to think about the maximum possibility and estimate. Example, if a
customer says that he needs a chat module and no clarification is made about what
the depth of it is, estimate to maximum possibility of how can a chat application be
made. Later in the negotiation table, show the client the estimation basis. So
according to the client's financial budget, changes will be made.
 Other Costing: None of the software estimation methodologies give cost for non-
software factors.
o If the software is using any third-party component, example Crystal Reports
etc., estimate them in a ad hoc way.
o Example, if in the project, company is also providing web hosting, domain
name, hardware etc., put them separately.
o If any training is involved, estimate them separately.
 Assumptions: As estimation is done at the initial stage, there can be lot of creep
and gray areas. Gray areas estimation has to be supported by proper assumptions.
 Review from Third Party: Before sending the costing to the client, review it
internally from a third person who is not involved in the project.
 Iterations: Iterate it as many as times possible and at various phases. Example,
use function points to iterate during scoping phase, that's initial phase, and Use Case
Point during the system requirement phase. This gives a good idea before
implementing that the costing is proper.
 Two teams estimation: During estimation, have two teams which will do the
estimation. So that cross verification can be done on the error percent of the
estimation.

References
It would be selfish on my part to say that the whole article is my own wisdom. So I have
provided all the links I have referred to prepare this article. If any of the link is copyright and
not to be produced, please email me at shiv_koirala@yahoo.com. I will see to my best that I
preserve the copyright.
 I work presently in Ag-technologies. Thanks to www.ag-technologies.com for
providing me a role in the estimation phase.
 Estimating, Software development effort based on Use Case experiences from
industry (Bente Anda, Hege Dreiem, Dag I.K Sjoberg and Magne Jorgensen)
 Use Case Points.
 Use Case Points.
 Writing Effective Use Cases (**PRE-PUB. DRAFT#3**): Alistair Cockburn Humans
and technology.
 For dictionary meaning of quotation.
 If your are looking at test effort using Use Case Points, have a look at the paper by
Cognizant Technology Solutions in the Quality Week 2001, San Francisco, California,
USA, June 2001 by Suresh Nageswaran.
 In this paper, they experimented using UUCFP (Unadjusted Use Case Flow Points) for
accuracy. By Gautam Banerjee (Annual IPML Conference 2004)
 Excellent quotation templates at Microsoft.
 Templates. Not necessary to follow exactly as it is but just for reference.
 Estimation using Use Case points
 http://heim.ifi.uio.no/~kribu/oppgave.pdf
 Basics of UML.
 My old function point tutorial.
 International Function Point user group.
 An Introduction to Function Point Analysis.
 A good PDF tutorial.
 Master thesis by Sofia Nystedt.
 Good thesis which has details about McCabe's complexity, Henry and Kafura’s
Information Flow, and Halstead measurement of complexity.
  Definition of UML.
 Definition of Object Oriented Programming.

Last Words
Software war for the best estimation has been going on for years. I am not pointing in this
article that Use Case Point is the best way to do estimation. So you will find I have
introduced the advantages and disadvantages section. But definitely, we have to measure.
One day, we have to unify on a common measurement principle. If we can say in real life,
city "xyz" is 100 kilometers far, why can not we say this project is of 1000 complexity, 200
function points or 650 Use Case points? Different languages, different compliers, different
processes companies follow have made it difficult to come to common grounds and common
measurement. But the largest hurdle we see is the software companies' attitude to come to
common conclusion of how to measure. If software can automate human complexity, then
software measurement also can be automated.
"We should no longer ask if we should measure, the question today is how?" - Dieter
Rombach Eurometrics 1991"
"Do not quote too less that programmers work for over night, you lose the project or end
doing social service, or loss. Do not quote too high that you lose the project. Be fair to
yourself and your customer."