Best Practice Software-Engineering · Alexander Schatten / Markus Demolsky / Dietmar Winkler /...

Best Practice Software-Engineering

In dieser Reihe sind bisher erschienen:

Martin Backschat / Bernd RückerEnterprise JavaBeans 3.0Grundlagen – Konzepte – Praxis

Peter LiggesmeyerSoftware-Qualität, 2. Aufl ageTesten, Analysieren und Verifi zieren von Software

Michael EnglbrechtEntwicklung sicherer SoftwareModellierung und Implementierung mit Java

Klaus ZeppenfeldObjektorientierte ProgrammiersprachenEinführung und Vergleich von Java, C++, C#, Ruby

Martin Backschat / Stefan EdlichJ2EE-Entwicklung mit Open-Source-ToolsCoding – Automatisierung – Projektverwaltung – Testen

Marco Kuhrmann / Jens Calamé / Erika HornVerteilte Systeme mit .NET RemotingGrundlagen – Konzepte – Praxis

Peter Liggesmeyer / Dieter Rombach (Hrsg.)Software Engineering eingebetteter SystemeGrundlagen – Methodik – Anwendungen

Stefan Conrad / Wilhelm Hasselbring / Arne Koschel / Roland TritschEnterprise Application IntegrationGrundlagen – Konzepte – Entwurfsmuster – Praxisbeispiele

Ingo Melzer et al.Service-orientierte Architekturen mit Web Services, 3. Aufl ageKonzepte – Standards – Praxis

Oliver Vogel / Ingo Arnold / Arif Chughtai / Edmund Ihler / Timo Kehrer / Uwe Mehlig / Uwe ZdunSoftware-Architektur, 2. Aufl ageGrundlagen – Konzepte – Praxis

Marco Kuhrmann / Gerd BenekenWindows® Communication FoundationKonzepte – Programmierung – Konzeption

Andreas Korff Modellierung von eingebetteten Systemen mit UML und SysML

Alexander Schatten et al.Best Practice Software-EngineeringEine praxiserprobte Zusammenstellung von komponentenorientierten Konzepten, Methoden und Werkzeugen

Alexander Schatten / Markus Demolsky / Dietmar Winkler / Stefan Biffl / Erik Gostischa-Franta / Thomas Östreicher

Best Practice Software-EngineeringEine praxiserprobte Zusammenstellung von komponentenorientierten Konzepten, Methoden und Werkzeugen

AutorenAlexander SchattenMarkus DemolskyDietmar WinklerStefan Biffl Erik Gostischa-FrantaThomas Östreicher

Weitere Informationen zum Buch unter: http://bpse.ifs.tuwien.ac.at

Wichtiger Hinweis für den BenutzerDer Verlag und die Autoren haben alle Sorgfalt walten lassen, um vollständige und akkurate Informationen in diesem Buch zu publizieren. Der Verlag übernimmt weder Garantie noch die juristische Verantwortung oder irgendeine Haftung für die Nutzung dieser Informationen, für deren Wirtschaftlichkeit oder fehlerfreie Funktion für einen bestimmten Zweck. Der Verlag übernimmt keine Gewähr dafür, dass die beschriebenen Verfahren, Programme usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt auch ohne beson-dere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Der Verlag hat sich bemüht, sämtliche Recht-einhaber von Abbildungen zu ermitteln. Sollte dem Verlag gegenüber dennoch der Nachweis der Rechtsinhaberschaft geführt werden, wird das branchenübliche Honorar gezahlt.

Bibliografi sche Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografi e; detaillierte bibliografi sche Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Springer ist ein Unternehmen von Springer Science+Business Mediaspringer.de

© Spektrum Akademischer Verlag Heidelberg 2010Spektrum Akademischer Verlag ist ein Imprint von Springer

10 11 12 13 14 5 4 3 2 1

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Ur-heberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfi lmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Planung und Lektorat: Dr. Andreas Rüdinger, Bianca AltonRedaktion: Bernhard GerlHerstellung und Satz: Crest Premedia Solutions (P) Ltd, Pune, Maharashtra, IndiaUmschlaggestaltung: SpieszDesign, Neu–Ulm

ISBN 978-3-8274-2486-0

Inhaltsverzeichnis

1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Projektarten und -aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Überblick zu Kapiteln und Themen . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Empfohlene Vorkenntnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Weitere Ressourcen im Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 Die Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.6 Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Lebenszyklus eines Software-Produkts . . . . . . . . . . . . . . . 11

2.1 Grundlegende Phasen eines Lebenszyklusses . . . . . . . . . . . 12

2.2 Übergreifende Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Anforderungen und Spezifikation . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Projektplanung und -steuerung . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Entwurf und Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6 Implementierung und Integration . . . . . . . . . . . . . . . . . . . . . . . 32

2.7 Betrieb und Wartung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.8 Vom Software-Lebenszyklus zum Vorgehensmodell . . . . . . . 43

2.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.1 Strategie für die Projektdurchführung . . . . . . . . . . . . . . . . . . . . 48

3.2 Wasserfallmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3 Das V-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4 V-Modell XT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5 Inkrementelles Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.6 Spiralmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.7 Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.8 Agile Software-Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.9 Anpassung von Vorgehensmodellen . . . . . . . . . . . . . . . . . . . . 65


4 Software-Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . 71

4.1 Einführung ins Projektmanagement . . . . . . . . . . . . . . . . . . . . . 72

4.2 Projektdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.3 Projektplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.4 Projektverfolgung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.5 Projektabschluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110


5 Qualitätssicherung und Test-Driven Development . . . . . 113

5.1 Der Qualitätsbegriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

5.2 Verifikation und Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

5.3 Software-Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5.4 Software-Inspektionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

v

5.5 Architekturevaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

5.6 Software-Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.7 Test-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

5.8 Automatische Codeprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154


6 Notationen, Methoden der Modellierung . . . . . . . . . . . . . . . 1636.1 UML-Diagrammfamilie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

6.2 Modellierung von Daten und Systemschichten . . . . . . . . . . . . 186

6.3 Projektmanagement-Artefakte . . . . . . . . . . . . . . . . . . . . . . . . . . 191


7 Software-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

7.1 Was ist eine Software-Architektur . . . . . . . . . . . . . . . . . . . . . . . 200

7.2 Wie entstehen Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

7.3 Sichten auf eine Software-Architektur . . . . . . . . . . . . . . . . . . . 206

7.4 Separation of Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

7.5 Schichtenarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

7.6 Serviceorientierte Architekturen . . . . . . . . . . . . . . . . . . . . . . . . 215

7.7 Ereignisgetriebene Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 221


8 Entwurfs-, Architektur- und Integrationsmuster . . . . . . . . 2298.1 Was ist ein Muster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

8.2 Grundlegende Muster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

8.3 Erzeugung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

8.4 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

8.5 Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

8.6 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281


9 Komponentenorientierte Software-Entwicklung . . . . . . . . 3019.1 Vom Objekt zum Service: Schritte der Entkopplung . . . . . . . 302

9.2 Frameworks als Basis für Komponentenbildung . . . . . . . . . . . 311

9.3 Dependency-Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

9.4 Persistente Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

9.5 Querschnittsfunktionen in Aspekte auslagern . . . . . . . . . . . . 351

9.6 Benutzerschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

9.7 Lose Koppelung von Systemen . . . . . . . . . . . . . . . . . . . . . . . . . 365

9.8 Logging: Protokollieren von Systemzuständen . . . . . . . . . . . . 371


10 Techniken und Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

10.1 Konvention oder Konfiguration? . . . . . . . . . . . . . . . . . . . . . . . . 378

10.2 Sourcecode-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

10.3 Build-Management und Automatisierung . . . . . . . . . . . . . . . . . 392

10.4 Die integrierte Entwicklungsumgebung . . . . . . . . . . . . . . . . . . 402

10.5 Virtualisierung von Hard- und Software . . . . . . . . . . . . . . . . . . 403

vi Inhaltsverzeichnis

10.6 Projektplanung und Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . 405

10.7 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

10.8 Kommunikation im (global verteilten) Team. . . . . . . . . . . . . . . 413


11 Epilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

Inhaltsverzeichnis vii

1 Einleitung

Software-Engineering, also die systematische, ingenieurmäßige Herstel-lung von Software [46], erfolgt in vielfältigen Anwendungsfeldern, tech-nischen Plattformen und Projektgrößen. In einem Feld, das von raschemtechnologischem Wandel geprägt ist, stellt sich für Einsteiger mit Grund-kenntnissen in der Programmierung und für Wiedereinsteiger die Frage,welche Auswahl an Methoden, Notationen und Techniken eine gute Grund-lage für die Durchführung eines mittelgroßen Projekts sein kann.

„Best-Practice Software-Engineering“ liefert eine aufeinander abgestimm- „Best-Practice“ Soft-ware-Engineeringte Zusammenstellung von Konzepten, Methoden und Werkzeugen für Soft-

ware-Engineering-Projekte, die sich in der Praxis bewährt haben. Der Be-griff „Best-Practice“ basiert auf der Idee, dass es für eine bestimmte Auf-gabe ein Bündel von Techniken, Methoden, Prozessen, Aktivitäten und An-reizen gibt, das effektiver oder effizienter ist als andere gebräuchliche Vor-gehensweisen. Effektiv bedeutet, dass das angestrebte Ergebnis mit höhererWahrscheinlichkeit bzw. geringeren Risiken erreicht wird. Effizient heißt,dass für ein bestimmtes Ergebnis weniger Ressourcen gebraucht werdenoder mit gleichen Ressourcen ein besseres Ergebnis erreicht wird als miteiner alternativen Vorgehensweise.

