Vorgehensmodell für die Entwicklung von WWW-Informationssystemen

Inhaltsverzeichnis:

1 Einleitung
1.1 Problemstellung
1.2 Gang der Untersuchung

2 Begriffsklärungen und Grundlagen
2.1 Vorgehensmodelle
2.1.1 Allgemein
2.1.2 Arten von Entwicklungsschemata
2.1.2.1 Ergebnisorientierte Entwicklungsschemata
2.1.2.2 Arbeitsprozessorientierte Entwicklungsschemata
2.2 Informationssysteme
2.2.1 Allgemein
2.2.2 Modellierungsarten
2.3 WWW-Informationssysteme
2.3.1 Einsatzarten
2.3.2 Unterschiede zu betrieblichen Informationssystemen und zur Software-Entwicklung

3 Auswahl eines geeigneten Entwicklungsschemas für WWW-Informationssysteme
3.1 Probleme und Anforderungen
3.2 Vorhandene Vorgehensmodelle aus verwandten Themenbereichen
3.2.1 Vorgehensmodell für die Entwicklung von Informationssystemen
3.2.2 Vorgehensmodelle bzw. Vorgehensweisen für das WebPublishing
3.2.3 Vorgehensmodelle für Multimedia und Hypermedia
3.3 Ergebnis

4 Darstellung des Vorgehensmodells für die Entwicklung von WWW-Informationssystemen (VEWIS)
4.1 Planung
4.2 Anforderungsdefinition und -analyse
4.3 Entwurf des WWW-Informationssystems
4.4 Entwicklung der WebSite
4.4.1 Entwurf der WebSite
4.4.1.1 Entwurf der Seitenorganisation
4.4.1.2 Entwurf des Seitenlayouts
4.5 Implementierung und Test
4.6 Serveraufbau
4.7 Erstellung der Inhalte
4.8 Programmierung
4.9 Aufbau der Datenbank
4.10 Einsatz und Werbung
4.10.1 Beurteilung des Einsatzes
4.10.2 Werbung
4.11 Wartung
4.11.1 Fehlerkorektur
4.11.2 Weiterentwicklung

5 Zusammenfassung und Ausblick

6 Literaturverzeichnis

Abbildungsverzeichnis:

Abbildung 1: Vorgehensmodell für die Entwicklung von WWW-Informationssystemen (VEWIS)

Abkürzungsverzeichnis:

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Problemstellung

Seitdem das WWW öffentlich zugänglich ist, hat es ein immenses Wachstum zurückgelegt. Es präsentieren sich im WWW immer mehr Unternehmen, Institutionen, Privatleute und andere. Dies liegt zum einen daran, daß es prinzipiell jedem möglich ist seine Informationen, ob privat oder geschäftlich, im WWW anzubieten. Zum anderen bieten sich durch das WWW eine Vielzahl neuer Möglichkeiten. Beispielsweise haben sich durch das WWW für die Präsentation, den Vertrieb und die Kommunikation ganz neue Wege ergeben. Selbst kleinen Unternehmen steht durch das WWW ein riesiger, ständig wachsender, weltweiter Markt zur Verfügung wobei die Kosten hierfür je nach Größe des eigenen Informationsangebots relativ gering sind. Es gibt nicht wenige Leute, die der Meinung sind, daß das WWW in Zukunft eines der wichtigsten Mittel zur Kommunikation, Informationsfindung und zum Handel sein wird. Deswegen kann sich heutzutage eigentlich kein größeres Unternehmen erlauben, nicht im Web präsent zu sein.

