In 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.