Um sich als „Best-Practice“ zu qualifizieren, muss eine Vorgehensweisewiederholbar sein und in ihrer Wirksamkeit im Zielkontext ausreichendevaluiert werden. In der Arbeit mit Projektteams und in der Analyse vonOpen-Source-Projekten hat sich gezeigt, welche Ansätze effektiv und ro-bust genug sind, um als Best-Practice zu gelten, und welche sich als zuumständlich oder als Modeerscheinungen herausgestellt haben.

Ziel dieses Buches ist eine durchgängige Darstellung der Fähigkeiten, Komponenten-orientierungdie für die erfolgreiche Abwicklung eines Software-Entwicklungsprojekts

notwendig sind. Gutes Software-Engineering erfordert einen ganzheitli-chen Ansatz und Verständnis in den Bereichen Anforderungsbeschreibung,Software-Prozess und Projektmanagement, Architektur und Design Pat-terns, Komponentenorientierung, Qualitätssicherung, integrierte Werkzeu-ge, Kommunikation sowie eine systematische Evaluierung bis zur Doku-mentation. Als Einführung in diese breite Materie finden Sie in den folgen-den Abschnitten eine Darstellung der wesentlichsten Komponenten soft-ware-intensiver Systeme, einen Überblick zu Ansätzen, um Software-Ent-wicklungsprojekte zu planen und zu steuern sowie eine Zusammenfassungder thematischen Schwerpunkte der Buchkapitel.

Die Anwendungsbereiche der Projekte befassen sich mit kommerziellen AnwendungsbereicheWeb-/Open-Source-Systemen und explizit nicht mit eingebetteten und si-cherheitskritischen Systemen.

1

1.1 Projektarten und -aspekte

Software-Systeme sind die Basis für umfassende Abläufe des Geschäfts-Prozesse, Techno-logien und Benutzer lebens (Abwicklung von Geschäftsprozessen wie einer Reisebuchung), der

Industrie (Anlagensteuerung) und Kommunikation & Unterhaltung (etwaMusikplattformen wie iTunes). Das komplexe Zusammenspiel einer Men-ge von Prozessen, Technologien und Benutzern ist notwendig, um effektivund effizient Ergebnisse ausreichend hoher Qualität zu erzielen.

Die Herstellung komplexer Software ist anspruchsvoll und braucht profes-Schnellere Ent-wicklung kom-plexer Systeme

mit Komponenten

sionelles Herangehen, von der Erfassung der Anforderungen, über den Ent-wurf der Systemarchitektur, bis hin zur detaillierten Umsetzung und Über-prüfung. Ein wesentlicher Aspekt in vielen Projekten ist, die Zeit von derPlanung zur Umsetzung einer Produktidee zu verkürzen und gleichzeitigProdukte mit ausreichend hoher Qualität zu liefern. Die Herstellung vonSoftware-Systemen durch Zusammensetzen von bestehenden Komponen-ten unterschiedlicher Quellen (etwa Open-Source-Plattformen) unterstützteine raschere Entwicklung.

Fehler und Qualitätsmängel von Software-Systemen betreffen immer mehrVorhersehba-res Verhalten Menschen in immer größerem Umfang. Ziel professioneller Software-Her-

steller ist es daher, „No-surprise-Software“ zu entwickeln, also Software,deren Verhalten und Eigenschaften vorhersehbar sind, insbesondere auchim Zusammenspiel mit anderen Systemen.

Durch die zunehmende Verbreitung von Software-Systemen kommenimmer mehr Menschen mit Software-Programmen in Kontakt. DasKnow-how von Benutzern reicht dabei von Laien bis hin zu „Power Usern“.Abgesehen von dem vorhandenen Wissen der Benutzer muss das Software-System leicht zu bedienen sein und bei auftretenden Fehler eine bestmög-liche Unterstützung bieten.

Ziel der Disziplin Software-Engineering ist, für große Software-SystemeSoftware-Engineeringähnliche Qualitätsmaßstäbe zu erreichen, wie es in klassischen Ingenieur-disziplinen üblich ist. Kostengünstige Entwicklung innerhalb des geplantenZeitrahmens (vorhersagbare Herstellungsdauer und -aufwand), hohe Pro-duktqualität (geringe Fehlerquote bei Auslieferung), verfügbare Professio-nisten für Anpassung und Wartung werden dabei angestrebt.

Typische Probleme bei großen Software-Entwicklungsprojekten resultie-ren aus der Komplexität von Software-Systemen, insbesondere auch ausder Integration mit anderen Systemen und der Veränderung des Umfeldsim Lauf der Zeit. Diese Komplexität wird, besonders am Anfang, häufigunterschätzt. Eine unzureichende Erfassung der Anforderungen sowie De-finition und Überprüfung der Qualität von Zwischenergebnissen, führt zumangelnder Qualität bzw. Verwendbarkeit der gelieferten Software.

Software-Projekte haben als Ziel ein neues Software-System zu entwickelnEntwicklungund Validierungdes „Bauplans“ oder existierende Systeme weiterzuentwickeln bzw. zu integrieren. Im Ge-

gensatz zu materiellen Produkten hat Software besondere Eigenschaften in

2 1 Einleitung

der Herstellung (wie geringe Kosten der Vervielfältigung, kein Qualitäts-verlust bei Vervielfältigung, sehr geringe Einschränkung durch physikali-sche Gesetze), sodass der Hauptaufwand in der Entwicklung und Validie-rung des „Bauplans“ für das Software-System entsteht.

Unrealistische Aufgabenstellungen, deren Komplexität mit dem Stand derTechnik nicht zu bewältigen sind, bzw. mangelnde Ausbildung und Erfah-rung der Projektmitarbeiter führen zu Schwächen im Projekt- und Risiko-management und zu Zeitverzögerungen bzw. zum Überschreiten des ge-planten Budgets.

Die Technologie eines Software-Projekts – etwa Rich-Clients, Distribu- Domäne &Technologiented Systems, Web Applications – hat bei Weitem nicht so viel Einfluss auf

die Komplexität eines Software-Produkts wie die Domäne, für welche dasProdukt hergestellt wird. Natürlich werden die verwendeten Technologi-en für die einzelnen Projekttypen auch auf die Anforderungen abgestimmt,dies ist sogar eine bekannte Vorgehensweise von Kunden: „Welche Soft-ware ist möglich?“ Erfahrung im Team wird benötigt, um die Domänezu analysieren, die entsprechenden Technologien zu wählen und mittelsSoftware-Engineering und Projektmanagement-Methoden den Aufwand zuschätzen und den Projektverlauf zu steuern.

Typ und Komplexität des geplanten Produkts haben starken Einfluss auf die Treiber des Projekt-aufwandsHerangehensweise (Prozesse, Methoden und Technologien) und den Um-

fang des zu planenden Projekts. In der Praxis wurden Projektkomplexitätund Produktgröße als Treiber für den Projektaufwand identifiziert [13].

Produktkomplexität beschreibt die Funktionen und die Anzahl bzw. den ProduktkomplexitätUmfang der beteiligten Software-Komponenten, wie z. B. Anzahl der Klas-sen, Module, Datenbanken und verwendete Technologien sowie Code-Zei-len. Verwendete Technologien und insbesondere bestehende Frameworkstragen ebenfalls zur Projektkomplexität bei, und es werden erfahrene Ent-wickler und Spezialisten für deren Einsatz benötigt.

Neue Projekte bringen oft viele Neuheiten für die Teammitglieder mit sich,was wiederum Projektrisiken birgt, die durch passende Planung und Hinzu- Projektrisikenziehen von Experten besser vorhersehbar und damit kontrollierbar werden.Häufigstes Risiko ist die Volatilität der Rahmenbedingungen (Änderungenan Technologien, Projektzielen) und der Anforderungen.

Mangelhafte Methodik und Werkzeuge in der Software-Entwicklung kön- Methodik undWerkzeugenen zu Design-Fehlern führen (late design breakage). Schwierige und teure

Wartung kann die Folge sein. Software-Entwickler sollten daher die ent-sprechende Vorgehensweisen kennen, um die Wünsche des Kunden alsAnforderungen einer Domäne festzuhalten und weiter das Fachwissen be-sitzen, die entsprechenden Technologien für die erforderte Funktionalitätauszuwählen und einzusetzen.

Als „Sprachen“ dienen in diesem Buch unter anderem die Unified Mode- Modellierung undVorgehensmodelleling Language (UML) sowie Vorgehensmodelle (RUP, SCRUM) und an-

1.1 Projektarten und -aspekte 3

dere Projektmanagement-Methoden zur Anforderungserhebung. In einemEntwicklerteam sowie in der Kommunikation mit dem Management undmit Kunden ist die frühzeitige Einigung auf die Vorgehensweise und diegewählten Werkzeuge sehr wichtig. Zudem haben nicht alle Teammitglie-der Kundenkontakt – die geplante Arbeit muss festgehalten und vom Pro-jektmanagement verteilt werden.

Ein kleines Projekt könnte beispielsweise die Entwicklung einer Rich-Cli-Kleines Projektent Applikation zur Verwaltung von Kundendaten sein. In der Umsetzungsind ein bis zwei Personen beteiligt, die sich am gleichen Standort befinden.Das primäre Ziel ist hier, ein kleines, funktionierendes Produkt zu erzeu-gen, das auf einer soliden und erweiterbaren Architektur aufbaut. Anwen-dung und Datenbank befinden sich auf demselben Rechner.

