Skript zur Vorlesung Software Engineering I

Präsentation zum Thema: "Skript zur Vorlesung Software Engineering I"—  Präsentation transkript:

1 Skript zur Vorlesung Software Engineering I
Vorgehensmodelle Das Prozessmodell, auch Vorgehensmodell, ist ein allgemeiner Entwicklungsplan, der das generelle Vorgehen beim Entwickeln eines Software-Produkts festlegt. Durch ein Prozessmodell werden die Reihenfolge des Arbeitsablaufs (Entwicklungsstufen, Phasenkonzepte) und die jeweils zugehörigen Aktivitäten festgelegt. Darüber hinaus werden Inhalt, Fertigstellungskriterien und Layout von Teilprodukten, sowie Verantwortlichkeiten und Kompetenzen von Mitarbeitern, anzuwendende Standards, Richtlinien, Methoden und Werkzeuge geregelt. Ziel ist es, den Entwicklungsprozess übersichtlicher zu gestalten, und die Komplexität beherrschbar zu machen. Dies wird durch die Unterteilung in überschaubare, zeitlich und inhaltlich begrenzte Phasen erreicht, welche sequentiell oder iterativ abgearbeitet werden können. Version Software Engineering I VE 02: Vorgehensmodelle

2 Definition: Entwicklungsprozess
Zur erfolgreichen Durchführung eines Projekts wird ein Software-Entwicklungsprozess angewendet. Darunter versteht man ein Vorgehensmodell, alle Aktivitäten und die angewandten Methoden. Das Vorgehensmodell ist die Beschreibung einer koordinierten Vorgehensweise bei der Abwicklung eines Vorhabens. Das Vorgehensmodell legt eine Reihe von Aktivitäten sowie deren Input und Output (Artefakte) fest. Weiterhin erfolgt eine feste Zuordnung von Rollen, welche die jeweilige Aktivität ausüben. Die Rollen, und somit die Verantwortung für die Aktivitäten, werden den einzelnen Mitgliedern des Projektteams zugeordnet. Version Software Engineering I VE 02: Vorgehensmodelle

3 Definition: Rollen, Aktivitäten, Artefakte
Prozesse werden mittels folgender Hauptkonzepte beschrieben: Rolle: Abstraktion der Aufgabe einer Person in einer bestimmten Situation z.B. Analytiker, Entwickler, Tester, Projektleiter usw. dieselbe Person hat in einem Projekt oft mehrere Rollen Aktivität: Abstraktion für eine Sorte zielgerichteten Handelns in einem Projekt z.B. Anforderungsermittlung, Architekturentwurf, Modulentwurf, Kodierung, Modultest etc. Artefakt: Abstraktion für eine Sorte von Arbeitsergebnis einer Aktivität z.B. Pflichtenheft, UML-Klassendiagramm, Programmcode, Testfall, Testbericht Version Software Engineering I VE 02: Vorgehensmodelle

4 „Code-and-Fix“ Vorgehensmodell
Das wohl einfachste Modell ist die „Code-and-Fix“-Vorgehensweise, bei der Entwickler ohne ein festgelegtes Prozessmodell Funktionen implementieren. Anschließend werden die so entstandenen Komponenten ad-hoc „getestet“ und gegebenenfalls verbessert (= Debugging). Für kleine Projekte ist dieser Ansatz durchaus angemessen, versagt aber bei größeren Software-Projekten völlig. Die Verwendung dieses Modells bei größeren Systemen war ursächlich für die Softwarekrise. Das wohl einfachste Modell ist die Code-and-Fix Vorgehensweise, bei der Entwickler ohne ein festgelegtes Prozessmodell Funktionen implementieren. Anschließend werden die so entstandenen Komponenten ad-hoc getestet und gegebenfalls verbessert. Dieses Modell ist sicherlich jedem Studenten aus eigenen Erfahrungen beim Lo¨sen von U¨ bungsaufgaben vertraut. F¨ur kleine Projekte ist der Ansatz auch durchaus angemessen, er versagt aber total bei gr¨oßeren Software-Projekten. Bewertung: + Geeignet f¨ur 1-Personen-Projekte im Umfang von Wochen, insbesondere wenn Entwickler und Anwender identisch sind. - Wartbarkeit sinkt kontinuierlich - Fehlerwahrscheinlichkeit steigt - Abhängigkeit vom Entwickler durch fehlende Dokumentation - Tests und Verbesserungen häufig nicht zufriedenstellend - Häufig erfüllt das Produkt nicht die Anforderungen des Kunden Größere Projekte können so nicht arbeitsteilig bewältigt werden ,,Code and Fix`` steht für ,,Programmierung und Fehlerbehebung``, teilweise auch bekannt als ,,Build-and-Fix`` Zyklus. Darunter wird ein völlig unstrukturiertes Vorgehen verstanden. Entstanden ist dieses Vorgehensmodell in der Anfangszeit der Rechentechnik, als Software meist von einem einzigen Entwickler produziert wurde. Der Entwickler beginnt direkt mit der Implementierung des Systems. Die Entwicklung wird solange fortgesetzt, bis das System den Vorstellungen des Programmierers entspricht. Fehler werden beim Auftreten durch den Programmierer behoben. Dieser Ansatz ist unstrukturiert, es wird kaum Dokumentation erstellt und Analyse und Entwurf werden ebenfalls fast komplett ausgespart. (vgl. ZBGK01, S. 45) Das Vorgehensmodell „Code and Fix“ ist dann erfolgsversprechend, wenn Entwickler und späterer Nutzer Rollen einer einzigen Person sind. Auch wenn dieses Vorgehensmodell durchaus qualitativ hochwertige Software hervorbringen kann, ist das Vorgehen in der professionellen Softwareentwicklung abzulehnen, da eine Wartung oder Weiterentwicklung der Software meist nur durch den ursprünglichen Entwickler möglich ist. Version Software Engineering I VE 02: Vorgehensmodelle

