| Author | Message | ||
     Alejandro G Corces |
Hello, I want to know your point of view about how to count this scenario in case there is a requirement for Application A to send data to Application B and there is logic associated to propagating this data. I have discussed about this with some colleagues and we did not come to a common view of it. So the suggested scenario would be the next: A transaction processed by Application B,requires information from a data store maintained within Application A. Application A is responsible for sending the data to Application B, and Application A maintains the software for that access. There are two points of view in the discussion we had: a)There is no EQ/EO in Application A as the EP is sequential and dependent of the EP in Application B. Application B counts an EIF and the FTR in its transactional function. b) An EO/EQ is counted for Application A. Application B counts an EIF and the FTR in its transactional function. Which is your point of view? | ||
| Maxim Rusakov |
Similiar cases are analyzed in CPM 4.3 Part 3 Chapter 3. based on my understanding there are 2 possible ways of counting of shared data: 1) ILF for Application A and EIF for Application B 2) EO/EQ for Application A and EI for Application B Second case is sending from A to B transaction data. For example: line 1: DELETE_RECORD ID = 123 line 2: UPDATE_RECORD ID = 23 STATUS = APPROVED .... In all other cases it should be ILF/EIF. Does it make sense? PS It is possible that this procedure is a part of another EP. CPM states that function point counting should be perfromed based on logical (not physical) point of view. | ||
| Alejandro G Corces |
Thanks Maxim. I know there are similar cases in the CPM. I based my scenario in the first scenario of the shared data, changing some conditions that are mentioned on it. For example instead of saying that Application B is responsible for the access and maintain the software for the access I say is Application A (owner of the ILF accessed). Does this mean something or it is just the way the functionality is implemented? Instead of saying From Application A perspective, there is no requirement to send data. The data is available in Application A. No credit is given to Application A for the transaction performed by Application B, I said there is a requirement and there is logic associated in propagating data. Does this mean something or despite all, the way we have to count this process is always the same (EIF plus FTR in Application B)? | ||
| Alejandro G Corces |
Thanks Maxim. I know there are similar cases in the CPM. I based my scenario in the first scenario of the shared data, changing some conditions that are mentioned on it. For example instead of saying that Application B is responsible for the access and maintain the software for the access I say is Application A (owner of the ILF accessed). Does this mean something or it is just the way the functionality is implemented? Instead of saying From Application A perspective, there is no requirement to send data. The data is available in Application A. No credit is given to Application A for the transaction performed by Application B, I said there is a requirement and there is logic associated in propagating data. Does this mean something or despite all, the way we have to count this process is always the same (EIF plus FTR in Application B)? | ||
| Maxim Rusakov |
Alejandro, please forgive me for keeping silence fow a while. 1) In previous post my point was that there is no EPs when two applications share data. BUT 2) I've read again you post and I should say I can not understand when/how Application A decides to send data to B. Does B send a request? Does A send data based on system time / event? Maybe there is no shared data at all. It maybe a plain EO/EQ but the consumer is another system. | ||
| Alejandro G Corces |
Hi Maxim, yes, Application B sends a request to capture information needed in its transaction. | ||
| Maxim Rusakov |
For Application A: plain EO/EQ. For Application B: I would count it as FTR. | ||
| Steve Neuendorf Username: Sneuendorf Post Number: 827 Registered: 07-2002 |
Hello Maxim, I am going to disagree. The data is maintained in A and referenced by transactions in B. How that is done should be of no consequence. The first consideration is "consistent counting". In part that means if we were to count an output type for A, there should be one or more input types for B. For B to have an input type (EI) (data, and not CI), the data must be maintained in B. So ask a simple question: if I ran the same transaction again and again for B, using the same data from A, would B's transaction look to see if the value is "already there" or would it go to A each time? If the answer is go to A each time, that is a good indication of an EIF, but if not that is not an indication of underlying transactions that should be counted. The next question to ask if the data is retained and reused in B for subsequent "consumption" is that if the user cares if the values stored in B become different than those currently in A. If the user cares, then it is clearly an EIF. If not, consider the data also maintained in B by an EI from A and count the output type for B also. Finally, and most important, the request from B to A for the data is not "self-contained" and not a separate EP and cannot be counted as such. Hope this helps, Steve |