Bei einem mittleren Projekt sind etwa 3-20 Personen an der UmsetzungMittleres Projektbeteiligt. Es ist wahrscheinlich, dass sich nicht alle Personen am gleichenStandort befinden. Persönliche Treffen mit allen wesentlichen Beteiligtensind aber regelmäßig möglich. Es wird beispielsweise eine Webanwendungentwickelt. Die Anwendung und die Datenbank befinden sich auf unter-schiedlichen Systemen, beide müssen eine hohe Verfügbarkeit haben. Beimittleren Projekten findet wesentlich mehr Modellierung statt, da mehrereEntwickler beteiligt sind und diese sich auf ein gemeinsames Design eini-gen müssen, um eine einheitliche Projektstruktur zu gewährleisten.

An einem großen Projekt sind weit über 20 Personen beteiligt, die sich anGroßes Projektverschiedenen Standorten (vielleicht sogar unterschiedlichen Kontinenten)befinden. Aufgrund der hohen Anzahl an Beteiligten sind regelmäßige per-sönliche Treffen nicht leicht möglich und würden vermutlich auch nichtsehr produktiv sein. Das Projekt besteht beispielsweise aus einer verteil-ten Anwendung im Enterprise-Umfeld, das hohe Verfügbarkeit aufweisenmuss und eine sehr hohe Anzahl an Benutzern aufweist. Die Anwendungintegriert verschiedene bestehende Systeme und soll so Unterstützung beider Abwicklung des Kerngeschäfts bieten.

Nicht nur die Größe des Projekts ist ein kritischer Faktor. Auch die Kennt-Projektkomplexitätnis der Domäne, die Qualifikation des Entwicklerteams sowie die techni-sche Komplexität spielen eine wesentliche Rolle. Projekte, die beispiels-weise wenig erprobte Cutting-edge-Technologien einsetzen (müssen) oderals sehr innovativ zu betrachten sind, bergen unabhängig von der Mengeder Anforderungen naturgemäß höhere Risiken als Routineprojekte, die miteinem erfahrenen Team und bekannten Technologien umgesetzt werden.

Mit der Zunahme der Projektgröße und -komplexität aber werden andereMethodischesVorgehen Ansätze zur Bewältigung der zusätzlichen Komplexität in den Bereichen

Software-Engineering, Architektur und Design sowie Projektmanagementund Qualitätssicherung notwendig. Im Software-Engineering bedeutet diesin erster Linie die systematische Verwendung von Methoden mit Werk-zeugunterstützung wie z. B. Versionsverwaltung bzw. Konfigurationsma-nagement und Build- und Test-Automatisierung. Wenn der Projektmana-

4 1 Einleitung

gement-Bedarf an Organisation, Planung und Überblick steigt, kann eineWerkzeugunterstützung zwar helfen, jedoch muss prinzipiell noch inten-siver an dem jeweiligen Projektmanagementprozess festgehalten werden.Eine genaue Definition der Kommunikationspfade bzw. wer mit wem kom-muniziert ist notwendig. Der Testaufwand, ein großer Teil der Qualitätssi-cherung, steigt meist überproportional. Hier ist eine saubere Dokumentati-on wichtig, damit das Projekt nachvollziehbar bleibt.

Neben erfahrenen Mitarbeitern helfen also verbesserte Prozesse, Metho-den und Werkzeuge des Software-Engineering, den Aufwand für die Ent-wicklung und Validierung zu verringern. Ziel sind kleinere, handhabbarereProjekte zu dimensionieren (wie etwa in der agilen Software-Entwicklungangestrebt). Eine zu hohe Produkt-/Projektkomplexität ist ein besonderesRisiko, das auch durch das Hinzufügen von Mitarbeitern (besonders in spä-ten Phasen) nicht zu bewältigen ist [15].

1.2 Überblick zu Kapiteln und Themen

Kapitel 2 beschäftigt sich mit dem Lebenszyklus eines mittelgroßen Lebenszyklus einesSoftware-ProduktsSoftware-Produkts aus Expertensicht. Diese chronologische Beschreibung

kann den Entwicklerteams als Leitlinie dienen, um ein Software-Projektim Team erfolgreich zu strukturieren und abzuwickeln. Je nach Anwen-dungsbereich der Software-Lösung sind die jeweiligen Phasen eines Pro-duktlebenszyklus unterschiedlich ausgeprägt und für den Anwender un-terschiedlich wahrnehmbar, wie beispielsweise Wartungsprojekte, Migra-tionsprojekte, Projekte mit öffentlichen Ausschreibungen und klassischeSoftware-Entwicklungsprojekte. Im realen Projektverlauf ist natürlich eineAnpassung an den jeweiligen Anwendungsfall im jeweiligen Projektkon-text erforderlich. Dieses Kapitel behandelt alle Phasen eines Software-Pro-duktes und beschreibt ausgewählte und wichtige Aspekte in den einzelnenAbschnitten.

Kapitel 3 stellt traditionelle Prozesse vor, wie beispielsweise Wasserfallm- Vorgehensmodelleodell, V-Modell XT und Rational Unified Process sowie flexible und agileAnsätze, wie beispielsweise SCRUM. Typische Schritte im Entwicklungs-prozess, die im Rahmen des Produktlebenszyklus erläutert wurden, sindAnforderungserhebung, Entwurf und Design, Implementierung und Inte-gration, Verifikation und Validierung sowie Betrieb, Wartung und Evoluti-on. Diese Schritte benötigen eine passende Strategie, um die Produktent-wicklung effektiv vorantreiben zu können. Je nach Projekt und Anwen-dungsdomäne haben sich zahlreiche konkrete Vorgehensmodelle etabliert,aus denen die Strategie für einen Projektkontext auszuwählen und anzupas-sen ist.

Kapitel 4 beschreibt klassische Projektplanungsmethoden, versucht aber Projektmanagementauch den Zusammenhang mit agiler Entwicklung herzustellen. Das Pro-jektmanagement entwickelt, ausgehend von einem Projektauftrag, einen

1.2 Überblick zu Kapiteln und Themen 5

Projektplan, der die Arbeit strukturiert und realistische Schätzungen dererforderlichen Ressourcen sowie der Projektdauer erlaubt. Während Ma-nager Schätzverfahren verwenden können, um einen Gesamtprojektplan zuerstellen, ist es selbst für erfahrene Projektmanager oft schwer, die Dauervon technischen Arbeiten zu schätzen. Dies trifft vor allem dann zu, wenndie Implementierung auf neuen Technologien beruht. Entsprechend sindAnsätze zur Projektverfolgung und -steuerung notwendig, um den Plan imProjektverlauf mit der Realität abzustimmen.

Kapitel 5 beschreibt grundlegende Konzepte der Qualitätssicherung in derQualitätssiche-rung und Test-Dri-ven Development modernen Software-Herstellung, wie Software-Reviews, Inspektionen, Ar-

chitekturreviews und Konzepte des Software-Testens. Test-Driven Deve-lopment ist ein bewährtes Konzept im Rahmen der komponentenorientier-ten Software-Herstellung, um qualitativ hochwertige Produkte herstellenzu können. Konzepte, wie Continuous Integration und Daily Builds, tragenzur Verbesserung der zu erstellenden Software-Lösung und insbesonderezur frühzeitigen Sichtbarkeit des realen Entwicklungsfortschritts bei.

Kapitel 6 gibt einen Überblick zu Notationen und Methoden der Modellie-Notationen undMethoden derModellierung rung für die Entwicklung kommerzieller Software-Produkte. Im adminis-

trativen Bereich hat sich in den letzten Jahren die Unified Modeling Lan-guage (UML) als Notation und Basis für Methoden weitgehend durchge-setzt. Die Sammlung von Notationen und Methoden in diesem Kapitel wer-den durchgehend in diesem Buch eingesetzt, um Konzepte und Strukturenzu illustrieren und zu beschreiben.

Kapitel 7 beschäftigt sich mit der Strukturierung von Software-SystemenSoftware-Architekturund stellt einen Überblick verschiedener Architekturstile vor. Mit der zu-nehmenden Komplexität moderner Software-Systeme gewinnen die Soft-ware-Architektur und die Rolle eines Software-Architekten immer mehran Bedeutung. Die Architektur bringt klare Grenzen und Struktur in dieAnwendung, befasst sich aber nicht nur mit der statischen Systemstruktur,sondern legt auch besonderes Augenmerk auf nichtfunktionale Anforde-rungen, wie Skalierbarkeit, Performanz oder Verfügbarkeit.

Kapitel 8 soll als Referenz auf bestehende Lösungsansätze für die im vorhe-Entwurfs-, Archi-tektur-, und Inte-grationsmuster rigen Kapitel beschriebenen Architekturen für ein kleines bis mittelgroßes

Projekt dienen. Die hier beschriebene Einführung in Entwurfs-, Architek-tur- und Integrationsmuster kann helfen, wiederkehrende Aufgaben mit er-probten Ansätzen zu implementieren.

Kapitel 9 befasst sich mit der Frage, in welche Teile (Komponenten) sichKomponentenori-entierte Softwa-re-Entwicklung die Software zerlegen lässt, und ob manche Teile mit bereits bestehenden

Software-Produkten realisiert werden können. Wir betrachten in diesemBuch eine Komponente als austauschbaren Programmteil gröberer Granu-larität mit wohl definierten Schnittstellen nach außen. Generell zielen Kom-ponenten auf die Verbesserung der Wiederverwendung von Software-In-vestitionen ab und ermöglichen die Komposition komplexer Software-Sys-teme aus einfacheren Teilkomponenten sowie den einfacheren Austausch

6 1 Einleitung

von Systemteilen im Lauf der Wartung und Evolution eines Anwendungs-systems.

Kapitel 10 stellt konzeptionelle Aspekte von Werkzeugen und Praktiken Techniken undWerkzeugevor, die den Software-Entwicklungsprozess wesentlich unterstützen. In