5 Einschub: Kommunikation in Projekten
Version Software Engineering I VE 02: Vorgehensmodelle

6 Anforderungen an Vorgehensmodelle
Für die Entwicklung größerer Systeme müssen daher geeignete Vorgehensmodelle definiert werden, die ein strukturiertes, arbeitsteiliges Vorgehen erzwingen. Diese Modelle müssen den Entwicklungsprozess in an der Realität orientierte, sinnvolle Phasen unterteilen. Für die Übergänge zwischen den Phasen müssen Dokumentationsstandards vereinbart werden, um die arbeitsteilige Kommunikation zu unterstützen.  Geeignete Phasen müssen identifiziert werden ! Version Software Engineering I VE 02: Vorgehensmodelle

7 Definition: Phasen im Software-Lebenszyklus
Software unterliegt (wie andere Produkte in ähnlicher Form) auch einem allgemeinen Lebenszyklus: Systementwicklung Entwicklung der Software Systemeinführung Vorbereitungen zur Nutzung der Software Wachstum Verbreitung der Nutzung der Software Reife (Wartung) Vornahme von Verbesserungen an der Software, Beseitigung von Fehlern Ablösung (Migration) Schrittweiser Übergang zu einem neuen Software-Produkt oder zu einer neuen Version des Produkts Der « Software-Lebenszyklus » (software lifecycle), beinhaltet alle Etappen (Phasen) von der Konzeption und Entwicklung einer Software bis hin zu ihrem Verschwinden. Ein Software-Lebenszyklus beginnt vor der Markteinführung einer Softwarelösung und besteht aus den Phasen Problementstehung, Entwicklungsprozess, Implementierung und Nutzung und wird durch die Ablösung der Software durch ihren Nachfolger abgeschlossen. Die Softwareentwicklung wird mit der Implementierung abgeschlossen und es folgt der produktive Einsatz der Software, in der auch Wartungsarbeiten vorgenommen werden. Unter Wartung versteht man sowohl das Beheben von Fehlern, als auch das Anpassen des Systems an eine veränderte Umgebung oder die Anreicherung durch weitere Funktionen. Beides führt zur Softwarealterung. Ein Software-Lebenszyklus endet schließlich durch die Ablösung des Systems durch ein Nachfolgeprodukt. Abgrenzung: Der Begriff Produktlebenszyklus umfasst dagegen den Zeitablauf zwischen Markteinführung und Herausnahme eines Produkts aus dem Markt. Der Produktlebenszyklus ist ein Konzept der Betriebswirtschaftslehre und beschreibt den Prozess zwischen der Markteinführung bzw. Fertigstellung eines marktfähigen Gutes und seiner Herausnahme aus dem Markt. Dabei wird die „Lebensdauer“ eines Produktes in mehrere Phasen unterteilt, die die Hauptaufgaben der aktiven Produktpolitik im Rahmen des Lebenszyklus-Managements (engl. life cycle management) darstellen. Der Produktlebenszyklus gilt in den meisten Fällen nur für Konsumgüter. Für Innovationen sollte der Technologielebenszyklus (TLC) zu Rate gezogen werden. ZBGK01 ZUSER, Wolfgang ; BIFFL, Stefan ; GRECHENIG, Thomas ; KÖHLE, Monika: Software Engineering: mit UML und dem Unified Process. München : Pearson Studium, 2001 Version Software Engineering I VE 02: Vorgehensmodelle

