Scrum und die IEC 62304 -...

Marc Bless

Scrumund die IEC 62304Medizinische Software mit agilen Methoden normkonform entwickeln

Leseprobe derVollständigen Ausgabe

Version 1.2

Juli 2013, Baden-Baden

coach.deagile

Vorwort zur LeseprobeDiese Leseprobe des Buches „Scrum und die IEC 62304“ bein-haltet folgende Beispielkapitel und -inhalte der vollständigen Ausgabe.

Praktiken und Artefakte:

• Sprint Review (gekürzt)• Test Automation• Zero Bug Tolerance (gekürzt)• User Story (gekürzt)

Paragraphen aus der IEC 62304:

• § 5.6 - Software integration and integration testing• § 5.7 - Software system testing• § 8.2 - Change control

Der wesentliche Unterschied zur gekürzten Ausgabe des Bu-ches liegt in der Integration der Originaltexte aus der Norm IEC 62304, wie der folgende Vergleich der Tabellen beider Ausga-ben aus dem Kapitel „Test Automation“ zeigt.

Beispiel „Test Automation“ in der gekürzten Ausgabe

§ SK Herstellung der Normkonformität

§ 5.6 BC Durch Test-Automation können bestehende Testfäl-le jederzeit wiederholt werden.

§ 5.7 BC Durch Test-Automation können alle vorhandenen Testfälle des Software-Systems nach Änderungen jederzeit durchgeführt werden.

Scrum und die IEC 62304

§ SK Herstellung der Normkonformität

§ 8.2 ABC Durch Test-Automation kann das Software-System jederzeit nach einer Änderung veri!ziert werden.

Beispiel „Test Automation“ in der vollständi-gen Ausgabe

§ SK Normtext Herstellung der Normkonformität

§ 5.6 BC retain su"cient records to permit the test to be repeated

Durch Test-Automation können bestehende Testfälle jederzeit wie-derholt werden.

§ 5.7 BC When changes are ma-de during SOFTWARE SYSTEM testing, repeat tests, perform modi!ed tests or perform additi-onal tests, as appropria-te, to verify the e#ecti-veness of the change in correcting the problem

Durch Test-Automation können alle vorhande-nen Testfälle des Soft-ware-Systems nach Änderungen jederzeit durchgeführt werden.

§ 8.2 ABC verify the change, in-cluding repeating any VERIFICATION that has been invalidated by the change

Durch Test-Automation kann das Software-Sys-tem jederzeit nach ei-ner Änderung veri!ziert werden.


Neben dieser Detaillierung der Normreferenzen für alle Prakti-ken und Artefakte ist der noch größere Mehrwert die rückwär-tige Referenz von den Norm-Texten auf alle abgeleiteten Prak-tiken und Artefakte.

Damit ist es Ihnen möglich, jederzeit für jeden Paragraphen aus der Norm herauszu!nden, mit welchen agilen Methoden er normkonform umgesetzt werden kann.

Ich wünsche Ihnen viel Vergnügen mit dieser Leseprobe und erwarte wie immer gerne Ihr Feedback und Ihre Kritik.


LESEPROBE

Schlagworte:

Medizinische Software, IEC 62304, agile Methoden, Scrum, Medizintechnik, Normkonformität, Software-Lebenszyklus, Software-Life-Cycle, Softwareentwicklung

© Marc Bless, alle Rechte vorbehalten

www.agilecoach.de

Version 1.2

Gestaltung: Marc Bless

Baden-Baden, Juli 2013

Alle Rechte vorbehalten. Insbesondere das Recht der mechani-schen, fotogra!schen oder elektronischen Vervielfältigung, der Einspeicherung und Verarbeitung in elektronischen Systemen, des Nachdruck in Zeitschriften und Zeitungen, des ö"entli-chen Vortrages, der Ver!lmung oder Dramatisierung, der Über-tragung durch Rundfunk, Fernsehen und Video, auch einzelner Bild- oder Textteile sowie der Übersetzung in andere Sprachen.


