Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Requirements Engineering in agilen Projekten - Flexibilität ist gefordert

  • 2,041 views
Uploaded on

In agilen Projekten ist funktionierende Software wichtiger als ausufernde Dokumentation. Durch kurze Entwicklungszyklen (Iterationen) werden den Anwendern schon während der Entwicklung Teilpakete......

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.

More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,041
On Slideshare
2,041
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
16
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Requirements Engineering in agilenProjektenFlexibilität ist gefordertTreffpunkt Semicolon, 31.08.2010Reinhard Brüggemeyer, GEDOPLAN GmbH
  • 2. Entwicklung von Informationssystemen30+ Jahre am Markt~35 MitarbeiterBeratung und EntwicklungMaßgeschneiderte Lösungen GEDOPLANStandardsoftware Archi- Entwick- Analyse tektur lung SAP® Java
  • 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. IT-Systeme und ProzesseBeratung, Schulung, Entwicklung80+ Mitarbeiterwww.involva-gruppe.de
  • 5. Agenda Prinzipien des Agilen Manifestes Requirements Engineering, einige Fachbegriffe Agiles Vorgehen in den Projektphasen Vorteile der agilen Vorgehensweise
  • 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. 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. Wer erstellt / nutzt Dokumentation ? Requirements Engineer -> beschreiben Projektleiter -> schätzen -> planen -> entscheiden Entwickler -> realisieren -> System warten Qualitätskontrolle -> testen Anwender -> System nutzen
  • 9. Fachbegriffe des Requirements Engineering Funktionale Nicht funktionale Anforderungen AnforderungenAnalyse Story verbale Beschreibung Use CasePlanung Timeboxing Iteration Produktfeature Iterationsfeature Release 9
  • 10. Phasen in Agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 10
  • 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. Phasen in agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 12
  • 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. Systemabgrenzung durch In-/Outmatrix Projekt Betriebsdatenerfassung Funktionalität Zeiterfassung IN Schichtbericht IN Urlaubserfassung OUT Leistungslohn IN Gehaltsabrechnung OUT 14
  • 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. Use Case Diagramm Projekt Betriebsdatenerfassung Kommen buchen Bericht anzeigen Gehen buchen Mitarbeiter Bericht Vorgesetzter korrigiere n Pause erfassen 16
  • 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. 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. 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. 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. Beispiel: Use Case in Konzeptionsphase 21
  • 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. 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. 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. 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. Phasen in agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 26
  • 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. 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. 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. Phasen in agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 30
  • 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. Beispiel eines Use Case mit erweitertenInformationen
  • 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. 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. 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. Realisierung in agilen Projekten Product Sprint Backlog Backlog Gemeinsamer Programmcode des Teams Feature-Burndown-Grafik Kurze Buildzeiten (Smoke-Build) Automatische Tests
  • 37. Phasen in agilen Projekten Vorstudie Konzeption Iterationsplanung Iterationsdurchführung Projektabschluss 37
  • 38. Projektabschluss / Releaseabschluss Gesamttest des Systems gegen das Gesamtmodel Anwenderdokumentation erstellen Auslieferung des Gesamtsystems Inbetriebnahme des Systems Abnahme des Systems 38
  • 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. 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. Vielen Dank für Ihre Aufmerksamkeit! Kontakt: reinhard.brueggemeyer@gedoplan.de www.gedoplan.de