8 Phasen im Entwicklungsprozess
Um ein Software-Projekt erfolgreich durchführen zu können, sollte ein Software-Entwicklungsprozess angewendet werden, der die Phasen des Software-Lebenszyklus angemessen behandelt. Das in der Vorlesung behandelte Themengebiet beschränkt sich im Wesentlichen auf die Phasen Systementwicklung und Systemeinführung, also von der Problemspezifikation bis zur Abnahme des daraufhin entwickelten Produkts durch den Kunden.  Weitere Unterteilung dieser Phasen notwendig! Version Software Engineering I VE 02: Vorgehensmodelle

9 Entwicklungsphasen: Aktivitäten
Analyse Design Codierung Test Einführung Wartung Was tun? Wie tun? Realisiere es! Wurde es richtig getan? Problemraum Lösungsraum Was muss verbessert werden? Wird benutzt… Problemmodell Lösungsmodell Ausführbare Lösung Davis1983 William S. Davis. System Analysis and Design. Addison-Wesley, Reading, MA, 1983. Version Software Engineering I VE 02: Vorgehensmodelle

10 Phasen im Entwicklungsprozess
Diese Aktivitäten sind Teil jeder Softwareentwicklung: Analyse  definieren, was das System tun soll Design  definieren, wie das System realisiert werden kann Implementierung  Realisierung des Systems Validierung  prüfen, ob das System die Anforderungen erfüllt Einführung  das System beim Kunden in Betrieb nehmen Wartung  weiterentwickeln des Systems nach geänderten Kundenanforderungen Da diese Aktivitäten normalerweise sequentiell bearbeitet werden, ist auch hierfür die Definition von Phasen geeignet. Tatsächlich enthalten alle Prozessmodelle typischerweise diese Aktivitäten und daraus abgeleitete Phasen! Version Software Engineering I VE 02: Vorgehensmodelle

11 Software Engineering I
Verschiedene Phasenmodelle Entwicklungs- Testphase und Konzeptphase Angebotsphase phase Inbetriebnahme Analyse der Erstellung Entwurfsphase Implementierung Anforderungen Pflichtenheft Inbe- Grob- Fein- Implemen- Aufgabendefinition Test trieb- entwurf entwurf tierung nahme Zeit – Streng sequenziell, keine Iterationen Anzahl und Bezeichnung der Phasen ist nicht fest vorgegeben – Zeitanteil der einzelnen Phasen fest Reine Phasenmodelle entsprechen nicht der Realität! Version Software Engineering I VE 02: Vorgehensmodelle

12 Software Engineering I
Wasserfallmodell Das Wasserfallmodell ist ein bekannter Ansatz zur Strukturierung des Entwicklungsprozesses nach dem Phasenprinzip. Der Name drückt aus, dass man sich wie bei einem mehrstufigen Wasserfall von der Planungsphase zur Wartungsphase bewegt. Weitere Unterteilung der Phasen ist möglich (z.B. in Implementierungsphase und Integrationsphase) Grundlegendes Modell mit vielen Varianten wie Anzahl der Phasen, Überlappung, Rücksprungmöglichkeiten etc. Anforderungs- definition System- und Softwareentwurf Implementierung und Komponententest Integration und Systemtest Betrieb und Wartung Anzahl und Bezeichnung der Phasen ist nicht fest vorgegeben Version Software Engineering I VE 02: Vorgehensmodelle

13 Wasserfallmodell: Nachteile
Die Annahme, dass zu Beginn eine abgeschlossene und korrekte Anforderungsdefinition existiert, entspricht nicht der Realität. Auftraggeber ist nur in der ersten Phase (Anforderungsdefinition) mit eingebunden. Lauffähige Version des Systems liegt erst am Ende der Entwicklung vor. Testen ist nur am Ende des Entwicklungszyklusses vorgesehen. Nichteinhalten der Projektdauer führt zu Abstrichen in den späten Phasen (z.B. beim Testen) Vorteile: Einfach verständlich Begrenzter Management-Aufwand Sehr strukturiert und kontrollierbar Version Software Engineering I VE 02: Vorgehensmodelle

14 Ergebnisorientiertes Phasenmodell
Gut geeignet zur Projektführung Es wurden Phasnemodelle entwickelt, um die Softwareentwicklung strukturiert und kontrolliert ablaufen lassen zu können. Der Abschluß einer einzelnen Phase stellt oftmals einen sog. "Meilenstein" (Quality Gate) im Projekt dar, daher spricht man auch von einem „ergebnisorientierten Phasenmodell“. Quality Gates Version Software Engineering I VE 02: Vorgehensmodelle

