Software in Medical Devices, by MD101 Consulting

Agile paradigm and critical software

If I had to sum-up in one sentence the constraints of critical software, it would be:
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 complexity.
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 do so.
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).

Conclusion

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!