Projektantrag bewerten

[dannyt]

Moin moin zusammen,

ich bin zwar schon länger angemeldet hier, war aber bisher nicht aktiv.

Also mal ein fröhliches Hallo in die Runde!

Ich bin gerade dabei, meinen Projektantrag für das Abschlussprojekt (IHK Bremen) anzufertigen. Bin auch eigentlich fertig

Würde mich freuen, die ein oder andere Meinung über den Antrag von euch zu bekommen.

Habe dazu aber auch noch eine Frage:

Bei Punkt 4 (Projektphasen mit Zeitplanung in Stunden) steht in der IHK Hilfe:

Hier geben Sie die erforderlichen Daten gemäß der Gliederung Punkt 4. für Ihr Projekt ein.

Den Brief, den ich von der IHK Bremen erhielt, sagte jedoch:

[...]

Ferner sind die Projektphasen einsch eines Zeitplanes anzugeben. Dazu gehören die Definition der Kernaufgaben des Projektes, eine Kennzeichnung der davon prüfungsrelevanten Aufgaben, die Zuordnung dieser Aufgaben zu Zeitumfängen, die Darstellung zeitlicher Abhängigkeiten innerhalb des Projektes und ein konkreter Terminplan.

[...]

Soll ich jetzt also nur eine reine Zeitplanung (siehe unten) erstellen, oder wird auch ein GANTT Diagramm o.ä. erwartet? Weil hochladen (wie bei Punkt 3.4) kann ich hier nichts...

1. Projektbezeichnung (Auftrag / Teilauftrag):

Erstellung einer Adressvalidierung für Microsoft Dynamics NAV

1.1 Kurzform der Aufgabenstellung

Für das Warenwirtschaftssystem (ERP-System) Microsoft Dynamics NAV soll eine

Adressüberprüfung realisiert werden, um Falscheingaben bei Adressen (Straße,

Postleitzahl, Ort) sowie Anreden (Herr, Frau) zu vermeiden.

1.2 Ist Analyse

Der Kunde XYZ steigt momentan auf das ERP System Microsoft Dynamics NAV um. Für

die Stammdatenpflege benutzte der Kunde zur Vorzeit ein anderes System, welches

nicht in der Lage war, Adressen zu überprüfen und die Richtigkeit zu

gewährleisten. Auch Microsoft Dynamics NAV im Originalzustand ist nicht in der

Lage, Adressen zu überprüfen und die Richtigkeit zu gewährleisten.

2. Zielsetzung entwickeln / Soll-Konzept

2.1 Was soll am Ende des Projektes erreicht sein?

Bei der Stammdatenpflege von Debitoren, Kreditoren und Kontakten sollen

zukünftig Falscheingaben von Straßen und Anreden vermieden werden.

Durch dieses Verfahren soll die Adressqualität in Microsoft Dynamics NAV

steigen. Dies vermindert die Kosten von falschen Zustellungen/Retouren und

erhöht gleichzeitig die Wirtschaftlichkeit des Unternehmens.

Da reine CRM Softwarepaket mitunter sehr teuer sein können, soll hiermit eine

kostengünstige und dennoch mächtige Alternative geschaffen werden.

2.2 Welche Anforderungen müssen erfüllt sein?

Gibt es z.B. die Straße "Test Straße" in "12345 Teststadt", so müssen Eingaben

wie z.B. "Teststr." in "12345 Test Stadt" vermieden werden. Der Abgleich

erfolgt durch einen zur Verfügung gestellten Straßenkatalog. Um ähnliche

Schreibweisen von Straßennamen zu erkennen, werden verschiedene Algorithmen

(u.a. das Soundex Verfahren) eingesetzt (fehlertolerante Suche).

2.3 Welche Einschränkungen müssen berücksichtigt werden?

Die Überprüfung der Adressen ist auf Deutschland beschränkt. Es wäre zu

komplex, Algorithmen zur Überprüfung internationaler Adressschemata im Rahmen

des Abschlussprojektes zu realisieren.

3. Projektstrukturplan entwickeln

3.1 Was ist zur Erfüllung der Zielsetzung erforderlich

Um die Adressvalidierung nutzen zu können, wird das ERP System Microsoft

Dynamics NAV in der Version 4.03 oder höher benötigt. Damit Adressreferenzen

vorhanden sind, muss dafür gesorgt werden, dass ein Straßenkatalog vorhanden

ist. Da zahlreiche Benutzer eines Systems mit dem Modul vertraut gemacht werden

müssen, muss ein Benutzerhandbuch erstellt werden. Das Projekt kann nur dann

