Use Case Points: an analysis phase estimating technique

Featured
32641 Views
1 Comments
26 Likes

Use Case Points are used as an analysis phase technique for estimating software development. Assuming the Business Analyst (BA) composes system use cases for describing functional requirements, the BA can use this technique for estimating the follow-on implementation effort. This article reviews the process of estimating the follow-on development effort for use cases. Use Case Points are derived from another software development estimating technique called “Function Points.” However, Function Points are used by systems analysts as a development phase technique that requires technical detail for estimating. (Note that this article assumes that the reader knows and understands the technique of use case. In this article, the term “system use case” or simply “use case” is a sequence of steps that accomplishes a user goal in a single online session.)

Probably the scariest word in the world is estimate. Whether we are looking at auto repair work or software development, estimating can bring the best of us to our knees. The purpose of an estimate is to set expectations. However, as soon as we provide an estimate, it is judged. It is either too high or too low (must be missing something).

Once I consulted for a firm that had outsourced all its software development. The firm still conducted the analysis phase for its applications internally resulting in a Business Requirements Document (BRD). The BRD was then passed by the firm to the outsourcer for software development implementation. For major efforts, the outsourcer always provided an estimate to the firm prior to development. During one consulting session, the firm’s management expressed a concern that a recent estimate was too high. Upon hearing this evaluation, I asked what they expected. The response was that there was no real expectation; they just “felt” the estimates were too high! Obviously what was missing was a preliminary estimate from the analysis phase to establish a baseline to compare with the outsourced estimate. Without a baseline, the discussion is pointless (pun intended).

Enter the World of Use Case Points

Assuming the Business Analyst composes system use cases for describing functional requirements during the analysis phase, the BA can estimate the development effort using a technique called Use Case Points; caveat, this estimate does not include work associated with project management, infrastructure and other support effort, and testing. Use Case Points are used as an analysis phase estimating technique developed by Gustav Karner in 1993 (1). They are derived from a development phase estimating technique called Function Points which was developed by Allan AlBrecht (2). In 2005, Agilis Solutions and FPT Software published a study (3) showing the estimation accuracy achieved using Use Case Points. The estimates were less than 9 percent from actual cost on 95 percent of the projects. The study included over 200 projects over a period of 5 years with the average project being 60 work months.

Both Use Case Points and Function Points techniques result in the number of hours needed to develop the software. The difference between the two techniques is in the information used for building the estimate.

  • Use Case Points

    • Conducted by business analysts during the analysis phase of a project

    • Can be classified as a class IV or III estimate (4)

    • Is based on information contained in a business requirement document

      • Functional requirements as modeled via system use cases, actors, and scenarios

      • Nonfunctional requirements

      • Assumptions on developmental risks

  • Function Points

    • Conducted by systems analysts during the development phase

    • Can be classified as a class II or I estimate which should be more detailed (4)

    • Is based on information contained in a technical specification

      • Data Functions using internal and external logical files

      • Transaction Functions using external inputs and external outputs, plus external inquiries

Calculating Use Case Points

To use this estimating technique, the business analyst uses four tables and four formulas.

  • Tables

    • Two tables represent functional requirements as described by system use cases. Note that both of these tables are entitled “unadjusted” since the totals from these tables need to be adjusted by the work entailed by nonfunctional requirements and the risk due to the characteristics of the development team.

      • Unadjusted Actor Points

      • Unadjusted Scenario Points

    • Nonfunctional Requirements Adjustment Table

    • Developmental Risk Adjustment Table

  • Formulas

    • Nonfunctional Adjustment Factor

    • Developmental Risk Adjustment Factor

    • Total Adjustment Factor

    • Total Unadjusted Use Case points

    • Total Adjusted Use Case Points

    • Development Work Estimate excluding project management, Infrastructure plus other supporting work, and testing – there has been some effort to include testing using a similar method with historical average testing hours per use case point (5)

Step 1 – Functional Requirement Tables

The first table (Table 1) considers the system use case actors. The purpose of the Unadjusted Actor Point Table is to classify and score different types of system use case actors. System use case actor roles can be portrayed by internal systems, external systems or people/time/sensors depending on the application. Respectively, these role types can be classified on the Karner weighted scale: simple – 1, average – 2, complex – 3. For example:

Actor Scale Actor Role Type Weight
1 – simple
2 – average
3 – complex
Number of Actors Unadjusted Points
Simple Internal System Application 1 3 3
Average External System Application 2 3 6
Complex Person, Time, Sensor 3 6 18
Total Unadjusted Actor Points 27

Table 1. Unadjusted Actor Points

