Beschreibungsmodelle

Beschreibungsmodelle Mike Hüftle 28. Juli 2006 Inhaltsverzeichnis 1 Einleitung 2 1.1.................................... 2 2 Architekturmodelle 3 2.1 Allgemeines.............................. 3 2.2 ARIS.................................. 4 2.3 ARIS.................................. 5 2.4 CIM-OSA............................... 6 2.5 CIM-OSA............................... 7 2.6 Literatur und Software........................ 8 3 Datenmodelle 9 3.1 Allgemeines.............................. 9 3.2 Entity-Relationship-Modelle..................... 10 3.3 UML-Modelle............................. 11 3.3.1 Nebenpfad: Klassendiagramm................ 11 3.3.2 Nebenpfad: Paketdiagramm................. 13 3.4 Literatur und Programme...................... 14 4 Prozessmodelle 15 4.1 Allgemeines.............................. 15 4.2 Datenfluss-Diagramm........................ 16 4.3 Ereignisgesteuerte Prozesskette................... 17 4.4 Literatur................................ 18 5 Vorgehensmodelle 19 5.1 Allgemeines.............................. 19 5.2 Wasserfallmodell........................... 20 5.3 Spiralmodell.............................. 21 5.4 Rapid Prototyping.......................... 22 5.5 V-Modell............................... 23 5.6 RUP.................................. 24 5.7 Literatur................................ 25 1

1 Einleitung 1.1 Beschreibungsmodelle Beschreibungsmodelle dienen der Darstellung von Strukturen, Zusammenhängen und Prozessen, ohne dass man daraus quantitative Werte für die Variablen ableitet. Sie beschreiben Elemente, Beziehungen und Abläufe in Systemen. Beschreibungsmodelle dienen immer nur einer ersten Analyse des Systems und seiner Systemumwelt. Es sind daher weitere, detailliertere Modellierungen nötig, um sie in ein Rechenmodell umsetzen zu können. Wichtige Modellgruppen In der Praxis wichtige Modellgruppen sind: Architekturmodelle Datenmodelle Prozessmodelle Vorgehensmodelle 2

2 Architekturmodelle 2.1 Allgemeines Architekturmodelle Architekturmodelle modellieren in der Wirtschaftsinformatik die Komponenten eines Informationssystems und ihre Beziehungen zueinander. Die Informatik versteht unter einem Architekturmodell eine Softwarearchitektur im Rahmen der Softwareentwicklung, die als Vorlage für die Entwicklung einer konkreten Software dient. Grundgedanke Grundgedanke von Architekturmodellen ist die Realisierung umfangreicher Modelledurch einzelne Komponenten, die miteinander verbunden werden. Anwendung Architekturmodelle werden insbesondere bei der Analyse komplexer Geschäftsprozesse eingesetzt, um deren strukturierte und übersichtliche Modellierung zur Übertragung auf ein Informationssystem zu ermöglichen 3

2.2 ARIS ARIS ARIS (Architektur integrierter Informationssysteme) wurde von Prof. A.-W. Scheer am Institut für Wirtschaftsinformatik der Universität des Saarlandes entwickelt und gehört heute zu den am häufigsten eingesetzten Architekturmodellen der Softwareentwicklung. Das ARIS-Konzept ist Grundlage vieler Softwareprodukte, insbesondere des ARIS-Toolsets der IDS-Scheer AG. Das ARIS-Toolset ist ein Softwareentwicklungs-Tool zur Modellierung von Geschäftsprozessen. Es wird häufig in Verbindung mit dem Einsatz von SAP- Systemen verwendet. Zerlegung in Teilmodelle Das ARIS-Konzept geht von einer Zerlegung des gesamten Modells in Teilmodelle aus, so dass für die Beschreibung der einzelnen Elemente spezielle Modelle und Methoden verwendet werden können. Durch die Aufteilung des ursprünglichen Problems in einfacher zu handhabende Teilprobleme wird die Komplexität der Modellierung erheblich reduziert. Für jedes Teilproblem können spezielle Methoden und Werkzeuge eingesetzt werden. 4

