Guidance on the use of AGILE practices in the development of medical device software

International standard - AAMI TIR 45:2012 describing AGILE practices in the development of medical device software. This standard has been recently recognized by US FDA. AAMI TIR45:2012, Guidance on the use of AGILE practices in the development of medical device software......Page 1 Title Page......Page 3 Copyright......Page 4 Contents......Page 5 Glossary of equivalent standards......Page 8 Committee representation......Page 11 Foreword......Page 13 Initial recommendations......Page 14 1.2 Exclusions......Page 17 1.3 Organization: Navigating this document......Page 18 2 References......Page 19 3 Terms and definitions......Page 20 4.1.1 Agile goals, values, principles, and practices......Page 27 4.2.2 International and other regulatory perspectives......Page 29 4.2.4 Regulatory goals, values, principles, and practices......Page 30 4.3.1 Aligning on goals......Page 31 4.3.2.1 Individuals and interactions over process and tools......Page 32 4.3.2.3 Customer collaboration over contract negotiation......Page 33 4.3.2.4 Responding to change over following a plan......Page 34 4.3.3.2 When the existing quality management system is robust and effective......Page 35 5.1 Incremental/evolutionary lifecycle......Page 36 5.1.1 Specifying the software development lifecycle......Page 37 5.1.2 Mapping the process model to the lifecycle model......Page 38 5.1.3 Executing process activities in multiple layers of abstraction......Page 40 5.1.5 Frequency and granularity of process activities......Page 41 5.1.7 The importance of software configuration management......Page 42 5.2 Inputs and outputs......Page 43 5.2.2 Entry criteria for inputs......Page 44 5.3 Design inputs and design outputs......Page 45 5.3.1 Activities for producing design inputs and design outputs......Page 46 5.3.2 Breaking up the work......Page 47 5.3.3 Timing of design inputs and design outputs within an agile story......Page 48 5.3.5 Synchronizing design inputs and design outputs......Page 50 5.4.2 Reviews as a verification activity......Page 52 5.5.1 Use of documentation......Page 53 5.5.3 Sum-of-the-parts of documentation......Page 55 5.6.1 Embrace change, manage change......Page 56 5.7 Human safety risk management......Page 57 6.1.1 Is agile too undisciplined to meet planning requirements?......Page 58 6.1.4 Agile's done is done concept is core to creating a verification plan......Page 59 6.2.1 Pairing......Page 60 6.2.4 Collective ownership......Page 62 6.3.2 Requirements done when a story is done......Page 63 6.3.6 How does agile help with requirements verification and validation?......Page 64 6.4.2 Architecture planning......Page 65 6.5.1 Activities of detailed design......Page 66 6.5.3 Documentation of detailed design......Page 67 6.6 Topics related to implementation and unit verification......Page 68 6.8 Topics related to software system testing......Page 69 6.8.4 Tests are as important as the code......Page 70 6.9 Topics related to software release......Page 71 6.10.3 Agile’s impact on change control......Page 72 6.11 Topics related to corrective and preventive action......Page 73 Bibliography......Page 74