|
0
|
1 \section{Das DBSRV-Projekt}
|
|
|
2
|
|
|
3 Wie in der Einführung beschrieben, wurde von den ersten Praktikanten bei \textbf{MAKA} das DBSRV-Projekt ins Leben gerufen.
|
|
|
4 Der DBSRV ist eine Art Framework für allerlei Programme die den Mitarbeitern zur Verfügung stehen. Zum Teil erweitern diese Programme die Funktion des ERP-Systems, aber es gibt auch Programme die komplett neue Funktionalitäten anbieten\footnote{Ein Beispiel hierfür wäre die Bilderdatenbank}.
|
|
|
5 All diese Programme sind von Praktikanten nach und nach geschrieben worden.
|
|
|
6
|
|
|
7 Ich habe hier einfach an der Stelle weitergemacht an der mein Vorgänger aufgehört hatte. Pflichtenhefte, oder vielleicht besser ``Konzepte'' existierten dazu bereits.
|
|
|
8
|
|
|
9 Im Folgendem werde ich den Begriff \textit{DBSRV} verwenden wenn ich dieses DBSRV-Projekt meine.
|
|
|
10
|
|
|
11
|
|
|
12
|
|
|
13
|
|
|
14
|
|
|
15 Während meines Praktikums habe ich an drei Programmen gearbeitet:
|
|
|
16
|
|
|
17 \begin{enumerate}
|
|
|
18 \item Einkaufsinformationssystem (kurz EIS)\\
|
|
|
19 Eine Abfragensammlung mit Reports wie Bestellobligo, Realer Wiederbeschaffungszeit und einem Fehlteilmanagement.
|
|
|
20 Dieses Programm war von meinem Vorgänger schon zur Hälfte fertig gestellt.
|
|
|
21
|
|
|
22 \item Montageinformationssystem (kurz MontIS)\\
|
|
|
23 Dem EIS recht ähnlich aber für die Montage. Zu implementieren war das Fehlteilmanagement und die Liefertreueanalyse.
|
|
|
24
|
|
|
25 \item Translator-Datenbank \& Dictionary\\
|
|
|
26 Eine Übersetzungsdatenbank für fremdsprachige Artikelbezeichungen um entsprechend lokalisierte Stücklisten drucken zu können.
|
|
|
27
|
|
|
28 \end{enumerate}
|
|
|
29
|
|
|
30
|
|
|
31
|
|
|
32
|
|
|
33 \newpage
|
|
|
34 \section{Einarbeiten}
|
|
|
35
|
|
|
36 Die erste Woche verbrachte ich damit die bestehende Codebasis des EIS und die Datenbank des ERP-Systems kennen und verstehen zu lernen. Dabei ist es natürlich eine Schwierigkeit sich die Denkmuster des vorherigen Programmierers zu verinnerlichen. Eine dabei sehr gute Entscheidung war den Code durch Refactoring kennenzulernen und gleichzeitig zu verbessern. Code zu lesen führt meist nicht zum gewünschten Erfolg (jedenfalls nicht in dem Maße). Indem man den Programmcode allerdings `umräumt', und die dabei zwangsläufig entstehenden Fehler\footnote{Die Erfahrung (und Murphy) zeigt, dass durch Refactoring immer Fehler entstehen werden. Oder wenn man es von der anderen Seite betrachtet, kommen so (Design-)Fehler zum Vorschein.} studiert, lernt man die Funktion des Codes sehr schnell und intensiv kennen.
|
|
|
37
|
|
|
38 Nachdem ich die Programmiergewohnheiten meines Vorgängers analysiert hatte und, durch die Arbeit mit dem Code, einen gewissen Einblick in die Logik der Datenherkunft erhalten hatte, machte ich mich daran selbst meinen ersten Report zu schreiben. Das größte Problem am Anfang war dabei herauszufinden aus welchen Datenbanktabellen ich die benötigten Daten erhalte. Bei über 70 Datenbanktabellen, mit zudem recht kryptischen Namen, war das auch verständlich. Mit der Zeit erkennt man dann aber ein Schema hinter den Bezeichnungen und kann sie sich so herleiten. Als Beispiel möchte ich die Tabellenspalte \texttt{ttdpur041100.T\_ORNO} anführen. Das erste \texttt{t} ist bei allen Tabellen so, dann folgt ein \texttt{td} für das Baan-Modul ``distribution'' (engl. für ``Vertrieb'' oder ``Absatz''), \texttt{pur} steht für ``purchase'' (engl. für ``Beschaffung''), die \texttt{041} ist die Tabelle ``Bestellkopf'' und die \texttt{100} steht für die Echtfirma. Um solche Schemen nachvollziehen zu können war auch ein Wissen über den Aufbau eines ERP-Systems notwendig, das ich mir während des Praktikums angeeignet habe. Mit der Zeit habe ich dann auch ein Gefühl dafür bekommen wo ich welche Daten finde.
|
|
|
39
|
