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