% header
% Dies ist version-0.9.8 der IHK Doku [FINAL]
% let's go...
%\documentclass[10pt,a4paper,ngerman]{article}
\documentclass[11pt,a4paper]{article}
\usepackage[latin1]{inputenc} % Ascii-Format dieses Dokuments
%\usepackage{babel} % neue deutsche Rechtschreibung
% Teutsch
\usepackage{german}
% lange Tabellen
\usepackage{longtable}
% pagestyle..
\usepackage{fancyhdr}
\pagestyle{fancy}
%\fancyhf{} % bisherige Kopf- und Fusszeilen loeschen
\fancyhead[R]{Nico Schottelius} % rechter Kopfzeileneintrag
%\fancyhead[L]{Projekdokumentation} % linker Kopfzeileneintrag
%\fancyhead[L]{\thepage} % linker Kopfzeileneintrag
%\fancyfoot[C]{\thepage} % Fusszeileneintrag (Seitenzahl zentriert)
\renewcommand{\headrulewidth}{0.4pt} % Strichstaerke unter der Kopfzeile
% let's start
\begin{document}
\title{Projektdokumentation: Webzugriff auf eine Datenbank via PHP}
\date{01.03.2004 - 30.04.2004}
\author{
Nico Schottelius\\
Rodenstra\ss{}e 12\\
30826 Garbsen\\
nico-ihk@schottelius.org\\
\\
Ausbildungsbetrieb:\\
Wirtschaftsgenossenschaft deutscher Tier\"arzte eG\\
Siemensstra\ss{}e 14\\
30827 Garbsen\\
http://www.wdt.de\\
}
% Title
\maketitle
\newpage
% Inhaltsverzeichnis
\tableofcontents
\newpage
\section{Pers\"onliche Erkl\"arung}
Ich versichere durch meine Unterschrift, dass ich die betriebliche Projektarbeit
und die dazugeh\"orige Dokumentation selbst\"andig in der vorgegebenen Zeit
erarbeitet habe. Ich habe keine anderen als die von mir angegebenen Quellen und
Hilfsmittel verwendet.\\
\begin{verbatim}
\end{verbatim}
\begin{tabbing}
xxxxxxxxxxxxxxxxx\=xxxxxxxxx\kill
$\overline{\mbox{\large{Ort, Datum}}}$
\>$\overline{\mbox{\large{Unterschrift des Pr\"uflings}}}$\\
\end{tabbing}
\begin{verbatim}
\end{verbatim}
Zur Kenntnis genommen:
\begin{verbatim}
\end{verbatim}
$\overline{\mbox{\large{Ausbilder/-in}}}$
\newpage
\section{Einleitung}
\subsection{Projektumfeld}
Das Projekt fand in der Wirtschaftsgenossenschaft deutscher Tier\"arzte eG
("`\textit{WDT}"') am Standort in Garbsen statt. Die WDT liefert Arzneimittel und
medizinisches Zubeh\"or f\"ur tier\"arztliche Praxen in ganz Deutschland. Zur Zeit
arbeiten circa 170 Mitarbeiter an drei Firmenstandorten, davon sind 14
Aussendienstmitarbeiter ("`\textit{ADM}"') in der Kundenbetreuung t\"atig. Ein
Gro\ss{}teil der Arbeitsabl\"aufe wird durch das
\textit{ERP-System}\footnote{ERP-System: Enterprise Resource Planing System}
unterst\"utzt.
So erfolgt die gesamte Auftragsbearbeitung, die Kommissionierung, der Versand,
der Einkauf sowie die Buchhaltung mit Hilfe dieses Systems.
Die Aussendiensmitarbeiter erhalten monatlich einen f\"ur sie relevanten,
individuellen Auszug aus der Datenbank.
\subsection{Ist-Zustand}
Zur Zeit werden Informationen zur Planung der Kundenberatung an die
Aussendienstmitarbeiter als \textit{Excel-Tabelle}\footnote{Excel ist ein Produkt
von Microsoft. Excel-Tabellen stellen ein properit\"ares Format zur Speicherung
von Tabellen dar}
via E-Mail versandt. Aufgrund der Verbindungsart
(\textit{HSCSD/GSM}\footnote{GSM ist die Technik die zum Verbinden der
Mobiltelefone verwendet wird, HSCSD ist die Daten\"ubertragung \"uber GSM}, ISDN
oder Modem) und der Gr\"o\ss{}e (circa 16 \textit{MiB}\footnote{KiB, MiB, GiB
sind Alternativbezeichnungen zu KB, MB und GB. Bei der
Verwendung von den letztern ist nicht klar, ob der Faktor 1000 oder 1024 gemeint
ist, 1024Byte entsprechen \textbf{immer} 1KiB. So sind z.B. manche 80GB Platten
nur 80000000000 Byte gross, was 74,51GiB entspricht.})
der Datei kommt es zu Problemen bei der \"Ubertragung. Diese Probleme
\"au\ss{}ern sich wie folgt:
\begin{itemize}
\item der Transfer der Datei dauert sehr lange (\"uber 30 Minuten)
\item durch eine Zwangstrennung im Funknetz nach 30 Minuten kann die Datei nicht
vollst\"andig \"ubertragen werden
\end{itemize}
Da E-Mail ein
\textit{Push-System}\footnote{Als "`Push-Systeme"' werden Systeme bezeichnet,
die die Informationen ohne Aufforderung des Benutzers zu selbigen senden
(neben E-Mail auch z.B. Plakate). Bei "`Pull-Sytemen"' hingegen muss der
Benutzer interaktiv die Informationen anfordern (z.B. Webseite).} ist,
ergibt sich zus\"atzlich das Problem, dass grunds\"atzlich in dreifacher
Hinsicht unn\"otige Daten \"ubertragen werden k\"onnen:
\begin{enumerate}
\item der ADM ben\"otigt die Informationen z.Z. nicht:
komplett unn\"otiger Versand.\\
Eine Filterung nach Anforderung ist mit dem momentanen System schwer zu realisieren
und k\"onnte bestenfalls manuell mit R\"ucksprache geschehen.
\item selbst wenn sich die Daten nicht ge\"andert haben, wird ein Update versandt\\
Dies hat zwei Gr\"unde:
\begin{enumerate}
\item die regelm\"assig empfangene E-Mail ist ein
Indiz f\"ur den ADM, dass das System ordnungsgem\"ass{} funktioniert
\item zum Zweiten wird keine Versionsverwaltung betrieben, sondern die
Excel-Tabellen jedes Mal komplett neu generiert
\end{enumerate}
\item Der ADM ben\"otigt nur einen Teil der Daten, bekommt
jedoch immer eine vorgefertigte Version mit gro\ss{}em Umfang (Daten\"uberfluss)
\item Bei jeder Aktualisierung werden auch die unver\"anderten Stammdaten
transferiert
\end{enumerate}
\subsection{Soll-Zustand}
Auf den Transfer via E-Mail soll grunds\"atzlich verzichtet und der
Zugriff in ein Pull-System umgewandelt werden.
Der Zugriff soll \"uber das
Internet auf ein Webinterface geschehen. Die Implementation muss auf dem
\textit{LAMP-System}\footnote{LAMP ist die Abk\"urzung f\"ur ein \textbf{L}inux,
\textbf{A}pache, \textbf{M}ySQL, \textbf{P}HP Kombination, wobei Linux das
Betriebssystem, Apache der Webserver, MySQL die Datenbank und PHP die
Programmiersprache ist.}
des Providers lauff\"ahig sein. Dazu soll ein m\"oglichst identisches Testsystem
intern verf\"ugbar sein. Die Daten m\"ussen aus dem ERP-System in einem
f\"ur MySQL importf\"ahigen Format bereitgestellt werden. Die entsprechenden
Aufgaben sollen gem\"a\ss{} der Qualifizierung der Mitarbeiter delegiert werden:
\begin{itemize}
\item das LAMP-System soll durch die Systemintegration bereitgestellt werden
\item der Export der Daten aus dem ERP-System soll durch die hauseigenen
Programmierer bereitgestellt werden
\item die Erstellung des Webzugriffs und der Dokumentation (inklusive Handbuch
f\"ur Benutzer und Entwickler, Schnittstellendefinitionen und Pflichtenheft) soll
vom Pr\"ufling erledigt werden
\end{itemize}
Ziel ist es, ein verwendbares System zu entwickeln und die Machbarkeit zu beweisen.
\section{Planung}
\subsection{Ablauf des Projektes}
Zu Beginn des Projektes wurden die Projektgrundsteine "`gelegt"':
\begin{enumerate}
\item es wurde ein Zeitplan f\"ur die einzelnen Phasen festgelegt, inklusive der
Festlegung von Besprechungsterminen
\item es wurden f\"ur die einzelnen Teams Schnittstellen definiert, damit diese
unabh\"angig voneinander arbeiten konnten und um eine klare Trennung zwischen den
einzelnen Modulen zu schaffen
\end{enumerate}
\subsection{Schnittstellendefinition}
Durch den sauberen Einsatz von Schnittstellen kann zum Beispiel ein Mitarbeiter
die Daten aus dem ERP-System auslesen und sie in einem definierten Format
speichern, w\"ahrend ein anderer schon die Umwandlung in die neue Datenbank
mit Hilfe von Testdaten programmiert. \\
Es sollen folgende Schnittstellendefinitionen erzeugt werden:
\begin{enumerate}
\item Benutzer/Weboberfl\"ache: Layoutdefiniton
\item Weboberfl\"ache/Datenbank: Zugriffsdefiniton
\item Datenbank/Quelldaten: Importformatdefiniton
\end{enumerate}
\subsection{Kompatibilit\"at}
Die Skripte m\"ussen ein identisches Verhalten auf dem Testsystem und auf dem
Echtsystem vorweisen. Um dies zu gew\"ahrleisten sind Modifizierungen, die im
Rahmen der Installation von Programmen als normal zu betrachten sind
(z.B. Pfad-, Limitierungs- oder Namensmodifikationen), n\"otig.
Das Erscheinungsbild dem Benutzer gegen\"uber soll soweit wie m\"oglich
identisch bleiben.
Eine Absprache mit dem \textit{ISP}\footnote{Internet Service Provider
bieten Internetanbindungen und Service an}
soll vor Beginn der Entwicklung stattfinden, damit eventuelle
Inkompatibilit\"aten vermieden werden k\"onnen.\\
Ein System, das nur In-House funktioniert, w\"are f\"ur die bestehende Situation keine
ad\"aquate L\"osung. Da die Kompatibilit\"at ein wichtiger Punkt im Rahmen des
Projektes ist, wurde diese in einer eigenen Schnittstelle definiert
("`Test /Echtsystem"').
\subsection{Layout (Benutzerschnittstelle)}
Das Layout muss vor Beginn der Entwicklung der Weboberfl\"ache definiert sein
und den spezifischen Anforderungen entsprechen. An dieses Layout sollen
s\"amtliche Skripte angepasst sein.
\section{Durchf\"uhrung}
\subsection{Erzeugen des PHP Such-Skripts}
Das PHP Skript wurde nach der Vorlage des Excel Dokumentes erzeugt. Zuerst
wurde das Skript monolithisch erzeugt, d.h. es enthielt keinerlei Module und
s\"amtliche Einstellungen waren in dem Skript selbst zu finden. Da sich
schnell herausstellte, dass eine solche Struktur schlecht zu erweitern ist,
wurde das Skript in mehrere Teile aufgeteilt, welche wiederum modularisiert sind.
Die Module wurden in ein Unterverzeichnis "`modules"' verschoben.
Konfigurationen k\"onnen nun zentral in den dazu passenden Dateien im
"`includes"' Verzeichnis vorgenommen werden.
Es soll die M\"oglichkeit geben, dass die Skripte sp\"ater extern gepflegt oder
erweitert werden. Da dies auch durch Dienstleistungen ausl\"andischer Firmen
geschehen k\"onnte, sind die Kommentare in Englisch. Da ein Gro\ss{}teil der
technischen Literatur in
Englisch geschrieben ist, werden deutsche Informatiker mit den englischen
Kommentaren keine Probleme haben.
Mit einigen Problemen behaftet war der Wechsel von Apache 1.3 zu Apache 2.0.
Der Letztere setzt keine globalen Variablen, wenn selbige durch eine Form
an ein PHP Skript gesendet werden. Dadurch musste nach dem Wechsel der Inhalt der
Formvariablen aus einem speziellen Parameterarray namens "`\_REQUEST"' ausgelesen
werden.
\subsection{Erzeugen des Importfilters}
Der Importfilter ist dem Layout des Hauptskriptes, und damit der allgemeinen
Definition, nachempfunden. Er wurde ebenfalls in PHP geschrieben und importiert
die hochgeladenen ASCII Tabellen in die MySQL Datenbank. Das Format der
ASCII-Tabellen wurde in der entsprechenden Schnittstellendefinition hinterlegt. \\
Das Standardverhalten bei identischen Primary Key Feldern ist, den alten Wert mit
dem neuen zu \"uberschreiben. Die Alternative, Werte zu addieren ist nur in
wenigen F\"allen sinnvoll und w\"urde in der praktischen Anwendung zu komplizierten
Abh\"angigkeiten und einigen zus\"atzlichen Definitionen und Tests f\"uhren. So
m\"usste man z.B. Felder wie die Postleitzahl oder die Telefonnummer gesondert
behandeln. Ebenfalls problematisch w\"are das Ergebnis, wenn jemand aus Versehen
zweimal den Upload Knopf bet\"atigt und somit zum Beispiel den Umsatz f\"ur
einen bestimmten Zeitraum verdoppelt. \\
Problematisch ist auch das Standardverhalten von PHP, welches nur eine maximale
Dateigr\"o\ss{}e von 2MiB vorsieht und einem Skript nur 8MiB Arbeitsspeicher
erlaubt. Wenn die Dateien dieses Limit \"uberschreiten, erzeugt PHP keine
Fehlermeldung, sondern ignoriert die hochzuladende Datei
(verifiziert bei PHP 4.3.4 und 4.3.5RC3).
\subsection{Erzeugen des Initialdatenbankgenerators}
Zur Vereinfachung der Arbeit wurde zus\"atzlich ein Skript eingerichtet, welches
eine initiale Datenbank mit den entsprechenden Tabellen anlegt. Die entsprechenden
Tabellen wurden in den Quelltext integriert, da eine Auslagerung der
Tabellenspezifikation einen zus\"atzlichen Parser erfordert h\"atte.
\subsection{Transfer in das Echtsystem}
Der Transfer in das Echtsystem verlief problemlos.
Der Einsatz im Echtsystem wurde mit dem ISP der WDT abgesprochen und
getestet.
Zuerst wurden die Sicherheitseinstellungen transferiert.
Danach wurden die PHP-Skripte hochgeladen, welche dann gleich zur Initialisierung der
Datenbank und dem Transfer der Echtdaten benutzt wurden. Da die Verbindung
\"uber das \textit{HTTPS}\footnote{Sicheres, verschl\"usselt \"ubertragen von
Dateien; Alternative zu HTTP} Protokoll erfolgt, sind die Daten w\"ahrend des
Transfers verschl\"usselt und f\"alschungssicher.
Die maximale Dateigr\"o\ss{}e f\"ur einen Upload durch PHP ist beim ISP
auf 8MB beschr\"ankt.
Deswegen mussten die Umsatz Tabellen, die pro Jahr eine Gr\"o\ss{}e von 22MiB
haben, aufgeteilt werden.
\section{Dokumentationsphase}
\subsection{Erstellen der Programmdokumentation}
Die Programmdokumentation ist f\"ur die Verwendung durch Entwickler und
Administratoren konzipiert und enth\"alt technische Fachbegriffe.
Sie wurde in Stichw\"ortern w\"ahrend der Durchf\"uhrungsphase niedergeschrieben
und danach zusammengefasst in ein Latex-Dokument. \textit{Latex}\footnote{
Siehe auch die deutsche TeX Webseite http://www.dante.de} ist ein Textsatzsystem,
welches insbesondere f\"ur wissenschaftliche und technische Dokumentation verwendet
wird. Die Programmdokumentation ist entsprechend der Bed\"urfnisse von
Administratoren und Entwicklern gegliedert und aufgebaut. Dies bedeutet z.B.,
dass der Administrator schnell die entsprechenden Sektionen zur Installation
und der Entwickler ebenso einfach den Aufbau der Programme finden kann.
Als Ausgabeformat wurde PDF gew\"ahlt, da dieses Format auf jeder Plattform
lesbar ist.
\subsection{Erstellen des Benutzerhandbuches}
Das Benutzerhandbuch wurde nach der Durchf\"uhrung erstellt. Dadurch
wurde garantiert, dass die Screenshots der Oberfl\"ache sich nicht mehr
ver\"andern k\"onnen. Vom Aufraggeber wurde eine Dokumentation gefordert, die den
Ablauf m\"oglichst pr\"azise und zugleich simpel beschreibt. Dies wurde durch den
Einsatz von Screenshots bewerkstelligt. Als Ausgabeformat wurde eine
Pr\"asentation (entweder im \textit{PowerPoint oder OpenOffice}\footnote{
PowerPoint ist ein Programm aus der Programmgruppe "`Microsoft Office"' von
Microsoft, OpenOffice ist ein OpenSource Konkurrenzprodukt zu Microsoft Office}
Format) gew\"ahlt, da in einer Pr\"asentation wie in einem Buch am Bildschirm
gebl\"attert werden kann.
\subsection{Erstellen der IHK-Projektdokumentation}
Bei der Erstellung dieser Dokumentation wurde \"ahnlich verfahren wie
bei der Erstellung der Programmdokumentation. Jedoch wurde diese Dokumentation
zuerst in OpenOffice geschrieben und nachher in Latex konvertiert, da Latex
wesentlich effektiver f\"ur die Erstellung von gro\ss{}en Dokumenten ist.
\section{Testphase}
\subsection{Testabschnitte w\"ahrend der Erstellung}
W\"ahrend der Entwicklungsphase wurde die Funktionalit\"at der Skripte mit Hilfe
einer Datenbank mit Pseudodaten getestet. Da die Anzahl der S\"atze in der
Datenbank sehr gering war, waren die Ergebnisse schnell verf\"ugbar und es
musste in Betracht gezogen werden, dass die Arbeit mit Echtdaten wesentlich
langsamer laufen k\"onnte. Dies best\"atigte sich jedoch nicht, die Auslieferung
der Daten durch die MySQL Datenbank verlief weiterhin gewohnt schnell. Die Ausgabe
erfolgte teilweise mit Debug Informationen. Diese beinhalteten z.B.
Variableninhalte oder R\"uckgabewerte von Funktionen.
\subsection{Eigentest aller Programme}
Nach der Entwicklungsphase wurden die Programme auf Funktionalit\"at und saubere
Ausgaben \"uberpr\"uft. So durften keine Debug-Nachrichten mehr erscheinen und es
sollten keine Fehler beim "`normalen Benutzen"' auftreten. Es wurde kritisch darauf
geachtet, dass keine Situation auftritt, die ein normaler Benutzer nicht verstehen
kann (z.B. Bildschirm ohne Inhalt). Des weiteren wurden generelle Sicherheitsl\"ucken
\"uberpr\"uft, wie
\textit{Buffer Overflows, SQL-Injektion und Cross-Site-Scripting}\footnote{Buffer
Overflows, SQL-Injektion und Cross-Site-Scripting sind
bekannte Fehler die bei der Programmierung auftreten. Die letzteren beiden
besonders bei der Programmierung von Skripten mit Webzugriff}.
\subsection{Fremdtest aller Programme}
Zum Abschlu\ss{} wurden die Programme von Mitarbeitern aus der EDV Abteilung
getestet und zus\"atzlich auf Sicherheitsl\"ucken gepr\"uft. Durch diese Hilfe
konnten Fehler entdeckt werden, die ein Entwickler selbst nicht bemerkt. So
wurde z.B. bemerkt, dass auf einer Seite ein Teil des Firmenlogos anders angezeigt
wurde ("`stehende Karawane"', sollte "`bewegte Karawane"' sein).
\section{Fazit}
\subsection{R\"uckblick}
Die Programmierung des Skriptes und die Einrichtung des Apache 2.0 mit PHP 4.3.4
aus dem Quelltext verliefen ohne Probleme. Dies wurde durch den Einsatz des
LAMP-Systems gef\"ordert, denn die einzelnen Komponenten,
Linux, Apache, MySQL und PHP, sind sehr gut aufeinander abgestimmt.
Einen Gro\ss{}teil der Zeit musste in die Entwicklung der Schnittstellen und
das Testen investiert werden. \\
Das Teamwork erleichterte die Entwicklungsarbeit, da durch vorhergehende Schulungen
und Tipps w\"ahrend der Entwicklung Probleme im Design fr\"uhzeitig vermieden
werden konnten.
So empfahlen Kollegen das Datenbankdesign in die dritte Form
der Normalisierung zu \"ubertragen um eine Umsetzung in eine relationale Datenbank
zu erleichtern und zeigten an Beispielen, wie dies zu geschehen hat.
Die strikte Trennung der einzelnen Aufgaben erleichterte die Arbeit. Dadurch konnte
problemlos an einem anderen Teil weitergearbeitet werden, w\"ahrend noch die
Echtdaten f\"ur die Datenbank fehlten.
\newpage
\subsection{Zeitplan mit Abweichungen}
\setlongtables
\begin{longtable}{||l|c|c||}
\caption{Zeitplan}
\endfirsthead
\hline \hline
\textbf{Aufgabe} & \textbf{ben\"otigte Zeit} & \textbf{geplante Zeit} \\
& (in h) & (in h) \\
\hline \hline
\textbf{1 Vorarbeiten [Differenz: -1h]} & \textbf{10} & \textbf{11} \\
\hline \hline
1.1 Vorbesprechung mit unserem Au\ss{}endienst & 1 & 3 \\
\hline
1.2 Eruieren und dokumentieren des genauen Problems & 4 & 3 \\
und Definition des IST-Status & & \\
\hline
1.3 R\"ucksprache mit dem Au\ss{}endienst und Abgleich & 1 & 1 \\
des dokumentierten IST-Status mit dem Au\ss{}endienst & & \\
\hline
1.4 Definieren des SOLL-Status & 3 & 3 \\
\hline
1.5 R\"ucksprache mit dem Au\ss{}endienst und Abgleich & 1 & 1 \\
des dokumentierten SOLL-Status mit dem Au\ss{}endienst & & \\
\hline \hline
\textbf{2 Planungsphase [-2h (gesamt: -3h)]} & \textbf{10} & \textbf{12}\\
\hline \hline
2.1 Grob-Modell entwickeln, das die Anforderungen des & 2 & 2 \\
Soll-Status widerspiegelt & & \\
\hline
2.2 Schnittstellen definieren & & \\
\hline
2.2.1 Benutzer/Webinterface ("`Layoutdefinition"') & 1 & 2 \\
\hline
2.2.2 Webinterface/Datenbank & 2 & 2 \\
\hline
2.2.3 Datenbank/Quelldaten & 1 & 2 \\
\hline
2.2.4 Echtsystem/Testsystem & 2 & 2 \\
\hline
2.3 Pflichtenheft erstellen & 2 & 2 \\
\hline \hline
\textbf{3 Realisierungs- und Testphase [+2h (gesamt: -1h)]} & \textbf{28} & \textbf{25} \\
\hline \hline
\multicolumn{3}{||l||}{3.1 Erstellen des Webinterfaces} \\
\hline \hline
3.1.1 Erstellen der Zugriffseinstellungen & 1 & 1 \\
\hline
3.1.2 Erstellen des Hauptprogrammes inklusive & 3 & 2 \\
Datenbankverbindung & & \\
\hline
3.1.3 Erstellen der Loginprozedur & 2 & 2 \\
\hline
3.1.4 Erstellen der Suchprozedur & 3 & 4 \\
\hline
3.1.5 Erstellen der Anzeigeprozedur & 5 & 2 \\
\hline
3.2 Testen des Webinterface in der Testumgebung & 5 & 5 \\
\hline
3.3 Erstellen des Konverters & 3 & 4 \\
(CSV Datenbank in MySQL-Format) & & \\
\hline
3.4 Testen des Konverters in der Testumgebung & 2 & 2 \\
\hline
3.5 Fremdtest des Webinterface in der Testumgebung & 1 & 1 \\
\hline
3.6 Fremdtest des Konverters in der Testumgebung & 1 & 1 \\
\hline
3.7 Transfer des Testsystems in das Echtsystem des Providers & 2 & 2 \\
\hline \hline
\textbf{4 Dokumentationsphase [-5h (gesamt: -6h)]} & \textbf{12} & \textbf{17} \\
\hline \hline
4.1 Erstellen der Programmdokumentation & 7 & 7 \\
\hline
4.2 Erstellen des Benutzerhandbuches & 5 & 10 \\
\hline \hline
\textbf{5 Abschlussphase [(gesamt: -6h)]} & \textbf{1} & \textbf{1} \\
\hline \hline
5.1 Vorstellung des Systems in der Au\ss{}endienstleitung & 1 & 1 \\
\hline \hline
\textbf{6. Pufferzeit f\"ur nicht vorhersehbare Ereignisse} & \textbf{9} & \textbf{3} \\
\hline \hline \hline
\textbf{Gesamtzeit} & \textbf{70} & \textbf{70} \\
\hline \hline
\end{longtable}
Einige Differenzen erl\"autere ich detaillierter, da sie wichtige Aspekte
der Projektentwicklung widerspiegeln.\\
Vorarbeiten:
\begin{itemize}
\item Die Besprechung mit dem Au\ss{}endienst verk\"urzte sich,
da diesem die Problematik des alten Systems schon bekannt war
\end{itemize}
Realisierungs- und Testphase:
\begin{itemize}
\item Die Anbindung an die Datenbank verlief nicht so problemlos wie erwartet, da
w\"ahrend der Entwicklung der Datenbankserver zwei kurze Ausf\"alle hatte. Dies
f\"uhrte zu unvermuteten Ergebnissen im Hauptprogramm.
\item Die Gestaltung der Anzeigeprozedur erwies sich als wesentlich komplexer als
anfangs angenommen, da das Aussehen so wenig wie m\"oglich vom alten System
abweichen sollte.
\end{itemize}
Dokumentationsphase:
\begin{itemize}
\item Die Benutzerhandb\"ucher wurden als einfache Pr\"asentation realisiert und
bedurften kein spezielles Layout oder des Drucks.
\end{itemize}
Pufferzeit f\"ur nicht vorhersehbare Ereignisse:
\begin{itemize}
\item Im Zeitplan wurde der Punkt "`Erstellung der Projektdokumentation"' vergessen
und musste deswegen hier einsortiert werden.
\end{itemize}
\subsection{Ausblick}
\subsubsection{Erweiterung der bestehenden Programme}
Zus\"atzlich zu den bestehenden Anzeigen k\"onnten noch Auswertungen programmiert
werden, die sowohl schriftlich als auch graphisch pr\"asentiert werden.
Des weiteren k\"onnte die Tabellenspezifikation aus init-database.php ausgelagert
und selbiges Skript um einen Parser erweitert werden.
\subsubsection{Hinzuf\"ugen weiterer Programme}
Die Verwaltung der Benutzer k\"onnte durch ein Skript vereinfacht werden, welches
das Hinzuf\"ugen, L\"oschen oder Modifizieren der MySQL Datenbank und der htpasswd
Datei \"ubernimmt. Die Aktualisierung k\"onnte automatisiert werden, wenn von
ProAlpha aus regelm\"assig (z.B. tagesweise) die aktuellen Ums\"atze an ein
Programm \"ubermittelt werden, welches die Daten via HTTPS an das Upload Skript
\"ubertr\"agt.
\subsection{Kostenrechnung}
\subsubsection{altes System}
Die Kosten vorher setzten sich wie folgt zusammen:
14 Au\ss{}endienstler holen 15 MiB gro\ss{}e Dateien zweimal im Monat ab.
Die Internetverbindung erlaubt eine Transferrate von ca. 4 KiB pro Sekunde.\\
\textbf{Rechnung:}
$$\mbox{Transferrate} = \frac{4\mbox{KiB}}{\mbox{s}}$$\\
$$15 \mbox{MiB} * 14 \mbox{ADM} = 210 \mbox{MiB} = 210 * \mbox{1024 KiB} =
215040 \mbox{KiB}$$\\
$$\frac{215040 \mbox{ KiB}}{\frac{4\mbox{ KiB}}{\mbox{s}}} = 53760\mbox{ Sekunden}
= 896\mbox{ Minuten}$$\\
$$1 \mbox{ Minute } \hat{=} 0,39 \mbox{Euro}$$\\
$$896\mbox{ Minuten } * \frac{0,39 \mbox{ Euro}}{\mbox{Minute}} = 349,44
\mbox{ Euro pro Update}$$\\
2 $*$ Monatlich wird das Update gesendet.\\
$$349,44\mbox{ Euro } * 2 = 698,88\mbox{ Euro pro Monat}$$
Dies ergibt eine Online-Nutzdauer von 53.760 Sekunden, was 896 Minuten entspricht.
Bei einem Minutenpreis von 39 Cent pro Minute enstehen \textbf{698,88 Euro}
monatliche Kosten.
\subsubsection{neues System}
Die momentane Kosten setzen sich zusammen aus den Kosten f\"ur das Hosting
des Webinterfaces und den Onlinekosten.
Der Provider bietet einen Webauftritt, der \"uber eine
HTTPS Verbindung abgesichert ist und eine Unterst\"utzung f\"ur PHP und MySQL
enth\"alt, f\"ur 50 Euro pro Monat an. \\
\textbf{Rechnung:}\\
$$\mbox{MySQL Datenbank + PHP + Webspace } =
\mbox{"`Webauftritt"' }= 50\mbox{ Euro pro Monat}$$
$$\mbox{Nutzh\"aufigkeit} = \frac{\mbox{2mal}}{\mbox{Tag}}\mbox{ (benutzt der
ADM das Webinterface)}$$\\
Dies macht er an 20 Tagen (Arbeitstage) im Monat.
$$\frac{\mbox{zweimal}}{\mbox{Tag}} * \frac{\mbox{Arbeitstage}}{\mbox{Monat}} = 40
\mbox{mal Nachsehen pro Monat (pro ADM)}$$\\
$$14 \mbox{ ADM} * 40\mbox{mal} \mbox{ Nachsehen} = 560\mbox{mal}
\frac{\mbox{Nachsehen}}{\mbox{Monat}}$$\\
Einmal Nachsehen entspricht statistisch nach einer Umfrage einer Minute
(da nicht jeder das Angebot nutzen w\"urde und manche l\"anger brauchen).\\
$$560 \mbox{Minuten} * \frac{0,39\mbox{ Euro}}{\mbox{Minute}} = 218.40
\mbox{Euro}$$\\
$$218,40 + 50,00 = 268,40 \frac{\mbox{Euro}}{\mbox{Monat}}$$
Damit ergeben sich kumuliert Kosten von \textbf{268,40 Euro} pro Monat.\\
In dieser Rechnung sind jedoch nicht die Entwicklungskosten f\"ur das neue
System enthalten. Diese setzen sich zusammen aus dem Stundenlohn und der Anzahl
der ben\"otigten Stunden.\\
\textbf{Rechnung:}
$$70\mbox{ Stunden} * 5\mbox{ Euro} = 350\mbox{ Euro}$$
Dieser Betrag ist nur einmal f\"allig und amortisiert sich im Normalfall \"uber
die Jahre. In unserem speziellen Fall sind die Entwicklungskosten sogar schon nach
einem Monat kompensiert.\\
\subsubsection{Kostenvergleich}
Das neue System erbringt eine Kostenvorteil von \textbf{430,48 Euro}
beziehungsweise verbraucht nur \textbf{38\%} der alten Kosten pro Monat.
\section{Anhang}
\subsection{Literatur}
\subsubsection{PHP}
\begin{itemize}
\item "`PHP kurz \& gut"', O'Reilly, ISBN 3-89721-225-0
\item "`Programmieren lernen in PHP4"', Hanser, ISBN 3-446-21754-1
\item http://www.php.net
\end{itemize}
\subsubsection{Apache}
\begin{itemize}
\item http://httpd.apache.org/
\end{itemize}
\subsubsection{HTTP}
\begin{itemize}
\item HTTP Pocket Reference, O'Reilly, ISBN 1-56592-862-8
\end{itemize}
\subsubsection{MySQL}
\begin{itemize}
\item Managing and Using MySQL, 2nd Edition, O'Reilly, ISBN 0-596-00211-4
\end{itemize}
\subsection{Schnittstellen}
\subsubsection{Benutzer/Weboberfl\"ache: Layoutdefiniton}
\begin{verbatim}
--------------------------------------------------------------------------------
Nico Schottelius, v0.6
Schnittstelle: Webinterface/Layout
--------------------------------------------------------------------------------
1. Generelle Layoutdefiniton
2. Benutzerinteraktion
3. Authentifizierung
4. Sicherheit
5. Einstiegsbildschirm
6. Suchergebnisse
7. Suchdetails
1. Generelle Layoutdefiniton
Die Weboberfläche sollte von der Farbwahl der Firmenhomepage [WL1] ähneln.
Zudem sollte ein firmentypisches Objekt (Logo, Motto, etc.) präsent sein.
2. Benutzerinteraktion
Der Benutzer soll die Oberfläche intuitiv bedienen können.
Fachwörter und technische Details sind zu verbergen, Fehlermeldungen wenn
möglich durch einfache Hinweise zu ersetzen.
3. Authentifizierung
Der Webserver (hier: Apache) sendet nach dem GET Aufruf des Clients
einen 401 (Unauthorized) Code und den WWW-Authenticate Header an den Browser. [WL2]
Dieser Header kann zusätzlich noch einen Text enthalten, wie z.B.
"Nur für Außendienstler erlaubt".
Die Authentifizierung wird dann in einem vom Browser selbstdefinierten
Authentifizierungsfenster durchgeführt, das den zusätzlichen Text
des Serverheaders beinhalten kann, jedoch nicht muss.
Das bedeutet das man Serverseitig nur definieren kann, das sich der Client
authentifizieren muss, jedoch nicht wie dieses Fenster aussieht (im Gegensatz
zu Javascript basierten Authentifizierungen, die jedoch keine echte Sicherheit bieten).
Die Authentifizierung wird Serverseitig durch die htaccess Methodik [WL3]
definiert. Diese benötigt die htaccess Einstellungen selbst [WL4] und
zur Benutzerverwaltung die htpasswd [WL5].
Des weiteren müssen die in der htpasswd vorhandenen Benutzer noch in der
MySOL Benutzerverwaltung angelegt werden. Diese erhalten dort ein
leeres Passwort vergeben, da die htaccess Authentifizierung ausreichend ist.
4. Sicherheit
Folgende Sicherheitsanforderungen sind vorhanden:
- Datenintegrität: die Daten müssen gewährleistet unveränderbar sein
- Vertraulichkeit: niemand darf unauthorisiertes Daten lesen können
- Verfügbarkeit: die Datenverbindung muss ständig verfügbar sein
Die ersten beiden Anforderungen werden durch das TLS Protokoll [WL5] erfüllt.
Die Verfügbarkeit des Webinterface im Internet ist abhängig von der Verfügbarkeit des Web- und MySQL Servers.
5. Einstiegsbildschirm
Die Einstiegsseite zeigt den Namen des aktuell angemeldeten Benutzers an.
Des weiteren befindet sich ein Auswahlfeld, das die Suchoptionen enthält,
und des Suchbegrifffeld auf dieser Seite.
Dem Benutzer muss eine angemessen Suchfunktion zur Verfügung stehen, die
das Suchen nach den erforderlichen Parametern erlaubt.
Als Suchoptionen müssen die folgenden vorhanden sein:
- Kundennummer
- Kundenname
- Praxennummer
- Telefon
- PLZ
- Ort
6. Suchergebnisse
Auf der Seite der Ergebnisse sollen der Suchbegriff und das Suchkriterium
als Überschrift dargestellt werden.
Die Suchergebnisse werden tabellarisch dargestellt, die Ergebnisse sind
geordnet nach Kundennummern, aufsteigend.
Des weiteren muss die Möglichkeit bestehen die Ergebnisse nach
den anderen angezeigten Feldern zu sortieren.
7. Suchdetails
Diese Seite soll sich an dem Beispiel Excel Dokument [WL6] orientieren.
Sie muss Details über den Kunden enhalten, u.a. die Anschrift
und soweit vorhanden die Telefonnummer.
[WL1]: http://www.wdt.de
[WL2]: RFC 2616
[WL3]: http://httpd.apache.org/docs-2.0/howto/auth.html
[WL4]: Beispiel: siehe Anhang dot-htaccess
[WL5]: RFC 2246, RFC 3546, Beispiel: htpasswd
[WL6]: Internes Dokument: Beispiel_Excel.xls
\end{verbatim}
\subsubsection{Weboberfl\"ache/Datenbank: Zugriffsdefiniton}
\begin{verbatim}
--------------------------------------------------------------------------------
Nico Schottelius, v0.2
Schnittstelle: Webinterface/Datenbank
--------------------------------------------------------------------------------
Tabellen und Felder in der Datenbank
------------------------------------
Die Typen der Felder und Tabellen sind in [WED1] dokumentiert.
Die Namen der Felder und Tabellen sind in [WED2] definiert.
Der Datenbankname und Datenbankserver sind frei wählbar, muessen
jedoch in der Konfigurationsdatei [WED3] angegeben werden.
Quellen:
[WED1]: Siehe Anhang: 2.2.3 Schnittstelle Datenbank/Quelldaten
[WED2]: Siehe Anhang: Quellcode zu modules/init-db-create.php,
Funktion create_db, array "$creat_query"
[WED3]: Siehe Anhang: Quellcode zu includes/db-settings.php
\end{verbatim}
\subsubsection{Datenbank/Quelldaten: Importformatdefiniton}
\begin{verbatim}
--------------------------------------------------------------------------------
Nico Schottelius, v0.6
Schnittstelle: Quelldaten/Datenbank
--------------------------------------------------------------------------------
1. Quelldaten
2. Zielform
3. Ziellayout / Typdefinition
4. Verhalten beim Import
1. Quelldaten
Die Quelldaten liegen in der Progressdatenbank [QDD1]. Sie müssen mithilfe von
Progress oder Alternativ ProAlpha [QDD2] ausgelesen werden.
2. Zielform
Es sollen CSV Tabellen entsprechend der Typdefinition erstellt werden, wobei pro Tabelle eine Datei erstellt wird.
Der Trenner soll jedoch kein Komma sein, sondern ein Semikolon.
Tabellenspalten sind getrennt durch Semikolen, Tabellenzeilen getrennt durch
Zeilenumbruch, kein Header (wie z.B. ADM Name; ADM Nr) ist vorhanden,
Reihenfolge wie unten in der Typdefinition.
3. Ziellayout / Typdefinition
Feldnamen(*) genutzte Feldergroessen
* = Bemerkung vorhanden
0. ADM-Tabelle
ADM-Nr.* [int]
ADM-Name. [text 255 stellig]
ADM-Nr. ist >=0 und <=999.
Nummern >=1000 und <=9999 werden fuer adminstrative Zwecke genutzt.
1. Kundentabelle
KundenNr.* [int]
Prax.Nr.* [int]
ADM-Nr. [int] [wie oben]
Name [text 255 stellig]
Strasse [text 255 stellig]
Strassennummer [text 255 stellig]
PLZ [text 255 stellig]
Ort [text 255 stellig]
Telefon [text 255 stellig]
KundenNr sind 6 stellig
PraxNr sind 6 stellig
2. Umsatztabelle
KundenNr. [int] [wie oben]
ArtNr. [int] [wie unten]
Umsatz [float]
Menge [int]
Tag [int]
Monat [int]
Jahr* [int]
Jahr ist vierstellig
3. Artikeltabelle
ArtNr. [int]
ArtName [text 255 stellig]
GruppenName [text 255 stellig]
4. Verhalten beim Import
Wenn ein Datensatz mit identischen Primary Key vorhanden ist,
so werden die alten Daten in der Zieldatenbank mit den neuen Werten
überschrieben.
Quellen:
[QDD1]: http://www.progress.de/, http://www.progress.com/
[QDD2]: http://www.proalpha.de/
\end{verbatim}
\subsubsection{Test-/Echtsystem}
\begin{verbatim}
--------------------------------------------------------------------------------
Nico Schottelius, v0.2
Schnittstelle: Test-/Echtsystem
--------------------------------------------------------------------------------
1 generelle Anpassungen
2 Probleme mit anderen PHP oder Apache Versionen oder Konfigurationen
1 generelle Anpassungen
Der Datenbankname und Datenbankserver müssen in der Konfiguration
"includes/db-settings.php" angepasst werden.
2 Probleme mit anderen PHP oder Apache Versionen oder Konfigurationen
Der Apache 2.0 bietet bei PHP keine globalen Variablen.
Der Aufruf von "/script.php?option=test" setzt nur im Apache 1.3.x die Variable
"option". Im Apache 1.3.x und im Apache 2.0 kann man jedoch über den Array
_REQUEST und dem index des Variablennamens (z.B. $_REQUEST['option']) den Inhalt
auslesen.
Für das Verzeichnis in dem die Skripte liegen muss in der Apache Config
"AllowOverride Auth" angeschaltet sein, damit die .htaccess Datei beachtet wird.
In der Standard Installation von PHP dürfen Dateien beim Upload nicht
größer sein als 2MiB.
Somit muss unter Umständen die Tabellengröße auf 2MiB limitiert werden.
Dies ist jedoch unproblematisch, da die Aktualisierung der Datenbank
inkrementell geschehen kann. Somit ist die Möglichkeit gegeben z.B.
monatlich, wöchentlich, oder sogar täglich eine Aktualisierung vorzunehmen.
Je kleiner die Abstände sind, desto kleiner sind logischerweise auch die Dateien.
Sollte eine Tabelle größer werden als 2MiB, so kann man sie auch teilen und
in mehreren Schritten hochladen.
Das Limit muss mit dem Provider abgeklärt werden.
\end{verbatim}
\subsection{Quelltext}
\subsubsection{includes/search.php}
\begin{verbatim}
"kunden",
"Kundenname" => "kunden",
"Praxennummer" => "kunden",
"Telefon" => "kunden",
"PLZ" => "kunden",
"Ort" => "kunden"
);
/* felder in den tabellen */
$suchbegriff_felder = array(
"Kundennummer" => "nr",
"Praxennummer" => "praxisnr",
"Kundenname" => "name",
"Telefon" => "telefon",
"PLZ" => "plz",
"Ort" => "ort",
);
/* felder in den tabellen */
$suchbegriff_map_field_eqto_kdnr = array(
"Kundennummer" => "nr",
"Praxennummer" => "praxisnr",
"Kundenname" => "name",
"Telefon" => "telefon",
"PLZ" => "plz",
"Ort" => "ort",
);
/*
Ausgabe: wie in excel
PraxenNummer
Kundennummer
Kundenname
PLZ
Telefon
Ort
WDT-Laufendes Jahr
Differenz Vorjahr
PRX-Laufendes Jahr
Differenz Vorjahr
GRO-Laufendes Jahr
Differenz Vorjahr
*/
?>
\end{verbatim}
\subsubsection{includes/db-settings.php}
\begin{verbatim}
\end{verbatim}
\subsubsection{init-database.php}
\begin{verbatim}
Initialisieren der Datenbank
';
$FOOTER='
