Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld

Größe: px

Ab Seite anzeigen:

Download "Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld"

Michaela Kerner
vor 8 Jahren
Abrufe

1 Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld Bernhard Fischer Fischer Consulting GmbH MedConf 2011 Luzern Folie 1

2 Wozu brauchen wir Requirements? MedConf 2011 Luzern Folie 2

3 Der Anforderungszoo Nutzungsanforderungen Kundenanforderungen Systemanforderungen Sub-Systemanforderungen Komponentenanforderungen Funktionale Anforderungen Nicht-Funktionale Anforderungen Leistungsanforderungen Performanzanforderungen Wartungsanforderungen Speicheranforderungen. MedConf 2011 Luzern Folie 3

Funktionale Anforderungen Nicht-Funktionale Anforderungen

4 Requirements als Kommunikationsmittel Was ist für das Produkt nötig um erfolgreich zu sein? Wie mache ich deutlich ich benötige? Marketing + Vertrieb Wie verstehe ich die Benutzer und deren Erfordernisse? Welche Benutzer Details des Features Gebrauchstauglichkeit muss ich beschreiben? In welche Reihenfolge soll entwickelt und werden und wie verfolge ich den Fortschritt Projektmanager Tester Wie teste ich das Produkt? Entwickler Product Owner / RE Engineer Um welche Aufgaben muss ich mich heute kümmern? MedConf 2011 Luzern Folie 4

Welche Benutzer Details des Features Gebrauchstauglichkeit muss ich beschreiben?

5 Aufgaben des RM RE als Planungsgrundlage RE als Architekturgrundlage RE als Entwicklungsgrundlage RE als Verifizierungsgrundlage MedConf 2011 Luzern Folie 5

6 Und agiles Requirements Engineering? MedConf 2011 Luzern Folie 6

Das agile Manifest: 8 Werte Menschen und deren Interaktionen Funktionsfähige Software Zusammenarbeit mit den Kunden Einstellung auf Änderungen sind wichtiger als ist

7 Das agile Manifest: 8 Werte Menschen und deren Interaktionen Funktionsfähige Software Zusammenarbeit mit den Kunden Einstellung auf Änderungen sind wichtiger als ist wichtiger als ist wichtiger als ist wichtiger als Prozesse und Werkzeuge Umfangreiche Dokumentation Vertragsverhandlungen Verfolgung eines Plans MedConf 2011 Luzern Folie 7

ist wichtiger als ist wichtiger als ist wichtiger als Prozesse und Werkzeuge

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 8

oberster Ebene und verfeinere sie mit der Zeit Stelle jede Funktionalität vollständig fertig, bevor

9 Und konkret? SCRUM als Beispiel MedConf 2011 Luzern Folie 9

10 Scrum Das Konzept Standup Meeting alle 24 Stunden Sprint Backlog Sprint 2-6 Wochen In Tasks heruntergebrochen Potentiell auslieferbares Produkt-Inkrement Product Backlog MedConf 2011 Luzern Folie 10

11 Scrum Rollen Scrum Master Team Entwickler und Tester Product Owner MedConf 2011 Luzern Folie 11

12 Das Product Backlog MedConf 2011 Luzern Folie 12

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 13

Product Owner priorisiert - Durch das Team abgeschätzt - Kann zu Beginn eines jedenn Sprints neu

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 Als

14 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 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. MedConf 2011 Luzern Folie 14

Als Arzt möchte ich mir zu einem Patienten eine Liste der Medikamente angezeigen lassen, die

15 Der Product Backlog Eisberg Sprint High Future Releases Release Priority Value Cost Risk Knowledge Low MedConf 2011 Luzern Folie 15

16 Anforderungen an RE in einer regulierten Umgebung MedConf 2011 Luzern Folie 16

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 17

Systemanforderungen Traceability zwischen System und SW-Anforderungen

18 Gebrauchstauglichkeit als Grundlage von Requirements Engineering und Systementwicklung MedConf 2011 Luzern Folie 18

P/B als Gemeinschaftswerk 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 Kunden clients und

19 P/B als Gemeinschaftswerk 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 Kunden clients und Benutzer 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 Stakeholder - insbesondere Usability Experte Fred Brooks, The Mythical Man Month: Product Owner Essays on Software Engineering. MedConf 2011 Luzern Folie 19

For the truth is, the clients do not know what they want.

20 Herleitung von Erfordernissen Nutzungskontext Nutzergruppe(n) Erfordernisse MedConf 2011 Luzern Folie 20

21 Nutzungsanforderungen Nutzungsanforderungen Fachlichen Anforderungen Kernaufgaben Nutzungsszenarien System- und /SW- Anforderungen MedConf 2011 Luzern Folie 21

Nutzungsanforderungen - Eine Nutzungsanforderung ist eine Benutzeraktion an einem interaktiven System, in einer die Tätigkeit beschreibenden Weise nicht in technisch realisierender

22 Nutzungsanforderungen - Eine Nutzungsanforderung ist eine Benutzeraktion an einem interaktiven System, in einer die Tätigkeit beschreibenden Weise nicht in technisch realisierender Weise Als Arzt muss ich zu einem Patienten alle aktuellen Verschreibungen einsehen können. (keine Angabe des Warum Bezug auf das zugrundeliegenden Erfordernis) MedConf 2011 Luzern Folie 22

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 23

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 24

25 The Story Metamodel MedConf 2011 Luzern Folie 25

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 26

27 Requirements Engineering als Grundlage von Architektur und Entwicklung MedConf 2011 Luzern Folie 27

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 28

29 Iterative-inkrementelle Entwicklung? MedConf 2011 Luzern Folie 29

30 Iterative-inkrementelle Entwicklung MedConf 2011 Luzern Folie 30

31 Ablauf einer Iteration Iteration beginnt Iteration planen Sprint Backlog Für jede User Story der aktuellen Iteration Anforderungen analysieren User Stories des Sprint Backlogs aktualisiert Risikoanalyse aktualisiert Systemarchitektur aktualisieren Detailliertes Design, soweit erforderlich, aktualisiert Testspezifikation aktualisiert Storytestplanen und erstellen Lösung entwerfen implementieren und testen Implementierung Modultest + zugehörige Protokolle Storytest durchführen Testprotokoll Iterationsergebnisse prüfen und freigeben Retrospektive Iteration beendet MedConf 2011 Luzern Folie 31

32 Requirements Engineering als Verifizierung-Grundlage MedConf 2011 Luzern Folie 32

33 Erforderliche Verifizierung? Die IEC fordert: Verifizierung der SW-Einheiten Verifizierung der SW-Integration Verifizierung des SW-Systems MedConf 2011 Luzern Folie 33

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 34

35 Fazit MedConf 2011 Luzern Folie 35

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 36

37 It s Question Time! Fischer Consulting GmbH Waldstr. 106 D Bochum info@bfischer-consulting.de MedConf 2011 Luzern Folie 37

Ähnliche Dokumente

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