Requirements Engineering in agilen Projekten - Flexibilität ist gefordert

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


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


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


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


Vorstudie

Konzeption

Iterationsplanung


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


Vorstudie

Konzeption

Iterationsplanung


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


Vorstudie

Konzeption

Iterationsplanung


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


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

Vielen Dank für Ihre Aufmerksamkeit!

Kontakt:

[email protected]

www.gedoplan.de