In this series of posts, I’ve been using Medical Device Development (as Regulated by US FDA via CFR 820.30, and internationally as regulated by IEC 62304) as an exemplar for suggesting ways to develop high quality software in regulated (and other high assurance, high safety, high economic cost of failure) environments in an agile manner.
In an earlier post, based on my reading of the 820.30 regs, I described the chain of regs and explanatory documents that might tend to imply a “waterfall” (sequential, one-pass, stage-gated) development model, which might look something as follows.
Whether based on CFR 820.30 or not, this would seem like a reasonable conclusion based on our historical approach to such development. With the addition above of a single pass “verification” and “validation” activities, this closely follows the requirements>design>code>test models of the past. On the surface, at least, this model has some obvious advantages:
– it is simple and logical (what could be more logical than code following requirements, and tests following that?)
– you only have to do “it all” (especially verification and validation, which can be both labor intensive and error prone) once.
Of course, readers of this blog know it doesn’t work well that way at all, and that’s why we strive for agility in the high assurance markets, just like we do everywhere else. But for many, the apparently beguiling (but false) simplicity of the model is one reason that it has made its way into the various governing corporate quality standards, etc., if for no other reason than “that’s the way we’ve always done it”. (And admittedly, most of the rest of the software industry is doing it that way too).
It Doesn’t Have to be that Way
Momentum aside, however, we now note that while such a thing could be inferred by the various governing documents and our own quality affairs personnel (and it certainly has been applied by countless FDA reviews and other quality audits), in point of fact the specific regs we are using in the exemplar DO NOT require such a process:
1) From US General Principles of Software Validation; Final Guidance for Industry and Staff (US FDA CDRH 2002) we note the following:
“This guidance does not recommend any particular lifecycle models…. “
2) Even more specifically, as Pate and Russell note from IEC62304 (a widely recognized international standard for medical device software which is largely harmonized with FDAs interpretation of CFR 820.30)
“these activities and tasks may overlap or interact and may be performed iteratively or recursively. It is not the intent to imply that a waterfall model should be used.”
3) And finally, from the 2009 Abbott Labs case study describing the successful application of agile development in a Class III (the most stringent FDA regulatory category) Adopting Agile in an FDA Environment:
“we will describe the adoption of agile practices…..This experience has convinced as that an agile approach (multiple iterations during the course of development) is the approach best suited to development of FDA-regulated medical devices.”
There you have it. If we are using waterfall development in support of high assurance systems (at least in the case of the regs we have described here), it is evidently because “we have always done so” (indeed, as this is still mostly case in much of the rest of the software industry) rather than “the regulators made us do it.”
So if, as an industry, we do want to increase the productivity, quality, and yes, even safety and efficacy of the software we produce, it’s time to move on!
Moving to an iterative and incremental, and … agile model.
With a nod to Abbott Labs whitepaper and the associated presentation, and with due respect to the verification and validation activities that will still be required in high-assurance development (see High Assurance Agile Development in Medical Devices: Prove It post), we offer the following figure as a potential, general model for iterative and incremental (and increasingly, as we will see) agile development in high assurance, regulated markets:
It can be seen from the figure that development of software in this model does not follow a waterfall, sequential reqs-code-test time line. Instead we use a series of short iterations, each of which “defines|builds|verifies” some new, and valuable user functionality. [note: I described this as the Define|Build|Test atomic building block of agile development in Scaling Software Agility.)
Periodically (typically after 3-4 iterations) this new increment of software can then be validated and reviewed, prior to being made available for alpha or beta testing, or general availability release. (The shorter the iterations and increments-the faster the feedback;the faster the feedback-the higher the quality. The shorter and faster we go-the more agile we become.)
With respect to additional elaboration of the model, it occurs to me that I’ve used the terms “verify” and “validate” here, as if we knew what they actually meant. Indeed, there is much confusion on the topic, so I’ll try to clarify that in the next post as I go one to explain more about the model above. When we do so, we’ll also hit that nifty high assurance bugaboo called “traceability”. (And doesn’t that one already just sound like some fun?)