The next table (Table 2) considers the system use cases. The purpose of the Unadjusted Use Case Point Table is to classify and score use cases on the basis of the number of dialogue exchanges. A dialogue exchange is defined as an actor request and a system response. Note that even though the system may have different responses to the same actor request, for example an error message, it is still considered a single dialogue exchange. These exchanges can be classified on a Karner weighted scale of simple (1-3 exchanges), average (4-7 exchanges), and complex (over 7 exchanges). For example:

Use Case Scale Use Case Dialogue Exchanges Weight
5 - simple
10 - average
15 complex
Number of Use Cases Unadjusted Points
(weight x number of use cases)
Simple 1-3 dialogue exchanges 5 3 15
Average 4-7 dialogue exchanges 10 10 100
Complex Over 7 dialogue exchanges 15 6 90
Total Unadjusted Scenario Points 205

Table 2. Unadjusted Use Case Points

Step 2 – Nonfunctional Requirement Table

The next table (Table 3) considers the nonfunctional requirements in order to adjust the system use case and actor points for application complexity. The purpose of the Nonfunctional Requirement Adjustment Factor Table is to classify and score nonfunctional requirements or general characteristics of the application. The total nonfunctional score along with the total developmental risk score (next step) is used as a factor to adjust the total unadjusted actor and use case points. The nonfunctional requirements are weighted (0-5, 5 being most concern) on importance and on a complexity scale (0-5, 0 being least complex, 3 being average, and 5 being most complex). Note that in the example, I have stated nonfunctional requirements, associated weights and complexity per my own experience; this means that the “constant” in the nonfunctional requirement adjustment factor formula needs to be determined for the average application.

Nonfunctional Requirement or General Characteristic Weight
(0-5)
5 – most concern
Complexity
(0-5)
0 – least
3 – average
5 – most
Score
(weight x complexity)
Distributed System 2 5 10
Performance 1 5 5
Usability 0.5 2 1
Backup and Recovery 1 2 2
Compatibility 1 2 2
Scalability 1 3 3
Transition Requirements 0.5 3 1.5
Portability 2 3 6
Maintainability 1 3 3
Reliability 1 5 5
Disaster Recovery 1 3 3
Availability 1 5 5
Security 1 4 4
Training/Operability 1 3 3
Total Nonfunctional Score 53.5

Table 3. Nonfunctional Requirement Adjustment Factor (may be augmented with columns on weight and complexity rational)

Step 3 – Developmental Risk Table

The next table (Table 4) considers the development risk to adjust the system use case and actor points for risk associated with the team. The purpose of the Developmental Risk Adjustment Factor Table is to classify and score perceived risk with the team in developing the application. As stated previously, the total developmental risk score along with the total nonfunctional score is used as a factor to adjust the total unadjusted actor and use case points. As with the nonfunctional requirements, the developmental risk is weighted (0-5, 5 being most concern) on importance and rated on a scale (0-5, 0 being low, 3 being average, and 5 being high).

However, in the case of developmental risk, some risks are opposite in nature and should have a negative weight. For example, part-time members * (see Table 4) rather than full-time members have a negative impact. Therefore, a high rating for part-time members should have a negative score. Note that in the example, I have stated development risks, associated weights and ratings per my own experience; this means that the “constant” in the development risk adjustment factor formula needs to be determined for the average application.

Team Risk Weight
(0-5)
5 – most concern
Rated
(0-5)
0 – low
3 – average
5 – high
Score
(weight x impact)
Skill Level 1.5 3 4.5
Experience Level 1 3 3
OO Experience 1 2 2
Leadership 1 3 3
Motivation 1 3 3
Requirement Stability 2 2 4
Part-time Team Members* -1 5 -5
Tool Availability 1 3 3
Total Development Risk Score 17.5

Table 4. Developmental Risk Adjustment Factor (may be augmented with columns on weight and rating rational)

 

Step 4 - The Formulas

The business analyst uses the first two formulas to calculate the nonfunctional adjustment and the developmental risk factors. But before we delve into the formulas, I want to encourage the reader to understand the formulas. I recently read an article on blindly following templates (6); I feel the same way about formulas. Don’t just blindly use them. Understand how the formula works. As mentioned before, if you change the tables (modify entries or weights), ensure you adjust the formula “constants” so that the formulas still yield factors of 1 for an average system..

Nonfunctional Adjustment Factor = “a constant” + (.01*Total Nonfunctional Score)

  • Formula derived from function point technique

  • The higher total nonfunctional score the higher the nonfunctional adjustment factor

  • Formula needs to yield a factor of 1 (no effect) for an average system

    • “a constant” – in the example in this article, given the nonfunctional requirements, weights, and average complexity rating of 3 for all categories, the Total Nonfunctional Score is 45 which yields (.01*45 = .45)

    • Therefore, “a constant” of .55 is used to provide a factor of 1 for an average application

    • With the constant set to .55, the nonfunctional adjustment factor ranges from .55 to 1.3 (i.e., Total Nonfunctional Score 0 to 75 respectively)

    • For the example in this article the nonfunctional adjustment factor is .55 + (.01*53.5) or 1.085

