How Galorath Made Use Case Points Viable For Accurate Estimating
Use case points provide a measure of size based on Use Cases, a natural artifact of the software process. The original concept was developed by Objectory AB (now part of IBM Rational Software.) There have been many detractors of use case points including Rational Software itself and USC. The Galorath team approached Use Case estimating with a number of approaches. Lee Fischman, who led the project came up with the concept of Normalized Use Cases (NUCs), a new metric based on Use Case Points He also had Galorath’s Dr. Tarbet set off to create better results from Use Case Points. Use Case Points are based on:
- Based on the number of actors and transaction for each case.
- Categorization into simple, medium and difficult.
- Linear combination of weighted counts
When Dr. Tarbet finished his analysis he obtained an Adjusted Correlation Coefficient (R2 ) = 0.984802, showing an exceptional value to the enhanced Use Case Point method.
Next he ran methodology with Lockheed actual. When Galorath analysts counted the use case points they were within 20% of actual effort. Lockheed analysts achieved better than 12% accuracy due to their ability to better classify the complexities.
The relationship of a use case model and the project effort was defined by Gustav Karner in his work on Objectory at Linkoping University. Karner identified a relationship between Unadjusted Use Case Points, and the effort necessary to design and develop a software project defined by the use case model. Thomas Fihlmanii utilized the concepts defined by Karner to establish a framework for time estimation from a use case model. This study has used the concepts of deriving effort estimation to develop an effort estimate that is used SEER’s sizing model, to effectively “execute the model backwards”. The result is an approximation of the project size.
Further work actually extracts Use Case information from Rational’s Rose, or RSx systems. This provides an automated estimate for just the information included in Use Cases. No function point estimating or counting, no line counting or estimation, SEER does all that automatically.
The four-step process to establish algorithms and weighting coefficients for this model
are as follows:
1. Established use case models in Rational Rose for known programs.
2. Established a function point count for the known programs.
3. Used SEER to establish an effort estimate based on the function point size.
4. Used the effort estimate from SEER to derive the weighting coefficients for the algorithms.
As a point of validation, an effort estimate was developed using UUCF for a complex aerospace project. The team had a use case model (developed using Rational Rose), a work breakdown structure (WBS), and a full set of metrics, including size metrics for each WBS component and actual effort expended, including requirements, design, code, test, Integration, Configuration Management, Quality Assurance, and software management. The UUCF model was applied to the project use case model by the Galorath team, who had limited domain knowledge of the project functionality. The result, as demonstrated in Section 4: Validation, was well within the 25% accuracy goal, which had been established as an expected threshold. A second estimate was conducted using the UUCF model with the contractor providing the definitions for simple, medium, and complex Actors and use cases. The result, also demonstrated in Section 4, was within 12.15% of the recorded metrics. The result indicates the accuracy to be expected as the project progresses, and the use case model is expanded from its initial capture of the requirements, to include the design and development considerations.
The UUCF model is applied in the following steps:
Step 1: Actor Count
| Evaluate the Actors in the project. Define the Actors as Simple, Average, or Complex. | Weighting | |
| Simple Actors – another system interfaced via a defined programming interface with specified API. |
A1 |
|
| Average Actors – another system interfaced to the use case via a protocol or a text based user interface. |
A2 |
|
| Complex Actors – a person interfacing to the use case via a graphics user interface (GUI). |
A3 |
|
| Weighting factor is selected to reflect performance of particular organization. | ||
Step 2: Actor Weight Factor Algorithm
|
Actor Type |
Description |
Factor |
Number of Actors |
|
Result |
|
Simple |
System Interface |
A1 |
N_A1 |
|
A1 *N_A1 |
|
Average |
Interactive or protocol driven interface |
A2 |
N_A2 |
|
A2 *N_A2 |
|
Complex |
Graphical Interface |
A3 |
N_A3 |
|
A3 *N_A3 |
|
Total Actor Weight Factor |
A_WF |
||||
Step 3: Use Case Count
| Evaluate the use cases. Define use cases as simple, average, or complex. | Weighting | |
| Simple use case: 1-3 transactions (set of activities that are performed entirely as an entity, an extension, or an include) |
U1 |
|
| Average use case: 4-7 transactions |
U2 |
|
| Complex use case: 8 + transactions |
U3 |
|
| Weighting factor is selected to reflect performance of particular organization. | ||
Step 4: Use Case Weight Factor Algorithm
|
Use Case Type |
Description |
Factor |
Number of use cases |
Results |
|
Simple |
1-3 Transactions |
U1 |
N_U1 |
U1* N_U1 |
|
Average |
4 -7 Transactions |
U2 |
N_U2 |
U2 * N_U2 |
|
Complex |
8 or more Transactions |
U3 |
N_U3 |
U3 * N_U3 |
|
Total Use Case Weight Factor |
U_WF |
|||
Step 5: Calculation of Use Case Factor
The Use Case Factor (UCF) is defined as the sum of the Actor Weight Factor and the Use Case Weight Factor:
UCF = A_WF + U_WF
Technical complexity and environmental factors will impact the evaluation and therefore need to be considered. For this study, the team utilized the technical factor and environmental factor defined in the previous study, as multiplying factors to influence the effort estimate. The Technical Weight Factor and Environmental Weight Factor are modified by an algorithm taken from University research.
Bottom Line: If users generate Use Case Points only from the Use Cases themselves there can be a significant variance. This is mitigated by automated training from other projects. AND Use Case Points can be a viable metric for software sizing, used and estimated on their own, not just from a Use Case Diagram.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Related posts:
- Lines of Code Versus Functon Points Versus Use Cases For Sizing I, along with many others, have written about the virtues of one size metric versus another. Some attempt to make...
- CostIQ Case-Based Reasoning Model For SEER Customer Order This week we received our first order for the official release of CostIQ, the case-based reasoning estimation engine for SEER. It has...
- New Code Counting Tool Made Available A new version of the USC code counting tool has been made available to the public. Code counters are useful for...
- The Business Case for IT Systems I just saw this UK business case for IT systems document. Very interesting. I love it when people tie IT...
- Make or Break: Why Accurate Cost Estimation Is Key A recent articlefrom executivebrief.com sent to me By Dr. Ricardo Valerdi of MIT discusses how the accuracy of the cost...
Comments
One Response to “How Galorath Made Use Case Points Viable For Accurate Estimating”
Leave a Reply
Project Prediction Infographic
I went through your explanation and it is very clear. Am in my first year in the university. I have a problem of figuring the class to which an actor belong. For instance an help deskperson that replies mails to clients. Should the help desk person be considered as average or complex.
Thanks in anticipation for your reply.