Software in Medical Devices, by MD101 Consulting

Fourth derivation: no user requirements!

In previous derivations, I made the hypothesis that we have user requirements at the beginning. What happen if we don't or have something very vague?
This is what people call agile methods. Let's see how to deal with it.

Agile methods, solution 1

Phase of reflexion

The solution is to have a short phase of reflexion at the beginning of the developement, to draw a sketch of the architecture of the software, its main functions and its intended use. Then, the iterations begin and all documents are updated during iterations.
Borrowing the terms of agile vocabulary, this phase of reflexion is like the sprint zero, which aims at initializing the backlog.

Not ready for reflexion?

This phase of reflexion can also be a bit longer. If you only have the idea, you will need one or two months to "translate" it to software. Usually, the decision to begin a software development project stems from a pre-prototype or the result of research phase or even the competitor's products. You could take advantage of this phase of reflexion to develop a sketch of your future software. This will incredibly increase the size of your backlog!

Iterations

After reflexions, the iterations begin. The software documentation previously initialized is updated on the fly, according to the content of the current iteration. Not all documentation should be updated at each iteration, hence some iterations may only contain bugs fixes and some others may contain brand new user requirements.
To make a parallel with the good old waterfall model, we can see iterations as small chunks of the waterfall cycle. You choose the parts of the cycle you should do in the iteration, given the content of the backlog you implement. This is represented in the image below (warning: this is not a representation of an iteration).

If an iteration contains only bugs fixes, then almost no documentation should be updated. Perhaps, only detailed conception or a bit of architecture, and if necessary a small test case to verify a bug fix. If an iteration contains software requirements, then the SRS and all other documents shall be updated. And take enough time to update it!
Taking our previous diagram, documents updates can be represented accordingly.

Consolidation

Once again, test are the weak link of the process. You won't have the time to test everything at each iteration. You have to accept this rule to be agile. (why re-testing everything if it changes so much ???)
At the end of the iterations, a consolidation phase is necessary to ensure that every technical requirement, every functional requirement, and the intended use are well implemented by the software. This consolidation is nothing else than a tests phase where the whole software is tested from A to Z. A consolidation should not be very long, since everything was already defined and tested before. This phase aims only at ensuring that there was no hole in the mesh of your iterations (holes = remaining bugs, most of times).
The tests phases shall be the classical ones: unit tests, functional tests and use cases tests. Depending on the content of your software, you may have deep unit tests verification (eg: complex algorithms) and/or deep use cases tests (eg: complex GUI) in a STD.

Backlog

The backlog is a central concept of agility. To sum-up what I said before, the diagram below shows how the size of backlog of software shoud progress, compared to the phases of reflexion, iterations and consolidation.
One important thing: any user requirement in the backlog after the beginning of the consolidation is an enhancement. It is postponed to the next software version.

Where are the reviews?

The user requirements review should happen when the user requirements are well defined. The software specifications review should happen when the specifications are well defined. The software architecture review should happen when the architecture is well defined...
The best way is to do the reviews ... at the end, before the consolidation phase!
This is not surprising, with agile methods you know only at the end how your software looks like.
However, I recommend to have an intermediate review during the cycle of iterations. You can estimate when the backlog is at its maximum and plan a review with your customer to verify that all main user requirements are here. Main user requirements found after this review may be implemented (if you have time and money!) or postponed to a further version.
A review is also the good time to place the pen in the inkwell and think about the content of your software. By the way, this is recommended by the agile methods! So take the chance of a review to formalize your requirements and have your documentation up-to-date.
To complete the previous diagram, intermediate reviews should be planned during the development. It is up to you to determine when to place them, given the evolution of the backlog.

Agile methods, solution 2

Here is another solution to deal with agile methods. Some of you will find it crap, but it works!
Very simple:

1. You do an agile process with poor documentation,
2. You end it with a formal waterfall process.

I like this one. :-)
The main drawback is to add costs to the software development project. Doing things the right way at the end of the process may be more expensive than doing it all along the project.
This is often the case when a R&D software development project is turned into a product used for research purposes. It is almost or fully functional and the homologation/clearance can be seen as the gap to clinical use. So much has been done during the research phase that is not necessary to redo it with a customized agile process for medical devices. The gap between an IEC 62304 compliant software and a functional software made by research teams is the formalized method and the documentation.
You know how your software looks like. This is the ideal case of waterfall process, when you know everything at the end of each phase. So this is not so stupid to do it like this!

To sum-up

Agile methods are the state-of-the-art for software developers today. Adapting agile methods to IEC 62304 is not difficult. Documentation has to be initialized and updated according to the content of iterations. Reviews should be planned before, during and after iterations, according to the content and the evolution of the backlog. A consolidation phase is necessary to verify that everything was implemented the right way.

In my next post, I will explain how to organize the content of iterations and the team to have the requirements of IEC 62304 met by an agile software development project. This will be the last post of this series. Then I will in a further post address the risk analysis in agile methods.