Book a Demo

Author Topic: Use Case Metrics ineffective  (Read 3903 times)

uml-architect

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Use Case Metrics ineffective
« on: January 02, 2010, 09:59:55 pm »
Hi,

it is a very good idea to implement metric calculation based on use case within an UML modeling tool. Actually, I use to assess software many times, based on a first use case project scoping.

Yet, the EA proposed method is much too simple to be effective.
Assessing the use cases into simple/medium/easy doesn't fit the function points approach (ISO 14143), which is the industry reference.

A better approach would consist in having an Estimation view in which each use cases is attached to classes that represent a potential number of inputs, outputs, tables/interfaces for readings and writings and constraints for additional needs to implement business rules. Summing these I/O allows applying the approach as described by the ISBSG and the IFPUG.

Furthermore, a simple breakdown report by package, in which the function points appear, may be sufficient. Actually, calculating the workload per function point is often provided aside, because this doesn't depend on the model.

The tool may also propose several default workload ratios by referencing the numbers published by the ISBSG.

You may read more about the subject in my paper (in French only):
http://www.uml-architect.com/estimation-uml

As an additional feature, a connection between the maintenance view and the related estimation efforts may be a good idea as so to manage software evolutions. This requires however more reflections about the subject.

son-of-sargasso

  • EA User
  • **
  • Posts: 122
  • Karma: +0/-0
    • View Profile
Re: Use Case Metrics ineffective
« Reply #1 on: January 02, 2010, 10:52:47 pm »
Interesting, but you gave no reference to Kirsten Ribu's extension of Karner's original proposal.  I believe that the EA calcs are based on this work, which as she says is only useful for estimating the size of a project in the early stages.
Certainly as development of a model proceeds, it is possible to go back to the more formal (although still fraughful) function point method.  I look forward to re-reading your paper once it is translated (as my French is possibly worse than my coding ability  :)  )
cheers
bruce