2

http://www.agilecoach.de

http://www.agilecoach.de

LESEPROBE

Inhaltsverzeichnis

Vorwort von Frank Lange 7

Über dieses Buch 9

Warum Agil und Medizintechnik? 11

Schneller Markteinstieg 11

Kundenzufriedenheit und Qualität 11

Agile Methoden - ein Mysterium? 13

Verbindung zweier Welten 14

Von der Norm zum Prozess 16

Überblick der Prozesse und Artefakte 23

Prozesse, Meetings, Reviews 28

Acceptance Testing 29

Clean Code / SOLID Principles 33

Continuous Integration 36

Early Integration / Early Testing 38

Exploratory and Manual Testing 40

Integration Testing 42

Problem Communication 45

Product Backlog Grooming 47

Quality Management Prozess 53

Release Planning Meeting 55

Risk Analysis and Management 58

Scrum 65


3

LESEPROBE

Software Maintenance Process 67

Sprint Planning 69

Sprint Retrospective 75

Sprint Review 77

Team Kick-O! Meeting 85

Test Automation 87

Test-Driven Development (TDD) 92

Unit Testing 97

Usability Process 100

Zero Bug Tolerance 102

Dokumente, Artefakte, Pläne 106

Architecture Documentation 107

Definition of Done 109

Definition of Ready 113

Iteration Notes (Sprint Notizen) 116

Linkable IDs 118

Product Backlog 120

Release Notes 123

Software Development Plan 125

Software Maintenance Plan 128

Sprint Development Plan = Sprint Backlog 130

Team Charter / Working Agreements 133

Test Documentation 136

User Story 138

Versioning System 145


4

LESEPROBE

Von den Anforderungen der Norm zu Praktiken und Arte-fakten 148

§ 1 - Scope 149

§ 4 - General requirements 151

§ 5 - Software development process 155

§ 5.1 - Software development planning 155

§ 5.2 - Software requirements analysis 162

§ 5.3 - Software architectural design 169

§ 5.4 - Software detailed design 172

§ 5.5 - Software unit implementation and vericifation 175

§ 5.6 - Software integration and integration testing 179

§ 5.7 - Software system testing 184

§ 5.8 - Software release 190

§ 6 - Software maintenance process 193

§ 6.1 - Establish software maintenance plan 193

§ 6.2 - Problem and modification analysis 196

§ 6.3 - Modification implementation 199

§ 7 - Software risk management process 201

§ 7.1 - Analysis of software contributing to hazardous situations 201

§ 7.2 - Risk control measures 204

§ 7.3 - Verification of risk control measures 206

§ 7.4 - Risk management of software changes 208

§ 8 - Software configuration management process 209

§ 8.1 - Configuration identification 209

§ 8.2 - Change control 211

§ 8.3 - Configuration status accounting 213


5

LESEPROBE

§ 9 - Software problem resolution process 214

Literatur- und Quellenverzeichnis 218

Feedback und Kontakt 223


6

LESEPROBE

Sprint Review

Beschreibung

Im Sprint Review Meeting wird vom Team vorgestellt, was im letzten Sprint alles geschehen ist und welche User Stories bzw. Anforderungen umgesetzt sind. Ziel des Sprint Review Mee-tings ist es, Feedback von allen beteiligten Stakeholdern zu erhalten und auf dieser Basis das Product Backlog für die kommenden Sprints anzupassen.

Es ist ein weitverbreiteter Irrtum, dass das Sprint Review Mee-ting dafür genutzt werden soll, die umgesetzten Stories und Anforderungen !nal zu beurteilen, abzunehmen und frei zu geben. Dies soll nach Möglichkeit bereits während des Sprints geschehen, sobald die einzelnen Stories und Anforderungen vom Team umgesetzt wurden. Auch hier gilt das Prinzip des frühen Feedbacks. Das Sprint Review Meeting ist gewisserma-ßen die letzte Möglichkeit für den Product Owner zur Abnah-me und Freigabe, birgt jedoch immer die Gefahr, dass Fehler und Mißverständnisse zu spät entdeckt werden und es damit nicht mehr möglich ist, diese noch im Sprint zu beseitigen.