2.3 ARIS Ebenen-Sicht Das so genannte ARIS-Haus basiert auf vier Sichten: der Organisations-, der Daten-, der Funktions- und der Steuerungssicht. Jede Sicht des ARIS-Konzeptes spiegelt eine bestimmte Sicht auf einen Geschäftsprozess wieder. Die Funktionssicht definiert die Abläufe im Unternehmen, die Organisationssicht die Ressourcen und die Datensicht die im Unternehmen vorgehaltenen Daten. Die Steuerungssicht verknüpft die anderen Sichten, indem sie zeitliche und logische Abläufe zwischen diesen festlegt. Die Steuerungssicht unterscheidet ARIS von anderen Architekturmodellen. ARIS- Konzepte Jede Sicht des ARIS-Hauses ist in drei Ebenen aufgeteilt. Das Fachkonzept, das DV-Konzept und die technische Implementierung. Der Übergang von einem zum nächsten Konzept bringt eine verfeinerte Strukturierung und technisch anspruchsvollere Beschreibung mit sich. Das Fachkonzept ist eine strukturierte Darstellung der verschiedenen Sichten mittels Beschreibungsmodellen (Organigramm, semantisches Datenmodell, Ereignisgesteuerte Prozesskette, Datenflussmodell). Das DV-Konzept beschreibt die Umsetzung des Fachkonzeptes in ein technisches Beschreibungsmodell (Netzwerktopologie, Datenbankmodell, Software- Struktogramme, Topologische Modelle). Auf der untersten Ebene, der technischen Implementierung, wird die technische Realisierung des Modells beschrieben (Physische Netzwerke, Datenbanksystem, Programmcode, Protokolle). 5

2.4 CIM-OSA CIM-OSA Die Informationssystemarchitekur CIM-OSA (Open Systems Architecture for Computer Integrated Manufacturing) wurde ursprünglich für die Computerintegrierte Fertigung (CIM) entwickelt. Sie entstand unter dem ESPRIT-Projekt (European Strategic Program for Research and Development in Information Technology) der Europäischen Union mit Hilfe von mehr als 30 europäischen Unternehmen und akademischen Institutionen. Im Mittelpunkt von CIM-OSA steht die prozessorientierte Modellierung von Produktionsunternehmen. Prozessbasierte Architektur CIM-OSA ist eine ereignisgesteuerte, prozessbasierte Architektur, die ein Unternehmen als eine Sammlung von (parallelen) Prozessen und dem Zusammenspiel von funktionalen Einheiten abbildet, welche die Prozesse ausführen. Ein Prozess ist in diesem Sinne eine Menge von Aktivitäten. Somit realisiert CIM-OSA eine klare Trennung von Prozessenund Ressourcen. Prozesse Ein Prozess wird durch drei Arten von Flüssen beschrieben. Kontroll- oder Arbeitsflüsse, Materialflüsse und Informationsflüsse. Diese Flüsse können sukzessive modelliert werden. Modellrestriktionen legen beispielsweise fest, welche Ressourcen für welchen Prozess benötigt werden oder welche Prozesse bei einem Ressourcenengpass bevorzugt bedient werden. 6

2.5 CIM-OSA Phasen Ähnliche wie ARIS baut CIM-OSA auf einer sichtenbasierten Architektur auf. Während der Modellierung wird der Abstraktionsgrad des Modells schrittweise verfeinert. Dabei werden drei Phasen des Implementierungsprozesses unterschieden: die Anforderungsphase, die Entwurfsphase und die Implementierungsphase. Sichtenbildung Im Rahmen einer Verfeinerung der Sicht auf das Modell wird zwischen einer Funktions-, einer Ressourcen-, einer Daten- und einer Funktionssicht unterschieden. Die Funktionssicht enthält eine hierarchische Aufgliederung der Struktur und des Verhaltens der Unternehmensprozesse. Durch diese Sichtenbildung und die damit verbundene Zerlegung des Gesamtmodells soll dessen Transparenz verbessert werden. Geltungsbereiche Eine weitere Möglichkeit der Verfeinerung betrifft den Geltungsbereich des Modells. Hier wird zwischen allgemeinen, branchenspezifischen und unternehmensspezifischen Modellen unterschieden. CIM-OSA- Würfel Fügt man die einzelnen Phasen, die Sichten und die Geltungsbereiche in drei Dimensionen zusammen, so entsteht der CIM-OSA-Würfel, der die genannten Aspekte des Modellbildungsprozesses grafisch verdeutlicht. Die Modellierung erfolgt mittels so genannter Templates (Vorlagen)von denen eine große Anzahl standardisiert zur Verfügung stehen. Dies sind Bausteine einer eigenen CIM- OSA-Modellierungssprache. Nachteile Im Gegensatz zu ARIS fehlt bei CIM-OSA eine Ebene, welche die einzelnen Sichten wieder zusammenfügt. Deshalb ist eine überschneidungsfreie Formulierung der einzelnen Schichten notwenig. Da die CIM-OSA-Modellierung sehr komplex ist, und vor ihrer Einführung bereits leistungsfähige Architekturmodelle bestanden, wird CIM-OSA in der Praxis nur selten zur Modellierung verwendet. 7

