- 这个话题有 12 回覆, 5 声音, 最后更新 6 年份, 5 月 前 通过
.
-
帖子
-
I have a user defined requirement that while performing an external input I have to send the location coordinates (Longitude, Latitude, Altitude) for which I will use Google API & based on the response I will send & save the location coordinate in the system.
I think that Google files which are referenced can be counted as an EIF.
Is my understanding correct? Need Expert advice.
Also in Google (This location data), will it be considered as an ILF?
Yes Ankur I have the same question: how to count the use of an existing webservice.
Should we see the Google webserivce to transform a coördinate to address information as an External Interface File EIF?
Or should we see the request to this webservice as an External Output EO (as we are sending information over our system-border)?
Or should we count both of them?How are others counting this?
Hello Ankur,
You are working on an External Input, which is part of some system. Let’s call this system System_A. So the system under study is System_A. We count an EI of System_A, giving 4 FP (assuming average complexity).
From System_A no EO is to be counted here, as the outgoing message to Google (API request) is not an elementary function. It is part of the EI and this message is not the primary intent of the user’s action. For the same reason the incoming message from Google (API response) is not to be counted.Now let’s consider the Google API itself. It exists, doesn’t change and resides outside System_A. So no FP to be counted here.
Should the Google webservice (API) be seen as an EIF? If we should, then the webservice should qualify as an EIF, which means that EIF definition applies to the webservice.
Nesma says: An external Interface File (EIF) is a logical group of permanent data seen from the perspective of the user that meets each of the following criteria:
• It is used by the application to be counted and
• It is not maintained by the application to be counted and
• It is maintained by another application and
• It is directly available to the application to be counted.
And furthermore:
• An external Interface File must be an Internal Logical File of another application.
Not all of this applies to the webservice, so the webservice is not an EIF.
Ifpug says: A data function shall be classified as an
b) External Interface File (EIF) if it is
• referenced, but not maintained, by the application being measured, 和
• identified in an ILF in one or more other applications.
This does not apply to the webservice, so the webservice is not an EIF.
Also the webservice does not contain the ILF(小号) 参考.
Where the requested data resides within Google will be unknown. Google will simply provide it, giving a correct message sent to it.
So no EIF identified here.希望这可以帮助!
问候,
马丁·雅各布斯
QSM欧洲Hello Martin,
You say “Not all of this applies to the webservice, so the webservice is not an EIF.”
Could you explain which of these criteria does not apply to the Google Api?Let’s say we are using the functionality in the Google Api to get an address from a zipcode.
This Api has data for all known zipcodes and the corresponding coordinates
Also this api has data for a lot of coordinates their adress information (street, city, country, 等等).1. It is used by the application to be counted
Yes our systemA uses the Google Api .It is not maintained by the application to be counted
没有, our systemA does not maintain the data of the Google ApiIt is maintained by another application
是, people at Google have applications that maintain this information.It is directly available to the application to be counted.
是, our systemA can directly call the functionality to retreive the dataAn external Interface File must be an Internal Logical File of another application
是, The zipcode, coordnaties and address information are ILF in the Google applicationSo you see, i think all criteria are met.
Please tell us which criteria you think is not met, so we can learn from each other.thank you,
AlexanderHello Alexander,
I will do my best!
See my response to your points between <mj> … </mj>
You say “Not all of this applies to the webservice, so the webservice is not an EIF.”
Could you explain which of these criteria does not apply to the Google Api?Let’s say we are using the functionality in the Google Api to get an address from a zipcode.
This Api has data for all known zipcodes and the corresponding coordinates Also this api has data for a lot of coordinates their adress information (street, city, country, 等等).
<mj> I don’t think the API “has” the data. It can get it for you, as it is an interface. Do you consider API to be a system itself, or is Google the system you are considering? </mj>1. It is used by the application to be counted Yes our systemA uses the Google Api .
<mj> I.m.o. this does not imply it is a data function. </mj>It is not maintained by the application to be counted No, our systemA does not maintain the data of the Google Api
<mj> It does not. Still: does the API contain the data? </mj>It is maintained by another application
是, people at Google have applications that maintain this information.
<mj> Do people at Google maintain information within the API? </mj>It is directly available to the application to be counted.
是, our systemA can directly call the functionality to retreive the data
<mj> You can retreive the data, but how do you know it is the actual data? </mj>An external Interface File must be an Internal Logical File of another application Yes, The zipcode, coordnaties and address information are ILF in the Google application
<mj> How do you know this? There might be several ILFs to compose this data. How many would you assume? </mj>So you see, i think all criteria are met.
Please tell us which criteria you think is not met, so we can learn from each other.
<mj> See my responses. I think you are making a lot of assumptions. Do you have the specs that support them? </mj>I am looking forward to continuation of this discussion as I think it is important to a lot of us!
问候,
马丁Google has published a lot of API to Google Maps.
You can read them here: https://developers.google.com/maps/documentation/geocoding/start
There you can read the “Reverse geocoding request and response (address lookup)” functionality.
You tell it some filter data and Google profides a list of data:
address_components
和
formatted_address
So i don’t need to know a lot of technical details about the technical way the data is stored.
Google tells me a logical list of address.From a user perspective this is the logical data that is used.
But if you prefere we can create our own example with a systemB that provides data through an api and for that example we exactly know how the data is stored. Do we need that example or can we continu with Google Maps as the example case?
Let’s continu with Google Maps as the example case.
This is the core of you reasoning, I think:
You tell it some filter data and Google profides a list of data:
address_components
和
formatted_address
So i don’t need to know a lot of technical details about the technical way the data is stored.
Google tells me a logical list of address.From a user perspective this is the logical data that is used.
I focus on your last sentence.
Google Maps sends a dataset which is then available to me to use.
Does this mean that in your view a dataset from outside the system boundary made available to you always is an EIF?
Does this dataset contain permanent data which is maintained by Google Maps?Yes let start with the sentence: “Google Maps sends a dataset which is then available to me to use”
You have two questions:
1. Does this mean that in your view [的] a dataset from outside the system boundary made available to you always is an EIF?
Maybe the word “always” is to strong, but yes, i think you can see this as an EIF.
I think of an example provided by the counting team of Nesma that describes a situation where two ILF’s for one system can be one EIF for an external system: https://nesma.org/freedocs/additional-example-06-code-and-description/2. Does this dataset contain permanent data which is maintained by Google Maps?
Yes i do think that this is permanent data within the Google Maps system: it is available to use and not only available during request and then consumed (gone). 换一种说法: Google Maps system knows for each zipcode a street and a city. This is known prior to the API request and is still known by the system after the API request. For for a perspective of the API request this is permanent data.Do you count the DETs asked by and provided to you as 1 EIF?
Do you know with certainty which ILFs of Google Maps are queried to provide the data made available to you?
Let’s look at the example you refer to.
If you have the certainty, then these should be named and counted. There might be more than one.
If you don’t have this certainty, then an assumption should be made. The example makes clear that different FP analysts can make different assumptions, resulting in different counts. This is what I referred to with my remark about assumptions in my first response to you and in: An external Interface File must be an Internal Logical File of another application Yes, The zipcode, coordnaties and address information are ILF in the Google application
<mj> How do you know this? There might be several ILFs to compose this data. How many would you assume? </mj>.
Do you simply count the webservice as an EIF? Do you document any assumption or explanation with it? I am trying to minimise FP analyst counting differences.Hi Martin, you keep asking question. To many for me, it is to confusing in a chat.
Personaly, in most cases I see a Webservice inside SystemB used bij SystemA as one EIF for SystemA.
I don’t document this a lot as it is very usual for me to do so.So how do you count for the example?
哇这真是满嘴. 我有许多相同的情况，需要了解确定尺寸的最佳方法. 我使用NESMA估算尺寸.
我使用USPS验证地址，因此在这种情况下, 看来我会有EIF (USPS将返回给我的地址) 并在验证请求后将USPS地址的EQ返回给客户 (换一种说法, 用户看到的EQ是USPS地址，可以选择它或保留输入的EQ) 以及EUS保留和维护的地址的EIF. 至于一个额外的情商 (这是从我的系统到USPS Web服务的消息) 和EI (使用有效地址返回邮件)…I am choosing to not count these separately as they are part of the primary EQ that the customer receives as the USPS address to use or keep what customer entered into the system.
我还使用Google地图来验证地址是否有效，并查看在哪里送货. 我想它的数量与上面的USPS场景相同.
你能帮我吗?? 谢谢.
- 您必须登录才能回复此主题.