Projektantrag Anwendungsentwickler

[mynotos]

Hallo Fachinformatiker, ich sommer schließe ich meine ausbildung zum anwendungsentwickler hab und habe derzeit folgenden projektantrag. Ich möchte gerne wissen was ihr von diesem projektantrag haltet und ob noch verbesserungen bestehen danke im voraus!

1 Projektbezeichnung:

Entwicklung eines Einzugsgebiets-Generators über eine Routing Schnittstelle

1.1 Projektbeschreibung:

Entwickelt werden soll eine Anwendung, die auf Basis von geografischen Koordinaten (Standort-Adressen) spezifische Einzugsgebiete, in Abhängigkeit von Geh-/Fahrtzeit oder der zurückgelegten Distanz in Kilometern bestimmt. Die zu entwickelnde Anwendung soll mit Hilfe des Straßennetzes vom Anbieter NOKIA Navteq und dessen bereitgestellter REST-Schnittstelle, europaweit in Form von Isoline – Polygone (Einzugsgebiete) berechnen. Ein Polygon bildet die Basis für das zu erstellende Einzugsgebiet. Die Anwendung soll auf einen Windows-basiertem Computer lauffähig sein.

Ist-Zustand:

Derzeit vertreibt das Unternehmen ein Programm, in dem eine andere Schnittstelle integriert ist, die das Isoline berechnet. Die zu entwickelnde Software soll den Kunden der Select-IT GmbH als Update zur Verfügung gestellt werden. Bei der Schnittstelle, die die bereits existierende Anwendung nutzt, handelt es sich um eine SOAP (Simple Object Access Protocol) Schnittstelle von Map24. Die Schnittstelle von Map24 wird seit dem Jahr 2009 nicht weiterentwickelt und unterstützt. Dadurch das die Map24 Schnittstelle auf einem alten Stand des Geo Quartal 2009 arbeitet, sind Berechnungen betreffend eines Isoline – Polygon ungenau. Des Weiteren ist es nicht möglich mehrere Abfragen parallel durchzuführen und hat Performanceverlust zur Folge. Hinzu kommt das die eingesetzte Schnittstelle nur die Möglichkeit bietet, Isoline auf Basis von durchschnittlichen Geschwindigkeiten pro Kraftfahrzeug zu berechnen.

Soll-Zustand:

Die zu entwickelnde Software soll auf die neue Schnittstelle von NOKIA zugreifen. Diese arbeitet wesentlich stabiler und weist eine höhere Performance in der Berechnung des Isoline auf. Die neue Software soll über die bereits bekannten Routingmöglichkeiten verfügen, die zur Berechnung des Isoline notwendig sind. Zusätzlich soll die Wahl der Fortbewegung um eine Fußgängeroption erweitert werden. Die Berechnung auf Basis eines Kraftfahrzeuges, als auch die des Fußgängers, soll in Abhängigkeit der zurückgelegten Distanz oder der gewünschten Fahr- /Gehzeit für das zu erstellende Isoline erweitert werden.

Der Prozessablauf soll wie folgt ablaufen:

Die zu entwickelnde Anwendung, soll aus der Datenbank die entsprechende Standort Adresse und die jeweils dazugehörigen Koordinaten einlesen. Mit den eingelesenen Koordinaten und der ausgewählten Routingoption wird eine Anfrage generiert. Diese generierte Anfrage, soll von dem zu realisierenden Programm an die NOKIA REST Schnittstelle gesendet werden. Anschließend führt die NOKIA REST-Schnittstelle eine serverseitige Aktion aus und berechnet alle notwendigen Koordinaten, die zur Erstellung eines Isoline - Polygons notwendig sind. Aus dem Ergebnis der ermittelten Koordinaten, von der NOKIA REST-Schnittstelle, soll eine GIS Geometrie (Polygon) erzeugt werden. Die erzeugte GIS Geometrie soll in der Datenbank gespeichert und für andere Programme, zur Weiterverarbeitung zur Verfügung gestellt werden. Des Weiteren soll die Performance optimiert werden.

Entwicklungsumgebung:

Das zu realisierende Programm soll in der Programmiersprache Delphi geschrieben werden. Die Entwicklungsumgebung ist Embarcadero Delphi XE. Das Programm soll mit einer Datenbank in Verbindung stehen. Die Datenbank die von dem zu realisierenden Programm genutzt werden soll ist eine PostgreSQL Datenbank. Das Programm soll auf jeden Windows-basierten Computer lauffähig sein.

Begriffserklärungen:

REST:

„Representational State Transfer“ bezeichnet ein Programmierservice für Webanwendungen. Im Grunde bezeichnet REST die Idee, genau einen Seiteninhalt als Ergebnis einer serverseitigen Aktion darzustellen.

Isoline / Isoline - Polygon:

Das Isoline in Bezug auf das Routing, wird von einem Standort aus berechnet. Von dem Standort aus, gehen verschiedene Wegstrecken (Isolinien) ab. Die Länge der Wegstrecken, wird durch die Routingoption Geh-/ Fahrzeit bestimmt und beachten die geografischen Gegebenheiten, in Bezug auf Gehwege und Straßen. Verbindet man alle Endpunkte der Strecken miteinander erhält man ein Isoline-Polygon. Anbei im Anhang eine Skizze zur Veranschaulichung.

Polygon:

Ein Polygon wird auch als Vieleck bezeichnet. Ein Polygon ist eine geometrische Figur die sich mindestens aus drei verschiedenen einander liegenden Punkten verbindet, sodass durch den entstandenen Linienzug eine zusammenhängende Fläche umschlossen wird

GIS:

„Geografisches Informationssystem“ ist ein Informationssystem mit dem nach Bill(1994) raumbezogene Daten digital erfasst und redigiert, gespeichert und reorganisiert, modelliert und analysiert sowie alphanumerisch und graphisch präsentiert werden.

2. Projektumfeld

Die Projektarbeit wird innerhalb des betrieblichen Praktikums bei der Firma xxxx durchgeführt. Die xxx ist eine Firma, die Software entwickelt, die in den Bereichen Geo-Marketing und Mediaplanung zum Einsatz kommt.

Prozessschnittstellen:

Abteilung „xxx“

- Ermittlung eines Einzugsgebiets auf Basis von Koordinaten

Organisatorische Schnittstellen:

Projektabstimmung und Projektübergabe:xxxx

Technische Schnittstelle:

Einbindung der Routing-NLP API 6.2 von NOKIA Navteq

3. Projektplanung

Analyse:

[2h] Problemanalyse

[7h] Erstellung Pflichtenheft

[2h] Wirtschaftlichkeitsanalyse

Konzeption:

[6h] Projektplanung

[2h] Qualitätsplan

[2h] Benutzeroberfläche

[2h] Testfall-Katalog erstellen

Implementierung:

[1h] Umsetzung Datenbankdesign

[15h] Programmierung

Validierung:

[6h] Testen

[2h] Abnahme

[1h] Qualitätsbericht

Dokumentation:

[3h] Soll-Ist Vergleich

[2h] Benutzerdokumentation

[15h] Prozessorientierter Projektbericht

Summe: 68 Stunden

Puffer: 2 Stunden

4. Geplante Dokumentationen

Benutzerhandbuch,

Abnahmeprotokoll,

Datenbankdesign,

Kostenplan,

Pflichtenheft,

Projektbericht,

Projektstrukturplan,

Statistiken Soll-Ist Vergleich,

Testfall-Katalog,

UML-Diagramme,

Qualitätsbericht,

Quellcode,

Wirtschaftlichkeitsanalyse,

Zeitplan

[Zaub9rk1nd]

Lass die Begriffserklärungen im Antrag raus, sofern nicht unbedingt gebraucht.

(Dann erklärt man sie normal im Kontext oder mit einer Fußnote).

REST-Schnittstelle brauchst du nicht erklären (deine Erklärung ist sogar nicht richtig), was ein Polygon ist sollte der PA auch wissen. ; )

Auch ist es ungünstig zu erwähnen, was du alles dokumentieren willst (Wenn du es aufschreibst, dann musst du es auch halten). Ich empfehle daher diesen Punkt zu überdenken bzw. wegzulassen. Es sieht viel aus und ist es auch, gerade in den 15Stunden das alles ordentlich abzuarbeiten, festzuhalten und ordentlich aufzubereiten.

Wenn du dich da mal nicht überschätzt.

Bearbeitet 24. Januar 2013 von Zaub9rk1nd

[mynotos]

Vielen dank schonmal für die antwort, ich passe REST mal an die 15h programmierung ist im grunde ein wenig zu viel (für meine kenntnisse und erfahrung in der programmierung) letzteres ist es nur api einbindung url ansprechen ergebniss auswerten und über die GIS funktion von PostGIS eine geomtrie erzeugen und speichern, wollte noch threading mit reinpacken aber das wäre dann unglaubwürdig gekommen.. aber es gibt ja noch die 2 stunden puffer . Zu den geplanten dokumentationen was kann ich rauslassen ?

[Schiller256]

Mach aus den 15 Std. in der Implementierung mal noch zwei bis drei einzelne Punkte. Das wäre mir etwas zu grob.

Im Moment bin ich mir nicht sicher ob das nicht vielleicht was dünn ist. Denn du liest Daten aus einer DB rufst damit die REST Schnittstelle auf und das Ergebnis daraus gibst und an eine andere Schnittstelle weiter. Zum Schluss speicherst du das ganze dann wieder ab. Das könnte wenn sich dein Ausschuss etwas mit dem Thema auskennt auch nach hinten los gehen.