Den Vorteilen des Web, wie weltweite, ganztägige Verfügbarkeit, Größe, Multimedialität und Integration weiterer Internetdienste, stehen allerdings auch Probleme gegenüber. Neben Problemen wegen der geringen Bandbreite liegt ein Hauptproblem darin, daß es oft schwierig ist die gewünschten Informationen im Web zu finden. Dies liegt zum einen an der Größe und Informationsvielfalt des Web, zum anderen daran, daß viele WWW-Informationssysteme keinen strukturierten Aufbau erkennen lassen. Bei solchen schlecht strukturierten WWW-Informationssystemen fällt es besonders ungeübten WWW-Benutzern schwerer an die gewünschten Informationen zu gelangen. Allerdings ergeben sich aufgrund der schlechten Strukturierung oft auch Probleme für den Informationsanbieter. Spätestens wenn er das WWW-Informationssystem entweder durch hinzufügen neuer WebPages oder neuer Komponenten, wie z. B. einer Datenbank, erweitern will, wird er feststellen, daß dies bei unstrukturierten WWW-Informationssystemen schwerfällt. Er muß nämlich überprüfen welche Seiten von der Änderung betroffen sind. Da das WWW-Informationssystem aber unstrukturiert aufgebaut wurde, ist es schwierig für Ihn einen Überblick über die Seiten zu bekommen. Mit dem weiteren Wachstum des WWW-Informationssystems nimmt auch dieses Problem zu. Dies kann zu einer Krise führen, die mit der Softwarekrise vergleichbar ist. Die Softwarekrise wurde teilweise durch die Einführung von Vorgehensmodellen für die Softwareentwicklung gelöst. Das Einführen von Vorgehensmodellen für die Entwicklung von WWW-Informationssystemen kann sicherlich auch eine Krise bei WWW-Informationssystemen teilweise verhindern. Da das WWW noch relativ jung ist, bestehen für die Entwicklung von WWW-Informationssystem allerdings noch keine Modelle zum strukturierten Vorgehen. Die meiste Literatur zu dem Thema WWW bezieht sich auf die Erstellung einzelner WebPages. Darüber hinaus findet man hin und wieder auch Literatur über die Entwicklung ganzer WebSites oder die Anbindung einer Datenbank an das WWW. Fast vergebens sucht man allerdings nach Literatur über das strukturierte Vorgehen bei der Entwicklung eines WWW-Informationssystems, welches Komponenten wie Datenbanken und Server einbezieht. Aus diesem Grund wird im Rahmen dieser Diplomarbeit ein Modell für das strukturierte Vorgehen bei der Entwicklung von WWW-Informationssystemen erstellt. Dazu werden zuerst Vorgehensmodelle bzw. Entwicklungsschemata aus Bereichen, die in Verbindung mit der Entwicklung von WWW-Informationssystemen stehen, wie die Softwareentwicklung, die Entwicklung betrieblicher Informationssysteme und Multimedia, vorgestellt und hinsichtlich ihrer Eignung für die Entwicklung von WWW-Informationssystemen überprüft. Daneben werden vorhandene Vorgehensweisen für die Entwicklung von WebSites und WWW-Informationssystemen vorgestellt und beurteilt. Aufbauend auf dieser Untersuchung wird ein Vorgehensmodell für die Entwicklung von WWW-Informationssystemen, im folgenden auch kurz VEWIS genannt, entwickelt und vorgestellt.

1.2 Gang der Untersuchung

Zuerst werden in Kapitel 2 die Begriffe Vorgehensmodell, betriebliche Informationssysteme und WWW-Informationssysteme erklärt. Außerdem werden Entwicklungsschemata des Softwareengineering für Vorgehensmodelle vorgestellt und Unterschiede zwischen WWW-Informationssystemen und betrieblichen Informationssystemen bzw. der Softwareentwicklung dargestellt.

In Kapitel 3 werden als erstes die Probleme vorgestellt, die häufig im Zusammenhang mit der Entwicklung von WWW-Informationssystemen auftreten. Außerdem sollen die Anforderungen genannt werden, die aufgrund der Probleme an ein Vorgehensmodell für die Entwicklung von WWW-Informationssystemen gestellt werden. Danach werden Vorgehensmodelle für die Entwicklung von WWW-Informationssystemen oder aus benachbarten Gebieten dargestellt und unter Berücksichtigung der Anforderungen und Probleme bewertet. Am Ende von Kapitel 3 wird beschrieben, welche Elemente der Vorgehensmodelle und Entwicklungsschemata in das Vorgehensmodell für die Entwicklung von WWW-Informationssystemen (VEWIS) eingeflossen sind.

Das VEWIS wird dann ausführlich in Kapitel 4 erklärt und die einzelnen Phasen des Vorgehensmodell beschrieben. Dabei werden die durchzuführenden Aktivitäten, die zu erbringenden Ergebnisse, einzusetzenden Methoden und Werkzeuge erläutert.

Zum Schluß wird in Kapitel 5 das Ergebnis kurz zusammengefaßt und ein Ausblick auf die weitere mögliche Entwicklung des Vorgehensmodells gegeben.

2 Begriffsklärungen und Grundlagen

2.1 Vorgehensmodelle

2.1.1 Allgemein

