Keith Collyer & Jordi Manzano

Transcript

1. Dr Keith Collyer Senior Solution Lead, Medical Devices and Electronic Design, IBM Jordi Manzano R&D Deputy Manager, Diagnostic Grifols
2. 2 Being Agile while still being Compliant
3. 3 •Grifols: – Plasma derivatives, in vitro diagnostic products and pharmaceutical products. – €2,600M total turnover (40% US, 40% EU, 20% ROW). – €130M diagnostic division turnover.
4. 4 IBM Rational Solution for Medical Device Development Based on Rational’s proven solutions for systems & software engineering • Meet regulatory compliance with enhanced automation and reporting to simplify audits, reputation loss, lawsuits and company collapse • Manage product complexity by integrate requirements and quality management • Reduce time-to-market and cost by early defect detection and removal IBM Rational Solution for Medical Devices extends the core Rational solution with integrated products, practices and guidance for:  Product compliance:  Medical device development specific processes (e.g. IEC 62304)  Traceability in medical device development  Design Control and Intended Use Validation  Evidence of regulatory compliance  Incremental migration to Agile work practices IBM Rational Solution for Systems and Software Engineering Open Lifecycle Integration Best Practices and Services Architecture, Design and Development Quality Requirements Planning, Change/ Configuration Management Visualize, Analyze, and Organize
5. 5 Topics: •Regulatory principles, activities and deliverables. •Waterfall development – Agile development. •Agile vs Regulatory principles: where they reinforce each other, and (seem) to collide. •Mapping of regulated activities in an Agile development process. •Making both worlds work together: conflicts and trade-offs. •Where tools can help – use of DOORS to handle incremental compliant developments.
6. 6 Regulatory principles, activities and deliverables •Established processes with planned activities as a means for ensuring safe and effective software. •Availability of objective evidence that the process was followed for a certain product (documents). •Descriptive over prescriptive approaches: more flexibility for compliance but tougher audits.
7. 7 Overview of IEC 62304 Source: European Medical Device & Technology, June 2010 • Quality management system • RISK MANAGEMENT • Software safety classification • Software development PROCESS – Software development planning – Software requirements analysis – Software ARCHITECTURAL design – Software detailed design – SOFTWARE UNIT implementation and verification – Software integration and integration testing – SOFTWARE SYSTEM testing – Software release • Software maintenance PROCESS • Software RISK MANAGEMENT PROCESS • Software configuration management PROCESS • Software problem resolution PROCESS • Documentation Requirements Gap Analysis 7
8. 8 Waterfall development – the “traditional” approach •Works well in contractual environments •Developers have “complete” knowledge •In practice, teams always iterate User Requirements System Requirements Architectural Design Component Development Integration & Verification Installation & Validation
9. 9 Agile development – Example: Scrum •Recognizes that requirements will change •Needs significant discipline to use – it is not hacking!
10. 10 V-model •Often interpreted as an extended waterfall •Better interpreted as showing time-independent relationships between artifacts •Consistent with both waterfall and agile User Requirements System Requirements Architectural Design Component Development Components Assemblies Completed System Operational Capability Component Tests Integration Tests System Tests Acceptance Tests
11. 11 Agile vs Regulatory principles: where they reinforce each other, where they (seem) to collide •Skilled people with means to work well together just makes a robust process even more robust . •Teams continuously ask themselves how processes are working Established processes “Individuals and interactions over processes and tools”
12. 12 Agile vs Regulatory principles: where they reinforce each other, where they (seem) to collide Objective evidence “Working software over comprehensive documentation” •Shouldn’t working software equal safe and effective software? •Agile principles help challenge documents that do not add value
13. 13 Agile vs Regulatory principles: where they reinforce each other, where they (seem) to collide Design inputs “Customer collaboration over contract negotiation” •Continuous customer involvement ensures that the intended use and user needs are successfully translated into a set of design inputs
14. 14 Agile vs Regulatory principles: where they reinforce each other, where they (seem) to collide Planning “Responding to change over following a plan” •Agile puts tremendous emphasis on planning. •Regulators expect plans to be updated as development evolves
15. 15 Making both worlds work together: conflicts and trade-offs •Conflicts: – Complete design input vs real life and changes vs emergent definition. – Formal sign-offs vs informal documents vs no documents. – Finish to start relationships vs parallelism. •Trade-offs: – Enough design input instead of complete design input. – Finish to finish relationships instead of finish to start ones. – Synchronization points. •Guidance from AAMI Technical Imp Report 45 on applying agile to IEC 62304
16. 16 Develop documents incrementally •Regulators need to see documents – How to create these in an agile environment •The V-model gives the clue – Populate the artifacts as material is developed – End up with complete documents that can be audited – TIR 45 gives directions: • No need to finish a document before moving on • At the end that all documents must be finals and synchronized
18. 18 Hardening Sprints •Need to take stock to check regulatory compliance •Hardening sprints used to do that •May be one or more hardening sprints to each release
19. 19 Synchronizing agile software development and hardware development •Issues: – Agile develops in time-boxed sprints – Hardware developers need to know timing of other teams •Grifols approach: – Planning intermediate software releases that are linked to hardware milestones – Hardening sprint also prevents accumulation of regulatory or technical debt – synchronization of design inputs (e.g. req document) with design outputs and sign offs
20. 20 Where tools can help – use of DOORS to handle incremental compliant developments •DOORS is being used in Grifols to handle: – Software requirements. – Architectural design. – Detailed design. – List of source files that implement the detailed design. – System test procedures and records. – Traceability information between all the above. •Information is created incrementally. •At synchronization points – Modules are baselined and exported into documents then put in the validated document management system for formal review and approval.