- Dit onderwerp heeft 12 antwoorden, 5 stemmen, en is voor het laatst bijgewerkt 6 jaar, 10 maanden geleden door
.
-
Berichten
-
Ik heb een door de gebruiker gedefinieerde vereiste dat ik tijdens het uitvoeren van een externe invoer de locatiecoördinaten moet verzenden (Lengtegraad, Breedtegraad, Hoogte) waarvoor ik Google API zal gebruiken & op basis van het antwoord dat ik zal sturen & sla de locatiecoördinaat op in het systeem.
Ik denk dat Google-bestanden waarnaar wordt verwezen, kunnen worden geteld als een EIF.
Is mijn begrip correct?? Deskundig advies nodig.
Ook in Google (Deze locatiegegevens), wordt het beschouwd als een ILF?
Ja Ankur Ik heb dezelfde vraag: hoe je het gebruik van een bestaande webservice meetelt.
Moeten we de Google-webservice zien om een coördinaat om te zetten in adresinformatie als een extern interfacebestand EIF?
Of moeten we de aanvraag aan deze webservice zien als een External Output EO (terwijl we informatie over onze systeemgrens verzenden)?
Of moeten we ze allebei tellen?Hoe tellen anderen dit?
Hallo Anku,
U werkt op een externe ingang, die deel uitmaakt van een of ander systeem. Laten we dit systeem System_A . noemen. Het bestudeerde systeem is dus System_A. We tellen een EI van System_A, geven 4 FP (uitgaande van gemiddelde complexiteit).
Vanaf System_A hoeft hier geen EO te worden geteld, als het uitgaande bericht naar Google (API-verzoek) is geen elementaire functie. Het maakt deel uit van de EI en dit bericht is niet de primaire bedoeling van de actie van de gebruiker. Om dezelfde reden het inkomende bericht van Google (API-reactie) is niet te tellen.Laten we nu eens kijken naar de Google API zelf. Het bestaat, verandert niet en bevindt zich buiten System_A. Dus geen FP te tellen hier.
Moet de Google-webservice (API) gezien worden als een EIF? Als we zouden moeten, dan moet de webservice kwalificeren als een EIF, wat betekent dat de EIF-definitie van toepassing is op de webservice.
Nesma zegt: Een extern interfacebestand (EIF) is een logische groep van permanente gegevens gezien vanuit het perspectief van de gebruiker die aan elk van de volgende criteria voldoet::
• Het wordt gebruikt door de applicatie die moet worden geteld en
• Het wordt niet bijgehouden door de applicatie die moet worden geteld en
• Het wordt onderhouden door een andere applicatie en
• Het is direct beschikbaar voor de toepassing die moet worden geteld.
En bovendien:
• Een extern interfacebestand moet een intern logisch bestand zijn van een andere toepassing.
Dit geldt niet allemaal voor de webservice, dus de webservice is geen EIF.
Ifpug zegt:: Een gegevensfunctie wordt geclassificeerd als een
b) Extern interfacebestand (EIF) als het is
• waarnaar wordt verwezen, maar niet onderhouden, door de applicatie die wordt gemeten, en
• geïdentificeerd in een ILF in een of meer andere toepassingen.
Dit geldt niet voor de webservice, dus de webservice is geen EIF.
Ook bevat de webservice niet de ILF(s) waarnaar verwezen wordt.
Waar de gevraagde gegevens zich binnen Google bevinden, is onbekend. Google levert het gewoon, het geven van een correct bericht dat ernaar is verzonden.
Dus geen EIF geïdentificeerd hier.Ik hoop dat dit helpt!
vriendelijke groeten,
Martin Jacobs
QSM EuropeHallo Martin,
Jij zegt “Dit geldt niet allemaal voor de webservice, dus de webservice is geen EIF.”
Kunt u uitleggen welke van deze criteria niet van toepassing zijn op de Google API?Laten we zeggen dat we de functionaliteit in de Google Api gebruiken om een adres uit een postcode te halen.
Deze API heeft gegevens voor alle bekende postcodes en de bijbehorende coördinaten
Ook deze api heeft gegevens voor veel coördinaten hun adresinformatie (straat, stad, land, enzovoort).1. Het wordt gebruikt door de toepassing die moet worden geteld
Ja ons systeemA maakt gebruik van de Google API .Het wordt niet onderhouden door de applicatie die moet worden geteld
Nee, ons systeemA houdt de gegevens van de Google API niet bijHet wordt onderhouden door een andere applicatie
Ja, mensen bij Google hebben applicaties die deze informatie bijhouden.Het is direct beschikbaar voor de toepassing die moet worden geteld.
Ja, ons systeem kan de functionaliteit direct aanroepen om de gegevens op te halenEen extern interfacebestand moet een intern logisch bestand zijn van een andere toepassing
Ja, De postcode, coördinaten en adresgegevens zijn ILF in de Google-applicatieDus je ziet, ik denk dat aan alle criteria is voldaan.
Vertel ons aan welke criteria u denkt dat er niet aan wordt voldaan, zodat we van elkaar kunnen leren.bedankt,
AlexanderHallo Alexander,
ik zal mijn best doen!
Zie mijn reactie op uw punten tussen <mj> … </mj>
Jij zegt “Dit geldt niet allemaal voor de webservice, dus de webservice is geen EIF.”
Kunt u uitleggen welke van deze criteria niet van toepassing zijn op de Google API?Laten we zeggen dat we de functionaliteit in de Google Api gebruiken om een adres uit een postcode te halen.
Deze API heeft gegevens voor alle bekende postcodes en de bijbehorende coördinaten. Ook deze api heeft gegevens voor veel coördinaten hun adresgegevens (straat, stad, land, enzovoort).
<mj> Ik denk niet dat de API “heeft” de data. Het kan het voor je krijgen, omdat het een interface is. Beschouw je API als een systeem zelf?, of is Google het systeem dat u overweegt? </mj>1. Het wordt gebruikt door de applicatie die moet worden geteld Ja, ons systeemA gebruikt de Google Api .
<mj> ik ben. dit betekent niet dat het een gegevensfunctie is. </mj>Het wordt niet bijgehouden door de applicatie die moet worden geteld Nee, ons systeemA houdt de gegevens van de Google API niet bij
<mj> Het doet niet. Nog altijd: bevat de API de gegevens?? </mj>Het wordt onderhouden door een andere applicatie
Ja, mensen bij Google hebben applicaties die deze informatie bijhouden.
<mj> Houden mensen bij Google informatie bij binnen de API?? </mj>Het is direct beschikbaar voor de toepassing die moet worden geteld.
Ja, ons systeem kan de functionaliteit direct aanroepen om de gegevens op te halen
<mj> U kunt de gegevens ophalen, maar hoe weet je dat het de werkelijke gegevens zijn?? </mj>Een extern interfacebestand moet een intern logisch bestand zijn van een andere toepassing Ja, De postcode, coördinaten en adresgegevens zijn ILF in de Google-applicatie
<mj> Hoe weet je dit? Er kunnen verschillende ILF's zijn om deze gegevens samen te stellen. Hoeveel zou je aannemen?? </mj>Dus je ziet, ik denk dat aan alle criteria is voldaan.
Vertel ons aan welke criteria u denkt dat er niet aan wordt voldaan, zodat we van elkaar kunnen leren.
<mj> Zie mijn reacties. Ik denk dat je veel aannames doet. Heb je de specificaties die ze ondersteunen?? </mj>Ik kijk uit naar de voortzetting van deze discussie, omdat ik denk dat deze voor velen van ons belangrijk is!
vriendelijke groeten,
MartinGoogle heeft veel API naar Google Maps gepubliceerd.
Je leest ze hier: https://developers.google.com/maps/documentation/geocoding/start
Daar lees je de “Verzoek en antwoord voor omgekeerde geocodering (adres opzoeken)” functionaliteit.
Je vertelt het wat filtergegevens en Google presenteert een lijst met gegevens:
adres_componenten
en
formatted_address
Ik hoef dus niet veel technische details te weten over de technische manier waarop de gegevens worden opgeslagen.
Google vertelt me een logische lijst met adressen.Vanuit gebruikersperspectief zijn dit de logische gegevens die worden gebruikt.
Maar als je wilt, kunnen we ons eigen voorbeeld maken met een systeemB dat gegevens levert via een api en voor dat voorbeeld weten we precies hoe de gegevens worden opgeslagen. Hebben we dat voorbeeld nodig of kunnen we doorgaan met Google Maps als voorbeeldgeval??
Laten we doorgaan met Google Maps als voorbeeldgeval.
Dit is de kern van je redenering, I denk:
Je vertelt het wat filtergegevens en Google presenteert een lijst met gegevens:
adres_componenten
en
formatted_address
Ik hoef dus niet veel technische details te weten over de technische manier waarop de gegevens worden opgeslagen.
Google vertelt me een logische lijst met adressen.Vanuit gebruikersperspectief zijn dit de logische gegevens die worden gebruikt.
Ik concentreer me op je laatste zin.
Google Maps stuurt een dataset die ik dan kan gebruiken.
Betekent dit dat in uw ogen een dataset van buiten de systeemgrens die u ter beschikking wordt gesteld altijd een EIF is??
Bevat deze dataset permanente data die wordt onderhouden door Google Maps?Ja, laten we beginnen met de zin: “Google Maps stuurt een dataset die ik dan kan gebruiken”
Je hebt twee vragen:
1. Betekent dit dat in uw ogen [van] een aan u ter beschikking gestelde dataset van buiten de systeemgrens is altijd een EIF?
Misschien het woord “altijd” is te sterk, maar ja, ik denk dat je dit als een EIF kunt zien.
Ik denk aan een voorbeeld van het telteam van Nesma dat een situatie beschrijft waarin twee ILF's voor één systeem één EIF kunnen zijn voor een extern systeem: https://nesma.org/freedocs/additional-example-06-code-and-description/2. Bevat deze dataset permanente data die wordt onderhouden door Google Maps?
Ja, ik denk echt dat dit permanente gegevens zijn binnen het Google Maps-systeem: het is beschikbaar voor gebruik en niet alleen beschikbaar op aanvraag en vervolgens geconsumeerd (weg). Met andere woorden: Het Google Maps-systeem kent voor elke postcode een straat en een stad. Dit is bekend voorafgaand aan het API-verzoek en is nog steeds bekend bij het systeem na het API-verzoek. Voor een perspectief van het API-verzoek zijn dit permanente gegevens.Telt u de door u gevraagde en aan u verstrekte DET's als: 1 EIF?
Weet u met zekerheid welke ILF's van Google Maps worden opgevraagd om de aan u ter beschikking gestelde gegevens te verstrekken??
Laten we eens kijken naar het voorbeeld waarnaar u verwijst.
Als je de zekerheid hebt, dan moeten deze worden benoemd en geteld. Er kunnen er meer dan één zijn.
Als je deze zekerheid niet hebt, dan moet er een aanname worden gedaan. Het voorbeeld maakt duidelijk dat verschillende FP-analisten verschillende veronderstellingen kunnen maken, resulterend in verschillende tellingen. Dit is waar ik naar verwees met mijn opmerking over aannames in mijn eerste reactie op jou en in: Een extern interfacebestand moet een intern logisch bestand zijn van een andere toepassing Ja, De postcode, coördinaten en adresgegevens zijn ILF in de Google-applicatie
<mj> Hoe weet je dit? Er kunnen verschillende ILF's zijn om deze gegevens samen te stellen. Hoeveel zou je aannemen?? </mj>.
Tel je de webservice gewoon als een EIF? Documenteer je er een veronderstelling of verklaring mee?? Ik probeer de telverschillen van FP-analisten te minimaliseren.Hallo Martin, je blijft vragen stellen. Te veel voor mij, het is te verwarrend in een chat.
persoonlijk, in de meeste gevallen zie ik een webservice binnen SystemB die door SystemA wordt gebruikt als één EIF voor SystemA.
Ik documenteer dit niet vaak, omdat het heel gebruikelijk voor mij is om dit te doen.Dus hoe tel je voor het voorbeeld??
Wow dit was een hele mond vol. Ik heb veel van deze zelfde scenario's en moet de beste manier begrijpen om het op maat te maken. Ik gebruik de NESMA Estimated dimensioneringsmethode.
Ik gebruik USPS om het adres te valideren, dus in dit geval, het lijkt erop dat ik een EIF zou hebben (voor het adres dat USPS naar mij terug zal sturen) en een EQ voor het USPS-adres dat op verzoek van validatie naar de klant wordt geretourneerd (met andere woorden, de EQ die de gebruiker ziet als het USPS-adres en deze kan selecteren of het ingevoerde adres kan behouden) en een EIF voor het adres dat USPS bewaart en onderhoudt. Wat betreft een extra EQ (dat is het bericht van mijn systeem naar de USPS-webservice) en de EI (voor het bericht terug met het geldige adres)... Ik kies ervoor om deze niet afzonderlijk te tellen omdat ze deel uitmaken van de primaire EQ die de klant ontvangt als het USPS-adres om te gebruiken of te behouden wat de klant in het systeem heeft ingevoerd.
Ik gebruik ook Google maps om te controleren of het adres geldig is en om te zien waar ik kan bezorgen. Ik kan me voorstellen dat het hetzelfde wordt geteld als het USPS-scenario hierboven.
Kun je helpen?? Bedankt.
Voor de Validatie van USPS-adressen, een nieuw onderwerp is begonnen, om de discussie gericht te houden. Gebruik de rest van deze thread alleen voor opmerkingen over het gebruik van Google API.
- Je moet ingelogd zijn om op dit onderwerp te reageren.