Publisher's Synopsis
Inhaltsangabe: Problemstellung: Meist ist der Einsatz eines kommerziellen Programms für ein Unternehmen die wirtschaftlichere Variante, als eine Softwareanwendung selbst zu entwickeln. Obwohl es auch im Bereich Projektmanagement mehrere Produkte gibt, welche viele Komponenten der Projektdatenbank erfüllen könnte, sind diese für die tägliche Arbeit des Projektmanagers (noch) nicht die erste Wahl. Der Hauptgrund ist sicherlich, dass die Projektdatenbank in der Anwendung und bei der Konfiguration der einzelnen Komponenten flexibler ist. Außerdem bieten die kommerziellen Produkte zu einem oft hohen Preis entweder gerade die eine erforderliche Komponente nicht, oder sind mit nicht benötigen Tools überfrachtet. Trotzdem hat auch der bisherige Einsatz der eigenentwickelten Datenbank gezeigt, dass eine solche Anwendung nur so gut ist, wie deren Benutzer. Diese müssen bei der Eingabe der Daten die Vollständigkeit wahren und die vorhandenen Regeln einhalten. Gerade die korrekte und vollständige Erfassung der Eingabeparameter ist der Schlüssel für eine umfangreiche Dokumentation und verschiedene Auswertungsmöglichkeiten. Dies stellt aber eine Gratwanderung dar, zwischen der für viele Kollegen erforderlichen Flexibilität und der strukturierten Eingabe von Daten um diese weiter verarbeiten zu können. Gleichzeitig hängt die Akzeptanz bei den Bearbeitern aber entscheidend von einer flexiblen und leichten Bedienung ab. Das Ergebnis dieser Gratwanderung stellt eine wichtige Voraussetzung für den weiteren Einsatz der Datenbank dar. Die Projektdatenbank selbst wurde im Laufe einer Projektbearbeitung aus der Praxis für die Praxis zunächst in MS Access 2000 entwickelt. Je nach Projektstadium wurden nach und nach weitere Module" aufgenommen, so dass die Datenbank bis zuletzt lebte". Der Mehrbenutzerbetrieb und die Weiterentwicklung der Datenbank machte eine Migration in eine Front und Back End Lösung erforderlich. Dies erfolgte mit ODBC da die meisten Funktionen nach dem Upsizen unve