Ein weiterer Irrtum besteht darin, das Sprint Review Meeting als reine Demonstration der umgesetzten Features zu nutzen. Eine Demo des entstandenen Produktinkrementes ist zwe ein wichtiger Bestandteil des Sprint Review Meetings, es geht je-doch viel mehr darum, das Feedback von echten Anwendern und Stakeholdern einzuholen.

Folgende Fragestellungen sollen im Sprint Review Meeting erörtert werden:

• Sind wir auf dem richtigen Weg mit unserer Produktentwick-lung?

• Hilft das, was wir erzeugt haben, wirklich dem Anwender?


77

LESEPROBE

• Welche (neuen) Erkenntnisse haben die Anwender und Sta-keholder bezüglich der weiteren Produktgestaltung gewon-nen?

• Welche Teile des kommenden Product Backlogs sind noch wichtig, welche sind obsolet?

Verantwortliche/beteiligte Rollen

• Product Owner• Entwicklungs-Team• Scrum Master• Stakeholder

Referenzen

• http://www.mountaingoatsoftware.com/scrum/sprint-review-meeting

• http://www.scrumcrazy.com/Tips+for+a+Good+Sprint+Review

Umgesetzte Anforderungen aus der Norm


§ 1 ABC All PROCESS outputs should be maintained in a consistent state

Im Sprint Review wird die Konsistenz geprüft zwischen der erzeugten Software, ihrer Anfor-derungen und weiterer Ergebnisse bzw. Inputs.


78

LESEPROBE


§ 5.2 ABC ensure that existing requirements, including SYSTEM requirements, are re-EVALUATED and updated as appropriate as a result of the soft-ware requirements ana-lysis ACTIVITY

Die Ergebnisse und Erkenntnisse aus dem Sprint Review Meeting "ießen als Feedback direkt in die Anforde-rungen ein und können im anschließenden Sprint Planning Mee-ting bedacht werden.

§ 5.4 C verify and document that the software detai-led design implements and follows the soft-ware ARCHITECTURE

Im Sprint Review wird präsentiert, dass das umgesetzte Software-Design der Software-Architektur entspricht.

§ 5.5 BC ensure that SOFTWARE UNITS meet acceptance criteria

Im Sprint Review zeigt das Team, welche Ak-zeptanzkriterien in Form von Testfällen die Software erfolgreich durchlaufen hat.

§ 5.6 BC EVALUATE the integra-tion test procedures for correctness

Im Sprint Review wer-den die Integrations-tests auf Korrektheit geprüft.

§ 5.7 BC verify that the VERIFI-CATION strategies and the test procedures used are appropriate

Im Sprint Review wird über Veri!kation und Testen berichtet.


80

LESEPROBE


§ 5.7 BC verify that all software requirements have be-en tested or otherwise VERIFIED

Im Sprint Review Mee-ting berichtet das Team über die durchgeführ-ten Tests aller umge-setzten Anforderungen.

§ 5.7 BC verify that test results meet the required pass/fail criteria

Im Sprint Review wer-den die umgesetzten Anforderung auf Basis ihrer Akzeptanzkriteri-en abgenommen und freigegeben.

Hinweis: das Sprint Re-view Meeting ist nicht dafür gedacht, die um-setzten Features durch den Product Owner abnehmen zu lassen. Es stellt nur den letzten Zeitpunkt dar, an dem dies geschehen kann. Sinnvollerweise werden Features bereits wäh-rend des Sprints direkt nach der Umsetzung vom Product Owner abgenommen.


81

LESEPROBE


§ 5.7 BC verify that SOFTWARE SYSTEM test procedu-res trace to software requirements

