| Author | Message | |||
     Adam Szablewski |
Hello How to count the case: Business wants billing system to have capability to store current services on request and to restore these services. Storing services will be used when a customer starts to use new service and old ones should be terminated (they should be stored). The customer gets an agreement to sign after he starts using service and to this time he has possibility to ask to terminate the new service and to restore old services for him. Then will be used functionality of restoring services in billing system. After restoring the configuration of services should be as in moment of storing them. So, from business point of view we have 2 new functionalities: 1. storing current services, 2. restoring stored services in place of new ones. The problem is: It seems these two functionalities should be counted as 2 EIs + some new ILFs for storing a few kind of services. But the first functionality is rather simple and the second one is much more complex: this is not only restoring, but process should: -verify what services should be terminated, -terminate services and move them to history, -verify if terminated services were billed - if yes the bill have to be automatically corrected (during this process), -restore services. The second functionality will be 10 times more expensive then the first one (expert estimation based on his great experience). How to show the complexity of the second functionality using FPA? best regards Adam | |||
| Adam Szablewski |
Any ideas? In fact I'm looking for common approach to count very complex processes, which are very frequent in billing systems. Any help will be valuable. Adam | |||
| Steve Neuendorf |
Hi Adam, FP is a great tool for measuring size, but it is a terrible one for measuring complexity. Even though we use "complexity" for identifying system components as Low, Average or High, it is anything but real complexity as you are faced with it. I suggest some operating definitions: "simple" would be something like applying the rules; it is the same pattern repeated many times. "Complicated" is applying several simple steps in a coordinated and integrated fashion; like doing a large application or project count. "Complex" is where the subject matter changes too, like the process you describe. Clearly the FP count does not address complexity. (See "The Checklist Manifesto" for good description.) A good clue is to look at the GSC. (For all my recent rants, I will do a rave.) The GSC, and even the guidelines, are a good list of items that are not addressed in the count but which should be addressed in the overall use of FP. One of which is "Complex Processing". Regarding your counting, it seems your primary data group is customer and services are subgroups. The processes you describe appear to be optional parts for maintain customer, and are not dependent, any more than is the new data (RETs of Customer) they maintain. Your enhancement should be changed customer ILF and changed "maintain customer" EI, as well as possibly the bill EO. Most likely there are other changes, but it does not look like there are any added functions for the count. So if you use the GSC, make sure you identify the change brought on by this project. Most likely, your DI for this item already reflects all of the other instances of Complex Processing from before, so you will need to address the complexity impact either as a part of DR and support rate and as a possible adjustment to your project estimate. Hope this helps, Steve | |||
| Adam Szablewski |
Steve, thanks for your answer. Could you give me more explanations: is not size of system change heavily connected with complexity of the change? Using VAF still gives rather small range of adjusted FP. Really, should I count the two functionalities as only 1 EI ("maintain a cutomer"): 1. storing customer's services 2. restoring them (with all activities described before)? What if for the same project there will be need to change other parts of process "maintain a customer" - the only way to get more FP is counting more FTRs and DET, but "maintain a customer" is so huge process that get the highest values of FP very fast. Should I count the 2 processes separately as 2 EIs? If yes, how to manage the problem, that cost of second EI will be probably 10 times greater than the first one? Mayby (i.e.) my company should build our own set of additional rules to allow counting nested subprocesses (like "verify if there was billing created and correct it")? thanks in advance Adam | |||
| Anand Bharadwaj |
Hi Adam, Even we are from Billing Application team and face similar issues where the application becomes highly configurable and the transactions reach highest complexity easily as more FTRs will be listed under it. We have a workaround where, the assumption is that the user is not just the end user who is billed, but 'all' identities who interact with the system. For example, if we assume billing system is reverted back to manual days, the Bill will not be generated directly by the customer himself...but by personnel inside the organization, who manually generates the bill for the ultimate user - Customer. Hence with inclusion of this the number of EPs will increase resulting in more covrege for counting exercise. | |||
| Steve Neuendorf |
Hello Adam, The answer is no. The functional size of an application, as measured with FP and the complexity of the application are two different things. The reason we are talking about FP 30 years later, is that the efforts to keep them separate have largely succeeded. We could come up with an impressive list of "size" measures that have come and gone in that time that did not make the distinction. I will stick by the way I see it should be counted; but, don't take my word. Use the CPM and its examples and see how you think it says it should be counted. And on your last point, it is not "maybe", but rather absolutely. You have to account for variation, the more you can account for and the more accurate your accounting is, the more successful your measurement. Just don't try to mix it in with FPI, and if you do, please stop calling it FP. You would find it does not work, and it will negatively affect how everything else works. I interpret Anand's suggestion as doing just that. The VAF is inadequate and inaccurate. The DI is a 5% overall adjustment, and the guidelines give only a +1% adjustment. What you describe is a discrete impact and really should be applied as a discrete adjustment for those projects where it has an impact. Hope this helps, Steve | |||
| Gianfranco Lanza |
As said by Steve, the complexity (how difficult is to realize my job) is not measurable by Function Point: they measure what I have to do not how. However we have to realize if our complexity is due to an algorithmic complexity or perhaps a complexity due to a great number of data operation (Data movements) In this latter case the use of Cosmic Function Point instead of IFPUG could help you. Best Regards CSI-Piemonte - Direzione Sviluppo Progetti www.csipiemonte.it e-mail: gianfranco.lanza@csi.it | |||
| Abinash Sahoo |
Hello Gianfranco, Quite interesting to hear about something new like COSMIC Function Point.  I hadn't come across this term earlier on this forum. I did a quick search in google and got some links. One of them from this forum, which has the guidelines document posted. http://www.ifpug.org/discus/messages/1751/4834.html?1047989493 I haven't yet gone through this document, which I certainly will, but it seems you surely are aware of this process. ( downloaded the 2009 manual from http://www.cosmicon.com/) Could you please throw some more light on this, like, how different is this from IFPUG FP. What more can one achieve by using FFP. Is it supposed to be used along with IFPUG or are these supposed to be kept completely separate. Just out of eagerness last question to a broader audience on this forum. Why do we have so many different international teams working on Function Points and each having different measurement guidelines. IFPUG, COSMIC, NESMA and may be more as well which I am not aware of. Even IFPUG itself does work separately in issuing whitepapers and guidelines for measuring functional & non functional requirements for different types of applications. So how does this all help an organization which thinks of applying FP? The most important area which I look forward to is IFPUG guidelines on deriving costs of development and other project parameters like resource , scheduling etc, not to miss the cost of NFR development as well. Any clues? Thanks & Regards, Abinash | |||
| Gianfranco Lanza |
Hello Abinash The world is well because is various! COSMIC Function Point were born to satisfy some particular software product, as for example real time products. The principal characteristics are that in Cosmic Function Point the data functions are mixed with the transaction functions (the Data Movements: each data moviments is correlated to a distinct logical group of data, there are four types of data movements, Entry, Exit, Read, Write; each one is one FP). In one single elementary process we can have a non limited number of data movements, so the weight in fp of the EPs can be very different. In my company (CSI Piemonte) we're using Cosmic Function Point to evaluate Batch processes (stream of batches), SOA Services and particular complexity Report (with many data movements), while we are using IFPUG in MIS Applications. You can not sum COSMIC FP with IFPUG FP, they are two different measures, but however you could have a sumilar productivity (FP/Hour). Till now there aren't many historical data (ISBSG Repository gives you some), the best thing in any case is to collect proper data. I attach a presentation made last year at Smef 2009 on the difference between IFPUG and COSMIC in some applications. cheers
CSI-Piemonte - Direzione Sviluppo Progetti www.csipiemonte.it e-mail: gianfranco.lanza@csi.it | |||
| Dominique Lafourcade |
Yes variety makes sometimes good business, for example we have yards and meters, and all the tools to go with each one of them. | |||
| Dominique Lafourcade |
Hello Abinash, It is a very valid reflection questioning why we have so many different standards for function points. It is clearly a problem for benchmarking, since they are not comparable, and goes in detriment of implementing function points as a whole. In my opinion if we had one clear standard, and a simple one, we would be much faster and more successful. Setting a standard is always difficult, variations and exceptions don’t help. Sincerely | |||
| P. Grant Rule |
Hi Abinash, Gianfranco, Dominique, COSMIC is hardly new. It originated in 1997/98 and has been an international standard since 2003. It was not "born to satisfy some particular software product, as for example real time products". Rather, it was designed explicitly by an international consortium of professional practitioners and academics, with contributions from some 19 countries, to: 1) resolve many known problems with the methods of functional size measurement that had been available up to 1998; 2) extend the capability of FPA so that functional size measurement could be used across a much wider range of software-intensive systems; 3) develop an FPA method that conforms to the rigorous scientific principles that apply to the definition of scales of measurement (which none of the other FPA methods do); 4) comply with ISO 14143, the international standard for all functional size measures; 5) be applicable to both small, simple monolithic architectures and to large, complex architectures; 6) be suitable for the purposes of performance measurement and estimating… and hence, benchmarking; 7) be independent of technology, tools, people & process… in order to facilitate comparisons of the performance outcomes resulting from the use of different varieties of these things; 8) be easily mapped "to concepts commonly in use in modern software development to enable ease-of-teaching, ease-of-use and acceptability, but especially to increase the chances of persuading tool vendors to provide automatic sizing"; 9) recognise the ubiquity and rigour of the input-process-output model of 'elementary process' (aka logical transaction aka stimulus/response pair aka thread-of-control, etc) as the 'minimum deliverable feature' and to accommodate 'polling' and 'interrupts'; 10) create a size measurement scale that reflects 'the use of data' aka 'the amount of information processing' required & performed; 11) produce a size measurement scale that has a clearly defined 'unit' of measure, and that is a true ratio scale, with a natural zero, where equal steps on the scale equate to equal amounts of information processing; and 12) provide a measure of functional size that, given the theoretical constraints, is compatible with older FPA methods and to provide guidance for converting between COSMIC and alternative measures of functional size. You may say that all this was a 'tall order'. But with lots of effort and significant contributions from around the globe, the enterprise was successful. Today, the COSMIC Measurement Manual is available in Arabic, Chinese, Dutch, English, French, German, Italian, Japanese, Spanish. It is applicable to, and used for, measuring business & MIS systems of all kinds, and for measuring real-time & embedded systems. It offers very significant benefits to those just adopting functional size measurement, and many advantages to users of existing 1st generation methods of FPA. Not least, the fact that COSMIC provides a defined unit of size: 1 datamovement = 1 COSMIC Function Point. Attached herewith is an Adobe Acrobat .PDF document offering an objective comparison of four ISO-standard methods of functional size measurement. I hope you find this helpful. Standards evolve and improve. Just as the engineering establishment moved away from mediaeval measures such as the cubit, the span, and the cloth-yard, to use the SI units metre, second, kilogram, kelvin, etc, so modern software engineers are moving to take advantage of the benefits provided by COSMIC. Note: I still have copies of the original correspondence between Charles Symons, myself and others from 1997/98, from which the above has been derived. Best regards, Grant (PG) Rule <g.rule@measuresw.com> @pg_rule
Software Measurement Services Ltd. [ www.measuresw.com ] 124 High Street, Edenbridge, Kent, TN8 5AY UK T: +44(0)1732 863 760 F: +44(0)1732 864 996 | |||
| Gianfranco Lanza |
Yes, you are absolutely right P. Grant; simply there are some particular environments in wich IFPUG Function Point are not so suitable, in my opinion, one of this is about Real Time System. Thanks for puntualization. About standardization I think that diversity has to be a value, not a defect. Cheers CSI-Piemonte - Direzione Sviluppo Progetti www.csipiemonte.it e-mail: gianfranco.lanza@csi.it | |||
| Abinash Sahoo Username: Abinash Post Number: 23 Registered: 05-2010 |
Hi Gianfranco, Dominique, Grant Thanks a lot for all your valuable views. Thanks & Regards, Abinash. |
Ifpug Function Points or Cosmic Function Points?
