Nesma-Homepage Foren Sizing Sizing – FPA Google API zum Erfassen von Standortkoordinaten

Anzeigen 13 Beiträge - 1 durch 13 (von 13 gesamt)
  • Autor
    Beiträge
  • #7690
    Ankur Shrivastava
    Teilnehmer

    Ich habe eine benutzerdefinierte Anforderung, dass ich während einer externen Eingabe die Standortkoordinaten senden muss (Längengrad, Breite, Höhe) für die ich Google API verwenden werde & basierend auf der Antwort, die ich senden werde & Speichern Sie die Standortkoordinate im System.

    Ich denke, dass Google-Dateien, auf die verwiesen wird, als EIF gezählt werden können.

    Ist mein Verständnis richtig?? Benötigen Sie kompetenten Rat.

    Auch bei Google (Diese Standortdaten), wird es als ILF betrachtet?

    #9278

    Ja Ankur Ich habe die gleiche Frage: wie man die Nutzung eines vorhandenen Webservices zählt.

    Sollten wir die Google-Website sehen, um eine Koordinate in Adressinformationen als EIF für externe Schnittstellendateien umzuwandeln?
    Oder sollten wir die Anforderung an diesen Webservice als externe Ausgabe-EO sehen? (während wir Informationen über unsere Systemgrenze senden)?
    Oder sollten wir beide zählen??

    Wie zählen andere das??

    #9415
    Martin Jacobs
    Teilnehmer

    Hallo Ankur,

    Sie arbeiten an einem externen Eingang, Das ist Teil eines Systems. Nennen wir dieses System System_A. Das untersuchte System ist also System_A. Wir zählen eine EI von System_A, geben 4 FP (unter der Annahme einer durchschnittlichen Komplexität).
    Ab System_A ist hier kein EO zu zählen, als ausgehende Nachricht an Google (API-Anfrage) ist keine elementare Funktion. Es ist Teil der EI und diese Nachricht ist nicht die Hauptabsicht der Benutzeraktion. Aus dem gleichen Grund die eingehende Nachricht von Google (API-Antwort) ist nicht zu zählen.

    Betrachten wir nun die Google-API selbst. Es existiert, ändert sich nicht und befindet sich außerhalb von System_A. Also hier kein FP zu zählen.

    Sollte der Google Webservice (API) als EIF gesehen werden? Wenn wir sollten, dann sollte sich der Webservice als EIF qualifizieren, Dies bedeutet, dass die EIF-Definition für den Webservice gilt.
    Sagt Nesma: Eine externe Schnittstellendatei (EIF) ist eine logische Gruppe permanenter Daten aus Sicht des Benutzers, die jedes der folgenden Kriterien erfüllt:
    • Es wird von der zu zählenden Anwendung verwendet und
    • Es wird von der zu zählenden Anwendung nicht gepflegt und
    • Es wird von einer anderen Anwendung verwaltet und
    • Es steht der zu zählenden Anwendung direkt zur Verfügung.
    Und außerdem:
    • Eine externe Schnittstellendatei muss eine interne logische Datei einer anderen Anwendung sein.
    Nicht alles gilt für den Webservice, Der Webservice ist also kein EIF.
    Ifpug sagt: Eine Datenfunktion ist als zu klassifizieren
    b) Externe Schnittstellendatei (EIF) wenn es so ist
    • referenziert, aber nicht gepflegt, durch die Anwendung gemessen werden, und
    • in einer ILF in einer oder mehreren anderen Anwendungen identifiziert.
    Dies gilt nicht für den Webservice, Der Webservice ist also kein EIF.
    Auch der Webservice enthält keine ILF(s) referenziert.
    Wo sich die angeforderten Daten in Google befinden, ist nicht bekannt. Google wird es einfach bereitstellen, eine korrekte Nachricht an sie senden.
    Hier wurde also kein EIF identifiziert.

    Hoffe das hilft!

    Grüße,
    Martin Jacobs
    QSM Europe

    #9416

    Hallo Martin,

    Du sagst “Nicht alles gilt für den Webservice, Der Webservice ist also kein EIF.”
    Können Sie erklären, welches dieser Kriterien für die Google-API nicht gilt??

    Angenommen, wir verwenden die Funktionen in der Google-API, um eine Adresse von einer Postleitzahl abzurufen.
    Diese API enthält Daten für alle bekannten Postleitzahlen und die entsprechenden Koordinaten
    Auch diese API hat Daten für viele Koordinaten ihrer Adressinformationen (Straße, Stadt, Land, etc).

    1. Es wird von der zu zählenden Anwendung verwendet
    Ja, unser SystemA verwendet die Google-API .

    Es wird von der zu zählenden Anwendung nicht gepflegt
    Nein, Unser SystemA verwaltet die Daten der Google-API nicht

    Es wird von einer anderen Anwendung verwaltet
    Ja, Google-Nutzer haben Anwendungen, die diese Informationen verwalten.

    Es steht der Anwendung direkt zur Verfügung, um gezählt zu werden.
    Ja, Unser SystemA kann die Funktionalität zum Abrufen der Daten direkt aufrufen

    Eine externe Schnittstellendatei muss eine interne logische Datei einer anderen Anwendung sein
    Ja, Die Postleitzahl, Koordinaten und Adressinformationen sind ILF in der Google-Anwendung

    Nun siehst du, Ich denke, alle Kriterien sind erfüllt.
    Bitte teilen Sie uns mit, welche Kriterien Ihrer Meinung nach nicht erfüllt sind, so können wir voneinander lernen.

    Vielen Dank,
    Alexander

    #9417
    Martin Jacobs
    Teilnehmer

    Hallo Alexander,

    Ich werde mein Bestes geben!

    Siehe meine Antwort auf Ihre Punkte zwischen <mj> … </mj>

    Du sagst “Nicht alles gilt für den Webservice, Der Webservice ist also kein EIF.”
    Können Sie erklären, welches dieser Kriterien für die Google-API nicht gilt??

    Angenommen, wir verwenden die Funktionen in der Google-API, um eine Adresse von einer Postleitzahl abzurufen.
    Diese API enthält Daten für alle bekannten Postleitzahlen und die entsprechenden Koordinaten. Auch diese API enthält Daten für viele Koordinaten ihrer Adressinformationen (Straße, Stadt, Land, etc).
    <mj> Ich glaube nicht, dass die API “hat” die Daten. Es kann es für Sie bekommen, wie es eine Schnittstelle ist. Betrachten Sie API als ein System selbst?, oder ist Google das System, das Sie in Betracht ziehen? </mj>

    1. Es wird von der Anwendung verwendet, um gezählt zu werden. Ja, unser SystemA verwendet die Google-API .
    <mj> I.m.o.. Dies bedeutet nicht, dass es sich um eine Datenfunktion handelt. </mj>

    Es wird von der zu zählenden Anmeldung nicht gepflegt, Unser SystemA verwaltet die Daten der Google-API nicht
    <mj> Es tut nicht. Immer noch: Enthält die API die Daten?? </mj>

    Es wird von einer anderen Anwendung verwaltet
    Ja, Google-Nutzer haben Anwendungen, die diese Informationen verwalten.
    <mj> Verwalten Google-Mitarbeiter Informationen in der API?? </mj>

    Es steht der Anwendung direkt zur Verfügung, um gezählt zu werden.
    Ja, Unser SystemA kann die Funktionalität zum Abrufen der Daten direkt aufrufen
    <mj> Sie können die Daten abrufen, aber woher weißt du, dass es die tatsächlichen Daten sind? </mj>

    Eine externe Schnittstellendatei muss eine interne logische Datei einer anderen Anwendung sein. Ja, Die Postleitzahl, Koordinaten und Adressinformationen sind ILF in der Google-Anwendung
    <mj> Woher weißt du das? Möglicherweise gibt es mehrere ILFs, um diese Daten zusammenzustellen. Wie viele würden Sie annehmen? </mj>

    Nun siehst du, Ich denke, alle Kriterien sind erfüllt.
    Bitte teilen Sie uns mit, welche Kriterien Ihrer Meinung nach nicht erfüllt sind, so können wir voneinander lernen.
    <mj> Siehe meine Antworten. Ich denke, Sie machen viele Annahmen. Haben Sie die Spezifikationen, die sie unterstützen?? </mj>

    Ich freue mich darauf, diese Diskussion fortzusetzen, da ich denke, dass es vielen von uns wichtig ist!

    Grüße,
    Martin

    #9418

    Sind wir uns einig, dass Google Maps ein System mit Funktionen und internen Daten ist??

    #9419

    Google hat viele APIs für Google Maps veröffentlicht.
    Sie können sie hier lesen: https://developers.google.com/maps/documentation/geocoding/start
    Dort können Sie die lesen “Reverse Geocodierungsanforderung und -antwort (Adressensuche)” Funktionalität.
    Sie teilen ihm einige Filterdaten mit und Google bietet eine Liste mit Daten an:
    Adresskomponenten
    und
    formatierte_Adresse
    Daher muss ich nicht viele technische Details über die technische Art und Weise der Speicherung der Daten wissen.
    Google teilt mir eine logische Adressliste mit.

    Aus Anwendersicht sind dies die logischen Daten, die verwendet werden.

    Wenn Sie es vorziehen, können wir unser eigenes Beispiel mit einem System B erstellen, das Daten über eine API bereitstellt, und für dieses Beispiel wissen wir genau, wie die Daten gespeichert werden. Benötigen wir dieses Beispiel oder können wir mit Google Maps als Beispiel fortfahren??

    #9420
    Martin Jacobs
    Teilnehmer

    Fahren wir mit Google Maps als Beispiel fort.

    Dies ist der Kern Ihrer Argumentation, Ich denke:
    Sie teilen ihm einige Filterdaten mit und Google bietet eine Liste mit Daten an:
    Adresskomponenten
    und
    formatierte_Adresse
    Daher muss ich nicht viele technische Details über die technische Art und Weise der Speicherung der Daten wissen.
    Google teilt mir eine logische Adressliste mit.

    Aus Anwendersicht sind dies die logischen Daten, die verwendet werden.

    Ich konzentriere mich auf Ihren letzten Satz.
    Google Maps sendet einen Datensatz, der mir dann zur Verfügung steht.
    Bedeutet dies, dass aus Ihrer Sicht ein Datensatz von außerhalb der Ihnen zur Verfügung gestellten Systemgrenze immer ein EIF ist??
    Enthält dieser Datensatz permanente Daten, die von Google Maps verwaltet werden??

    #9421

    Ja, lass uns mit dem Satz beginnen: “Google Maps sendet einen Datensatz, der mir dann zur Verfügung steht”

    Sie haben zwei Fragen:
    1. Bedeutet das aus Ihrer Sicht? [von] Ein Datensatz von außerhalb der Systemgrenze, der Ihnen zur Verfügung gestellt wird, ist immer ein EIF?
    Vielleicht das Wort “immer” ist zu stark, aber ja, Ich denke, Sie können dies als EIF sehen.
    Ich denke an ein Beispiel des Zählteams von Nesma, das eine Situation beschreibt, in der zwei ILFs für ein System ein EIF für ein externes System sein können: https://nesma.org/freedocs/additional-example-06-code-and-description/

    2. Enthält dieser Datensatz permanente Daten, die von Google Maps verwaltet werden??
    Ja, ich denke, dass dies permanente Daten im Google Maps-System sind: Es ist verfügbar und nicht nur während der Anfrage verfügbar und wird dann konsumiert (Weg). Mit anderen Worten: Das Google Maps-System kennt für jede Postleitzahl eine Straße und eine Stadt. Dies ist vor der API-Anforderung bekannt und dem System nach der API-Anforderung weiterhin bekannt. Für eine Perspektive der API-Anforderung sind dies permanente Daten.

    #9422
    Martin Jacobs
    Teilnehmer

    Zählen Sie die von Ihnen angeforderten und zur Verfügung gestellten DETs als 1 EIF?
    Wissen Sie mit Sicherheit, welche ILFs von Google Maps abgefragt werden, um die Ihnen zur Verfügung gestellten Daten bereitzustellen??
    Schauen wir uns das Beispiel an, auf das Sie sich beziehen.
    Wenn Sie die Gewissheit haben, dann sollten diese benannt und gezählt werden. Es könnte mehr als eine geben.
    Wenn Sie diese Gewissheit nicht haben, dann sollte eine Annahme gemacht werden. Das Beispiel macht deutlich, dass verschiedene FP-Analysten unterschiedliche Annahmen treffen können, was zu unterschiedlichen Zählungen führt. Darauf habe ich mit meiner Bemerkung zu Annahmen in meiner ersten Antwort an Sie und in Bezug genommen: Eine externe Schnittstellendatei muss eine interne logische Datei einer anderen Anwendung sein. Ja, Die Postleitzahl, Koordinaten und Adressinformationen sind ILF in der Google-Anwendung
    <mj> Woher weißt du das? Möglicherweise gibt es mehrere ILFs, um diese Daten zusammenzustellen. Wie viele würden Sie annehmen? </mj>.
    Zählen Sie den Webservice einfach als EIF? Dokumentieren Sie damit eine Annahme oder Erklärung?? Ich versuche, die Zählunterschiede zwischen FP-Analysten zu minimieren.

    #9443

    Hallo Martin, Sie stellen immer wieder Fragen. Zu viele für mich, es ist zu verwirrend in einem Chat.

    Persönlich, In den meisten Fällen sehe ich einen Webservice in SystemB, der bij SystemA als einen EIF für SystemA verwendet.
    Ich dokumentiere dies nicht viel, da es für mich sehr üblich ist, dies zu tun.

    Wie zählen Sie für das Beispiel??

    #15982
    SueHannan
    Teilnehmer

    Wow das war ein Schluck. Ich habe viele dieser Szenarien und muss verstehen, wie ich sie am besten dimensionieren kann. Ich verwende die NESMA Estimated Sizing-Methode.

    In diesem Fall verwende ich USPS, um die Adresse zu validieren, es scheint, ich hätte einen EIF (für die Adresse, die USPS an mich zurücksenden wird) und einen EQ für die USPS-Adresse, die auf Anfrage zur Validierung an den Kunden zurückgesandt wird (mit anderen Worten, Der EQ, den der Benutzer als USPS-Adresse ansieht, kann ihn auswählen oder die eingegebene Adresse beibehalten) und einen EIF für die Adresse, die USPS behält und verwaltet. Soweit ein zusätzlicher EQ (Dies ist die Nachricht von meinem System an den USPS-Webdienst) und die EI (für die Nachricht zurück mit der gültigen Adresse)… Ich entscheide mich, diese nicht separat zu zählen, da sie Teil des primären EQ sind, den der Kunde als USPS-Adresse erhält, um zu verwenden oder zu behalten, was der Kunde in das System eingegeben hat.

    Ich verwende auch Google Maps, um zu überprüfen, ob die Adresse gültig ist und um zu sehen, wohin sie geliefert werden soll. Ich würde mir vorstellen, dass es genauso gezählt wird wie das obige USPS-Szenario.

    Kannst du helfen?? Vielen Dank.

    #15983
    Frank Vogelezang
    Schlüsselmeister

    Für die USPS-Adressvalidierung, ein neues Thema wurde gestartet, um die Diskussion fokussiert zu halten. Bitte verwenden Sie den Rest dieses Threads nur für Kommentare zur Verwendung der Google API.

    Wechseln Sie zum Thema USPS.

Anzeigen 13 Beiträge - 1 durch 13 (von 13 gesamt)
  • Sie müssen angemeldet sein, um auf dieses Thema antworten zu können.