Software in Medical Devices, by MD101 Consulting

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.


For example, we replace a cycle of 18 months by 3 cycles of 6 months each.

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. 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.
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.
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.