| Author | Message | ||
     Federico Cozzi |
Hello, I am counting an enhancement project on an application which is based on a software package. The enhancement required to develop a new output screen to show some data (an existing ILF) which were not shown before. To be clear: that ILF existed before the enhancement, but was not visible on screen in any way. Since the application is based on a software package, the enhancement was developed just by configuring the system (INSERTs on system tables). Person A says that the change can't be counted since the application logic was not modified. Person B says that new DETs cross the application boundary (which didn't cross before), therefore either an existing transactional function was modified, or a new one was created. Who is right? Thanks | ||
| Steve Neuendorf |
Hello Frederico, First off, I would go with B. I would like to understand what A means by logic being modified. If the application does something it did not do before or does something different from before, it would certainly seem that the "logic" has changed. The rest of your question is confusing. How could something not visible in any way be an ILF? What that would lead me to ask is if you are not counting things in the package that are not actually used by the end user, but that is a different question. Hope this helps, Steve | ||
| Federico Cozzi |
Hello Steve, let me clarify. Both A and B agree that that data (which, by the way, is a separate table on the database) is an ILF because it was already inserted into the system and was already retrievable, but not from the user screen. The system contains many database tables (Table1, Table2 etc) which are separate ILFs. These data come from external systems (through EI). The system already has EQ transactional function(s) to provide these ILFs to external systems. The system already has the possibility to show *some* of these ILFs to the user on the screen. However this specific ILF (say it is Table7) was not visible on the user screen. It could only be retrieved from external systems. The enhancement required to show this particular ILF on screen. This was accomplished just by a few INSERTs on system tables (this is a software package) Person A says that the application "logic" was not modified (after all, no deployment took place) since the application already had the ability to look at system tables and output that ILF. In a sense, the functionality was already present in the system, and it came out by tweaking the system. This change was compared to a "configuration" in the package, just like changing the tariff options in a billing package. Person B says that this particular configuration alters the system, since it changes the DETs which crosses the application boundary. Thanks for your answer, Federico | ||
| Steve Neuendorf |
Hello Federico, As is common, you have the disadvantage of more than just the user view. It sounds like the user cannot see the data before the enhancement and can after. Whether that was a void you had to fill or just a curtain you had to pull back is really outside the user view. So person B is still offering the best reasoning. From the user view, the boundary defines a black box, and the user infers what in inside the box by seeing what enters and exits the boundary. So if what exits the boundary changes, the user view changes and it is, as you describe it here, a countable change. From your description of the count, and of course I may not be understanding it very well, you may want to have your count independently audited. As a generalization, data from other systems is available through EIF (or shared ILF) and the physical transactions are not counted. At any rate, if the application is initially counted correctly, it should be clear to both persons A and B that the end user view has changed. Hope this helps, Steve | ||
| Federico Cozzi |
Hello Steve, thanks for you reply. I am not a certified FP. Is there any reference in the FP counting method to enhancement as "development" vs "configuration"? This keeps coming out in our context and I would like to understand it more. (I am glad that you agree with B, since B is me.) Thanks, Federico | ||
| Egon W. Reich |
Hi Federico, I am not a certified FP counter, but I think that B is the right option. If the user can see new data on the application screens, and this data if meaningful to the user (business data, not technical data) then you have an application enhancement. For sizing in FP the application enhancement, you should count the FP size for all the funtions (EQ, EO) that show the new data on their screens. Coming to your last question (development vs configuration), I think that from the FPA point of view there is no difference: FPA just counts the FP size of the functions that you have modified; no matter if you modified these functions by development (writing pieces of code) or by configuration (modifying some system tables). But when you move from FP sizes to efforts (hours/FP) or costs ($/FP) there are differences: configuration effort is much less (say, 40% or less) than coding effort. This is because configuration changes don't require all the activities needed for development: usually, a configuration change requires just system testing and final testing with the end user. Regards E.R. | ||
| Federico Cozzi |
Hello Egon, thanks for your reply. Both yours and Steve's comments are insightful. I really value them. However I am interested exclusively in the FP count, that is "is this enhancement countable?" Is there any particular FP rule / guideline regarding enhancements of software packages? I couldn't find any, but I am no certified FPS. [This distinction between "configuration" and "development" keeps coming out in my context and I would like to investigate it.] Thanks, Federico | ||
| Steve Neuendorf |
Hello Federico and Egon, And I am not a developer, so maybe we can come up with an answer together. Ideally for existing software, you have a baseline from which to count and you use the enhancement rules and guidance and formulas. In CPM 4.3, Part 3 Chapter 4 is all about enhancements. The distinctions are about the user view and not the type of work being done. Anything not in the user view before is considered as Added. (Ignore conversion for now). For a development project (DFP), everything is considered added. For enhancement counts (EFP) we also consider functionality changed within or removed from the user view (Change - before and after and Deleted). Conversion is also a form of Added in DFP and EFP but is not a part of the delivered application (AFP). Within Estimating and charging, the distinction between development and configuration is real but not for the FP count. To roughly estimate an enhancement, ask the question: does the required data exist: if yes, just preform the enhancments. If no, do the DETs exist, but not the needed values? If yes you must add the transactions to acquire the values too; if no, does the data structure exist? If yes, you must modify ILFs or read EIFs and do the enhancements, if no, you must also add the ILFs and EIFs that will provide the data. In my mind if the first question is answered yes (DETs and Values) then the project is probably configuration. If you go below that, some development is probably involved, down to no DET and no structure, which would be all development for the project (which would be ADDed functionality in the enhancement count. Hope this is helpful and not too confusing. Good luck, Steve Hope this is helpful. Steve | ||
| Egon W. Reich |
Hi Federico. I think there are no official IFPUG guidelines for measuring, in some way, the customizing of ERP packages. I only read some white papers suggesting tecniques for measuring customizing using FP. I know that at least two big european customers, who implemented SAP ERP, did not estimate customizing effort using FP, or some other functional tecnique. They just estimated, in some way, the effort for customizing, and converted it to FP. Regards E.R. P.S. (April 12, 2010) Sorry, I now realize that the terminology of this post may be misleading: (1) by "customizing an ERP", I meant, more specifically, "changing the configuration of an ERP"; (2) by "SAP customizing", I meant, more specifically, "SAP IMG Activities". (Message edited by egonreich on April 12, 2010) | ||
| Charley Tichenor |
Egon -- There is a metric some organizations use for sizing ERP software customization call RICE objects. RICE stands for the counts of low, medium, and high complexity reports, interfaces, data conversions, and enhancements (or extensions such as security patches, bolt-ons, workflows, etc.) used for the particular ERP customization. RICE objects are recognized by the US Government Accounting Office (as are lines of code and function points), and at least one of the major software cost estimation tools allows its use as an option. This is a relatively new metric that seems to be catching on. It does seem to have its pros and cons. Charley | ||
| Federico Cozzi |
Hello Egon and Charley, I am afraid my definition of "software package" was misleading. Our system is not an ERP. It's a different kind of enterprise system but is still based on a software package. Your comment on SAP is however interesting. I do not know SAP. Why is SAP not particularly suited to FP counts? Is it because SAP is an ERP, or just because it's a software package? What I mean is this: could it be that our software package (which is not SAP!) is not particularly suited to FP counts just because it's a software package? For instance: is Siebel suited to FP counts? Thanks! Federico | ||
| Charley Tichenor |
I'm certainly not saying that function points do not apply to SAP or an ERP. It just depends on what you are trying to forecast. My best estimates of early software sizing using fucntion points occur when the ILFs can be enumerated. Then I use an ILF Model to estimate the size of the software, and then do the cost forecast. With ERPs, the situation is a little different in that the ERP is already a fully developed software product -- like a "kit" -- and that the cost to use it is based largely on the licenses one needs, and not on the size of the software in the kit per se. IF the ERP does not exactly meet one's needs out of the box, one must then modify it with some collection of reports, interfaces, data conversions, and extensions. It is the cost of these modifications, in general, that account for the additional development cost (licenses + additional RICE development). This is the basic idea behind the RICE metric -- at least from my relatively new experience with it. ERPs can be and have been counted using function points, and function point-based metrics like cost per function point apply just as with any other software development approach. But if one needs to forecast the cost and duration of the modifications one might want for an ERP, then many people use the RICE approach. It has its advantages and disadvantages. Charley | ||
| Egon W. Reich |
Hi Charley and Federico. Maybe my last post was a little bit misleading. I will try to clarify it.  SAP, as all ERP packages, can be easily measured in FP: after all, SAP is made by internal tables, screens, reports ... and all these objects can be easily measured by FP. There are two ways of customizing SAP to suit the user needs: customizing the product (also said "IMG Activity"), and customizing the source code. "Product customizing" (IMG Activity) is modifying SAP internal, "technical", tables to suit customer needs. The final effect of IMG Activities is modifying SAP screens, reports and so on; but often, changing only one parameter in a SAP system table can affect hundreds of screens or reports. Therefore, the correlation between the effort for IMG Activities and the size in FP of the functions impacted is not considered very good. The second type of SAP customizing is modifying the source code, which is written in ABAP language. This activity can be seen as a "traditional" enhancement activity. The effort for this activity is often estimated using FPs. So, in a nutshell: SAP data tables, screens, reports and so on can be easily measured in FP; but the effort for IMG Activities is not usually estimated using FP. Regards E.R. |