2.6 Literatur und Software Literaturverzeichnis Literatur zu ARIS Bullinger, H.-J.; Schreiner, P. (Hrsg.): Business Process Management Tools,- Eine evaluierende Marktstudie über aktuelle Werkzeuge, Frauenhofer IRB Verlag, Stuttgart 2001. Scheer, A.-W.: Architektur integrierter Informationssysteme. Springer, Berlin, Heidelberg et al. 1992. Scheer, A.-W./ Jost, W.: ARIS in der Praxis. Springer, Berlin 2002. Literatur zu CIM-OSA Bernus, P./Nemes, L. (1996): Modelling and Methodologies for Enterprise Integration, Chapman & Hall, London, 1996. Bernus, P./Mertins, K./Schmidt, G. (eds): Handbook on Architectures for Information Systems. Springer, Berlin Heidelberg New York 1998. ESPRIT Consortium AMICE (eds.): CIMOSA - CIM Open System Architecture. Springer, Berlin Heidelberg New York 1993. Vernadat, F.: CIMOSA: Enterprise modelling and enterprise integration using a process-based approach, in: Yoshikawa, H./Goossenaerts, J. (eds.): Information Infrastructure Systems for Manufacturing, North-Holland, Amsterdam 1993, pp. 65-84. Softwaretools zur Geschäftsprozessmodellierung ARIS 6 Collaborative Suite, IDS-Scheer, http://www.ids-scheer.de CIMOSA compliant Business Process Modelling, NEMETZ INFORMATIONS- VERARBEITUNG, www.nemetz-it.de PACE Simulator Development System (PACE 5.0), IBE, http://www.ibepace.com/ DELMIA Toolset for Product-Process Modelling, DELMIA, http://www.delmia.com/ CLT - CIMOSA Learning Tool for Enterprise Integration, Polytecnic University Valencia, 2000 8

3 Datenmodelle 3.1 Allgemeines Darstellung von Informationen Ein Datenmodell ist eine Darstellung von Informationen und deren Beziehungen. Man spricht auch von einem semantischen Datenmodell. Datenmodelle beschreiben die Struktur von Informationen (in Form gespeicherter Daten) und ihre Beziehungen untereinander als fachbezogenen Ausschnitt der Realität. Sie bilden Systeme auf die zugehörigen Daten- oder Klassenstrukturen ab. Für die Modellierung und formale Darstellung von Datenmodellen werden Techniken wie das ER-Modell oder das Klassendiagramm der UML benutzt. 9

3.2 Entity-Relationship-Modelle Entity- Relationship- Modell (ERM) Das Entity-Relationship-Modell (ERM) geht auf Chen [] zurück. Es ist aufgrund seiner klaren Definitionen und der einfachen, benutzerfreundlichen Darstellungsweise das am häufigsten verwendete Modell zur Beschreibung von relationalen Datenstrukturen. Das Modell setzt sich aus einer grafischen Darstellung und einer Beschreibung der darin enthaltenen Elemente zusammen. ERM und relationale Datenbanken Es wird in der konzeptionellen Phase der Datenbankentwicklung zur Systemstrukturierung verwendet und dient als Grundlage für die spätere Implementierung. Relationale Datenbankschema können relativ einfach aus dem ERM abgeleitet werden. Es ermöglicht, aus einer Beschreibung der realen Welt, die einzelnen Felder, Datentypen und Tabellen einer relationalen Datenbank zu modellieren. Elemente des ERM Das ERM unterscheidet zwischen Entities (Objekten), Attributen und Relationen (Beziehungen). Entities sind Personen oder Dinge, beispielsweise Maschinen oder Fahrzeuge, welche zu Entitytypen zusammengefasst werden. Dies sind Mengen gleichartiger Entities. Entitytypen werden im ERM als Rechteck dargestellt und groß geschrieben. Attribute sind Eigenschaften der Entities, beispielsweise Namen von Personen oder die Kapazität einer Maschine und werden als mit dem Entitytyp verbundener Kreis dargestellt. Relationen modellieren die Beziehung zwischen zwei oder mehreren Entitytypen. Beziehungen werden im ERM durch Rauten dargestellt, welche die Entities verbinden. Es könne verschiedene Arten von Beziehungen abgebildet werden, so dass das ERM eine flexible Struktur zur Modellierung von Datenstrukturen bietet. Die Abbildung zeigt ein einfaches Beispiel für ein ERM. Dargestellt ist eine Autofahrt mit Fahrer, Auto und verbrauchtem Benzin. [] 10

