Use case points

Last updated

Use case points (UCP or UCPs) is a software estimation technique used to forecast the software size for software development projects. UCP is used when the Unified Modeling Language (UML) and Rational Unified Process (RUP) methodologies are being used for the software design and development. The concept of UCP is based on the requirements for the system being written using use cases, which is part of the UML set of modeling techniques. The software size (UCP) is calculated based on elements of the system use cases with factoring to account for technical and environmental considerations. The UCP for a project can then be used to calculate the estimated effort for a project.

Contents

History

The UCP technique was developed by Gustav Karner in 1993 while employed at what was known at the time as Objectory Systems, which later merged into Rational Software and then IBM. The UCP method was created to solve for estimating the software size of systems that were object oriented. It is based on similar principles as the Function Point (FP) estimation method, but was designed for the specific needs of object oriented systems and system requirements based on use cases. [1] [2] [3]

Method

The method for determining the size estimate to develop a system is based on a calculation with the following elements:

Once the previous four elements have been calculated, the final size estimate can be calculated. This final number is known as the use case points or UCP for a software development project.

The following sections walk through the various calculations to determine the UCP for a project.

Unadjusted Use Case Weight (UUCW)

The UUCW is one of the factors that contribute to the size of the software being developed. It is calculated based on the number and complexity of the use cases for the system. To find the UUCW for a system, each of the use cases must be identified and classified as Simple, Average or Complex based on the number of transactions the use case contains. Each classification has a predefined weight assigned. Once all use cases have been classified as simple, average or complex, the total weight (UUCW) is determined by summing the corresponding weights for each use case. The following chart shows the different classifications of use cases based on the number of transactions and the weight value assigned for each use case within the classification.

Use Case ClassificationNo. of TransactionsWeight
Simple1 to 3 transactions5
Average4 to 7 transactions10
Complex8 or more transactions15
UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) + (Total No. Complex Use Cases x 15)

Unadjusted Actor Weight (UAW)

The UAW is another factor that contributes to the size of the software being developed. It is calculated based on the number and complexity of the actors for the system. Similar to finding the UUCW, each of the actors must be identified and classified as Simple, Average or Complex based on the type of actor. Each classification also has a predefined weight assigned. The UAW is the total of the weights for each of the actors. The following chart shows the different classifications of actors and the weight value assigned.

Actor ClassificationType of ActorWeight
SimpleExternal system that must interact with the system using a well-defined API1
AverageExternal system that must interact with the system using standard communication protocols (e.g. TCP/IP, FTP, HTTP, database)2
ComplexHuman actor using a GUI application interface3
UAW = (Total No. of Simple actors x 1) + (Total No. Average actors x 2) + (Total No. Complex actors x 3)

Technical Complexity Factor (TCF)

The TCF is one of the factors applied to the estimated size of the software in order to account for technical considerations of the system. It is determined by assigning a score between 0 (factor is irrelevant) and 5 (factor is essential) to each of the 13 technical factors listed in the table below. This score is then multiplied by the defined weighted value for each factor. The total of all calculated values is the technical factor (TF). The TF is then used to compute the TCF with the following formula:

TCF = 0.6 + (TF/100)
FactorDescriptionWeight
T1Distributed system2.0
T2Response time/performance objectives1.0
T3End-user efficiency1.0
T4Internal processing complexity1.0
T5Code reusability1.0
T6Easy to install0.5
T7Easy to use0.5
T8Portability to other platforms2.0
T9System maintenance1.0
T10Concurrent/parallel processing1.0
T11Security features1.0
T12Access for third parties1.0
T13End user training1.0

Environmental Complexity Factor (ECF)

The ECF is another factor applied to the estimated size of the software in order to account for environmental considerations of the system. It is determined by assigning a score between 0 (no experience) and 5 (expert) to each of the 8 environmental factors listed in the table below. This score is then multiplied by the defined weighted value for each factor. The total of all calculated values is the environment factor (EF). The EF is then used to compute the ECF with the following formula:

ECF = 1.4 + (-0.03 x EF)
FactorDescriptionWeight
E1Familiarity with development process used1.5
E2Application experience0.5
E3Object-oriented experience of team1.0
E4Lead analyst capability0.5
E5Motivation of the team1.0
E6Stability of requirements2.0
E7Part-time staff-1.0
E8Difficult programming language-1.0

Use Case Points (UCP)

Finally the UCP can be calculated once the unadjusted project size (UUCW and UAW), technical factor (TCF) and environmental factor (ECF) have been determined. The UCP is calculated based on the following formula:

UCP = (UUCW + UAW) x TCF x ECF

Example

To illustrate the process of calculating the UCP, an Online Shopping System will be used. The diagram below depicts the Use Case Diagram for the system to be developed.

Online Shopping System Use Case Model.jpg

Unadjusted Use Case Weight (UUCW)

To calculate the UUCW, the use cases must be defined and the number of transactions for each use case identified. The Online Shopping System use case diagram is depicting that nine use cases exist for the system. Assuming 2 of these use cases are simple, 3 are average and 4 are complex, the calculation for UUCW is as follows:


UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) + (Total No. Complex Use Cases x 15)
For the Online Shopping System, the UUCW = (2 x 5) + (3 x 10) + (4 x 15) = 100
UUCW = 100

Unadjusted Actor Weight (UAW)

To calculate the UAW, the actors must be identified. The Online Shopping System use case diagram is depicting five actors; One simple for the Payment Processing System and four complex for each of the human users actors (i.e. Online Customer, Marketing Administrator, Warehouse Clerk, Warehouse Manager.) The calculation for UAW is as follows:

UAW = (Total No. of Simple Actors x 1) + (Total No. Average Actors x 2) + (Total No. Complex Actors x 3)
For the Online Shopping System, UAW = (1 x 1) + (0 x 2) + (4 x 3) = 13
UAW = 13

Technical Complexity Factor (TCF)

To calculate the TCF, each of the technical factors is assigned a value based on how essential the technical aspect is to the system being developed. The diagram below shows the assigned values for the Online Shopping System. The values are multiplied by the weighted values and the total TF is determined.

FactorDescriptionWeightAssigned ValueWeight x Assigned Value
T1Distributed system2.0510
T2Response time/performance objectives1.055
T3End-user efficiency1.033
T4Internal processing complexity1.022
T5Code reusability1.033
T6Easy to install0.510.5
T7Easy to use0.552.5
T8Portability to other platforms2.024
T9System maintenance1.022
T10Concurrent/parallel processing1.033
T11Security features1.055
T12Access for third parties1.011
T13End user training1.011
Total (TF): 42

Next, the TCF is calculated:

TCF = 0.6 + (TF/100)
For the Online Shopping System, TCF = 0.6 + (42/100) = 1.02
TCF = 1.02

Environmental Complexity Factor (ECF)

To calculate the ECF, each of the environmental factors is assigned a value based on the team experience level. The diagram below shows the assigned values for the Online Shopping System. The values are multiplied by the weighted values and the total EF is determined.

FactorDescriptionWeightAssigned ValueWeight x Assigned Value
E1Familiarity with development process used1.534.5
E2Application experience0.531.5
E3Object-oriented experience of team1.022
E4Lead analyst capability0.552.5
E5Motivation of the team1.022
E6Stability of requirements2.012
E7Part-time staff-1.000
E8Difficult programming language-1.04-4
Total (EF): 10.5

Next, the ECF is calculated:

ECF = 1.4 + (-0.03 x EF)
For the Online Shopping System, ECF = 1.4 + (-0.03 * 10.5) = 1.085
ECF = 1.085

Use Case Points (UCP)

Once the Unadjusted Use Case Weight (UUCW), Unadjusted Actor Weight (UAW), Technical Complexity Factor (TCF) and Environmental Complexity Factor (ECF) has been determined, the Use Case Points (UCP) can be calculated with the following formula:

UCP = (UUCW + UAW) x TCF x ECF
For the Online Shopping System, UCP = (100 + 13) x 1.02 x 1.085 = 125.06
UCP = 125.06

