agiles anforderungsmanagement? wie soll denn das bei ...€¦ · 2 requirement-basiertes testen §...

Agiles Anforderungsmanagement?Wie soll denn das bei medizinischer SW funktionieren? Was braucht es denn dazu?

25.10.2016

Bertram HerzogAgilist, SCRUM-Master, SW-Program Manager, Medizininformatiker

225.10.2016Carl Zeiss Meditec AG, Bertram Herzog, Medical Technology Business Group

Vorstellung

§ Bertram Herzog - Medizininformatiker (Dipl.-Inform. Med.) aus Leidenschaft- Software-Projektleiter (Carl Zeiss Meditec AG), u.a.

Requirements-Engineering- Software-Qualitätsverantwortlicher im (SW-)Projekt (Carl Zeiss

Meditec AG)- SCRUM-Master für 3 Entwicklungsteams von insgesamt 25

Personen.- stets in der Medizin-SW unterwegs: Cerner (Image Devices),

Siemens AG – syngo.via§ Inspirationen aus vielen Tagen Arbeitsalltag – ausschließlich

persönlich gefärbt J§ Inspirationen aus der AAMI University Schulung „Effective

Application of Agile Practices in the Development of Medical Device Software (TIR 45)“


Agenda

Einführung

• Requirements-Engineering im klassischen vs. agilen Projekt• Rolle und Ziele im med. Projekt, • Rolle und Ziele im agilen med. Projekt

• Die große Herausforderung agiler Projektdokumentationen

Agile Annahmen und Stolpersteine

im RE

• User-Stories ODER Requirements• Exkurs: Normen – oder: Wer fordert eigentlich Anforderungen an?• Trad. Gründe für Requirements – oder: „Als … brauche ich 1 Anforderung, um ...“

• Testen – ein Kultur-Thema ?!• Exkurs: Fluch und Segen der Testautomatisierung, „die wahren Gralshüter“

• Menge und Struktur von Requirements• Refactoring von Requirements• Traceability• Dokumentation und Tooling

Schluss

• Synopsis• Zusammenfassung• Fazit, Ausblick• Anspruch und Ziele erreicht?


Requirements-Engineeringim klassichen vs. agilen Projekt

§ klassisches Projekt (ein „Durchlauf“):- Anforderungen als DER stichhaltige Transporteur des

Gewollten à Vertragscharakter zwischen allen Beteiligten- Grundlage für Schätzungen (Kosten, Risiko) & Tests (Qualität)

à Requirements-Engineering als Methode stellt die Validität dieses rechtlichen Vertragswerkes sicher.

§ agiles Projekt:- meist User Stories als Transporteur des Gewollten, incl.

des Grundes und Wertes, warum es gewollt ist àVertragscharakter ungeklärt

à Requirements-Engineering als Methode stellt was sicher?


Requirements-Engineeringim agilen Projekt

§ Das „iterative“erlaubt es, bestimmte Projektstadien immer wieder zu durchlaufen,bedingt es, bestimmte Projektmeilensteine immer wieder zu durchlaufen

§ Das „inkrementelle“erlaubt es, das Produkt stetig zu erweitern, bedingt es, dass Erweiterungen ins Produkt dokumentiert eingebracht werden können.


Requirements-Engineering Ziele im med. SW-Projekt

§ Medizinprodukt muss vor Inverkehrbringen (meist) zugelassen werden- Konformitätsbewertungsverfahren, z.B. EU - Zulassungsverfahren, z.B. USA, China

§ Geschieht durch Aufzeigen, dass Arbeitsweise systematisch und deterministisch war:- Konformitätsbewertungsverfahren: „Ich habe mich an die

geforderten Standards gehalten.“- Zulassungsverfahren / Audit: Ich kann die in der

Zulassung nötige Argumentation plausibel aufbauenà Fazit: Requirements-Engineering wird als hoher Wert /

Disziplin der Wahl zur Sicherung dieser Ansprüche angesehen.


Requirements-Engineering Ziele im agilen med. SW-Projekt

§ Gleiche Ziele, aber immer wieder à Iterativ inkrementell§ Herausforderungen:

- Ist jede Iteration ein volles Mini-Projekt?- Wie klein und schnell, wie „lean“ können wir werden?


„The Great Challenge“

§ Am Ende muss sich die Bewertung auf das „FinishedDevice“ beziehen.

à Wir wollen eine Aussage über das „Finished Device“, nicht den Weg dorthin!

§ Wie können wir von vielen Imkrementen auf „das Finished Device“ schließen?

§ Was muss wirklich am „finished Device“ gezeigt werden?