erfolgreich abgeschlossen werden, wenn ein einzuhaltender Zeitplan erstellt

wurde und jegliche Programmierungen ausgiebig getestet wurden.

3.2 Hauptaufgaben auflisten

--> Analysephase

--> Planungsphase

--> Implementierungsphase

--> Dokumentationsphase

--> Inbetriebnahmephase

3.3 Teilaufgaben auflisten

--> Analysephase

----> Durchführen einer IST-Analyse

----> Erstellung eines SOLL-Konzeptes

--> Planungsphase

----> Erstellung eines GANTT Diagramms

----> Erstellung eines ER-Diagramms

--> Implementierungsphase

----> Aufbauen der Datenbankstruktur

----> Programmierung der Funktionen

----> Implementierung in Microsoft Dynamics NAV

----> Erstellung von Testverfahren

----> Durchführung der Tests

--> Dokumentationsphase

----> Erstellung der Dokumentation

----> Erstellung des Benutzerhandbuchs

--> Inbetriebnahmephase

----> Abnahme durch den Kunden

3.4 Darstellung

( Projektstrukturplan passt schon )

4. Projektphasen mit Zeitplanung in Stunden

Analysephase (4 Stunden)

- Durchführen einer IST-Analyse (1 Stunde)

- Erstellung eines SOLL-Konzeptes (3 Stunden)

Planungsphase (5,5 Stunden)

- Erstellung eines GANTT Diagramms (2,5 Stunden)

- Erstellung eines ER-Diagramms (3 Stunden)

Implementierungsphase (46,5 Stunden)

- Aufbauen der Datenbankstruktur (2,5 Stunden)

- Programmierung der Funktionen (30 Stunden)

- Implementierung in Microsoft Dynamics NAV (8 Stunden)

- Erstellung von Testverfahren (2 Stunden)

- Durchführung der Tests (4 Stunden)

Dokumentationsphase (13 Stunden)

- Erstellung der Dokumentation (10 Stunden)

- Erstellung des Benutzerhandbuchs (3 Stunden)

Inbetriebnahmephase (1 Stunde)

- Abnahme durch den Kunden (1 Stunde)

Gesamt: 70 Stunden

Danke und Grüße

dannyt

[DarkMaster]

zum Antrag selber kann ich nicht viel sagen, da ich kein NAV Spezialist bin.

Aber nach kurzer Recherche bin ich auf ähnliches Addon gestoßen

q.address Add-on für Microsoft Dynamics NAV (Navision)

(soll keine Werbung sein, nur dem TE helfen)

@TE:

warum also eine eigenprogrammierte Lösung, wenn es bereits sowas gibt?

[dannyt]

Hallo DarkMaster,

vielen Dank für deine Antwort.

Du hast Recht, dass es bereits so etwas in der Richtung gibt.

Ich wage auch zu behaupten, dass die Lösung besser ist, als meine es sein wird.

Ich möchte mit meiner Lösung lediglich eine "kostengünstige Alternative" anbieten und das Monopol (?) in ein (bilaterales) Oligopol verwandeln.

Außerdem kam diese Anforderung kürzlich bei einem Kunden, wodurch es so oder so umgesetzt werden müsste.

warum also eine eigenprogrammierte Lösung, wenn es bereits sowas gibt?

(von mir) geschätzte >90% aller Abschlussprojekte sind keine Weltneuheit

[flashpixx]

Also im groben würde ich sagen ist das alles okay.

Was ich nicht in den Antrag rein schreiben würde, was Du für ein Verfahren für die Vergleiche einsetzen willst (soundex). Außerdem der Hinweis zu Soundex ? Wikipedia der funktioniert wirklich nur gut bei englischen Wörtern, somit würde ich das fachlich sehr kritisch sehen, da Du den Adressbestand ja auf die BRD beschränkst und sicher wenige englische Bezeichnungen hast.

Da ich mich mit so etwas beschäftige würde ich Dir

Levenshtein-Distanz ? Wikipedia empfehlen (für längere Texte eignet sich auch Normalized Compression Distance | flashpixx.de ). Da ich selbst einige Jahre mit NAV gearbeitet habe, kann man die Masken zur Adresseingabe auch so gestalten, dass man eben teilstringbasierte Suche durchführt, d.h. der User kann die Straße buchstabenweise eingeben und bekommt dann automatisch eine passend gefilterte Liste. Dafür kann man z.B. Suffix tree - Wikipedia, the free encyclopedia verwenden, ein bekannter Algorithmus dafür ist Ukkonen's algorithm - Wikipedia, the free encyclopedia

[dannyt]