Ein Vorgehensmodell wird definiert als "...ein Muster zur Beschreibung eines Entwicklungsprozesses auf der Basis eines Entwicklungsschemas." ([FBM98], S. 18). Ein Beispiel für ein Vorgehensmodell ist das V-Modell. Der Entwicklungsprozeß, welcher durch das Vorgehensmodell beschrieben werden soll, stellt dabei den Lebenszyklus eines Softwareprodukts dar. Dieser Lebenszyklus beginnt mit der Planung der Entwicklung des Softwareprodukts und endet damit, daß das Softwareprodukt nicht mehr eingesetzt bzw. aus Entwicklersicht weiter entwickelt und gepflegt wird. Ein Entwicklungsschema stellt eine prinzipielle Strategie für das Vorgehen bei der Entwicklung dar. Sie dient, wie oben definiert, als Basis für ein Vorgehensmodell. Um ein Vorgehensmodell zu erhalten, erstellt man auf Grundlage des Entwicklungsschemas ein Vorgehen für eine bestimmte Aufgabe. In Kapitel 4 wird beispielsweise auf Grundlage des Phasenmodells, der evolutionären Entwicklung und des Prototyping ein Vorgehensmodell für die Entwicklung von WWW-Informationssystemen abgeleitet.

Vorgehensmodelle stellen einen idealisierten Ablauf eines Entwicklungsprozesses dar und sollen dessen Analyse ermöglichen. Sie bestehen hauptsächlich aus Aktivitätstypen und Ergebnistypen. Aktivitätstypen stellen eine Abstraktion von Aktivitäten dar, wobei eine Aktivität die konkrete Durchführung eines Arbeitsschrittes ist. Aktivitäten erzeugen oder verwenden Ergebnisse, die wiederum als Ergebnistyp abstrahiert werden. Es bestehen Beziehungen zwischen den Ergebnissen und Aktivitäten, bzw. Ergebnistypen und Aktivitätstypen, die in der Ablaufstruktur abgebildet werden. Aktivitäten erzeugen beispielsweise Ergebnisse, die wiederum in Aktivitäten weiterverarbeitet werden. Es bestehen allerdings auch Beziehungen zwischen den einzelnen Aktivitätstypen bzw. Ergebnistypen untereinander. Diese werden in der Aktivitäts- bzw. Ergebnisstruktur dargestellt. Die Ergebnistypen stellen die Bestandteile des Softwareprodukts dar, die z.B. verschiedene Aufgaben innerhalb des Programms erfüllen und untereinander in Beziehung stehen, um das Programm als Ganzes zum laufen zu bringen (vgl. [Chr92], S. 55-80). Für konkrete Projekte muß man aus einem Vorgehensmodell einen konkreten Entwicklungsprozeß ableiten. Dazu paßt man die Aktivitäten und Ergebnisse des Vorgehensmodells beim Tailoring an das konkrete Projekt an.

Für Vorgehensmodelle die ausgeliefert werden, gibt es prinzipiell drei Grundtypen. Das Dach-Modell, welches im Prinzip alle notwendigen Aktivitäten und Resultate enthält, das Kern-Modell, welches die wichtigsten Aktivitätstypen und Resultatstypen enthält und meistens ergänzt werden muß, und das modulare Bausteinmodell, welches aus relativ unabhängigen Teilmodellen besteht, wobei für dieselbe Aufgabe verschiedene Teilmodelle vorhanden sein können (vgl. [Chr92], S. 45).

2.1.2 Arten von Entwicklungsschemata

In diesem Kapitel sollen bekannte Entwicklungsschemata kurz vorgestellt und verglichen werden, um später unter Umständen nach einem oder mehreren von ihnen ein Vorgehensmodell zu entwickeln.

2.1.2.1 Ergebnisorientierte Entwicklungsschemata

Es werden im folgenden das Phasenmodell, das Wasserfallmodell mit Rückkopplung und das U-Modell vorgestellt. Sie sind aufgrund ihrer sequentiellen, unflexiblen Vorgehensweise für Entwicklungsprozesse geeignet, bei denen das Problem schon bekannt und das Anwendungsfeld, auf das sie sich beziehen, schon älter ist, da bei diesen Erfahrungen vorliegen und der Entwicklungsprozeß stärker standardisiert werden kann. (vgl. [Bre98], S. 35 und 55 -57) Die Modelle sind vom Projektmanagement gut organisierbar, allerdings wird oft kritisiert, daß sie in der Realität nicht vollständig umsetzbar sind. (vgl. [BuF97], S. 14)

2.1.2.1.1 Phasenmodell