Agenda

Einführung




im RE




Schluss

• Synopsis• Zusammenfassung• Fazit, Ausblick• Anspruch und Ziele erreicht?


Hauptteil


Der Weg der agilen Annahmen und Stolpersteine im Requirements-Engineering

§ User-Stories vs. Requirements- Exkurs: Normen- Traditionelle Gründe für Requirements

§ Testen (akzeptanzbasiertes Testen vs. Test nach Req.-Spezifikation)

§ Menge und Struktur von Requirements§ Refactoring von Requirements§ Traceability§ Dokumentation und Tooling


User Story vs. Requirements1

§ Warum sollten wir im Agilen Projekt überhaupt noch Requirements pflegen?

§ Wir haben doch alles in User Stories aufgeschrieben!


Wer fordert eigentlich Anforderungen an?

§ Was sagen die Normen zu Requirements, die wir wirklich brauchen?- 62304- 62366-1:2015- EN-ISO 14971:2012- FDA QSR 820.30(c) / GSVP

§ Was ist ein „Requirement“ und was nicht?


Wer fordert eigentlich „Anforderungen“ an?

§ Requirements kommen aus „User Needs“, die sich ergeben, um den „Intended Use“ sicher zu erfüllen.

à Alles, was nicht aus „User Needs“ und Intended Usekommt, ist kein Requirement.

à Alles, was der Sicherheit des Produktes zuträgt, ist ganz sicher ein Requirement.


User Story vs. Requirements1

§ Lessons Learned: - User Stories sind kompakt.- User Stories sind im Inhalt sehr sehr wertvoll.- Summe aller User-Stories beschreibt aber den

zurückgelegten Weg zum Produkt, nicht das Produkt selbst.

- Requirement Specification beschreibt das Produkt! - Frage ist, für wen sie geschrieben wird, d.h. wer was

daraus ableitet? Wer sind die Kunden / Leser?- User Stories sind gefühlt weniger „informell“, wenn sie für

die Dokumentation und Zulassung verwendet werden.§ In der Kürze liegt die Würze!


Akzeptanzbasiertes Testen ersetzt Requirement-basiertes Testen 2

§ Als Tester brauche ich ein Requirement, sonst kann ich keinen Test schreiben.

§ Risiken werden dann weniger kontrolliert betrachtet und mitigiert.

§ Als Tester brauche ich jetzt für diese (nicht-)Funktionalität ein Requirement, sonst kann ich keinen Test „anhängen“.


Traditionelle Gründe für Requirements

Als … brauche ich ein Requirement, damit ich … kann.§ Tester à verifizieren

- Ist die Funktion korrekt, d.h. fehlerfrei umgesetzt?§ Tester / Produktmanager à validieren

- wird mit der verifizierten Funktion das User-Need erfüllt?- Kann der Benutzer die Funktion eingängig sicher

verwenden? (Usability)§ QA/QM à Traceability bestimmen

- Beziehung zwischen Anforderung und dazugehörigen Verfikations-/Validierungsergebnissen.

- Vollständigkeitsmaß / „Erfüllungsgrad“


Traditionelle Gründe für Requirementsund Ihre agilen Antagonisten

§ Verifikation à Akzeptanzkriterien- Klassisch: Anforderung als Basis.

§ Validierung à User Need, Rationale der User Story („so that“)

- Klassisch: Produkt-Requirement Specification / Usability File Input-Dokumente als Basis.

§ Traceability à Traceability- horizontal: Qualitätsmaß:

Anforderung à Verfikation/Validierung,- vertikal: Erfüllungsgrad des „Kundenwunsches“


§ Lessons Learned (1/2): - Ja, unbedingt machen!- Tester im Team lernen in der Diskussion so viel mehr und

können so viel mehr Feedback an Entwickler / SW-Architekten geben, wie es ein schriftliches (Prozess-) Modell nie erreichen würde.

- Akzeptanzkriterien sind das Qualitätsmaß von User Stories.

- Akzeptanzbasiertes Testen hilft, Requirements lösungsfrei zu halten! Tests sind eher lösungsgebunden.



§ Lessons Learned (2/2): - Traceability zur RiA gefährdet?

- Nein, da im Gegenteil in den Diskussionen eher noch neue Schritte aufgedeckt werden können, die zu einer Gefährdungssituation führen können.

- Idee bricht das bisherige Traceability-Modell, das in vielen Tools als Metrik zugrunde liegt.

- Testfallorganisation muss sich tatsächlich von der Organisation der Anforderungen lösen.

§ Kultur-Thema



Warum ist das Test-Tooling so „old-school“3