3.3 UML-Modelle Unified Modeling Language (UML) Die Unified Modeling Language (UML) ist eine vereinheitlichte und standardisierte Beschreibungssprache, um Strukturen und Abläufe in objektorientierten Softwaresystemen darzustellen. UML bietet Bezeichner und grafische Notationen für die meisten Begriffe der Objektorientierung. Da die Standardisierung auch das Datenformat der Speicherung von UML-Dokumenten umfasst (eine XML-Variante), ermöglicht UML Daten über die Modellierung zwischen unterschiedlichen Modellierungstools auszutauschen. Diagrammtypen der UML UML unterstützt 13 Diagrammtypen, welche für unterschiedliche Zwecke eingesetzt werden. Die Abbildung gibt einen Überblick über die Diagrammtypen der UML. Wichtige Diagrammtypen Beispiel für Diagrammtypen sind: Klassendiagramme: Beschreiben die Struktur und das Verhalten von Objekten. Objekte sind Instanzen einer Klasse mit Attributen und Operationen (Methoden). Mehr Informationen zu Klassendiagrammen Anwendungsfalldiagramme: Modellieren die Anforderungen an ein System aus Sicht des Benutzers Aktivitätsdiagramme: Beschreiben Aktivitäten als eine Menge von elementaren Aktionen, zwischen denen Kontroll- und Datenflüsse existieren. Paketdiagramme: Stellen die Unterteilung der Software in einzelne Module dar. Mehr zu Paketdiagrammen 3.3.1 Nebenpfad: Klassendiagramm Objekte Objekte sind Modellierungseinheiten (z.b. der Kunde Erwin Meier), die gewissen Attribute besitzen (z.b. ihren Namen). MIttels der Operationen (Methoden), die für ein Objekt verfügbar sind, kann auf dieses Objekt zugegriffen werden, beispielsweise können Attributwerte des Objektes ausgelesen oder 11

verändert werden oder es können Berechnungen mit diesen Attributwerten durchgeführt werden (z.b. kann die Kreditwürdigkeit von Herrn Meier geprüft werden). Objekte mit gleichen Attributen und Operationen werden zu Klassen zusammengefasst. Ein Objekt wird auch Instanz einer Klasse genannt. Super- und Subklassen Eine Superklasse fasst mehrer Subklassen zusammen. Alle Subklassen verfügen über die Attribute und Operationen ihrer Superklasse, können aber auch eigene Attribute und Operationen besitzen. So haben die Subklassen Unternehmen als auch Privatkunde beide einen Namen und eine Adresse. Der Privatkunde hat zusätzliche eine Kreditkartennummer, das UNternehmen eine Kontaktperson und eine Kreditwürdigkeit. Beziehungen Beziehungen (Assoziationen) verknüpfen verschiedene Klassen miteinander. Die Multiplizität a..b an der Beziehung einer Klasse K zu einer Klasse C ist folgendermaßen zu interpretieren: Zu einer Instanz der Klasse C gehören a..b Instanzen der Klasse K. Beispielsweise gehören zu jeder Instanz der Klasse Auftrag eine bis mehrer Instanzen der Klasse Auftragsposition, zu einer Instanz Auftragsposition gehört jedoch immer genau eine Instanz Auftrag. Die Multiplizität * bedeutet beliebig viele. Beispiel Wichtige Begriffe Weitere wichtige Begriffe der UML sind: Vererbung: Übernahme von Eigenschaften und Methoden übergeordneter Klassen (Superklassen) der Klassenhierarchie Polymorphie: Verwendung des gleichen Namens für Methoden, die in unterschiedlichen Klassen ähnliche Operationen ausführen (die Methode fahren ist für die Klasse PKW sicherlich anders implementiert als für Fahrrad ) Instanz: Objekt einer bestimmten Klasse Persistenz: dauerhafte Speicherung von Objekten Surrogat: eindeutige, nicht veränderbare Identifikation eines Objektes 12