15 Entwicklungsphasen: Inputs, Outputs
Lastenheft (CRS) Systemmodellierung Lastenheft (CRS) Systemmodellierung Lastenheft (CRS) Systemmodellierung Kundenanforderungen, Lastenheft (CRS), Systemmodellierung SAS, MODs Implementierung, Modultests SAS, MODs Implementierung, Modultests SAS, MODs Implementierung, Modultests Pflichtenheft (SRS) Systemspezifikation (Grob-,Feinentwurf) Pflichtenheft (SRS) Systemspezifikation (Grob-,Feinentwurf) Pflichtenheft (SRS) Systemspezifikation (Grob-,Feinentwurf) Pflichtenheft (SRS) Systemspezifikation (Grob-,Feinentwurf) Systemtestplan (STP) Systemvalidierungsplan (SVP) Systemtestplan (STP) Systemvalidierungsplan (SVP) Analyse Design Codierung Test Einführung Wartung Architekturspezifikation (SAS) Modulspezifikationen (MODs) Architekturspezifikation (SAS) Modulspezifikationen (MODs) Architekturspezifikation (SAS) Modulspezifikationen (MODs) Architekturspezifikation (SAS) Modulspezifikationen (MODs) Architekturspezifikation (SAS) Modulspezifikationen (MODs) Architekturspezifikation (SAS) Modulspezifikationen (MODs) Architekturspezifikation (SAS) Modulspezifikationen (MODs) Architekturspezifikation (SAS) Modulspezifikationen (MODs) Architekturspezifikation (SAS) Modulspezifikationen (MODs) Systemtestreport (STR) Systemvalidierungs- report (SVR) Systemtestreport (STR) Systemvalidierungs- report (SVR) Systemtestreport (STR) Systemvalidierungs- report (SVR) Systemtestreport (STR) Systemvalidierungs- report (SVR) Systemtestreport (STR) Systemvalidierungs- report (SVR) Pflichtenheft (SRS) MODs Systemintegrations- report (SIR) MODs Systemintegrations- report (SIR) MODs Systemintegrations- report (SIR) MODs Systemintegrations- report (SIR) MODs Systemintegrations- report (SIR) MODs Systemintegrations- report (SIR) MODs Systemintegrations- report (SIR) Bugreports Change Requests (CRQ) Bugreports Change Requests (CRQ) Bugreports Change Requests (CRQ) Version Software Engineering I VE 02: Vorgehensmodelle

16 Software Engineering I
V-Modell Eine Weiterentwicklung des ergebnisorientierten Phasenmodells. QS-orientiert: Es hebt die Validierung der Phasen durch Tests hervor. Weit verbreitet und bei staatlichen deutschen Organisationen und Behörden vorgeschrieben (V-Modell XT). Das V-Modell ist eine Weiterentwicklung des Wasserfallmodells. Es drückt insbesondere die große Bedeutung der Validierung durch Tests aus. Das V-Modell ist bei der Softwareentwicklung für staatliche deutsche Organisationen und Behörden vorgeschrieben. Bewertung: + Integration der Qualitätssicherung in das Wasserfallmodell + Gut geeignet für große Projekte - Bürokratie-Overhead für kleine und mittlere Projekte - Strikter Phasenablauf - Nicht methodenneutral und kaum Unterstützung durch Werkzeuge Version Software Engineering I VE 02: Vorgehensmodelle

17 Phasenmodell: Dokumente
Anforderungsphase Customer Requirements Specification (Lastenheft, CRS) Business Case (Wirtschaftlichkeitsrechnung, BC) Product Solution Study (Produktlösungsstudie, PSS) System Requirements Specification (Pflichtenheft, SRS) Milestones/Ressources/Costs (Project Plan, MRC) Realisierungsphase System Architecture Specification (Systemarchitektur, SAS) System Integration Plan (Systemintegrationsplan, SIP) System Test Plan (Systemtestplan, STP) System Validation Plan (Systemvalidierungsplan, SVP) Module Documentation (Moduldokumentation, MOD) System Integration Report (Systemintegrationsbericht, SIR) System Test Report (Systemtestbericht, STR) System Validation Report (Systemvalidierungsbericht, SVR) Version Software Engineering I VE 02: Vorgehensmodelle

18 Inkrementelles Metamodell
Für die Entwicklung von aufeinander aufbauenden Softwareversionen (Wachstumsmodell) Basismodell wird bis zum Entwurf (System Design) angewendet Dann wird bei der Implementierung der Features schrittweise vorgegangen Schnittstellen, welche späteres Hinzufügen von Subsystemen erlauben Jeder inkrementelle Schritt wird separat entworfen, codiert, getestet und integriert Version Software Engineering I VE 02: Vorgehensmodelle