For the Online Shopping System, the total estimated size to develop the software is 125.06 Use Case Points.

Now that the size of the project is known, the total effort for the project can be estimated. For the Online Shopping System example, 28 man hours per use case point will be used.

Estimated Effort = UCP x Hours/UCP
For the Online Shopping System, Estimated Effort = 125.06 x 28
Estimated Effort = 3501 Hours

Further development

One major weakness of the Use Case Points method is that it has never been thoroughly calibrated using regression analysis due to a lack of a statistically sufficient number of projects. Moreover, the linear model of Karners approach does not take the diseconomies of scale into account that occur in software development projects. [4] Still, the easily applicable sizing approach and counting rules provide many benefits for estimations in early phases and thus allow to quickly yield the FSM (functional size measurement, in this case UUCW + UAW) of an application or IT product. This FSM can then be combined with statistically validated estimation models like COCOMO II to gain more reliable estimation results. [4]

See also

Related Research Articles

Earned value management (EVM), earned value project management, or earned value performance management (EVPM) is a project management technique for measuring project performance and progress in an objective manner.

The Constructive Cost Model (COCOMO) is a procedural software cost estimation model developed by Barry W. Boehm. The model parameters are derived from fitting a regression formula using data from historical projects.

Standard error

The standard error (SE) of a statistic is the standard deviation of its sampling distribution or an estimate of that standard deviation. If the statistic is the sample mean, it is called the standard error of the mean (SEM).

In digital circuit design, register-transfer level (RTL) is a design abstraction which models a synchronous digital circuit in terms of the flow of digital signals (data) between hardware registers, and the logical operations performed on those signals.

Cost estimation in software engineering is typically concerned with the financial spend on the effort to develop and test the software, this can also include requirements review, maintenance, training, managing and buying extra equipment, servers and software. Many methods have been developed for estimating software costs for a given project.

SEER for Software (SEER-SEM) is an algorithmic project management software application designed specifically to estimate, plan and monitor the effort and resources required for any type of software development and/or maintenance project. SEER, which comes from the noun, referring to one having the ability to foresee the future, relies on parametric algorithms, knowledge bases, simulation-based probability, and historical precedents to allow project managers, engineers, and cost analysts to accurately estimate a project's cost schedule, risk and effort before the project is started.

In statistics, resampling is any of a variety of methods for doing one of the following:

  1. Estimating the precision of sample statistics by using subsets of available data (jackknifing) or drawing randomly with replacement from a set of data points (bootstrapping)
  2. Exchanging labels on data points when performing significance tests
  3. Validating models by using random subsets

The function point is a "unit of measurement" to express the amount of business functionality an information system provides to a user. Function points are used to compute a functional size measurement (FSM) of software. The cost of a single unit is calculated from past projects.

In software development, test effort refers to the expenses for tests. There is a relation with test costs and failure costs. Some factors which influence test effort are: maturity of the software development process, quality and testability of the testobject, test infrastructure, skills of staff members, quality goals and test strategy.

Software sizing or Software size estimation is an activity in software engineering that is used to determine or estimate the size of a software application or component in order to be able to implement other software project management activities. Size is an inherent characteristic of a piece of software just like weight is an inherent characteristic of a tangible material.

Forest inventory is the systematic collection of data and forest information for assessment or analysis. An estimate of the value and possible uses of timber is an important part of the broader information required to sustain ecosystems. When taking forest inventory the following are important things to measure and note: species, diameter at breast height (DBH), height, site quality, age, and defects. From the data collected one can calculate the number of trees per acre, the basal area, the volume of trees in an area, and the value of the timber. Inventories can be done for other reasons than just calculating the value. A forest can be cruised to visually assess timber and determine potential fire hazards and the risk of fire. The results of this type of inventory can be used in preventive actions and also awareness. Wildlife surveys can be undertaken in conjunction with timber inventory to determine the number and type of wildlife within a forest. The aim of the statistical forest inventory is to provide comprehensive information about the state and dynamics of forests for strategic and management planning. Merely looking at the forest for assessment is called taxation.