heutigen Projekten ist es üblich eine ausgereifte Entwicklungsumgebung(IDE) mit umfangreichen Funktionen zu verwenden und darüber hinausWerkzeuge für Versionierung (SCM), Issue Tracking, Build Managementund Test Reporting, sowie Kollaborationswerkzeuge einzusetzen. DieseWerkzeuge sollen das strukturierte Arbeiten in einem Team unterstützen.

1.3 Empfohlene Vorkenntnisse

Zielgruppe dieses Buches sind Entwickler mit Grundkenntnissen der Pro- Zielgruppegrammierung, die einen Einstieg in moderne komponentenorientierte Ent-wicklung suchen.

Es wird vorausgesetzt, dass der Leser gute Kenntnisse zu algorithmischenStrukturen und Abläufen hat. Des Weiteren ist Erfahrung mit Konzeptender objektorientierten Programmierung für das Verständnis notwendig. Diemeisten Beispiele im Buch sind in Java programmiert, sind aber so gene-risch gehalten, dass man sie auch ohne spezielle Java-Kenntnisse verstehenbzw. die Konzepte leicht auf andere Plattformen übertragen kann.

Der Fokus dieses Buches liegt auf übergreifenden Aspekten des Softwa- Fokusre-Engineering. Technologien oder Konzepte, zu denen es bereits Spezial-literatur gibt, können hier nicht im Detail erklärt werden. Im Besonderentrifft dies auf folgende Themen zu:

Die Beispiele in diesem Buch sind weitgehend in Java gehalten, Ja- Javava-Kenntnisse sind daher von Vorteil. Eine der besten Einführungen in diewichtigsten Aspekte der Programmiersprache Java ist das „Handbuch derJava-Programmierung“ von Guide Krüger und Thomas Stark [62]. DiesesHandbuch ist auch online1 verfügbar.

Modelle werden in diesem Buch zumeist in der Unified Modeling Langua- UMLge (UML) dargestellt. In Kapitel 6 werden einige wichtige Diagramme undKonzepte ausreichend vorgestellt, um die Diagramme in diesem Buch zuverstehen. Für eine Vertiefung ist der UML User Guide von Rumbaugh,Jacobson und Booch [78] empfehlenswert.

Das relationale Datenbankmodell wird kurz in Abschnitt 9.4.7 eingeführt. Relationales ModellIn der Entwicklungspraxis ist ein wesentlich detaillierteres Verständnis so-wohl des relationalen Modells als auch der Verwendung relationaler Daten-banken (Schema, SQL, Administration, Interfaces etc.) erforderlich. Die

1http://www.javabuch.de

1.3 Empfohlene Vorkenntnisse 7

Modellierung mit Entity-Relationship Diagrammen wird in Abschnitt 6ebenfalls nur kurz erklärt. Als weiterführende Literatur wird „Relationa-le Datenbanksysteme: Eine praktische Einführung“ [59] empfohlen

Die extensible Markup Language (XML) steht im Zentrum einer VielzahlXMLvon Standards wie XML DTDs, Schemasprachen, XSL(T), XLink. Eineganz knappe Einführung wird in Abschnitt 9.4.9 gegeben. In den meistenProjekten wird man an vielen Stellen mit Standards aus dem XML-Um-feld konfrontiert, eine Beschäftigung mit diesem Themenbereich ist daherebenfalls ratsam. Die meisten XML-Standards sind offen spezifiziert undim Rahmen des World Wide Web Konsortium (W3C)2 publiziert. Auch dieWebservice Standards, die z. B. in Abschnitt 8.6.1 oder 9.1.4 erwähnt wer-den, sind XML-basierte W3C-Standards.

In Kapitel 5 wird ein Überblick von Software-Testen sowie eine kurze Be-Software-Testenschreibung von Test-Driven Development geboten. Vor allem für die An-wendung im Software-Engineering empfiehlt es sich, weitere vertiefendeLiteratur zu studieren. Hier ist das Buch „xUnit Test Patterns“ [69] vonGerard Meszaros sehr empfehlenswert.

1.4 Weitere Ressourcen im Web

Dieses Buch adressiert den Bedarf an einer Zusammenstellung pra-xiserprobter Werkzeuge und Methodiken für Entwickler im Team.Das Buch beschreibt langfristig gültige Konzepte und wird weiter-hin durch Ressourcen im Web ergänzt: unter der Adresse http://bpse.ifs.tuwien.ac.at sind größere zusammenhängende Bei-spiele zu finden, die die Beispiele im Buch ergänzen und erweitern.Weiterhin finden sich detailliertere technische Anleitungen zu Frame-works und Patterns sowie Dokumentvorlagen und Beispiele für dasProjektmanagement zum Download. Im Best-Practice Software-Enginee-ring Blog http://best-practice-software-engineering.blogspot.com diskutieren wir aktuelle Themen und Trends im Soft-ware-Engineering. Sie sind herzlich eingeladen, dort an der Diskussion zuteilzunehmen.

2http://www.w3c.org

8 1 Einleitung

1.5 Die Autoren

Alexander Schatten

ist Projektleiter des Best-Practice-Software-Engineering Projekts und ver-antwortlich für Design- und Integrationsmuster, Techniken undWerkzeuge,Aspekte der Software-Architektur, komponentenorientierte Entwicklung.Alexander Schatten ist Senior-Researcher am Institut für Software-Technikder TU Wien, Berater im Bereich von Software-Architekturen und Softwa-re-Engineering mit Schwerpunkt auf Open-Source-Systeme sowie Autorzahlreicher Artikel in Zeitschriften wie Infoweek oder iX3.

Markus Demolsky

ist Spezialist für Architektur- und Integrationsthemen mit langjährigerErfahrung in Analyse und Umsetzung internationaler Software-Projek-te. Sein besonderes Interesse gilt komponentenorientierten Open-Source-Technologien im Java-EE-Umfeld. In seiner selbstständigen Tätigkeit un-terstützt er Unternehmen bei der Auswahl von Open-Source-Technologienim Java-Umfeld und entwickelt Individualsoftware für KMUs. Außerdemschreibt er regelmäßig Fachartikel für das Javamagazin, Eclipsemagazinund die iX4.

Dietmar Winkler

ist Lehrbeauftragter und Forscher am Institut für Softwaretechnik an derTUWien mit den Schwerpunkten Software- und Systementwicklung, Qua-litätssicherung und Qualitätsmanagement sowie empirischer Softwaretech-nik. Aus diesen Tätigkeiten resultierten zahlreiche Publikationen bei inter-nationalen Konferenzen. Weiteres ist er als selbstständiger Berater für Qua-litätssicherung, Projekt-, Qualitäts- und Prozessmanagement in Konzeptio-nierung und Umsetzung in den Industriebereichen Automobilzulieferungund öffentliche Verwaltung tätig. Er ist verantwortlich für die Themenbe-reiche Software-Lebenszyklus, Vorgehensmodelle, Projektmanagement so-wie Qualitätssicherung 56.

Stefan Biffl

lehrt und forscht an der Fakultät für Informatik der TU Wien in den Berei-chen Software-Engineering, Qualitätssicherung und Projektmanagement.

3http://www.schatten.info4http://www.demolsky.at/de/team/mdy5http://qse.ifs.tuwien.ac.at/~winkler6und http://www.dwq-consulting.at

1.5 Die Autoren 9

Grundlegendes Interesse ist, im steten Wandel der Methoden und Werk-zeuge brauchbare Bündel von Ansätzen im Praxiskontext zu erproben underfolgreiche „Best-Practices“ für Studierende und Praktiker zugänglich zumachen. Die Ansätze im vorliegenden Buch basieren auf Konzepten, diesich in den letzten 20 Jahren in der Arbeit mit kleinen bis mittleren Pro-jektteams als erfolgreich erwiesen haben7.

Erik Gostischa-Franta

studiert an der TU Wien und ist Tutor in den Bereichen Software-Enginee-ring, Projektmanagement und Qualitätssicherung am Institut für Softwa-re-Technik. Besonderes Interesse besteht an agilen Methoden sowie struk-turiertem Vorgehen in der Software-Entwicklung mithilfe von definiertenProzessen. Diese Erkenntnisse gibt er an Studierende im Rahmen von Lehr-veranstaltungen weiter. Er hat Erfahrung mit Content-Management undmissions-kritischen Systemen in der Industrie sowie Software-Demonstra-tionen bei Messen und Präsentationen bei Kundenstellen. Erik Gostischa-Franta ist Hauptverantwortlich für die Projektmanagement- und Dokumen-tationsaspekte in diesem Buch mit Schwerpunkt auf der UML und dessenEinsatz im Software-Engineering-Umfeld.

Thomas Östreicher

studiert an der TU Wien und forscht am Institut für Software-Technik. Be-sonderes Interesse besteht an der Modellierung softwareintensiver Systemeund testgetriebenen agilen Methoden. Thomas Östreicher ist verantwort-lich für die Modellierungsaspekte in diesem Buch mit Schwerpunkt auf derUML.

1.6 Danksagung

Dieses Buch ist aus der Praxis unserer Erfahrung mit zahlreichen Soft-ware-Teams entstanden. Unser herzlicher Dank gilt insbesondere MichaelZöch, Lukas Lang, Dominik Dorn, Andreas Pieber, Christian Mastnak undAdam Zielinski für interessante Diskussionen sowie zahlreiche konkretekonstruktive Hinweise zur Verbesserung.

7http://qse.ifs.tuwien.ac.at/~biffl

10 1 Einleitung

2 Lebenszyklus einesSoftware-Produkts

Software-Produkte folgen – ebenso wie Produkte des täglichen Lebens,wie beispielsweise Mobiltelefone und Autos – einem Lebenszyklus, derbei der ersten Idee beginnt, den Entwicklungsprozess durchläuft, in die Be-triebs- und Wartungsphase übergeht und schlussendlich mit der kontrollier-ten Stilllegung des Produkts endet.