19 Inkrementelles Metamodell
Darstellung eines übergeordneten Modells zur Durchführung von Software-Inkrementen (Versionen). Änderungswünsche können natürlich auch Fehlermeldungen sein! Weitere Darstellung eines übergeordneten Modells zur Planung von Software-Inkrementen (Versionen). Änderungswünsche können natürlich auch Fehlermeldungen sein! Version Software Engineering I VE 02: Vorgehensmodelle

20 Inkrementelle Entwicklung
Auslieferung des 1. Inkrements Analyse Entwurf Code Test 2. Inkrements Inkrement 2 3. Inkrements Inkrement 3 4. Inkrements Inkrement 4 Zeit Softwaresysteme werden oft inkrementell in Iterationsschritten entwickelt, d.h. die volle Software-Funktionalität wird erst nach und nach geliefert und oft auch erst nach und nach dfefiniert, also nicht von Beginn an eingeplant. Dann spricht man von einem Wachstumsmodell, wobei jeder Iterationsschritt nach dem zuvor erwähnten Phasenmodell durchgeführt wird. Ein derartiges Wachstumsmodell erfordert ein übergeordnetes Projektmanagementmodell, welches die notwendigen Iterationsschritte steuert Version Software Engineering I VE 02: Vorgehensmodelle

21 Inkrementelle Entwicklung: Vor-/Nachteile
Vorteile der inkrementellen Entwicklung Kundenwünsche können in jedem Inkrement erfüllt und ausgeliefert werden, somit ist Systemfunktionalität früher verfügbar. Frühe Inkremente agieren als Prototyp und helfen Anforderungen für spätere Inkremente zu eruieren. Geringeres Risiko für das Scheitern des Gesamtprojektes. Nachteile der inkrementellen Entwicklung Abbildung der Kundenbedürfnisse (Anforderungen) auf einzelne Inkremente ist nicht trivial Ermittlung der Grundfunktionen für das erste Inkrement ist schwierig Grundfunktionen sind Funktionen, die später von Teilsystemen gebraucht werden! Version Software Engineering I VE 02: Vorgehensmodelle

22 Software Engineering I
Spiral-Modell Spezielle Weiterentwicklung des Wasserfallmodells für große, risikoreiche Systeme Es ist zyklisch und nicht linear wie das Wasserfallmodell Es findet also in jedem der Durchläufe erneut eine Risikoanalyse in den Quadranten statt: Q 1: Ziele, Anforderungen und Alternativen identifizieren Q 2: Alternativen untersuchen, Prototyping und Simulationen Q 3: Entwicklung und Validierung Q 4: Ergebnisse untersuchen und nächste Iteration planen Bei jedem Durchlauf entsteht ein neuer Prototyp Das Spiralmodell ist kein Wachstumsmodell, sondern ein Prototypenmodell! Das Spiral-Modell ist ein evolutionäres Modell bei dem zuerst Kernkomponenten identifiziert und realisiert werden. Ein weiteren Teilprojekten werden später weitere Komponenten hinzu kommen. • Bei der Spezifikation und dem Entwurf von Kernkomponenten bereits Erweiterungen berücksichtigen. • Architektur offen f¨ur Erweiterungen halten. • Jeweils pr¨ufen, ob Wiederverwendung von Komponenten oder der Einsatz von Standardsoftware m¨oglich ist. F¨ur jedes Teilprojekt und jede Verfeinerungsebene werden die folgenden Schritte durchlaufen: 2.6. TRANSFORMATIONELLES MODELL 21 1. Anforderungsdefinition 2. Bewertung von Alternativen und Risiken 3. Entwurf, Implementation und Test des Teilprodukts gem¨aß eines geeigneten Prozeßmodells 4. Auswertung und Vorbereitung des n¨achsten Umlaufs Bewertung: + Risikominimierung in allen Phasen und bei allen Teilprojekten + Jede Komponente kann nach dem geeignetesten Prozessmodell entwickelt werden + Regelm¨aßige Bewertung und Korrektur der Ergebnisse + Unterst¨utzt Wiederverwendung - Hoher Managementaufwand - Bei vielen Iterationen geht die Phasentrennung verloren Version Software Engineering I VE 02: Vorgehensmodelle

