being agile while still being compliant: a practical approach · being agile while still being...
TRANSCRIPT
1
Being Agile while Still Being Compliant: A Practical Approach
Jordi Manzano, Software QA Manager and R&D Deputy Manager, Diagnostic Grifols, S.A.
Dr. Keith Collyer, Senior Solution Manager, Electronics and Medical Devices Industry Solutions, IBM
Copyright © 2013 by IBM UK Ltd. and Diagnostic Grifols, S.A. Published and used by INCOSE UK Ltd and INCOSE with permission.
2
•Grifols:
– Plasma derivatives, in vitro diagnostic products and pharmaceutical products.
– €2,600M total turnover (40% US, 40% EU, 20% ROW).
– €130M diagnostic division turnover.
3
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
4
Topics:
•Regulatory principles, activities and deliverables.
•Waterfall development – Agile development.
•Agile vs Regulatory principles: where they reinforce each other, where they (seem) to
collide.
•Making both worlds work together: conflicts and trade-offs.
•Grifols’ agile cycle.
•Where tools can help – use of DOORS to handle incremental compliant
developments.
5
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.
6
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
6
7
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
8
Agile development – Example: Scrum
•Recognizes that requirements will change
•Needs significant discipline to use – it is not hacking!
9
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
10
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”
11
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.
12
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.
13
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.
14
Making both worlds work together: conflicts and trade-offs
Conflicts Trade-offs
Design Inputs Design Outputs
Design Inputs
Design Outputs
•Guidance from AAMI TIR 45 on applying agile in the development of medical device software.
15
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
17
Sprint 0
•Plan field and internal releases
(synchronization with hardware).
•SRS: Comprehensive, not complete.
•Architectural & environment main decisions.
•Formal approval.
18
Releases
•Planning – building – hardening.
•Off - sprint tasks:
– Backlog “grooming”.
– Formal test procedures.
19
Sprints
•Definition of done (Story):
– SRS complete (DOORS).
– SDS complete (DOORS).
– Test design complete (DOORS)
– Coding rules & UT/IT passed (Jenkins).
– No relevant defects unresolved.
20
Intermediate hardening sprints
•If release longer than 3-4 sprints.
•Need to take stock to and prevent accumulation
of regulatory and/or technical debt.
•Synchronization of design inputs (e.g. SRS
document) with design outputs and formal sign -
offs.
21
Final hardening sprint(s)
•Complete all regulatory tasks.
•Ensure no unacceptable unresolved defects
remain.
22
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
23
Where tools can help – use of DOORS to handle incremental compliant
developments
•DOORS is being used in Grifols to handle:
– Risk management.
– Software requirements.
– Architectural design.
– Detailed design.
– List of source files that implement the detailed design.
– System test procedures, records and summary reports.
– Traceability information between all the above.
•Information is created incrementally.
•At synchronization points (hardening sprints), modules are baselined and exported
into documents that are introduced in the validated document management system for
formal review and approval.
24
Summary:
•There are certainly challenges using Agile in regulated environments.
•Regulatory and Agile principles reinforce themselves in some areas, but there are
conflicts that need trade-offs to be solved.
•AAMI TIR 45 gives important directions on the medical devices field on how these
trade-offs can be made acceptable from a regulatory standpoint.
•It’s important to map regulated activities into the actual Agile cycle that is followed:
– This map should be formalized in a procedure.
– When regulatory submissions / audits take place, this map will help auditors understand
how regulatory requirements are met throughout the (Agile) development cycle.
•Tools like DOORS are essential to support the development cycle and be able to
build the formal documents that are needed to show compliance with regulations.