3.3.2 Nebenpfad: Paketdiagramm Pakete Das Paketdiagramm ist ein Strukturdiagramm, das Pakete, Paketimports, Paketverschmelzungen und Abhängigkeitsbeziehungen dargestellt. Ein Paket steht für eine Menge zusammengehöriger Klassen und Assoziationen und wird als Kästchen mit einem Reiter dargstellt, der den Paketnamen enthält. Pakete sind beispielsweise (in gewissem Umfang) eigenständige Softwaremodule. Innerhalb der Paketbox können auch enthaltene Klassen oder Unterpakete dargestellt werden. Paketdiagramme Paketdiagramme stellen Abhängigkeiten zwischen Paketen dar. Abhängigkeiten werden durch einen gestrichelten gerichteten Pfeil dargestellt. Dabei greift das Quellpaket (stumpfes Ende) auf das Zielpaket (Pfeilspitze) zu. Struktur Die Abbildung zeigt ein Paketdiagramm mit 4 Paketen. Paket P3 hat Zugriff (access) auf das Paket P1. P3 kann Elemente aus P2 importieren. Im Gegensatz zum Zugriff können beim Import Paketteile auch an andere Pakete weitergegeben werden. P4 kann somit auf Paketteile aus P3 und P2 zugreifen. 13

3.4 Literatur und Programme Literaturverzeichnis Literatur zum Entity-Relationship-Model Chen, P. P.: The Entity-Relationship Model. Toward a Unified View of Data, in: ACM Transactions on Database Systems Vol. 1, 1976, pp. 9-36. Kemper, A./ Eickler, A.: Datenbanksysteme: Eine Einführung. 5. Aufl., Oldenbourg, Berlin 2004. Literatur zur UML Balzert, H.: Lehrbuch der Objektmodellierung, Spektrum Akademischer Verlag, Heidelberg 1999. Balzert, H.: UML 2 in 5 Tagen, W3L, Bochum 2005. Born, M./Holz, E./Kath, O.: Softwareentwicklung mit UML 2, Addison-Wesley, 2004. Jeckle, M./Rupp, C./Hahn, J./Zengler, B./Queins, S.: UML 2 glasklar, Hanser-Verlag, München 2003. Störrle, H.: UML 2 für Studenten, Pearson Studium Deutschland, München 2005. Softwaretools zur UML- Modellierung ArgoUML, University of California, www.argouml.org (Open Source) ARTiSAN Studio, ARTiSAN Software Tools, http://www.artisansw.com/ Fujaba, Uni Paderborn, http://wwwcs.uni-paderborn.de/cs/fujaba/ (Freie Software) Smart Draw, SmartDraw.com, http://www.smartdraw.com Einen guten Überblick zu UML-Tools gibt die Seite http://www.jeckle.de/umltools.htm 14

4 Prozessmodelle 4.1 Allgemeines Beschreibung von Prozessen Ein Prozessmodell ist eine abstrakte, vereinfachende Beschreibung eines Prozesses(z.B. eines Geschäftsprozesses). Ein Prozess besteht aus einer zeitlich, funktional-logischen Abfolge von einzelnen Prozessschritten. Jedes Prozessmodell stellt aufgrund seiner Abstraktionsstufe immer eine bestimmte Sicht auf den beschriebenen Prozess dar. Prozessmodelle dienen als Vorlage für die Dokumentation, Analyse und Gestaltung von Prozessen. 15

