Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search


How to develop medical device software with agile methods? - Part 1

IEC 62304 is the standard to apply for software in medical devices. It is not bound to any software development method or model. Though not explicit, using the waterfall development model is the most straighforward way to apply this standard.
The waterfall model has become old fashioned to the eyes of most of software developers, with the emergence of agile methods. Agile methods are so popular now that everydody wonders how to apply IEC 62304 with agile methods.

An AAMI/CDV-1 TIR(SW1) - Guidance on the use of agile practices in the development of medical device software exists about this subject. But it is still a draft and only members of AAMI have access to it.

So, how to use agile methods and still be compliant with IEC 62304?
Here are my thoughts about these questionings!

This is a preliminary article in a series of three about agile methods.

Tweaking the waterfall model

A word to explain how I managed to reach a conclusion about dealing with agile methods. I start from the waterfall model, the de-facto standard, and derive it sequentially, until it looks like the agile methods.

First derivation of waterfall model

The most simple thing to do is to repeat the waterfall cycles, instead of one plain waterfall cycle in n months, we repeat the cycle p times, each cycle lasting n/p months.
Software in Medical Devices - phases of waterfall development process

For example, we replace a cycle of 18 months by 3 cycles of 6 months each.
Software in Medical Devices - waterfall development process repeated 3 times

User requirements

The percentage of user requirements completed increases during each cycle. We obtain 3 versions of software:

  • Iteration 1, with 33% of user requirements,
  • Iteration 2, with 66% of user requirements
  • V1.0, fully functional final version.

The duration of cycles is still compatible with the production of the documents at each cycle. The SRS, SDD, STP, STD, STR (and so on, see my page about templates...) are created during iteration 1; updated during iteration 2 and completed in iteration 3.

Repetition of tests

One fundamental thing is to avoid regressions, when something used to work in iteration 1, doesn't work in iteration 2 or 3. Testing the whole software at each iteration is the only way to avoid regressions.
So tests are repeated at each iteration.

Second derivation

Let's add more cycles, by doubling the number of cycles in 18 months.
We have now 6 cycles of 3 months each. Software in Medical Devices - waterfall repeated n times, like iterations The situation tends to become difficult to manage. The burden created by the repetition of iterations becomes to high (excepted if you have plenty of time/money and people dedicated to it):

  • User requirements may not be easily split in many iterations,
  • Technical requirements, software architecture and software design may not need being updated at each iterations,
  • Software tests have to be updated, whatever the burden (less tests --> more bugs).

A solution is to spend time of the first stage to software specifications, architecture design and (a bit of) detailed design. This first stage is consacred to the reflexion on the functions, the architecture and the design. Developers may (and will) write sketches of software but this remains a low percentage of activity.
The SRS, STP, SAD and SDD should be almost 100% finished at the end of the first stage.
Software in Medical Devices - waterfall development repeated n times, with first and last iterations that are modified Then the iterations begin, of 3 months each. They stem from the results of the first stage to implement sequentially the software requirements in each iteration and the tests cases. So only the SDD and the STD are updated at each iteration. Others documents should remain unchanged or be slightly changed to match the small changes in software requirements and design.
During the last stage, the whole software is verified, last bugs are fixed and the software is validated.
Again, as I said before, the whole software has to be tested when it is complete. You should spend time of the last stage only to re-test extensively the software. This is the only way to ensure that it is correctly verified.

Third derivation

Let's add even more cycles, during 18 months we do 36 iterations of 2 weeks. We absolutely don't have time to do the whole documentation of the waterfall process during each cycle. Keeping the first stage of reflexion and the last stage of testing, the iterations are shrinked to fit the timeline of the project.
Software in Medical Devices - reflexion and validation surrounding iterations This is like pushing the second iteration derivation to its limits. Nothing new here compared to the second derivation.
Again, the testing phases are mandatory in each iteration. Since there is no time left to retest everything in two weeks, only the software parts impacted by the coding of the current iteration should be tested at the end of the iteration, plus expected regressions.

Derivations but not agile

What I showed above is still not agile methods, like scrum or extreme programming.
In previous derivations of the waterfall model, I made the hypothesis that we have user requirements at the beginning. Not having the user requirements is a fundamental parameter of agile methods.
So, what happen if we don't have user requirements or have something very vague about the intended use?
This will be the second part of this series.
See you next week.



Comments

1. On Friday 25 May 2012, 14:07 by Tony Johnson

Is it possible to obtain copies of the powerpoint slides or visio diagrams for this article? I would like to re-use the digrams in a presentation.

2. On Friday 25 May 2012, 14:07 by Tony Johnson

Is it possible to obtain copies of the powerpoint slides or visio diagrams for this article? I would like to re-use the digrams in a presentation.

3. On Saturday 7 December 2013, 00:59 by Sandra

Hi there, I enjoy reading through your article post.
I wanted to write a little comment to support
you.

Add a comment

Comments can be formatted using a simple wiki syntax.

They posted on the same topic

1. On Friday 3 October 2014, 14:18 by Anonymous blog

From test driven development and specifications |

(…) There's an interesting series of blog posts (beginning here) I was reading in which agile methodologies for medical software is discussed. One solution (described as Agile (…)

This post's comments feed