MADCAD.com - The Cloud-Based Reference Library

- Free Trial - Webinar - Feedback

Cart (0)

No items in cart.

Total

There is a technical issue about last added item. You can click "Report to us" button to let us know and we resolve the issue and return back to you or you can continue without last item via click to continue button.

Home

Content

eLibrary

Not a subscriber? Register for a trial account.

Username:
Password:

Incorrect username/password.

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.

Email *
Password *
Confirm *
First Name *
Last Name *
Title
Company Name *
Company Size *
Industry *
Address *
Address 2
City *
State *	Zip *
Country *
Phone *
How did you hear about MADCAD.com? *

Print page(s), starting from page (current page)

Continue to Print

Reset password

Enter your personal account email address to request
a password reset:

Reset password

Enter your account email address to request
a password reset:

Save As:

Are you sure you want to delete this group?

Security check

Please check the following box:

Please login to your personal account to use this feature.

Email:

Password:

Forgot your password?

Remember me for one month

Need a login? Register now.

Please login to your authorized staff account to use this feature.

Username:

Password:

Are you sure you want to empty the cart?

There were no books found for the applied search filters.

CLICK TO START OVER

Report To Us

Please fill the form below so that we can contact you.

Full name*
Email*
Phone

Contact us for a custom quote

Please fill the form below and a member of our staff will contact you shortly. The contents of your cart will automatically be sent to us so we can provide an accurate custom quote.

Company*
Full name*
Email*
Phone

⨯To continue with accurate pricing,
please select your company type below:

Large goverment organizations

Large multi-national corporation (more than $5B annual revenue)

None of the above

Your company has a special pricing case for IEEE.
For pricing, please contact us by filling out the form.

Full name*
Email*
Phone
Your selection

⨯We need your input!

Are you a code official in a jurisdiction with less than 300,000 population?

Yes No

This item is only available for the code officials of jurisdictions less then 300K population.

If you do not meet the criteria item will be removed and you will be able to continue shopping other items.

⨯ We need your input!

Your company has a special pricing case for ASME.
Please make sure the information you provide below is accurate.

Company Industry
Number Of Employees
Revenue

Pricing for the ASME publications in the store is for a 1-4 employee company in Construction Industry with revenue under $500,000.
If correct company info does not match what is publicly available info we will suspend the access and contact you for correction.
Please call 1-800-798-9296 if you have any questions.
If your company has more than 5,000 employee or more than 500 mil revenue please email us at info@madcad.com to receive a special quote, use "ASME Quote" on the subject line.

Cart Warning

eLibrary > AAMI TIR45:2023 Guidance on the use of agile practices in the development of medical device software >

AAMI TIR45:2023 Guidance on the use of agile practices in the development of medical device software, 2023

