requirements engineering in agilen projekten - flexibilität ist gefordert
DESCRIPTION
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.TRANSCRIPT
Requirements Engineering in agilen
Projekten
Flexibilität ist gefordert
Treffpunkt Semicolon, 31.08.2010
Reinhard Brüggemeyer, GEDOPLAN GmbH
Entwicklung von Informationssystemen
30+ Jahre am Markt
~35 Mitarbeiter
Beratung und Entwicklung
Maßgeschneiderte Lösungen
Standardsoftware
AnalyseArchi-
tektur
Entwick-
lung
SAP®
GEDOPLAN
Java
Seit 1998 im Bereich Java:
80+ Beratungs- und Entwicklungsprojekte
Konzeption und Entwicklung
30+ Seminartitel
Java / Java EE
Diverse App.-Server
Glassfish
IBM WebSphere
JBoss
Oracle WebLogic
SAP NetWeaver
AnalyseArchi-
tektur
Entwick-
lung
SAP®
GEDOPLAN
Java
IT-Systeme und Prozesse
Beratung, Schulung, Entwicklung
80+ Mitarbeiter
www.involva-gruppe.de
Agenda
Prinzipien des Agilen Manifestes
Requirements Engineering, einige Fachbegriffe
Agiles Vorgehen in den Projektphasen
Vorteile der agilen Vorgehensweise
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
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
Wer erstellt / nutzt Dokumentation ?
Requirements Engineer -> beschreiben
Projektleiter -> schätzen
-> planen
-> entscheiden
Entwickler -> realisieren
-> System warten
Qualitätskontrolle -> testen
Anwender -> System nutzen
Fachbegriffe des Requirements Engineering
Funktionale Nicht funktionale
Anforderungen Anforderungen
Analyse Story verbale
Beschreibung
Use Case
Planung Timeboxing
Iteration
Produktfeature
Iterationsfeature
Release
9
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
Phasen in Agilen Projekten
10
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
Phasen in agilen Projekten
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
12
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
Systemabgrenzung durch In-/Outmatrix
Projekt Betriebsdatenerfassung
Funktionalität
Zeiterfassung IN
Schichtbericht IN
Urlaubserfassung OUT
Leistungslohn IN
Gehaltsabrechnung OUT
14
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
Use Case Diagramm
Projekt Betriebsdatenerfassung
Mitarbeiter Vorgesetzter
16
Kommen
buchen
Bericht
anzeigen
Pause
erfassen
Gehen
buchen
Bericht
korrigiere
n
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
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
Gesamtmodel der funktionalen Anforderungen
Projekt Betriebsdatenerfassung
19
Betriebsdaten
- erfassung
Zeit
- erfassung
Schicht -
bericht
Kommen
buchen
Gehen
buchen
Pause
erfassen
Bericht
anzeigen
Bericht
korrigieren
Mitarbeiter
authentifizieren
Mitarbeiter
identifizieren
Gesamt –
projekt
Bereich
Anwender
–
ebene
Support –
ebene
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
Entwicklungskomplexität: Komplexität der Entwicklung20
Beispiel: Use Case in Konzeptionsphase
21
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
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
Hierarchisches Schätzen
abstrakte
Use Cases
konkrete
Use Cases
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
Zeiterfassung
2
Schichtbericht
3
Komme
n
buchen
2
Gehen
buchen
4
Pause
erfasse
n
2
Bericht
anzeigen
Bericht
korrigiere
n
Klassenmodel der Objekte
Strukturierung aller Objekte des Systems
Beschreibung der Begriffe und ihrer Beziehungen
Beschreibung der Objekteigenschaften durch Attribute
25
Schichtbericht
Bemerkung
Freigabedatum
Aufgabenzeitrau
m
Startzeitpunkt
Endezeitpunkt
Pausenzeitraum
Startzeitpunkt
Endezeitpunkt
Aufgabe
Bezeichnung
Phasen in agilen Projekten
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
26
Agiles, iteratives Vorgehen
27
Gesamtplanun
g
-
Anforderungen
- Aufwand
- Reihenfolge
Iterations-
planung
Detail
Spezifikation
Systementwu
rf für Iteration
Realisierung
Anwender-
präsentation
Iterations-
test
Iterationsplanung - Wann wird eine Anforderung
realisiert?
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 verzichten28
Use Case / Iterations Matrix
Aufteilung eines Use Case (Rapportschein verwalten)
Funktion 1.Iteration 2.Iteration 3.Iteration
Anwesenheit anzeigen x
Pausen anzeigen x
Auftragsdaten anzeigen x
Zeiträume modifizieren x
29
Phasen in agilen Projekten
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
30
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
Beispiel eines Use Case mit erweiterten
Informationen
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
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
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
Realisierung in agilen Projekten
Gemeinsamer Programmcode des Teams
Feature-Burndown-Grafik
Kurze Buildzeiten (Smoke-Build)
Automatische Tests
Product
Backlog
Sprint
Backlog
Phasen in agilen Projekten
Vorstudie
Konzeption
Iterationsplanung
Iterationsdurchführung
Projektabschluss
37
Projektabschluss / Releaseabschluss
Gesamttest des Systems gegen das Gesamtmodel
Anwenderdokumentation erstellen
Auslieferung des Gesamtsystems
Inbetriebnahme des Systems
Abnahme des Systems
38
Requirements Engineering in agilen Projekten
39
Vorstudie Entscheidungsvorlage für
das Management
Konzeption
Iterationsplanung
Iterationsdurchführung
Abschlussphase
Use Case Model
Objektmodel
Funktionsumfang der
nächsten Iteration
Detailspezifikation der
Use Cases und Klassen,
Systementwurf, Software
Anwenderdokumentation
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