Sizing in many metrics

[Capers Jones]

Size remains difficult and ambiguous in the software field.

As of 2015 there seem to be 23 common sizing metrics, with few conversion rules among them.
So far as I know no other industry has so many metrics for the same value. Software also has 2,700 programming languages, also for unknown reasons. My view is that all these languages and metrics mean that none are fully satisfactory or we would not have so many.
Pasted below are the metrics I know about. If anyone is aware of others please let me know or post it on this blog.

1. IFPUG 4.3
2. Automated code based
3. Automated UML-based
4. Backfired function points
5. COSMIC function points
6. Fast function points
7. Feature points
8. FiSMA function points
9. Full function points
10. Function points light
11. IntegraNova models
12. Mark II function points
13. Nesma function points
14. RICE objects
15. SCCQI function points
16. Simple function points
17. SNAP non functional metrics
18. SRM pattern matching
19. Story points
20. Unadjusted function points
21. Use case points
22. Logical code statements
23. Physical LOC (blank, comments)

Thanks,
Capers Jones
SRM Sizing Metrics

[Ian Alyss]

Dear Capers,

Nice list! Good that you distinguish between “Automated code”, “Automated UML” and “Backfiring”, since they are essentially different. There are several tastes of “Fast”, which one do you mean? If you don’t mean the Fast Function Points from Gartner, then you should add FFPAi (which is the combination of their traditional FFPA, Configuration Points and IBRA-points). I think the Full Function Points is no longer valid, since it has been replaced by COSMIC. I only know IntegraNova as a development environment, but not as a size measure. In that case you should also add OutSystems Agile Network Sizing (ANS) and the like.

Greetings from Ireland

[Frank Vogelezang]

Dear Capers,

I definitely see improvement in the list from a similar one you published in 2008. See my personal blog “The price of IT” about that. You just mention Nesma function points in one line. I guess you mean the Nesma ISO/IEC 24570 standard for detailed function point counting. But did you realize that Nesma also has two methods for fast counting:

• Indicative FPA method for ROM estimates
• High level count for a fast, but still very accurate count

These two methods, which are also described in the standard, are very helpful when you need a size estimate fast. See this page for a short introduction.

Nesma also has a number of methods that are meant for specific environments/purposes:

• FPA for software enhancement
• FPA applied to datawarehousing
• Functional Sizing in a SOA-based environment (only in Dutch)

Maybe you can reserve some extra lines for Nesma based methods in the next version of your list.

And, maybe it’s my own fault that you included SCCQI, but as far as I am aware there is only one person in the world using that method.

Regards, Frank

[Luigi Lavazza]

Dear Capers,
your list could actually be split into two lists: one containing the different size measures, and the other containing the processes that have been proposed for the measures in the first list.
In fact, the indicative and high level counts mentioned by Frank were not proposed to defined yet another size measure, but to simplify the process of measuring already existing size metrics (namely, nesma function points). There are several such proposals, including Early&quick function points, the Tichenor method, the method based on ISBSG average weights, etc. Personally, I would not consider these as new measures, but as new simplified processes to achieve FPA size measures faster and earlier (e.g., when the functional specifications of the software to be developed are not yet fully available, thus making the application of standard measurement process impossible).
Similarly, several UML-based measures are just proposals of processes to derive the usual measures (IFPUG, COSMIC, etc.) from functional specifications provided via UML diagrams.

Concerning the first list, you could possibly add class points, although they were proposed by researcher but –as far as I know– never applied in practice.

kind regards
Luigi

[Capers Jones]

Luigi,

Thanks for your comments. Sorry for the delay – I am on a trip and was offline due to travel.

I have a patent-pending size method based on pattern matching. It can be used before requirements and takes only a few minutes to size any application. We have used it for projects ranging from about 1 function point to 300,000..

We start by placing the project on our formal taxonomy. Then we select projects with the same taxonomy pattern from our knowledgebase of about 25,000 projects. As it happens projects with the same taxonomy pattern are about the same size in function points but not in lines of code. But we can also handle lines of code for 79 languages plus combinations such as Java and SQL.

The same pattern-matching method is used by other industries such as Zillow and Trulia for comparing real-estate and the Kelley Blue Book for comparing the costs of used automobiles.

Our method is a standard feature of our Software Risk Master (SRM) tool, which also predicts size in 23 metrics at the same time. We provide size quality and and cost estimates as a service for clients in many countries: China, Canada, Peru, Israel, Japan, etc.

I can’t add class points because none of my clients use the metric and I have no data.

Regards,
Capers Jones

[Capers Jones]

Luigi,

Our sizing method is based on a formal taxonomy. It is also a standard feature of our Software Risk Master (SRM) estimating tool.

We place projects to be sized on our proprietary taxonomy and then extract similar projects from our knowledge base and aggregate their size. As it happens projects with the same taxonomy patterns are of similar sizes.

Our method does not require access to requirements or internal information.

As a result we can size any software project, and do so very rapidly.

Here are 150 samples that I put together just to illustrate that any software project can be sized using our patent-pending method.
>>150 Examples

Of course sizing by itself is only part of what clients need. Also attached are sample project results using powers of 10 from 10 to 100,000 function points. The samples are not full SRM estimates but only interesting excerpts.
>>Powers of 10

Regards,
Capers Jones

[Wim Visser]

Dear Capers,

I agree with Luigi that your first list contains several items that are not different metrics but the same metrics with only different counting/measuring procedures. Unfortunately you do not respond on the comments of Frank and Luigi. In my opinion your list contains less then 23 metrics and I am very anxious to know your opinion about their comments.

Best regards

Wim Visser

[Marten Eisma]

Dear Capers,

I see that there are a lot of methods for (product) sizing. I use product sizing mostly for estimating purpose (new projects and new releases for application maintenance puposes). The estimated product size is mostly between 300 FP and 5.000 FP with a lot of uncertainity.

The product size estimate is mostly used for estimates of effort / team size), duration and defects.

The project estimates are mostly based on business requirements, so also the product size is also estimated as a probability (with a range).

My question would be:
Is there also a model / method for evaluating to select the most relevant method for product sizing at the start of a project / release, knowing that an accuracy of +/- 10% is acceptable.

Marten Eisma

[Author]

Posts