Developmental Risk Adjustment Factor = “a constant” + (-0.03*Total Developmental Risk Score)

  • No equivalent formula in function point technique

  • The higher total development risk score the lower the developmental risk adjustment factor (i.e., multiplier is negative)

  • Multiplier 0.03 is used rather than the same multiplier used in the nonfunctional adjustment factor; the higher multiplier lowers the developmental risk adjustment factor more with a higher developmental risk score

  • Formula needs to yield a factor of 1 (no effect) for an average system

    • “a constant” – in the example in this article, given the developmental risks, weights, and average complexity rating of 3 for all categories, the Total Development Risk Score is 22.5 which yields (-0.03*22.5 = -.675)

    • Therefore, “a constant” of 1.675 is used to provide a factor of 1 for an average application

       

    • With the constant set to 1.675, the developmental risk adjustment factor ranges from 1.825 to .55 (i.e., Total Development Risk Score -5 to 37.5 respectively)

       

With the above adjustment factors calculated, the business analyst proceeds with final formulas for the use case point estimate. The business analyst first determines total adjustment factor by multiplying the nonfunctional and development risk factors. Given the nonfunctional requirements and developmental risks I have stated, the total adjustment factor ranges from a minimum of .3025 to a maximum of 2.735. The BA then adds up the total unadjusted scenario case and actor points, and finally multiplies the total adjustment factor and total unadjusted use case and actor points to produce the total adjusted use case points (see formulas and examples below).

Total Adjustment Factor = Nonfunctional * Developmental Risk

= 1.085   *   1.15

= 1.24775

Total Unadjusted Use Case Pts = unadjusted Scenario Pts + unadjusted Actor Pts

= 205   +   27

= 232

Total Adjusted Use Case Pts = Total Adjusted Factor * Total unadjusted Use Case Pts

= 1.24775   *   232

= 289 (rounded)

The Conversion Formula

With the total adjusted use case points, the business analyst can now determine the work effort estimate in units of time for developing the use cases (note caveat at the beginning of this article). The key element in this conversion is the development hours per use case point. Unfortunately, the historical average development hours per use case point are probably not available for your firm. However, averages for function points are available ranging from 15 to 45 hours per function point depending on the industry (7). These averages may be used in lieu of established use case point averages. When in doubt, practitioners recommend to use 20 hours (8).

Work Effort Estimate = Total Adjusted Use Case Points  *  Average Hours per Use Case Point

=    289    *    20

= 5780 hours or 723 days or 145 weeks or 36 months (rounded)

Summary

Figure 1 depicts a high-level view of the Use Case Points estimates process. As with any estimating technique, the purpose of Use Case Points is to set expectations. The 2005 Agilis Solutions and FPT Software results have provided some evidence of its accuracy. Business Analysts can use this estimating technique during the analysis phase of a project to generate class II or III estimates. Note the caveat of project management and testing exclusion, ensure the correct constant is used in the adjustment factor formulas, and limited availability of historical averages on use case points per hour.

Use Case Points Estimating Process

Figure 1. Use Case Points Estimating Process

References

  1. Karner, Gustav. “Resource Estimation for Objectory Projects” Objective Systems SF AB, 1993.

  2. Albrecht, A.J. “Measuring Application Development Productivity” Proc. of IBM Applications Development Symposium, Monterey, CA, 14-17 Oct. 1979: 83.

  3. Carroll, Edward R. “Estimating Software Based on Use Case Points” 2005 Object-Oriented, Programming, Systems, Languages, and Applications (OOPSLA) Conference, San Diego, CA, 2005.

  4. http://www.aacei.org/technical/rps/17r-97.pdf

  5. http://www.scribd.com/doc/956228/Test-Effort-Estimation

  6. http://www.batimes.com/articles/its-time-for-template-zombies-to-die.html

  7. http://www.rebootrethink.com/justTheFacts/industrybyindustry.php

  8. http://www.codeproject.com/KB/architecture/usecasepoints.aspx

Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail – [email protected].

Like this article:
  26 members liked this article
Featured
32641 Views
1 Comments
26 Likes

COMMENTS

gjackson posted on Wednesday, August 17, 2011 11:54 AM
Are you sure you aren't leaving out any other accomplishments in the Author section? Nice bow tie!
Only registered users may post comments.






Latest Articles

The Art of Letting Stakeholders Have Your Way
Nov 23, 2020
0 Comments
Study after study in behavioral science show that certain approaches are more effective than others when we’re trying to convince others to see ...





Copyright 2006-2020 by Modern Analyst Media LLC