Leif Geiger. FG Software Engineering. ! Ende der 60er Jahre. ! Idee: Ingeniersmäßige Softwareentwicklung! Softwaretechnik.

Größe: px

Ab Seite anzeigen:

Download "Leif Geiger. FG Software Engineering. ! Ende der 60er Jahre. ! Idee: Ingeniersmäßige Softwareentwicklung! Softwaretechnik."

Marie Meyer
vor 8 Jahren
Abrufe

1 Einführung Software Engineering! Motivation! Softwaretechnik! Beispiel! Kernaussagen des PMs und der QS! Vorgehensmodelle Wasserfall-Modell V-Modell Rational Unified Process! Requirements Engineering 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 LOC 50/50 Chance mehr als LOC klappt nur im Glücksfall der Markt wollte Programme > 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 1 2! Um 2000: Motivation 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 LOC klappt LOC 50/50 Chance mehr als LOC nur im Glücksfall der Markt will Programme > 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: LOC pro Tag! Nach Laprie 1999: Motivation 1/3 der Projekte wird zur Zufriedenheit der Kunden und des Anbieters durchgeführt 1/3 der Projekte überzieht Zeit und Kosten, liefert nur Teilfunktionalität, Programme instabil 1/3 der Projekte scheitert ganz 3 4

2 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 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.! 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. 6 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! 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. 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.! 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

3 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 9 Wasserfallmodell 10 V-Modell SE im V-Modell! Submodule Projektmanagement Qualitätssicherung Softwareentwicklung Konfigurations- Management! OO Softwareentwicklung! definiert Rollen! beschreibt Aktivitäten und Produkte! definiert Werkzeuge inkrementell prototypisch iterativ Use-Cases driven Architekturbeschreibung durch Klassendiagramme 11 12

4 Der Unified Process [JBR] Der Unified Process! objektorientiert! 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 Die Produkte des Requirements Capturing! Domain Model "Klassendiagramme" der Subject-, Usage- und System-World! oder besser Business Model 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,

5 Requirements Refinement 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 Die Probleme des Requirements Engineering! 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"! 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 19 20

6 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 ! Watts Humphrey: The Personel Software Process! Kent Beck: Extreme Programming Explained 21

Ähnliche Dokumente

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das