Leveraging Reusability and Traceability in Medical Device Development
•Als PPT, PDF herunterladen•
1 gefällt mir•724 views
Learn best practices for creating verifiable, traceable requirements. The presentation also includes information about how Seapine's TestTrack supports streamlining better processes, data capture, reusability, and traceability in the requirements phase and a Q&A session.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Leveraging Reusability and Traceability in Medical Device Development
Ähnlich wie Leveraging Reusability and Traceability in Medical Device Development (20)
Mehr von Seapine Software
Mehr von Seapine Software (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Leveraging Reusability and Traceability in Medical Device Development
- 1. Leveraging Reusability & Traceability in Product Development David A. Vogel, Ph.D. – President - Intertech Engineering Associates, Inc. Larry Nicholson – Life Sciences Business Development – Seapine Software, Inc. sponsored by www.inea.com info@inea.com Boston: 100 Lowder Brook Drive, Suite 2500, Westwood, MA 02090 T: (781)801-1100 1 © 2012 – Intertech Engineering Associates, Inc. Chicago: 475 Half Day Road, Suite 110, Lincolnshire, IL 60069 T: (773)915-2290
- 2. More detail … Much of the content of this webinar is covered in more detail in this text book. For more information, see www.validationtext.com 2 © 2012 – Intertech Engineering Associates, Inc.
- 3. Setting Expectations • This webinar will: – Introduce you to some basic concepts – Point out examples of benefits of traceability – Stimulate thinking about how more focus on traceability would benefit your organization • Unfortunately, too little time to dig into specific solutions • Getting traceability right in your organization will take time 3 © 2012 – Intertech Engineering Associates, Inc.
- 4. Traceability Mentioned in GPSV* • General Principles of Software Validation, FDA Guidance Document • Regulatory position … a soft “requirement” • Little guidance on how or why Reproduced with permission, from Medical Device Software Verification, Validation, 4 © 2012 – Intertech Engineering Associates, Inc. and Compliance by David A. Vogel, Ph.D. © 2011 Artech House, Inc., Norwood, MA
- 5. Benefits of Traceability • Project Metrics • Are we designing the device right? (verification) – Are all requirements implemented? – Are all requirements verified? – Are we meeting requirements of standards? • Are we designing the right device? (validation) – Are we meeting “stakeholder” needs? • Clinical, Marketing, Legal, Service, Manufacturing, Risk Control, Usability • … and, yes, Regulatory 5 © 2012 – Intertech Engineering Associates, Inc.
- 6. Sample Benefits - I A SOFTWARE REQUIREMENTS B DESIGN REQUIREMENT Reproduced with permission, from Medical Device Software Verification, Validation, 6 © 2012 – Intertech Engineering Associates, Inc. and Compliance by David A. Vogel, Ph.D. © 2011 Artech House, Inc., Norwood, MA
- 7. Sample Benefits - II A SOFTWARE REQUIREMENTS B SYSTEM LEVEL SOFTWARE VERIFICATION TESTS Reproduced with permission, from Medical Device Software Verification, Validation, 7 © 2012 – Intertech Engineering Associates, Inc. and Compliance by David A. Vogel, Ph.D. © 2011 Artech House, Inc., Norwood, MA
- 8. TRACE ORGANIZATION 8 © 2012 – Intertech Engineering Associates, Inc.
- 9. Top Down • Note top level design input sources • Logical, predictable Reproduced with permission, from Medical Device Software Verification, Validation, 9 © 2012 – Intertech Engineering Associates, Inc. and Compliance by David A. Vogel, Ph.D. © 2011 Artech House, Inc., Norwood, MA
- 10. Modified Top Down • Design inputs often have “requirements” from variety of levels • Efficiencies from reuse Reproduced with permission, from Medical Device Software Verification, Validation, 10 © 2012 – Intertech Engineering Associates, Inc. and Compliance by David A. Vogel, Ph.D. © 2011 Artech House, Inc., Norwood, MA
- 11. Traceability/Reusability Ties Quality System to Project Specific Artifacts Difficult to Change FDA – QSR SW Design & Dev. Policies 820.30 Quality System General (QSM) FDA – 62304 – SW G.P.S.V. Lifecycle Guideline Standard Software Software Development Testing Process Process Easier to Change Software System Level Project Specific Requirements Software Testing Software Integration Design Level Software Specifications Testing Software Unit Level Design Software Specifications Testing Software Software V & V Development Plan Plan 11 © 2012 – Intertech Engineering Associates, Inc.
- 12. Decomposition of DHF Artifacts System Level Software Test Plan System Level System Level Test System Level Test Plan Master Plan Master uP - Test Plan Safety uP - Functional GUI uP - Functional 12 © 2012 – Intertech Engineering Associates, Inc.
- 13. Is There Such a Thing As Too Much? • Yes • Ask yourself: – Why do I need this trace? – What benefit do we get from it? • Document these answers • If no benefit, why do it? (tracing can get “addictive”) 13 © 2012 – Intertech Engineering Associates, Inc.
- 14. TRACE MORPHOLOGIES 14 © 2012 – Intertech Engineering Associates, Inc.
- 15. Morphology Do’s and Don’ts Reproduced with permission, from Medical Device Software Verification, Validation, 15 © 2012 – Intertech Engineering Associates, Inc. and Compliance by David A. Vogel, Ph.D. © 2011 Artech House, Inc., Norwood, MA
- 16. METRICS AND TRACEABILITY 16 © 2012 – Intertech Engineering Associates, Inc.
- 17. Properly Designed Traces Allow Some Metrics • How many requirements have been designed? • How many requirements have verification tests written? • How many tests have unresolved defects written against them? • What is the average fan-out of requirements to design elements … requirements to verification tests? 17 © 2012 – Intertech Engineering Associates, Inc.
- 18. Future Considerations • Analyze current processes and tools • Consider Intertech for helping to develop and improve processes and methods • Consider Seapine Software for an integrated framework to support good processes and product development artifacts 18 © 2012 – Intertech Engineering Associates, Inc.
- 19. Questions & Answers Please submit your questions via the Q&A panel at the bottom right of your screen sponsored by www.inea.com info@inea.com Boston: 100 Lowder Brook Drive, Suite 2500, Westwood, MA 02090 T: (781)801-1100 19 © 2012 – Intertech Engineering Associates, Inc. Chicago: 475 Half Day Road, Suite 110, Lincolnshire, IL 60069 T: (773)915-2290
Hinweis der Redaktion
- Note the 2 nd two bullets are the V & V questions we ask ourselves.
- Quickly A: requirement with no corresponding design, i.e. unfulfilled B: un-required design element how does that happen? un-necessary design (gold plating, etc.) more often, inadequate resolution of requirements
- Quickly A: requirement with no corresponding system level software test (untested) B: test with no corresponding requirement how does that happen? inadequate resolution of requirements – requirements end up being documented in the tests - tests usually constructed from observed behavior (useless)
- Top level arrowheads on wrong end. Two way arrows wrong .. A mess.
- Note only software dealt with here. Similar traces for hardware, mechanical, etc. Reuse: If company makes many similar products, many of top level Design Inputs will be very similar. Applicable Standards may be same or slightly different. Imagine Project B copies top 2 levels (inputs, system requirements, and software requirements) from Project A. As differences in needs are identified, they can be traced to system requirement changes necessitated by the DI change because trace is in place. Similarly, changes in system requirement traces to needed changes in software requirements, etc.
- Note – simplified situation for PPT purposes Quality System in top un-shaded area. Applies to all projects/devices, etc. High level, generic. Policy (top red) calls out the regulations, standards (general and device specific), and guidances with which the company complies. Each reg/std/guidance traces to specific element that belong at the Process level (e.g. the existence of plans, reviews, verification, validation, etc.) Note trace from SW Dev Process to SDP and from SW Test Process to SVVP The contents of project artifacts or specifics of activities that are spelled out in a guidance or standard are traced from that source doc to the project doc. In this case, note that 62304 traces to SDP and SVVP. It’s important to make these trace links obvious, visible, reportable, usable. Document users won’t comply with trace implications if they have to work too hard for them. Tools are needed so users don’t have to work so hard for creating and using the traces. So far, pretty generic and reusable device to device. When we get to green boxes the information gets more specific. Note that each of these could refer to sub-hierarchies. For instance, System level requirements/testing could be broken down as follows.
- Depending on similarity of manufacturer devices, much can be reused project to project. Similar diagram could (should) apply to software requirements. Trace the requirements from 62304 for System Level Software Testing down as far as appropriate in the hierarchy. This takes a fair amount of design and planning, but worth the effort. There are no “set” ways to do it. The style and design depends on the manufacturer’s needs, tastes, and need to control. This kind of traceability not only applies to V&V artifacts, but also to SDP’s, SVVP’s, CMP’s, Change Management, Defect Management, etc.
- Documents, in general should fan-out, i.e. one to many. Seldom many to one. If too much one to one, either not enough detail in child document, or too much detail in parent. Many to many may seem like it’s helpful, but in general is unusable.
- Transition to Seapine Software with a high-level demonstration to some of the key points we spoke of earlier.