Class C software and agile methods
Are agile methods compatible with the constraints of development set by IEC
62304 standard of class C software?
After a series of three posts about agile methods and risks analysis. I focus in this post on IEC 62304 class C critical software.
Agile paradigm and critical software
If I had to sum-up in one sentence the constraints of critical software, it
The more critical, the less user requirements.
Critical software don't like complexity
Complexity is a direct source of bugs, so critical software don't like
Multiple user requirements are a source of complexity, the more user requirements, the more workflows, components, branches, conditions and the like. So the best way to have a critical software run without bugs is to limit the numbers of user requirements.
Limiting the number of user requirements doesn't mean that we limit the number of software requirements deduced from the user requirements. In other words, few user requirements and a lot of software requirements cutting into small pieces the goals of user requirements.
Users doing critical tasks don't like complexity
If you have to do a critical task, say something very critical, like a
Cardiopulmonary Resucitation, you don't want a complex scenario. Complexity
adds stress and you don't want it. You prefer if it is very simple. If the
scenario is not simple, you are trained to act as defined according to that
scenario. This is the case of doctors who spent 10 years of their lives
learning by heart subtilities of medical protocols.
So, when defining the requirements of critical software, users will be prone to:
- Define the software functions for A to Z, thinking to all possibilities according to bibliography and their experience,
- Define a simple software.
If users aren't prone to define something simple, you should guide them to
This is the opposite situation of agile methods, where software definition evolves a lot during design. This is also the ideal situation for the waterfall model.
Would user add new user requirements to critical software?
You could object that it is difficult to think about everything in a
software before implementing it. If you do a presentation of a software in the
middle of the development, no doubt that beta test users will suggest or impose
new user requirements.
But there is a good chance that the new requirements won't need to reconsider the architecture or refactor the whole software. We are more in a situation of a waterfall model with multiple runs, like the ones I showed in the first two diagrams of this post.
So, agile methods aren't really adapted to critical sofware because the agile paradigm is not respected.
In other words: No changes in user requirements = no agile method.
Separating very critical parts
One way to mitigate risks is to separate the most critical parts in the
architecture of your software (as asserted in the IEC/TR 80002-1 guideline).
For example, the critical part runs on a microcontroller and the rest runs on
an embedded PC on linux. The first is class C, the last is class B.
Organizing the development of critical parts
The separation of critical parts requires a good experience of software
architecture. I can't give advice about architecture, it's too dependent on
technology. But it doesn't prevent me to give my advices about the kind of
organization that manages that kind of software development!
Steps are the following:
- identify class C critical part
- do it in a separate sub-project, with less agile method or absolutely not agile methods like waterfall,
- do the less critical (or not critical) part with agile methods.
Doing the less critical part with agile methods doesn't mean that it is open bar! You still have to respect the contraints of medical software development with agile paradigm!
A way to develop the critical software
The pitfall of this organization is the interface between the critical and non critical part. There is a good change that the interface can introduce bugs in the critical part if the interface of the less/non critical part evolves a lot. To do so, you have to fix the interfaces early:
- Separate interface development from the rest of the project,
- Implement interfaces of both parts,
- And implement simulators of components that use the interfaces to verify they work.
The condition to do so is to have a validated design of the critical part and its interfaces. This is not a 100% efficient solution but it can avoid a lot of problems with the interfaces. The drawback is to have few or zero possibilities of evolution of the interfaces when the non critical part evolves.
Software development team
If you have only one unified team (this is a prerequisite of agile methods)
and the same technologies for critical and non-critical, begin with the
development of the critical part with the waterfall and continue with the
development of the non critical part with agile method.
But I think this is rarely the case. There is a good chance that you have two different teams, one for the critical part and one for the rest, especially if technologies (framework, language, OS) are not the same in both parts.
This means that both teams have to communicate and work together. Team communication is also a source of bugs and this is the role of project managers to avoid quiproquos and misunderstandings (something to handle in the project management plan).
The underlying reflexion in this post is that there is no miracle solution
for the development of critical software.
Very critical software are made with waterfall or equivalent method. Agile software development and critical software development are somewhat antonyms. I tried to give my own solutions but their principle is to separate the critical part from the rest... and to develop critical part with a regular method.
Applying agile methods to constrained and critical software is like herding cats!