Hallo flashpixx,

vielen Dank für deine Antwort.

Hätte nicht gedacht, dass es hier noch mehr NAV Kenner gibt *g*

Das Verfahren habe ich mal aus dem Antrag genommen.

Ich habe mich schonmal kurz mit verschiedenen Algorithmen auseinandergesetzt und wie die Realisierung hierfür in NAV aussieht.

Bei Soundex vs. Levenshtein habe ich mich aber entschlossen Soundex zu nehmen, weil Levenshtein ja zur Laufzeit berechnet werden muss. Sprich die eingegebene Straße muss dann mit jeder Straße im Verzeichnis abgeglichen werden. Bei Soundex ist es so, dass dieser ja immer gleich ist und ich somit den Soundex Code bei jeder Straße mit hinterlegen kann, was eine Abprüfung extrem verkürzt.

Eine filterbasierte Suche hab ich mir sowieso vorgestellt. Vielleicht auch ein Mix zwischen beidem (Stichwort temporäre Tabellen).

Vielen Dank jedenfalls für die anderen beiden Algorithmen!

[flashpixx]

Hätte nicht gedacht, dass es hier noch mehr NAV Kenner gibt *g*

NAV ist zwar ganz nett, aber in manchen Dingen auch extrem umständlich, ich bin da eher geteilter Meinung (kommt auf den konkreten Einsatz an).

Bei Soundex vs. Levenshtein habe ich mich aber entschlossen Soundex zu nehmen, weil Levenshtein ja zur Laufzeit berechnet werden muss.

Nein nicht zwingend. Ich kann Dir nur aus Erfahrung von Soundex abraten, ich habe mal etwas ähnliches gemacht und die Ergebnisse sind miserabel.

Ich würde Dir zu einer Kobination aus Suffix-Tree und Levenshtein raten. Du kannst die Suffixes in einer Tabelle inkl des Distanzwertes legen und bei der Eingabe des Benutzer passend aus der Tabelle lesen. Tree und Distanzwert musst Du nur dann neu berechnen, wenn sich die Daten ändern.

[dannyt]

NAV ist zwar ganz nett, aber in manchen Dingen auch extrem umständlich

So ist es

Ich habe mir gerade mal ein Beispiel einer Suffix Konstruktion (C++) angeschaut.

Das sieht sehr komplex aus, wie ich finde. Ich weiß nicht, ob so etwas im Rahmen des Abschlussprojektes [für mich] durchführbar ist und ob NAV mir die Möglichkeiten hierfür bietet (NAV ist ja sehr starr...).

Aber ich werde mir mal Gedanken darüber machen

Bearbeitet 19. Januar 2011 von dannyt

[flashpixx]

Das sieht sehr komplex aus, wie ich finde. Ich weiß nicht, ob so etwas im Rahmen des Abschlussprojektes [für mich] durchführbar ist und ob NAV mir die Möglichkeiten hierfür bietet (NAV ist ja sehr starr...).

Du kannst unter NAV jedes beliebige COM Objekt verwenden z.B. könntest Du den Suffix Tree als XML DOM Struktur aufbauen und schießt diesen später einfach in die Tabelle, einen Baum kann man auch ohne Probleme in einer Tabelle speichern.

Alternativ, die auch sehr gut Funktionieren sind so genannte "String Kernel". Das ist salopp eine mathematische Repräsentation eines Skalarproduktes zwischen zwei String, also deren Distanz / Ähnlichkeit. Auf die schnelle:

Powered by Google Text & Tabellen

bzw

Powered by Google Text & Tabellen

Powered by Google Text & Tabellen

Du wirst eben das Problem bekommen, dass die Datenmenge extrem groß ist und Du sie schnell durchsuchen musst. Wenn Du z.B. durch die PLZ einschränken kannst, dann würde ich das im Vorfeld machen. Aber wenn Du z.B. die PLZ von München (also alle PLZ Bereiche) angibst und dann dort alle Straßen mit "R" beginnend listen willst, wirst Du schnelle Algorithmen und dahinter effiziente Datenstrukturen benötigen. Du zu Durchsuchende Datenmenge wird zwar mit jedem Buchstaben eingeschränkter, aber die Datenbank muss schon sehr viele Datensätze verarbeiten.

Mal davon abgesehen, dass Du ggf auf Tippfehler effizient reagieren solltest, denn sicherlich kennt nicht jeder immer die korrekte Schreibweise eines Straßennamens.

Für die String Kernel Geschichten gibt es fertige Implementationen in C, die Du evtl als externe NAV Komponente (COM) einbinden kannst.