Das Phasenmodell war das erste bekannte Entwicklungsschema für Software, auf dem alle anderen Entwicklungsschemata aufbauen. Deswegen soll es hier etwas ausführlicher mit seinen einzelnen Phasen dargestellt werden. Es ist ergebnisorientiert und seine Anwendung ist sinnvoll bei alten, bekannten Anwendungsfeldern, die schon stark standardisiert sind. Es teilt den Lebenszyklus von Software in verschiedene Phasen ein, für die jeweils zu definieren ist, welches Ergebnis erzeugt werden muß. Erst wenn die Ergebnisse erzeugt und die Phase abgeschlossen wurde, darf die nächste Phase in Angriff genommen werden. Das Phasenmodell beginnt bei der Problemanalyse und Planung, auf die dann Systemspezifikation (Anforderungsdefinition), System- und Komponentenentwurf, Implementierung und Komponententest, Systemtest und zuletzt Betrieb und Wartung folgen (vgl. [PoB96], S. 17). Diese Phasen sollen jetzt kurz vorgestellt werden:

In der Analyse- und Planungsphase wird eine Ist-Analyse durchgeführt und es werden die Hauptfunktionen, die Hauptanforderungen und die wichtigsten Qualitätsmerkmale in einem Rahmenvorschlag festgelegt. Außerdem wird eine Untersuchung hinsichtlich der technischen, personellen und ökonomischen Durchführbarkeit und alternativer Lösungen vorgenommen. Am Schluß ist zu entscheiden, ob das Produkt hergestellt werden soll (vgl. [Bal92], S. 74 + 75). Soll das Produkt hergestellt werden, müssen in der Systemspezifikation die Anforderungen ermittelt, festgelegt, beschrieben, analysiert und verabschiedet werden, so daß sie in einem Pflichtenheft festgehalten werden können. Außerdem soll ein genauer Projektplan festgelegt werden.(vgl. [Bal92], S. 95 + 96) Ausgehend von dem Pflichtenheft soll in der System- und Komponentenentwurfsphase eine Systemarchitektur des zu erzeugenden Produkts entworfen werden, deren Komponenten die Anforderungen erfüllen. Außerdem müssen die Schnittstellen und Wechselwirkungen zwischen den Komponenten und das logische Datenmodell festgelegt werden. In der Implementierungs- und Komponententestphase werden die Entwürfe in eine Programmiersprache und gegebenenfalls in ein physisches Datenmodell übertragen und diese in ausführbare Programme übersetzt. Außerdem werden die Systemkomponenten auf semantische Korrektheit geprüft. Danach wird beim Systemtest das System als ganzes und die Wechselwirkungen zwischen den Komponenten unter realen Bedingungen geprüft. Nachdem die Tests erfolgreich durchgeführt wurden, beginnt die Betriebs- und Wartungsphase, d. h. das Produkt wird betrieblich eingesetzt und gewartet. Wartung ist ein Oberbegriff für die Wartung im engeren Sinne und der Pflege. Die Wartung im engeren Sinne beinhaltet die Beseitigung von Fehlern, die während des Einsatzes festgestellt werden, während die Pflege die Anpassung an Änderungswünsche und Veränderungen sowie Weiterentwicklungen umfaßt.

Neben den genannten Phasen gehören zum Phasenmodell noch die Tätigkeiten Dokumentation, Qualitätssicherung und Konfigurationsmanagement, welche projektbegleitend durchgeführt werden.(vgl. [PoB96], S. 19 + 20) Das Hauptproblem des Phasenmodells liegt darin, daß die Phasen in der Praxis nur selten strikt getrennt werden können. Dies gilt insbesondere für die Phasen System- und Komponentenentwurf, Implementierung und Komponententest, da speziell bei der Top-down-Vorgehensweise jede Ebene zuerst entworfen und dann implementiert wird (vgl. [Bal92], S. 189). Deshalb müssen die Phasen entweder teilweise gemischt werden oder es muß eine Möglichkeit geben in vorhergehende Phasen zu wechseln. Bei der Systemspezifikation ist häufig das Problem aufgetreten, daß die konkreten Anforderungen erst während des Entwurfs den Betroffenen klar wurden. Deswegen sollte hier eine Möglichkeit vorliegen, von der Entwurfsphase in die Systemspezifikationsphase zu wechseln, um Änderungswünsche zu berücksichtigen. Auch wurde kritisiert, daß die Kommunikation zwischen Auftraggeber- bzw. Benutzerseite und den Entwicklern ungenügend waren (vgl. [Bal92], S. 97). Ein weiteres Problem des Phasenmodells liegt darin, daß erst sehr spät greifbare Ergebnisse vorliegen, anhand derer die Auftraggeber und Benutzer das Produkt validieren und Änderungswünsche äußern können (vgl. [PoB96], S. 23). Aus diesen Gründen wurden vom Phasenmodell weitere Entwicklungsschemata abgeleitet, welche diese Probleme beheben sollen. Man sollte daher nicht strikt nach dem Phasenmodell vorgehen, sondern es eher als ein Mittel für die Organisation der Entwicklung sehen (vgl. [Bal92], S. 111).

