FDA Software Verification and Validation

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.

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.

http://www.klocwork.com/solutions/FDA/

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, very interesting cases 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: disturbing.

Notes for Editors

Todd Landry, a Senior Product Manager at Klocwork, a leading developer of static source code analysis software and expert in critical software defects. He is responsible for guiding the company's technical direction and strategy. With nearly 20 years of global technology experience, he brings a valuable combination of vision, experience, and direct insight into the developer perspective.

http://www.klocwork.com/products/insight-pro/
http://www.klocwork.com/blog/2009/05/findbugs-not-recognizing-exceptions/

Klocwork is an enterprise software company providing automated source code analysis software products that automate security vulnerability and quality risk assessment, remediation, measurement for C, C++ and Java software and java static analysis. More than 300 organizations have integrated Klocwork's automated source code analysis tools into their software development process in order to ensure their code is free of mission-critical flaws while freeing their developers to focus on what they do best - innovate.

Share:


Tags: analysis, automated, code, code analysis, FDA software, peer code review, software quality, software validation, Source, Source code, source code analysis, Static, static code analysis


About Klocwork

View Website

Klocwork
15 New England Executive Park
Burlington, MA 01803