SE1 20061115 Vorgehensmodelle - Software Engineering Kassel

Leif Geiger 

Software Engineering I 

Leif Geiger 

Einführung Software Engineering 

! Motivation 

! Softwaretechnik 

! Beispiel 

! Kernaussagen des PMs und der QS 

! Vorgehensmodelle 

– Wasserfall-Modell 

– V-Modell 

– Rational Unified Process 

! Requirements Engineering 

! Um 2000: 


Motivation 

FG Software Engineering 

1 


– Leistungsfähige PCs und Server, 1GB Hauptspeicher, 1GHz CPU, 1TB 

Platten, … (Faktor 10^6 in 30 Jahren) 

– Multi-User, Multi-Tasking, LANs, Internet, GUIs, … 

– Eiffel, Java, … 

– Programmgrößen bis 1.000.000 LOC klappt 

– 10.000.000 – 30.000.000 LOC 50/50 Chance 

– mehr als 50.000.000 LOC nur im Glücksfall 

– der „Markt“ will Programme > 100.000.000 LOC (Faktor 10^3 in 30 Jahren) 

! Voraussichtlich wird sich die zu beherrschende Problemgröße alle 

3 Jahre verdoppeln 

! Bemerkung: Die „Produktivität“ der Entwickler ist nicht wesentlich 

gewachsen: 50 – 100 LOC pro Tag 

3 

Leif Geiger 

Es begab sich: 

! Ende der 60er Jahre 


Motivation 


– zentrale (Stickstoff gekühlte) Großrechner, 3kB Hauptspeicher, 1kHz CPU, 

Magnetbänder, … 

– closed-shop Betrieb mit Lochkarten, evtl. ASCII Terminals 

– Assembler, Fortran, Cobal, C, … 

– Programmgrößen bis 1000 LOC (Lines of Code) klappt 

– 10.000 – 30.000 LOC 50/50 Chance 

– mehr als 50.000 LOC klappt nur im Glücksfall 

– der „Markt“ wollte Programme > 100.000 LOC 

– einige große Firmen hatten gerade einige große Projekte in den Sand gesetzt 

– keiner wusste wie man so was macht 

! 1972 Konferenz in Garmischpartenkirchen ruft „Softwarekrise“ aus 

! Idee: Ingeniersmäßige Softwareentwicklung ! Softwaretechnik 

Leif Geiger 

! Nach Laprie 1999: 


Motivation 

– 1/3 der Projekte wird zur Zufriedenheit der 

Kunden und des Anbieters durchgeführt 

2 


– 1/3 der Projekte überzieht Zeit und Kosten, liefert 

nur Teilfunktionalität, Programme instabil 

– 1/3 der Projekte scheitert ganz 

4

Leif Geiger 


Leif Geiger 

Lösungsansätze der Softwaretechnik 

! bessere Software-Ingenieure 

! bessere Programmiersprachen 

! Objektorientierte Entwurfsmethoden 

! Bessere Werkzeuge 

! Formale Methoden 

! Wiederverwendung 

! Reengineering 

! besseres Projektmanagement ! Prozessmodelle, 

Vorgehensmodelle, Konfigurationsmanagement 

! aber: „No silver bullet“ F.Brooks, IEEE Computer 1987 


Fortsetzung Beispiel 

! Die Firma führt eine explizite Abschlusskontrolle aller Geräte vor 

Auslieferung ein. 

! Eine eigene Testabteilung prüft alle Geräte und führt gegebenenfalls 

Reparaturen durch. 

! Bei 14 % der Geräte ersetzt die neue Testabteilung kaputte Birnen. 

! Die Fehlerrate bei Kunden sinkt auf 2%. 

! Die Kundendienstabteilung kann um 87,5 % verkleinert werden. 

! Alle sind glücklich und zufrieden. 

! Nur der Absatz geht immer noch zurück. 

! Die Projektoren kosten ungefähr 50 % mehr als vergleichbare Geräte 

der Konkurrenz 


5 


! Man wirbt zu horrenden Kosten einen Mitarbeiter der Konkurrenz ab und 

stellt fest, dass die eigene Test- und Reparaturabteilung 33 % der 

Mitarbeiter beschäftigt, bei der Konkurrenz sind es nur 5 %. 

! Die meiste Zeit geht für’s Birnenwechseln drauf. 

7 

Leif Geiger 

Ein an den Haaren herbeigezogenes 

Beispiel aus der Fertigungstechnik 

(siehe [Klaus Pohl, erstes Kapitel]) 

! Eine Firma stellt Diaprojektoren her. 

! Wenn ein Kunde an einem Gerät einen Defekt feststellt, 

dann kann er das Gerät innerhalb von 14 Tagen 

anstandslos umtauschen oder reparieren lassen. 

! Die Firma ist für Kulanz und guten Kundendienst berühmt. 

! Alle sind glücklich und zufrieden. 

! Eines Tages stellt das Controlling fest, dass der Absatz 

zurückgeht. 

! Die Projektoren kosten ungefähr das Doppelte wie 

vergleichbare Geräte der Konkurrenz. 


Leif Geiger 


! Man stellt fest, dass fast die Hälfte der Kosten vom 

Kundendienst verursacht werden. Der häufigste Defekt sind 

kaputte Birnen bei 16 % der neu ausgelieferten Geräte. Ein 

Techniker fährt zum Kunden und ersetzt die Birne. 


Fortsetzung Beispiel 

! Die Firma überprüft den Mitarbeiter, der die Birnen in der Fertigung 

einbaut. 

! Direkt nach dem Einbau sind nur 1 % der Birnen defekt. 

6 


! Weitere Überprüfungen ergeben, dass die Birnen auf dem Weg von der 