§ Warum können wir nicht genauso cool testen wie wir entwickeln?

§ Wie können wir aus der Mannigfaltigkeit von Testergebnissen „einfach“ sinnige Reports generieren?


Warum ist das Test-Tooling so „old-school“3

§ Lessons Learned:- Test-Tooling und Test-Rest-Result-Management

unterliegt als Support-Tool den strengen Regeln der Toolvalidierung à „Heiliger Gral“

- Im Gegensatz zu einem Phasenmodell entsteht in einem inkrementell-iterativen Vorgehen mit automatisierten Tests ein Vielfaches an Testergebnissen.

- Tooling muss mit der Menge der Ergebnisse klarkommen;

- Reports müssen einerseits Nutzergerecht sein (Entwickler, Tester), aber auch „zulassungsfördernd“ sein (d.h. auf Meilensteine komprimierbar)


Wie halten wir die Menge der Anforderungen niedrig? Wie bekommen wir sie kleiner?(Requirements-Change-Management)

§ Was passiert beim Hinzufügen einer Anforderung:

Anfo

rder

ung

inha

ltlic

h ne

u

Anfo

rder

ung

freig

eben

Neu

e Lö

sung

im

plem

entie

ren

Neu

e Lö

sung

frei

gebe

n

Neu

e Te

stfä

lle e

rste

llen

und

an A

nfor

deru

ng li

nken

.

TF a

usfü

hren

auf

neu

er

SW-V

ersi

on

TF-E

rgeb

niss

e ve

rwal

ten


Wie halten wir die Menge der Anforderungen niedrig?4

§ Wie können wir verhindern, dass unsere Anforderungsmenge ausufert?


§ Lessons Learned:- Willensstark sein und kritisch prüfen -- es ist schon fast

alles gesagt worden…- Braucht diese User-Story tatsächlich eine neue Anforderung

/ eine Erweiterung einer Anforderung?- Würde ich die Lösung spezifizieren, und nicht die

Anforderung?- Ein neuer Test rechtfertigt noch keine neue Anforderung!- „Flughöhe prüfen“: Ist es anforderungsrelevant, oder „zu low-

level“?- Ist es für die Sicherheit des Systems und für den Intended

Use nötig?- Kann es auch in ein anderes, u.U. nicht derart streng

kontrolliertes Dokument? (interne Dok., Usability-Spec)

Wie halten wir die Menge der Anforderungen niedrig?4


„Flughöhe“ von Requirements

