Grundlagen der Modellierung und

Vorlesung: Entwurf 

LE 2: Grundlagen der Modellierung und 

Projektmodelle 

Gliederung: Lernziele: 

2. Grundlagen der Modellierung und Projektmodelle Sie kennen wichtige 

Projektvorgehens-weisen mit ihren 

A. Projektvorgehensweisen 

Vor- und Nachteilen. 

Sie wissen, wie mit dem generischen 

Architekturrahmen 

B. Generischer Architekturrahmen 

Modellierungsansätze anhand der 

Merkmale, Sicht, Ebene und 

C. Gegenüberstellung Daten- / Funktions- und Metamodell unterschieden werden 

Objektorientierte Modellierung 

können. 

Sie kennen die wesentliche Merkmale 

der Daten-, Funktions- und 

objektorientierten Modellierung. 

© Prof. Dr. H. Krcmar 

Projektvorgehensweisen 

• Wasserfallmodell 

• Prototyping Projektmodell 

• Spiralmodell nach Böhm 

• V-Modell 

© Prof. Dr. H. Krcmar

Wasserfallmodell 

Quelle: zitiert in: Lehnert et al. 1995 S. 91 nach Boehm 1981 


Vorteile des Wasserfallmodells 

Vorteile: 

Es ist besser als ein vollkommen systemloses Vorgehen 

Definition von Meilensteinen wird unterstützt 

Alternativen sind schwer zu finden 

Universell anwendbar 

Anmerkung: Die vorgestellte Variante des Wasserfallmodells 

realitätsnäher als die klassische Variante, die keine Rückbezüge 

zwischen den Phasen kennt. 

Quelle: in Anlehnung an Sinz 1996 Vorlesung EBIS 1 


Nachteile des Wasserfallmodells 

Nachteile: 

Realitätsfern: Der reale Entwicklungsprozess vollzieht sich 

nicht in disjunkten Phasen 

Sehr große Zeitspanne zwischen Anforderungsspezifikation 

und dem ersten Ergebnis 

Annahme vollständiger Anforderungsspezi-fikation 

Lastenheft (Auftraggeber) bzw. Pflichtenheft (Auftraggeber 

oder Auftragnehmer) in der ersten Phase erwies sich bei 

Softwareprojekten als unrealistisch. 

Quelle: in Anlehnung an Sinz 1996 Vorlesung EBIS 1 


Prototyping Projektmodell 

Quelle: zitiert in: Lehnert et al. 1995 S. 91 nach Sneed 1989 und Agresti 1986 


Rapid Prototyping 

Einsatz von Entwicklungsumgebungen, die eine schnelle 

Entwicklung des Prototypen erlauben, der i.d.R. den realen 

Anforderungen nicht gewachsen ist. (Stichwort: 4GL) 

vertikales Prototyping 

vollständige Realisierung eines ausgewählten Teils der 

Anwendung durch alle Schichten 

exploratives Prototyping 

Unterstützung der Spezifikationsaktivitäten 

experimentelles Prototyping 

software-technische Überprüfung eines Lösungskonzeptes - 

in realer Umgebung. 

horizontales Prototyping 

ausgewählte Schichten des Systems werden konstruiert (z.B. 

Benutzeroberfläche, oder DB) 

Quelle: Lehnert et al. 1995 S. 93f. 

Arten des Prototyping 


Bewertung des Prototyping Projektmodells 

Vorteile: 

Eine umfassende Anforderungsspezifikation zum 

Projektstart ist nicht notwendig 

Eine Festlegung auf bestimmte Basismaschinen 

(Programmiersprachen, Datenbanken, Hardware) zum 

Projektstart ist nicht notwendig 

Erste Ergebnisse können rasch präsentiert werden; somit 

können Fehlentwicklungen frühzeitig aufgedeckt werden. 

Nachteil: 

Gefahr, dass aus dem Prototyp (auf Druck des Kunden) 

schnell das fertige Produkt entwickelt werden soll. Wenn 

der Prototyp dafür nicht geplant war, führt dies i.d.R. zu 

einem minderwertigen Produkt 

Quelle: Lehnert et al. 1995 S. 92f. 


Spiralmodell nach Boehm 

Quelle: zitiert in: Lehnert et al. 1995 S. 96 nach Boehm 1988 siehe auch Raasch 92, S. 414 f. 


Vorteile: 

Erweitert das Prototyping Konzept um eine risikogesteuerte 

Abbruchmöglichkeit 

Kombiniert das Wasserfallmodell und den Prototyping 