23 Evolutionäre Modelle: Eigenschaften
Softwareentwicklungsprozess ist nicht linear, sondern Folge von Entwicklungszyklen Entwicklung verläuft über viele Versionen, bis ein angemessenes Produkt entsteht Entwicklung beginnt typischerweise mit einem Prototyp: Evolutionäres Prototyping Zusammenarbeit mit dem Kunden, um Anforderungen zu bestimmen Entwicklung beginnt bei den eindeutigen Anforderungen "Wegwerf"-Prototyping (Throw-Away) Anforderungen des Kunden sollen verstanden werden Entwicklung beginnt bei den unklaren Anforderungen Version Software Engineering I VE 02: Vorgehensmodelle

24 Software Engineering I
Evolutionäre Modelle Version Software Engineering I VE 02: Vorgehensmodelle

25 Evolutionäre Modelle: Vor-/Nachteile
Vorteile der evolutionären Modelle Kundennähe während des gesamten Entwicklungsprozesses Akzeptanz des Kunden wird durch fortlaufende Einbeziehung seiner Wünsche verbessert Nachteile der evolutionären Modelle Keine regelmäßigen Zwischenversionen für die Messung des Projektfortschritts Keine kosteneffiziente Dokumentation möglich Stetige Veränderungen führen zu schlecht strukturierten Systemen Schlechte Eignung für große Systeme mit langer Lebensdauer Prozess ist nicht sichtbar  Wiedergänger von „Code-and-Fix“ ? Version Software Engineering I VE 02: Vorgehensmodelle

