Requirements Engineering in agilenProjektenFlexibilität ist gefordertTreffpunkt Semicolon, 31.08.2010Reinhard Brüggemeyer,...
Entwicklung von Informationssystemen30+ Jahre am Markt~35 MitarbeiterBeratung und EntwicklungMaßgeschneiderte Lösungen    ...
Seit 1998 im Bereich Java:   80+ Beratungs- und Entwicklungsprojekte   Konzeption und Entwicklung   30+ Seminartitel   Jav...
IT-Systeme und ProzesseBeratung, Schulung, Entwicklung80+ Mitarbeiterwww.involva-gruppe.de
Agenda Prinzipien des Agilen Manifestes Requirements Engineering, einige Fachbegriffe Agiles Vorgehen in den Projektphasen...
Agiles Manifest  Funktionierende Software ist wichtiger als umfangreiche  Dokumentation  Gute Kommunikation ersetzt Dokume...
Sinn und Zweck von Business Spezifikationen  Gemeinsames Verständnis der Anforderungen  Kommunikation zwischen Projektteam...
Wer erstellt / nutzt Dokumentation ?  Requirements Engineer   ->   beschreiben  Projektleiter           ->   schätzen     ...
Fachbegriffe des Requirements Engineering              Funktionale         Nicht funktionale              Anforderungen   ...
Phasen in Agilen Projekten  Vorstudie  Konzeption  Iterationsplanung  Iterationsdurchführung  Projektabschluss            ...
Vorstudie  Betrachtung des gesamten Projektes  Realisierungsalternativen ermitteln  Technische Machbarkeit prüfen  Grobpla...
Phasen in agilen Projekten  Vorstudie  Konzeption  Iterationsplanung  Iterationsdurchführung  Projektabschluss            ...
Bestandteile der Konzeption  Systemabgrenzung  Gesamtmodell der funktionalen Anforderungen  Prioritäten der Anforderungen ...
Systemabgrenzung durch In-/Outmatrix  Projekt Betriebsdatenerfassung  Funktionalität  Zeiterfassung    IN  Schichtbericht ...
Ermittlung der funktionalen Anforderungen  Betrachtung des Systems als Black Box  Wer ist von den System in irgendeiner We...
Use Case Diagramm Projekt Betriebsdatenerfassung                  Kommen                   buchen                         ...
Anforderungen an Use Cases (INVEST)  Independent           sind unabhängig voneinander  Negotiable    sind verhandelbar  V...
Strukturierung der funktionalen Anforderungen  Welche Use Cases sind konkrete Use Cases auf  Anwenderebene?  Welche Use Ca...
Gesamtmodel der funktionalen Anforderungen  Projekt Betriebsdatenerfassung                              Betriebsdaten     ...
Use Case Attribute für die Konzeption  Primärer Akteur:          Hauptanwender  Ziel und Inhalt:          Kurze textliche ...
Beispiel: Use Case in Konzeptionsphase                                         21
Bewertung der Anforderungen  Bewertung der Anforderungen nach „Business Priorität“ und  „Entwicklungskomplexität“  Use Cas...
Schätzung der Anforderungen  „Wetter von gestern“ Prinzip  Use Case Point Methode  Use Cases auf Anwenderebene schätzen  S...
Hierarchisches Schätzen          Zeiterfassung                  Schichtbericht                                            ...
Klassenmodel der Objekte  Strukturierung aller Objekte des Systems  Beschreibung der Begriffe und ihrer Beziehungen  Besch...
Phasen in agilen Projekten  Vorstudie  Konzeption  Iterationsplanung  Iterationsdurchführung  Projektabschluss            ...
Agiles, iteratives Vorgehen Gesamtplanun g                           Iterations- -                             planung Anf...
Iterationsplanung - Wann wird eine Anforderungrealisiert?  Anforderungen mit hoher „Business Priorität“ möglichst früh  re...
Use Case / Iterations Matrix  Aufteilung eines Use Case (Rapportschein verwalten)Funktion             1.Iteration       2....
Phasen in agilen Projekten  Vorstudie  Konzeption  Iterationsplanung  Iterationsdurchführung  Projektabschluss            ...
Detailspezifikation der Anforderungen / Use Cases  Haupt-Erfolgsszenario:   Schritte die im Erfolgsszenario –  dem        ...
Beispiel eines Use Case mit erweitertenInformationen
Gründe für die späte Detailspezifikation  Aktuelle Rahmenbedingungen – Gesetze / Verordnungen  Technische Weiterentwicklun...
Vorteile der Beschreibung mit Use Cases  Die Sicht des Anwenders steht im Mittelpunkt  Planungs – und Analyseinformationen...
Systementwurf auf Basis der Spezifikation  Abbildung des Use Case Model auf ein Objektmodel  Sequenzdiagramme: In welcher ...
Realisierung in agilen Projekten    Product                 Sprint    Backlog                Backlog  Gemeinsamer Programm...
Phasen in agilen Projekten  Vorstudie  Konzeption  Iterationsplanung  Iterationsdurchführung  Projektabschluss            ...
Projektabschluss / Releaseabschluss  Gesamttest des Systems gegen das Gesamtmodel  Anwenderdokumentation erstellen  Auslie...
Requirements Engineering in agilen Projekten     Vorstudie                Entscheidungsvorlage für                        ...
Vorteile des agilen Vorgehens  Iterationen beziehen die Realisierung der Software ein  Der Projektfortschritt ist transpar...
Vielen Dank für Ihre Aufmerksamkeit!                   Kontakt:     reinhard.brueggemeyer@gedoplan.de               www.ge...
Nächste SlideShare
Wird geladen in …5
×