2.1.2.1.2 Wasserfallmodell mit Rückkopplung

Beim Wasserfallmodell mit Rückkopplung wird die strenge sequenzielle Vorgehensweise aufgegeben und eine Rückkopplung zwischen den Phasen eingeführt. Allerdings soll diese Rückkopplung nur zwischen aufeinanderfolgenden Phasen stattfinden. Zusätzlich wird eine Validierung der Phasenergebnisse z. B. durch Prototypen am Ende jeder Phase durchgeführt. (vgl. [PoB96], S. 24)

2.1.2.1.3 U-Modell

Beim U-Modell (oft auch V-Modell genannt) werden die Qualitätssicherungsmaßnahmen stärker einbezogen. Der Entwicklungsprozeß wird in zwei Hälften eingeteilt, deren Phasen sich gegenüberstehen. Auf der einen Seite stehen die Entwurfstätigkeiten, d.h. Problemanalyse und Planung, Systemspezifikation (Anforderungs-definition), System- und Komponentenentwurf, Implementierung, während auf der anderen Seite die Integrationstätigkeiten stehen, das heißt beginnend bei der Implementierung, der Komponententest, Systemtest und zuletzt Betrieb und Wartung. Neben den Rückkopplungen des Wasserfallmodells, werden die Beziehungen zwischen den Entwürfen und den entstandenen Ergebnissen überprüft (z. B. zwischen Systementwurf und -test und Komponentenentwurf und -test).(vgl. [Bre98], S. 41 + 42 und [HFM92], S. 37)

2.1.2.2 Arbeitsprozessorientierte Entwicklungsschemata

Es werden hier Prototyping, die Evolutionäre Entwicklung, das Spiralmodell und die objektorientierte Softwareentwicklung vorgestellt. Diese Entwicklungsschemata sind aufgrund ihrer inkrementellen, zum Teil iterativen und flexiblen Vorgehensweise, für Entwicklungsprozesse geeignet, bei denen Erfahrungen fehlen und der Entwicklungsprozeß noch nicht standardisiert werden kann. Beispiele hierfür sind zum einen Probleme die bisher noch nicht aufgetreten waren und zum anderen Anwendungsfelder die noch neu sind. (vgl. [Bre98], S. 37 und 55 -57) Eine als Gegenüber den ergebnisorientierten Entwichlungsschemata haben die genannten Entwicklungsschemata den Vorteil einer größeren realitätsnähe. Allerdings sind sie vom Management schwer zu beherrschen. (vgl. [BuF97], S. 14)

2.1.2.2.1 Prototyping

Die Probleme des Phasenmodells, der erst spät vorliegenden greifbaren Ergebnisse und der mangelhaften Kommunikation, sollen im Prototyping-Ansatz gelöst werden. Es werden bestimmte Systemkomponenten frühzeitig durch Prototypen realisiert, d.h. durch unvollständige Implementierungen, die der Benutzer schon bewerten kann und damit die Möglichkeit hat, die Entwicklung zu beeinflussen. Die Entwicklung des Prototypen besteht aus den Hauptschritten Auswahl, Implementierung und Bewertung. Für den Prototyping-Ansatz gibt es verschiedene Methoden, welche sich nach ihren Zielsetzungen unterscheiden lassen:

Beim explorativen Prototyping sollen noch unbekannte Anwendungen oder Eigenschaften ermittelt werden. Für bekannte Zielsetzungen und Anforderungen sollen beim experimentellen Prototyping Lösungsmöglichkeiten untersucht, bewertet und verglichen werden. Beim evolutionären Prototyping wird ein Prototyp des Systems erstellt, der dann schrittweise bis zum fertigen System weiterentwickelt wird.

