Estimation techniques - estimation using use cases

We have read about estimation techniques like problem and process based estimation techniques. There is another estimation approach that uses use cases which provide insight into software scope and requirements. However, it is somewhat difficult to develop an estimation technique using use cases.

- There is no standard format or style in which use cases can be described because there are many different formats and styles that a use case can use.
- The complexity of the functions are not addressed by the use cases.
- Complex behavior like interactions among many functions and features are not described by the use cases.
- Use cases are used to represent the user's view of the software.

Use case estimation technique for one person can require a lot of effort while use case estimation technique for some other person can be done in a day or two. According to Smith, use cases can be used for estimation but it is only possible and considered within the context of structural hierarchy that the use case describe.

- structural hierarchy can have not more than 10 use cases.
- each use case can have not more than 30 different scenarios.
- before using use case estimation, level within structural hierarchy is established, average length of each use case is computed, type of software is defined, rough architecture is considered.
- empirical data is used to establish lines of code or function point for each level.

Estimation techniques - Process based Estimation

Another technique that is used is estimating a project on the basis of estimating the base on the process that will be used. A process is decomposed into small tasks and effort that is required to fulfill each task is estimated. As apart of this process one is required to take the project scope and derive software functions from the scope. Now typically, for each function, there are a series of framework activities that must be performed. A 2*2 table would typically be constructed which maps these functions and the related framework activities.

Once you get the problem functions and the process activities, the table is filled by estimating the effort for each software activity for each software function. Once you are done with all the estimation, you have a complete table that forms an input for an estimation of the total cost. As a part of this step, you need to have values for the costing for the various activities. As an example, initial architectural and design activities are done by more senior and experienced people, with the costing for these resources being significantly more than the costing for future coding and testing.

Based on the above, we can generate a total cost. We can also generate the total cost through the lines of code and function point methods. Now, we have three methods of costing and can compare one against the other. If these are close to each other, then the estimates are reliable. If this is not so, then more investigation is required. This would require that the steps that have been taken to research and estimate through the lines of code, function point, or process based estimation would need to be re-examined in much more detail until possible errors are detected and estimates re-calculated.