4.2 Datenfluss-Diagramm Datenfluss- Diagramme Datenflussdiagramme (Blasendiagramme, bubble charts) dienen der Beschreibung von Datenflüssen. Sie sind ein wichtiger Bestandteil der Strukturierten Analyse (SA). Dies ist eine in den 70er Jahren entwickelte Methode zur Systembeschreibung in der Softwareentwicklung. Ein komplexes System wird hierarchisch in immer einfachere Funktionen aufgegliedert und gleichzeitig eine Datenflussmodellierung durchgeführt. Elementtypen in Datenfluss- Diagrammen Es werden vier Elementtypen in einem solchen Diagramm unterschieden: [] Datenspeicher (Dateien) werden durch den Namen des Speichers zwischen zwei parallelen Linien dargestellt. Datenspeicher können von Prozessen (Funktionen) ausgelesen oder beschrieben werden. Ein Prozess wird durch einen Kreis (bubble) mit seinem Namen dargestellt. In weiteren Datenfluss-Diagrammen können einzelne Prozesse (Subprozesse) detailliert dargestellt werden. Schnittstellen zur Systemumwelt jenseits der Systemgrenzen werden durch ein Rechteck mit dem Namen der Datenquelle oder -senke dargestellt. Datenflüsse, dargestellt durch gerichtete Kanten, repräsentieren den Informationsfluss zwischen den anderen Elementen. Beispiel Die Abbildung zeigt ein Beispiel für ein Datenfluss-Diagramm. Die kleinen Kreise mit vier bzw. acht Speichen sind die logischen Verknüpfungen oder bzw. und zwischen zwei Datenflüssen. Anwendung Da jedoch komplexe Systeme mittels der Datenflussanalyse nur schwierig zu modellieren sind, wird diese heute kaum noch genutzt. Anstatt dessen wird meist die Ereignisgesteuerte Prozesskette eingesetzt. 16

4.3 Ereignisgesteuerte Prozesskette EreignisgesteuerteDie Ereignisgesteuerte Prozesskette (EPK) ist ein wesentliches Element der Prozesskette ARIS-Modellierung um Geschäftsprozesse abzubilden. Außerdem wird sie häufig bei der Prozesskostenrechnung und der Prozessoptimierung eingesetzt. Elemente der EPK In einer EPK gibt es zwei Objekttypen - Ereignisse und Aktivitäten: Ereignisse sind Voraussetzungen und Folgen von Aktivitäten, denen Eintrittswahrscheinlichkeiten zugeordnet werden können. Sie nehmen keine Ressourcen in Anspruch. Aktivitäten werden durch Ereignisse ausgelöst und enden in Ereignissen. Mit ihnen ist ein Ressourcenverbrauch (Zeit, Geld, Menschen etc.) verbunden. Jede Aktivität kann außerdem mit einem Informationsobjekt verbunden werden, aus dem Informationen abgerufen oder in dem Informationen gespeichert werden können. Ereignisse und Aktivitäten bilden eine alternierende Folge, d.h. auf ein Ereignis folgt immer eine Aktivität und umgekehrt. Zwischen Ereignissen und Aktivitäten können logische Verknüpfungen stehen. Erlaubt sind die Operatoren entweder oder, oder sowie und. Beispiel Die Abbildung zeigt ein Beispiel für eine EPK anhand einer Autofahrt, die entweder unkompliziert verlaufen kann, oder aber durch eine Panne und die damit verbundenen Ereignisse und Aktivitäten unterbrochen wird. 17

4.4 Literatur Literaturverzeichnis Literatur zu Ereignisgesteuerten Prozessketten Scheer, A.-W.: Architektur integrierter Informationssysteme. Springer, Berlin, Heidelberg et al. 1992. Scheer, A.-W./ Jost, W.: ARIS in der Praxis. Springer, Berlin 2002. 18

5 Vorgehensmodelle 5.1 Allgemeines Allgemeines Ein Vorgehensmodell definiert die einzelnen Schritte in einem Vorgehen, das als Modell für unterschiedliche Projekte ausformuliert werden kann. Ein Vorgehensmodell gibt Methoden und Werkzeuge vor und definiert Abläufe und Ergebnisse in einem Projekt. Es hat die Aufgabe, die in einem Gestaltungsprozess auftetenden Aufgaben und Vorgänge in einer logischen Abfolge zu strukturieren und zu dokumentieren. Auf den folgenden Seiten werden Vorgehensmodelle vorgestellt, die für die Softwareentwicklung konzipiert wurden. Es existieren ähnliche Vorgehensmodelle in anderen Bereichen, beispielsweise im Änderungsmanagement. 19

