Docstoc

Agile 2009

Document Sample
Agile 2009 Powered By Docstoc
					Moving to Agile in an FDA Environment


An Experience Report




                           August 27, 2009
                      Introduction
• Available for download at (insert link here)

• Agile Resources
   – Agile Manifesto http://www.agilemanifesto.org/
   – Agile Alliance http://www.agilealliance.org

• Agile Books
   – http://www.agiletek.com/thoughtleadership/books
   “Agile Software Development” by Alistair Cockburn
   “Agile Project Management” by Jim Highsmith




                          An Experience Report
                                Slide 2
                  Outline

• The Abbott Experience
• Lessons Learned
 1. The least burdensome approach?
 2. A Risk Based Approach
 3. Control what you don’t know, don’t let it
    control you
 4. Dispense with ceremony
• Results


                 An Experience Report
                       Slide 3
               The Abbott Experience
• Comparing two FDA-regulated
  medical device projects
   – One not agile, one agile
   – Class III devices (most stringent)
   – Results of agile adoption
       •   Lower cost
       •   Shorter duration
       •   Better, less prescriptive test cases
       •   Accommodated change
       •   Higher quality

• See paper “Adopting Agile in an
  FDA Regulated Environment”




                                  An Experience Report
                                        Slide 4
                                 Product Development Lifecycle
                                                                           Product Development Lifecycle
                                         Research
                                                                                                                                               Development
                Concept                                              Feasibility



Concept Phase                    Concept Phase   Feasibility Phase                 Feasibility Phase   Development Phase   Development Phase                  Development Phase
                                                                                                                                                                 Increment n      Design Transfer
 Increment 1                      Increment n      Increment 1                       Increment n          Increment 1         Increment 2




          Capability Inventory

          (Comprehensive list of
          features, scenarios,
          architectural elements,
          etc. – a living document)

                                                                                                                                Increment
                                                                              Increment n, Iteration 1                             Increment n, Iteration 1     Increment n, Verification




                                                                             An Experience Report
                                                                                   Slide 6
Software Development Lifecycle




           An Experience Report
                 Slide 7
                                          Iteration Model
Iteration Model



       Software Characterization
                                                              Software              Software Confirmation
                                                             Construction
      Product Definition                                                              System Test
                                                          Design
      Feature Summary                                                                 Regression Analysis
      Feature Descriptions                                Feature Detailed Design     Integration Test
      Software Requirements                                        Presentation       Acceptance Test
      ...                                                          Business Rule      Functional Testing
                                                                   Data Access        ...
                                                                   Persistence

                                                          Test Design
      Planning                                            ...                         Stakeholder Review
      Software Development Plan                                                       Application
      Software Process Definition                                                     Requirements
      Software Engineering Development Practice                                       Feature Descriptions
      Software Test Plan
                                                          Implementation
                                                                                      Scenario Descriptions
      Software Configuration Management Plan                                          ...
                                                          Presentation
      Software Quality Assurance Plan
                                                          Business
      Software Measurement Plan
                                                          Data Access
      Capability Allocation Matrix
                                                          Database
      Software Schedule
                                                          Test Cases
      ...                                                                             Software Release
                                                          ...

                                                                                      Version Description
                                                                                      (Release Notes)
                                                          Verification                Traceability Matrix
      High Level Design                                                               Inputs -> Outputs
                                                          Unit Test                   Validation / Verification
      High Level Design Description                       Integration Test            Data
      Software Architecture Description                   Code Inspection             ...
      User Interface Design Document                      Design Review
      User Interface Framework                            ...
      ...




                                                  An Experience Report
                                                        Slide 8
       Sample Design Control Documents

      QSR Ref.   ISO Ref.   Design Control Element                      Documents
1.   820.30(b)   7.3.1      Design and development           Design and Development Plan
                            planning
2.   820.30(c)   7.3.2      Design input                     System Requirements Specification
                                                             Safety Risk Analysis
3.   820.30(d)   7.3.3      Design output                    System Design Description
                                                             Source code
                                                             Drawings/Schematics
4.   820.30(e)   7.3.4      Design review                    System review reports
                                                             Design review reports
5.   820.30(f)   7.3.5      Design verification              Verification Test Procedures
6.   820.30(g)   7.3.6      Design validation                Validation Test Procedures
                                                             Test Summary Report
                                                             Requirements traceability matrix
7.   820.30(h)   NA         Design transfer                  Design transfer procedure
8.   820.30(i)   7.3.7      Design changes                   Change control procedures
9.   820.30(j)   4.2.3-4    Design history file              Document control procedures


                                                  Courtesy of: Certified Compliance Solutions, Inc.


                                  An Experience Report
                                        Slide 9
      Sample Submission Documents


Num.            Requirement                                 Document
1.     Level of concern                Safety Risk Analysis
2.     Software Description            Design and Development Plan
3.     Device Hazard Analysis          Safety Risk Analysis
4.     Software Requirements           System Requirements Specification
       Specifications (SRS)
