SDLC stands for Software Development Life Cycle.
IEC 62304, first released in 2006, amended in 2015, very recently not updated to revision 2, may be my favorite standard.
I like it because it is not overly prescriptive. One may expect, from the title, that it would prescribe what development model a manufacturer should follow. But it does not. And this is good. This means that each manufacturer can adopt a development life-cycle that matches best their culture, stack, innovation spirit and management policies.
But that is not easy or obvious to do so in compliance. Compliance to IEC62304 - like with most of the regulatory ecosystem - is based on the creation and management of documented evidence. So when adopting an Agile, iterative life-cycle, these documented evidence may have to be produced and maintained iteratively - which may sound like not only opposite to the principles of Agile, but also defeating its alleged ‘main purpose" - speed.
Some may be tempted by an “hybrid” approach: Develop a MVP with an Agile process, then, as a concession to the requirements of the regulated medical technology industry, shift to an IEC62304-compliant waterfall process to produce a “final” product that can be “approved”. Sadly (for the entrepreneur who thought they had found the perfect trade-of between development agility and regulatory compliance), this does not work this way. This is not an hybrid approach, it is rather a wasteful (often) and risky (always) path.
Remember what SDLC stands for? Development Life Cycle. All the resources spent during the MVP stage, if not documented properly, are wasted. One of the most common misconception about Agile is that speed is NOT the main point, the raison d’etre of the philosophy. Speed is almost a side-effect of adopting an Agile development method, the same way delays and unwanted iterations are a side effect of Waterfall methods, not their essence.
The main point of the Agile philosophy is to achieve high-quality software development to address the needs of its end users. And Agile methods (regardless of the flavor, aka Scrum etc.) achieve that by acknowledging (and even embracing):
- that end users need to be involved in the development process
- that their interaction with a “work in progress” solution will create new knowledge about the problem(s) to be solved
- that in turn this new knowledge will trigger a need for changes in the direction of solution development.
This knowledge creation process is fundamental to Agile Software Development (and to Product Design and Development in general, hardware, software or services alike). The “hybrid” approach above completely overlooks this. When the time comes to document a waterfall life cycle, the development teams needs to start from scratch to document the customer requirements, software architecture etc. using either:
- a ‘fake’ process to reuse the MVP code whilst appearing like this exercise was done using a real waterfall approach (hence the “risky” above. Notified bodies and other audit authorities will see through that instantly - the times of computer illiterate auditors is past and forgotten).
- a ‘real’ waterfall process to rebuild the code base from scratch, based on the requirements elicitation done with the MVP (hence the “wasteful” above). We wrote “often” above, as one may argue that if the earlier MVP process was well documented, it may not be wasted, and the waterfall “code rewrite” can be seen as “just” a refactoring exercise for the sake of a better codebase. Maybe - although to properly document the initial phase, the manufacturer needs to put in place procedures and systems that are very close to what would have been needed for a real Agile SDLC to start with!
Regardless of where you are in this journey, Diapason can help you. From educating founders and early stage development teams to the principles of IEC62304, to reviewing your processes and records for best practices (gap analysis) and to assessing compliance (internal auditing), we can deploy remotely or in-situ. Call us now.
PS: If your application is not a medical device, or is excluded from medical device regulations in your market, you don’t have to comply with IEC62304 for regulatory reasons. But you still want your development teams to adopt state-of-the-art development practices. There are other technical standards you can follow for that, such as IEEE/ISO/IEC 12207. But they are not any easier/simpler.