Neben der oben genannten Lösung der Probleme des Phasenmodells, gelten als weitere Vorteile eine erhöhte Benutzerakzeptanz und frühzeitige Benutzerausbildung wegen der Beteiligung an der Entwicklung und einem frühen Lernprozeß bei den Entwicklern. Allerdings können auch Schwierigkeiten auftreten, wie z. B. eine Ablenkung von der eigentlichen Produktentwicklung, wobei sich unter Umständen die Verantwortlichen bereits mit dem Prototyp zufriedengeben und das eigentliche Produkt überhaupt nicht entwickeln. (vgl. [HFM92], S. 65 - 67) Außerdem entsteht ein hoher Kommunikations- und Abstimmungsaufwand, da die Systementwickler, Programmierer und Programmtester ständig neue Prototypen entwickeln und sich über diese beraten müssen. (vgl. [BuF97], S. 15)

2.1.2.2.2 Evolutionäre Entwicklung

Die evolutionäre Entwicklung baut auf dem Prototyping auf. Die zu erstellenden Teilsysteme des zu entwickelnden Softwaresystems werden bezüglich ihres Nutzen-/Kostenverhältnisses bewertet und die Teilsysteme mit den besten Werten zuerst implementiert. Dadurch sind die wichtigsten Funktionen früh verfügbar und die Erfahrungen mit diesen Teilsystemen können in den folgenden Teilsystemen berücksichtigt werden. Außerdem kann dadurch verhindert werden, daß unnötige Teilsysteme entwickelt werden. Allerdings besteht bei einem fehlenden Gesamtkonzept die Gefahr, daß ein nicht homogenes System entwickelt wird und die Struktur des Softwaresystems nicht konsistent bleibt. Außerdem können spätere Teilsysteme eingeschränkt werden.(vgl. [Chr92], S. 166)

2.1.2.2.3 Spiralmodell

Beim Spiralmodell steht der Risikoaspekt im Vordergrund, weswegen es besonders für unsichere Projekte sinnvoll ist. Im Phasenmodell wird nämlich davon ausgegangen, daß die späteren Phasen realisierbar sind. Das Spiralmodell ist in vier Quadranten aufgeteilt. Im ersten Quadranten werden Anforderungen, Alternativen und Einschränkungen identifiziert. Im zweiten Quadranten sollen die Alternativen bewertet, Risiken identifiziert und durch die Entwicklung von Prototypen aufgelöst werden. Im dritten Quadranten wird das System entwickelt und im vierten Quadranten wird die nächste Phase geplant. Diese vier Quadranten des Spiralmodells werden so oft durchlaufen, bis die Risiken behoben sind und das Produkt endgültig fertiggestellt werden kann. Die Ausdehnung der Spirale soll den geleisteten Gesamtaufwand darstellen. (vgl. [Chr92], S. 169 + 170)

2.1.2.2.4 objektorientierte Softwareentwicklung

Die objektorientierte Programmierung soll den Entwurfs- und Implementierungsprozeß verbessern, weswegen sich diese Phasen bei der objektorientierten Softwareentwicklung von den Phasen der prozeduralen Softwareentwicklung unterscheiden. Dagegen bleiben die Phasen Problemanalyse, Planung und Systemspezifikation (Anforderungsdefinition) unverändert. Die Besonderheit bei der objektorientierten Programmierung liegt darin, daß bei der Implementierung bereits existierende Komponenten zusammengefügt werden und beim Entwurf späterer Komponenten berücksichtigt werden müssen. Dadurch ist eine strikte Trennung der Phasen System-, Komponentenentwurf, Implementierung und Komponententest bei der objektorientierten Softwareentwicklung unmöglich und es liegen schon sehr früh Teilergebnisse vor. Eine weitere Besonderheit der objektorientierten Programmierung liegt darin, daß in einer projektübergreifenden Klassenbibliothek wiederverwendbare Klassen archiviert und in Folgeprojekten wiederverwendet werden können. Daraus ergeben sich Unterschiede für die objektorientierte Softwareentwicklung gegenüber der prozeduralen Softwareentwicklung bezüglich der Wartung. Dem Vorteil der Wiederverwendbarkeit der Klassen und der dadurch erlangten Produktivitätssteigerung in Folgeprojekten steht allerdings der Nachteil gegenüber, daß beim Anlegen und Warten der Klassenbibliothek zusätzlicher Aufwand entsteht.(vgl. [PoB96], S. 28 - 31)

2.2 Informationssysteme

2.2.1 Allgemein

