fachgebiet software engineering Übersicht © 23.01.2014 albert zündorf, kassel university...

Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University

Vorgehensmodelle

Motivation

Softwaretechnik

Beispiel

Kernaussagen des PMs und der QS

Vorgehensmodelle Wasserfall-Modell V-Modell Rational Unified Process

Requirements Engineering


Motivation

Nach Laprie 1999: 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


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


Wasserfallmodell


SE im V-Modell

OO Softwareentwicklung inkrementell prototypisch iterativ Use-Cases driven Architekturbeschreibung durch Klassendiagramme


V-Modell

Submodule Projektmanagement Qualitätssicherung Softwareentwicklung Konfigurations-

Management

definiert Rollen

beschreibt Aktivitäten und Produkte

definiert Werkzeuge


Der Unified Process [JBR]

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


Der Unified Process


Requirements Capturing


Requirements Refinement


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"


Lösungsansätze

Berater / Consultants vor 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


Qualitätssicherung: Ein an den Haaren herbeigezogenes Beispiel

(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.


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 . . .


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 …


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

fachgebiet software engineering Übersicht © 23.01.2014 albert zündorf, kassel university...

Documents