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.
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]
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.
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 Classification | No. of Transactions | Weight |
---|---|---|
Simple | 1 to 3 transactions | 5 |
Average | 4 to 7 transactions | 10 |
Complex | 8 or more transactions | 15 |
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 Classification | Type of Actor | Weight |
---|---|---|
Simple | External system that must interact with the system using a well-defined API | 1 |
Average | External system that must interact with the system using standard communication protocols (e.g. TCP/IP, FTP, HTTP, database) | 2 |
Complex | Human actor using a GUI application interface | 3 |
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:
Factor | Description | Weight |
---|---|---|
T1 | Distributed system | 2.0 |
T2 | Response time/performance objectives | 1.0 |
T3 | End-user efficiency | 1.0 |
T4 | Internal processing complexity | 1.0 |
T5 | Code reusability | 1.0 |
T6 | Easy to install | 0.5 |
T7 | Easy to use | 0.5 |
T8 | Portability to other platforms | 2.0 |
T9 | System maintenance | 1.0 |
T10 | Concurrent/parallel processing | 1.0 |
T11 | Security features | 1.0 |
T12 | Access for third parties | 1.0 |
T13 | End user training | 1.0 |
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:
Factor | Description | Weight |
---|---|---|
E1 | Familiarity with development process used | 1.5 |
E2 | Application experience | 0.5 |
E3 | Object-oriented experience of team | 1.0 |
E4 | Lead analyst capability | 0.5 |
E5 | Motivation of the team | 1.0 |
E6 | Stability of requirements | 2.0 |
E7 | Part-time staff | -1.0 |
E8 | Difficult programming language | -1.0 |
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:
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.
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:
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:
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.
Factor | Description | Weight | Assigned Value | Weight x Assigned Value |
---|---|---|---|---|
T1 | Distributed system | 2.0 | 5 | 10 |
T2 | Response time/performance objectives | 1.0 | 5 | 5 |
T3 | End-user efficiency | 1.0 | 3 | 3 |
T4 | Internal processing complexity | 1.0 | 2 | 2 |
T5 | Code reusability | 1.0 | 3 | 3 |
T6 | Easy to install | 0.5 | 1 | 0.5 |
T7 | Easy to use | 0.5 | 5 | 2.5 |
T8 | Portability to other platforms | 2.0 | 2 | 4 |
T9 | System maintenance | 1.0 | 2 | 2 |
T10 | Concurrent/parallel processing | 1.0 | 3 | 3 |
T11 | Security features | 1.0 | 5 | 5 |
T12 | Access for third parties | 1.0 | 1 | 1 |
T13 | End user training | 1.0 | 1 | 1 |
Total (TF): | 42 |
Next, the TCF is calculated:
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.
Factor | Description | Weight | Assigned Value | Weight x Assigned Value |
---|---|---|---|---|
E1 | Familiarity with development process used | 1.5 | 3 | 4.5 |
E2 | Application experience | 0.5 | 3 | 1.5 |
E3 | Object-oriented experience of team | 1.0 | 2 | 2 |
E4 | Lead analyst capability | 0.5 | 5 | 2.5 |
E5 | Motivation of the team | 1.0 | 2 | 2 |
E6 | Stability of requirements | 2.0 | 1 | 2 |
E7 | Part-time staff | -1.0 | 0 | 0 |
E8 | Difficult programming language | -1.0 | 4 | -4 |
Total (EF): | 10.5 |
Next, the ECF is calculated:
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:
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.
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]
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.
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:
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 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.
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:
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.