Ansatz, diese sind weiter als Spezialfälle ableitbar 

Stellt eine Anpassung der Theorie an die Realität dar 

Nachteil: 

Iteration und Parallelität werden nicht explizit unterstützt 

Anmerkung: Die Vorteile des Wasserfall- bzw. Prototyping Modells gelten 

auch für das Spiralmodell. 

Quelle: Raasch 1992 S. 414 f. 

Bewertung des Spiralmodells 


Anforderungsdefinition 

Grobentwurf 

Feinentwurf 

Modulimplementation 

V-Modell 

Anwendungsszenarien Validierung 

Abnahmetest 

Testfälle 

Testfälle 

Testfälle 

Quelle: Balzert, Lehrbuch der Software-Technik (1998), S. 101 


Systemtest 

Integrationstest 

Modultest 

Ebenen des V-Modells 

Die Strukturierung des V- Modells erfolgt anhand der Ebenen: 

Quelle: Hummel,Midderhoft: “V-Modell ´97: Das fortgeschriebene Vorgehensmodell der Bundesverwaltungen”, 

in:Gesellschaft für Informatik, 1/97, S. 39 


Verifikation 

1. Vorgehensweise (Was ist zu tun?) 

2. Methoden (Wie ist etwas zu tun?) 

3. Werkzeuganforderungen (Womit ist etwas zu tun?) 

Diese Ebenen werden jeweils den vier Submodellen des V-Modells zugeordnet: 

1. Projektmanagement 

2. Systemerstellung 

3. Qualitätssicherung 

4. Konfigurationsmanagement

Submodell “Projektmanagement” 

Ziel: Regelung der Aufgaben und Funktionen des technischen Projektmanagement 

im Entwicklungszyklus, sowie Planung, Steuerung 

und Kontrolle projektinterner Tätigkeiten, Einrichtung von 

Schnittstellen zu projektexternen Einheiten und projektinternen 

Rollen. 

Aktivitäten: • Projektinitialisierung 

• Vergabe/Beschaffung 

• Auftragnehmer-Management 

• Feinplanung 

• Kosten-/Nutzenanalyse 

• Durchführungsentscheidungen 

• Risikomanagement 

• Projektkontrolle und -steuerung 

• Berichtswesen 




Submodell “Systemerstellung” 

Ziel: Zusammenfassung aller der unmittelbaren Systementwicklung 

dienenden Aktivitäten und Entwicklungsdokumente. 

Aktivitäten: • Systemanforderungsanalyse 

• Systementwurf 

• Software- (SW) /Hardware- (HW) Anforderungsanalyse 

• SW - Grobentwurf 

• SW - Feinentwurf 

• SW - Implementierung 

• SW - Integration 

• Systemintegration 

• Überleitung in die Nutzung 



Submodell “Qualitätssicherung” 

Ziel: Regelung der Aufgaben und Funktionen der Qualitätssicherung (QS) 

innerhalb des Systementwicklungsprozesses. 

Aktivitäten: • QS-Initialisierung 

• Prüfungsvorbereitung 

• Prozeßprüfung von Aktivitäten 

• Produktprüfung 

• QS-Berichtswesen 




Submodell “Konfigurationsmanagement” 

Ziel: Eindeutige Identifikation von Produkten, Verdeutlichung der 

Zusammenhänge und Unterschiede verschiedener Versionen einer 

Konfiguration sowie Kontrolle von Produktänderungen. 

Aktivitäten: • Konfigurationsmanagement (KM) - Initialisierung 

• Produkt- und Konfigurationsverwaltung 

• Änderungsmanagement 

• KM- Dienste 




Aktivitäten und Rollen im V-Modell 

• Aktivitäten und Produkte des IT-Entwicklungs- und 

Pflegeprozesses bilden die Grundelemente des V-Modells. 

• Aktivität = Tätigkeit, die bezogen auf ihr Ergebnis und ihre 

Durchführung präzise beschrieben werden kann. 

• Produkt = Ergebnis einer Aktivität 

• Jeder Aktivität werden Rollen zugeordnet. 

• Rolle = Erfahrung, Kenntnisse und Fähigkeiten um Aktivitäten 

durchzuführen. 

• Es gibt grundsätzlich drei Rollen: 1. Manager 

2. Verantwortliche 

3. Durchführende 

Quelle: Balzert, Lehrbuch der Software-Technik (1998), S. 103-105 


Bewertung des V-Modells 