Unter einem Informationssystem kann man ein System verstehen "...das Informationen verarbeitet, d.h. erfaßt, überträgt, transformiert, speichert und bereitstellt."([FeS98], S. 1) Dies kann beispielsweise ein Mensch sein. Allerdings können noch viele andere Sachen Informationsysteme darstellen. Im Rahmen dieser Arbeit interessieren besonders betriebliche, rechnergestützte Informationssysteme. Betriebliche, rechnergestützte Informationssysteme sind definiert als "... ein Werkzeug zur Erfassung und Kommunikation von Information zum Zwecke der Erfüllung der Anforderungen seiner Benutzer, der (Geschäfts-) Aktivitäten ihres Unternehmens und zur Erreichung der Unternehmensziele." ([Vos94], S. 31) Im folgenden sollen bei Verwendung des Begriffs Informationssysteme diese betrieblichen, rechnergestützte Informationssysteme gemeint sein. Es bestehen verschiedene Arten solcher Informationssysteme. Als Beispiele seien hier genannt Datenbanksysteme, Management-Informationssysteme, Decision on Support-Systeme, Information Retrieval-Systeme und Dokumentationssysteme. Das Informationssystem unterstützt die Unternehmensaktivitäten indem es Informationen bereitstellt oder Vorgänge automatisiert, die mit diesen Unternehmensaktivitäten in Verbindung stehen. Eine Unternehmensaktivität kann beispielsweise die Lenkung eines Betriebs sein. Dabei können z.B. Bilanzdaten bereitgestellt werden, die automatisch durch die Eingabe der einzelnen Belege erstellt werden. Das Informationssystem besteht aus den im Unternehmen vorhandenen Ressourcen die der Unterstützung der Unternehmensaktivitäten dienen, d.h. den Daten, der DBMS-Software, der nötigen Rechner-Hardware, den Personen, welche die Daten benutzen und verwalten, der relevanten Anwendungs-Software sowie der Programmierer, die diese entwickeln. Dies entspricht einer Auffassung von Informationssystemen im weiten Sinne.(vgl.[FeS98] und [Vos94])

Neben verschiedenen Arten von Informationssystemen kann man auch ihre Informationsbenutzer unterscheiden: Professionelle Benutzer erhalten eine spezielle Ausbildung, arbeiten viel mit dem Informationssystem und können umfangreiche Aufgaben ausführen. Ein Informationssystem muß für sie effizient bedienbar sein und schnelle Ergebnisse liefern. Gelegentliche Benutzer verfügen über keine spezielle Ausbildung, sondern müssen über den Bildschirm angeleitet werden und können nur verhältnismäßig einfache Aufgaben ausführen. Für sie muß ein Informationssystem einfach zu bedienen sein. Professionelle und gelegentliche Benutzer benötigen spezielle Anwenderprogramme, die ihre Arbeit gezielt unterstützen und über eine Benutzeroberfläche verfügen, die ihren Fähigkeiten entspricht. Systemspezialisten arbeiten an einem Informationssystem direkt mit freien Abfragen, wozu sie eine Datenmanipulationssprache verwenden.(vgl. [Zeh98], S. 18 - 22)

2.2.2 Modellierungsarten

Bei der Modellierung von Informationssystemen kann man grob vier Arten unterscheiden, bei denen verschiedene Elemente im Vordergrund stehen. Meist wird nicht nur eine sondern mehrere Modellierungsarten eingesetzt, da diese sich gegenseitig ergänzen und dadurch eine bessere Übersicht über das System und die Elemente erreicht wird. Die vier Modellierungsarten sollen nun kurz erläutert werden.

Bei der funktionsorientierten Modellierung stehen die Funktionen, die ein System erfüllen soll, im Vordergrund. Es werden die Funktionen jeweils verfeinert und auch Anwendungsdaten modelliert. Diese Modellierungssichten wurden im Datenfluß zusammengefaßt. Die ereignisorientierte Modellierung stellt Ereignisse, die von außen auf das System einwirken und die Reaktionen des Systems auf diese dar. Für Informationssysteme besonders wichtig ist die datenorientierte Modellierung, da die Manipulation von Daten das zentrale Bearbeitungselement darstellt. Es wird hierbei die Datenstruktur abgebildet. Die methodischen Grundlagen kommen bei der Datenmodellierung aus dem Datenbankentwurf. Bei der objektorientierten Modellierung bilden die Funktionen mit den Daten eine Einheit. Außerdem unterstützt es das Konzept der Kapselung, Informationhiding, Abstraktion, Klassifizierung, Vererbung und Polymorphismus.(vgl. [BuF97], 16 - 19)

2.3 WWW-Informationssysteme