Vormontage zur Gehäusemontage kaputt gehen: 

! Die Stufe im Förderband wird ausgebaut. 

! Die Fehlerrate bei der Testabteilung sinkt auf 1 %. 

! Die Testabteilung kann auf 7 % ihrer Größe verkleinert werden. 

! Alle sind glücklich und zufrieden, nur . . . 

8

Leif Geiger 


Leif Geiger 

Kernaussagen des Projektmanagements 

und der Qualitätssicherung 

! Wartung und Fehlerbehebung sind die 

Hauptkostenpunkte 

! Qualitätsverbesserung senkt die Kosten 

! Qualitätsverbesserung muss am 

Herstellungsprozess ansetzen 

(! Qualitätssicherung und Projektmanagement 

sind eigentlich das gleiche) 

! Grundlagen für die Prozessverbesserung sind: 

– Messungen, Metriken, Controlling, Prüfungen, . . . 

– klar definierte Prozesse => projektübergreifende 

Vergleichbarkeit (formale Prozessdefinition) 

– Planung und Überwachung der Prozessausführung 

– Management Commitment 

– … 


V-Modell 

! Submodule 


9 


– Projektmanagement 

– Qualitätssicherung 

– Softwareentwicklung 

– Konfigurations- 

Management 

! definiert Rollen 

! beschreibt Aktivitäten 

und Produkte 

! definiert Werkzeuge 

11 

Leif Geiger 


Leif Geiger 

! OO Softwareentwicklung 

– inkrementell 

– prototypisch 

– iterativ 

– Use-Cases driven 


Wasserfallmodell 

SE im V-Modell 

– Architekturbeschreibung durch Klassendiagramme 


10 


12

Leif Geiger 


Leif Geiger 

! objektorientiert 

Der Unified Process [JBR] 

! benutzt die UML 

! Use-Case driven 

! inkrementell und iterativ 

! Architektur basiert 

! Phasen 

– Konzeptionsphase (englisch Inception) 

– Entwurfsphase (englisch Elaboration) 

– Konstruktionsphase (englisch Construction) 

– Übergabephase (englisch Transition) 

! Arbeitsschritte ähnlich dem Wasserfallmodell 

! beschreibt Rollen / Aktivitäten / Dokumente / Produkte 


Requirements Capturing 


13 


15 

Leif Geiger 


Leif Geiger 

Der Unified Process 

Die Produkte des Requirements Capturing 

! Domain Model 

– "Klassendiagramme" der Subject-, Usage- und System-World 

! oder besser Business Model 



14 


– vollständige Modellierung (Klassendiagramme plus 

Verhaltensspezifikationen) der Subject-, Usage- und System-World 

! Feature List 

– funktionale Anforderungen (meist textuell): 

– Was soll die neue Software in unseren Business Abläufen 

automatisieren? 

! Supplementary Requirements 

– nichtfunktionale Anforderungen 

– Antwortzeiten, Verfügbarkeit, Resourcenbedarf, . . . 

16

Leif Geiger 


Leif Geiger 


Requirements Refinement 

Die Probleme des Requirements 

Engineering 


17 


! Der Kunde weiß im allgemeinen nicht was er 

will 

! "Den Kunden" gibt es eigentlich nicht, 

unterschiedliche Interessensgruppen auf 

Kundenseite 

! Business Model meist nicht vorhanden 

! Einzelne Kundenvertreter kennen oft nur 

Ausschnitt des eigenen Business Models 

! Das Business Model ist ein "Moving Target" 

19 

Leif Geiger 

Die vier Welten des Requirements 

Engineering 

! Subject World 

– Modell der Anwendungsdomäne 

– die Daten / Vorgänge die verwaltet / bearbeitet werden sollen 

! Usage World 

– Wer sind die Anwender des geplanten Softwaresystems 

– Was sind die Aufgaben, die die Anwender bearbeiten 

! System World: 

– bestehende Software und ihre Doku und ihre Entwicklungsgeschichte 

! Development World: 

– "Entwicklunswelt". Hier wird die neue Software entwickelt 

– fertige Produkte wandern aus der Entwicklungswelt in die Systemwelt 

Aufgabe des Requirements Engineering ist die präzise Modellierung 

aller 4 Welten. 


Leif Geiger 

! Berater / Consultants vor 


Lösungsansätze 

– Experten in der Erstellung von Business Models 

– das alleine ist früher oft gescheitert 

! Vertreter vor 

– dem Kunden passendes Problem zum eigenen Produkt einreden 

! Iterative Prozesse 

– erste Teilfunktionalitäten werden früh vom Kunden evaluiert 

! eXtreme Programming 

– Kunde definiert Anforderungen selbst 

– Kunde formalisiert Anforderungen mittels Tests 

– Kunde priorisiert Anforderungen 

– Kunde evaluiert jede Teilfunktionalität sofort 

– Kunde hat im Zweifel selber Schuld 


18 


20

Leif Geiger 

Literatur zu Vorgehensmodellen 

! Grady Booch, James Rumbaugh, Ivar Jacobson: 

The Unified Software Development Process, 

Addison Wesley 1999 (relativ wichtiges 

Standardwerk) 

! Jochen Seemann, Jürgen Wolff von Gudenberg: 

Software Entwurf mit UML; Springer 2000 (finde 

ich ziemlich gut) 

! Klaus Pohl: Process Centered Requirements 

Engineering; Wiley, 1996, ISBN 0 86380 193 5 



! Watts Humphrey: The Personel Software Process 

! Kent Beck: Extreme Programming Explained 

21

SE1 20061115 Vorgehensmodelle - Software Engineering Kassel

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?