Agile Practices Proven in Highly Regulated Environments by Craig Langenfeld
•Als PPTX, PDF herunterladen•
16 gefällt mir•5,270 views
Many organisations operatin in highly regulated environments, such as healthcare, have concluded that in order to achieve the next level of product quality and safety improvements, not to mention enhanced competitiveness, adoption of a more Agile approach is required. In this presentation, you will learn how the Agile software development approach for high assurance systems addresses many of the challenges found in many highly regulated enterprise environments. Presented by Craig Langenfeld
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (10)
Ähnlich wie Agile Practices Proven in Highly Regulated Environments by Craig Langenfeld
Ähnlich wie Agile Practices Proven in Highly Regulated Environments by Craig Langenfeld (20)
Mehr von Agile Software Community of India
Mehr von Agile Software Community of India (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Agile Practices Proven in Highly Regulated Environments by Craig Langenfeld
- 1. Agile Practices Proven in High Assurance and Highly Regulated Environments © 2011 Rally Software Development and Leffingwell, LLC.
- 2. Define high assurance? “High assurance software systems are unique because they must satisfy basic functional service properties that the system intends to deliver, as well as guarantee desirable system properties such as security, safety, timeliness, and reliability.” © 2011 Rally Software Development and Leffingwell, LLC. 2
- 3. © 2011 Rally Software Development and Leffingwell, LLC. 3
- 4. Regulating bodies… FDA – Federal Drug Administration ISO – International Standards European Union MEDDEV Drug Controller General of India – Central Drugs Standard Control Organisation (CDSCO – Medical Devices Division Health Canada Ourselves (CMMI) Global Harmonization Task Force – guidance docs IEC, although not a regulation is recognized as a good standard when developing such things as medical devices Software Development and Leffingwell, LLC. © 2011 Rally 4
- 5. © 2011 Rally Software Development and Leffingwell, LLC. 5
- 6. “Although the waterfall model is a useful tool for introducing design controls, its usefulness in practice is limited… for more complex devices, a concurrent engineering model is more representative of the design processes in use in the industry. “ From [FDA CDRH 1997] Design Control Guidance for Medical Device Manufacturers © 2011 Rally Software Development and Leffingwell, LLC. 6
- 7. Surprise? FDA and IEC Guidance does NOT recommend waterfall [FDA CDRH 2002] It is important to note, that neither this document, nor CFR820.30 itself, constrains development to single pass, stage-gated, waterfall activities. From General Principles of Software Validation….. [FDA CDRH 2002]: While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software life cycle. From [FDA CDRH 1997] Design Control Guidance for Medical Device Manufacturers : Although the waterfall model is a useful tool for introducing design controls, its usefulness in practice is limited… for more complex devices, a concurrent engineering model is more representative of the design processes in use in the industry. IEC 62304 medical device standard states: … these activities and tasks may overlap or interact and may be performed iteratively or recursively. It is not the intent to imply that a waterfall model should be used. © 2011 Rally Software Development and Leffingwell, LLC. 7
- 8. Industry myth perpetuated by our own waterfall past? © 2011 Rally Software Development and Leffingwell, LLC. 8
- 9. Software engineering & SDLC Lean / Agile Craig Langenfeld PMP, CSM Regulated craig@rallydev.com environment © 2011 Rally Software Development and Leffingwell, LLC. 9
- 10. Dean Leffingwell © 2011 Rally Software Development and Leffingwell, LLC. 10
- 11. Waterfall Story © 2011 Rally Software Development and Leffingwell, LLC. 11
- 12. © 2011 Rally Software Development and Leffingwell, LLC. 12
- 13. Where are we going? ➵ Agile Proven within High Assurance ➵ Healthcare Example ➵ How? ➵ Agile Framework for High Assurance ➵ High Assurance Requirements Model ➵ Artifact generation ➵ Updated Quality Management Systems © 2011 Rally Software Development and Leffingwell, LLC. 13
- 14. Agile is already in high assurance Abbott Laboratories – – 20 – 30 % fewer defects were found – availability of working software early on was a significant factor – “This experience has convinced us that an agile approach is the approach best suited to development of FDA-regulated devices.” GE Healthcare Goes Agile – Dr. Dobbs article 2010 – “we are making progress and feel that the benefits of our Agile adoption have been worth the effort. Because of this we are rolling out Agile globally within GE Healthcare” AFEI DoD Agile Development Conference – “Agile Methods are in widespread use by the U.S. DoD, Prior … the commercial industry and DoD contractors believed the U.S. DoD was not committed to Agile , an enormously incorrect assumption…” Sources: Abbott Labs whitepaper: http://www.computer.org/portal/web/csdl/doi/10.1109/AGILE.2009.50. AAMI report: See http://www.aami.org/applications/search/details.cfm?WebID=P1541_D6110 DoD Association for Enterprise Information (AFEI): See http://www.afei.org/Pages/default.aspx. (See http://davidfrico.com/afei-2010.doc) © 2011 Rally Software Development and Leffingwell, LLC. 14
- 15. Whitepapers and other references Association for Advancement Medical Instrumentation – TIR - Guidance on the use of AGILE practices in the development of medical device software – “Since AGILE is a highly INCREMENTAL/EVOLUTIONARY approach, it can therefore be mistakenly assumed that AGILE is incompatible with the expectations for a medical device software process. “ Blogs… – Scott Ambler – Agile Scaling Model – Tom Grant – Forrester Analyst – Dean Leffingwell – Scaling Software Agility Blog © 2011 Rally Software Development and Leffingwell, LLC. 15
- 16. Agile gets results “We experienced a 20-50% increase in productivity.” − BMC Case Study Productivity “ makes the work more enjoyable, helps us work together, and is empowering” 37-50% faster to − Medtronic market Quality − QSM research Time to Morale Market © 2011 Rally Software Development and Leffingwell, LLC. 16
- 17. Agile drives quality, safety, efficacy …fewer defects were found − Abbott Labs Collective Coding Ownership Standards Test-Driven Development Pair Automated Programming Testing Quality Simple Continuous Design Refactoring Integration User Stories … of 131 respondents, 88% said quality was better or significantly better Helps us find bugs earlier − Shine Technology Survey − Medtronic © 2011 Rally Software Development and Leffingwell, LLC. 17
- 18. AN AGILE, HIGH ASSURANCE LIFECYCLE FRAMEWORK © 2011 Rally Software Development and Leffingwell, LLC. 18
- 19. But high assurance development has additional requirements Medical device exemplar: US FDA mandates Software Verification and Validation User Review Needs Design Input Design Process Design Verification Output Medical device Validation Source: FDA CDRH 1997 Design Control Guidance for Medical Device Manufacturers © 2011 Rally Software Development and Leffingwell, LLC.
- 20. So we have additional mandates Code of Federal Regulations CFR 21 Part 830, Subpart C Design Controls mandates device design verification and validation. Verification Validation Provides objective evidence that the Confirmation …… that software design outputs of a particular phase specifications conform to user needs of the software development life cycle and intended uses, and that the meet all of the specified requirements particular requirements implemented for that phase. through software can be consistently fulfilled….Since software is usually part of a larger hardware system, the validation … includes evidence that all software requirements have been You built it implemented correctly and completely right and are traceable to system requirements. Sources: Regulation: Code of Federal Regulations 21 Part 830, Subpart C Design Controls Guidance: General Principles of Software Validation You built © 2011 Rally Software Development and Leffingwell, LLC. the right 20
- 21. And Code of Federal Regulations CFR 21 Part 830, Subpart C Design Controls mandates a requirements specification. Requirements Specification Traceability A documented software requirements FDA guidelines describe traceability and a specification (SRS) provides a baseline for primary mechanism to assure that both validation and verification. The verification and validation are complete software validation process cannot be and consistent. completed without an established software Traceability. The degree to which a requirements specification relationship can be established between (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) two or more products of the development and (g process, especially products having a predecessor-successor or master- subordinate relationship to one another; e.g., the degree to which the requirements and design of a given software component match [IEEE] Sources: Regulation: Code of Federal Regulations 21 Part 830, Subpart C Design Controls Guidance: General Principles of Software Validation © 2011 Rally Software Development and Leffingwell, LLC. 21
- 22. ITERATION MECHANICS Daily Backlog Standup Grooming Iteration Define Iteration Planning Demo, Review & Build Retrospective Verify Product Iteration Product Backlog Backlog Increment © 2011 Rally Software Development and Leffingwell, LLC.
- 23. PROJECT AGILE LIFECYCLE System Increment Planning, Analysis , Architecture, QM Design S Transfer Project Verification Verification Verification Validation Inception Iteration Iteration Iteration Iteration N Production Code Set up Project Infrastructure Verification and Validation activities and artifacts driven by QMS © 2011 Rally Software Development and Leffingwell, LLC.
- 24. High Assurance Scaled Agile Framework
- 25. The User Story Acceptance Definition of Criteria Done As a <role> I can <activity> So that <business value> As an EPAT (Extracorporeal Pulse Activation Technology) technician, (<role>) I can adjust the energy delivered (<what I do with the system>) in increments so as to deliver higher or lower energy pulses to the patient’s treatment area (<value the patient receives from my action>). © 2011 Rally Software Development and Leffingwell, LLC.
- 26. Traceability from User Story to Code and Story Acceptance Test Software Implemented by User Story Code Requirements 1 1..* Specification 1 1 Verified by Verified by 1..* 1..* Unit Test Story Acceptance Test © 2011 Rally Software Development and Leffingwell, LLC.
- 27. Validating Product Claims Product Requirements Pulse amplitude is adjustable Feature from 1-5 bar Document Traced to As an operator, I can adjust the pulse As an operator, I always amplitude in .1 bar increments so as to be see the current setting able to make small changes to change on the display in .1 bar energy delivered to patient area increments, so I can be confident I’m delivering the right energy Software Requirements As an operator, rotating the energy knob past Specification the point where the system is delivering 5 bar will have no further effect User User User Story Story Story © 2011 Rally Software Development and Leffingwell, LLC.
- 28. High Assurance Agile Backlog Model Source: Leffingwell. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley 2011. © 2011 Rally Software Development and Leffingwell, LLC. © 2011 Leffingwell, LLC.
- 29. Validating Features and System Qualities © 2011 Rally Software Development and Leffingwell, LLC. 29
- 30. Agile and Quality Management Systems (QMS) Continuous improvement or (re-)write from scratch Establish cross-functionalQMSscrum team Run releases and sprints to refine / establish QMS Design Controls needs to provide flexibility Software Development Life Cycle (SDLC), Tools, etc. should be specified in the Design and Development Plan (DDP), not in the QMS © 2011 Rally Software Development and Leffingwell, LLC. 30
- 31. Validation Sprint Activities © 2011 Rally Software Development and Leffingwell, LLC. 31
- 32. Quality Management Strategy Matt Anderson Director Program Management March 10, 2012
- 33. MethodQ/SLIM Overview Initial “Design Input” Signature Release Plan • Roadmap • User Stories/Capabilities (Epics) •Acceptance Criteria Tasks to update for each User Story Iterations • Solution Level Requirements • Design artifacts Final “Design Input” Signature • Solution Level Requirement Document(s) Final “Design Output” Signature Release •Asset design artifacts, code, traceability © 2011 Rally Software Development and Leffingwell, LLC.
- 34. Change Record Management Release CR Initial “Design Input” Signature • Roadmap Capability CR Final “Design Input” Signature •Current Solution Level Requirements Release CR Final “Design Output” Signature •Solution Level Test Scenarios • Test Evidence Release • Solution Level Technical Artifacts © 2011 Rally Software Development and Leffingwell, LLC.
- 35. Change Record Management Release CR Initial “Design Input” Signature •User Stories • Acceptance Criteria • Initial Visual Design Capability CR Final “Design Input” Signature •Updated Solution Level Requirements • Visual Design Final “Design Output” Signature • Test Scenarios • Test Evidence Release CR • Code/Code Review • Technical Artifacts as needed Release © 2011 Rally Software Development and Leffingwell, LLC.
- 36. Parent/Child Relationships Release CR Capability CR Capability CR Capability CR Capability CR Capability CR Capabilities cannot span releases, but can span iterations CR can be both a Child and a Parent Each CR must have completed Design Input and Output – Initial Design Input for Child can be covered by the Parent © 2011 Rally Software Development and Leffingwell, LLC.
- 37. Agile extremism does not help (working software over documentation) © 2011 Rally Software Development and Leffingwell, LLC. 37
- 38. Agile and most regulating bodies are not at odds © 2011 Rally Software Development and Leffingwell, LLC. 38
- 39. Satisfy compliance while preserving Agility. © 2011 Rally Software Development and Leffingwell, LLC.
- 40. Implement the appropriate degree of rigor © 2011 Rally Software Development and Leffingwell, LLC.
- 41. © 2011 Rally Software Development and Leffingwell, LLC. 41
- 42. Agile – Perfect for High Assurance “Agile isn’t just good for High Assurance development – it’s better than traditional methods.” - Tom Grant, Forrester Group © 2011 Rally Software Development and Leffingwell, LLC.
- 43. Live long and prosper! Craig Langenfeld craig@rallydev.com cameo by Matt Anderson © 2011 Rally Software Development and Leffingwell, LLC. 43
Hinweis der Redaktion
- Examples of high assurance software systems include command and control systems, nuclear power plants, electronic banking, aerospace systems, automated manufacturing and medical systems (examples in India)HealthcareFDA 21 CFR 820.30 Sub-clause 4.4 of ISO 9001IEC 62304
- Regulation of medical devices is intended to protect the health and safety of patients, users, and third persons, by attempting to ensure that marketed products are safe and effective. Different countries and regions have different agencies that regulate medical devices. While these different agencies have many different specific regulations, they share much in common and all have similar goals and guiding principles. This regulatory perspective section concentrates on regulation for quality system requirements specific to design control.Sub-clauses of ISO 13485 clause 7.3 (Design and Development) have the same overall objectives of the United States FDA regulation related to design controls. For some time the FDA, Health Canada, the EU, Japan, and Australia have been working within the Global Harmonization Task Force (GHTF) to develop guidance documents that reflect international agreement on quality management system essential principles and requirements. Information on guidance documents from the various GHTF study groups can be found at www.GHTF.org.
- Who in this room is from a regulated industry?If you are in a regulated environment who is practicing Agile?Who has read their governing regulation or associated guidance in the past 6 months?
- As it relates to FDA 21 CFR 820.30 and Sub-clause 4.4 of ISO 9001
- Ask Micheal’s opinion on these points to offer additional color to the commentary
- With respect to this one industry, and with respect to these specific guidelines, any notion that we are mandated to apply a single-pass, waterfall model to software development is an industry myth, one which has likely been perpetuated by our own waterfall past (“we’ve always done it this way”) and our existing quality management systems, and not because “the regulations make us do it”I’m asking you to do two things with our time here today…ParticipateChallenge status quo by reading and re-interpreting the standards, regulations and guidelines that you follow today.
- Case studies, blogs, papers, and a cameo appearanceAgile Framework for Regulated EnvironmentsRequirements Model Artifacts and activities (output)QMS changes
- Abbott Laboratories (molecular diagnostics division)– presented at the Agile Conference 2009 -> dates back to 2004“On the Agile project, fewer defects were found…Estimated project duration and team size decrease of 20 – 30%“This experience has convinced us that Agile approach is is the approach best suited for the development of FDA Regulated devicesImaging Solutions division 375+ engineers globally, 18 products, support clinician productivityChallenge: “…the problem with this approach is the ability to incorporate customer feedback early in the cycle and any significant changes could require complete changes in design that cause lengthy delays”Result: “we are making progress and feel that the benefits of our Agile adoption have been worth the effort. Because of this we are rolling out Agile globally within GE Healthcare” Further evidence would be the US dept of defense. Highly secure highly thought of as “un Agile”
- Guidance in the use of Agile Practices in the Development of Medical Device Software“Since agile is a highly incremental/evolutionary approach, it can therefore be mistakenly assumed that agile is incompatible with the expectations for a medical device software process. “
- Why is Agile for High Assurance getting so much attention in the past couple of years? For the same reason that Agile got everyone’s attention at the end of the last century. Because it works. And most importantly it produces quality products.
- And if we look at the practices that XP alone provides us with almost every one of them provides us with a higher degree of quality, safety, and efficacy.
- While regulatory agencies do not prohibit or encourage the use of any specific software development methodology, but they do indicate some expected characteristics of the selected software lifecycle and development. In particular, they emphasize that software verification and VALIDATION should be conducted throughout the software development lifecycleFrom the intended use point of view, agile’s emphasis on customer collaboration aligns very well with the regulatory perspective's emphasis on software VALIDATION.
- Acceptance criteriaDefine | Build | VerifyDefinition of doneInput -> Traceability -> Output
- Verification Iteration Define | Build | VerifyValidate and Review
- Diff
- Suggest Michael offer an Omnyx user story here to replace EPAT example.
- A foundational element of regulations and standards for medical device software is that a quality management system must be “established”, where “established” means that the quality management system is defined, it is documented, it is understood by those who use it, and objective evidence is produced to demonstrate it has been properly used. A quality management system is documented within the organization’s common process documentation (such as procedures, protocols, and work instructions) as well as specific documentation unique to a project (such as in project plans and reports).Changes that agile brings to a robust and effective quality management system should not diminish or give the perception of diminishing the effectiveness of the established system. Changes should be made within the requirements of regulations, regulatory guidance, and standards, and therefore not raise undue concern among regulators.
- Documentation (evidence) is necessary to demonstrate compliance to regulations, to evaluate software for regulatory approval, to facilitate the investigation into software problems, and to evaluate software for those devices requiring regulatory approval, e.g., approval, clearance, licensing, registration, self-certification, etc.
- Agile extremism does not help (working software over documentation)
- Agile and regulating bodies are not at odds (waterfall is not mandated by regulations)Agile and Regulations both strive to ensure high product quality
- Internal interpretation of regulations often more constrainingRegulatory requirements and guidance documents recognize that different kinds of medical device software require different development processes, practices, and documentation. For example, the FDA’s “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” describes "Level of Concern", recommending that the extent of documentation to be submitted should be proportional to the Level of Concern associated with the device. The FDA’s guidance document “General Principles of Software Validation” recommends that the specific approach, techniques, and level of effort applied to software development be based on the intended use and the safety risk associated with the software. IEC 62304 describes "Software Safety Classification" and provides guidance on the development processes to be applied depending on the classification. All of these are recommending that the risk associated with a software product should be assessed in order to establish a development process with the appropriate level of rigor and robustness.
- Urban Myth: Agile is not for high assuranceHigh assurance - late adoptersEarly adopters – no wayMajority adopters – stating to take noticeLate adopters – want to get on band wagonWant to reap agile benefitsHigh assurance competitors are now doing agileFaster time to marketIncreased productivityHigher qualityHigher customer satisfactionWith respect to this one industry, and with respect to these specific guidelines, any notion that we are mandated to apply a single-pass, waterfall model to software development is an industry myth, one which has likely been perpetuated by our own waterfall past (“we’ve always done it this way”) and our existing quality management systems, and not because “the regulations make us do it”I feel that management is in some ways very attached to Waterfall because it fits so nicely with phased-gated development with doing requirements, then having a stage gated requirements review, design phased, with Geoffrey Moore: “Waterfall put a man on the moon but it’s inadequate for today’s hyper connected and competitive environment.”