Enterprise Architect provides a comprehensive project estimation tool that calculates effort from use case and actor objects, coupled with project configurations defining the complexity of the work environment. This method is based on Karner's Use Case Points Method, with several variations noted below. You can also produce a metrics report containing the project estimation analysis to incorporate into your project documentation. An example is here.

Before estimating project size, you will first need to configure the technical and environmental factors (see menu item Configuration - Metrics and Estimation Types - TCF and ECF values). For both TCF (technical complexity factor) and ECF (environment complexity factor), an editable table contains a list of factors influencing project productivity. A weight is associated with each factor, reflecting how much that factor relatively affects productivity; a weight is irrelative to a project. The supplied factors and their associated weights are defined by the Use Case Points Method, although they may be adjusted to suit a project's specific needs. For most purposes, the only table column needing adjustment will be 'Value', which indicates the degree of influence a particular factor holds over the project. As a suggested gage, a value of '0' indicates no influence, a '3' indicates average influence, and a '5' indicates strong influence.

As you build your project using UML use cases to describe the proposed functionality, you should assign a rating to each use case:

• Easy (5 points): The use case is considered a simple piece of work, uses a simple user interface and touches only a single database entity; its success scenario has less than 3 steps; its implementation involves less than 5 classes
• Medium (10 points): The use case is more difficult, involves more interface design and touches 2 or more database entities; its success scenario has between 4 to 7 steps; its implementation involves between 5 to 10 classes
• Complex (15 points): The use case is very difficult, involves a complex user interface or processing and touches 3 or more database entities; its success scenario has over seven steps; its implementation involves more than 10 classes

The above are different accepted methods to assign complexities, but serve as rough guidelines. If you are writing an application with no persistence but complex processing, you will have to use your judgment to assign complexity ratings.

While building the use cases, note that you can also assign them to Phases (e.g. 1.0, 1.1) and later filter your estimate based on Phase. You can also enter free text into the Tag field of a use case and filter the estimate based on tag information (e.g. <URGENT>).

Karner's UCP method also calculates project effort by considering project actors, and their contributing complexity. There is an option to include actors in the estimation calculation; by default, only use cases are considered. If project actors are also included, make sure their complexity has been assigned by some method; rough guidelines to this assignment are supplied below:

• Easy: The actor represents another system with a defined API
• Medium: The actor represents another system interacting through a protocol, like TCP/IP
• Complex: The actor is a person interacting via an interface.

Once you have set up the use cases, actors and environment, highlight the package in the project browser whose contents you would like to estimate; for the entire project, select the root view. Next, select Project - Use Case Metrics from the menu. The following screen will appear:

This details the complexity information for your project:

* Although Karner's UCP method recommends excluding included and extending use cases in this count, Enterprise Architect considers all use cases in its calculation. If these use cases require functionality to be developed, the effort still exists and should be factored.

A critical factor is the 'Default Hours' variable - which is best defined using experience with similar projects. Although the EA default is set to 10 hours, this variable could easily exceed 30 hours, depending on the environment.

The best way to accurately configure a new project to your unique environment is by considering the use cases of completed projects. After configuring a completed project as instructed above, and running a metrics report, the available factors can be fine-tuned to yield an estimate matching the actual hours. Then, you can begin using these figures as your baseline.

Note that a good sanity check is to look at the 'Ave Hours per Use Case' figure: if you believe you can build an easy use case in the time allowed (including your procedures of design, testing, documentation, review, etc.) and the medium and difficult likewise, then you are on the right track.

Don't expect a magic answer to the question 'how much?' or 'how long?' - collect some statistics and experience to guide estimates of new projects.