AAMI TIR45:2023; Guidance on the use of AGILE practices in the development of medical device software
Title page
AAMI Technical Information Report
Copyright information
Contents
Committee representation
Foreword
Introduction
1 Scope [Go to Page]
1.1 Inclusions
1.2 Exclusions
1.3 Organization: Navigating this document
2 Normative references
3 Terms and definitions [Go to Page]
3.1 agile
3.2 acceptance test-driven development ATDD
3.3 backlog
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 [Go to Page]
Figure 1—EVOLUTIONARY life cycle
3.11 executable requirements
3.12 increment
3.13 incremental [Go to Page]
Figure 2—INCREMENTAL life cycle: “Staged delivery”
Figure 3—INCREMENTAL life cycle: “Design to schedule”
3.14 increment layer
3.15 iteration
3.16 lean
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
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
3.29 validation
3.30 verification
3.31 waterfall
4 Setting the stage [Go to Page]
4.1 The AGILE perspective [Go to Page]
4.1.1 Agile benefits, values, principles, and practices
4.2 The regulatory perspective [Go to Page]
4.2.1 The United States FDA regulatory perspective [Go to Page]
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
4.2.4 Regulatory goals, values, principles, and practices
4.2.5 Where to learn more
4.3 Aligning perspectives [Go to Page]
4.3.1 Aligning on goals
4.3.2 Aligning on values
4.3.3 Aligning AGILE with a quality management system
4.3.4 Aligning on the level of rigor and robustness
5 Aligning on concepts [Go to Page]
5.1 incremental/evolutionary life cycle [Go to Page]
5.1.1 Specifying the software development life cycle
5.1.2 Mapping the process model to the life cycle model [Go to Page]
Figure 5—Mapping IEC 62304’s activities into AGILE’S INCREMENTAL/EVOLUTIONARY life cycle
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
5.1.10 Aligning agile and non-agile development teams [Go to Page]
5.1.10.1 Planning and synchronization
5.1.10.2 Aligning design inputs
5.1.10.3 Aligning design outputs
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 [Go to Page]
Figure 6—DESIGN INPUT/OUTPUT relationship: Highest level of abstraction
5.3.2 Breaking up the work [Go to Page]
Figure 7—DESIGN INPUT/OUTPUT relationship: WATERFALL development
Figure 8—DESIGN INPUT/OUTPUT relationship: INCREMENTAL/EVOLUTIONARY
5.3.3 Timing of design inputs and design outputs within an agile story [Go to Page]
Figure 9—DESIGN INPUT/OUTPUT relationship: STORY level
Figure 10—DESIGN INPUT/OUTPUT relationship: STORY level showing activities
Figure 11—DESIGN INPUT/OUTPUT relationship: STORY level showing detail and sequencing
5.3.4 Inputs to agile STORIES
5.3.5 Synchronizing design inputs and design outputs [Go to Page]
Figure 12—Synchronizing DESIGN INPUT/OUTPUT at INCREMENT and RELEASE boundaries
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 [Go to Page]
Figure 13—A linear flow of process activities
Figure 14—A parallel flow of process activities
5.5.2 Sequencing of documentation activities
5.5.3 Sum-of-the-parts of documentation [Go to Page]
Figure 15—Sum-of-the-parts documentation
5.5.4 Process artifacts (the audit trail)
5.5.5 Approvals and evidence
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.6.4 The role of software tools in regulated agile
5.7 Human safety risk management
6 Aligning on practices [Go to Page]
6.1 Addressing IEC 62304 in an agile way [Go to Page]
6.1.1 Topics related to planning [Go to Page]
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?
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
6.1.2 Topics related to software requirements analysis and documentation [Go to Page]
6.1.2.1 Relationship between STORIES and requirements
6.1.2.2 STORIES and Requirements: One thing or two?
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?
6.1.2.7 How does agile address requirements verification and validation?
6.1.3 Topics related to software architecture [Go to Page]
6.1.3.1 Evolving architecture
6.1.3.2 Architecture planning
6.1.3.3 Architecture verification
6.1.4 Topics related to detailed design [Go to Page]
6.1.4.1 Activities of detailed design
6.1.4.2 Emergent design
6.1.4.3 Documentation of detailed design
6.1.5 Topics related to implementation and unit verification
6.1.6 Topics related to integration and integration testing
6.1.7 Topics related to software system testing [Go to Page]
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
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
6.1.9 Topics related to configuration management and change management [Go to Page]
6.1.9.1 Software configuration identification
6.1.9.2 Agile’s impact on change control
6.1.10 Objective evidence for activities defined in IEC 62304 [Go to Page]
Table 1—Examples of objective evidence
6.2 Using agile practices for regulatory compliance [Go to Page]
6.2.1 Product backlog, backlog Refinement, and “Definition of Ready”
6.2.2 Sprint backlog
6.2.3 ITERATIONS and increments
6.2.4 “Definition of Done”
6.2.5 iteration review
6.2.6 Product owner role
6.2.7 Scrum master role
6.2.8 Development team role
6.2.9 Continuous integration
6.2.10 Pairing
6.2.11 Test driven development
6.2.12 “Stop the line”
6.2.13 retrospectives/reflections
6.2.14 Collective ownership
6.2.15 Coding standards
6.3 Addressing other regulatory requirements in an agile way [Go to Page]
6.3.1 Topics related to design validation [Go to Page]
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
6.3.1.3 Demo as a design validation activity
6.3.1.4 Design validation testing in the agile model
6.3.1.5 Aligning incremental design validation with regulatory requirements
6.3.2 Topics related to risk management (safety) [Go to Page]
Figure 17—Risk management activities in an AGILE model
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
6.3.3 Topics related to cybersecurity [Go to Page]
Figure 18—Cybersecurity activities in an AGILE model
6.3.3.1 Cybersecurity as part of backlog management
6.3.3.2 Cybersecurity as part of backlog execution
6.3.3.3 Integrating cybersecurity expertise
6.3.4 Topics related to usability [Go to Page]
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
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
Appendix A (informative) Analysis of the value statements from the manifesto for agile software development [Go to Page]
A.1 Individuals and interactions over process and tools
A.2 Working software over comprehensive documentation
A.3 Customer collaboration over contract negotiation
A.4 Responding to change over following a plan
Appendix B (informative) Applying agile development to IEC 62304 – Quick Guide [Go to Page]
B.1 Regulation, Standards and Procedures
B.2 agile Software Development and 62304 [Go to Page]
Figure B.1—Overview of software development processes and activities
Figure B.2—Medical Device Standards and 62304 processes
B.3 agile - 4 layers of abstraction [Go to Page]
B.3.1 Planning for Development for each of the agile Layers [Go to Page]
Figure B.3—62304 Planning activities
B.3.2 The product layer
B.3.3 The Release Layer
B.3.4 The Increment Layer
B.3.5 The story layer
B.4 Software Integration and Integration Testing
B.5 Software System Testing
Appendix C (informative) Quick reference guide [Go to Page]
Table C.2—Index of activities of interest
Bibliography [Go to Page]

About Us / Careers / support@madcad.com / 1.800.798.9296