26 Evolutionäres Modell: eXtreme Programming (XP)
Weiterentwicklung des inkrementellen Ansatzes Flexibles („agiles“) Vorgehensmodell Basiert auf der Entwicklung und Auslieferung sehr kleiner Inkremente (Teilsysteme) Zwei Forderungen motivierten die Entwicklung von XP Develop for today Konzentration auf aktuelle Probleme Do the simplest thing that could possible work Verwendung des einfachsten Entwurfs (Simple Design), d.h. Erfüllung der Anforderungen Redundanzfreiheit  Wiedergänger von „Code-and-Fix“ ? Extreme Programming ist der bekannteste agile Softwareentwicklungsprozess. Auf den ersten Blick rückt Extreme Programming die eigentliche Implementierung in den Mittelpunkt. Dadurch erscheint Extreme Programming für viele Programmierer sehr interessant, da er den Programmierer von den oft als lästig empfundenen Formalien wie Dokumentationserstellung befreit. Extreme Programming wirkt sehr radikal, da es mit einer Reihe von bisherigen Grundannahmen bricht. Dabei gibt Extreme Programming konkrete Handlungsanweisung zur Gestaltung der einzelnen Arbeitsschritte vor. Die Autoren40 betonen, dass nur eine vollständige Umsetzung aller von Extreme Programming vorgegebenen Prinzipien zu einer erfolgreichen Anwendung von Extreme Programming führen wird. (vgl. Bec00, S. 63) Extreme Programming ist es durch seine Popularität gelungen, die Aufmerksamkeit des Fachpublikums auf die agilen Methodiken zu lenken. Im Rahmen der agilen Softwareentwicklung wird in der Literatur von Methodiken anstatt Vorgehensmodellen gesprochen. Eine Methodik ist danach eine begriffliche Zusammenfassung für Prozesse und Methoden. In dieser Arbeit wird Methodik als Synonym für Vorgehensmodell verwendet. Im nun folgenden Abschnitt wird Extreme Programming umfassend dargestellt. Extremes Programmieren (XP) Als Alternative zu den relativ schwerfälligen Prozessmodellen wurde insbesondere für kleine Projekte Ende der neunziger Jahre „Extremes Programmieren“ vorgeschlagen [2, 16]. Der Ansatz ist für kleine Projekte mit bis zu Entwicklern geeignet und basiert auf den folgenden zwölf Techniken (Praktiken in der XP-Terminologie): 1. Kleine Releases • Hochgradig iterativer Entwicklungsprozess mit einem Release-Zyklus von 1-3 Monaten. • Ein Release besteht aus mehreren Iterationen von 1-3 Wochen Dauer. • Iterationen zerfallen wiederum in Arbeitspakete von 1-3 Tagen. • Nach jeder Iteration kann der Kunde Abweichungen von seinen Vorstellungen feststellen und korrigieren. 2. Planungsspiel • Kunden beschreiben gew¨unschte neue Funktionen f¨ur die n¨achste Iteration in Form einer „User Story“ und versehen sie mit Priorit¨aten. • Entwickler sch¨atzen den Aufwand zur Realisierung f¨ur jede Story. • Der Kunde entscheidet, welche Story in der n¨achsten Iteration implementiert werden. • Gegebenenfalls ist eine Wiederholung des Planungsspiels notwendig bis ein Gleichgewicht erreicht wird und eine realistische Planung f¨ur die n¨achste Iteration entstanden ist. 3. Tests • Automatisierte Tests spielen eine zentrale Rolle von XP. • Entwickler schreiben Tests f¨ur ihre Klassen (unit tests). • Der Kunde entwickelt Testf¨alle f¨ur eine Story (functional test). • Wichtig: Entwickler schreiben Tests bevor die Klassen implementiert werden. 4. Systemmetapher • Eine Systemmetapher steht f¨ur die grunds¨atzliche Idee hinter der Architektur und ist sowohl Kunden als auch Entwicklern bekannt. • Sie ersetzt den Architekturentwurf. 5. Einfacher Entwurf • Entwickler w¨ahlen immer die einfachste L¨osung, die den aktuellen Anforderungen gen¨ugt (the simplest thing that could possibly work). • Anforderungen k¨onnen sich morgen ¨andern, wodurch zus¨atzlich eingebaute Flexibilit¨at nutzlos w¨urde. • Sollte sp¨ater eine generellere L¨osung notwendig sein, so wird der Entwurf refaktorisiert. 6. Refaktorisierung • Refaktorisierung dient der Vereinfachung des Entwurfs unter Beibehaltung der Semantik (Eliminierung duplizierten Quellcodes). • Verbesserung der Versta¨ndlichkeit und A¨ nderbarkeit des Quelltextes. • Durch die umfangreiche Testsammlung kann festgestellt werden, ob bei einer Refaktorisierung sich Fehler eingeschlichen haben. • Der Quelltext selbst soll schließlich in hohem Maße selbsterkl¨arend sein und anderweitige Dokumentation ersetzen. 7. Programmieren in Paaren • Die Programmierung erfolgt immer in Paaren vor einem Rechner. 2.7. EXTREMES PROGRAMMIEREN (XP) 23 • W¨ahrend einer der Entwickler programmiert pr¨uft der Partner den Quelltext auf logische Fehler und ob der neue Quelltext zur Systemmetapher paßt oder ob weitere Tests fehlen. • Die Paarbindung ist dynamisch und f¨ordert so den Austausch vonWissen ¨uber verschiedene Aspekte des Softwaresystems. • Nach verschiedenen Studien führt das Programmierung in Paaren zu nur leicht gestiegenen Kosten und deutlich verst¨andlicherem und fehlerfreierem Quelltext. 8. Gemeinsames Eigentum • Der entstandene Quelltext geh¨ort nicht einem bestimmten Entwickler sondern allen Entwicklern in einem Projekt. 9. Kontinuierliche Integration • Neu entwickelter oder ge¨anderter Quelltext wird regelm¨assig (mindestens einmal am Tag) in die aktuelle Code-Basis integriert • Dabei m¨ussen alle vorhandenen Tests bestanden werden. Stunden-Woche • Das Programmieren in Paaren stellt hohe Anspr¨uche an die Konzentration der Partner. • Daher werden geregelte Arbeitszeiten von 40 Stunden (Richtwert) eingehalten. 11. Kundenvertreter im Team • Da keine Spezifikation vorhanden ist, gibt es viele R¨uckfragen an den Kunden. • Es sollte daher ein Kunde f¨ur die Entwickler st¨andig verf¨ugbar sein. 12. Programmierrichtlinien • Alle Entwickler halten sich an feste Programmierrichtlinien um einheitlichen Quelltext zu erzeugen, der von allen anderen Entwicklern verstanden und leicht ge¨andert werden kann. Bewertung: + Einfaches Prozessmodell für kleinere Softwareprojekte. + Kundenwünsche haben starken Einfluß auf den Entwicklungsprozess. + Steigert die Zufriedenheit der Entwickler. - Fehlen einer expliziten Spezifikation erschwert es, nachträglich neue Entwickler in das Team zu integrieren. - Die Umsetzung von XP ist nur unzureichend dokumentiert. Das Konzept der Systemmetapher ist vage. Version Software Engineering I VE 02: Vorgehensmodelle

27 Arten und Merkmale von Prozessen
In plangetriebenen Prozessen werden alle Aktivitäten im Voraus geplant und der Projektfortschritt wird gegen diesen Plan gemessen. In agilen (evolutionären) Prozessen erfolgt die Planung iterativ, es ist leichter, auf sich ändernde Kundenanforderungen einzugehen. In der Praxis enthalten die meisten existierenden Prozesse Elemente sowohl aus dem plangetriebenen als auch aus dem dem agilen Ansatz.  Es gibt keine richtigen oder falschen Software- Entwicklungsprozesse! Version Software Engineering I VE 02: Vorgehensmodelle

