Software in Medical Devices, by MD101 Consulting

The fundamental difference between a "classical" iteration and an iteration of software development for medical devices is the additional activities related to mandatory documentation of software development.

Organization of an iteration

Typical iteration

A typical iteration can be summarized on a diagram like this one:

Like any agile method, the development shall be centered on:

1. The user's requirements
2. The coding activities

To make it compliant with medical devices software development, additional tasks are mandatory.

Software documentation tasks

Specifications and risk analysis shall be updated at the begining of the iteration, after the startup meeting. If there are no changes in user requirements or technical specifications, there's quite a good chance that these updates are not needed.
An iteration can switch directly to coding if there's nothing to update!
However, there's little probability that an iteration doesn't need documentation updates.

Software Testing tasks

Software testing is made of two parts:

1. Describing tests
2. Testing software

IMHO, tests is the weak link, like in any other software development method.
Describing tests may be skipped, either unit tests I've already coded it! Coding unit tests is boring. or manual tests There's so much to code! I don't have time to write tests!
Testing may be skipped as well. Testing happens at the end of an iteration and it may be skeezed by bug fixes and the like.

Duration of an iteration

The duration of an iteration is not fixed. It depends on the size of the requirements, bugs fixes, small enhancements which are coded.
I can give some metrics:

• bugs fixes only: 3 to 5 days
• minor enhancements and not chalenging user requirements: 5 to 10 days
• challenging user's requirements, architecture refactoring: 10 to 15 days

Having an iteration of more than 10 days should be an exceptional case. Those who are used to agile methods know these metrics, this doesn't sound new.
Be careful however to reserve enough time to software documentation and testing. These additional tasks either extend the duration of an iteration, or reduce the number of other tasks completed.
Once again, skipping documentation and testing is the main pitfall of agile methods. It happens quite faster than you imagine!

Organization of the team

First of all, the project manager should be someone with experience in the field of medical devices. Nothing new here.

Software team

The additional tasks mentioned above should be shared by different people. It's not possible to have only one person responsible for these tasks. He/she won't have time to code and will be put aside of the group.
From my own experience:

• Documentation of specifications, architecture and risks analysis is reserved to the project manager or an experienced sofware architect,
• Documentation of detailed design should be allocated to a developer,
• Documentation of manual tests should be allocated to a developer and/or an integrator/tester,
• Software testing shall be done by a tester who is not the coder of the tested part.

A few remarks and justifications about this:

• Someone who only writes documentation would be put apart quickly, he would be a source of disturbance to developers, continuously asking about the software content.
• A tester won't be put aside, even if he/she doesn't code. A tester generates bugs and closes them, a big concern for developers!
• A developer who hasn't the willingness to write documentation will never do it. So choose carefully the ones to whom you give documentation tasks!
• A developer who is happy with documenting software is more prone to understand challenges outside pure coding tasks. It's one of the good ways to identify future software architects and projects managers.

Quality manager

I haven't told about the quality manager yet. He/she is an important piece of the puzzle. However it's difficult to have quality managers who are software specialists at the same time. That's why I didn't include him in the software team. If you have one who has both knowledges, you're lucky.
The quality manager shall be involved in the process by being present to reviews. Maybe not all meetings of iterations but from time to time during important iterations with big changes (the project manager has to decide when to invite him). His external view of the project will be of great use.
Of course, the quality manager shall be present to main reviews like those I mentioned in my previous post.

Conclusion

To sum-up, iterations for medical devices software development are constrained by the mandatory tasks of software documentation and thorough software testing.
These tasks increase the quantity of work to do in one iteration and they should be allocated to people who have the will and the time to do it. Reserving documentation to only one person is not a good solution.

In this series of posts, I talked a little bit about risks management. But dealing with risk management in agile methods deserves its own article. It will be the subject of my next post.
Bye.