Some application areas have quite strict quality requirements. The space and aviation industry is one, another in which I am currently involved is that of medical systems. The importance of quality for those systems has led to the establishment of several quality standards for the development of software for medical systems, of which I will name a few:
- ISO 9000 and ISO 13485 describe the requirements for a quality system that is implemented in the developing company.
- IEC 62304 describes requirements for the software development process used to produce software for medical devices. This is derived from ISO/IEC 12207 which is the general standard for software development lifecycle.
- ISO 14971 describes the requirements for risk management.
- ISO 25010 describes a standard for quality requirements of a system, not specifically targeted for medical software but software in general.
The standards documents themselves seem to assume a quite rigorous set of processes implemented in a company that develops software for these purposes.
I was recently asked to coach a newly hired development team in dealing with these standards. The only thing was: they needed to comply to the standards, but wanted to develop their software using agile processes. The question was: could it be done? And could it be done in line with the aggressive delivery schedule they had taken upon themselves for the commercial availability of their first product?
They were not alone. For example GE Healthcare is doing the same. The FDA even recognised a proposed mapping of IEC 62304 on agile (AAMI TIR45) as a standard, thus endorsing agile as a recognised process to develop high quality software.
However endorsing agile processes is one thing, actually implementing them in a company that needs to deliver that software in a tight timeframe, as well as the complete setup and implementation of the required quality system (QMS) and processes is another. As many people are finding out, some to their detriment, you need a very experienced coach to help you on the road of agile development, the more so for software for medical devices. The coach not only needs to be versed in agile in a large variety of contexts, but also in quality systems and risk management. There’s not many of those, but the problem is you do need one, otherwise you might reach one goal but certainly will miss the other. The mapping of the two is too complex to deal with if you need to learn one (or even more problematic: both!).
Fortunately the agile community also recognised the need for agile processes to be suitable for (extreme) high-quality requirements. Scott Ambler, a recognised agile pioneer, has founded DAD, Disciplined Agile Delivery, and that project is also a source of established experience and working material for teams that are wrestling with agile in the contexts I am talking about.
The essence of applying agile for the development of software for medical devices that is in risk Class C (the highest risk class) is that you should not need to do concessions on the agile principles (as for example expressed in the Agile Manifesto). But how you do that is very hard to put in a check list. It is very tempting, under mounting pressure of time and resources, to fall back on “more control” and waterfall processes, if not by the development team itself, then by management or project management. The advantages of agile should be exploited from a very early stage: early delivery of working software, demonstrated quality and test coverage, and traceability to requirements and defined risks. That way the development team as well as management will have a steadily growing trust in the approach which will allow the team to reach maturity fast, within a year or so depending on previous experience of the team members.
The author is very interested in contacting others working in these areas (especially in The Netherlands).
Leave a Reply