[Quelle: http://www.slideshare.net/jeffpatton/user-story-mapping-2008 via http://jpattonassociates.com/category/slides/ (2016-10-22)]


Wie bekommen wir die Menge der Anforderungen kleiner / handhabbarer?5

§ Wie können wir verhindern, dass unsere Anforderungsmenge ausufert?

§ Wie können wir verhindern, dass wir uns „verzetteln“§ Wie können wir konsistent bleiben und übersichtlich?


Anforderungsmenge verringern, resilienterbekommen? à Requirements-Refactoring

§ Was passiert beim Ändern einer Anforderung:à Branching

„skeptisches Tooling“: - alle abhängigen Anf. revalidieren,- alle abhängigne TCs revalidieren- alle bisherigen Testergebnisse einfrieren.

Anfo

rder

ung

inha

ltlic

h än

dern

„ske

ptis

ches

Too

ling“

àTr

acea

bilit

yei

nfrie

ren*

Anfo

rder

ung

freig

eben

Neu

e Lö

sung

im

plem

entie

ren

Neu

e Lö

sung

frei

gebe

n

Alte

Tes

tfälle

w

iede

rver

wen

den

oder

Neu

e Te

stfä

lle e

rste

llen

und

an

Anfo

rder

ung

linke

n.

TF a

usfü

hren

auf

neu

er S

W-

Vers

ion

TF-E

rgeb

niss

e ve

rwal

ten


§ Lessons Learned:- Vgl. letztes „Lessons Learned“- Anforderungen Clustern und Themen / verschlagworten /

N-/FRs à Voraussetzung für Vieles, thematisches „Refactoring“

- Funktionalität (Business Logik) und Trigger (UI) getrennt halten. à Resilienz

- Anforderungen durch kurzen Titel kennzeichnen àermöglicht ein „Querlesen“

- Anforderungen ähnlich einem Objektmodell aufbauen „allgemein“, „genauer“ à erleichtert Refactoring

- Unbedingt: Testfälle unabhängig von Anforderungen ebenfalls organisieren à nicht nur über Traceability

Wie bekommen wir die Menge der Anforderungen kleiner / handhabbarer?5


Wie bekommen wir sie kleiner und resilienter? à Requirements-Refactoring - Beispiel

§ Beispiel zu einem Anforderungs-RefactoringStartpunkt: Req. beschreibt Logik eines Bildschirms incl. aller Feldwerte, Aktionen der Buttons, Bedingungen, wann was wählbar ist.Zielpunkt: Logik und (G)UI trennen, evtl. „Zwischenebene einziehen“, risikobasiert trennen, Links innerhalb der Req. einführen, TCs auftrennenà Branching


Requirements-Refactoring – Beispiel

§ StartpunktThe system shall offer a Login func-tionalityon a login-screen where the user can enteruser credentials. The system shall offer theability to login or to close the applicationwithout logging on. The button to Log-In shallonly be enabled if the user name is the nameof a registered users.If and only if the credentials are correct, thesystem shall …

à Divide and Conquer, Risk vs. NoRisk


Requirements-Refactoring - Beispiel

§ Mögl. Endpunkt:[SystemSecurity_RestrictedAccess] (vielleicht sogar eine risikominimierende Maßnahme - Cybersecurity)

[Login_Functionality]

[Login_AccessViaGui]u.U. auch [Login_AccessViaCmdLine]


Traceability im Agilen Med. SW-Projekt

§ Viel mehr Datenpunkte an Testergebnissen basierend auf vielen verschiedenen Systemzuständen (pro Inkrement)

§ Was lohnt sich aufzuheben?§ Was kann man aufgeben?§ Was muss mein Tooling können?





Sprint(10 Tage)

Anforderungen

Testfälle Testergebnisse(Daily B.)

STestergebnisse

1 1 3 15 (*) 152 1 3 30 453 2 6 15a + 15n 754 3 10 30a + 15n 120

à Beispielrechnung:1 Anforderung, Projektdauer 4 Sprints (á 10 Werktage), Erweiterung im 3. Sprint, Split im 4. Sprint, Daily Test-Cycle




§ Was lohnt sich aufzuheben?§ Was kann man aufgeben?§ Was muss mein Tooling können?à Traceability kommt ohne effektives Tooling nicht aus

(vgl. Folie „Testing“)à … kann zu jedem Zeitpunkt verfügbar sein (vgl.

„Coverage“)à … muss zu jedem Meilenstein und für das „Finished

Device“ aggregierbar sein.



§ Was heißt „aggregierbar“?à

§ Wer „leitet“ die Versionierung?à gewählter Zeitpunkt

User Story1 User Story2

Anforderung 1

Anforderung 2

Testfall 1

Testfall 2

Testergebnis 1

Testergebnis 2

Anforderung 2‘ Testfall 2‘ Testergebnis 2‘

Testergebnis 1

Zeit



§ Was heißt „aggregierbar“?à

§ Wer „leitet“ die Versionierung?à gewählter Zeitpunkt

User Story1 User Story2

Anforderung 1

Anforderung 2

Testfall 1

Testfall 2

Testergebnis 1

Testergebnis 2

Anforderung 2‘

Testfall 2‘

Testergebnis 2‘

Testergebnis 1

Zeit

User Story2-1

Testergebnis 2


Wie behalten wir den Überblick?à Dokumentation und Tooling6



§ Lessons Learned:- Für die tägliche Arbeit: Dashboards (transient)- Für das „finished device“ und „Projektmeilensteine“:

Summaries aus Tools, die ein „Drill-Down“ ermöglichen- Requirements-/Test-Tooling sollte mit der agilen

Toolchain (Sprint, Release-Planning) koppelbar sein.- Für die Dokumentation: Toolvalidierung durchführen

(lassen).

Wie behalten wir den Überblick?à Dokumentation und Tooling6


… und jetzt nochmals zurück zur Königsfrage:Brauchen wir im Agilen Projekt Requirements?

§ Steht nicht in guten User Stories alles drinnen?à In guten User Stories steht alles drinnen, was es für das

tägliche Arbeiten braucht!à Aus guten User Stories lässt sich ein schlanker Satz an

Requirements ableiten, der für den Überblick im Projekt unabdingbar ist, denn er bildet immer das gesamte Produkt ab.

§ Sowohl als auch – aber schlank!


Agenda

Einführung




im RE




Schluss

• Synopsis• Zusammenfassung• Fazit• Anspruch und Ziele erreicht? Ausblick


Zusammenfassung

§ Agiles Requirements Management funktioniert.§ User Stories und Requirements ergänzen sich.§ Requirements dienen dem Überblick.§ Änderungen an der ToolChain sind essentiell.§ Es ist ein Kulturwandel

- auf Seiten der Entwicklung,- auf Seiten der Verifikation und Validierung.

§ Es ist ein Blick-Wandel, denn die gleichen Werte des agiles Manifests gelten jetzt nicht nur „für mich“, sondern auch „um mich herum“.


Agiles Anforderungsmanagement?Wie soll denn das bei medizinischer SW funktionieren? Was braucht es denn dazu?

§ Wie?à Mit Hilfe eines Mind-Sets, das inkrementell-iterative

Prozesse zulässt und leben will.

§ Was braucht es dazu?à Mut (zum Weglassen), Änderungswille,

Durchhaltevermögen, Offene Herzen, Offenen Geist, gute Werkzeuge


Zusammenfassung

Auswirkungen auf… sind

… Welche Auswirkungen hat solch ein Vorgehen auf meinen Anforderungsprozess?… auf meinen Dokumentationsprozess?

…auf meine Tool-Chain? …auf meine Team-Mitglieder

und das Projekt

Keine, außer der Tatsache, dass es immer wieder möglich sein muss, Anforderungen ohne Panik ändern zu können.

Ich muss zu jedem Zeitpunkt (evtl. sogar für jeden Zeitupunkt) ein konsistentes Dokument erzeugen können (auch die Test-Seite des V) (vgl. DevOps)

Meine Tool-Chain muss mich im obigen unterstützen, sie darf mich nicht behindern.

Das Team darf jederzeit Änderungen wollen wollen, da es selbst auch iterativ arbeitet.


IEC 62304

… und gegen wie viele Normen haben wir jetzt verstoßen?

ISO 13485QM-

System

TIR45


Vielen Dank!à Fragen ?


Ausblick: Fluch und Segen der TestautomatisierungDev-Ops-Kulturen

§ Testautomatisierung ist ein „muss“ im inkrementell-iterativen, sonst erstickt das Projekt in Änderungsanalysen.

à Requirement als Design-Input für ein Inkrement gerät wieder unter Zeit-Druck

§ Dev-Ops-Ansätzen und „Continuous Release“ revolutionieren den Ansatz von „Nightly Builds“, „Stabilisierungs-Builds“, „Release-Builds“

à Requirement und Test-Case geraten unter der „Mähmaschine“ Dev-Ops unter (Zeit-)Druck

new


Backup-Slide: Agile Manifesto


Backup-Slide: Wie kann ein agiles Vorgehen jetzt aussehen?


Requirements aus Sicht der FDA

(Aber was muss ich jetzt dokumentieren?)


Alles, was nicht aus „User Needs“ und Intended Usekommt, ist kein Requirement.

§ User Needs müssen validiert werden, Requirementsmüssen verifiziert werden.

(Wann das im Projekt geschieht, regelt der Testplan, nicht unbedingt per se das SW-Entwicklungsmodell.)


Die „Anforderung“, die „Verifikation“, die „Validierung“ und die „Traceability“


à Alles, was nicht aus „User Needs“ und Intended Usekommt, ist kein Requirement.

§ Verifikation§ Validierung (SW-Validierung, z.B. GSVP / Usability

Tests / Validierung gemäß 62366)à User Needs müssen validiert werden, Requirements

müssen verifiziert werden.§ Traceability ist ein Maß, mit dem eine Beziehung

zwischen zwei oder mehr Produkten des Entwicklungsprozesses gemacht werden kann.


Agenda

- Einführung: Das alt-griechische Projektdrama- Requirements-Engineering im klassischen vs. agilen Projekt

- Rolle und Ziele im med. Projekt, - Rolle und Ziele im agilen med. Projekt- Die große Herausforderung agiler Projektdokumentationen

- Der Weg der agilen Annahmen und Stolpersteine im Requirements-Engineering- Die sofortige Frage: User-Stories vs. Requirements

- Exkurs: Normen – oder: Wer fordert eigentlich Anforderungen an?- Traditionelle Gründe für Requirements – oder: „Als … brauche ich eine

Anforderung, um ...“- Testen (akzeptanzbasiertes Testen vs. Test nach Req.-Spezifikation) – ein

Kultur-Thema ?!Exkurs: Fluch und Segen der Testautomatisierung, „die wahren Gralshüter“

- Menge und Struktur von Requirements- Refactoring von Requirements- Traceability- Dokumentation und Tooling

- Synopsis, Zusammenfassung, Fazit, Anspruch und Ziel erreicht?

agiles anforderungsmanagement? wie soll denn das bei ...€¦ · 2 requirement-basiertes testen §...

Documents