| Author | Message | ||
     Swee Lim |
We are using FP to measure the total FP count for our application. While doing that, we are facing the following problem of having HIGH Complexity for simple function we are developing. Description of our application: We have two groups of API: Query API and Maintenance (create, update, delete) API. For each API, we would like to capture System Log (contains any messages) as well as Performance Log (contains performance time). The underlying implementation of handling these logs is provided by a separate application (third party). What each API does is to dump the data (for system log) and start/end time (for performance log) to the 3rd party application. In the first estimation, we treated System Log and Performance Log as 2 separate Logical Files since the data is going out from system boundary. About the File Types Referenced factor, we use "0-1" as Low, "2" as Average and ">=3" as High. The problem we have with this estimation is since we always have at least 3 Logical Files in our API (1 from System Log, 1 from Peformance Log and at minimum, 1 from the file being manipulated in the API), it force us always have Average to High complexity (depends on Data Element Types)since it is always fall within the last row in the Complexity Matrix. This is what we mentioned: Simple API in actual VS HIGH Complexity in FP count. We are thinking of using the following methods to resolve this problem: 1) Treat System Log and Performance Log as separate API/application and do a separate FP count for each of them. This will help ensure that the simple API we built will have Low or Average Complexity in FP Count. 2) Customize the File Types Referenced factor to: "3-4" as Low, "5" as Average and ">=6" as High. This is based on our understanding that each API will have at least 3 Logical Files. If you have any idea to contribute, really appreciate that. Thank You! SH | ||
| GUNESH APTE |
Hi, Since you have CRUD API, as a part of single application, to me, it looks like that, the Application Boundry should be drawn in such a way that, it results in ONE SINGLE APPLICATION. It is not logical to treat System Log and Performance Logs, as two applications. System log file and Performance log file are created as a part of each CRUD Transaction; hence there is only one APPLICATION as far as counting FP is concerned. Also, Cutomization of the FTR Referred look outside the scope of the FP counting practices. Those number of FTRs must have been decided based on lot of research at IFPUG, and emperical data, and historical results. So to me, it looks completely illogical to change the FTR numbers, for convinience of our counting. Another point to be kept in mind is that, only the permanent/persistent data which is maintained by the Application is to be considered as FTR. I recommend that, you can validate this, whether System Log and Performance Log are permanent data stores; which are maintained by your application. As per my understanding, if these Logs are created for temperory storage, of say few days, then it need not be counted as FTR. I would like to see some more postings on this topic, to see other's views on this case. - Gunesh Apte Mahindra British Telecom Ltd, Mumbai-400072, India | ||
| Swee Lim |
Gunesh, The data captured into system log and performance log is used for monitoring and debugging. These data will be purged in some pre-determined timeframe. By the way, since functionality of System Log and Performance Log are provided by single 3rd party application, should it be treated as 2 ILF or 1 ILF? Back to the basic problem we have, from FP analysis, the API with HIGH Complexity will result in Simple API in actual built. FP failed to reflect the actual complexity of the API we built. Regards, SH | ||
| Gene Fellner |
Log files are generally not counted in FP analysis. Older versions of the CPM specifically pointed this out; I'm not sure if the language was retained in the current version. In order for a log file, audit trail file, security backup file, etc., to be counted as a File Function, end-user functionality must exist to access the data. Since you explained that this data is only available to technical staff for monitoring and debugging, it does not satisfy the definition of a File Function. Therefore, you must not count these files as ILFs and you must not include them as FTRs in rating Transactional Functions. I hope this has been of some help. | ||
| GUNESH APTE |
Hi Gene, It is true that, FP Size is from the perspective of the sophisticated end-user; and hence system logs & performance logs should not be considered as ILF. But what if, these log files are purged into some single file, which can be accessed by the system administrator, to monitor the overall performance of software system. Can we consider it as ILF, in this case. System Administrator is also one of the users of the system. What are your views about this aspect? I would highly appriciate your opinion on this, as this is a common problem, which we are also facing in our projects. As whether to count functionality associated with System/Performance Logs as a part of FP Count or not. Many people are of the opinion that, we spend efforts to build this functionality and if we do not size it, then the efforts derived from the size does not reflect correct figures. At times, in some software systems, lot of software code is written to create such system & audit trails, and is major work in the work package. - Gunesh Apte Mahindra British Telecom Ltd, Mumbai-400072, India | ||
| Swee Lim |
Hi Gunesh, For our case, since System Log and Performance Log is built into separate application, we have size it separately. The only effort for the current application (or client application) we are building is the effort to use the client portion of the System Log and Performance Log application to capture the log messages into respective files (handle by the server portion of the application). So, to the client application, every minimum effort is required to log either System or Performance log. SH | ||
| Gene Fellner |
Ganesh, I think you should take a close look at your Application Boundary Diagram. In most MIS end-user software (as opposed to infrastructure, communications, compilers, avionics, factory control, etc.), the system administrator is NOT considered an end user. She is usually a member of the IT staff. So you are correct that she is a USER, but she is not an END USER. That is an important distinction. The people in system operations, the help desk, data security, contingency planning, PMO, and other support or staff organizations interact with the application and may even have their own menus and their own transactions. But from the perspective of the true end user, all of that functionality is invisible and occurs inside the application boundary. I notice that you use the term "sophisticated end user." That is OK if what you mean is "an end user with a sophisticated understanding of the BUSINESS requirements." But many people will think that what you mean is "an end user with a sophisticated understanding of COMPUTER TECHNOLOGY." In order to avoid that ambiguity, I teach my students to use the term "an end user who has extensive knowledge of the company's business processes, but is not very computer-literate." I hope this is helpful. Gene | ||
| GUNESH APTE |
Hi Gene, I can understand your view-point. I am aware that, as per IFPUG definition of the end-user, she is the one who is "an end user who has extensive knowledge of the company's business processes, but is not very computer-literate." I am quite comfortable with this interpretation of an end-user. The problem lies in the fact that, FP Size does not reflect the efforts which software developers spend in developing the code, which generates the system logs, performance logs and audit trails. Since as a project manager, we have to derive the efforts (in person-days) from the FP Size, it is important that, the estimated efforts are accurate and reflect the real efforts, which software developers have to spend in building the software. Since the productivity figures are also based on FP Size and Efforts, it very important to get these figures right. If we do not count the system log, performance log and audit trail development, as a part of FP Size, often FP count goes down and that has further impact on Productivity metrices. Since we take more man-days to complete lesser FPs, the productivty figure i.e. No Of FPs/person-days goes down. Hence, software professionals in our company tend to include administrative and infrastrutural software, as a part of FP SIZE. How to go about handling this situation? May be, we need to educate them further in IFPUG FP guidelines and change our mind set, that "Every thing which goes into software project development must be counted as FP". - Gunesh Apte Mahindra British Telecom Ltd, Mumbai-400072, India | ||
| Ravi Kumar Putcha |
Hi All, I was reading through the initial post by Swee Lim and the responses with respect to the counting of the System Log and Performance Log. In order to determine whether these need to be counted (or not) as ILFs (or EIFs) would it not be relevant to try and find out who the user of the application in question is i.e. what is the primary "business" intent of the application? For instance, if this were to be a "non-business" (as in non-financial, non-telecom, non-retail) type of application but one in respect of which the ability to do performance analysis of applications and report this information or for other "scientific" processing wouldn't these two logs then become central to the application being counted and, therefore, be treated as ILFs instead of being ignored just because the CPM says so? I am not sure if such applications are FP countable as, say, a banking application (which I am more familiar with) would be - but if it were it might not be wrong to count these files as ILFs. Swee Lim, as to your question on whether you can reduce the FPs assigned to your "low complexity high FP" functionality, all I can say is "Wow". I am more familiar with the kind of questions Gunesh has asked (such as that FP does not give enought credit to such "system" files) and this is probably the first time I have come across your kind of case. On a more serious note, though, I am not aware of how to count fewer FPs for the function in question. The only possibility is that your application is not all that "complex" and you will probably end up with a rather low VAF and hence a lower UFP which might even out the initial problem you stated! I would like to hear from others on this forum about the last para of my post. | ||
| Ravi Kumar Putcha |
Hi Gunesh, Interesting post. But I must say I am wondering if there would some really experienced FP Analysts out there who would be horrified to hear that you want to know "if VAF can be used to adjust the UFP count". If that was the impression I conveyed, let me apologize. I did not mean that one can use the VAF to "doctor" the size of the application - in terms of FP "philosophy" (for want of a better term) I am almost certain that VAF is not meant to window dress the size of the app. What I meant actually was that while the individual transactional function types and data function types for the application in question might add up to a certain number of UFP, it is possible that that the "real" size of the app would be reflected in terms of AFPs and that would be an accurate representation of the size of the function which was what this post started with. | ||
| Swapnil P |
Dear All, Can you read this in conjunction with the following posting... We have discussed on a similar situation earlier. http://www.ifpug.org/discus/messages/1778/5118.html?1064388568 My views - It seems like the User of the log information is application administrator, who in turn will present the information to the business users or will use this information to improve the performance/maintainability of the application hence he should be treated as an "user". We also had a posting on data being retreived through a MQ/API for a query wherein we considered the files as ILFs. If we look it from a user point of view the primary intent of the transaction is CRUD with logging of information for each transaction. Now its not concerned with the user how the information is being logged, whether a third party tool is doing so or the same application under consideration is doing so. Here we go to implementation of the requirement which should not be considered at the time of FP analysis. Since the information logged is logically related and will be maintained for further analysis we should consider it as an ILF. For the second question about changing the FP counting rules, I think if we do that then the objectivity of the FPA will be lost and we will not have standard rules to follow so lets avoid that. Even otherwise is based on the "gut" feeling that the effort required will be less to implement it, which is again implementation view. I also agree to Gunesh's view that the effort will be required to implement this requirement, which can only be considered through FP sizing. Hope this will open up more threads for discussion. Regards, Swapnil Regards, Swapnil | ||
| Gene Fellner |
Hello all, To comment on several points: 1. "It seems like the user of the log information is the application administrator, who in turn will present the information to the business users or will use this information to improve the performance/maintainability of the application; hence he should be treated as a 'user'." What you have described is not a complete software function. It is the system administrator who delivers the information across the Application Boundary to the end users, not an automated Elementary Process. Therefore the functionality does not satisfy the definition of any of the three Transactional Functions and cannot be given a Function Point measure. 2. "The problem lies in the fact that FP size does not reflect the efforts which software developers spend in developing the code." FP size does indeed not reflect effort, but that is not a problem. FP are a measure of SIZE, not EFFORT. Effort is measured separately, by a timekeeping system. As you point out, one of the most common uses of FP is to measure software delivery rate: Number of FP delivered in one staff-month. (Or, since we often do it upside-down in the USA, Number of staff-hours to deliver one FP.) Therefore it is imperative that size and effort be maintained as two distinct measures so delivery rate statistics will bring differences like this to the staff's attention. This application contains a feature that is only partially developed. Data is derived and extracted, but not delivered to the end user. A manual process must be executed to complete the delivery of data. This means that the end users cannot access the data on demand, they have to ask an IT staff member to do it for them. There is additional opportunity for human error. They can't compare current figures to past figures without saving a stack of paper and using a calculator, or re-keying the data into a spreadsheet. This process does not offer the convenience, control, and data integrity of a fully automated function and is therefore not worth as much money to the end user as a fully automated function. Furthermore, a certain amount of software development effort was expended to deliver this less-than-fully-automated feature. The end users paid for it, but they did not get a fully automated Transactional Function for their money. The delivery rate and cost rate for this project will be impacted by these anomalies. The end users should be able to see this impact. If we contaminate size metrics by adjusting them to reflect effort, then we are losing information. The impact of developing partially automated functions will not be brought to the end users' attention so they can make a business decision as to whether the automation of the function should be completed. 3. "Maybe we need to educate them further in IFPUG FP guidelines and change our mind set that everything which goes into software project development must be counted as FP." That is correct. Everything that goes into the project must be counted as EFFORT, but not necessarily SIZE. Documentation, training, hardware configuration -- there are many deliverables from a software project that are not even software, much less countable functions. 4. "Customize the File Types Referenced factor to: 3-4 as Low, 5 as Average and >=6 as High. This is based on our understanding that each API will have at least 3 Logical Files." I strongly recommend against this type of customization in my classes. Eventually, as your organization reaches higher levels on the SEI CMM, your executives will want to compare its performance against industry, national, or global benchmarks. If you are not using the same FP counting rules as other organizations, you won't be able to do this. It is bad enough that no two organizations measure labor the same way (at least, in the USA this is not much of an exaggeration). But if they also don't measure FP the same way, benchmarks will be meaningless. I urge everyone to meticulously follow either the IFPUG AFP rules or the ISO UFP rules in measuring software. Consistency is one of the defining characteristics of an engineering discipline. I believe that if we want to be thought of as "software engineers," we must get in the habit of following standard engineering practices. Regards, Gene | ||
| Swapnil P |
Hi Gene, But if "logging information for each transaction" is a user specifed requirement then shouldn't we consider it as files in our application. Regards, Swapnil | ||
| Gene Fellner |
Not all user requirements result in File and Transactional Functions. The user may state a requirement for response time, throughput, fully automated backup and recovery, Macintosh instead of PC platforms, flat screen monitors, and a Mean Time Between Failure of six months. Some of these things will be reflected in the GSCs if you are using AFP, but none of them will be counted as Files or Transactions. Logging is just one more example of a requirement of this type. Many of the terms in the CPM are used in IT and already have generally understood meanings. But in the CPM they are given a slightly different meaning. One of these terms is "file." It is important to realize that what we thought of as a "file" when we were developing software is not the same thing as a "file" in the Function Point methodology. | ||
| Swapnil P |
The basic Question still remains unanswered. HOw do we count for the effort that would be required to implement this fucntionality? I think everyone in this forum will appreciate the effort required to implement it. If it is not counted in the size then how do we account for it? Regards, Swapnil | ||
| GUNESH APTE |
Hi Swapnil, I think, both of us seems to be talking the same language so far. If FP SIZE does not take into account the efforts to be spend on building "Infrastructural Software"(I am using this word for software which generates system logs, audit trails, performance logs etc.), then it really becomes difficult to estimate EFFORTS from the FP SIZE. I understand that, FP SIZE is derived from the "Functional User Requirements" and it should reflect only the end-user perspective of the system, leaving aside implementation issues and all infrastructural software. But there has to be some provision, so that, when we map FP SIZE into the EFFORTS (in person days), to account for this kind of user requirements, such as, creation of system logs, audit trails for system administration etc. Otherwise the productivity in terms of staff hours per FP, often goes down, resulting in more staff hours per FP. Some software professionals see this as a limitation on the part of IFPUG FP, and look at other SIZE and EFFORT Estimation models like COSMIC FFP, Weighted Use Case based size estimation, Feature Points etc., and the whole purpose of having a standard sizing mechanism, for the software industry is diluted due to this. I would like to see other's opinion on this aspect. - Gunesh Apte Mahindra British Telecom Ltd, Mumbai-400072, India | ||
| Swapnil P |
Hi All, Lets go back to the definition of "User" and not "end user" An extract from the IFPUG Manual - "A user view represents a formal description of the user’s business needs in the user’s language. Developers translate the user information into information technology language in order to provide a solution. A function point count is accomplished using the information in a language that is common to both user(s) and developers. A user view: • Is a description of the business functions • Is approved by the user • Can be used to count function points • Can vary in physical form" Some more definition - "Frequently the term end user or user is used without specifying what is meant. In this case, the user is a sophisticated user. Someone that would understand the system from a functional perspective --- more than likely someone that would provide requirements or does acceptance testing." So if we are asked to develop some business function, it is the business user who is the user of the functionality/application. If we are asked to develop a technical functionality for the system admin, then the user of that particular functionality is the system admin. The user of the application being developed doesn't necessarily mean the business end user only. Anyone who is using the system and needs some functionality (business or technical) in the system is the user of the system. The term sophisticated is explained cleary in IFPUG manual --> person who can define requirements,test the system against it, make desicions and accept the system etc I still feel that its a user requirement and we should count that as ILFs. Regards, Swapnil | ||
| Charley Tichenor |
Function points are the number of standardized units of software produced by the software development team. Function point size statistically correlates with effort, just as with probably most business situations where number of units produced correlates with work effort. When I started counting back in 1990 (and since then), I always felt that my counts were conducted according to the current IFPUG CPM; however, after every class taken at IFPUG conferences my counting skills improved. They also improved after studying the materials in the conferences’ Proceedings and questioning the seniors. As my skills improved, sometimes I realized that there was software functionality that I had previously missed. My point here is that with more training and more labor, I realized that the IFPUG function point counting methodology was quite strong and that any problems with my counts likely reflected my need for something like better counting or facilitation skills, more counting experience, or some more research. I take the initial position that if there is functionality required by one or more of the users, then part of my responsibility is to figure out how to count it. I don’t question or blame the methodology if I can’t figure it out and then try to look to other competing methods for answers. In those (very) rare cases were the CPM does not address a particular local situation, we develop a local counting standard and at least consistently apply it -- with the caveat that the local standard must improve the correlation between function point count and effort or some other similar factor important to us. Charley | ||
| Yogomaya Maharana |
Hi, Needed a answer as to how many transactions to count for the requirement below for Application A. Application A recieves feed files from Application C. Application A uses these feed files to load in its ILFs. a) 3 .dat files ( Usage Summary file, Adjustments File, and Payments Files) b) 2 reference files (Service arrangement reference file and product reference file) c) 1 Commitment file. Since this Application A is now retiring , Application A has to send these files ( reference , commitment, and data files ) to the new application (Application B). Application B will now be taking over Application A. The requirement says - "Application A will send the Feed reference, data & commitment files of all the months to application B. The feed files will be sent in the same format as they were send to Application A by Application C. |