In software development, effort estimation is the process of predicting the most realistic amount of effort required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.

Weighted Micro Function Points (WMFP) is a modern software sizing algorithm which is a successor to solid ancestor scientific methods as COCOMO, COSYSMO, maintainability index, cyclomatic complexity, function points, and Halstead complexity. It produces more accurate results than traditional software sizing methodologies, while requiring less configuration and knowledge from the end user, as most of the estimation is based on automatic measurements of an existing source code.

Methodology to evaluate complexity and cost of developing and maintaining application software for creating information systems - this is an algorithmic model assessment value software, developed by a consortium of Kazakh IT companies: Kazakhstan Association of IT-companies Company System Studies "Factor" and JSC "National Information Technologies. Method allows assessment of complexity and cost of development of [software] in the early stages and is based on an assessment of the functional size of software.

Estimation Process of finding an approximation, which is a value that is usable for some purpose, though uncertain

Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available. Typically, estimation involves "using the value of a statistic derived from a sample to estimate the value of a corresponding population parameter". The sample provides information that can be projected, through various formal or informal processes, to determine a range most likely to describe the missing information. An estimate that turns out to be incorrect will be an overestimate if the estimate exceeded the actual result, and an underestimate if the estimate fell short of the actual result.

Unified Code Count (UCC)

The Unified Code Counter (UCC) is a comprehensive software lines of code counter produced by the USC Center for Systems and Software Engineering. It is available to the general public as open source code and can be compiled with any standard ANSI C++ compiler.

SNAP is the acronym for “Software Non-functional Assessment Process,” a measurement of non-functional software size. The SNAP sizing method complements ISO/IEC 20926:2009, which defines a method for the sizing of functional user requirements. SNAP is a product of the International Function Point Users Group (IFPUG), and is sized using the “Software Non-functional Assessment Practices Manual,” (APM) now in version 2.4. The SNAP methodology has the IEEE standard IEEE2430-2019.

Resource estimation is used to determine and define the ore tonnage and grade of a geological deposit, from the developed block model. There are different estimation methods used for different scenarios dependent upon the ore boundaries, geological deposit geometry, grade variability and the amount of time and money available. A typical resource estimation involves the construction of a geological. Resource model with data from various sources. Depending on the nature of the information and whether the data is hard copy or computerized, the principal steps of computer resource estimation are:

  1. Creation, standardization and validation of the database.
  2. Section plotting and interactive geological modeling.
  3. Geostatistical analysis.
  4. Block modeling and block estimation.

In Agile software development, the Fibonacci scale consists of a sequence of numbers used for estimating the relative size of user stories in points. Agile Scrum is based on the concept of working iteratively in short sprints, typically two weeks long, where the requirements and development are continuously being improved. The Fibonacci sequence consists of numbers that are the summation of the two preceding numbers, starting with [0, 1]. Agile uses the Fibonacci sequence to achieve better results by reducing complexity, effort, and doubt when determining the development time required for a task, which can range from a few minutes to several weeks.

Risk score is the name given to a general practice in applied statistics, bio-statistics, econometrics and other related disciplines, of creating an easily calculated number that reflects the level of risk in the presence of some risk factors.

References

  1. Murali Chemuturi, Software Estimation Best Practices, Tools and Techniques for Software Project Estimators, J.Ross Publishing, 2009, p. 84-87
  2. Dennis, Alan R., Barbara Haley Wixom, and David Tegarden. Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, Third Edition, John Wiley & Sons, 2009, Chapter 5 - Functional Modeling
  3. Dennis, Alan R., Barbara Haley Wixom, and David Tegarden. Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, Fourth Edition, John Wiley & Sons, 2012, Chapter 2 - Project Management
  4. 1 2 Carl Friedrich Kress, Olivier Hummel, Mahmudul Huq: A Practical Approach for Reliable Pre-Project Effort Estimation. In: CEUR Workshop Proceedings, Vol. 1138, p. 23, 2014