Im Sprint Review Mee-ting präsentiert das Team die erzeugten und durchgeführten Tests zu den umgesetz-ten Anforderungen. (Es werden keine Tests erstellt, zu denen keine Anforderungen existie-ren.)

§ 5.7 ABC test coverage of requi-rements, RISK CON-TROL, usability, and test types (e.g., fault, instal-lation, stress) should be demonstrated and documented

Im Sprint Review wer-den die entwickelten und durchlaufenen Tests, sowie die Test-Abdeckung demonst-riert.

§ 5.8 BC ensure that software VERIFICATION has been completed and the re-sults EVALUATED before the software is released

Im Sprint Review wer-den die umgesetzten Anforderungen evalu-iert und freigegeben, bevor sie in ein Softwa-re-Release gelangen können.

§ 7.3 BC evaluate implemented risk control measures to identify new possible hazards

Im Sprint Review wer-den umgesetzte Risiko-Maßnahmen auf neue mögliche Gefahrensi-tuationen hin unter-sucht.


82

LESEPROBE

Test Automation

Beschreibung

Eine Test-Automation ist die Basis für kontinuierliche Integrati-on und ermöglicht eine e#ziente Veri!kation nach jeder klei-nen Änderung am System.

Oft wird die Frage gestellt, ob wirklich jeder Test automatisiert werden soll. Die gültige Antwort darauf lautet: jeder Test, der mehr als ein mal durchgeführt werden wird, sollte automati-siert werden.

Durch Test-Automation wird ein Sicherheitsnetz hergestellt, welches uns ermöglicht, jederzeit ein lau$ähiges Gesamtsys-tem herstellen zu können. Die gewonnene Sicherheit meldet uns Fehler, die sich durch Seitene$ekte in Schnittstellen und Funktionalitäten eingeschlichen haben. Diese Fehler können dann sofort beseitigt werden, so dass wir mit einem funktio-nierenden Gesamtsystem weiter arbeiten können.


• Entwicklungs-Team

Referenzen

• Lisa Crispin - Agile Testing• http://xprogramming.com/articles/automatedtesting/ • http://xprogramming.com/blog/automating-story-tests/


87

LESEPROBE



§ 5.5 BC ensure that SOFTWARE UNITS meet acceptance criteria

Durch Test-Automation wird sichergestellt, dass die Software immer wieder die de!nierten Akzeptanzkriterien in Form von automatisier-ten Tests erfolgreich durchläuft.

§ 5.5 BC perform the SOFTWARE UNIT VERIFICATION and document the results

Durch Test-Automation können die Ergebnisse aller Unit-Tests als Do-kumentation erzeugt werden.

§ 5.6 BC conduct REGRESSION TESTING appropriate to demonstrate that de-fects have not been introduced into pre-viously integrated software

Regressionstests vor-handener Software-Versionen können durch Test-Automation jederzeit sicherstellen, dass keine Fehler im Software-System entstanden sind.

§ 5.6 BC retain su#cient records to permit the test to be repeated

Durch Test-Automation können bestehende Testfälle jederzeit wie-derholt werden.


88

LESEPROBE


§ 5.6 BC document the test re-sult (pass/fail and a list of ANOMALIES)

Mit einer Test-Automa-tion kann durch die Durchführung aller vorhandenen Tests eine Dokumentation der Test-Resultate erzeugt werden.

§ 5.7 BC verify that all software requirements have be-en tested or otherwise VERIFIED

Mit Hilfe einer umfas-senden Test-Automati-on kann sichergestellt und nachgewiesen werden, dass alle An-forderungen getestet und veri!ziert sind.

§ 5.7 BC establish and perform a set of tests, expressed as input stimuli, expec-ted outcomes, pass/fail criteria and procedures, for conducting SOFT-WARE SYSTEM testing, such that all software requirements are co-vered

Durch Test-Automation können die Testfälle aller Software-Anforde-rungen jederzeit durchgeführt werden.

