Free content for your website or blog
Home About Us Article Writing Most Read Articles Authors Blog Wiki Contact Us
RSS Register Login
Topics
 
Home > Business >

FDA Software Verification and Validation

Date Published: 16th September 2009
Bookmark and Share Republish FDA Software Verification and Validation
Author: David Boon RSS Views: N/A PRINT ASK ABOUT THIS ARTICLE
Main topic of today is using Agile in an FDA regulated medical device context. Sounds like an impossibility I know, but the folks from Agiletek and Abbott presented a very interesting case study on how they did it. They started off by presenting "the way it used to work", highlighting an older product development cycle from the 1990s that had very strictly defined dev phases, including a 10-12 week integration cycle - yikes! When they decided to implement Agile on a more recent project they broke up their 3-5 year dev cycle in 6 week iterations. Here were the biggest barriers they found to achieving this:
Documentation - they tackled this topic upfront. There is a perception that the FDA wants truckloads of docs from medical device manufacturers. The reality is, according to the presenters, that’s not the case… the FDA wants "enough" documentation to demonstrate your process ("least burdensome" in FDA-speak). The biggest area is of course documenting requirements which they did through a Capability Matrix.

Requirements - this required a big culture shift. They talked about past projects with 14 month requirements definition phases… which still didn’t capture everything! Now, they realize it’s a myth that all the req’ts can be defined upfront, and as the gentleman from Abbott stated: "Your requirements are final when the product is retired from market."
Software verification and validation (V&V) - they emphasized a risk-based approach. Run code inspections and reviews on the most critical areas of code. Keep your requirements focused and high-level so testers are testing the important stuff.
Anyway, here are the results they found by modernizing their development with Agile: higher visibility, lower costs (estimated schedule and team size reduction of 20-30%), higher quality product (availability of working software allows for continuous V&V), and overall the project had a steady pace to it rather than mad integration scrambles or backend V&V chaos.

The one big aspect of Agile they weren’t able to implement is the customer feedback component. This is mainly due to the limitations med device companies have around "pre-marketing" their product.
All in all, a very interesting case study. Be interested to hear where anyone else has seen this done in a highly regulated environment. Signing off from Agile 2009… be sure to follow us on Twitter:
Tags: myth, critical areas, iterations, quality product, case study, impossibility, gentleman, steady pace, 1990s, market software, yikes, product availability
This article is free for republishing
Source: http://www.articlealley.com/article_1091359_15.html
Bookmark and Share Republish FDA Software Verification and Validation

Ask a Question About this Article

Powered by