5.2 Wasserfallmodell Wasserfallmodell Das Wasserfallmodell steht für die traditionelle Vorgehensweise bei der Softwareentwicklung. Die Bezeichnung Wasserfallmodell kommt von einer grafischen Darstellung, welche das Vorgehen als Kaskade von Entwicklungsschritten zeigt. Vorgehensweise Jede Software-Entwicklung besteht nach dem Wasserfallmodell aus einer Folge von Entwicklungsstufen, wobei jede Stufe einen definierten Start- und Endpunkt mit festgelegten Ergebnissen hat. Das Vorgehen im Wasserfall-Modell durchläuft die in der Abbildung dargestellten Stufen: [] 1. Voruntersuchung: Anforderungsanalyse 2. Fachentwurf: Anforderungsspezifikation 3. Systementwurf und -spezifikation 4. Implementierung: Programmierung und Tests einzelner Module 5. Integration der Module und Systemtests 6. Stabilisierung: Auslieferung, Einsatz und Wartung Die Stufen können nur in einer Richtung durchlaufen werden. Erweiterungen dieses Modells erlauben auch, einzelne Stufen zurückzugehen um Fehlerverbesserungen auf einer vorherigen Stufe vornehmen zu können. 20

5.3 Spiralmodell Spiralmodell Das Spiralmodell ist ein iteratives Vorgehensmodell als Weiterentwicklung des Wasserfall-Modells. Es fasst die Software-Entwicklung als einen zyklischen Prozess auf, in dem jeder Zyklus mindestens vier Aktivitäten durchläuft. In jedem Zyklus wird der Entwicklungsstand der zu entwickelnden Software dokumentiert. Vorgehens- Zyklus Zu Beginn eines Zyklus werden Ziele und Rahmenbedingungen des Entwicklungsprozesses festgelegt. Anschließend wird eine Risikobewertung des aktuellen Entwicklungsstandes vorgenommen. Die Hauptaktivität umfasst die (Weiter-) Entwicklung der Software und ihre Validierung. In einer letzten Aktivität erfolgt die Planung des weiteren Projektverlaufes und die Bewertung des Projektfortschrittes. 21

5.4 Rapid Prototyping Rapid Prototyping Rapid Prototyping ist ein Methode der Softwareentwicklung, die zu schnellen ersten Ergebnissen führen soll. In einem mehrfach zu durchlaufenden Zyklus werden Software-Prototypen implementiert und getestet. Aus den Tests heraus entstehen neue Anforderungen, die dann in den nächsten Prototypen einfließen. Frühzeitige Berücksichtigung von Änderungen Rapid Prototyping dient dazu, dem Auftraggeber bzw. den zukünftigen Nutzern schon früh in der Softwareentwicklung eine Vorstellung vom System und der Benutzeroberfläche zu geben um so etwaige Änderungswünsche nicht im Nachhinein implementieren zu müssen. Die iterative Entwicklung kann somit früh auf Probleme aufmerksam machen und veränderte Kundenwünsche in die Anforderungen einfließen lassen. Probleme Durch die schnelle Entwicklung wird jedoch oft eine uneffiziente Programmierung in Kauf genommen. Auch kann Rapid Prototyping in eine Endlosschleife immer neuer Anforderungen führen und so die geplante Projektdauer erheblich verlängern. 22

5.5 V-Modell Ergebnisse und Aktivitäten Im V-Modell werden, im Gegensatz zu einem klassischen Phasenmodell (Wasserfallmodell, Spiralmodell), lediglich Aktivitäten und Ergebnisse definiert und keine strenge zeitliche Abfolge festgelegt. Auch gibt es keine Abnahmen am Ende der Phasen wie dies bei Phasenmodellen der Fall ist. Submodelle Im V-Modell werden ähnliche Aktivitäten zu Submodellen zusammengefasst. Es werden die Submodelle Softwareerstellung (SWE), Qualitätssicherung (QS), Konfigurationsmanagement (KM) und Projektmanagement (PM) unterschieden. Aktivitäten und Produkte Aktivitäten werden in Hauptaktivitäten und verschiedene Hierarchieebenen von Teilaktivitäten untergliedert. Aktivitäten können Dokumente (so genannte Produkte) verändern. Produkte können verschiedene Zustände annehmen: geplant, in Bearbeitung, vorgelegt und akzeptiert. Je nach Zustand sind sie verfügbar und können von Aktivitäten bearbeitet werden. Für jede Aktivität ist festgelegt, welche Produkte sie modifiziert und wie diese Modifikation durchgeführt wird. Zu jeder Aktivität ist ein Produktfluss und eine Abwicklung festgelegt. Der Produktfluss gibt an, aus welchen vorhergehenden Aktivitäten die Eingabeprodukte kommen und an welche nachfolgenden Aktivitäten die modifizierten Ausgabeprodukte weitergereicht werden. Die Abwicklung enthält detaillierte Angaben zur Durchführung einer Aktivität. Tailoring Als Tailoring wird die Anpassung des V-Modells auf die Gegebenheiten eines speziellen Produktes bezeichnet. Das V-Modell dient beispielsweise bei der Entwicklungen von IT-Systemen für die öffentliche Hand als Standard. 23

