Already a subscriber?
MADCAD.com Free Trial
Sign up for a 3 day free trial to explore the MADCAD.com interface, PLUS access the
2009 International Building Code to see how it all works.
If you like to setup a quick demo, let us know at support@madcad.com
or +1 800.798.9296 and we will be happy to schedule a webinar for you.
Security check
Please login to your personal account to use this feature.
Please login to your authorized staff account to use this feature.
Are you sure you want to empty the cart?
AAMI TIR45:2012/(R)2018 - Guidance on the use of AGILE practices in the development of medical device software, 2012
- AAMI TIR45:2012/(R)2018, Guidance on the use of AGILE practices in the development of medical device software
- Title Page
- AAMI Technical Information Report
- Copyright
- Contents
- Glossary of equivalent standards
- Committee representation
- Foreword
- Introduction [Go to Page]
- Why read this TIR?
- Initial recommendations
- 1 Scope [Go to Page]
- 1.1 Inclusions
- 1.2 Exclusions
- 1.3 Organization: Navigating this document
- 2 References
- 3 Terms and definitions
- 4 Setting the stage [Go to Page]
- 4.1 The agile perspective [Go to Page]
- 4.1.1 Agile goals, values, principles, and practices
- 4.1.2 Expectations for tailoring
- 4.2 The regulatory perspective [Go to Page]
- 4.2.1 The U.S. FDA regulatory perspective
- 4.2.2 International and other regulatory perspectives
- 4.2.3 IEC 62304
- 4.2.4 Regulatory goals, values, principles, and practices
- 4.2.5 Expectations for tailoring
- 4.2.6 Where to learn more
- 4.3 Aligning perspectives [Go to Page]
- 4.3.1 Aligning on goals
- 4.3.2 Aligning on values [Go to Page]
- 4.3.2.1 Individuals and interactions over process and tools
- 4.3.2.2 Working software over comprehensive documentation
- 4.3.2.3 Customer collaboration over contract negotiation
- 4.3.2.4 Responding to change over following a plan
- 4.3.3 Transitioning to the use of agile for medical device software development [Go to Page]
- 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
- 4.3.3.3 When the existing quality management system needs improvement
- 5 Aligning on concepts [Go to Page]
- 5.1 Incremental/evolutionary lifecycle [Go to Page]
- 5.1.1 Specifying the software development lifecycle
- 5.1.2 Mapping the process model to the lifecycle model
- 5.1.3 Executing process activities in multiple layers of abstraction
- 5.1.4 Process flow: the timing and sequence of process activity execution
- 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
- 5.1.8 Defining “done”
- 5.1.9 Feedback mechanisms and iterations
- 5.2 Inputs and outputs [Go to Page]
- 5.2.1 Which inputs
- 5.2.2 Entry criteria for inputs
- 5.2.3 Exit criteria for outputs
- 5.3 Design inputs and design outputs [Go to Page]
- 5.3.1 Activities for producing design inputs and design outputs
- 5.3.2 Breaking up the work
- 5.3.3 Timing of design inputs and design outputs within an agile story
- 5.3.4 Inputs to agile stories
- 5.3.5 Synchronizing design inputs and design outputs
- 5.3.6 Final verification
- 5.4 Design reviews [Go to Page]
- 5.4.1 Formal design review at stage boundaries
- 5.4.2 Reviews as a verification activity
- 5.4.3 Independence of review
- 5.5 Documentation [Go to Page]
- 5.5.1 Use of documentation
- 5.5.2 Sequencing of documentation activities
- 5.5.3 Sum-of-the-parts of documentation
- 5.5.4 Process artifacts (the audit trail)
- 5.6 Managing the dynamic nature of agile [Go to Page]
- 5.6.1 Embrace change, manage change
- 5.6.2 Satisfy the customer
- 5.6.3 Maintain the software development process
- 5.7 Human safety risk management
- 6 Aligning on Practices [Go to Page]
- 6.1 Topics related to planning [Go to Page]
- 6.1.1 Is agile too undisciplined to meet planning requirements?
- 6.1.2 Is shippable software, after every increment, a realistic expectation?
- 6.1.3 Agile’s 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
- 6.2 Topics related to team structure and collaboration [Go to Page]
- 6.2.1 Pairing
- 6.2.2 Stop the line
- 6.2.3 retrospectives/reflections
- 6.2.4 Collective ownership
- 6.3 Topics related to product definition and requirements documentation [Go to Page]
- 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
- 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?
- 6.4 Topics related to software architecture [Go to Page]
- 6.4.1 Evolving architecture
- 6.4.2 Architecture planning
- 6.4.3 Architecture verification
- 6.5 Topics related to detailed design [Go to Page]
- 6.5.1 Activities of detailed design
- 6.5.2 Emergent design
- 6.5.3 Documentation of detailed design
- 6.6 Topics related to implementation and unit verification
- 6.7 Topics related to integration and integration testing
- 6.8 Topics related to software system testing [Go to Page]
- 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
- 6.8.5 Documentation of software system testing results
- 6.8.6 Traceability
- 6.9 Topics related to software release
- 6.10 Topics related to configuration management and change management [Go to Page]
- 6.10.1 Software configuration identification
- 6.10.2 Management of soup on agile projects
- 6.10.3 Agile’s impact on change control
- 6.11 Topics related to corrective and preventive action
- Bibliography [Go to Page]