12/05/2020 at 20:42 #24164
Hi, I recently learned about COSMIC sizing, and I wanted to share some of my initial reactions as well as get some clarifications.
1. At first, I was confused. It took me a bit too long to learn about the basic EXRW measurement technique. The website/paper should probably start with those terms, and describe the “3 phases” of measurement later. Also not sure why Entry and eXit were chosen instead of terms that don’t both start with an E. If you want to have fun with acronyms, we could use Writes Inserts Reads and Exits. 4 data movements across the WIRE 😛
2. The rule about scope and layers confused me a bit at first. In the end, I translated this in my head as basically serving multiple functions.
A) Help emphasise that work should not be done across boundaries and allow each piece to be worked on separately.
B) Help reduce confusion by comparing different scales of the project at the same time. A single function might be 4cfp, but also an entire microservice might be 4cfp but they aren’t directly comparable.
C) In my mind, this led me to think of different scales of points and to rename them. Something like cosmic epic points, cosmic story point, and cosmic function points. I understand that this isn’t the intent here, but I’d like to better understand why that is.
3. One of the biggest side benefits I see of using COSMIC functional points is giving clarity and insight into whether or not the function unit is designed correctly. If you find your actual implementation having a much larger CFP score than the estimate, that’s a good indication that the functional unit can benefit from some high-level refactoring.
I think there is a lot of benefit in replacing story points or time-based estimates with CFPs, and I’m rather sad that I only learned about this now, instead of 10-15 years ago.
13/05/2020 at 21:02 #24168
Thanks for your interesting and stimulating feedback, most welcome!
1) There is a 6 page introduction to COSMIC in the Knowledge base (free download) that responds to your comment. It is: ‘What is a COSMIC function point’. I’ll forward your comment on the website to the web team, if agreed the current Introduction could be replaced by the said document. Obviously we want to keep the COSMIC method stable, however using an pronounceable acronym is a good idea: where needed we could use the more or less pronounceable WREX as an alternative that doesn’t require change of long-existing abbreviations.
2) I agree with you’re A) and B): sizes of software of different character may not be directly comparable. Your point C): the benefit of COSMIC is that it sizes the content of requirements (i.e. functionality), not the form of requirements. Introducing different points would complicate comparison of productivity of development for yet another variable (form of requirements) is involved. Besides, many other forms of requirements exist and may arise. different scales would be confusing.
A difference in size between estimate and implementation should at least result in an investigation into the causes of the difference, so that these causes can be envisaged as much as possible (incomplete requirements, scope creep, non-functional requirements implemented as functional requirements, etc.).
14/05/2020 at 13:39 #24170
Thank you Arian for the response.
I think different scales would actually be less confusing than the current rules. I had to explain this point 3 times in the past few days, as each person kept bringing up the point that a function is the same size as a website, but clearly not the same amount of work.
My mind was thinking, “you don’t use inches to measure a country’s border”. Maybe using the metric system here would make sense? (MicroCFPs, CFPS, MegaCFPs.) Obviously, the system should be stable and I wouldn’t suggest making this part of the standard. However, I want to make sure that doing this in our own team won’t lead to some already known bad side-effects.
A new question arose today, and that was the complexity/size of software based on what sort of tests would be required to ensure it is working. Should the number of e2e tests which need to be recorded be added to the calculation? .. actually I think I’ll make a new post about this.
16/05/2020 at 22:47 #24173
The way to solve the ‘same size but different effort’ issue is solved by using a separate regression model for effort estimating, each one for comparable pieces of software. For the diferent units I refer to my previous response, note also that a kilo of lead and a kilo of gold are both measured in kilo’s, apparently this suffices, i.e. the difference in price is kept out of the unit of weight.
Your point on e2e testing sounds interesting, I look forward to your post.
17/05/2020 at 09:42 #24176
I’m having a hard time wrapping my head around your analogy.
When looking at software size, we often have to deal with layers of abstraction. The more abstract the layer, the simpler and “smaller” the software looks, but underneath that abstraction, the software can get pretty big. In my mind, the higher-level abstraction could be measured in kilograms while the low-level implementation details might be measured in grams.
The effort/size here in my view is more related to “how hard is it to get the abstraction right” rather than being some factor related to “comparable software” because there isn’t really any other software to compare it to. The abstractions required are unique to the software being developed.
What am I missing?
20/05/2020 at 16:46 #24194
The COSMIC method allows to extent the method ‘locally’ (for instance within a company), which may support experimenting with your ideas more formally. I refer to Part 2 of the Measurement Manual, section 4.1.
- You must be logged in to reply to this topic.