§ 5.7 ABC When a change is made to a SOFTWARE SYS-TEM, REGRESSION TES-TING should be deter-mined, planned and documented.

Durch Test-Automation kann das gesamte Software-System nach einer Änderung vollständig mit allen vorhandenen Testfällen geprüft werden.


89

LESEPROBE


§ 5.7 BC When changes are ma-de during SOFTWARE SYSTEM testing, con-duct testing appropria-te to demonstrate that unintended side e$ects have not been introdu-ced

Durch Test-Automation kann das gesamte Software-System nach einer Änderung vollständig mit allen vorhandenen Testfällen geprüft werden.

§ 5.7 BC When changes are ma-de during SOFTWARE SYSTEM testing, repeat tests, perform modi!ed tests or perform additi-onal tests, as appropria-te, to verify the e$ecti-veness of the change in correcting the problem

Durch Test-Automation können alle vorhande-nen Testfälle des Soft-ware-Systems nach Änderungen jederzeit durchgeführt werden.

§ 8.2 ABC verify the change, in-cluding repeating any VERIFICATION that has been invalidated by the change

Durch Test-Automation kann das Software-Sys-tem jederzeit nach ei-ner Änderung veri!ziert werden.

Verknüpfung mit anderen Praktiken und Arte-fakten

• Test Documentation - Die benötigte Test Dokumentation wird mit Hilfe der Test Automation bei Bedarf auf Knopfdruck automatisch erzeugt.


90

LESEPROBE

• Continuous Integration - Kontinuierliche Integration benö-tigt eine funktionierende Test-Automatisierung, um ihren Nutzen entfalten zu können.


91

LESEPROBE

Zero Bug Tolerance

Beschreibung

Zero Bug Tolerance sorgt dafür, dass während einer Produkt-entwicklung keine Fehler verwaltet werden, sondern dass die-se behoben werden. Das Verwalten von Fehlern und die Be-wertung und Auswertung dadurch entstehender Fehlerlisten kostet eine große Menge an Zeit und Energie, welche die E#-zienz für wichtige Entwicklungsaufgaben reduziert.

Auf den ersten Blick mag es utopisch und unrealistisch klingen, keine Fehler verwalten zu wollen. Dies führt in letzter Konse-quenz dazu, kein Fehler-Tracking-System mehr zu benötigen.

Die Anwendung der Zero Bug Tolerance ist jedoch denkbar einfach:

• Entdeckte/gefundene Fehler werden schnellstmöglich von Team und Product Owner bewertet. Sie verbleiben nicht erst lange „auf Halde“ in einem eigenen Verwaltungssystem, sondern kommen direkt zur Bewertung auf den Tisch.

• Entweder handelt es sich um einen dringlichen Fehler, wel-che eine bereits umgesetzte Funktionalität beeinträchtigt. Dann wird dieser Fehler weit oben im Product Backlog ein-sortiert, um möglichst in der nächsten Iteration behoben werden zu können.

• Oft handelt es sich um einen nicht nachvollziehbaren oder sogar unwichtigen „Fehler“, der die Funktionalität für den Anwender in keiner Weise einschränkt. Diese Art von Fehler


102

LESEPROBE

können direkt gelöscht werden14, da der Nutzen ihrer Behe-bung in keinem Verhältnis zum Aufwand steht.

• Manchmal wird aus einer Fehlermeldung ein Feature-Wunsch. In diesem Fall kann ein entsprechender Eintrag vom Product Owner im Product Backlog angelegt werden.


• Product Owner• Entwicklungs-Team• Scrum Master

Referenzen

• http://www.infoq.com/news/2011/02/zero-defect-systems• http://www.joelonsoftware.com/articles/fog0000000043.ht

ml (Punkt 5)• http://sdt.bz/32548


103