Dieses Kapitel behandelt alle Phasen eines mittelgroßen Software-Produktsaus Expertensicht und beschreibt ausgewählte und wichtige Aspekte in deneinzelnen Abschnitten. Diese chronologische Beschreibung kann den Ent-wicklerteams als Leitlinie dienen, um ein Software-Projekt im Team er-folgreich zu strukturieren und abzuwickeln. Je nach Anwendungsbereichder Software-Lösung sind die jeweiligen Phasen eines Produktlebenszyklusunterschiedlich ausgeprägt und für den Anwender unterschiedlich wahr-nehmbar, wie beispielsweise Wartungsprojekte, Migrationsprojekte, Pro-jekte mit öffentlichen Ausschreibungen und klassische Software-Entwick-lungsprojekte. Im realen Projektverlauf ist natürlich eine Anpassung an denjeweiligen Anwendungsfall im jeweiligen Projektkontext erforderlich.

Übersicht2.1 Grundlegende Phasen eines Lebenszyklusses . . . . . . . . 12

2.2 Übergreifende Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Anforderungen und Spezifikation . . . . . . . . . . . . . . . . . . . . . 17

2.4 Projektplanung und -steuerung . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Entwurf und Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6 Implementierung und Integration . . . . . . . . . . . . . . . . . . . . . 32

2.7 Betrieb und Wartung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.8 Vom Software-Lebenszyklus zum Vorgehensmodell . . . . 43

2.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

11

2.1 Grundlegende Phasen des Software-Lebenszyklusses

Ein Software-Prozessmodell bildet ein einheitliches Rahmenwerk für dieProzessmodell

Ablaufplanung eines Entwicklungsprojekts, wie sie beispielsweise durchdie ISO/IEC 12207 [47] oder durch das „Software-Engineering Body ofKnowledge“ (SWEBOK) [88] definiert sind. Grundsätzlich ist es natürlichauch möglich, Software ohne Plan, Rahmen oder Konzept zu erstellen. Indiesem sogenannten Build-and-Fix-Verfahren werden Anforderungen quasiBuild-and-Fix„auf Zuruf“ umgesetzt und bestehende Lösungen geändert oder erweitert.Diese unsystematische und unstrukturierte Vorgehensweise mag bei sehrkleinen Software-Lösungen zwar mehr oder weniger gut funktionieren, dasProdukt wird jedoch durch sehr viele unkontrollierte Änderungen im Laufder Zeit schnell unübersichtlich und dadurch unwartbar, unprüfbar, unplan-bar und schlicht unbrauchbar. Aufgrund dieser Nachteile ist dieses Vorge-hen für Software-Projekte (auch bei scheinbar kleinen Lösungen) denkbarungeeignet und entwickelt sich schnell zu einer Kostenfalle.

Software-Engineering – als Ingenieursdisziplin – beschäftigt sich mitder systematischen und strukturierten Herstellung von Software-Produk-Systematische und

strukturierte Soft-ware-Entwicklung ten [83]. Ein wesentlicher Aspekt ist dabei der geregelte (also systema-

tische und strukturierte) Ablauf eines Software-Entwicklungsprojekts. Imeinfachsten Fall umfasst dieser Ablauf den gesamten Lebenszyklus einesSoftware-Produkts, von der Konzeptionierung über Analyse, Design, Im-plementierung und Test bis zur Betriebs- und Wartungsphase. Der Lebens-zyklus endet mit dem kontrollierten Außerbetriebsetzen des Software-Pro-dukts.

Die einzelnen Phasen eines Software-Projekts werden dabei vom Projekt-Projekt- undQualitätsmanagement

begleiten einSoftware-Projekt

management (PM) und dem Qualitätsmanagement (QM) begleitet. Sie un-terstützen die Steuerung des Projektablaufs unter Berücksichtung von Zeit-,Kosten- und Qualitätsaspekten im Hinblick auf die zu erstellenden Pro-dukte. Definierte Zeitpunkte innerhalb des Projektablaufs, sogenannte Ent-scheidungspunkte (Decision Gates) oder Meilensteine (Milestones) tren-nen die einzelnen Phasen in einem Projektplan ab. Diese Zeitpunkte stellenFixpunkte für das Projekt- und Qualitätsmanagement dar, um den Projekt-fortschritt zu beobachten und gegebenenfalls steuernd einzugreifen, fallsdas angestrebte Qualitätsniveau zu diesem Zeitpunkt nicht den definiertenErwartungen entspricht. Dazu ist es notwendig, entsprechende Kennzahlenund Metriken zur Erhebung des Projektstatus aus der Sicht des Projekt-Kennzahlen und

Metriken zurProjektverfolgung managements (siehe Kapitel 4) und des Qualitätsmanagements (siehe Ka-

pitel 5) einzuführen. Diese Kennzahlen und Metriken dienen als Entschei-dungsgrundlage für den Projekt- und Qualitätsleiter, um beispielsweise imRahmen eines Vorgehensmodells (siehe Kapitel 3) zusätzliche Iterationeneinzuplanen (etwa in einem inkrementellen Vorgehensmodell) oder weitereMaßnahmen zur Qualitätssicherung (siehe Kapitel 5) anzustoßen.

12 2 Lebenszyklus eines Software-Produkts

Abbildung 2.1Basiskonzept des

Software-Lebenszyklus.

Abbildung 2.1 visualisiert die vier grundlegenden Schritte des Lebens-zyklusses sowie eine detailliertere Gliederung anhand konkreter Pha- Vier grobe Phasensen [83]. Die Schritte Software-Spezifikation (Projektdefinition und -pla-nung), Design und Implementierung (Detailplanung und konkrete tech-nische Umsetzung), Software-Validierung (Überprüfung des Produkts imHinblick auf die Spezifikation und auf die Kundenwünsche) und Soft-ware-Evolution (Weiterentwicklung des Produkts) bilden eine sehr grobeStruktur eines Software-Projekts und finden sich nahezu in allen Projek-ten wieder. Eine detailliertere Betrachtung des Software-Lebenszyklussesbeinhaltet eine feinere Untergliederung dieser vier groben Phasen, die inweiterer Folge detaillierter behandelt werden. Die technischen Phasen bein-halten dabei Anforderungen & Spezifikation, Planung, Entwurf & Design,Implementierung & Integration, Betrieb & Wartung sowie Stilllegung.

Projekt- und Qualitätsmanagement sind übergreifende Aktivitäten mit de-finierten Schnittstellen zu allen technischen Phasen. In weiterer Folge wer-den wichtige Aspekte in den jeweiligen Phasen des Software-Lebenszy-klusses im Sinn von Best-Practice Software-Engineering identifiziert undim Überblick dargestellt.

2.2 Übergreifende Aktivitäten

Begleitend zu den unterschiedlichen technischen Phasen im Rahmen ei-nes Software-Entwicklungsprojekts sind übergreifende Aktivitäten erfor-derlich, um einen erfolgreichen Projektablauf zu ermöglichen. Dies sindim Wesentlichen Projektmanagement und Qualitätsmanagement.

2.2.1 Projektmanagement

Das Projektmanagement (PM) beschäftigt sich mit der Planung, Kontrolle Planung, Kontrolle,Steuerungund Steuerung von Projekten und stellt einen organisatorischen Rahmen für

eine erfolgreiche Projektabwicklung zur Verfügung. Gemäß DIN 69901 istein Projekt ein „Vorhaben, das im Wesentlichen durch die Einmaligkeit der

2.2 Übergreifende Aktivitäten 13

Bedingungen in ihrer Gesamtheit gekennzeichnet ist“ [24]. Diese Bedin-gungen umfassen sowohl Zielvorgaben des Projekts und konkrete Anfor-derungen an das zu erstellende Produkt, als auch finanzielle, zeitliche undpersonelle Restriktionen und sich daraus ergebende Risiken. Diese Aktivi-„Software-Enginee-

ring is a value-ba-sed contact sport“ täten werden von zahlreichen Faktoren beeinflusst: So ist die Planung von

Projekten nicht nur vom anfallendem Aufwand und den zur Verfügung ste-henden Ressourcen und Personen abhängig, sondern unter anderem auchvon ihren technischen und fachlichen Fähigkeiten, sowie ihrem sozialemUmgang in einem Team. „Software-Engineering is a value-based contactsport“, wie es Barry Boehm treffend beschreibt [13]. Das bedeutet, dassjedes Teammitglied seinen Beitrag zum Gesamtprojekt leistet und somitauch einen Anteil am Projekterfolg hat. Aufgrund der Bedeutung des Pro-jektmanagements in einem Software-Entwicklungsprojekt ist diesem The-menschwerpunkt das Kapitel 4 gewidmet.

2.2.2 Qualitätsmanagement

Unter Qualitätsmanagement (QM) versteht man alle zu erfüllenden Aufga-Herstellen hoch-wertiger Produkte ben, die zur Herstellung eines qualitativ hochwertigen Produkts notwendig

sind. Qualitätsmanagement und Projektmanagement ergänzen einander undbegleiten das Software-Entwicklungsprojekt über den gesamten Lebenszy-klus. In der Praxis zielt Projektmanagement eher auf technische, finanzielleund planerische Aspekte ab, Qualitätsmanagement rückt den qualitativenKundennutzen in den Vordergrund. Eine konkrete Definition von „Quali-tät“ findet sich beispielsweise in der ISO 9000: „Die Beschaffenheit einerEinheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erforder-nisse zu erfüllen“ [49]. In Anlehnung an diese Definition verwenden wirden Qualitätsbegriff in diesem Buch aus zwei unterschiedlichen Sichten:Sichten auf Qualität