5.6 RUP Rational Unified Process Der Rational Unified Process (RUP) ist ein von der Firma Rational Software Corporation entwickeltes Vorgehensmodell zur Softwareentwicklung. Er basiert auf einem iterativen Software-Entwicklungsprozess ähnlich dem Spiralmodell. Aspekte des RUP Wichtige Aspekte des RUP sind das Anforderungsmanagement, der Einsatz komponentenbasierter Architekturen, das visuelle Modellieren der Software, die laufende Qualitätssicherung und das Änderungsmanagement. Elemente des RUP Die Basiselemente des RUP sind Tätigkeiten, Workflows, Rollen, Artefakte, Iterationen, Phasen und Zyklen. Tätigkeiten Tätigkeiten sind definierte Arbeitseinheiten, deren Abfolge durch einenworkflow beschrieben wird. Die Tätigkeiten werden von Rollen ausgeführt, dies sind Individuen oder Gruppen von Bearbeitern. Die Inputs und Outputs von Tätigkeiten werden Artefakte genannt. Workflow Es existieren verschiedene Arten von Workflows wie beispielsweise Projektmangement, Anforderungs-, Analyse-, Entwurfs-, Implementierungs- oder Testworkflow. Iterationen fassen (Teile von) Workflows zusammen, die einen bestimmten Systemaspekt betreffen. Phasen sind Folgen von Iterationen, die alle einen bestimmten Aspekt des RUP verfolgen. Zyklen umfassen die gesamte Entwicklung von einzelnen Produkt-Releases. Vorteile des RUP Der RUP bringt verschiedene Vorteile: Durch die iterative Vorgehensweise werden Missverständnisse und Fehler früh entdeckt und der Benutzer wird in die Entwicklung mit einbezogen. Es erfolgt ein laufendes Testen der Software und somit eine ständige Qualitätssicherung. Inkonsistenzen zwischen den Anforderungen und dem tatsächlichen Entwurf werden frühzeitig aufgedeckt. Durch das Arbeitsmanagement kann der Arbeitsaufwand gleichmäßiger auf die einzelnen Rollen verteilt werden. Alle Beteiligten können sich während des Entwicklungsprozesses über den Projektstatus informieren. 24

5.7 Literatur Literaturverzeichnis Literatur zum Software-Engeneering Boehm, B.W.: Software Engineering Economics. Prentice Hall, Englewood Cliffs 1981. Balzert, H.: Lehrbuch der Software-Technik: Software-Management, Software-Qualitätssicherung. Spektrum Verlag, Heidelberg 1998. Pagel, B.-U., Six H.W.: Software Engineering - Band 1: Die Phasen der Softwareentwicklung. Addison-Wesley, Bonn 1994. Literatur zum V-Modell Dröschel, W./Heuser, W./Midderhoff, R. (Hrsg.): Inkrementelle und objektorientierte Vorgehensweisen mit dem V-Modell 97. Oldenbourg 1997. Bröhl, A.-P. /Dröschel, W. (Hrsg.): Das V-Modell. Der Standard für die Softwareentwicklung mit Praxisleitfaden, 2. Aufl., Oldenbourg 1995. www.v-modell.iabg.de Literatur zum RUP Hunt, J.J.: The Unified Process for Practitioners, Object-Oriented Design, UML and Java Design. Springer, 2000. Jacobson, I.: The Unified Software Development Process. Addison-Wesley, 1999. Kruchten, P. : The Rational Unified Process-An Introduction. 2nd ed., Addison-Wesley, 2000. 25