14 Dieses Vorgehen erfordert Mut und die Einsicht, dass durch das Aufbewahren alter und unwichtiger Fehlermeldungen kein Mehrwert für eine spätere Fehlerbehebung gewonnen wird. Soll-te Ihr Umfeld dieses Vorgehen nicht zulassen, dann versuchen Sie zumindest, solche Fehlermeldungen in ein Archiv zu ver-schieben, welches nicht jederzeit Sichtbar ist und den Blick auf das Wesentliche verschleiert.

LESEPROBE



§ 5.6 BC enter ANOMALIES found during software integration and integra-tion testing into a soft-ware problem resoluti-on PROCESS

Eine konsequente Zero-Bug-Tolerance führt dazu, dass alle Fehler, welche während der Software-Integration gefunden werden, schnellstmöglich be-hoben oder als irrele-vant de!niert werden.

§ 5.7 BC enter ANOMALIES found during software system testing into a software problem reso-lution PROCESS

Eine konsequente Zero-Bug-Tolerance führt dazu, dass alle Fehler, welche während der Software- und System-Tests gefunden werden, schnellstmöglich be-hoben oder als irrele-vant de!niert werden.

§ 5.7 ABC If a decision has been made not to !x anoma-lies, they need to be EVALUATED in relation to the HAZARD analysis and the SAFETY of the device. Root cause and symptoms of ANOMA-LIES, and the rationale for not !xing them should be documented.

Bei einer Zero Bug Tole-rance muss nicht jedes Problem und nicht je-der Fehler behoben werden. Falls entschie-den wird, einen Fehler nicht zu beheben, muss die Begründung do-kumentiert werden. Dies kann direkt im entsprechenden Backlog-Eintrag erfol-gen.


104

LESEPROBE

User Story

Beschreibung

Eine User Story steht in diesem Kontext für sämtliche Typen von Anforderungen, die in einem Product Backlog oder Sprint Backlog enthalten sein können.

Unter den Begri$ fallen:

• User Story,• technische Story,• Fehlerbeschreibung,• Problembeschreibung, • Anforderung,• etc.

Echte User Stories helfen dem Product Owner und dem Ent-wicklungs-Team dabei, den Fokus auf den Anwendernutzen zu legen. Bei jeder Diskussion über Inhalte und Anforderungen an das zu erstellende System sollen Fragen folgender Art gestellt werden:

• „Für welchen Anwender erzeugt dies genau welchen Nut-zen?“

• „Welches Problem wird durch die Umsetzung dieser Story behoben?“

User Stories be!nden sich anfänglich im Product Backlog und durchlaufen ihren Lebenszyklus über die De!nition-of-Ready in das Sprint Backlog des Entwicklungs-Teams. Dort werden sie zerlegt in Tasks, die während der Iteration abgearbeitet wer-den, bis die User Story über die De!nition-of-Done vom Pro-duct Owner abgenommen wird und aus der weiteren Betrach-tung herausfällt.


138

LESEPROBE


• Product Owner• Entwicklungs-Team

Referenzen

• Mike Cohn - User Stories Applied• http://guide.agilealliance.org/guide/stories.html• http://www.extremeprogramming.org/rules/userstories.html• http://www.mountaingoatsoftware.com/topics/user-stories



§ 4 ABC when a SOFTWARE I-TEM is decomposed into further SOFTWARE ITEMS, such SOFTWARE ITEMS shall inherit the software safety classi!-cation of the original SOFTWARE ITEM

User Stories, welche durch Story Splitting aus einer übergeordne-ten User Story entstan-den sind, erben die Sicherheitsklassi!zie-rung dieser übergeord-neten User Story.

§ 4 ABC document the software safety class assigned to each SOFTWARE SYS-TEM in the RISK MANA-GEMENT FILE

Die Sicherheitsklassi!-zierung wird als Attri-but jeder User Story zugeordnet, welche die Risiko-Analyse durch-laufen hat.


139

LESEPROBE


§ 5.7 BC establish and perform a set of tests, expressed as input stimuli, expec-ted outcomes, pass/fail criteria and procedures, for conducting SOFT-WARE SYSTEM testing, such that all software requirements are co-vered

