Agiles Anforderungsmanagement mit SCRUM im … · MedConf 2011 Luzern Folie 1 Bernhard Fischer...
Transcript of Agiles Anforderungsmanagement mit SCRUM im … · MedConf 2011 Luzern Folie 1 Bernhard Fischer...
MedConf 2011 Luzern Folie 1
Bernhard Fischer
Fischer Consulting GmbH
Agiles Anforderungsmanagement mit
SCRUM
im regulierten Umfeld
MedConf 2011 Luzern Folie 3
Der Anforderungszoo
• Nutzungsanforderungen
• Kundenanforderungen
• Systemanforderungen
• Sub-Systemanforderungen
• Komponentenanforderungen
• Funktionale Anforderungen
• Nicht-Funktionale Anforderungen
• Leistungsanforderungen
• Performanzanforderungen
• Wartungsanforderungen
• Speicheranforderungen
• ….
MedConf 2011 Luzern Folie 4
Requirements als
Kommunikationsmittel
Benutzer
Wie mache ich deutlich
ich benötige?
Wie verstehe ich die
Benutzer und deren
Erfordernisse ?
Gebrauchstauglichkeit
Welche Details des Features muss ich
beschreiben?
Product Owner / RE Engineer
Um welche Aufgaben muss ich
mich heute kümmern?
Entwickler
Wie teste ich
das Produkt? Tester
Was ist für das Produkt
nötig um erfolgreich
zu sein?
Marketing + Vertrieb
In welche Reihenfolge soll entwickelt und werden und wie verfolge ich den
Fortschritt
Projektmanager
MedConf 2011 Luzern Folie 5
Aufgaben des RM
• RE als Planungsgrundlage
• RE als Architekturgrundlage
• RE als Entwicklungsgrundlage
• RE als Verifizierungsgrundlage
MedConf 2011 Luzern Folie 7
Das agile Manifest: 8 Werte
Prozesse und
Werkzeuge
Menschen und deren
Interaktionen
sind
wichtiger
als
Verfolgung eines Plans Einstellung auf
Änderungen
Umfangreiche
Dokumentation
Funktionsfähige
Software
Vertragsverhandlungen Zusammenarbeit mit
den Kunden
ist
wichtiger
als
ist
wichtiger
als
ist
wichtiger
als
MedConf 2011 Luzern Folie 8
Das agile Manifest: Folgerungen
• Aktive Benutzermitwirkung ist über den
gesamten Entwicklungsprozess erforderlich
• Anforderungen entwickeln sich über die Zeit
• Ermittle Anforderungen zunächst auf oberster
Ebene und verfeinere sie mit der Zeit
• Stelle jede Funktionalität vollständig fertig, bevor
Du die nächsten beginnst
• Zusammenarbeit zwischen allen Stakeholder ist
entscheidend
MedConf 2011 Luzern Folie 10
Scrum – Das Konzept
Sprint
2-6 Wochen
Potentiell auslieferbares Produkt-Inkrement
Product Backlog
Standup Meeting – alle 24 Stunden
In Tasks
heruntergebrochen
Product Backlog
Sprint Backlog
MedConf 2011 Luzern Folie 13
Product Backlog: Eigenschaften
- Enthält die Anforderungen an das Produkt
- Idealerweise so formuliert, das jeder Eintrag einen Nutzen für einen
Benutzer oder den Kunden hat
- Durch den Product Owner priorisiert
- Durch das Team abgeschätzt
- Kann zu Beginn eines jedenn Sprints neu priorisiert werden
- Kann neu abgeschätzt werden, wenn neue Informationen vorliegen
MedConf 2011 Luzern Folie 14
• Als Arzt
• möchte ich mir zu einem Patienten eine Liste der
Medikamente angezeigen lassen, die diesem Patient derzeit
verschrieben wurden,
• damit ich ihn nicht falsch behandle.
Anforderungen als User Stories
- Die User Stories beschreibt in einem Satz eine Systemleistung, welche
für einen Benutzer einen Nutzen hat
- Idealerweise standardisiert und in aktiver Sprache
MedConf 2011 Luzern Folie 15
Der Product Backlog Eisberg
Sprint
Release
Priority
High
Low
Future
Releases
Value
Cost
Risk
Knowledge
MedConf 2011 Luzern Folie 17
Was ist zu berücksichtigen?
• Integration der Gebrauchstauglichkeit
• Traceability zwischen Kunden- und Systemanforderungen
• Traceability zwischen System – und SW-Anforderungen
• Traceability zwischen Risk Mitigations , Gefährdungen und
SW-Komponenten
• Traceability zwischen SW-Anforderungen und Testfällen
MedConf 2011 Luzern Folie 18
Gebrauchstauglichkeit
als Grundlage von Requirements
Engineering und Systementwicklung
MedConf 2011 Luzern Folie 19
“The hardest single part of building a software
system is deciding precisely what to build … the
most important function that software builders do for
their clients is the iterative extraction and refinement
of the product requirements. For the truth is, the
clients do not know what they want. They usually do
not know what questions must be answered, and
they have almost never thought of the problem in
the detail that must be specified”
— Fred Brooks, 1995. The Mythical Man Month:
Essays on Software Engineering.
Product Owner
Usability Experte
Stakeholder - insbesondere
Kunden und Benutzer
P/B als Gemeinschaftswerk
MedConf 2011 Luzern Folie 20
Herleitung von Erfordernissen
Erfordernisse
Nutzungskontext
Nutzergruppe(n)
MedConf 2011 Luzern Folie 21
Nutzungsanforderungen
Nutzungsanforderungen
Nutzungsszenarien
Fachlichen Anforderungen
System- und /SW-
Anforderungen
Kernaufgaben
MedConf 2011 Luzern Folie 22
• Als Arzt
• muss ich zu einem Patienten alle aktuellen Verschreibungen
einsehen können.
• (keine Angabe des Warum Bezug auf das
zugrundeliegenden Erfordernis)
Nutzungsanforderungen
- Eine Nutzungsanforderung ist eine Benutzeraktion an einem interaktiven
System, in einer die Tätigkeit beschreibenden Weise – nicht in technisch
realisierender Weise
MedConf 2011 Luzern Folie 23
User Stories ?
• Nutzungsanforderungen als Basis der User Stories
• Gruppiert zu Features und ggf. Feature Sets
• Detailliert durch fachliche Anforderungen die System Inputs
und Outputs, Grenzen, etc. spezifizieren
• Detailliert durch Nicht-Funktionale Anforderungen, die
Leistungsanforderungen etc. spezifizieren
MedConf 2011 Luzern Folie 24
Informationen im P/B
User Stories
- Beschreiben das SW-Systems funktional
- Sind durch nicht-funktionale Anforderungen anreichern
- und durch fachliche Anforderungen ergänzt
- werden weiter detailliert , wenn es erforderlich ist
- Storytests dienen zur Verifizierung der Funktionalität
- User Interface Design ist immer einen Sprint voraus
MedConf 2011 Luzern Folie 26
Traceability?
• Kundenanforderungen führen auf einfache Weise zu User Stories
• Daher P/B als Requirements-Dokument verstehen.
• Zu jeder Story gehören die Testfälle, die die Funktionalität nachweisen.
Traceability daher “natürlich”
• Traceability zwischen Risk Mitigations , Gefährdungen und SW-
Komponenten: konventionell: RM-Akte, User Stories und zugehörige Test,
sowie Trace zu der Komponente über Architektur / Design
MedConf 2011 Luzern Folie 28
Architekturerstellung
Architektur
- wird auf Basis des initialen P/B erstellt
- zu Beginn der Entwicklung
- und wird – wenn notwendig – in jedem Sprint aktualisiert
- Dient als Basis der Aufwandsschätzung
- Emergentes Design auf Basis der Produktvision
- Architektur und Design gehen fließend ineinander über …
MedConf 2011 Luzern Folie 31
Sprint Backlog
User Stories des Sprint
Backlogs aktualisiert
Risikoanalyse
aktualisiert
Systemarchitektur
aktualisieren
Detailliertes Design, soweit
erforderlich, aktualisiert
Implementierung
Modultest + zugehörige
Protokolle
Testprotokoll
Anforderungen analysieren
Storytest durchführen
Retrospektive
Iterationsergebnisse
prüfen und freigeben
Iteration beendet
Iteration beginnt
Testspezifikation
aktualisiert
Storytestplanen und
erstellen
Lösung entwerfen
implementieren und testen
Iteration planen
Für jede User Story der aktuellen Iteration
Ablauf einer Iteration
MedConf 2011 Luzern Folie 33
Erforderliche Verifizierung?
Die IEC 62304 fordert:
• Verifizierung der SW-Einheiten
• Verifizierung der SW-Integration
• Verifizierung des SW-Systems
MedConf 2011 Luzern Folie 34
Umsetzung
Das SW-System
• Wird inkrementell erstellt
• Systemtest werden ebenfalls inkrementell erstellt
• Integration wird durch den Systemtest mitgetestet
• Verifizierung der Systemeinheiten werden durch Unittests abgedeckt
• Dokumente werden aktualisiert, aber typischer nicht in jedem Sprint
freigegeben.
MedConf 2011 Luzern Folie 36
Durch agiles RE
• Kann der Usability-Prozess natürlich integriert werden
• Systemtest werden inkrementell mit dem System entwickelt.
• Traceability zu Kundenanforderungen erfolgt „natürlich“
• Nutzen für Kunden und Benutzer wird in Vordergrund gestellt
• Risikomanagement nicht komplexer
• Projektmanagement erhält verlässliche Daten zur Planung
MedConf 2011 Luzern Folie 37
It’s Question Time!
Fischer Consulting GmbH
Waldstr. 106
D-44869 Bochum
www.bfischer-consulting.de