Agile Development in Regulated Environments Example: Medical Devices – Waterfall Lifecyle Model
Posted on October 23, 2010 by Dean Leffingwell in Agile and FDA, High Assurance and Regulated EnvironmentsIn an earlier post, I noted that I would be using the FDA CFR 21 820.30 regulations as our example “stalking horse” to try to develop a reasonable and logical way of conforming agile development to these, and similar regulatory standards that are prevalent in high assurance software development industries. By way of context and example, here’s the regulatory tree that drives the medical device industry in the US.
The heart of the matter here is CFR21, Part 820.30 Subpart C, Design Controls, and expectations for meeting these regulations are elaborated in the much larger documents on the right. But since the document highlighted on the left is really the legal document, (and it is remarkably short), we’ll first analyze that to understand what we are legally obligated to achieve in this regulated software process. This regulatory document can be found online here.
It’s objective is:
“a)General. (1) Each manufacturer of any ……(device), shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met.”
It goes on to describe the various lifecycle activities, and the work that has to be done in each . I’ve captured the highlights in the table below.
If we look at this pictorially, and perhaps with the implied waterfall that one tends to naturally infer, you get the following picture.
If we use the shorthand we provided in the table above for the development activities, then you get the following picture:
Wow, that sure looks familiar, and somehow, not very agile, does it? Does it have to be that way. NO. That’s the subject of the next post.
Add to Google








I am definately interested in seeing how the “Agile” development lifecycle can translate to meet the lifecycle activites defined in your last diagram here. Please subscribe me to the blog.
I am also very interested in any case studies where what you do propose to meet the FDA compliance issues has actually been reviewed in an audit by an FDA equivalent governing body.
[...] some others have gone down this road before. And while the analysis of CFR 820.30 we did in the last post might indicate a waterfall mentality, the fact is that it doesn’t have to be that way at [...]
[...] standard for medical device software, one that is harmonized with FDA CFR 820.30. see my post.). It’s a great example of what this series is all [...]
[...] an earlier post, based on my reading of the 820.30 regs, I described the chain of regs and explanatory documents [...]