1. Erfüllung der spezifizierten Eigenschaften eines Produkts: Diese Sicht-weise beleuchtet das Produkt im Hinblick auf die spezifizierten Vor-gaben, also ob die erstellte Lösung auch der Spezifikation entspricht,das Produkt also richtig erstellt wurde. Diese Sichtweise wird generellauch als Verifikation bezeichnet.

2. Erfüllung der vom Kunden gewünschten Eigenschaften eines Produkts:Diese Sichtweise rückt den Kundenwunsch und die Kundenanforde-rungen in den Vordergrund, also ob das richtige Produkt erstellt wurde.Diese Sichtweise wird auch als Validierung bezeichnet.

Zentrale Fragestellungen sind, (a) welche Eigenschaften ein Software-Produkt erfüllen muss und wie man dazu kommt, (b) wie diese Eigen-schaften effizient umgesetzt werden können und (c) wie die umgesetz-ten Eigenschaften überprüft werden können. Produkteigenschaften lassensich beispielsweise aus den Kundenanforderungen und anderen übergeord-neten Vorgaben, etwa gesetzliche Regelungen, ableiten (siehe dazu Ab-


Abbildung 2.2Qualitätsmerkmale nach

ISO/IEC 9126-1 [50].

schnitt 2.3). Die Umsetzung erfolgt typischerweise – je nach Anwendungs-domäne – über ein konkretes Vorgehensmodell (siehe dazu Kapitel 3). ZurÜberprüfung (Verifikation und Validierung) der erstellten (Teil-)Lösungkönnen geeignete Maßnahmen aus dem Bereich Qualitätssicherung einge-setzt werden (siehe dazu Kapitel 5).

Die Eigenschaften eines Produkts lassen sich zwar direkt aus den Kun- Ordnungsrahmenvon Produkteigen-schaftendenanforderungen ableiten, allerdings empfiehlt sich hier die Verwendung

eines Ordnungsrahmens, um eine gewisse Vollständigkeit zu erreichen.Wichtig ist hier nicht nur die Betrachtung der funktionalen Anforderungen,sondern auch begleitender Anforderungen, die zwar nicht direkt ersichtlichsind, aber für ein erfolgreiches Produkt unumgänglich sind.

Beispielsweise stellt die ISO International Organization for Standardiza-tion einen Klassifikationsansatz zur systematischen Einteilung von Qua-litätseigenschaften oder -merkmalen zur Verfügung. Abbildung 2.2 fasstwichtige Qualitätsmerkmale in Anlehnung an die ISO/IEC 9126-1 zusam-men [50]. Diese Klassifikation ermöglicht eine systematische Betrachtung Qualitätsmerkmale

nach ISO/IEC 9126-1der Kundenanforderungen im Rahmen der Anforderungsanalyse (siehe Ab-schnitt 2.3). Dieser Klassifikationsansatz beschreibt eine grobe Einteilungvon Qualitätsmerkmalen:

> Das Qualitätsmerkmal Funktionalität umfasst alle (funktionalen) An-forderungen an das System, d. h., welche Aufgaben durch die zu er-stellende Lösung erfüllt werden sollen, z. B. bezüglich Korrektheit undSicherheit.

> Die Zuverlässigkeit beschreibt die Fähigkeit eines Systems, die ver-langte Funktionalität unter gegebenen Randbedingungen in gegebenerZeit zu erfüllen, z. B. Produktreife und Fehlerverhalten.

> Die Benutzbarkeit definiert die Verwendbarkeit durch den Endanwen-der, wie z. B. Verständlichkeit der Benutzerführung und Erlernbarkeitdurch den Anwender. In diese Kategorie fällt typischerweise die Ge-staltung der Benutzeroberfläche.

2.2 Übergreifende Aktivitäten 15

> Die Effizienz umfasst primär das Zeitverhalten bzw. das Ausmaß, indem ein System seine Leistungen mit einem Minimum an Ressourcenerbringen kann.

> Änderbarkeit ist eine Eigenschaft, vorgegebene Änderungen oder Er-weiterungen an dem Software-Produkt durchführen zu können.

> Übertragbarkeit bezeichnet die Fähigkeit, das Software-System in ei-ne andere Umgebung (z. B. auf eine andere Plattform) zu übertragenbzw. dort einzusetzen.

Aufgrund der unterschiedlichen Anforderungen an die Produkte ist meistJedes Projekt istunterschiedlich nur eine Auswahl der genannten Qualitätsmerkmale relevant. Im Rahmen

des Projekts sollte man aber zumindest über alle Qualitätsmerkmale nach-denken, um den notwendigen Bedarf zu hinterfragen. Die Auswahl der re-levanten Qualitätsmerkmale hängt auch von der Anwendungsdomäne ab. Jenachdem, ob ein administratives Software-System (etwa ein Informations-system) oder eine sicherheitskritische Anwendung (etwa eine Kraftwerks-steuerung) erstellt werden soll, sind andere Aspekte der Qualitätsmerkmalezu betrachten und eine geeignete Vorgehensweise zu definieren.

Sind die Anforderungen und Merkmale definiert, kann das Projekt sauberstrukturiert, geplant und umgesetzt werden – sofern die Anforderungen sta-bil bleiben. In diesem Fall bieten sich systematische Software-Prozesse an,wie sie im Kapitel 3 beschrieben werden. In einigen Fälle (beispielsweiseim öffentlichen oder im sicherheitskritischen Bereich) sind diese systema-tischen Vorgehensweisen auch explizit vorgeschrieben.

In der gängigen Praxis stehen die Anforderungen und erwarteten Merkma-le leider nicht bereits zu Beginn fest und bleiben auch nicht stabil. Dahermuss man davon ausgehen, dass sich Anforderungen und Merkmale lau-fend (auch häufig) ändern können und auch werden. Vor diesem Hinter-grund sind agile Ansätze gefragt, die auf diese Änderungen geeignet rea-gieren können. Beispielsweise empfiehlt sich hier ein agiler Ansatz, derdas Projekt inkrementell aufbaut. Beispiele für diese Modelle, wie etwaSCRUM, werden in Kapitel 3.8 erläutert. Obwohl in zahlreichen Projek-ten eine agile Vorgehensweise verfolgt wird, sind dennoch Anforderungen(beispielsweise Plattformabhängigkeit oder Skalierbarkeit), die einen di-rekten Einfluss auf die Architektur haben, frühzeitig zu berücksichtigen. Insolchen Fällen gilt es, die Produktqualität frühzeitig einzuschätzen und zuverbessern. Dabei ist es wichtig, Fehler möglichst frühzeitig zu erkennenFrühzeitige

Fehlererkennungund Korrektur und zu korrigieren, da die Kosten dramatisch ansteigen, je später ein Fehler

im Produkt erkannt wird. Reviews und Inspektionen als statische Methodenund Software-Testen als dynamische Methode sind weitverbreitete Metho-den der Qualitätssicherung (siehe dazu Kapitel 5).


2.2.3 Reviews und Inspektionen

Reviews und Inspektionen sind analytische Methoden der Qualitätssiche-rung, die eine systematische Fehlererkennung (und Lokalisierung) währenddes gesamten Entwicklungsprozesses ermöglichen. Besonders bewährt ha-ben sich Reviews in Inspektionen speziell in frühen Phasen der Entwick-lung, da – im Gegensatz zu Tests – kein ausführbarer Softwarecode be-nötigt wird. Reviews und Inspektionen können beispielsweise für Anfor-derungen, Design, Testfälle aber natürlich auch Softwarecode eingesetztwerden. Je nach Schwerpunkt existieren Ansätze, die unterschiedliche Feh-ler- und Risikoklassen oder Dokumenttypen adressieren. Neben speziellenAnwendungen, wie beispielsweise Design-Inspections oder Code-Reviews,werden sie typischerweise auch für die Freigabe von Dokumenten bei Mei-lensteinen oder an Phasengrenzen eingesetzt. Reviews und Inspektionen als Analytische

Methoden der QSwichtige Vertreter analytischer Methoden der Qualitätssicherung sowie diekonkrete Vorgehensweisen werden in Abschnitt 5.3 detailliert beschrieben.

2.2.4 Software-Tests

Im Gegensatz zu Reviews und Inspektionen benötigen Software-Tests aus- TraditionelleProzesseführbaren Code, der in traditionellen Prozessen, wie beispielsweise im

Wasserfallmodell (siehe Abschnitt 3.2), typischerweise erst recht spät imEntwicklungsprojekt vorliegt. Diese Tests finden auf unterschiedlichenEbenen (beispielsweise Komponenten- oder Unittests, Integrationstests undSystem- oder Abnahmetests) Anwendung und erfüllen unterschiedlich defi-nierte Aufgaben. Testansätze werden ebenfalls im Kapitel „Qualitätssiche-rung und Test-Driven Development“ in Abschnitt 5.6 detailliert beschrie-ben.

Test-Driven Development (oder auch Test-First Development) ist ein An- Test-DrivenDevelopmentsatz aus dem Bereich der agilen Software-Entwicklung, bei dem Imple-

mentierung und Test quasi parallel ablaufen. Die Grundidee dabei ist, zuerstdie Testfälle (zur Beschreibung der Funktionalität) zu erstellen und erst imAnschluss daran die eigentliche Funktionalität zu implementieren und zutesten. Diese Vorgehensweise hat unter anderem den Vorteil, dass die An-forderungen in Form von Testfällen klar und nachvollziehbar dokumentiert(und auch verstanden) sind und entsprechend umgesetzt werden können(siehe dazu Kapitel 5).

2.3 Anforderungen und Spezifikation

Anforderungen (Requirements) stehen am Beginn jedes Software-Entwick- „The hardest singlepart of building a sys-tem, is deciding whatto build.“ (Boehm,1997)