5.     Architecture Design Chart       System Design Description
6.     Software Design Specification   System Design Description
7.     Traceability Analysis           System and safety requirements traceability matrix
8.     Software Development            Design and Development Plan
       Environment Description
9.     Verification and Validation     Verification Test Procedures
       Documentation                   Validation Test Procedures
                                       Test Summary Report
10.    Revision Level History          Initial market release
11.    Unresolved anomalies            As per procedure, anomalies that affect safety or
                                       essential performance are not allowed in a release



                                             Courtesy of: Certified Compliance Solutions, Inc.


                                An Experience Report
                                      Slide 10
Lessons Learned
               Least Burdensome
   We [FDA] are defining the term
   “least burdensome” as a
   successful means of
   addressing a premarket issue
   that involves the most
   appropriate investment of
   time, effort, and resources on
   the part of industry and FDA.

--The Least Burdensome Provisions of the FDA
   Modernization Act of 1997: Concept and
   Principles; Final Guidance for FDA and Industry

                       An Experience Report
                             Slide 12
A Risk Based Approach




                  Courtesy of: Certified Compliance Solutions, Inc.


      An Experience Report
            Slide 13
       Risk Based Approaches

• IEC 62304 section 5.1.1, page 31:
 Note 1: The software model can identify different
 activities for different software items according to
 the safety classification
• FDA General Principles of Software
  Validation, page 7, section 3.1.2:
 The level of confidence, and therefore the level of
 software validation, verification, and testing effort
 needed, will vary depending on the safety risk
 (hazard) posed by the automated functions of the
 device.
                               Courtesy of: Certified Compliance Solutions, Inc.


                   An Experience Report
                         Slide 14
     FDA Reviewer Guidance 2005
  SOFTWARE     MINOR  MODERATE                               MAJOR
DOCUMENTATION CONCERN CONCERN                               CONCERN
Verification and   Software          Description of      Description of
Validation         functional test   V&V                 V&V activities
Documentation      plan, pass /      activities at       at the unit,
                   fail criteria,    the unit,           integration, and
                   and results.      integration,        system level.
                                     and system          Unit,
                                     level. System       integration and
                                     level test          system level
                                     protocol,           test protocols,
                                     including           including
                                     pass/fail           pass/fail
                                     criteria, and       criteria, test
                                     tests results.      report,
                                                         summary, and
                                                         tests results.

                                     Courtesy of: Certified Compliance Solutions, Inc.


                      An Experience Report
                            Slide 15
Control What You Don’t Know, Don’t Let It Control You

• What you do know:
    – A typical medical device is developed over a 3-5 year
      time horizon
    – It is a myth that you can predict in detail your end
      product requirements up-front
    – Start with a core set of features that you must implement
    – Implement the core features first
    – Defer the most volatile features as long as possible

• Iterative approach allows the team to:
    – Manage scope and limit feature creep
    – Negotiate scope and tradeoffs with key stakeholders

• “At time of commercial launch, a number of features,
  once thought to be essential, were not included. Some
  were deferred as long as three years. Nonetheless,
  the product was considered highly successful and
  trading off nice to have features for three years of
  sales is an easy choice.”

                            An Experience Report
                                  Slide 16
Dispense With Ceremony
• If it is not adding value, and it is not required,
  do not do it
• The design history files should contain the
  minimum set of documentation that satisfies
  the regulatory requirements
• There will be other activities that you will
  want to document, no need to include in
  design history file, make sure they add value
  and do it in a least burdensome way
• Avoid doing things because “that’s the way
  we’ve always done it”
• If it feels like you are wasting your time you
  probably are




                An Experience Report
                      Slide 17
Results
                       Results
• High visibility
   – Easier to manage and control
   – Far fewer surprises
• Lower cost and shorter duration
   – Estimated schedule and team size reduction of 20%-
     30%
   – Estimated cost savings of 35%-50%
• Higher quality
   – Availability of working software facilitated continuous
     testing instead of back loaded V&V
   – Resulted in fewer overall defects, especially at the end
     of the project
• Better work life balance and team morale
   – Project death marches are rarer because the issues
     are surfaced as you go and are managed accordingly,
     not all saved up for the end of the project

                       An Experience Report
                             Slide 19
Q&A
 Thank You
Tim Hughes                     J.R. Jenks
Managing Partner               Managing Partner
thughes@agiletek.com           jrjenks@agiletek.com
847-699-2260                   847-699-2250

John Skach                     Rod Rasmussen
Senior Technology Architect    Director, Informatics & Software Systems
jskach@agiletek.com            Rodney.Rasmussen@abbott.com
847-699-2264                   847-938-3633



                  An Experience Report
                        Slide 21

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:9/24/2012
language:English
pages:20