Vorteile: - Integrierte, detaillierte Darstellung von Systemerstellung, 

Qualitätssicherung, Konfigurationsmanagement und Projektmanagement. 

- Generisches Vorgehensmodell mit definierten Möglichkeiten 

zum Maßschneidern auf projektspezifische Anforderungen. 

- Standardisierte Abwicklung von Systemerstellungsprojekten. 

- Gut geeignet für große Projekte. 

Nachteile: - Unkritische Übertragung der Vorgehenskonzepte auf andere 

Anwendungstypen. 

- Unnötige Produktvielfalt und Software-Bürokratie bei kleinen 

und mittleren Softwareentwicklungen 

- Ohne geeignete CASE-Unterstützung nicht handhabbar. 

- Gefahr, daß bestimmte Software-Methoden festgeschrieben 

werden, da das V-Modell nicht methodenneutral ist 



• Der generische Architekturrahmen 

• Prinzipien des Entwurfs und der Implementierung 

im Überblick 

• Vorgehensweisen bei der IS-Modellierung 

• Datenorientiert 

• Funktionsorientiert 

• Objektorientiert 

Entwurfskonzepte 


Der generische Architekturrahmen 

Quelle: Sinz 1996, “Architektur betrieblicher Informationssystem” S. 3 


Ziele des generischen Architekturrahmen 

• Schaffung eines einheitlichen und 

durchgängigen Beschreibungsrahmens für 

Architekturen 

• Unterstützung der Kombination 

unterschiedlicher Architekturen 

• Unterstützung von Erweiterbarkeit, 

Wiederverwendbarkeit und Anpaßbarkeit 

von Architekturen 

Anmerkung: In früheren Veröffentlichungen wurde der 

Architekturrahmen als allgemeiner Architekturrahmen 

statt generische Architekturrahmen bezeichnet. 

Quelle: vgl. Sinz 1996, Vorlesung EBIS 1 


Erläuterung der Elemente 

des generischen Architekturrahmens 

• Modellebene (MM, S, P) 

Eine Modellebene umfasst eine vollständige Beschreibung eines 

Modellsystems unter einem bestimmten Blickwinkel (z.B. fachlich, 

technisch) 

• Metamodell (MM) 

Metaobjekte und Beziehungen zwischen Metaobjekten 

• Sichten S 

Projektionen auf MM. Sichten stellen Ausschnitte eines 

Modellsystems dar. Wenn Sichten durch Projektion auf ein 

integriertes Metamodell gebildet werden, bleibt der Zusammenhang 

zwischen den Sichten gewahrt. 

• Beziehungsmetamodell 

Integriertes Metamodell über den Metamodellen benachbarter 

Modellebenen. Es setzt Metaobjekte benachbarter Metamodelle 

zueinander in Beziehung. 

Quelle: Sinz 1996, “Architektur betrieblicher Informationssystem” S. 4 f. 


Beispiel für den Einsatz des generischen 

Architekturrahmens 

Quelle: vgl. Sinz 1996, Vorlesung EBIS 1 


• Grundlegende Vorgehensweisen, die beim methodischen 

Design von Informationssystemen angewendet werden 

können: 

• Top-down 

- Bsp. Abstrakte Definition aller Module vor der Implementierung 

• Bottom-up 

- Bsp. Successive Realisierung der Module, abschließende 

Zusammenführung zu einer Gesamtlösung 

• Most-critical-component first 

- Bsp. Zeitkritische Komponente zuerst realisieren, wenn die den 

Anforderungen genügt, den Rest Top-down oder Button-up 

umsetzen 

Quelle: vgl. Lehnert et al. 1995 S. 300f. 

Prinzipien des Entwurfs und 

der Implementierung 


Quelle: vgl. Lehnert et al. 1995 S. 302f. 

Top-Down / Bottom-Up 


Literatur 

• Basisliteratur 

• Sinz, Elmar J. – Architektur betrieblicher 

Informationssysteme, Bamberger Beiträge zur 

Wirtschaftsinformatik Nr. 40 (als Download verfügbar) 


Kontrollfragen 

• Wie findet sich das Prototyping-Projektmodell im 

Wasserfallmodell wieder? 

• Warum ist das klassische Wasserfallmodell für SW-Projekte nicht 

optimal? 

• Welche Aufgabe hat der generische Architekturrahmen? 

• Welcher Zusammenhang besteht zwischen einem Projektmodell 

und den Sichten bzw. Ebenen des generischen 

Architekturrahmens?

Grundlagen der Modellierung und

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?