Generisches Entwickeln mittels PHP und MySQL am Beispiel einer Backoffice-Datenbank
©2003
Diplomarbeit
92 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Meine Diplomarbeit stellt einen generischen Ansatz dar, mit dem für auf Datenbanken basierende Software Eingabemasken, Suchmasken etc. generiert werden können, sodass etwaige Änderungen an der Datenbank keine Auswirkungen auf die Scripts haben. Da die Entwicklung dieses Ansatzes mit einem Auftrag aus der Wirtschaft verbunden war und somit als eigenständiges IT-Projekt angesehen werden kann, wird in der Arbeit auch der allgemeine Ablauf eines solchen Projektes vorgestellt, Vorgehensmodelle diskutiert und die eigene Vorgehensweise ausführlich begründet.
Darüber hinaus gibt ein Kapitel über generische Modelle einen Überblick, welche Lösungen moderne Programmiersprachen wie Java oder C++ für generische Programmierung bereitstellen.
Inhaltsverzeichnis:Inhaltsverzeichnis:
1.PERSÖNLICHE MOTIVATION UND ZIELSETZUNG4
2.DER AUFTRAG5
2.ADIE FIRMA5
2.BSYSTEMSPEZIFIKATION6
2.b.iZiel des Projektes6
2.b.iiEntwicklungsumgebung6
2.b.iiiLeistungsumfang6
2.b.ivLixto6
2.b.vSystemarchitektur7
2.b.viBackoffice7
2.b.viiWebshop*10
3.VORGEHENSMODELLE BEI PROJEKTEN11
3.ABUILD-AND-FIX ZYKLUS11
3.BDER SOFTWARE-LIFE-CYCLE12
3.CDAS WASSERFALLMODELL13
3.DDAS V-MODELL14
3.EDAS SPIRALMODELL16
3.FDAS INKREMENTELLE MODELL17
3.GEXTREME PROGRAMMING20
3.HPROJEKT WEBSHOP22
4.ANALYSE23
4.AANFORDERUNGSANALYSE23
4.BANALYSEMODELL26
5.MODELLIERUNGSKONZEPTE KONZEPTIONELLER DATENMODELLE30
5.AKLASSIFIKATION31
5.BAGGREGATION32
5.CVERALLGEMEINERUNG (GENERALISIERUNG)33
6.ENTWURF34
6.ASYSTEM35
6.BUSER INTERFACE38
6.b.iWebshop39
6.b.iiBackoffice41
6.CEER44
7.GENERISCHE MODELLE53
7.AGENERISCHE DATENTYPEN54
7.BEIN VERGLEICH DER GENERISCHEN PROGRAMMIERUNG MIT JAVA UND C++55
7.CBEISPIEL: FORMULARE MIT PHP GENERISCH AUSWERTEN56
7.DAKTUELLE FORSCHUNGEN58
8.IMPLEMENTIERUNG61
8.ASUCHMASKE65
8.a.iSearch.php65
8.a.iiShowdatabase.php66
8.BEDITIEREN DER ENTITIES68
8.b.iMask.php69
8.b.iiEingabeüberprüfung71
8.CEDITIEREN DER RELATIONEN76
8.DLAGERHALTUNG79
9.TEST82
9.ATESTPLANUNG UND VORBEREITUNG82
9.BTESTMETHODEN84
10.INBETRIEBNAHME UND WARTUNG86
11.ZUSAMMENFASSUNG87
12.LITERATURVERZEICHNIS88
Meine Diplomarbeit stellt einen generischen Ansatz dar, mit dem für auf Datenbanken basierende Software Eingabemasken, Suchmasken etc. generiert werden können, sodass etwaige Änderungen an der Datenbank keine Auswirkungen auf die Scripts haben. Da die Entwicklung dieses Ansatzes mit einem Auftrag aus der Wirtschaft verbunden war und somit als eigenständiges IT-Projekt angesehen werden kann, wird in der Arbeit auch der allgemeine Ablauf eines solchen Projektes vorgestellt, Vorgehensmodelle diskutiert und die eigene Vorgehensweise ausführlich begründet.
Darüber hinaus gibt ein Kapitel über generische Modelle einen Überblick, welche Lösungen moderne Programmiersprachen wie Java oder C++ für generische Programmierung bereitstellen.
Inhaltsverzeichnis:Inhaltsverzeichnis:
1.PERSÖNLICHE MOTIVATION UND ZIELSETZUNG4
2.DER AUFTRAG5
2.ADIE FIRMA5
2.BSYSTEMSPEZIFIKATION6
2.b.iZiel des Projektes6
2.b.iiEntwicklungsumgebung6
2.b.iiiLeistungsumfang6
2.b.ivLixto6
2.b.vSystemarchitektur7
2.b.viBackoffice7
2.b.viiWebshop*10
3.VORGEHENSMODELLE BEI PROJEKTEN11
3.ABUILD-AND-FIX ZYKLUS11
3.BDER SOFTWARE-LIFE-CYCLE12
3.CDAS WASSERFALLMODELL13
3.DDAS V-MODELL14
3.EDAS SPIRALMODELL16
3.FDAS INKREMENTELLE MODELL17
3.GEXTREME PROGRAMMING20
3.HPROJEKT WEBSHOP22
4.ANALYSE23
4.AANFORDERUNGSANALYSE23
4.BANALYSEMODELL26
5.MODELLIERUNGSKONZEPTE KONZEPTIONELLER DATENMODELLE30
5.AKLASSIFIKATION31
5.BAGGREGATION32
5.CVERALLGEMEINERUNG (GENERALISIERUNG)33
6.ENTWURF34
6.ASYSTEM35
6.BUSER INTERFACE38
6.b.iWebshop39
6.b.iiBackoffice41
6.CEER44
7.GENERISCHE MODELLE53
7.AGENERISCHE DATENTYPEN54
7.BEIN VERGLEICH DER GENERISCHEN PROGRAMMIERUNG MIT JAVA UND C++55
7.CBEISPIEL: FORMULARE MIT PHP GENERISCH AUSWERTEN56
7.DAKTUELLE FORSCHUNGEN58
8.IMPLEMENTIERUNG61
8.ASUCHMASKE65
8.a.iSearch.php65
8.a.iiShowdatabase.php66
8.BEDITIEREN DER ENTITIES68
8.b.iMask.php69
8.b.iiEingabeüberprüfung71
8.CEDITIEREN DER RELATIONEN76
8.DLAGERHALTUNG79
9.TEST82
9.ATESTPLANUNG UND VORBEREITUNG82
9.BTESTMETHODEN84
10.INBETRIEBNAHME UND WARTUNG86
11.ZUSAMMENFASSUNG87
12.LITERATURVERZEICHNIS88
Leseprobe
Inhaltsverzeichnis
ID 7245
Christian Gruber
Generisches Entwickeln
mittels PHP und MySQL am
Beispiel einer Backoffice-
Datenbank
Diplomarbeit
Technische Universität Wien
Fachbereich Technische Naturwissenschaften und Informatik
Abgabe Juni 2003
ID 7245
Gruber, Christian: Generisches Entwickeln mittels PHP und MySQL am Beispiel einer
Backoffice-Datenbank
Hamburg: Diplomica GmbH, 2003
Zugl.: Technische Universität Wien, Technische Universität, Diplomarbeit, 2003
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
2
INHALTSVERZEICHNIS
1. PERSÖNLICHE MOTIVATION UND ZIELSETZUNG
... 4
2. DER AUFTRAG
... 5
2.
A
D
IE
F
IRMA
... 5
2.
B
S
YSTEMSPEZIFIKATION
... 6
2.b.i Ziel des Projektes
... 6
2.b.ii Entwicklungsumgebung
... 6
2.b.iii Leistungsumfang
... 6
2.b.iv Lixto
... 6
2.b.v Systemarchitektur
... 7
2.b.vi Backoffice
... 7
2.b.vii Webshop*
... 10
3. VORGEHENSMODELLE BEI PROJEKTEN
... 11
3.
A
B
UILD
-
AND
-F
IX
Z
YKLUS
... 11
3.
B
D
ER
S
OFTWARE
-L
IFE
-C
YCLE
... 12
3.
C
D
AS
W
ASSERFALLMODELL
... 13
3.
D
D
AS
V-M
ODELL
... 14
3.
E
D
AS
S
PIRALMODELL
... 16
3.
F
D
AS INKREMENTELLE
M
ODELL
... 17
3.
G
E
XTREME
P
ROGRAMMING
... 20
3.
H
P
ROJEKT
W
EBSHOP
... 22
4. ANALYSE
... 23
4.
A
A
NFORDERUNGSANALYSE
... 23
4.
B
A
NALYSEMODELL
... 26
5. MODELLIERUNGSKONZEPTE KONZEPTIONELLER DATENMODELLE
... 30
5.
A
K
LASSIFIKATION
... 31
5.
B
A
GGREGATION
... 32
5.
C
V
ERALLGEMEINERUNG
(G
ENERALISIERUNG
)
... 33
6. ENTWURF
... 34
6.
A
S
YSTEM
... 35
6.
B
U
SER
I
NTERFACE
... 38
6.b.i Webshop
... 39
6.b.ii Backoffice
... 41
6.
C
EER
... 44
7. GENERISCHE MODELLE
... 53
7.
A
G
ENERISCHE
D
ATENTYPEN
... 54
7.
B
E
IN
V
ERGLEICH DER GENERISCHEN
P
ROGRAMMIERUNG MIT
J
AVA UND
C++
... 55
7.
C
B
EISPIEL
: F
ORMULARE MIT PHP GENERISCH AUSWERTEN
... 56
7.
D
A
KTUELLE
F
ORSCHUNGEN
... 58
8. IMPLEMENTIERUNG
... 61
3
8.
A
S
UCHMASKE
... 65
8.a.i Search.php:
... 65
8.a.ii Showdatabase.php
... 66
8.
B
E
DITIEREN DER
E
NTITIES
... 68
8.b.i Mask.php
... 69
8.b.ii Eingabeüberprüfung
... 71
8.
C
E
DITIEREN DER
R
ELATIONEN
... 76
8.
D
L
AGERHALTUNG
... 79
9. TEST
... 82
9.
A
T
ESTPLANUNG UND
V
ORBEREITUNG
... 82
9.
B
T
ESTMETHODEN
... 84
10. INBETRIEBNAHME UND WARTUNG
... 86
11. ZUSAMMENFASSUNG
... 87
12. LITERATURVERZEICHNIS
... 88
4
1. Persönliche Motivation und Zielsetzung
Das Studium der Wirtschaftsinformatik ist über weite Strecken
ein theoretisches. Natürlich ist mir die Sinnhaftigkeit dieser
Tatsache durchaus bewusst, dennoch war für mich bei der Auswahl
des Themas für meine Diplomarbeit die praktische Anwendung des
Erlernten eine wichtige Voraussetzung, um so im universitären
Rahmen Erfahrung für das Berufsleben sammeln zu können.
Als mich daher Dipl. Ing. Martin Summerer ansprach, ein
konkretes Projekt durchzuführen, war ich sogleich mit Feuer und
Flamme dabei. Das Entwickeln von Datenbanksystemen bzw. die
Forschung über generische Abläufe bei der Programmierung war
zusätzlich noch ein Aspekt, der mich immer schon gereizt hat.
Ziel des Projektes war es, zu erörtern, inwieweit generische
Programmierung bei einer Datenbank sinnvoll ist bzw. wo deren
Grenzen liegen.
Diese Arbeit soll die Vorteile, aber auch die Problemfelder von
generischem Programmieren aufzeigen und damit einen Beitrag zum
besseren Verständnis der Materie liefern, die heutzutage immer
wichtiger wird. Darüber hinaus werden anhand des praktischen
Beispiels die verschiedenen Möglichkeiten und Vorgehensweisen
bei der modernen Softwareentwicklung illustriert.
5
2. Der Auftrag
2.a Die Firma
Die im Jahr 1999 gegründete Impact Business Solutions mit Sitz
in Wien hat sich auf folgende Themen spezialisiert:
·
Implementierung und Optimierung von SAP LES-Lösungen
(Logistic Execution System)
·
Lager- und Distributionslogistik
·
Produktionsplanungslösungen
·
Capable to Promise (Echtzeit-Lieferterminermittlung
während Kundenauftragserfassung bei Kundeneinzelfertigung)
Neben der betriebswirtschaftlichen und technischen Beratung
bietet das Unternehmen auch
·
Beratung im Logistikbereich und
·
kundenspezifische Zusatzentwicklungen in R/3 an.
Ein weiterer Schwerpunkt von Impact Business Solutions liegt in
der Beratung zur Einführung von ERP-Systemen in
Mittelbetrieben. ERP steht dabei für Enterprise Resource
Planning und ist der zusammenfassende Begriff für die Planung,
Realisierung und Analyse aller Geschäftsprozesse eines
Unternehmens. Die Anforderungen an ein IT-Consultingunternehmen
für kleine und mittelständische Unternehmen sind deutlich höher
als die eines vergleichbaren Anbieters für Großunternehmen.
Dies hängt damit zusammen, dass Großunternehmen selbst über
eigene qualifizierte Mitarbeiter verfügen, die in der Lage
sind, Aufgaben zu übernehmen, für die jedoch bei kleinen und
mittleren Unternehmen keine Kapazitäten vorhanden sind. Um den
besonderen Anforderungen eines kleinen oder mittleren
Unternehmens gerecht zu werden, sind vorgefertigte SAP-Systeme
mit branchenspezifischen Abbildungen von Prozessen notwendig,
um zu einem definierten Aufwand und Zeitpunkt die Einführung
der Software zu ermöglichen.
6
2.b Systemspezifikation
2.b.i Ziel des Projektes
Das Grundziel des Projektes ist es, vorzugsweise kleinen oder
auch mittleren Betrieben eine günstige Möglichkeit zu bieten,
die Abwicklung eines Großteils ihrer Geschäftsprozesse
durchzuführen sowie einen integrierten Webshop bereitzustellen.
Dabei ist großes Augenmerk darauf zu legen, dass der
Verwaltungsaufwand für den Benutzer so gering wie möglich
gehalten wird und doppelte Verwaltung von Daten und unnötige
Schnittstellen vermieden werden (z.B. Doppelter Artikelstamm
für das Backoffice und für den Webshop).
2.b.ii Entwicklungsumgebung
Die Entwicklungsumgebung wird nicht direkt vorgegeben, soll
aber unabhängig vom Betriebssystem und, aus Kostengründen für
den Endbenutzer, auch unter Linux lauffähig sein.
2.b.iii Leistungsumfang
Das Paket soll modular und objektorientiert aufgebaut sein
sodass Anwendungsbereiche unabhängig voneinander lauffähig
sind. Zu den Anwendungsbereichen zählen in erster Linie
Verwaltung von Artikelstamm, Lager und Kunden sowie
Auftragsabwicklung und Fakturierung, sowie eine integrierte
Angebotslegung über das WWW (Webshop). Bei der Implementierung
des Webshops sollen moderne Technologien (Lixto) zum Content-
Management der im Web angebotenen Artikel untersucht und
verwendet werden (siehe 2.b.iv). Im Konzept soll stets bedacht
werden, dass weitere Komponenten wie Mahnwesen, Buchhaltung,
Lieferantenmanagement etc. einfach angebunden werden können.
2.b.iv Lixto
,,Lixto Produkte ermöglichen die kosteneffektive und
zuverlässige Navigation zu sowie Extraktion von strukturierten
Daten aus Webseiten und Informationsportalen. Die von Lixto
7
erzeugten XML Daten können leicht in existierende Anwendungen
integriert werden." [Lixto03]
Mit diesen Worten wird Lixto auf der firmeneigenen Homepage
beschrieben. Tatsächlich eignet sich Lixto hervorragend, um den
Aufwand für Content Management auf einem Minimum zu halten.
Mittels einer grafischen Oberfläche hat der Benutzer die
Möglichkeit, ein Wrapper-Programm zu generieren, das aus
anderen browserbasierten Plattformen Informationen
herausfiltert und in einer XML-Datei abspeichert. Die Wrapper
sind so eingerichtet, dass sie in regelmäßigen Abständen die
Inhalte neu filtern und so die Information immer auf dem
aktuellsten Stand halten.
So können beispielsweise bei einem Webshop zu jedem angebotenen
Artikel weitere Informationsquellen bzw. Beschreibungen oder
Kommentare zu selbigem aufgelistet sein.
2.b.v Systemarchitektur
Im Rahmen der Diplomarbeit soll geklärt werden, welche
Systemarchitekturen für das Vorhaben die geeignetste ist.
·
Komplette Datenbank beim Provider
·
Webshop-relevante Daten beim Provider, Backoffice
Verwaltung lokal
·
2 unabhängige Datenbanken mit normierter Schnittstelle
2.b.vi Backoffice
Im Backoffice hat der Administrator die Möglichkeit, die Daten
für den Webshop zu verwalten, Fakturen zu stellen und Lagerein-
bzw. Ausgänge einzugeben.
Dieser Bereich ist demnach nicht für den Endkunden gedacht,
sondern für den Webshopbetreiber. Wenn in Zusammenhang mit dem
Backoffice von Kunden die Rede ist, ist immer der Endkunde
gemeint, der den Webshop besuchen und dort Einkäufe tätigen
kann. Der Administrator hingegen ist der User des Systems, der
den Webshop betreibt.
8
Folgende Fixpunkte sollen in das System integriert werden, bei
den mit * gekennzeichneten Systemteilen ist die Implementierung
vorerst nicht erforderlich:
Artikelstamm:
Es gibt sowohl Einzelartikel als auch Setartikel. Setartikel
bestehen aus Einzelartikeln und können ihrerseits wieder Teil
eines Setartikels sein. Die Artikel müssen auch Artikelgruppen
zuordenbar sein.
Einkaufspreis:
Zum Nettoeinkaufspreis eines Einzelartikels können Rabatte und
Zuschläge des Anbieters gespeichert werden. Der Einkaufspreis
eines Setartikels ergibt sich immer aus den
Bruttoeinkaufspreisen der enthaltenen Einzelartikel.
Verkaufspreis:
Jeder Einzelartikel hat einen Nettoverkaufspreis. Der
Nettoverkaufspreis eines Setartikels wird entweder aus der
Summe der Nettoverkaufspreise der enthaltenen Einzelartikel
bestimmt, oder ist ein eigens eingegebener Nettowert.
Montagestunden*:
Zu jedem Artikel sollen auch Montagestunden hinterlegt werden
können, die sich in der Handhabung analog zu dem Verkaufspreis
verhalten.
Kundenverwaltung:
In der Kundenverwaltung werden sämtliche Kundendaten und
darüber hinaus Zuordnungen zu definierbaren Kundengruppen
(Endkunden, Wiederverkäufer, ...) gespeichert.
Weiters muss man die Möglichkeit haben, für Kunden spezifische
Artikel Verkaufspreise zu speichern. Dasselbe gilt sinngemäß
für Kundengruppen. Falls der spezifische Verkaufspreis eines
Kunden ungleich dem spezifischen Verkaufspreis der ihm
zugeordneten Kundengruppe ist, gilt der kundenspezifische
Preis.
9
Lagerverwaltung:
Bei der Lagerverwaltung werden Artikelein- und Ausgänge
gespeichert.
Weiters soll eine Bestandsliste geführt werden, bei der jedoch
nur Einzelartikel berücksichtigt werden. Bei Ausgang eines
Setartikels werden alle zum Setartikel gehörigen Einzelartikel
von der Bestandsliste abgezogen.
Auftragsabwicklung und Fakturierung:
Die Auftragsabwicklung soll sowohl aus dem Webshop heraus als
auch aus dem Backoffice (Mail, telefonische Bestellung)
erfolgen können. Es sollen sowohl direkte Aufträge als auch
Angebots- bzw. Preisanfragen an das System möglich sein.
Aufträge:
Aufträge bestehen aus Artikeln und Mengenangaben. Abhängig vom
Kunden bzw. seiner Kundengruppe werden Verkaufspreise
errechnet. Weiters müssen dem Kunden Lieferangebote gemacht
werden können, die aus dem Backoffice administrierbar sein
sollen. Abhängig von Artikeln und Mengenangaben sollen abhängig
von Auftragsvolumen Lieferkosten berechnet werden können.
Angebots bzw. Preisanfragen*:
Angebots bzw. Preisanfragen sind unverbindliche Anfragen des
Kunden. Auf Kunden bzw. Kundengruppen-Ebene soll festgelegt
werden, welche Kunden bzw. Kundengruppen zu Angebots bzw.
Preisanfragen berechtigt sind. Preisanfragen sollen im
Backoffice bearbeitet werden können. Dabei sollen sowohl Mengen
als auch Preisrabatte angewandt werden können und das fertige
individuelle Angebot soll per Mail an den Kunden
zurückgeschickt werden können.
Fakturierung:
Zu jedem Auftrag soll es möglich sein, eine Faktura zu drucken
und in der Datenbank abzulegen. Wünschenswert ist auch eine
Möglichkeit des Versands der Faktura auf elektronischem Weg.
10
2.b.vii Webshop*
Kundenindividuelle Shops*:
Der Endkunde soll die Möglichkeit haben, sich einzuloggen und
sich Kunden-spezifische Daten anzeigen lassen zu können. Er
kann diese Option aber auch ungenutzt lassen und vollen Zugriff
auf alle Webshop-Daten haben.
Artikelangebot*:
Das Artikelangebot soll direkt aus der Backofficedatenbank
gelesen werden. Bei einem Kundenlogin soll der spezifische
Preis des Kunden bzw. der Kundengruppe ausgewiesen werden.
Optional soll auch die Verfügbarkeit des Artikels geprüft
werden können oder die verfügbare Menge ausgewiesen werden.
Content Management*:
Die angezeigten Zusatzinformationen der Artikel sollen mittels
Lixto (siehe 2.b.iv) realisiert werden. Dabei soll untersucht
werden, welche Form der Einbindung der im Web gefundenen
artikelspezifischen Inhalte am zielführendsten ist direkte
Einbindung in Html oder Pufferung über eine Datenbank.
Warenkörbe*:
Jeder Kunde soll seinen eigenen Warenkorb zusammenstellen und
diesen dann als Kaufauftrag absenden können. Weiters sollen
auch Lieferangebote unterbreitet werden und deren Preise
unabhängig zu den bestellten Artikeln berechnet werden können
(analog Backoffice).
11
3. Vorgehensmodelle bei Projekten
Nach [Zus00] haben moderne Softwareentwicklungsprozesse
folgendes Erscheinungsbild:
·
Softwareprojekte werden immer umfangreicher.
·
Die Anforderungen an die Applikationen wachsen.
·
Unterschiedlichste Techniken müssen gleichzeitig
eingesetzt werden.
·
Investitionen in die entwickelte Software müssen geschützt
werden, d.h. die Software muss in angemessener Zeit und
mit kalkulierbaren Kosten wartbar und erweiterbar bleiben.
·
Das zur Wartung der Software nötige Know-how muss
langfristig und nicht personengebunden zur Verfügung
stehen. (Knowledge Management)
Um diesen Ansprüchen für unterschiedliche Projekttypen gerecht
zu werden, sind verschiedene Vorgehensmodelle für die
Durchführung eines Projektes notwendig.
Die Art und Weise, wie die Arbeitsschritte angeordnet und
durchlaufen werden, sowie die Definition von übergeordneten
Phasen sind in den einzelnen Modellen stark unterschiedlich.
In unterschiedlichen Software Entwicklungsprozessen, die den
inhaltlichen Vorgaben einer Methode folgen, unterscheidet sich
somit nur die Strategie, jedoch nicht der tägliche
Arbeitsprozess in Form der Arbeitsschritte und Tätigkeiten. Aus
diesem Grund ist es meist auch möglich, in einem Unternehmen je
nach Projekt mehrere verschiedene Vorgehensmodelle zu
verwenden, ohne dass sich für den einzelnen Entwickler in
seiner täglichen Arbeit etwas ändert.
3.a Build-and-Fix Zyklus
Dieses in [Zus00] beschriebene Vorgehen ist das einfachste
seine Art, welches jeder Programmierer schon einmal angewendet
hat.
Im Kopf eines Einzelnen entsteht eine Idee für eine bestimmte
Software. Er selbst implementiert dieses System entsprechend
der Vorstellungen in seinem Kopf. Die Arbeit an der Software
12
dauert genau so lange, bis diese den Qualitätsansprüchen seines
Programmierers genügt. Im Falle von auftretenden
Änderungswünschen werden diese vom Programmierer in das System
eingebracht.
Es existiert keinerlei Dokumentation, strukturiertes Vorgehen
oder eine Einteilung in Arbeitsschritte wie Analyse oder
Entwurf. Sämtliche notwendige Tätigkeiten werden vom
Programmierer selbst zum Zeitpunkt der Entwicklung der Software
durchgeführt. Auf diese Art und Weise entstandene Systeme
können durchaus von hoher Qualität sein, und manche nützliche
Anforderung umsetzen. Allerdings ist der Umfang im Normalfall
äußerst begrenzt, die Wartung kann ausschließlich vom
Programmierer selbst durchgeführt werden und auch der Einsatz
durch andere Personen ist meist nur bedingt möglich.
3.b Der Software-Life-Cycle
Die in den folgenden Kapiteln vorgestellten Vorgehensmodelle
basieren auf der grundlegenden Idee des Software-Life-Cycle
([Pomb93]), welcher ein strukturiertes Vorgehen bei der
Erstellung von Software vorsieht.
Während des Entwickelns eines Systems ist eine Durchführung
folgender Arbeitsschritte notwendig:
1. Anforderungen bestimmen
2. Analyse
3. Entwurf
4. Implementierung
5. Test und Inbetriebnahme/Wartung
Sollten sich die Anforderungen ändern, können diese erst im
Zuge eines neuen Projektes verwirklicht werde, welches wiederum
alle Arbeitsschritte in der vorgesehenen Reihenfolge
durchläuft.
Das größte Problem bei einem solchen starren Vorgehen stellt
die fehlende Möglichkeit dar, einen oder mehrere Schritte
zurück zu gehen, wenn bereits während der Durchführung eines
Projektes (auch im Zuge der Wartung) Änderungen einzelner
Systemteile notwendig werden sollten.
13
Abb.1 Phasen des Software-Life-Cycle-Prozesses [Zus00]
3.c Das Wasserfallmodell
Die fehlende Möglichkeit von ,,Schritten zurück" berücksichtigt,
zumindest teilweise, das Wasserfallmodell ([Royc98]). Dieses
sieht zwar auch eine Abfolge der Arbeitsschritte Anforderungen,
Analyse, Entwurf, Implementierung, Test und Betrieb vor, lässt
aber einen Rückwärtsschritt von einem Arbeitsschritt auf den
direkten Vorgänger zu. Es bleibt jedoch die Bedingung bestehen,
dass ein Arbeitsschritt erst dann abgeschlossen werden kann,
wenn alle vorgesehenen Produkte dafür fertiggestellt worden
sind. Dies soll zu einer Risikominimierung für den nächsten
Arbeitsschritt führen.
Das Wasserfallmodell ist ein stark verbreitetes
Vorgehensmodell, von dem zahlreiche Varianten beschrieben
worden sind. Es eignet sich gut für Projekte, in denen die
Arbeitsschritte deutlich voneinander getrennt werden können.
Dazu müssen alle Risiken bereits vor Projektbeginn ausreichend
untersucht werden können. Weiters lässt sich diese Art von
Projekt besonders bei kleinen Arbeitsgruppen gut durchführen,
da alle Mitarbeiter gleichzeitig an einem Arbeitsschritt
arbeiten können.
Bei großen Arbeitsgruppen ist es aufgrund der Anzahl und den
unterschiedlichen Qualifikationen unmöglich, alle
Gruppenmitglieder an einem Arbeitsschritt arbeiten zu lassen.
14
Für solche Projekte sollte ein iteratives Modell gewählt
werden.
Abb 2: Wasserfallmodell
3.d Das V-Modell
Das V-Modell (siehe z.B. [Bröh93] oder [Müll99]) gliedert den
Softwareentwicklungsprozess in sechs Phasen:
1. Anforderungsanalyse
2. Systementwurf
3. Entwurf und Implementierung der Module
4. Modultest
5. Systemintegration
6. Systemabnahme
Die letzten drei Phasen bilden die Tests für die Produkte der
ersten drei.
Der Modultest testet die Module, welche aus Entwurf und
Implementierung hervorgegangen sind und den höchsten
Detaillierungsgrad aller im Laufe der Softwareentwicklung
15
entstandenen Produkte aufweisen. Die Systemintegration
überprüft die Korrektheit des Systementwurfs. Die Systemabnahme
zeigt die Richtigkeit der anfangs erstellten Anforderungen.
Abb. 3 zeigt die einzelnen Phasen und ihre Zusammenhänge. Die
Produkte und ihre Tests entsprechen den verschiedenen Sichten
auf ein System. Aus der Anordnung dieser Sichten ergibt sich
das für dieses Modell namengebende ,,V".
Abb.3: Das V-Modell
Die Produkte der ersten drei Phasen zusammen mit den Tests,
welche diese überprüfen, werden als Modelle bezeichnet:
1. Anwendermodell: besteht aus Anforderungsanalyse,
Systemspezifikation und dem abgenommenen System
2. Architekturmodell: besteht aus technischer Spezifikation,
Teilsystem-Spezifikation, getestetem Teilsystem und
getestetem System.
Modulspezifikation
Getestete
Module
Modultest
Implemen-
tationssicht
Systementwurf
Getestetes
System
Integrationstest
Arichitektursicht
Akzeptanztest
Anwendersicht
Systemenspezifikation
Installiertes
System
System in
Verwendung
16
3. Implementierungsmodell: besteht aus Modul-Spezifikation
und getesteten Modulen.
Das V-Modell strukturiert den Softwareentwicklungsprozess
ähnlich dem Wasserfallmodell in einer Abfolge von Phasen. Als
wesentlichen Fortschritt betont es die Zusammengehörigkeit von
Produkten und diese überprüfenden Tests.
Jedoch ist es ebenso wie die obigen zwei Modelle sehr anfällig
für Fehler in frühen Phasen, welche bei später Entdeckung zu
einem beträchtlichem Aufwand für deren Korrektur führen können.
3.e Das Spiralmodell
Das Spiralmodell ist nach [Zus00] entwickelt worden, um den
möglichen Projektrisiken der beschriebenen Modelle entgegen zu
wirken. Der gesamte Prozess ist in vier Phasen gegliedert, die
im Zuge einer evolutionären Softwareentwicklung mehrmals
durchlaufen werden. In jedem Durchlauf werden demnach nur
bestimmte Produkte entwickelt, welche auf den Produkten des
vorhergehenden Durchlaufes aufbauen und die Grundlage für den
nächsten Durchlauf bilden. Die vier Phasen und deren wichtigste
Tätigkeiten sind:
·
Zielbestimmung: Jeder Durchlauf beginnt mit der Bestimmung
der genauen Ziele und Produkte desselben. Es werden auch
Alternativen (z.B. Entwurfsvarianten) und Restriktionen
(z.B. aufgrund des Zeitplanes) untersucht und
festgehalten.
·
Vergleich alternativer Lösungsmöglichkeiten: In der nun
folgenden Phase werden die Ziele und Alternativen unter
Berücksichtigung der Restriktionen bewertet und die darin
enthaltenen Risiken festgestellt. Für die gefundenen
Risiken werden Lösungsstrategien zur Beseitigung der
Ursachen dafür entwickelt (z.B. Erstellung eines
Prototypen, Simulation, Befragung der Benutzer usw.)
·
Entwicklung und Test: In dieser Phase werden die für
diesen Durchlauf vorgesehenen Produkte entwickelt.
Klarerweise können je nach Projekt und identifizierten
Risiken die Anzahl und Abfolge der Produkte in den
einzelnen Durchläufen stark variieren.
17
·
Planung des nächsten Zyklus: Basierend auf den Ergebnissen
einer Review, welche als Abschluss für jeden Durchlauf
vorgesehen ist, wird der nächste Zyklus geplant.
Abbildung 4 zeigt die Form des Spiralmodells mit vier
Durchläufen.
Abb.4 Das Spiralmodell nach Boehm
Die Systemerstellung selbst kann zum Beispiel durch ein
eingebettetes Wasserfall- oder V-Modell strukturiert werden,
womit ein Verbinden der verschiedenen Möglichkeiten erreicht
werden kann.
3.f Das inkrementelle Modell
Im Wasserfallmodell wie im V-Modell ist eine abgeschlossene
Analyse Voraussetzung für den Entwurf und die Implementierung.
Gibt es unklare Anforderungen oder sind die Anforderungen noch
nicht komplett, kann mit dem Entwurf nicht begonnen werden, bis
die letzte Anforderung restlos geklärt ist. Nach erfolgter
18
Implementierung bekommt der Kunde das fertige System als Ganzes
geliefert.
Bei großen Projekten hat dies zur Folge, dass die Auslieferung
des Produktes ein oder mehrere Jahre dauern kann. Der Kunde
muss lange Zeit warten, bis er sein System begutachten kann.
Noch dazu ist es bei Projekten in dieser Größe sehr leicht
möglich, dass sich Anforderungen aufgrund des langen Zeitraumes
ändern. Somit besteht das Risiko, dass das ausgelieferte
Produkt bereits nicht mehr den aktuellen Anforderungen
entspricht und eine sofortige Überarbeitung notwendig ist, oder
der Kunde mit den Einschränkungen auskommen muss.
Wie in [Zus00] beschrieben, versucht das inkrementelle Modell,
diese Probleme zu lösen. Anstatt auf die Fertigstellung der
gesamten Anforderungen zu warten, wird sobald eine
ausreichende Anzahl an Kernanforderungen beschrieben ist für
diese ein Entwurfs- und die Implementierungsphase gestartet. Je
mehr Anforderungen hinzukommen, desto mehr wird vom System
schrittweise gebaut.
Das inkrementelle Modell hat folgende Eigenschaften:
1. Das Software-Produkt wird stufenweise entwickelt. Die
Entwicklung wird durch die Erfahrungen der Entwickler und
des Kunden mit dem wachsenden Produkt gesteuert.
2. Die Wartung wird als Erstellung einer neuen Version des
bestehenden Produktes betrachtet.
3. Dieses Vorgehensmodell ist gut geeignet, wenn der Kunde
seine Anforderungen noch nicht vollständig überblickt,
bzw. sich über die Möglichkeiten zur Realisierung der
Anforderungen nicht bewusst ist und deshalb die
Anforderungen nicht formulieren kann.
4. Die Entwicklung wird hauptsächlich durch den Code
getrieben. Im Zentrum des Interesses stehen lauffähige
Systemteile.
Es ist mit diesem Modell möglich, Teile des Systems bereits vor
Fertigstellung des gesamten Systems beim Kunden einzuführen
(z.B. ein oder mehrere Subsysteme). Mit diesen Teilen kann der
Kunde eine eingeschränkte Anzahl an Anforderungen realisieren.
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2003
- ISBN (eBook)
- 9783832472450
- ISBN (Paperback)
- 9783838672458
- DOI
- 10.3239/9783832472450
- Dateigröße
- 1.1 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Technische Universität Wien – Technische Naturwissenschaften und Informatik
- Erscheinungsdatum
- 2003 (September)
- Note
- 1,0
- Schlagworte
- wirtschaftsinformatik modellierungskonzept systemspezifikation prospekt datenmodell