Requirements Engineering in agilen Projekten - Flexibilität ist gefordert

2.456 Aufrufe

Veröffentlicht am

In agilen Projekten ist funktionierende Software wichtiger als ausufernde Dokumentation. Durch kurze Entwicklungszyklen (Iterationen) werden den Anwendern schon während der Entwicklung Teilpakete der geplanten Softwarelösung mit einem sinnvollen Funktionsumfang bereit gestellt. In agilen Projekten ist die flexible Reaktion auf Änderungen der Anforderungen wichtiger als ein starrer Projektplan. Agilität bei der Entwicklung erfordert aber auch Agilität bei der Beschreibung der funktionalen Anforderungen (Requirements Engineering). Use Case-Modelle eignen sich hervorragend für diese Aufgabe. Durch dieses Vorgehen ist es möglich, Wünsche der Anwender, geänderte Rahmenbedingungen und Erfahrungen aus der bisherigen Entwicklung in der Realisierung zu berücksichtigen. Reinhard Brüggemeyer, Dozent dieses "Treffpunkt Semicolon", zeigt, warum in agilen Projekten der Anwender und seine Aufgaben im Mittelpunkt stehen. Pro und Contra des agilen Vorgehens gegenüber dem klassischen Requirements Engineering werden diskutiert.

Veröffentlicht in: Business
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.456
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
20
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Requirements Engineering in agilen Projekten - Flexibilität ist gefordert

  1. 1. Requirements Engineering in agilenProjektenFlexibilität ist gefordertTreffpunkt Semicolon, 31.08.2010Reinhard Brüggemeyer, GEDOPLAN GmbH
  2. 2. Entwicklung von Informationssystemen30+ Jahre am Markt~35 MitarbeiterBeratung und EntwicklungMaßgeschneiderte Lösungen GEDOPLANStandardsoftware Archi- Entwick- Analyse tektur lung SAP® Java
  3. 3. Seit 1998 im Bereich Java: 80+ Beratungs- und Entwicklungsprojekte Konzeption und Entwicklung 30+ Seminartitel Java / Java EE GEDOPLAN Diverse App.-Server Glassfish Archi- Entwick- IBM WebSphere Analyse tektur lung JBoss Oracle WebLogic SAP® SAP NetWeaver Java
  4. 4. IT-Systeme und ProzesseBeratung, Schulung, Entwicklung80+ Mitarbeiterwww.involva-gruppe.de
  5. 5. Agenda Prinzipien des Agilen Manifestes Requirements Engineering, einige Fachbegriffe Agiles Vorgehen in den Projektphasen Vorteile der agilen Vorgehensweise
  6. 6. Agiles Manifest Funktionierende Software ist wichtiger als umfangreiche Dokumentation Gute Kommunikation ersetzt Dokumentation In kurzen Abständen übergebene Software ist Basis der Kommunikation Schnelle Rückkopplung durch feste Iterationen Nur notwendige Dokumentation wird erstellt Reaktion auf Änderungen ist wichtiger als starrer Projektplan Änderungen an Anforderungen werden bei der Realisierung berücksichtigt 6
  7. 7. Sinn und Zweck von Business Spezifikationen Gemeinsames Verständnis der Anforderungen Kommunikation zwischen Projektteam und Auftraggeber Basis für … Aufwandsschätzungen Projektplanung Realisierung Test Die Informationen sind so detailliert, wie sie in jeder Projektphase benötigt werden Klassisches Vorgehen: Vollständiges Pflichtenheft vor Start der Realisierung 7
  8. 8. Wer erstellt / nutzt Dokumentation ? Requirements Engineer -> beschreiben Projektleiter -> schätzen -> planen -> entscheiden Entwickler -> realisieren -> System warten Qualitätskontrolle -> testen Anwender -> System nutzen
  9. 9. Fachbegriffe des Requirements Engineering Funktionale Nicht funktionale Anforderungen AnforderungenAnalyse Story verbale Beschreibung Use CasePlanung Timeboxing Iteration Produktfeature Iterationsfeature Release 9
  10. 10. Phasen in Agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 10
  11. 11. Vorstudie Betrachtung des gesamten Projektes Realisierungsalternativen ermitteln Technische Machbarkeit prüfen Grobplanung für … Zeitbedarf Personalbedarf Kosten Entscheidungsvorlage für das Management Die Vorstudie betrachtet das gesamte Projekt Hier unterscheidet sich agiles Vorgehen nicht von klassischen Projekten 11
  12. 12. Phasen in agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 12
  13. 13. Bestandteile der Konzeption Systemabgrenzung Gesamtmodell der funktionalen Anforderungen Prioritäten der Anforderungen Aufwandsschätzungen für die Anforderungen Klassenmodell der Objekte Systemarchitektur Klärung neuer technischer Anforderungen durch Prototypen Beschreibung der nicht funktionalen Anforderungen 13
  14. 14. Systemabgrenzung durch In-/Outmatrix Projekt Betriebsdatenerfassung Funktionalität Zeiterfassung IN Schichtbericht IN Urlaubserfassung OUT Leistungslohn IN Gehaltsabrechnung OUT 14
  15. 15. Ermittlung der funktionalen Anforderungen Betrachtung des Systems als Black Box Wer ist von den System in irgendeiner Weise betroffen (Stakeholder) ? Welche Akteure nutzen das System? Welche Use Cases benötigen die jeweiligen Akteure? Welches primäre Ziel haben die Akteure (Geldabheben oder Pineingabe) ? 15
  16. 16. Use Case Diagramm Projekt Betriebsdatenerfassung Kommen buchen Bericht anzeigen Gehen buchen Mitarbeiter Bericht Vorgesetzter korrigiere n Pause erfassen 16
  17. 17. Anforderungen an Use Cases (INVEST) Independent sind unabhängig voneinander Negotiable sind verhandelbar Valuable haben einen Geschäftswert Estimatable sind schätzbar Small sind möglichst in einer Timebox umsetzbar Testable sind testbar
  18. 18. Strukturierung der funktionalen Anforderungen Welche Use Cases sind konkrete Use Cases auf Anwenderebene? Welche Use Cases unterstützen Use Cases auf Anwenderebene? Welche abstrakten Use Cases gruppieren konkrete Use Cases? Ebenenkonzept der Use Cases (nach Cockburn) Gesamtprojekt (Level 1) Bereich (Level 2) Anwendersicht (Level 3) Supportsicht (Level 4) Level 2 und 3 liefern eine vollständige Beschreibung des Systems 18
  19. 19. Gesamtmodel der funktionalen Anforderungen Projekt Betriebsdatenerfassung Betriebsdaten Gesamt – - erfassung projekt Zeit Schicht - Bereich - erfassung bericht Kommen Gehen Pause Bericht Bericht Anwender buchen buchen erfassen anzeigen korrigieren – ebene Mitarbeiter Mitarbeiter Support – authentifizieren identifizieren ebene 19
  20. 20. Use Case Attribute für die Konzeption Primärer Akteur: Hauptanwender Ziel und Inhalt: Kurze textliche Inhaltsangabe Ebene: Beschreibungsebene Akteure und Interessen: Wer verfolgt welche Ziele? Vorbedingung: Welche Bedingungen müssen vor dem Start eines Use Case erfüllt sein? Minimal Garantie: Was ist das Minimalergebnis? Auslöser: auslösendes Ereignis Hauptobjekt: Überwiegend bearbeitetes Objekt Business Priorität: Priorität der Anwender 20
  21. 21. Beispiel: Use Case in Konzeptionsphase 21
  22. 22. Bewertung der Anforderungen Bewertung der Anforderungen nach „Business Priorität“ und „Entwicklungskomplexität“ Use Case Priorität Komplexität Gesamtpriorität Kommt buchen 5 1 5,1 Geht buchen 5 1 5,1 Leistungslohn berechnen 4 3 5,0 Leistungslohn simulieren 2 5 5,4 Schichtbericht erzeugen 4 3 5,0 22
  23. 23. Schätzung der Anforderungen „Wetter von gestern“ Prinzip Use Case Point Methode Use Cases auf Anwenderebene schätzen Schätzung durch mehrere Personen und Mittelwert bilden Abstrakte Use Case Points in konkreten Aufwand umrechnen 23
  24. 24. Hierarchisches Schätzen Zeiterfassung Schichtbericht abstrakte 2 3 Use Cases Komme Gehen Pause Bericht Bericht konkrete n buchen erfasse anzeigen korrigiere Use Cases buchen 4 n n 2 2 Bewertung der abstrakten Use Cases Bewertung der konkreten Use Cases für einen Bereich Umrechnung der Bewertungen in Aufwand (1 Punkt = 2 MT) Aufwand Zeiterfassung = (2 + 4 + 2) * 2 MT = 16 MT Aufwand Schichtbericht = 16 MT / 2 * 3 = 24 MT 24
  25. 25. Klassenmodel der Objekte Strukturierung aller Objekte des Systems Beschreibung der Begriffe und ihrer Beziehungen Beschreibung der Objekteigenschaften durch Attribute Schichtbericht Bemerkung Freigabedatum Pausenzeitraum Aufgabenzeitrau Aufgabe Startzeitpunkt m Bezeichnung Endezeitpunkt Startzeitpunkt Endezeitpunkt 25
  26. 26. Phasen in agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 26
  27. 27. Agiles, iteratives Vorgehen Gesamtplanun g Iterations- - planung Anforderungen - Aufwand - Reihenfolge Anwender- Detail präsentation Spezifikation Iterations- Systementwu test rf für Iteration Realisierung 27
  28. 28. Iterationsplanung - Wann wird eine Anforderungrealisiert? Anforderungen mit hoher „Business Priorität“ möglichst früh realisieren (Easy Wins) Komplexe Anforderungen früh einplanen, um Risiken zu minimieren Abhängigkeiten zwischen den Anforderungen berücksichtigen (Trigger, Vorbedingungen) Anforderungen, die dasselbe Hauptobjekt bearbeiten, evtl. gemeinsam umsetzen Umfangreiche Anforderungen auf Iterationen aufteilen Mit Minimalergebnis beginnen Varianten weglassen Auf Komfort verzichten 28
  29. 29. Use Case / Iterations Matrix Aufteilung eines Use Case (Rapportschein verwalten)Funktion 1.Iteration 2.Iteration 3.IterationAnwesenheit anzeigen xPausen anzeigen xAuftragsdaten anzeigen xZeiträume modifizieren x 29
  30. 30. Phasen in agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 30
  31. 31. Detailspezifikation der Anforderungen / Use Cases Haupt-Erfolgsszenario: Schritte die im Erfolgsszenario – dem Normalfall – durchlaufen werden Erweiterungen: Die Varianten des Normalfalls werden mit ihren einzelnen Schritten beschrieben Fehlerbeschreibungen: Im Fehlerfall wird jeder Schritt beschrieben, der durchlaufen werden soll 31
  32. 32. Beispiel eines Use Case mit erweitertenInformationen
  33. 33. Gründe für die späte Detailspezifikation Aktuelle Rahmenbedingungen – Gesetze / Verordnungen Technische Weiterentwicklungen Bisherige Erfahrungen aus dem Projekt Zusätzliche / geänderte Wünsche der Anwender 33
  34. 34. Vorteile der Beschreibung mit Use Cases Die Sicht des Anwenders steht im Mittelpunkt Planungs – und Analyseinformationen werden abgebildet Komplexe Sachverhalte können beschrieben werden Es gibt ein einheitliches Abstraktionsniveau Abhängigkeiten werden erkannt Es werden keine Informationen auf Vorrat erfasst
  35. 35. Systementwurf auf Basis der Spezifikation Abbildung des Use Case Model auf ein Objektmodel Sequenzdiagramme: In welcher Reihenfolge werden Nachrichten zwischen den Objekten gesendet? Tracebility: Welche Use Cases werden in welchen Designkomponenten abgebildet? Wo wirken sich Änderungen von Use Cases aus? Gibt es Designelemente, die keinem Use Case zugeordnet sind? Welche Use Cases beziehen sich auf ein Hauptobjekt? Welche Use Cases werden von demselben Akteur in demselben Arbeitsumfeld genutzt? 35
  36. 36. Realisierung in agilen Projekten Product Sprint Backlog Backlog Gemeinsamer Programmcode des Teams Feature-Burndown-Grafik Kurze Buildzeiten (Smoke-Build) Automatische Tests
  37. 37. Phasen in agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 37
  38. 38. Projektabschluss / Releaseabschluss Gesamttest des Systems gegen das Gesamtmodel Anwenderdokumentation erstellen Auslieferung des Gesamtsystems Inbetriebnahme des Systems Abnahme des Systems 38
  39. 39. Requirements Engineering in agilen Projekten Vorstudie Entscheidungsvorlage für das Management Konzeption Use Case Model Objektmodel Iterationsplanung Funktionsumfang der nächsten Iteration Iterationsdurchführung Detailspezifikation der Use Cases und Klassen, Systementwurf, Software Abschlussphase Anwenderdokumentation 39
  40. 40. Vorteile des agilen Vorgehens Iterationen beziehen die Realisierung der Software ein Der Projektfortschritt ist transparent Gleichmäßige Auslastung des Projektteams Kontinuierliches Lernen durch Retrospektiven nach jeder Iteration
  41. 41. Vielen Dank für Ihre Aufmerksamkeit! Kontakt: reinhard.brueggemeyer@gedoplan.de www.gedoplan.de

×