Leseprobe
Inhaltsverzeichnis
Abkürzungsverzeichnis
Vorwort
Einleitung
1 Phasenmodell der Systementwicklung
1.1 Analysephase
1.2 Eigenentwicklung oder Standardsoftware?
1.3 Entwurfsphase bei Eigenproduktion
1.4 Entwurfsphase bei Standardsoftware
1.5 Realisierungsphase bei Eigenentwicklung
1.6 Realisierungsphase bei Standardsoftware
1.7 Einführungsphase
1.8 Kritik des Phasenmodells
2 Wasserfall- und V-Modell
Literaturverzeichnis (inklusive weiterführender Literatur)
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Vorwort
Die vorliegende Arbeit wurde zusammen von Christoffer Riemer und Jan Schwenke geschrieben. Zur Kennzeichnung der Autoren wird am Anfang jedes Abschnittes ein Namenskürzel eingefügt. Das Kürzel (CR) kennzeichnet die von Christoffer Riemer geschriebenen Abschnitte. Abschnitte, die mit dem Kürzel (JS) beginnen, wurden von Jan Schwenke verfasst.
Einleitung
(CR) „Allgemein beschreibt jedes Vorgehensmodell die Folge aller Aktivitäten, die zur Durchführung eines Projekts erforderlich sind. Vorgehensmodelle für die Systementwicklung […] geben an, wie die Prinzipien, Methoden, Verfahren und Werkzeuge der System- und Softwareentwicklung einzusetzen sind.“[1] Durch Vorgehensmodelle soll in der Softwareentwicklung die Komplexität beherrschbar und der Entwicklungsprozess übersichtlicher gestaltet werden. Dieser wird dabei in überschaubare, zeitlich und inhaltlich abgrenzbare Phasen unterteilt. Diese Phasen können einmal durchlaufen werden, wie beispielsweise beim Wasserfallmodell, oder mehrmals, wie es beim Spiralmodell der Fall ist. Man kann zwischen drei Typen von Vorgehensmodellen unterscheiden. Dies sind Softwareentwicklungsprozesse, Software-Lebenszyklusmanagement und Software-entwicklungs-Philosophie.[2]
Software-Entwicklungsprozesse sollen die Steuerung einer Softwareentwicklung von der Konzeption bis zum Einsatz ermöglichen. Beim Software-Lebenszyklusmanagement werden die Entwicklungsphasen über den gesamten Lebenszyklus erweitert. Softwareentwicklungs-Philosophien hingegen beschreiben, wie Software am Besten entwickelt werden sollte, beispielsweise extreme Programmierung[3] und Prototyping[4].
1 Phasenmodell der Systementwicklung
(CR) Für viele Vorgehensmodelle bildet das Phasenkonzept der Systemtechnik die Grundlage. Durch die Phaseneinteilung wird die Komplexität eines IT-Projektes reduziert, da es in überschaubare, zeitlich aufeinander folgende Teilaufgaben zerlegt wird. Durch das Vorgeben von Phasenzielen in Form von Meilensteinen können eventuelle Änderungen rechtzeitig eingearbeitet werden, Fehler erkannt und beseitigt oder das Projekt gar abgebrochen werden, wenn ein Erfolg unwahrscheinlich erscheint. Damit kann die Einhaltung von Vorgaben überprüft, der Entwicklungsaufwand überwacht und steuernde Maßnahmen eingeleitet werden. Für jede Phase muss festgelegt werden, was zu tun ist und wie es zu tun ist. Für eine sinnvolle Verantwortungsvergabe muss des Weiteren festgelegt werden wer etwas zu tun hat, wann etwas zu tun ist und welche Kosten dabei höchstens entstehen dürfen.[5]
Die vier Phasen Analyse, Entwurf, Realisierung und Einführung liegen fast allen Vorgehensmodellen zugrunde. In der Vorphase Projektbegründung werden zunächst der Projektauftrag und die Zielvorstellungen definiert.[6]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1 : Das Phasenmodell der Systementwicklung
Quelle: Eigene Darstellung in Anlehnung an Stahlknecht/Hasenkamp (2002), S. 221; Breitner (2006a), S.16.
1.1 Analysephase
(CR) Im ersten Schritt der Analysephase wird eine Ist-Analyse durchgeführt. Dabei wird der Ist-Zustand erhoben und beschrieben um vor allem Schwachstellen und unerwünschte Zustände analysieren und bewerten zu können. Zu Beginn der Analyse müssen die Erhebungstechniken bestimmt und die Darstellungsform der Ergebnisse festgelegt werden. Von besonderem Interesse sind hierbei ausgewählte Geschäftsprozesse und Arbeitsabläufe im Unternehmen. Um die benötigten Daten zu erhalten und darzustellen, können dabei die in Tab. 1 dargestellten Techniken eingesetzt werden.[7]
Abbildung in dieser Leseprobe nicht enthalten
Tab. 1: Erhebungs- und Darstellungstechniken
Quelle: Eigene Darstellung in Anlehnung an Stahlknecht/Hasenkamp (2002), S. 235 – 238.
Festgestellte Mängel sollen mit dem zu entwickelnden System behoben oder zumindest vermindert werden. Verbesserungsvorschläge sollten schon während der Ist-Analyse festgehalten werden. In der Regel wird die Ist-Analyse mit einem schriftlichen Bericht und einem Meilenstein für Entscheider abgeschlossen, an dem entschieden wird, ob die nächste Phase begonnen werden kann, Nachbesserungen nötig sind oder das Projekt gar abgebrochen wird.
Im zweiten Schritt der Analyse ist ein Soll-Konzept zu entwickeln. Hierfür werden Anforderungen und Ziele für das System formuliert. Es wird zuerst ein Fachentwurf erstellt, der beschreibt, was das Anwendungssystem leisten soll. Die hier beschriebenen funktionalen Anforderungen betreffen den Leistungsumfang des Systems und werden mit den Erhebungstechniken und Darstellungstechniken festgehalten, die auch bei der Ermittlung des Ist-Zustands eingesetzt werden. Des Weiteren werden die Schnittstellen definiert, über die Benutzer mit dem System kommunizieren werden. Nach dem Fachentwurf wird ein Grobentwurf erstellt, der beschreibt, wie das System realisiert werden soll. Diese nicht-funktionalen Anforderungen betreffen die Realisierung, die Systemeinführung, die Qualität und das Projektmanagement. Die Vorgehensweise zur Erstellung des Grobentwurfs ist stark davon abhängig, ob eine funktions-, daten- oder objektorientierte Sichtweise der Programmierung gewählt wird sowie von äußeren Rahmenbedingungen, beispielsweise Betriebssystemen, Datenbankverwaltungssystemen, Programmiersprachen und Softwareentwicklungswerk-zeugen.[8]
Alle aus Sicht der Kunden wünschenswerten Softwareeigenschaften werden im so genannten Lastenheft dokumentiert. Es enthält Wünsche der Auftraggeber an die Leistungen des Systems. Sämtliche Leistungsanforderungen des Lastenheftes, die für eine Erfüllung des Projektes notwendig sind, werden präzisiert, vervollständigt, nachvollziehbar gemacht, mit technischen Festlegungen verknüpft und vom Auftragnehmer im so genannten Pflichtenheft festgehalten.[9] Am Ende der Analysephase folgt ein weiterer Meilenstein, an dem Entscheidungsträgern das Soll-Konzept präsentiert und über die Fortführung des Projektes entschieden wird.[10]
1.2 Eigenentwicklung oder Standardsoftware?
(CR) Nach der Bestimmung des Soll-Konzeptes muss entschieden werden, ob ein eigenes System entwickelt oder eine Standardsoftware erworben wird. Eine Eigenentwicklung ist vor allem dann notwendig, wenn keine den Anforderungen entsprechende Standardsoftware vorhanden ist und durch den Einsatz einer Eigenentwicklung Wettbewerbsvorteile erwartet werden können. Vorteile durch den Erwerb einer Standardsoftware können sich daraus ergeben, dass der Kauf meist kostengünstiger ist als die eigene Produktion und Standardsoftware häufig sofort verfügbar ist und schneller eingesetzt werden kann. Weiterhin sind bei Einsatz von Standardsoftware keine oder weniger IT-Spezialisten im eigenen Unternehmen notwendig und die Risiken der Eigenentwicklung können umgangen werden. Oft werden professionelle Schulungen angeboten. Ferner verfügt Standardsoftware aufgrund einer hohen Nachfrage und einer relativ langen Laufzeit häufig über eine höhere Qualität. Den Vorteilen stehen folgende Nachteile gegenüber: Es sind oft erhebliche Anpassungen der Standardsoftware nötig, da der Anwender besondere Anforderungen hat. Die Ablauforganisation muss teilweise an die Standardsoftware angepasst werden. Sie kann zu allgemein entwickelt sein, was zu Effizienz- und Performanceverlusten führen kann. Außerdem kann es zu Schnittstellen- und Identifikationsproblemen sowie zu einer ungewollten Abhängigkeit vom Hersteller der Software kommen.[11]
1.3 Entwurfsphase bei Eigenproduktion
(CR) In der Entwurfsphase werden die Vorraussetzungen für die darauf folgende Realisierungsphase geschaffen. Es werden dabei drei Schritte durchlaufen. Zuerst wird ein strukturierter Systementwurf erstellt. Daran anschließend werden die Programmspezifikationen in Form eines erneuten Pflichtenheftes festgehalten. Diese enthalten detaillierte Vorgaben für einen Programmentwurf. Im letzten Schritt erfolgt die Erarbeitung eines systematischen und möglichst strukturierten Programmentwurfs anhand der Programmspezifikationen.[12]
Der Systementwurf wird aus dem Grobkonzept der Analysephase abgeleitet. Er besteht bei strukturierter Vorgehensweise aus dem Datenbankentwurf, dem Funktionsentwurf und dem Prozessentwurf. Aus dem Systementwurf werden die Programmspezifikationen für den Programmentwurf festgelegt. Sie enthalten Informationen über die Datenorganisation, Eingabedaten, Verarbeitungsinformationen und Ausgabedaten. Aus den Programmspezifikationen wird entweder ein Programmablaufplan oder ein Struktogramm erstellt, das in der Realisierungsphase in die Programmiersprache übertragen wird. Bei objektorientierter Vorgehensweise werden Daten und Funktionen zu Objekten zusammengefasst und mit Methoden der objektorientierten Systementwicklung bearbeitet.[13] Bei dem an die Entwurfphase anschließenden Meilenstein wird über die weitere Vorgehensweise entschieden.
1.4 Entwurfsphase bei Standardsoftware
(CR) Da der Erwerb einer Standardsoftware meist sehr kostenintensiv ist und nicht einfach wieder rückgängig gemacht werden kann, sollte die Auswahl sehr sorgfältig getroffen werden. Der Auswahlprozess sollte dabei die Punkte Ausschreibung und Angebotseinholung, Grob- und Feinbewertung der Angebote sowie Endauswahl enthalten.
Im ersten Schritt muss eine ausreichende Anzahl von Angeboten eingeholt werden. Bei der Grobbewertung sollten zuerst Angebote, die so genannte K.O.-Kriterien nicht erfüllen, ausgeschlossen werden. Danach sollte über weitere Kriterien die Auswahl bis auf ca. drei bis fünf Angebote eingegrenzt werden. Für die Feinbewertung kann z. B. eine Nutzwertanalyse durchgeführt werden. Dabei werden alle relevanten Kriterien zusammengestellt und gewichtet.[14] Um über die Fortführung des Projektes entscheiden zu können, sollten Wirtschaftlichkeitsvergleiche angestellt werden. Dabei können reine Kostenvergleiche und Kosten/Nutzen-Vergleiche erstellt werden. Bei den Kosten ist zwischen einmaligen und laufenden Kosten zu unterscheiden.[15]
1.5 Realisierungsphase bei Eigenentwicklung
(CR) Bei der Realisierung stehen die eigentliche Programmierarbeit und der Programm- und Systemtest im Vordergrund. Der Verlauf der Programmierung ist abhängig von den eingesetzten Programmen sowie von den benutzten Prinzipien, Methoden und Verfahren.[16]
Nach der Programmierung erfolgt das Testen. Es ist vorteilhaft, wenn die Anwendung schon während der Programmierung auf Fehler kontrolliert wird. „Unter Testen im engeren und klassischen Sinne versteht man die Prüfung von codierten Programmen auf korrekte Formulierung und Ausführung.“[17] Ein Software-Test ist ein mögliches Verfahren zur Verifikation und Validierung eines Programms. Unter Verifikation versteht man den mathematischen Beweis, dass das entwickelte Programm den vorher festgelegten Spezifikationen entspricht,[18] wohingegen bei der Validierung die Eignung beziehungsweise der Wert einer Software bezogen auf ihren Einsatzzweck überprüft wird.[19] Zum Testen können unterschiedlichste Verfahren angewendet werden. Neben der Überprüfung des Programmcodes sollte unter anderem ein Modultest, ein Komponententest, ein Systemtest und ein Abnahmetest mit allen Personen, die mit dem Programm arbeiten werden, durchgeführt werden. Die Bewertung der Ergebnisse des Tests führt zu weiteren Maßnahmen (z. B. Bugfixing).[20] Am Ende der Realisierungsphase folgt ein weiterer Meilenstein, an dem über die Fortführung des Projektes entschieden wird.
[...]
[1] Vgl. Breitner (2006a), S. 5.
[2] Vgl. Wapedia (2007), S. 1 – 2.
[3] Extreme Programmierung ist ein Softwareentwicklungsprozess, der durch kurze Zyklen mit häufigen Rückkopplungen und die kontinuierliche Überprüfung von realisierten mit spezifizierten Anforderungen gekennzeichnet ist. Weiterhin wird der Entwicklungsprozess nicht im Detail geplant, sondern an veränderte Anforderungen angepasst und umfasst den gesamten Lebenszyklus einer Software (vgl. Heinrich et al (2004), S. 244).
[4] Prototyping ist ein Ansatz zur Softwareentwicklung mit ausgeprägter Benutzerbeteiligung. Vgl. vertiefend Heinrich et al. (2004), S. 532 – 533.
[5] Vgl. Stahlknecht/Hasenkamp (2002), S. 222; Mertens et al. (2005), S. 160.
[6] Vgl. Stahlknecht/Hasenkamp (2002), S. 214.
[7] Vgl. Stahlknecht/Hasenkamp (2002), S. 229 – 230.
[8] Vgl. Stahlknecht/Hasenkamp (2002), S. 247 – 250.
[9] Vgl. Hasenkamp (2007), S. 2 – 3.
[10] Vgl. Stahlknecht/Hasenkamp (2002), S. 257.
[11] Vgl. Stahlknecht/Hasenkamp (2002), S. 302 – 303; Amberg (2007), S. 9.
[12] Vgl. Stahlknecht/Hasenkamp (2002), S. 258.
[13] Vgl. Stahlknecht/Hasenkamp (2002), S. 257; Stahlknecht/Hasenkamp (2002), S. 278.
[14] Vgl. Stahlknecht/Hasenkamp (2002), S. 304 – 310.
[15] Vgl. Waehlert (2007), S. 35 – 37.
[16] Vgl. Stahlknecht/Hasenkamp (2002), S. 288.
[17] Vgl. Stahlknecht/Hasenkamp (2002), S. 295.
[18] Vgl. IT Wissen (2007c), S. 1.
[19] Vgl. Meyers Lexikon Online (2007), S. 1.
[20] Vgl. Floyd/Oberquelle (2004), S. 8.