One of the widely accepted software design patterns is the Waterfall model in which all activities, starting from requirement gathering until the deployment are followed sequentially. It uses clear structures, transforms information well, and targets concrete goals. Even though it is popular, it does have several shortcomings:
- No room for incorporating new changes until the current phase is completed.
- No involvement of clients and end-users throughout all phases.
- Delay in testing and deployment phases (as major changes cannot be included).
Considering these limitations, the Agile design pattern was created. It uses the iterative software development method in which software might receive new requirements or may undergo design changes in any phase of development1. Also, elements like Sprint and Continuous Integration with Continuous Deployment (CICD) facilitate the involvement of product owners or clients along with their feedback in all phases.
Software developed for a medical device must be compliant with the FDA regulations at a minimum. FDA defines standard protocols for software developed using the Waterfall model. But, in the case of Agile, in which the changes given by the clients or by the design team are implemented at any software life cycle stages, what factors play key roles in FDA regulatory processes?
The two significant parameters considered are Design Controls and Reviews. In the following context, Story is defined as a feature discussed from a user perspective. Also, Sprint is a period of 2 or 3 weeks where the product owners along with the development and testing team reviews the current state of the software. The following are Design Controls activities for regulating Agile-based software:
- Requirement gathering and planning – Update project plan and forecast document.
- Architecture and Story design – Update system architecture, SRS, traceability documents, and verification protocols.
- Risk evaluation of Stories – Update risk document.
- Programming and testing with CICD – Update SDS and traceability document.
- Demo phase – Document design review.
- User testing – Update usability summary and risk management documents.
- Risk evaluation – Update risk document.
- Testing (System, Acceptance) – Update test reports.
- Retrospect/ Working on past software activities – Update software development plan.
Moreover, Design Review is constituted by the Software Verification and Validation. In Agile, software verification is conducted right from the very first User Story which results in the following activity mapping: User Story à Code/ Programs à Unit level testing à System testing. Validation is carried out by clients or end-users in which they test the overall functionality along with the data flow via product demos or reviews conducted at the end of every Sprint.2
To sum up, for software that possesses a complex design and requirements are not clear, Agile is a perfect design pattern. Additionally, it is essential that software developed with Waterfall or the Agile model and running in a medical setting needs to be FDA compliant. Do you need help ensuring your medical device software is compliant with FDA’s requirements? Our regulatory experts at EMMA International can help your software product become compliant. Contact us at 248-987-4497 or info@emmainternational.com for additional information.
1Neetu Yadav (December 2016), FDA Perspective on Agile Methodology: Healthcare Environment, Retrieved on 08/12/2020 from https://www.linkedin.com/pulse/fda-perspective-agile-methodology-healthcare-neetu-yadav/.
2Bernhard Kappe (2013), Ebook: Agile in an FDA Regulated Environment. Retrieved on 08/12/2020 from https://orthogonal.io/insights/ebook-agile-in-an-fda-regulated-environment/.