Wegen der Begriffsvielfalt für verschiedene Komponenten des WWW soll hier zuerst eine Begriffsabgrenzung vorgenommen werden. Die Bezeichnungen World Wide Web, WWW, Web und W3 sind gleichbedeutend und stehen für den Hypermedia-Dienst des Internets. Das World Wide Web stellt ein Netz (engl. = Web) dar, dessen Knoten die einzelnen WebSites und die Kanten die Verbindungen zwischen diesen Knoten darstellen. WebSites werden oft nur kurz Site genannt und es gibt verschiedene Schreibweisen, z.B. Website oder Web-Site. Die WebSite hat eine eigene Adresse im WWW und besteht aus einzelnen WebPages. Diese stellen die einzelnen Seiten, die man im WWW auf dem Bildschirm sieht, dar. Dabei können z.B. unter Verwendung von Frames mehrere WebPages gleichzeitig auf dem Bildschirm angezeigt werden. Frames teilen den Bildschirm in verschiedene Bereiche auf, in denen jeweils eine WebPage angezeigt werden kann. WWW-Informationssysteme, auch als Web-Informationssysteme bezeichnet und im folgenden als WIS abgekürzt, stellen die Zusammenfassung der WebSite und der mit ihr verbundenen Komponenten dar. In Anlehnung an die Beschreibung betrieblicher, rechnergestützter Informationssysteme werden als Komponenten verstanden die Inhalte, der Server bestehend aus Hard- und Software, die Datenbank, den Personen, welche die Daten benutzen und verwalten, der relevanten Anwendungs-Software sowie der Programmierer, die diese entwickeln. Daraus folgt, daß es sich bei WIS um Informationssysteme handelt, welche mit dem WWW verbunden sind. Das WIS stellt ein offenes Informationsangebot dar. Bei seiner Entwicklung, speziell der Benutzeroberfläche, muß berücksichtigt werden, daß bei offenen Informationsangeboten alle Benutzergruppen zugreifen können. Allerdings wird mit zunehmender Verbreitung und Akzeptanz des Internets die Gruppe der gelegentlichen Benutzer gegenüber der Gruppe der professionellen Benutzer abnehmen.

Die Vorteile von WWW-Informationssystemen gegenüber betrieblichen Informationssystemen und Kundeninformationssystemen liegen im WWW selbst, in welchem jeder jederzeit, unabhängig von Ort und Plattform, auf die Informationen über eine einheitliche Benutzeroberfläche zugreifen kann. Voraussetzung für den Zugriff ist nur, daß man einen Zugang zum Internet hat und über die notwendige Zugangssoftware, einen sogenannten Browser, verfügt. Durch den leichten Zugang zum WWW, seine Einsatzmöglichkeiten und dem immer größer werdenden Markt des WWW entstehen z.B. neue Möglichkeiten für den Kundenservice und -support, für die direkte und interaktive Kommunikation mit Kunden und Lieferanten und für die Vertriebsabteilung eines Unternehmens ein zusätzlicher globaler und preiswerter Vertriebskanal (vgl. [Sch97], S. 3). Die Internet-Standards gelten für die bekanntesten Betriebssysteme, wodurch ermöglicht wird, diese verschiedenen Betriebssysteme miteinander zu verbinden. Deswegen sind WWW-Informationssysteme leicht erweiterbar und aktualisierbar, es besteht die Möglichkeit Intranets anzubinden und sowohl der innerbetriebliche als auch der Informationsaustausch mit Geschäftspartnern wird durch die standardisierten Protokolle erleichtert. Intranets stellen lokale Netzwerke dar, welche die Internetprotokolle als Netzwerkprotokolle verwenden und daher leicht an das Internet angebunden werden können. Aufgrund der Multimediafähigkeit des WWW können viele verschiedene Ressourcen, wie z. B. Dokumente, Sound, Bilder, Videos, Datenbanken usw., über eine universelle Schnittstelle zur Verfügung gestellt werden. Auch können über diese universelle Schnittstelle verteilte Systeme als ein System transparent präsentiert werden. Dazu wird eine Startseite, die sogenannte Homepage, erstellt, welche die einzige Schnittstelle zwischen dem WWW und dem verteilten System darstellen soll. Dadurch präsentiert sich das verteilte System dem Benutzer nur als ein System. Die einzelnen Komponenten des verteilten Systems können nun mit dieser Startseite verbunden werden, wodurch der Benutzer auf das gesamte System zugreifen kann.(vgl. [Bic97], S. vii - ix)

[...]