Softwaretechnik ¨Uberblick I - Informatik - FB3

Transcription

Softwaretechnik
Prof. Dr. Rainer Koschke
Fachbereich Mathematik und Informatik
Arbeitsgruppe Softwaretechnik
Universität Bremen
Wintersemester 2011/12
Überblick I
Entwicklungsprozesse
Entwicklungsprozesse:
Lernziele
Wasserfallmodell
V-Modell
Testgetriebene Entwicklung
Inkrementelle Entwicklung
Spiralmodell
Rational Unified Process
Cleanroom Development
Agile Methoden
Extreme Programming (XP)
Scrum
Agile versus traditionelle Vorgehensweisen
Capability Maturity Model
Persönlicher Softwareprozess
Wiederholungsfragen
Weiterführende Literatur
Entwicklungsprozesse: Lernziele
Lernziele
verschiedene Software-Entwicklungsprozessmodelle kennen
Vor- und Nachteile/Anwendbarkeit abwägen können
die Besonderheit von Prozessen der Software-Entwicklung
kennen
Entwicklungsprozesse: Lernziele
Grundlagen für guten Prozess:
Wohldefiniertheit
sonst Falsch-, Nicht-, Mehrarbeit
sonst Information nicht verfügbar oder unverständlich
Quantitatives Verstehen
objektive Grundlage für Verbesserungen
Kontinuierliche Änderung
sonst Prozess schnell überholt
Angemessenheit
Prozess muss dem zu lösenden Problem angemessen sein
d.h. effektiv und effizient sein
Entwicklungsprozesse: Wasserfallmodell
Striktes Wasserfallmodell nach Royce (1970)
System−
analyse
Ist−Zustand
System−
spezifikation
System−
entwurf
Anforderungen
SW−Architektur
Modulspez.
und −entwurf
Modul−
spezifikation
Codierung
Modultest
Programmteile
(isoliert getestet)
Programm
Zeit
Integration u.
Systemtest
Einsatz u.
Wartung
2011-10-30
Softwaretechnik
Wasserfallmodell
System−
analyse
Ist−Zustand
System−
spezifikation
System−
entwurf
Anforderungen
SW−Architektur
Modulspez.
und −entwurf
Modul−
spezifikation
Codierung
Modultest
Programmteile
(isoliert getestet)
Integration u.
Systemtest
Programm
Zeit
Hier sehen wir als Beispiel das strikte Wasserfallmodell. Es enthält alle Aktivitäten in streng sequenzieller Folge.
Dieses Modell eignet sich, wenn die Arbeitsschritte deutlich voneinander getrennt werden können. Alle Risiken
müssen vor Projektbeginn ausgeschlossen werden können. Es ist geeignet, wenn die Mitarbeiteranzahl klein ist, da
alle Mitarbeiter gleichzeitig an einem Arbeitsschritt arbeiten können.
Dieses Modell ist für die allermeisten Aufgabenstellung jedoch unrealistisch. Es setzt voraus, dass jede Aktivität auf
Anhieb erfolgreich abgeschlossen werden kann. Allerdings werden z.B. die Anforderungen oft auch noch in späten
Phasen des Projekts geändert bzw. erst dann überhaupt erst richtig verstanden. Dann müssen frühe Aktivitäten
wiederholt werden.
Entwicklungsprozesse: Wasserfallmodell
Striktes Wasserfallmodell Royce (1970)
Eigenschaften dieses Modells:
dokumenten-getrieben: jede Aktivität erzeugt Dokument
streng sequenzielle Aktivitäten
+ klar organisierter Ablauf
+ relativ einfache Führung
+ hohe Qualität der Dokumentation
– Entwicklung bildet langen Tunnel
– 90%-fertig-Syndrom
– Spezifikationsmängel lassen sich kaum frühzeitig erkennen
– Entwicklung beim Kunden wird ignoriert
Einsatz u.
Wartung
Entwicklungsprozesse: V-Modell
V-Modell von Boehm (1979)
Zeit
Konzept
Anwendung &
Support
Konzeptvalidierung
Projektplan &
Anforderungen
Installation &
Betriebstest
Anforderungen
Baseline
Validierung
Verifikation
System−
entwurf
Akzeptanztest
Modul−
entwurf
2011-10-30
Code
Softwaretechnik
V-Modell
Integration &
Systemtest
Klassen−
test
Zeit
Konzept
Anwendung &
Support
Konzeptvalidierung
Projektplan &
Anforderungen
Installation &
Betriebstest
Anforderungen
Baseline
Validierung
Verifikation
System−
entwurf
Akzeptanztest
Modul−
entwurf
Code
Integration &
Systemtest
Klassen−
test
Das V-Modell ist kein eigenständiges Prozessmodell im eigentlichen Sinn. Die Produkte im V-Modell werden wie im
Wasserfallmodell streng sequenziell erstellt. Es fügt dem Wasserfallmodell lediglich eine zusätzliche strukturelle
Sicht hinzu, nämlich dass für jedes zu erstellende Dokument ein entsprechender Test existieren und durchgeführt
werden soll.
Das V-Modell sieht sowohl Verifikationen als auch Validierungen vor. Validierung: Es wird das richtige Produkt
erstellt. Verifikation: Das Produkt wird richtig erstellt.
Eine weitere Konsequenz des V-Modells für die konkrete Projektplanung ist, dass man die Test- und
Validierungsaktivitäten früher als die tatsächliche Durchführung der Aktivität vorbereiten kann. Beispielsweise kann
der Akzeptanztest vorbereitet werden, sobald man die Anforderungen kennt. Auf diese Weise können Aktivitäten
bei einem Projektteam parallelisiert werden: Der Tester kann Testfälle für den Akzeptanztest entwickeln, auch wenn
noch keine Implementierung existiert.
Entwicklungsprozesse: V-Modell
Eigenschaften:
entspricht Wasserfallmodell
+ betont Qualitätssicherung
+ frühe Vorbereitung von Validierung und Verifikation
zusätzliche Parallelisierung
Fehler/Mängel werden früher entdeckt
– alle sonstigen Nachteile des Wasserfallmodells
Entwicklungsprozesse: Testgetriebene Entwicklung
Testgetriebene Entwicklung (Sneed 2004)
Kennzeichen testgetriebener Entwicklung:
Testfälle . . .
werden früh aus Anwendungsfällen abgeleitet
dienen als Baseline
treiben den Entwurf
treiben die Kodierung
Test-Teams treiben die Entwicklung, statt von Entwicklern
getrieben zu werden
Anwendungs- und Testfälle
Anwendungsfälle beschreiben Anforderungen
sind jedoch oft nicht detailliert genug, um erwartetes
Verhalten vollständig zu spezifizieren
Testfälle können Anwendungsfälle hier komplementieren
zu jedem Anwendungsfall sollte es mindestens einen Testfall
geben
Testfälle können zur Kommunikation zwischen Entwickler und
Kunden/Anwender dienen
Testfälle dienen als Baseline:
definieren die Vorbedingungen einer Produktfunktion
spezifizieren die Argumente einer Produktfunktion
spezifizieren das Verhalten einer Produktfunktion (die
Nachbedingungen)
Testfälle treiben den Entwurf:
Testfall ist ein Pfad durch die Software-Architektur
Testfälle verknüpfen Anforderungsspezifikation und
Architekturkomponenten
Testfälle können zur Studie der zu erwartenden Performanz
und anderer Systemattribute zur Entwurfszeit verwendet
werden
Testfälle treiben die Kodierung:
vor Implementierung einer Klasse werden erst Testtreiber
entwickelt
Testtreiber enthält mindestens einen Test für jede nichttriviale
Methode
Testfall hilft, die richtige Schnittstelle zu definieren
Testfall zwingt Entwickler, über das zu erwartende Resultat
nachzudenken
Testfälle spezifizieren die Methoden zumindest partiell
Tester treiben die Entwicklung:
Tester sind verantwortlich für die Auslieferung des Produkts
Tester legen Kriterien für die Auslieferbarkeit fest
Entwickler sind Lieferanten für die Tester
Softwareentwicklung ist eine Versorgungskette; das Ende
zieht, anstatt gedrückt zu werden
Entwicklungsprozesse: Inkrementelle Entwicklung
Bewusstseinsebenen
bewusstes Wissen (20-30%)
Wissen, über das man sich im Klaren ist oder das in seiner
vollen Bedeutung klar erkannt wird
unbewusstes Wissen (≤40%)
Wissen, das sich dem Bewusstsein im Moment nicht darbietet,
aber dennoch handlungsbestimmend ist, und potenziell
aufgerufen werden kann
unterbewusstes Wissen
unbekannte Wünsche, die erst von außen herangetragen
werden müssen, um als Anforderungen erkannt zu werden
2011-10-30
Bewusstseinsebenen
Softwaretechnik
bewusstes Wissen (20-30%)
Wissen, über das man sich im Klaren ist oder das in seiner
vollen Bedeutung klar erkannt wird
unbewusstes Wissen (≤40%)
Wissen, das sich dem Bewusstsein im Moment nicht darbietet,
aber dennoch handlungsbestimmend ist, und potenziell
aufgerufen werden kann
Bewusstseinsebenen
unterbewusstes Wissen
unbekannte Wünsche, die erst von außen herangetragen
werden müssen, um als Anforderungen erkannt zu werden
• bewusst: will mit meinem Handy telefonieren
• unbewusst: Tastatur und Display sollen auf derselben Seite meines Handys sein
• unterbewusst: ich will SMS verschicken können
Basisfaktoren
Minimalanforderungen
→ Mangel führt zu massiver
Unzufriedenheit
→ mehr als Zufriedenheit ist nicht
möglich
Kano-Modell
Kunde sehr zufrieden,
begeistert
Begeisternde
Faktoren
Leistungsfaktoren
Leistungs−
faktoren
bewusst verlangte
Sonderausstattung
Erfüllungsgrad
→ bei Erfüllung: Kundenzufriedenheit
→ sonst: Unzufriedenheit
Erwartungen
nicht erfüllt
Basisfaktoren
Begeisternde Faktoren
unbewusste Wünsche,
nützliche/angenehme
Überraschungen
→ steigern Zufriedenheit
überproportional
Kunde unzufrieden
enttäuscht
Kosten für Änderungen
Kosten für Änderung
60 − 100 x
1,5 − 6 x
1x
Zeit
Definition Entwicklung nach Auslieferung
Pressman (1997)
Inkrementelles Modell von Basili und Turner (1975)
Analyse
Auslieferung
des 1. Inkrement
Entwurf
Codierung
Test
Analyse
Entwurf
Codierung
Test
Analyse
Entwurf
Codierung
Test
Analyse
Entwurf
Codierung
Auslieferung
des 2. Inkrement
Auslieferung
des 3. Inkrement
Test
Auslieferung
des 4. Inkrement
2011-10-30
Softwaretechnik
Analyse
Auslieferung
des 1. Inkrement
Entwurf
Codierung
Test
Analyse
Entwurf
Codierung
Test
Analyse
Entwurf
Codierung
Test
Analyse
Entwurf
Codierung
Auslieferung
des 2. Inkrement
Das Wasserfallmodell geht davon aus, dass alle Anforderungen zu Beginn erfasst werden können und diese während
des Projekts stabil bleiben. Dies ist in der Praxis selten der Fall.
Im Laufe des Projekts gewinnen die Entwickler ein besseres Verständnis der Anwendungsdomäne und entdecken
Irrtümer in ihren ursprünglichen – oft nur impliziten – Annahmen. Ähnlich wird auch der Kunde sich oft erst im
Laufe des Projekts im Klaren, was er eigentlich erwarten kann und will. Auch die Rahmenbedingungen, unter denen
das Projekt startete, können sich ändern (z.B. Gesetze oder Normen).
Die Anforderungen sind also selten stabil. Damit wird das Wasserfallmodell in seiner strikten Auslegung fragwürdig.
Allerdings hat auch schon der Erfinder des Wasserfallmodells, Royce, empfohlen, das System zweimal zu
entwickeln. Das erste Mal, um überhaupt erst Anforderungen und mögliche Lösungen auszuloten. Das zweite Mal,
um ein adäquates und qualitativ hochwertiges Produkt zu erstellen.
Das inkrementelle Modell führt diesen Gedanken fort. Anstatt auf die Fertigstellung der gesamten Anforderungen
zu warten, werden – sobald eine ausreichende Anzahl von Kernanforderungen beschrieben ist – für diese ein
Entwurf und die Implementierung gestattet. Je mehr Anforderungen hinzukommen, desto mehr zusätzliche
Inkremente werden gestartet.
Das inkrementelle Modell ist gut geeignet, wenn Kunde die Anforderungen noch nicht vollständig überblickt bzw.
sich der Möglichkeiten zur Realisierung der Anforderungen nicht bewusst ist und deshalb die Anforderungen nicht
formulieren kann.
Es ist mit diesem Modell möglich, Teile des Systems bereits vor Fertigstellung des gesamten Systems beim Kunden
einzuführen (z.B. ein oder mehrere Subsysteme). Mit diesen Teilen kann der Kunde eine eingeschränkte Anzahl an
Anforderungen realisieren. Die Zeitspanne zwischen Auftragsvergabe und Einsatz von zumindest Systemteilen wird
somit geringer.
Federt die Gefahr des Wasserfallmodells ab, am Ende mit leeren Händen dazustehen. Sind wenigstens die ersten
Inkremente erfolgreich entstanden, hat der Kunde zumindest ein partielles System.
Während der Entwicklung kann noch auf Änderungen reagiert werden.
Das Modell steht und fällt mit der Möglichkeit, Kernanforderungen zu identifizieren und ausreichend zu
spezifizieren. Die initale Software-Architektur muss für alle Anforderungen – Kernanforderungen wie alle anderen,
die im Laufe des Projekts formuliert werden – tragfähig sein; ansonsten ist ein hoher Restrukturierungaufwand
notwendig. Darum sollten am Anfang alle Anforderungen bekannt sein, die sich maßgebend auf die Architektur
auswirken.
Beispiel für Textverarbeitung
Iterationen:
1
grundlegende Funktionalität
Datei-Management, Editor, Textausgabe
2
erweiterte Funktionalität
Style-Files, Bearbeitung mathematischer Formeln, Einbinden
von Graphiken
3
zusätzliche Funktionalität
Rechtschreibprüfung, Grammatiküberprüfung,
Überarbeitungsmodus
4
ergänzende Funktionalität
Tabellenkalkulation, Geschäftsgraphiken, E-Mail,
Web-Browser, Scanner-Anbindung, Flipper
Auslieferung
des 3. Inkrement
Test
Auslieferung
des 4. Inkrement
Eigenschaften:
Wartung wird als Erstellung einer neuen Version des
bestehenden Produkts betrachtet.
+ Entwicklung erfolgt stufenweise
brauchbare Teillösungen in kurzen Abständen
+ Lernen durch Entwicklung und Verwendung des Systems.
+ Gut geeignet, wenn Kunde Anforderungen noch nicht
vollständig überblickt oder formulieren kann.
”‘I know it when I see it”’
– Kernanforderungen und Architekturvision müssen vorhanden
sein.
– Entwicklung ist durch existierenden Code eingeschränkt.
Vergleich inkrementelles Modell und Wasserfallmodell
Entwicklungsprozesse: Spiralmodell
Spiralmodell von Boehm (1988)
2011-10-30
Mehrere Iterationen der folgenden Schritte:
1
Bestimmung der Ziele und Produkte des Durchlaufs;
Berücksichtigung von Alternativen (z.B. Entwurfsvarianten)
und Restriktionen (z.B. Zeitplan)
2
Bewertung der Risiken für alle Alternativen; Entwicklung
von Lösungsstrategien zur Beseitigung der Ursachen
3
Arbeitsschritte durchführen, um Produkt zu erstellen
4
Review der Ergebnisse und Planung der nächsten Iteration
Softwaretechnik
Spiralmodell
Mehrere Iterationen der folgenden Schritte:
1
Bestimmung der Ziele und Produkte des Durchlaufs;
Berücksichtigung von Alternativen (z.B. Entwurfsvarianten)
und Restriktionen (z.B. Zeitplan)
2
Bewertung der Risiken für alle Alternativen; Entwicklung
von Lösungsstrategien zur Beseitigung der Ursachen
3
Arbeitsschritte durchführen, um Produkt zu erstellen
4
Review der Ergebnisse und Planung der nächsten Iteration
Das Spiralmodell kann für sehr große und komplexe Projekte verwendet werden, da es der Komplexität durch das
risikogesteuerte Vorgehen Rechnung trägt. Die Anzahl der Durchläufe ergibt sich erst während des Projekts und
wird durch die auftetenden Risiken bestimmt. Dies hat zur Folge, dass zu Beginn des Projekts ein Zeit- und
Kostenplan nur schwer zu erstellen ist. Die Risikoanalyse kann nur durch erfahrene Projektleiter durchgeführt
werden. Bei zu zaghaftem Vorgehen kann sich das Projekt unnötigerweise verlängern, was zu erhöhten Kosten
führt. Zu schnelles Vorgehen kann Risiken vernachlässigen und zu Problemen in folgenden Durchläufen führen.
Beispiel eines Spiralmodells
(Generische) Risiken:
Ist das Konzept schlüssig? Kann es aufgehen?
Was sind die genauen Anforderungen?
Wie sieht ein geeigneter Entwurf aus?
Beispiel eines Spiralmodells mit vier Durchläufen
1. Bestimme Ziele,
Alternativen,
Restriktionen
Bewerte Alternativen,
2.
identifiziere und
beseitige Risiken
Kosten
Fo
rts
ch
rit
t
Risikoanalyse
Risikoanalyse
Risikoanalyse
Zustim−
mung
durch
Reviews
Risiko−
analyse
Start
P1
Anford.plan, Konzept
Lebenszykl. für
plan
Betrieb
Proto−
Proto−
typ 3
typ 2
Anforde−
Fein−
rungs− Produkt− entwurf
entwurf
def.
Entwicklungs−
Anforderungs−
plan
plan
Integration
und Testplan
Entwurfs−
prüfung
4.
Plane die
nächste Phase
Codieren
Modultest
Integration
und Test
Verbesserungsplan
Abnahme−
test
betriebs−
fähiger
Prototyp
3.
Entwickle das Produkt,
prüfe die nächste
Produktstufe
Bewertung Spiralmodell
Meta-Modell: Iterationen können beliebigen Modellen folgen
+ bei unübersichtlichen Ausgangslagen wird die Entwicklung in
einzelne Schritte zerlegt, die jeweils unter den gegebenen
Bedingungen das optimale Teilziel verfolgen
– schwierige Planung (was jedoch dem Problem inhärent ist)
– setzt große Flexibilität in der Organisation und beim Kunden
voraus
Entwicklungsprozesse: Rational Unified Process
Rational Unified Process (RUP) nach Gornik (2001)
Phasen
Konzeption
Iterationen
Initial
Aktivitäten
Elaboration
Elab. 1
Elab. 2
Konstruktion
Konst. 1
Konst. 2
Übergabe
Konst 3.
Domänen−
analyse
Überg. 1
Auslieferung
Anforderungs−
analyse
Entwurf
Test
Implementierung
Überg. 2
Zeit
Geschäftsmodellierung
/ Domänenanalyse
Anforderungsanalyse
Entwurf
Implementierung
Test
Auslieferung
Konfigurations−
/ Änderungsmanagement
Projektmanagement
Infrastruktur
2011-10-30
Aktivitäten
Softwaretechnik
Zeit
Geschäftsmodellierung
/ Domänenanalyse
Anforderungsanalyse
Entwurf
Implementierung
Test
Auslieferung
Konfigurations−
/ Änderungsmanagement
Projektmanagement
Infrastruktur
Aktivitäten
Der Rational Unified Process (RUP) – als Konkretisierung des Unified Process der Firma Rational – ist ein weiteres
inkrementelles Modell.
Der Prozess insgesamt gliedert sich in vier Phasen mit einer unterschiedlichen Anzahl von Iterationen. Das Produkt
jeder Phase unterscheidet sich von den Produkten anderer Phasen.
Die Konzeptionsphase (Inception) erarbeitet die Anforderungen. Die Elaborationsphase (Elaboration) erstellt einen
Entwurf. Die Konstruktionsphase (Construction) erstellt das implementierte System. Die Übergabephase
(Transition) führt das System beim Kunden ein.
Jede Iteration gliedert sich in die Aktivitäten Geschäftsmodellierung, Anforderungsanalyse, Entwurf,
Implementierung, Test und Auslieferung. Jede Iteration wird durch ein formales Review abgeschlossen.
Die Ausprägung der einzelnen Aktivitäten ist phasenabhängig. In der Konzeptphase z.B. dient eine
Implementierung lediglich einem Konzeptbeweis (Machbarkeit kritischer Anforderungen) oder einer Demonstration
(ein Benutzerschnittstellenprototyp). Es genügt hierfür eine weniger aufwändige, prototypische Implementierung
(der Prototyp sollte anschließend weggeworfen werden!).
Der Aufwand jeder Aktivität variiert also in den Phasen. Dies wird durch die Kurven im Schaubild veranschaulicht.
Die Geschäftsmodellierung beispielsweise erzeugt in der Konzeptionsphase naturgemäß einen hohen Aufwand, hat
in der Übergabephase aber keine Bedeutung mehr. Alle Flächen gemeinsam ergeben den Gesamtaufwand des
Projekts. Die Summe der Flächen pro Spalte ist der Aufwand pro Iteration. Die Summe der Flächen pro Zeile ist
der Aufwand pro Aktivität.
Die Hauptaktivitäten sind Geschäftsmodellierung (optional), Anforderungsanalyse, Entwurf, Implementierung, Test,
Auslieferung. Die Geschäftsmodellierung dient dazu, eine gemeinsame Sprache für die unterschiedlichen Gruppen
Softwareentwickler und Betriebswirte zu finden und die Software-Modelle auf die zugrunde liegenden
Geschäfsmodelle zurückzuführen. Die Geschäftsprozesse werden durch so genannte Geschäfts-Anwendungsfälle
dokumentiert. Sie zielen darauf ab, ein gemeinsames Verständnis, welche Geschäftsprozesse in der Organisation
unterstützt werden sollen, aller Beteiligten zu erreichen. Die Geschäfts-Anwendungsfälle werden analysiert, um zu
verstehen, wie die Geschäftsprozesse unterstützt werden sollen.
RUP: Konzeptionsphase (Inception)
Ziel: “Business-Case” erstellen und Projektgegenstand abgrenzen.
Resultate:
Vision der Hauptanforderungen, Schlüsselfeatures und
wesentliche Einschränkungen
initiale Anwendungsfälle (10-20% vollständig)
Glossar oder auch Domänenmodell
initialer Business-Case: Geschäftskontext, Erfolgskriterien
(Schätzung des erzielten Gewinns, Marktanalyse etc.) und
Finanzvorschau
initiale Risikobetrachtung
Projektplan mit Phasen und Iterationen
Business-Modell falls notwendig
2011-10-30
ein oder mehrere Prototypen
Softwaretechnik
Ziel: “Business-Case” erstellen und Projektgegenstand abgrenzen.
Resultate:
Vision der Hauptanforderungen, Schlüsselfeatures und
wesentliche Einschränkungen
initiale Anwendungsfälle (10-20% vollständig)
Glossar oder auch Domänenmodell
initialer Business-Case: Geschäftskontext, Erfolgskriterien
(Schätzung des erzielten Gewinns, Marktanalyse etc.) und
Finanzvorschau
initiale Risikobetrachtung
Projektplan mit Phasen und Iterationen
Business-Modell falls notwendig
ein oder mehrere Prototypen
Begleitende Aktivitäten sind das Konfigurations- und Änderungsmanagement und das Projektmanagement. Ihr
Aufwand ist in allen Phasen mehr oder minder gleich. Der Aufwand für das Konfigurations- und
Änderungsmanagement zeigt leichte Peaks im Übergang von einer Phase zur anderen, wenn die Konfigurationen
fest gezurrt werden und zum Teil nachgearbeitet werden muss.
Dem Glossar kommt eine ganz besondere Bedeutung zu. Es erklärt die Begriffe der Anwendungsdomäne.
Software-Entwickler sind Spezialisten für die Entwicklung von Software, aber Laien in sehr vielen ihrer
Anwendungsdomänen. Darüber hinaus verwenden auch Kunden oft die Begriffe uneinheitlich bzw. geläufige Worte
mit einer ganz speziellen Bedeutung in ihrem Kontext. Mißverständnisse zwischen Kunden und Softwareentwickler
sind sehr häufig und können zu teuren Fehlentwicklungen führen.
Eine Marssonde, bei deren Entwicklung europäische und amerikanische Organisationen mitwirkten, verfehlte ihr
Ziel, weil den Organisationen nicht bewusst war, dass sie unterschiedliche metrische Systeme für ihre Software
zugrunde legten. Die einen interpretierten einen Wert in Zentimetern, die anderen in Zoll (Inch).
Im Glossar beschreibt der Software-Entwickler, was die Begriffe des Kunden bedeuten, ebenso wie seine eigenen
speziellen Begriffe. Der Kunde begutachtet das Glossar. Damit definieren beide Partein ihr Vokabular.
Mißverständnisse sollen so minimiert werden.
Das Domänenmodell (oft auch konzeptuelles Modell genannt) beschreibt die Begriffe/Objekte der
Anwendungsdomäne und ihre Relationen.
Eine Reihe der genannten Punkte wird sicherlich in Zusammenarbeit mit Betriebswirten ausgearbeitet.
Softwareentwickler haben eine Liebe zur Technologie, übersehen jedoch leider oft die Wirtschaftlichkeit ihrer Ideen.
Mit ihr steht und fällt jedoch das Projekt.
Die Erstellung von Prototypen hat das Ziel, mögliche technologische Risiken auszuschließen, dem Kunden ein
konkretes Bild der möglichen Anwendung zu vermitteln (Benutzerschnittstellenprototyp), Anforderungen zu
konkretisieren (“I know it when I see it”) und die Machbarkeit bestimmter Anforderungen zu demonstrieren.
Das Business-Modell erläutert, wie das System eingesetzt wird, um damit Profite zu erzielen.
RUP: Elaborationsphase (Elaboration)
Ziel: Verständnis der Anwendungsdomäne, tragfähige
Software-Architektur, Projektplan, Eliminierung der Risiken
Anwendungsfallmodell (mind. 80% fertig)
alle Anwendungsfälle und Aktoren sind identifiziert,
die meisten Anwendungsfallbeschreibungen wurden entwickelt
zusätzliche nichtfunktionale Anforderungen und
Anforderungen, die nicht mit einem spezifischen
Anwendungsfall assoziiert sind
Beschreibung der Software-Architektur
2011-10-30
ausführbarer Architekturprototyp
Softwaretechnik
Ziel: Verständnis der Anwendungsdomäne, tragfähige
Software-Architektur, Projektplan, Eliminierung der Risiken
Anwendungsfallmodell (mind. 80% fertig)
alle Anwendungsfälle und Aktoren sind identifiziert,
die meisten Anwendungsfallbeschreibungen wurden entwickelt
zusätzliche nichtfunktionale Anforderungen und
Anforderungen, die nicht mit einem spezifischen
Anwendungsfall assoziiert sind
Beschreibung der Software-Architektur
ausführbarer Architekturprototyp
Die Elaborationsphase ist die kritischste Phase. Hier entscheidet sich, ob das System tatsächlich gebaut wird. Der
Engineering-Anteil ist weitgehend erbracht. Bis dahin halten sich die Kosten noch in Grenzen. Nun schließen sich
die teure Konstruktions- und Übergabephase an.
Die Aktivitäten der Elaborationsphase stellen sicher, dass die Software-Architektur, die Anforderungen und Pläne
hinreichend stabil sind (mögliche Änderungen sind antizipiert, völlig ausschließen lassen sie sich meist nicht) und
Risiken sind ausreichend betrachtet, so dass Kosten und Zeitplan zuverlässig geschätzt werden können. Ab hier
sollte man sich auf eine Projektdurchführung mit festem Preis einlassen können.
In der Elaborationsphase wird ein ausführbarer Architekturprototyp in ein oder mehr Iterationen erstellt. Die Anzahl
der Iterationen hängt vom Scope, der Größe, der Risiken und dem Grad des Unbekannten des Projekts ab.
Zumindest die kritischen Anwendungsfälle sollten hierfür einbezogen werden, da sie typischerweise die größten
technischen Risiken aufwerfen. Ein evolutionärer Prototyp (d.h. einer der schrittweise ausgebaut wird) kann
durchaus verwendet werden. Man sollte jedoch auch einige explorative Wegwerfprototypen in Erwägung ziehen, um
spezifische Risiken wie z.B. Entwurfs- oder Anforderungskompromisse auszuloten. Sie dienen auch als
Machbarkeitsstudien und Demonstrationen.
RUP: Elaborationsphase (Elaboration); Fortsetzung
überarbeitete Liste der Risiken und überarbeiteter
Business-Case
Plan für das gesamte Projekt sowie grober Plan für die
Iterationen und Meilensteine
2011-10-30
ein vorläufiges Benutzerhandbuch (optional)
Softwaretechnik
überarbeitete Liste der Risiken und überarbeiteter
Business-Case
Plan für das gesamte Projekt sowie grober Plan für die
Iterationen und Meilensteine
ein vorläufiges Benutzerhandbuch (optional)
Die Erstellung des Benutzerhandbuchs kann bereits frühzeitig beginnen. Es ist konkreter als die
Anforderungsspezifikation und abstrakter als die Implementierung. Somit kann es als Brücke von den
Anforderungen zur Implementierung benutzt werden.
Das vorläufige Handbuch dient sowohl als Spezifikation für die Implementierung und den Test als auch für die
intensivere Auseinandersetzung mit der Benutzerführung (Beispiel: Was orthogonal und einfach zu beschreiben ist,
kann oft auch orthogonal und einfach implementiert werden). Überlegungen zur Benutzerführung sollten frühzeitig
gemacht werden, weil Änderungen größere Restrukturierungen nach sich ziehen können.
RUP: Konstruktionsphase (Construction)
Ziel: Fertigstellung, Integration und Test aller Komponenten;
auslieferbares Produkt.
Software-Produkt integriert in die entsprechende Plattform
Benutzerhandbuch
2011-10-30
Dokumentation des gegenwärtigen Releases
Softwaretechnik
Ziel: Fertigstellung, Integration und Test aller Komponenten;
auslieferbares Produkt.
Software-Produkt integriert in die entsprechende Plattform
Benutzerhandbuch
Dokumentation des gegenwärtigen Releases
In der Konstruktionsphase werden alle übrigen Komponenten und Feature realisiert und in das Produkt integriert
und intensiv getestet. Die Konstruktionsphase ist einem gewissen Sinne ein Herstellungsprozess, bei dem Wert auf
das Management von Ressourcen und das Controlling gelegt wird, um Kosten, Zeitplan und Qualität zu optimieren.
In diesem Sinne geht der Prozess nun von der intellektuellen Entwicklung zur Entwicklung auslieferbarer Produkte
über.
Viele Projekte sind groß genug, um die Konstruktion zu parallelisieren. Die Parallelisierung kann die Verfügbarkeit
auslieferbarer Releases beschleunigen. Andererseits kann sie auch die Komplexität der Ressourcenverwaltung und
der Synchronisation der Arbeitsflüsse erhöhen.
Eine robuste Architektur und ein verständlicher Plan hängen stark zusammen. Deshalb ist eine kritische Qualität
der Architektur die Einfachheit ihrer Konstruktion. Dies ist einer der Gründe, weshalb die ausgeglichene
Entwicklung der Architektur und des Plans während der Elaborationsphase so sehr betont wird.
Das Resultat der Konstruktionsphase ist ein Produkt, das tatsächlich in die Hände des Benutzers übergehen kann.
RUP: Übergabephase (Transition)
Ziel: Produkt wird der Benutzergemeinde übergeben.
Hauptziele im Einzelnen:
Benutzer sollten sich möglichst alleine zurecht finden.
Beteiligte sind überzeugt, dass die Entwicklungs-Baselines
vollständig und konsistent mit den Evaluationskriterien für die
Vision sind.
Erreichung der letzten Produkt-Baseline so schnell und
kostengünstig wie möglich.
Typische Tätigkeiten:
“Beta-Test”, um das neue System gegen die
Benutzererwartungen zu validieren
Parallele Verwendung mit einem Legacy-System, das durch
das Produkt ersetzt werden soll
Konversion aller notwendigen Daten (Dateien und
Datenbanken)
Schulung aller Benutzer und Administratoren
Übergabe an Marketing, Vertrieb und Verkäufer
2011-10-30
Softwaretechnik
Typische Tätigkeiten:
“Beta-Test”, um das neue System gegen die
Benutzererwartungen zu validieren
Parallele Verwendung mit einem Legacy-System, das durch
das Produkt ersetzt werden soll
Konversion aller notwendigen Daten (Dateien und
Datenbanken)
Schulung aller Benutzer und Administratoren
Übergabe an Marketing, Vertrieb und Verkäufer
Wenn ein Produkt ausgeliefert wird, ergibt sich in der Regel schnell die Notwendigkeit neuer Releases, um
Probleme zu beseitigen, Features zu realisieren, deren Implementierung verschoben werden musste, und
Erweiterungen vorzunehmen.
Die Übergabephase beginnt, wenn eine Baseline reif genug ist, um beim Endbenutzer installiert werden zu können.
Das erfordert typischerweise, dass zumindest eine nützliche Teilmenge des Systems mit einer aktzeptablen Qualität
fertig gestellt werden konnte und dass die Benutzerdokumentation vorhanden ist.
Meist fallen mehrere Iterationen in der Übergabephase an: Beta-Releases, allgemeine Releases, Bug-Fix- und
Erweiterungsreleases. Hoher Aufwand wird in die Entwickler der benutzerorientierten Dokumentation, die Schulung
von Benutzern, Unterstützung der Benutzer in ihren ersten Verwendungen des Produkts und Reaktion auf
Benutzer-Feedback investiert.
Man sollte sich an diesem Punkt jedoch auf den Feinschliff, die Konfiguration, Installation und Usability-Aspekte
beschränken. Gänzlich neue Erweitungen sollten durch einen nachfolgenden separaten Entwicklungszyklus realisiert
werden.
Die Übergabephase kann trivial sein (Software und Handbuch wird auf einen Server im Internet gelegt) oder auch
sehr aufwändig und kompliziert (Ersetzung einer Flugaufsichts-Software).
Empfohlene Anzahl von Iterationen nach Kruchten (1998)
Komplexität
Konzeption
Elaboration
Konstruktion
Übergabe
Summe
niedrig
normal
hoch
0
1
1
1
3
1
2
2
1
6
1
3
3
2
9
Bewertung des RUPs
Übernimmt vom Spiralmodell die Steuerung durch Risiken
Konkretisiert die Aktivitäten (Spiralmodell ist ein
Meta-Modell)
Änderungen der Anforderungen sind leichter einzubeziehen als
beim Wasserfallmodell
Projekt-Team kann im Verlauf hinzulernen
2011-10-30
(Hauptsächlich) Konstruktionsphase kann inkrementell
ausgestaltet werden
Softwaretechnik
Bewertung des RUPs
Bewertung des RUPs
Übernimmt vom Spiralmodell die Steuerung durch Risiken
Konkretisiert die Aktivitäten (Spiralmodell ist ein
Meta-Modell)
Änderungen der Anforderungen sind leichter einzubeziehen als
beim Wasserfallmodell
Projekt-Team kann im Verlauf hinzulernen
(Hauptsächlich) Konstruktionsphase kann inkrementell
ausgestaltet werden
Iterativ ist nicht gleich inkrementell. Bei der iterativen Entwicklung werden Entwicklungsschritte wiederholt
ausgeführt. Bei der inkrementellen Entwicklung geschieht dies auch, jedoch immer um eine neues Release auf Basis
eines vorherigen zu bauen. Letzteres ist im Begriff Iteration nicht eingeschlossen.
Entwicklungsprozesse: Cleanroom Development
Cleanroom Development (Mills u. a. 1987)
Fehlerbeseitigung
Spezifiziere
System
formal
Definiere
Software−
inkremente
Entwickle
Verwendungs−
profil
Entwickle
strukturiertes
Programm
Verifiziere
Code
formal
Integriere
Inkrement
Entwerfe
statistische
Tests
Schlüsselstrategien
Formale Spezifikation
Strukturierte Programmierung
Statische Verifikation
Statistisches Testen
basiert auf Verwendungsprofilen (die Verwendungsweise der
Software in der Praxis)
die häufigsten (und kritischsten) Verwendungsarten werden
verstärkt getestet
Teste
integriertes
System
2011-10-30
Softwaretechnik
Schlüsselstrategien
Formale Spezifikation
Strukturierte Programmierung
Statische Verifikation
Statistisches Testen
basiert auf Verwendungsprofilen (die Verwendungsweise der
Software in der Praxis)
die häufigsten (und kritischsten) Verwendungsarten werden
verstärkt getestet
Statistisches Testen gleicht einem statistischen Experiment. Aus der formalen Spezifikation und den im Feld
ermittelten Benutzungsprofilen werden geeignete Testfälle entwickelt. Mit Hilfe der Ergebnisse des Tests wird dann
die Mean-Time-To-Failure (durschnittliche Dauer bis zu einem Störfall) mit einer gewissen Wahrscheinlichkeit
vorhergesagt.
Gruppen:
Spezifikationsteam:
verantwortlich für Entwicklung und Wartung der
Systemspezifikation
erstellt kundenorientierte und formale Spezifikation
Entwicklungsteam:
verantwortlich für Entwicklung und Verifikation der Software
Software wird nicht ausgeführt hierzu!
verwendet Code-Inspektion ergänzt durch
Korrektheitsüberlegungen (nicht streng formal)
Zertifizierungsteam:
verantwortlich für statistische Tests
Erfahrungen Cobb und Mills (1990):
weniger Fehler als bei traditioneller Entwicklung
bei vergleichbaren Kosten
Entwicklungsprozesse: Agile Methoden
Agiles Manifest
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the
items on the left more.
— http://agilemanifesto.org/
Prinzipien der agilen Entwicklung
Kundenzufriedenheit durch schnelle Auslieferung nutzbarer
Software
funktionsfähige Software wird häufig ausgeliefert (eher
Wochen als Monate)
funktionsfähige Software ist das Maß für Fortschritt
auch späte Änderungen der Anforderungen sind willkommen
enge tägliche Kooperation von Geschäftsleuten und
Entwicklern
Konversation von Angesicht zu Angesicht ist die beste
Kommunikationsform (gemeinsamer Ort)
Projekte bestehen aus Menschen, denen man vertrauen sollte
kontinuierliches Streben nach technischer Exzellenz und
gutem Design
Einfachheit
selbstorganisierte Teams
kontinuierliche Anpassung an sich ändernde Bedingungen
— http://www.agilemanifesto.org/principles.html
Varianten der agilen Entwicklung
Agile Unified Process (AUP)
Dynamic Systems Development Method (DSDM)
Essential Unified Process (EssUP)
Extreme Programming (XP)
Feature Driven Development (FDD)
Open Unified Process (OpenUP)
Scrum
Entwicklungsprozesse: Extreme Programming (XP)
Extreme Programming (Beck 2000)
Extreme Programming (XP) ist eine agile Methode für
kleinere bis größere Entwicklerteams (max. 10-15 Personen),
Probleme mit vagen Anforderungen
und Projekte, bei denen ein Kundenrepräsentant stets greifbar
ist.
http://www.extremeprogramming.org/
Extreme Programming (Beck 2000)
Anerkannte Prinzipien und Praktiken werden extrem“ umgesetzt:
”
Code-Reviews → permanente Reviews durch
Pair-Programming
Testen → ständiges Testen: Unit-Tests sowie Akzeptanztests
durch den Kunden/Benutzer
klare Struktur → jeder verbessert sie kontinuierlich durch
Refactoring
Einfachheit → stets die einfachste Struktur wählen, die die
aktuellen Anforderungen erfüllt
Integration → permanente Integration auch mehrmals am Tag
Validierung:
Kunde/Benutzer ist stets involviert bei der Planung neuer
Iterationen und verantwortlich für Akzeptanztest
kurze Iterationen → Dauer in Minuten und Stunden, nicht
Wochen, Tage, Jahre
aber auch Auslassung anerkannter Prinzipien:
Dokumentation: mündliche Überlieferung, Tests und
Quellcode
Planung: sehr begrenzter Horizont
Weitere XP-Charakteristika
Kunde vor Ort
eine Metapher statt einer Architekturbeschreibung
40-Stundenwoche
Code ist kollektives Eigentum
Kodierungsstandards
Entwicklungsprozesse: Scrum
Scrum-Prozess
2011-10-30
Softwaretechnik
Scrum
Scrum-Prozess
Bildquelle: http://en.wikipedia.org/wiki/File:Scrum_process.svg, GPL
Scrum-Rollen (Pichler 2008)
Product Owner:
vertritt Endkundenbedürfnisse
vereint Produkt- und
Projektmanagementaufgaben
fest integriert in Entwicklung
Aufgaben:
Anforderungsbeschreibung und
-management
Releasemanagement und Return on
Investment
enge Zusammenarbeit mit dem Team
Stakeholder-Management
Scrum-Prozess
Team:
entscheidet selbst, wieviele Anforderungen
in einem Inkrement umgesetzt werden
legt Arbeitsschritte und
Arbeitsorganisation selbst fest
agiert autonom
interdisziplinär besetzt
selbstorganisiert
klein
Vollzeitmitglieder
Arbeitsplätze in unmittelbarer Nähe
Scrum-Master (vom Team bestimmt):
Aufgaben
etabliert Scrum
unterstützt Team
stellt Zusammenarbeit von Team und
Product Owner sicher
beseitigt Hindernisse
verbessert Entwicklungspraktiken
führt durch dienen
Fähigkeiten
Moderation
Coaching
Erfahrung in Softwareentwicklung
Scrum: Product Backlog
Product Backlog enthält
alle bekannten funktionalen und nichtfunktionalen
Anforderungen
weitere Arbeitsergebnisse (z.B. Aufsetzen der Test- und
Entwicklungsumgebung)
keine Aktivitäten!
wird vom Product Owner gepflegt
Prio
1
Thema
Kalender
2
Kalender
3
Kalender
Nutzer
kann
Termin löschen
...
...
...
Beschreibung
Administrator
kann zentrale
Kalenderdatenbank anlegen
Nutzer
kann
Termin eintragen
Akzeptanz
Aufwand
Installationsskript
2
legt DB an
valider Termin
wird eingetragen, invalider
Termin
wird
zurückgewiesen
gelöschter
Termin
ist
entfernt;
Löschung nur,
wenn Rechte
vorhanden
...
3
3
...
2011-10-30
Softwaretechnik
Scrum
Prio
1
Thema
Kalender
2
Kalender
3
Kalender
Nutzer
kann
Termin löschen
...
...
...
Beschreibung
Administrator
kann zentrale
Kalenderdatenbank anlegen
Nutzer
kann
Termin eintragen
Das Product Backlog ist ein lebendes Dokument. Es wird nach jedem Sprint aktualisiert. Seine Einträge sind
priorisiert. Sie weisen einen unterschiedlichen Detaillierungsgrad auf: Die im kommenden Sprint anvisierten
Anforderungen sind genauer beschrieben. Der Aufwand jedes Eintrags ist abgeschätzt (Einheit: Punkte; siehe
unten).
Vorlagen gibt es z.B. unter
http://epf.eclipse.org/wikis/scrum/Scrum/guidances/templates/burndown_chart_D182CF23.html
Scrum: Kostenschätzung
Schätzklausur und Planungspoker
Akzeptanz
Aufwand
Installationsskript
2
legt DB an
valider Termin
wird eingetragen, invalider
Termin
wird
zurückgewiesen
gelöschter
Termin
ist
entfernt;
Löschung nur,
wenn Rechte
vorhanden
...
3
3
...
Scrum: Kostenschätzung
Punkteskala (Fibonacci-Reihe):
0
1
2
3
5
8
13
kein Aufwand
sehr kleiner Aufwand
kleiner Aufwand = 2 × sehr kleiner Aufwand
mittlerer Aufwand = sehr kleiner + kleiner Aufwand
großer Aufwand = kleiner + mittlerer Aufwand
sehr großer Aufwand = mittlerer + großer Aufwand
riesiger Aufwand = großer + sehr großer Aufwand
Scrum: Entwicklungsgeschwindigkeit
Punkte werden im Projektverlauf auf Echtzeit abgebildet
Entwicklungsgeschwindigkeit (Velocity) = Punkte / Sprint
Velocity Chart
Scrum: Steuerungselemente
Sprint Burndown Chart
Release Burndown Chart
Entwicklungsprozesse: Agile versus traditionelle Vorgehensweisen
Agile versus weit voraus planende Prozessmodelle
Risiken agiler Methode:
Skalierbarkeit, Kritikalität, Einfachheit des Entwurfs,
Personalfluktuation, Personalfähigkeiten
Risiken weit voraus planender Prozessmodelle:
Stabilität der Anforderungen, steter Wandel, Notwendigkeit
schneller Resultate, Personalfähigkeiten
Generelle Risiken:
Unsicherheiten bei der Technologie, unterschiedliche
Interessengruppen, komplexe Systeme
— Boehm und Turner (2003)
Entwicklungsprozesse: Capability Maturity Model
Entwickelt vom SEI 1985-91 für DoD
Beschreibt Stufen der Prozessreife
Maßstab/Leitfaden für Verbesserungen
Idee: besserer Prozess → besseres Produkt
5 Stufen (CMM Level 1-5)
Definiert Schlüsselbereiche (Key Process Areas)
Steigende Transparenz des Prozesses
ständige
Verbesserung
Vorhersagbarkeit
Einheitlichkeit
Konsistenz
Disziplinierter
Prozess
Repeatable
Initial
Optimizing
Managed
Defined
CMM Level 1 – Initial
Prozess meist völlig instabil
Typisch: in Krisen nur noch Code & Fix
Qualität und Fertigstellung unvorhersagbar
Erfolge nur durch gute Leute und großen Einsatz
CMM Level 2 – Repeatable
Projekterfolge nachvollziehbar und wiederholbar
Projektplanung und -management basiert auf Erfahrung
Key Process Areas:
Anforderungsverwaltung (u.a. Reviews)
Projektplanung (Zeitplanung, Risikomgmt., Prozess)
Projektverfolgung und -überblick (Transparenz)
Unterauftragsverwaltung
Qualitätssicherung (QS-Plan)
Konfigurationsverwaltung (Konsistenz, Änderungsverfolgung)
CMM Level 3 – Defined
Organisationsweiter Prozess, wird für jedes Projekt angepasst
Zuständig: Software Engineering Process Group
Kosten, Zeitplan und Funktionalität im Griff
Key Process Areas:
Organisationsweiter Prozess
Prozessdefinition
Ausbildungsprogramm
Integriertes Softwaremanagement (Anpassung auf konkretes
Projekt)
Software-Engineering-Techniken, Tool-Unterstützung
Koordination zwischen Gruppen
Peer Reviews
CMM Level 4 – Managed
Einbeziehung quantitativer Aspekte
Ziele setzen und überwachen
Prozessmessdaten werden aufgenommen, archiviert, analysiert
Vorhersagbarkeit steigt
Key Process Areas:
Quantitative Prozesssteuerung
→ Leistung des Prozesses überwachen
Software-Qualitätsmanagement
→ Messbare Ziele für Prozessqualität
CMM Level 5 – Optimizing
Änderungsmanagement für Technologie und Prozesse
Feedback von Projekten zum Prozess → ständige
Verbesserung
Key Process Areas:
Defektvermeidung
→ Analyse von Fehler-/Problemursachen
→ Vermeiden erneuten Auftretens
Verwaltung von Technologieänderung
→ neue Technologien bewerten, evtl. einführen
Verwaltung von Prozessänderung
→ kontinuierliche Verbesserung
70%
60%
50%
Initial
Repeatable
Defined
Managed
Optimizing
40%
30%
20%
10%
0%
1995
1997
1999
2001
SEI Assessments (Quelle: SEI)
Probleme mit CMM
Management: ”‘zu teuer”’
Wenig verbreitet (ca. 10-15%)
Nur langsame Verbesserung (ca. 2 Jahre/Level)
Neue Technologien nicht berücksichtigt
Capability Maturity Model – Management
Optimizing
Managing
Managed
Participative
Defined
Supportive
Repeatable
Recognized
Ignored
Initial
Quelle: Parker (1995)
Capability Maturity Model Integration (CMMI)
Viele Maturity-Model-Varianten
→ CMMI: ”‘Integration”’ (SEI 2000):
Angepasst an iterative Entwicklung
Generische Ziele hinzugefügt
Zusätzliche KPAs:
Level 2: Measurement and Analysis
Level 3: Software Product Engineering (verfeinert); Risk
Management; Decision Analysis and Resolution
Level 4, 5: nur Restrukturierungen
Entwicklungsprozesse: Persönlicher Softwareprozess
Persönlicher Softwareprozess (PSP)
Watts S. Humphrey (1995) (SEI)
Anwendung von CMM auf einen Entwickler
Schwerpunkte: Planung, Qualität
Vorteile:
Schneller umsetzbar
Konkrete Techniken angebbar
Verbesserungen sofort wahrnehmbar
→ höhere Motivation
PSP0
PSP1
PSP2
PSP3
PSP – Evolution
Personal
Quality
Managmt.
Personal
Planning
Process
Baseline
Personal
Process
PSP0 – Baseline Personal Process
PSP0: Bisherige Vorgehensweise plus
Messung
Zeit pro Phase
gefundene/gemachte Fehler pro Phase
Zeit für Fehlerbehebung
Formulare: Projektplan, Zeiten, Fehler
PSP0.1: plus
Codierrichtlinien
Messung der LOC (Veränderungen)
Formular: Prozessverbesserung
Cyclic
Personal
Process
PSP1 – Personal Planning Process
PSP1: PSP0.1 plus
Größenschätzung mit PROBE (PROxy-Based Estimating)
Schätzung basiert auf Objekten (Entwurf)
Unterscheidet Objekte nach Typ, Größe, #Methoden
Daten sammeln, Regressionsanalyse
Formular: Testbericht
PSP1.1: PSP1 plus
Aufgabenplanung
Zeitschätzung, -planung
Projektverfolgung (Earned Value Tracking)
PSP2 – Personal Quality Management
PSP2: PSP1.1 plus
Code Reviews (Checklisten)
Design Reviews (Checklisten)
PSP2.1: PSP2 plus
Design Templates:
Operational Scenario (≈ Anwendungsfall)
Functional Specification (formale Spezifikation)
State Specification (≈ Zustandsdiagramm)
Logic Specification (Pseudocode)
→ Vermeidung von Designfehlern
→ Beurteilung der Qualität
Cost-of-Quality (Behebung, Bewertung, Vermeidung)
PSP3 – Cyclic Personal Process
PSP3:
Anwendung auf große Projekte
Nach High-Level Design: Aufteilung in Module
Anwendung von PSP2.1 auf jedes Modul
Formular: Issue tracking log
Entwicklungsprozesse: Wiederholungsfragen
Wiederholungs- und Vertiefungsfragen
Erläutern Sie die Ideen sowie Vor- und Nachteile der
Entwicklungsprozesse. . .
Wasserfall
V-Modell
testgetriebene Entwicklung
inkrementelle Entwicklung
Spiralmodell
Extreme Programming
Gegeben ist das folgende Szenario: [. . . ]. Welches
Vorgehensmodell empfehlen Sie?
Unter welchen Umständen würden Sie eher agiles Vorgehen
als voraus planendes empfehlen?
Stellen Sie das Capability Maturity Model dar. Wozu dient es?
Wie können Prozesse verbessert werden?
Was ist der persönliche Software-Entwicklungsprozess? Wozu
dient er?
Entwicklungsprozesse: Weiterführende Literatur
Weiterführende Literatur
Bibliographie zu Entwicklungsprozessen:
Arbeitskreis der Fachgruppe 5.11
“Begriffe und Konzepte der Vorgehensmodellierung”
http://www.vorgehensmodelle.de/giak/
arbeitskreise/vorgehensmodelle/publallg.html
Rational Unified Process: Kruchten (1998)
1 Basili und Turner 1975 Basili, V. ; Turner, J.: Iterative
Enhancement: A Practical Technique for Software Development.
In: IEEE Transactions on Software Engineering 1 (1975),
Dezember, Nr. 4, S. 390–396
2 Beck 2000 Beck, Kent: Extreme Programming Explained.
Addison-Wesley, 2000 (The XP Series). – ISBN 201-61641-6
3 Boehm und Turner 2003 Boehm, B. ; Turner, R.: Using
risk to balance agile and plan-driven methods. In: IEEE
Computer 36 (2003), Juni, Nr. 6, S. 57–66
4 Boehm 1979 Boehm, Barry W.: Guidelines for verifying and
validating software requirements and design specification. In:
EURO IFIP 79, 1979, S. 711–719
5 Boehm 1988 Boehm, Barry W.: A spiral model of software
development and enhancement. In: IEEE Computer 21 (1988),
Mai, Nr. 5, S. 61–72
6 Cobb und Mills 1990 Cobb, R. H. ; Mills, H. D.:
Engineering Software Under Statistical Quality Control. In: IEEE
Software 7 (1990), Nr. 6, S. 44–54
7 Gilb 1988 Gilb, Tom: Principles of Software Engineering
Management. Harlow, UK : Addison-Wesley, 1988
8 Gornik 2001 Gornik, David: IBM Rational Unified Process:
Best Practices for Software Development Teams / IBM Rational
Software. 2001 (TP026B, Rev 11/01). – White Paper
9 Humphrey 1995 Humphrey, Watts S.: A Discipline For
Software Engineering. Addison-Wesley, 1995 (SEI series in
software engineering)
10 Kruchten 1998 Kruchten, Phillipe: The Rational Unified
Process: An Introduction. Reading, Mass.: Addison-Wesley, 1998
11 Mills u. a. 1987 Mills, H.D. ; Dyer, M. ; Linger, R.:
Cleanroom Software Engineering. In: IEEE Software 4 (1987),
September, Nr. 5, S. 19–25
12 Parker 1995 Parker, Burton G.: Data Management Maturity
Model. July 1995
13 Pichler 2008 Pichler, Roman: Scrum — Agiles
Projektmanagement erfolgreich einsetzen. dpunkt.verlag, 2008.
– ISBN 978-3-89864-478-5
14 Pressman 1997 Pressman, Roger: Software Engineering – A
Practioner’s Approach. Vierte Ausgabe. McGraw-Hill, 1997
15 Royce 1970 Royce, W.: Managing the Development of Large
Software Systems. In: Proceedings Westcon, IEEEPress, 1970,
S. 328–339
16 Sneed 2004 Sneed, Harry: Vorlesungsskriptum
Software-Engineering. Uni Regensburg: Wirtschaftsinformatik
(Veranst.), 2004

Softwaretechnik ¨Uberblick I - Informatik - FB3

Transcription

Documents pareils

Entwicklungsprozesse in Open-Source

3HAC024962-005

Wir suchen den ältesten RATIONAL Combi

Chronologie zum „Proceß“

94 Vierzig Jahre Combi-Dämpfer von Rational

Deutsche Rational AG

Business Case für die IT-Ausbildung Die e

Leitartikel als PDF öfnnen - GMP

SPICE - Ein Schlüssel zur System-und Software