lungsprojekts. Im Rahmen der Anforderungen wird definiert, welches Pro-blem gelöst werden soll und welche Leistung das geplante Produkt erbrin-gen soll. Durch die Berücksichtigung möglichst aller beteiligten Personen

2.3 Anforderungen und Spezifikation 17

(Stakeholder) gestaltet sich beispielsweise der erste Kontakt zwischen Auf-traggeber (Kunde) und Entwickler sehr facettenreich. Die Sicht des Kundenauf das Produkt wird von seinem eigenen Nutzen geprägt sein – allerdingsweiß er häufig nicht genau, was er wirklich will und wie das Vorhaben rea-lisiert werden kann. Der Entwickler hat seine eigene (oft technische) Sichtauf das Projekt und hat ebenfalls keine genaue Vorstellung, was der Kundetatsächlich braucht. Er verfügt aber über das notwendige Know-how mög-licher technischer Lösungen, die – aus dem Blickwinkel des Entwicklers –den Vorstellungen des Kunden entsprechen könnten. In der Anforderungs-phase (Requirements Definition) muss es also einen Kompromiss aller be-teiligten Personen geben, sodass einerseits klar ist, was der Auftraggeberbenötigt und erwartet und andererseits, was der Entwickler wie verwirkli-chen kann und soll.

Die Anforderungsanalyse oder Anforderungsspezifikation beschreibt denSystematischeAnforderungsanalyse Kompromiss aller beteiligten Stakeholder im Hinblick auf das zu erstellen-

de Produkt aus der aktuellen Sicht aller Beteiligten. Typische Kompromis-se betreffen beispielsweise die Funktionalität, natürlich die Kosten, einenrealisierbaren Abgabetermin und andere Leistungsparameter, wie beispiel-weise die Zuverlässigkeit des Produkts. Je nach Projekt erstellt das Team,das sowohl Vertreter von Kunden und Anwendern als auch Vertreter desEntwicklungsteams umfassen soll, im Rahmen der AnforderungsanalyseProdukte, wie beispielsweise Systembeschreibungen, Begriffsverzeichnis-se zur Verbesserung des gemeinsamen Verständnisses, Schnittstellendefini-tionen, Story-Boards, Anwendungsfalldiagramme und entsprechende Be-schreibungen und Prototypen. Nach Fertigstellung der Anforderungsspezi-fikation erfolgt typischerweise eine qualitätssichernde Maßnahme – meistein Review oder eine Inspektion, um die erstellten Produkte im Hinblickauf Richtigkeit, Vollständigkeit und Konsistenz zu prüfen. In vielen Fäl-len, beispielsweise in öffentlichen oder sicherheitskritischen Projekten, istdiese Anforderungsspezifikation Vertragsbestandteil und dient als Basis fürdie weitere Projektplanung. Das setzt jedoch voraus, dass die Anforderun-gen weitgehend stabil sind.

In der gängigen Praxis können sich diese Anforderungen jedoch häufig än-Iterationendern, vor allem, wenn sich der Kunde noch nicht im Klaren ist, was kon-kret umgesetzt werden soll, oder dem Entwickler nicht klar ist, was derKunde genau benötigt. In diesem Fall empfiehlt sich ein agiler Ansatz mitmehreren Iterationen, die auf einer stabilen Architektur aufbauen. In der-artigen Projekten ist es durchaus üblich, nur wichtige Teile (beispielswei-se Anforderungen mit hoher Priorität) eines Projekts in einer Iteration zubetrachten und im Rahmen der Anforderungsanalyse zu bearbeiten. DieAnforderungsanalyse kann daher als Teil einer Iteration betrachtet werden,die bei jedem neuen Durchlauf an aktuelle Gegebenheiten angepasst wird.SCRUM ist ein typischer Vertreter eines agilen Prozesses, der diesem An-satz folgt (siehe Abschnitt 3.8). In jedem Fall ist es notwendig, die Anfor-derungen des Kunden an das zu erstellende System explizit zu betrachten.


Warum sind Anforderungen aber so wichtig?

> Anforderungen repräsentieren die „reale Welt“ und drücken das ge- Warum sind Anforde-rungen wichtig?wünschte Verhalten aus Nutzersicht aus. Der Anwender muss mit dem

Produkt arbeiten können.

> Unterschiedliche Stakeholder (etwa Kunde/Anwender und Entwick-ler) haben unterschiedliche Interessen und Erwartungshaltungen undbetrachten das Projekt aus ihren individuellen Blickwinkeln (abhän-gig vom individuellen Fachwissen).

> Durch Anforderungen wird ein gemeinsames Verständnis über dieLeistung des Produkts hergestellt.

> Typischerweise werden Anforderungen in Textform beschrieben bzw.grafisch dargestellt. Dazu bieten sich beispielsweise Story-Boards,User-Stories oder eine Modellierung der Anforderungen an (beispiels-weise mittels UML Use-Cases, wie sie in Abschnitt 6.1.2 beschriebenwerden).

> Anforderungen müssen testbar und nachvollziehbar sein! Werkzeugefür das Anforderungsmanagement wie etwa „Doors“ oder „RationalRequisite Pro“ unterstützen das Team bei der Bearbeitung, Nachver-folgung und Organisation von Anforderungen.

Eine zentrale Herausforderung in der Software-Entwicklung sind instabile,unvollständige und unklare Anforderungen. Im Idealfall gilt es, diese Än-derungen an den Anforderungen zu reduzieren oder gänzlich zu vermeiden.Die Praxis sieht allerdings anders aus: Änderungen treten während des ge-samten Projekts auf. Dementsprechend ist ein kontrollierter Umgang mitsich ändernden Anforderungen unumgänglich. Eine Grundvoraussetzungdafür ist aber, dass das „Fundament“, wie beispielsweise die Architektur,stabil bleibt. Kritische Änderungen, die beispielsweise die Architektur unddas Design betreffen, können hohe Kosten für Korrekturen hervorrufen undbis zum Projektabbruch führen. Untersuchungen im industriellen Umfeldzeigen diese Tatsache deutlich auf.

Der Chaos-Report dokumentiert Ergebnisse aus einer Untersuchung von Chaos-Reportüber 8300 Anwendungen bei 365 Unternehmen im Hinblick auf Projekt-fehlschläge. Die häufigsten Gründe für den Projektabbruch betreffen denProblembereich Anforderungen [17]. Die Abbildung 2.3 beschreibt die Er-gebnisse des Chaos-Report im Überblick. Anforderungen beschreiben denKundenwunsch an ein Software-System, um ein konkretes Problem zu lö-sen. Daher sollte möglichst frühzeitig feststehen, was der Kunde konkretbenötigt, um eine qualitativ hochwertige Lösung erstellen zu können. Dadas in vielen Fällen nicht möglich ist und die Anforderungen instabil sind,empfiehlt sich ein iterativer Prozess um – aufbauend auf einem stabilen


9,9%

4,3%

6,2%

7,5%

8,1%

8,7%

9,3%

9,9%

10,6%

12,4%

13,1%

0% 5% 10% 15%

Sonstiges

10. Mangelhafte Technologiekenntnisse

9. Mangelhaftes IT Mangement

8. Produkt wird nicht mehr benötigt

7. Mangelhafte Planung

6. Änderung von Anforderungen

5. Mangel an Managementunterstützung

4. Unrealistische Erwartungen

3. Mangel an Resourcen

2. Mangelnde Einbeziehung der Anwender

1. Unvollständige Anforderungen

Abbildung 2.3Chaos-Report [17].

Fundament (der Architektur) – das System schrittweise zu entwickeln. Un-abhängig davon, sind neben den Endanwendern alle involvierten Stake-holder (Rollen innerhalb des Entwicklungsteams, Kunden, Endanwenderund Wartungspersonal) zu berücksichtigen, da unterschiedliche Rollen ty-pischerweise unterschiedliche Sichten auf das Projekt haben. Generell stelltsich aber die Frage, welche Arten von Anforderungen überhaupt existierenund wie diese möglichst vollständig erfasst und beschrieben werden kön-nen.

2.3.1 Arten von Anforderungen

Zur vollständigen Bearbeitung von Anforderungen ist es sinnvoll, Anfor-Klassifikation vonAnforderungen derungen in unterschiedliche Kategorien zu klassifizieren. Generell lassen

sich Anforderungen in vier grobe Kategorien einteilen [71]:

> Funktionale Anforderungen bilden das eigentliche Systemverhaltenund die jeweiligen Funktionen des zu erstellenden Produkts ab.

> Nichtfunktionale Anforderungen zielen auf Qualitätsmerkmale ab, diebeispielsweise auf die Leistungsfähigkeit des Systems abzielen. Einemögliche Klassifizierung dieser nicht funktionalen Anforderungen istin Abbildung 2.2 im Rahmen eines Qualitätsmodells dargestellt.

> Designbedingungen legen die technischen Rahmenbedingungen, wiebeispielsweise Entwicklungsumgebung und Zielplattform fest.

> Prozessbedingungen definieren die Rahmenbedingungen für die Ent-wicklung des Software-Produkts in dem ein konkretes Vorgehen defi-niert wird.

Funktionale Anforderungen (Functional Requirements) umfassen und be-FunktionaleAnforderungen schreiben das erwartete Systemverhalten aus der Sicht unterschiedlicher

Stakeholder, etwa aus der Sicht eines Kunden (Customer), Endanwenders


