Over the past several years, agile software development has become an accepted method for developing software products. There have been questions from both manufacturers and regulators as to whether (or which) agile practices are appropriate for developing medical device software. Enough medical device manufacturers have implemented agile practices in their software development so that answers to these questions can be documented. Having clear guidance of which practices have been found to be appropriate will be very useful for all developers of medical device software. This TIR will provide recommendations for complying with international standards and U.S. Food and Drug Administration (FDA) guidance documents when using agile practices to develop medical device software.

PDF Catalog

PDF Pages	PDF Title
1	AAMI TIR45:2023; Guidance on the use of AGILE practices in the development of medical device software
3	Title page
4	AAMI Technical Information Report Copyright information
5	Contents
7	Committee representation
10	Foreword
11	Introduction
13	1 Scope 1.1 Inclusions 1.2 Exclusions
14	1.3 Organization: Navigating this document
15	2 Normative references
16	3 Terms and definitions 3.1 agile 3.2 acceptance test-driven development ATDD 3.3 backlog
17	3.4 build 3.5 burndown/burnup chart 3.6 CAPA 3.7 design input/output 3.8 done 3.9 emergence/emergent 3.10 evolutionary strategy
18	Figure 1—EVOLUTIONARY life cycle 3.11 executable requirements 3.12 increment 3.13 incremental
19	Figure 2—INCREMENTAL life cycle: “Staged delivery”
20	Figure 3—INCREMENTAL life cycle: “Design to schedule” 3.14 increment layer 3.15 iteration 3.16 lean
21	3.17 product layer 3.18 release 3.19 release layer 3.20 refactor/refactoring 3.21 retrospective 3.22 software development life cycle model
22	3.23 software of unknown provenance SOUP 3.24 stakeholder 3.25 story 3.26 story layer 3.27 test-driven development TDD 3.28 traceability
23	3.29 validation 3.30 verification 3.31 waterfall 4 Setting the stage 4.1 The AGILE perspective 4.1.1 Agile benefits, values, principles, and practices
25	4.2 The regulatory perspective 4.2.1 The United States FDA regulatory perspective
26	Figure 4—Design Controls from 21 CFR 820.30 4.2.2 European Union (EU) and other regulatory perspectives 4.2.3 IEC 62304 standard
27	4.2.4 Regulatory goals, values, principles, and practices
28	4.2.5 Where to learn more 4.3 Aligning perspectives 4.3.1 Aligning on goals 4.3.2 Aligning on values
29	4.3.3 Aligning AGILE with a quality management system
30	4.3.4 Aligning on the level of rigor and robustness 5 Aligning on concepts 5.1 incremental/evolutionary life cycle
31	5.1.1 Specifying the software development life cycle 5.1.2 Mapping the process model to the life cycle model
32	Figure 5—Mapping IEC 62304’s activities into AGILE’S INCREMENTAL/EVOLUTIONARY life cycle
33	5.1.3 Executing process activities in multiple layers of abstraction
34	5.1.4 Process flow: the timing and sequence of process activity execution
35	5.1.5 Frequency and granularity of process activities 5.1.6 The importance of integration activities 5.1.7 The importance of software configuration management
36	5.1.8 Defining “done” 5.1.9 Feedback mechanisms
37	5.1.10 Aligning agile and non-agile development teams 5.1.10.1 Planning and synchronization 5.1.10.2 Aligning design inputs
38	5.1.10.3 Aligning design outputs
39	5.2 Inputs and outputs 5.2.1 Which inputs 5.2.2 Entry criteria for inputs
40	5.2.3 Exit criteria for outputs 5.3 Design inputs and design outputs
41	5.3.1 Activities for producing DESIGN INPUTs and DESIGN OUTPUTs
42	Figure 6—DESIGN INPUT/OUTPUT relationship: Highest level of abstraction 5.3.2 Breaking up the work Figure 7—DESIGN INPUT/OUTPUT relationship: WATERFALL development
43	Figure 8—DESIGN INPUT/OUTPUT relationship: INCREMENTAL/EVOLUTIONARY 5.3.3 Timing of design inputs and design outputs within an agile story
44	Figure 9—DESIGN INPUT/OUTPUT relationship: STORY level Figure 10—DESIGN INPUT/OUTPUT relationship: STORY level showing activities
45	Figure 11—DESIGN INPUT/OUTPUT relationship: STORY level showing detail and sequencing 5.3.4 Inputs to agile STORIES
46	5.3.5 Synchronizing design inputs and design outputs Figure 12—Synchronizing DESIGN INPUT/OUTPUT at INCREMENT and RELEASE boundaries
47	5.3.6 Final verification 5.4 Design reviews
48	5.4.1 Formal design review at stage boundaries 5.4.2 Reviews as a verification activity 5.4.3 Independence of review
49	5.5 Documentation 5.5.1 Use of documentation Figure 13—A linear flow of process activities
50	Figure 14—A parallel flow of process activities
51	5.5.2 Sequencing of documentation activities 5.5.3 Sum-of-the-parts of documentation
52	Figure 15—Sum-of-the-parts documentation 5.5.4 Process artifacts (the audit trail)
53	5.5.5 Approvals and evidence
54	5.6 Managing the dynamic nature of agile
55	5.6.1 Embrace change, manage change 5.6.2 Satisfy the customer 5.6.3 Maintain the software development process
56	5.6.4 The role of software tools in regulated agile
57	5.7 Human safety risk management
58	6 Aligning on practices 6.1 Addressing IEC 62304 in an agile way 6.1.1 Topics related to planning 6.1.1.1 Is agile too undisciplined to meet planning requirements? 6.1.1.2 Is shippable software, after every increment, a realistic expectation?
59	6.1.1.3 Agile’s focus on “working software” and continuous integration forms a very effective integration strategy 6.1.1.4 agile’s done is done concept is core to creating a verification plan
60	6.1.2 Topics related to software requirements analysis and documentation 6.1.2.1 Relationship between STORIES and requirements
61	6.1.2.2 STORIES and Requirements: One thing or two?
62	6.1.2.3 When does a story have enough definition to begin work? 6.1.2.4 Requirements done when a story is done 6.1.2.5 Requirements documentation 6.1.2.6 Can executable requirements be a valid part of the requirements definition and documentation?
63	6.1.2.7 How does agile address requirements verification and validation? 6.1.3 Topics related to software architecture 6.1.3.1 Evolving architecture
64	6.1.3.2 Architecture planning 6.1.3.3 Architecture verification
65	6.1.4 Topics related to detailed design 6.1.4.1 Activities of detailed design 6.1.4.2 Emergent design
66	6.1.4.3 Documentation of detailed design 6.1.5 Topics related to implementation and unit verification
67	6.1.6 Topics related to integration and integration testing
68	6.1.7 Topics related to software system testing 6.1.7.1 The importance of software system test planning 6.1.7.2 The value of continuous testing 6.1.7.3 The importance of regression testing
69	6.1.7.4 Tests are as important as the code 6.1.7.5 Documentation of software system testing results 6.1.7.6 Traceability to Software System Testing 6.1.8 Topics related to software release
70	6.1.9 Topics related to configuration management and change management 6.1.9.1 Software configuration identification 6.1.9.2 Agile’s impact on change control
71	6.1.10 Objective evidence for activities defined in IEC 62304
72	Table 1—Examples of objective evidence
73	6.2 Using agile practices for regulatory compliance
74	6.2.1 Product backlog, backlog Refinement, and “Definition of Ready”
75	6.2.2 Sprint backlog 6.2.3 ITERATIONS and increments 6.2.4 “Definition of Done”
76	6.2.5 iteration review 6.2.6 Product owner role
77	6.2.7 Scrum master role
78	6.2.8 Development team role 6.2.9 Continuous integration 6.2.10 Pairing
80	6.2.11 Test driven development 6.2.12 “Stop the line” 6.2.13 retrospectives/reflections
81	6.2.14 Collective ownership 6.2.15 Coding standards
82	6.3 Addressing other regulatory requirements in an agile way 6.3.1 Topics related to design validation
83	Figure 16—Design validation activities in an AGILE model 6.3.1.1 Using a story’s definition as inputs to design validation 6.3.1.2 Product owner role in design validation
84	6.3.1.3 Demo as a design validation activity 6.3.1.4 Design validation testing in the agile model
85	6.3.1.5 Aligning incremental design validation with regulatory requirements
86	6.3.2 Topics related to risk management (safety) Figure 17—Risk management activities in an AGILE model
87	6.3.2.1 Risk management as part of backlog management 6.3.2.2 Risk management as part of backlog execution 6.3.2.3 Integrating risk management expertise
88	6.3.3 Topics related to cybersecurity Figure 18—Cybersecurity activities in an AGILE model 6.3.3.1 Cybersecurity as part of backlog management
89	6.3.3.2 Cybersecurity as part of backlog execution 6.3.3.3 Integrating cybersecurity expertise 6.3.4 Topics related to usability
90	Figure 19—Usability activities in an AGILE model 6.3.4.1 Product owner’s role in usability 6.3.4.2 Usability as part of backlog management
91	6.3.4.3 Usability as part of backlog execution 6.3.4.4 Addressing usability during product demos 6.3.4.5 Integrating usability expertise
93	Appendix A (informative) Analysis of the value statements from the manifesto for agile software development A.1 Individuals and interactions over process and tools
94	A.2 Working software over comprehensive documentation A.3 Customer collaboration over contract negotiation
95	A.4 Responding to change over following a plan
96	Appendix B (informative) Applying agile development to IEC 62304 – Quick Guide B.1 Regulation, Standards and Procedures B.2 agile Software Development and 62304
97	Figure B.1—Overview of software development processes and activities
98	Figure B.2—Medical Device Standards and 62304 processes B.3 agile – 4 layers of abstraction
99	B.3.1 Planning for Development for each of the agile Layers Figure B.3—62304 Planning activities
100	B.3.2 The product layer
101	B.3.3 The Release Layer B.3.4 The Increment Layer B.3.5 The story layer
102	B.4 Software Integration and Integration Testing
103	B.5 Software System Testing
104	Appendix C (informative) Quick reference guide Table C.2—Index of activities of interest Bibliography

Published By	Publication Date	Number of Pages
AAMI	2023	105


PDF Format	Searchable	Printable	Preview Now

Standard Title	AAMI TIR45:2023 Guidance on the use of agile practices in the development of medical device software
Published Code	AAMI
Publication Date	2023
Pages Count	105

AAMI TIR45 2023

PDF Catalog

Related products