Agile Development in a Regulated Environment
-
Upload
techwellpresentations -
Category
Technology
-
view
88 -
download
4
description
Transcript of Agile Development in a Regulated Environment
![Page 1: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/1.jpg)
AT3 Session 6/6/2013 10:15 AM
"Agile Development in a Regulated Environment"
Presented by:
Chris Ampenberger PHT Corporation
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com
![Page 2: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/2.jpg)
Chris Ampenberger PHT Corporation
Chris Ampenberger is a development manager at PHT Corporation, the leading provider of innovative systems used to collect patient-driven eData for clinical research. Chris manages three agile development teams which maintain PHT’s back-end systems that receive and process all acquired data. He has several years of experience managing software development teams in a number of industries. Chris started practicing agile seven years ago and managed its complete implementations in two companies. He has brought PHT’s Scrum implementation to a new level by: shortening sprints; measuring team and stakeholder satisfaction; and focusing on automating unit tests, functional testing, and release documentation.
![Page 3: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/3.jpg)
Agile Development in a Regulated EnvironmentChris Ampenberger,
Directory Engineer, PHT
Trust your Patient-Driven eData with PHT
y g ,
June 2013
Discussion Topics
1 Background
22 Say what you do and do as you say!
3 Audit Readiness is a Deliverable
4 Practice, practice, practice
22
5 Contact Info
![Page 4: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/4.jpg)
Background
• About Me
― Chris Ampenberger
― ~27 years in IT
― Working with Agile/Scrum since 2006
― Since 2011 with PHT Corporation
• About PHT
― Develops trials to capture patient reported outcomes (ePRO) through mobile devices
― Class 1 medical device manufacturer
― Over 540 trials in 14 therapeutic areas
3
p
― >70,000 mobile devices
― Fulfillment in 68 countries, supporting 97 languages
Say what you do and do as you say!
44
![Page 5: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/5.jpg)
US Regulations & Guidance
• 21CFR Part11 Electronic Records and Electronic Signatures Rule (Mar 1997)
• FDA Guidance for Industry: General Principles of Software Validation (Jan 2002)2002)
• FDA Guidance for Industry: Computerized Systems Used in Clinical Investigations (May 2007)
• FDA Guidance for Industry: Patient-Reported Outcome Measures: Use in Medical Product Development to Support Labeling Claims (Dec 2009)
• FDA Guidance for Industry: Electronic Source Documentation in Clinical Investigations (Dec 2010)
5
Investigations (Dec 2010)
• 21CFR880 Medical Devices; Medical Device Data Systems (Feb 2011)
• FDA Guidance for Industry: Mobile Medical Applications (DRAFT Jul 2011)
European Regulations & Guidance
• DIRECTIVE 1999/93/EC … on a Community framework for electronic signatures (Dec 1999)
• Reflection paper on expectations for electronic source data and data transcribed to electronic data collection tools in clinical trials (Feb 2011)
• Annex 11: Computerized Systems (June 2011)
• Reflection paper on the Use of Interactive Response Technologies (Interactive Voice/Web Response Systems) in Clinical Trials (DRAFT Aug 2011
6
![Page 6: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/6.jpg)
Regulatory Environment
• General distrust of electronic systems
• Regulators lag far behind technology
• US: Field inspectors are not always familiar with software• US: Field inspectors are not always familiar with software
• EU: EC’s and GCP Inspectors may include one or more software experts on the team
7
Consequences:
Plan
Our processes and standard operating procedures used to look like the following:
Plan
Execute
D li
=
88
Deliver
![Page 7: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/7.jpg)
Process Evolution
ExecuteDeliver
Now they look more like the following:
Plan
AnalyzeAdjust
― Documented in a framework of policies, standard operating procedures work instructions etc
99
http://en.wikipedia.org/wiki/File:Scrum_process.svg
procedures, work instructions etc
― The framework undergoes periodic reviews to stay up to date
― Execution is documented in a paper trail that accompanies every release.
Then & Now
Product Requirements Specification ► Epics & User Stories
Software Requirements Specification ► User Stories
Software Design Specification ► Functional Specification Task & Wiki
1.5 year release cycle ► 6 month
Varying length phases ► 2 week sprints
Phases for requirements, design etc ► Weekly grooming
10
![Page 8: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/8.jpg)
Audit Readiness is a Deliverable
• Christmas every year is not a surprise, neither are Audits!
• Plan for it:
― Break it downBreak it down
▸ Every story, every bug
▸ Every sprint
▸ Every release
― Enforce it
▸ Mini audits
11
▸ Checklists
▸ “Nagging” scripts
Invest in Automation
― Use an electronic system to support your SDLC that produces an audit trail and offers an API
― For every piece you have to produce, ask your self:
▸ Is it necessary?
▸ What is the minimum I have to produce?
▸ When is the earliest I can get it done and when is it due?
▸ How can I automate it?
12
![Page 9: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/9.jpg)
Do it the Agile Way
― Start small!
― Pick highest value target first
▸ For example patch paper trail
▸ StudyWorks 4.16.0.2: 7 documents, 2 weeks, 240 person hours
▸ StudyWorks 4.16.0.4: 1 document, 2 days, 32 person hours
― Audit Trail automation and process improvements become part of the backlog
▸ Scrum the Scrum
Learn from audits and incorporate it in the backlog
13
― Learn from audits and incorporate it in the backlog
Where we are today• We use
― Rally▸ User Stories, Defects, Tasks▸ Test Cases, Test Results, Test Sets
― AccuRev with the GitCentricJ ki
• From that we generate― Validation Plan
― Test Plan
― Build Plan― Jenkins― Robot Test Framework― Skytap cloud
― Product Requirements Report
― Functional Specifications Report
― Traceability Matrix
― Unit Test Report
― Code Review Report
1414
― Test Case Results Report
― Test Case Results Review Report
― Defect Summary
![Page 10: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/10.jpg)
Example: Patch Audit Trail
• We needed a report for patches that showed that we follow our procedures
• It needs to contain:
― Plan date
― Planned release date
― Actual release date
― Defects to be fixed
― Plan for defect validation
15
― Plan for regression testing
― Documentation of unit testing
― Documentation of code reviews
― Test results
Example: Patch Audit Trail
• Plan date -> Release.CreationDate
• Planned release date ->Release.ReleaseDate
• Actual release date -> Release.RevisionHistory[].Date
16
![Page 11: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/11.jpg)
Example: Patch Audit Trail
• Defects to be fixed -> Defects per iteration
• Plan for defect validation -> Owner of Tasks with prefix [SQE-EXE]
17
Example: Patch Audit Trail• Plan for regression testing
• -> TestSets per release or iteration
• -> TestCases per TestSet
18
TestSet
![Page 12: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/12.jpg)
Example: Patch Audit Trail
• Documentation of unit testing
• -> Task with prefix [DEV-UT] per defect or story
• -> Owner is engineeer
• -> Description contains result of test, or name of automated test
• -> Test results from Jenkins
19
Example: Patch Audit Trail
• Documentation of code reviews
• - > Record of promotions in AccuRev from the review stream to the integration stream
• -> Contains list of changed files & timestamp
• -> Notes with names of member participating in the code review
20
![Page 13: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/13.jpg)
Example: Patch Audit Trail• Test results
• -> TestSets per release or iteration
• -> most recent TestCaseResult per TestSet with build belonging to release
21
TestSet
Practice, Practice, Practice
• Manager audits scrum team
• Have another group audit your group: Development audits Quality
• Quality Management & Compliance• Quality Management & Compliance
• External consultant
22
![Page 14: Agile Development in a Regulated Environment](https://reader033.fdocuments.in/reader033/viewer/2022060119/558cad3bd8b42a39188b4589/html5/thumbnails/14.jpg)
A Word of Caution
• Safety is paramount
• Second is the value of the overall product to the customer
• Nobody buys your product because you have perfect paperwork • Nobody buys your product, because you have perfect paperwork and processes
• Sometimes that means to set boundaries
23
Take Away
• Main Point
― Audit Readiness is a deliverable that needs to be integrated in every step of the scrum process
• Key Ideas
― Invest in automation
― Start Small
― Scrum the scrum and continuously improve your process
― Practice
24