28 Arten von Vorgehensmodellen
Phasenmodell Plangetrieben. Getrennte und eindeutige Phasen für Spezifikation und Entwicklung. Inkrementelles (Evolutionäres) Modell Spezifikation, Entwicklung und Validierung erfolgen überlappend. Kann plangetrieben oder agil sein. Wiederverwendungs-Modell Das System wird (teilweise) aus existierenden Komponenten zusammengebaut. Kann plangetrieben oder agil sein.  In der Realität werden die meisten großen Systeme nach einem Prozess entwickelt, der Elemente aus allen diesen Modellen enthält! Version Software Engineering I VE 02: Vorgehensmodelle

29 Planungshorizont von Prozessmodellen
Wichtiges Unterscheidungsmerkmal für Prozessmodelle: Wie präzise / strikt / weit voraus wird geplant? Sehr: Phasenmodelle möglichst präzise und strikt, für das gesamte Projekt im Voraus Mittel: Iterative Modelle präzise wo möglich nicht strikt (nötige Veränderungen werden akzeptiert) nur für wenige Iterationen im Voraus Wenig: Agile Modelle Nur so viel Planung wie unbedingt nötig Lieber Ziele als Pläne (wegen Flexibilität) Version Software Engineering I VE 02: Vorgehensmodelle

30 Auswahl des Prozessmodells
Wann sind welche Modelle geeignet ? Plangetriebene Modelle: Wenn exaktes Resultat in definierter Zeit erreicht werden muss Wenn sehr große (insbesondere verteilte) Projektgruppen koordiniert werden müssen Dann sind Pläne und Dokumente zur Koordination unverzichtbar Agile Modelle: Wenn hohe Unsicherheit über die Anforderungen besteht Inhalt, Prioritäten Wenn Änderungen von außen häufig sind Anforderungen, Zeitplan, Budget, Qualitätsziele etc. Version Software Engineering I VE 02: Vorgehensmodelle

31 Auswahl des Prozessmodells
Wann sind welche Modelle geeignet ? Plangetriebene Modelle: Parallele Entwicklung von HW und SW (z.B. Automotive) Verteilte Entwicklung (z.B. in mehreren Firmen, Standorten) Wiederverwendung geplant/gewünscht Agile Modelle: Projekt hat keinen Zeitplan (z.B. Hobbyprojekt) Arbeit mit unausgereifter und unbeherrschter Technologie Projekt hat unklare Anforderungen Version Software Engineering I VE 02: Vorgehensmodelle

32 Organisationsprozesse
Produktmanagement / Projektmanagement / Qualitätsmanagement Führungsprozess Analyse Design Codierung Test Einführung Wartung Kern-prozess Supportprozesse Support-prozesse Methoden und Verfahren Trainings- und Support-organisation Qualitäts- und Testorganisation Versions-/ Konfigurations-management Zusätzlich zum eigentlichen Softwareentwicklungsprozess existieren in Softwareentwicklungsorganisationen meist eine Reihe von Supportprozessen, die die Entwicklungstätigkeit unterstützen! Version Software Engineering I VE 02: Vorgehensmodelle

33 Software Engineering I
Zusammenfassung Softwareentwicklungsprozesse sind Aktivitäten, die bei Produktion und Entwicklung von Softwaresystemen vorkommen. Diese können in einem Vorgehensmodell dargestellt werden. Allgemeine Aktivitäten sind Anforderungsanalyse und -spezifikation, Entwurf und Implementierung, Validierung und Weiterentwicklung. Iterative Vorgehensmodelle beschreiben den Softwareentwicklungsprozess als Kreislauf von Aktivitäten Für eine inkrementelle Entwicklung muss im Initialprojekt ein Grobkonzept und die Definition der Systemarchitektur für den gesamten Projektumfang festgelegt werden. Version Software Engineering I VE 02: Vorgehensmodelle

34 Zusammenfassung iterative Prozessmodelle
Prototypenmodell: Baue anfangs ein (Teil)System "zum Wegwerfen", um kritische Anforderungen besser zu verstehen. Dann folge einem Phasenmodell. Risikomodell (Spiralmodell): Prototypenmodell, tue in jeder Iteration das, was am stärksten zur Verringerung des kritischsten Projektrisikos beiträgt. Inkrementelles Modell: Baue das Gesamtsystem schrittweise. In jedem Schritt werden nur neue Teile hinzugebaut, es wird jedoch (theoretisch) nie etwas Existierendes verändert. Iteratives (Evolutionäres) Modell: In jedem Schritt werden neue Teile hinzugebaut und wo nötig auch existierende verändert. Version Software Engineering I VE 02: Vorgehensmodelle