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<\/p>\n
| PDF Pages<\/th>\n | PDF Title<\/th>\n<\/tr>\n | ||||||
|---|---|---|---|---|---|---|---|
| 1<\/td>\n | AAMI TIR45:2012\/(R)2018, Guidance on the use of AGILE practices in the development of medical device software <\/td>\n<\/tr>\n | ||||||
| 3<\/td>\n | Title Page <\/td>\n<\/tr>\n | ||||||
| 4<\/td>\n | AAMI Technical Information Report Copyright <\/td>\n<\/tr>\n | ||||||
| 5<\/td>\n | Contents <\/td>\n<\/tr>\n | ||||||
| 8<\/td>\n | Glossary of equivalent standards <\/td>\n<\/tr>\n | ||||||
| 11<\/td>\n | Committee representation <\/td>\n<\/tr>\n | ||||||
| 13<\/td>\n | Foreword <\/td>\n<\/tr>\n | ||||||
| 14<\/td>\n | Introduction Why read this TIR? Initial recommendations <\/td>\n<\/tr>\n | ||||||
| 17<\/td>\n | 1 Scope 1.1 Inclusions 1.2 Exclusions <\/td>\n<\/tr>\n | ||||||
| 18<\/td>\n | 1.3 Organization: Navigating this document <\/td>\n<\/tr>\n | ||||||
| 19<\/td>\n | 2 References <\/td>\n<\/tr>\n | ||||||
| 20<\/td>\n | 3 Terms and definitions <\/td>\n<\/tr>\n | ||||||
| 27<\/td>\n | 4 Setting the stage 4.1 The agile perspective 4.1.1 Agile goals, values, principles, and practices <\/td>\n<\/tr>\n | ||||||
| 29<\/td>\n | 4.1.2 Expectations for tailoring 4.2 The regulatory perspective 4.2.1 The U.S. FDA regulatory perspective 4.2.2 International and other regulatory perspectives <\/td>\n<\/tr>\n | ||||||
| 30<\/td>\n | 4.2.3 IEC 62304 4.2.4 Regulatory goals, values, principles, and practices <\/td>\n<\/tr>\n | ||||||
| 31<\/td>\n | 4.2.5 Expectations for tailoring 4.2.6 Where to learn more 4.3 Aligning perspectives 4.3.1 Aligning on goals <\/td>\n<\/tr>\n | ||||||
| 32<\/td>\n | 4.3.2 Aligning on values 4.3.2.1 Individuals and interactions over process and tools <\/td>\n<\/tr>\n | ||||||
| 33<\/td>\n | 4.3.2.2 Working software over comprehensive documentation 4.3.2.3 Customer collaboration over contract negotiation <\/td>\n<\/tr>\n | ||||||
| 34<\/td>\n | 4.3.2.4 Responding to change over following a plan <\/td>\n<\/tr>\n | ||||||
| 35<\/td>\n | 4.3.3 Transitioning to the use of agile for medical device software development 4.3.3.1 Aligning agile with a quality management system 4.3.3.2 When the existing quality management system is robust and effective <\/td>\n<\/tr>\n | ||||||
| 36<\/td>\n | 4.3.3.3 When the existing quality management system needs improvement 5 Aligning on concepts 5.1 Incremental\/evolutionary lifecycle <\/td>\n<\/tr>\n | ||||||
| 37<\/td>\n | 5.1.1 Specifying the software development lifecycle <\/td>\n<\/tr>\n | ||||||
| 38<\/td>\n | 5.1.2 Mapping the process model to the lifecycle model <\/td>\n<\/tr>\n | ||||||
| 40<\/td>\n | 5.1.3 Executing process activities in multiple layers of abstraction <\/td>\n<\/tr>\n | ||||||
| 41<\/td>\n | 5.1.4 Process flow: the timing and sequence of process activity execution 5.1.5 Frequency and granularity of process activities <\/td>\n<\/tr>\n | ||||||
| 42<\/td>\n | 5.1.6 The importance of integration activities 5.1.7 The importance of software configuration management <\/td>\n<\/tr>\n | ||||||
| 43<\/td>\n | 5.1.8 Defining \u201cdone\u201d 5.1.9 Feedback mechanisms and iterations 5.2 Inputs and outputs <\/td>\n<\/tr>\n | ||||||
| 44<\/td>\n | 5.2.1 Which inputs 5.2.2 Entry criteria for inputs <\/td>\n<\/tr>\n | ||||||
| 45<\/td>\n | 5.2.3 Exit criteria for outputs 5.3 Design inputs and design outputs <\/td>\n<\/tr>\n | ||||||
| 46<\/td>\n | 5.3.1 Activities for producing design inputs and design outputs <\/td>\n<\/tr>\n | ||||||
| 47<\/td>\n | 5.3.2 Breaking up the work <\/td>\n<\/tr>\n | ||||||
| 48<\/td>\n | 5.3.3 Timing of design inputs and design outputs within an agile story <\/td>\n<\/tr>\n | ||||||
| 50<\/td>\n | 5.3.4 Inputs to agile stories 5.3.5 Synchronizing design inputs and design outputs <\/td>\n<\/tr>\n | ||||||
| 52<\/td>\n | 5.3.6 Final verification 5.4 Design reviews 5.4.1 Formal design review at stage boundaries 5.4.2 Reviews as a verification activity <\/td>\n<\/tr>\n | ||||||
| 53<\/td>\n | 5.4.3 Independence of review 5.5 Documentation 5.5.1 Use of documentation <\/td>\n<\/tr>\n | ||||||
| 55<\/td>\n | 5.5.2 Sequencing of documentation activities 5.5.3 Sum-of-the-parts of documentation <\/td>\n<\/tr>\n | ||||||
| 56<\/td>\n | 5.5.4 Process artifacts (the audit trail) 5.6 Managing the dynamic nature of agile 5.6.1 Embrace change, manage change <\/td>\n<\/tr>\n | ||||||
| 57<\/td>\n | 5.6.2 Satisfy the customer 5.6.3 Maintain the software development process 5.7 Human safety risk management <\/td>\n<\/tr>\n | ||||||
| 58<\/td>\n | 6 Aligning on Practices 6.1 Topics related to planning 6.1.1 Is agile too undisciplined to meet planning requirements? <\/td>\n<\/tr>\n | ||||||
| 59<\/td>\n | 6.1.2 Is shippable software, after every increment, a realistic expectation? 6.1.3 Agile\u2019s focus on “working software” and continuous integration forms a very effective integration strategy 6.1.4 Agile’s done is done concept is core to creating a verification plan <\/td>\n<\/tr>\n | ||||||
| 60<\/td>\n | 6.2 Topics related to team structure and collaboration 6.2.1 Pairing <\/td>\n<\/tr>\n | ||||||
| 62<\/td>\n | 6.2.2 Stop the line 6.2.3 retrospectives\/reflections 6.2.4 Collective ownership <\/td>\n<\/tr>\n | ||||||
| 63<\/td>\n | 6.3 Topics related to product definition and requirements documentation 6.3.1 When does a story have enough definition for the team to begin work? 6.3.2 Requirements done when a story is done <\/td>\n<\/tr>\n | ||||||
| 64<\/td>\n | 6.3.3 Requirements documentation 6.3.4 Can stories\/acceptance tests be used for final requirements? 6.3.5 Can executable requirements be a valid part of the requirements definition and documentation? 6.3.6 How does agile help with requirements verification and validation? <\/td>\n<\/tr>\n | ||||||
| 65<\/td>\n | 6.4 Topics related to software architecture 6.4.1 Evolving architecture 6.4.2 Architecture planning <\/td>\n<\/tr>\n | ||||||
| 66<\/td>\n | 6.4.3 Architecture verification 6.5 Topics related to detailed design 6.5.1 Activities of detailed design <\/td>\n<\/tr>\n | ||||||
| 67<\/td>\n | 6.5.2 Emergent design 6.5.3 Documentation of detailed design <\/td>\n<\/tr>\n | ||||||
| 68<\/td>\n | 6.6 Topics related to implementation and unit verification <\/td>\n<\/tr>\n | ||||||
| 69<\/td>\n | 6.7 Topics related to integration and integration testing 6.8 Topics related to software system testing <\/td>\n<\/tr>\n | ||||||
| 70<\/td>\n | 6.8.1 The importance of software system test planning 6.8.2 The value of continuous testing 6.8.3 The importance of regression testing 6.8.4 Tests are as important as the code <\/td>\n<\/tr>\n | ||||||
| 71<\/td>\n | 6.8.5 Documentation of software system testing results 6.8.6 Traceability 6.9 Topics related to software release <\/td>\n<\/tr>\n | ||||||
| 72<\/td>\n | 6.10 Topics related to configuration management and change management 6.10.1 Software configuration identification 6.10.2 Management of soup on agile projects 6.10.3 Agile\u2019s impact on change control <\/td>\n<\/tr>\n | ||||||
| 73<\/td>\n | 6.11 Topics related to corrective and preventive action <\/td>\n<\/tr>\n | ||||||
| 74<\/td>\n | Bibliography <\/td>\n<\/tr>\n<\/table>\n","protected":false},"excerpt":{"rendered":" AAMI TIR45:2012\/(R)2018 – Guidance on the use of AGILE practices in the development of medical device software<\/b><\/p>\n |