Eine User Story beinhal-tet alle Testfälle, welche notwendig sind, um die Anforderungen dieser User Story prüfen und sicherstellen zu kön-nen.

§ 5.7 BC verify that SOFTWARE SYSTEM test procedu-res trace to software requirements

User Stories beinhalten neben der De!nition einer Anforderung auch deren Akzeptanz- und Testkriterien.

§ 6.2 ABC record PROBLEM RE-PORTS that include actual or potential ad-verse events, and devi-ations from speci!cati-ons

User Stories können auch Fehler- und Prob-lemberichte darstellen, welche Abweichungen der Anforderungen und der Spezi!kation bein-halten.

§ 8.2 ABC provide traceability of change requests, their approvals, and relevant problem reports

Eine User Story, welche auf Basis eines Prob-lems formuliert wird, beinhaltet den zugehö-rigen Problembericht, um Traceability herzu-stellen.


143

LESEPROBE

Von den Anforderungen der Norm zu Praktiken und ArtefaktenDieses Kapitel beinhaltet die Gesamttabelle aller Normtexte mit Verweis aus den entsprechenden Paragraphen und die Si-cherheitsklassi!zierung, sowie eine Beschreibung der jeweili-gen Normkonformität und eine Praktik bzw. ein Artefakt, mit dem die Konformität hergestellt werden kann.

Hinweis! In der gekürzten Ausgabe dieses Buches sind die In-halte dieses Kapitels nicht enthalten. Bei Interesse wenden Sie sich bitte an den Autor.


148

LESEPROBE

§ 5.6 - Software integration and in-tegration testing

SK Normtext Herstellung der Normkonformität

Praktik/Artefakt

BC conduct REGRESSI-ON TESTING appro-priate to demonstra-te that defects have not been introduced into previously in-tegrated software

Regressionstests vorhandener Soft-ware-Versionen können durch Test-Automation jeder-zeit sicherstellen, dass keine Fehler im Software-System entstanden sind.

Test Auto-mation

BC document the test result (pass/fail and a list of ANOMALIES)

Mit einer Test-Auto-mation kann durch die Durchführung aller vorhandenen Tests eine Dokumen-tation der Test-Resul-tate erzeugt werden.

Test Auto-mation

BC enter ANOMALIES found during soft-ware integration and integration testing into a software prob-lem resolution PRO-CESS

Eine konsequente Zero-Bug-Tolerance führt dazu, dass alle Fehler, welche wäh-rend der Software-Integration gefun-den werden, schnellstmöglich behoben oder als irrelevant de!niert werden.

Zero Bug Tolerance


179

LESEPROBE


Praktik/Artefakt

BC enter ANOMALIES found during soft-ware integration and integration testing into a software prob-lem resolution PRO-CESS

Fehler, welche wäh-rend der Software-Integration auftau-chen, werden im Sprint Backlog ge-p"egt, um sie schnellstmöglich zu beheben.

Sprint De-velopment Plan = Sprint Backlog

BC EVALUATE the integ-ration test procedu-res for correctness

Im Sprint Review werden die Integra-tionstests auf Kor-rektheit geprüft.

Sprint Re-view

BC identify the tester Die Iteration Notes (Sprint Notizen) be-inhalten die Liste der in der Iteration betei-ligten Team-Mitglie-der, wie zum Beispiel auch die Tester.

Iteration Notes (Sprint Notizen)

ABC In order to fully test a SOFTWARE PRO-DUCT both black and white box tes-ting might be requi-red.

Akzeptanztests ent-sprechen Black-Box-Tests.

Acceptan-ce Testing

ABC In order to fully test a SOFTWARE PRO-DUCT both black and white box tes-ting might be requi-red.

Exploratives Testen entspricht Black-Box-Tests.

Explorato-ry and Ma-nual Tes-ting


180

LESEPROBE

§ 5.7 - Software system testing


Praktik/Artefakt