(User) oder eines Entwicklers (Developer). Eine zentrale Herausforderungim Rahmen der Anforderungserhebung und -definition ist die Herstellungeines gemeinsamen Verständnisses der zu erstellenden Software-Lösung,da die Projektteilnehmer typischerweise aus unterschiedlichen Domänenstammen und ein unterschiedliches Vokabular, Begriffsverständnis und eindomänenspezifisches Hintergrundwissen mitbringen. Erst ein gemeinsa-mes Verständnis der zu erstellenden Software-Lösung ermöglicht auch eineerfolgreiche Projektdurchführung. UML Anwendungsfalldiagramme (Use-Cases) sind ein geeigneter Ansatz zur Visualisierung der Anforderungen(speziell für funktionale Anforderungen) in einem System. In der agilenSoftware-Entwicklung haben sich sogenannte User-Stories, Story-Boardsund Feature-Lists etabliert, die für die Beschreibung von Anforderungeneingesetzt werden. Diese Darstellungsarten werden im Kapitel 6 vorge-stellt.

Während funktionale Anforderungen direkt das Systemverhalten beschrei- Nicht funktionaleAnforderungenben und die jeweiligen Funktionen in den Vordergrund rücken, beschreiben

nicht funktionale Anforderung (Non-Functional Requirements) zusätzlicheSystemattribute und Qualitätsmerkmale, die nicht unmittelbar die Funktio-nalität des Systems adressieren. Derartige nicht funktionale Anforderun-gen umfassen beispielsweise Anwenderfreundlichkeit (Usability), Effizi-enz oder Performance. Die ISO/IEC 9126-1 stellt etwa einen Ordnungsrah-men für die Klassifikation von unterschiedlichen Anforderungsklassen be-reit (siehe Abbildung 2.2) [50]. Während die Überprüfung der funktionalenAnforderungen recht einfach zu sein scheint, müssen auch nicht funktiona-le Anforderung überprüfbar sein (siehe dazu Kapitel 5).

Bei der Erhebung von Anforderungen müssen nicht nur die produktrelevan- Designbedingungenten Eigenschaften, sondern auch Eigenschaften, die auf den Herstellungs-prozess abzielen, adressiert werden. Diese Design- und Prozessbedingun-gen beeinflussen den Prozessablauf und somit auch den Projektverlauf.De-signbedingungen (Design Constraints) beschreiben die technischen Rah-menbedingungen, die bei der Entwicklung zu berücksichtigen sind. Desi-gnbedingungen umfassen beispielsweise die zu verwendende Software-Ar-chitektur, Zielplattform oder definieren eine verteilte Nutzung der Anwen-dung. Bei der Überprüfung müssen diese Designbedingungen ebenfalls be-rücksichtigt werden.

Prozessbedingungen (Process Contraints) definieren die grundlegende Vor- Prozessbedingungengehensweise bei der Entwicklung eines Software-Produkts. Sie legen alsoden konkreten Software-Prozess fest, der für das aktuelle Projekt anzuwen-den ist und definieren die einzusetzenden Methoden zur Erstellung der Pro-dukte im Rahmen des Projekts. Beispielsweise können hier Vorgehensmo-delle (siehe Kapitel 3) zum Einsatz kommen. Je nach Projektumfeld eignensich systematische und strukturierte Prozesse (beispielsweise für sicher-heitskritische Anwendungen oder Projekte im öffentlichen Bereich) aberauch agile Ansätze (beispielsweise bei instabilen Anforderungen oder beiinkrementellen Entwicklungen) zur Durchführung des Projekts. In der in-


dustriellen Praxis ist ein Trend von den „schwergewichtigen“ hin zu fle-xiblen (agilen) Prozessmodellen feststellbar. In jedem Fall sollten Prozesseeingesetzt werden, die auf den jeweiligen Anwendungsfall oder das Un-ternehmen abgestimmt sind (Process Tailoring). Tailoring ermöglicht dieAnpassung eines konkreten Vorgehensmodells an individuelle Projektge-gebenheiten (siehe Abschnitt 3.9). Im öffentlichen Bereich hat sich bei-spielsweise das V-Modell XT [43] etabliert, das unter anderem auch Me-chanismen für Prozesstailoring beinhaltet (siehe Abschnitt 3.4). Das V-Mo-dell XT wird bei der Vergabe von Projekten im öffentlichen Bereich auchzunehmend im Rahmen der Ausschreibung gefordert, wobei das V-ModellXT auch agile Projektdurchführungsstrategien unterstützt – also auch demaktuell feststellbaren Trend in der industriellen Praxis folgt.

2.3.2 Anforderungsprozess

Aufgrund der Vielzahl an unterschiedlichen Anforderungen ist es sinnvoll,Anforderungsprozessbei der Erhebung von Anforderungen einem definiertem Prozess zu fol-gen. Dadurch wird einerseits die Nachvollziehbarkeit und Vollständigkeitals auch ein gewisses Maß an Qualität der Anforderungen ermöglicht.

Sowohl die möglichst vollständige Erhebung von Anforderungen (oder vonStabilität vonAnforderungen Teilen von Anforderungen im Rahmen einer Iteration) als auch die Über-

prüfung der definierten Anforderungen unter Berücksichtigung aller rele-vanter Rollen (Stakeholder) ist zeitaufwändig und nicht trivial. Je nach Sta-bilität der Anforderungen muss eine geeignete Vorgehensweise (Softwa-re-Prozess) gewählt werden, um die Anforderungen zielgerichtet umsetzenzu können. Bei stabilen und sich kaum mehr ändernden Anforderungenkann ein systematisches und phasenorientiertes Prozessmodell, wie etwadas V-Modell (siehe Abschnitt 3.3), gewählt werden; sind die Anforderun-gen instabil und ändern sich während des Entwicklungsprozesses häufig,sollte eher ein agiler Ansatz, wie etwa SCRUM (siehe Abschnitt 3.8), ein-gesetzt werden.

Je nach Projektgröße existieren unzählige Anforderungen in verschiedenenPriorisierung vonAnforderungen Kategorien, die im Projekt umgesetzt werden sollen. Allerdings sind nicht

alle Anforderungen gleich wichtig, daher sollten Überlegungen über dieReihenfolge der Umsetzung angestellt werden. Eine Priorisierung von An-forderungen in must-be-, expected- und nice-to-have-Kritieren ist im prak-tischen Umfeld sehr empfehlenswert. Must-be- und nice-to-have-Kriteriensind im Regelfall einfach fassbar, da diese typischerweise transparent sindund klar kommuniziert werden. Speziell in agilen Prozessen wie SCRUMist diese Priorisierung sowie der Umgang mit Änderungen in der Priorisie-rung ein wesentlicher Teil des Prozesses.

Erwartete Anforderungen (expected) an ein System werden zwar impli-zit angenommen, aber in seltenen Fällen auch explizit bekannt gegeben.Diese Erwartungen sind in unterschiedlichen Anwendungsdomänen auch


Abbildung 2.4 Prozesszur Anforderungs-

erhebung [71].

unterschiedlich – je nach Erwartungshaltung der involvierten Stakehol-der. Die Herausforderung besteht darin, implizite Anforderungen explizit Implizite

Anforderungenexplizit definierenzu machen, um sie entsprechend umsetzen und auch überprüfen zu kön-

nen. Je nach Hintergrund und Erfahrung der beteiligten Stakeholder exis-tieren unterschiedliche (eventuell auch sich widersprechende) Erwartungs-haltungen. Beispielsweise kann die Einfachheit der Benutzerführung unter-schiedlich interpretiert werden: Der Endkunde könnte erwarten, mithilfe ei-nes Wizzards oder Assistenten durch einen Bestellvorgang durchgeführt zuwerden. Ein Entwickler könnte eine einfache Benutzerführung durch eineklare Strukturierung der Menüs ausdrücken. Daher ist es erforderlich, al-le (auch implizit angenommene) Anforderungen explizit zu definieren undgegebenenfalls zu diskutieren. In vielen Fällen kann es auch sinnvoll sein,schnelle Prototypen zu erstellen, um einerseits die Kommunikation zwi-schen den unterschiedlichen Stakeholdern zu verbessern und andererseitsdem Kunden etwas Greifbares zur Verfügung zu stellen. Durch Prototypenkann sich der Kunde und Anwender schnell ein Bild davon machen, wiebeispielsweise der Bestellvorgang umgesetzt werden könnte.

Andere Arten der Priorisierung betrachten beispielsweise den zu erwarten-den (Kunden-)Nutzen der konkreten Anforderung (value-based) oder daserwartete Risiko bei der Umsetzung (risk-based) [9].

Daher ist es sinnvoll, speziell in der frühen Phase der Anforderungserhe-bung, einem definiertem Prozess zu folgen (siehe Abbildung 2.4), an dessen Prozess zur Anforde-

rungserhebungEnde abgestimmte Systemspezifikationen oder klar definierte User-Storiesstehen. Dieser Prozess besteht aus vier wesentlichen Schritten:

> Anforderungserhebung (Requirements Elicitation). Ziel ist es, abge-stimmte Anforderungen in einem definierten Projektumfeld zu sam-meln, zu klassifizieren und zu priorisieren. Meist wird dieser Schritt inForm eines Brainstormings im Team umgesetzt.

> Analysephase. Die Modellierung von Anforderungen (etwa mit UMLUse-Cases) ermöglicht durch den Einsatz von Visualisierungen einbesseres Verständnis des erwarteten Systemverhaltens. Das Kapitel 6beschreibt die wesentlichen Modellierungsvarianten im Detail.

> Spezifikation. Modellierte und bewertete Anforderungen fließen inSpezifikationen oder User-Stories ein, die das Systemverhalten in Be-zug auf die Anforderungen beschreiben. Diese Dokumente sind die


Date post:	20-Aug-2019
Category:	Documents
Upload:	trantu
View:	221 times
Download:	0 times

Best Practice Software-Engineering · Alexander Schatten / Markus Demolsky / Dietmar Winkler /...

Documents