BC enter ANOMALIES found during soft-ware system testing into a software prob-lem resolution PRO-CESS

Eine konsequente Zero-Bug-Tolerance führt dazu, dass alle Fehler, welche wäh-rend der Software- und System-Tests gefunden werden, schnellstmöglich behoben oder als irrelevant de!niert werden.

Zero Bug Tolerance

BC enter ANOMALIES found during soft-ware system testing into a software prob-lem resolution PRO-CESS

Fehler, welche wäh-rend der System-Ve-ri!kation gefunden und nicht sofort be-hoben werden, wer-den in das Product Backlog einsortiert.

Product Backlog

BC establish and per-form a set of tests, expressed as input stimuli, expected outcomes, pass/fail criteria and procedu-res, for conducting SOFTWARE SYSTEM testing, such that all software require-ments are covered

Durch Test-Automa-tion können die Test-fälle aller Software-Anforderungen je-derzeit durchgeführt werden.

Test Auto-mation


184

LESEPROBE


Praktik/Artefakt

BC It is acceptable to test software requi-rements in earlier phases.

Anforderungen kön-nen bereits vor ihrer endgültigen Umset-zung getestet und integriert werden.

Early Integ-ration / Early Tes-ting

ABC test coverage of re-quirements, RISK CONTROL, usability, and test types (e.g., fault, installation, stress) should be demonstrated and documented

Im Sprint Review werden die entwi-ckelten und durch-laufenen Tests, sowie die Test-Abdeckung demonstriert.

Sprint Re-view

BC verify that all soft-ware requirements have been tested or otherwise VERIFIED

Im Sprint Review Meeting berichtet das Team über die durchgeführten Tests aller umgesetz-ten Anforderungen.

Sprint Re-view

BC verify that all soft-ware requirements have been tested or otherwise VERIFIED

Mit Hilfe einer um-fassenden Test-Au-tomation kann si-chergestellt und nachgewiesen wer-den, dass alle Anfor-derungen getestet und veri!ziert sind.

Test Auto-mation


186

LESEPROBE


Praktik/Artefakt

BC When changes are made during SOFT-WARE SYSTEM tes-ting, repeat tests, perform modi!ed tests or perform ad-ditional tests, as ap-propriate, to verify the e$ectiveness of the change in cor-recting the problem

Durch Test-Automa-tion können alle vorhandenen Testfäl-le des Software-Sys-tems nach Änderun-gen jederzeit durch-geführt werden.

Test Auto-mation


189

LESEPROBE

§ 8.2 - Change control


Praktik/Artefakt

ABC change CONFIGURA-TION ITEMS only in response to an ap-proved CHANGE REQUEST

Die Umsetzung von Anforderungen, wel-che das bestehende Software-System verändern (in einem inkrementell-iterati-ven Prozess also alle Anforderungen), muss vom Product Owner beauftragt sein. Dies kann mit Hilfe der De!nition-of-Ready sicherge-stellt werden.

De!nition of Ready

ABC identify and perform any ACTIVITY that needs to be repea-ted as a result of the change, including changes to the soft-ware safety classi!-cation of SOFTWARE SYSTEMS and SOFTWARE ITEMS

Im Sprint Planning Meeting werden vom Team alle Tasks identi!ziert, welche für die Umsetzung einer Änderung (er-neut) durchgeführt werden müssen.

Sprint Planning


211

LESEPROBE


Praktik/Artefakt

ABC provide traceability of change requests, their approvals, and relevant problem reports

Eine User Story, wel-che auf Basis eines Problems formuliert wird, beinhaltet den zugehörigen Prob-lembericht, um Tra-ceability herzustel-len.

User Story

ABC verify the change, including repeating any VERIFICATION that has been invali-dated by the change

Durch Test-Automa-tion kann das Soft-ware-System jeder-zeit nach einer Än-derung veri!ziert werden.

Test Auto-mation


212

Scrum und die IEC 62304 -...

Documents

Transcript of Scrum und die IEC 62304 -...