TGFR Consulting LLC Introduction
Using agile software development for a medical device is quite possible, providing the process considers and adapts to some key constraints medical development imposes. These constraints include:
- Development needs defined set of Design Inputs. These input requirements represent an “engineering level of detail” for the system and are derived based upon the intended use, user needs and risk control measures
- Formal verification confirms conformance to Design Inputs.
- The requirement for user validation of the “finished device”
Medical device development usually follows a waterfall process. This process includes defined development, verification and validation phases. Using an iterative agile process needs to include these key activities. Without considering the activities associated with design inputs and verification, iterative agile process advantages may not be realized. This doesn’t mean agile can’t be effective, just that the workflow needs to be adapted to accommodate these constraints.
The follow sections define mechanisms that allow the application of an iterative process to be applied in the development of a medical device
Overview
The following drawing provides an overview of an agile process that accommodates the constraints of medical device development
Requirements partitioning reviews the Design Inputs and architecture, establishing the requirements partitioning, creating a structured backlog for the sprints.
The sprint requirements process structures requirements prior to the the execution and reduces churn to design inputs. Eliminating churn enables better verification of each sprint’s output.
Sprint verification leverages the requirements to develop verification designs for each development sprint. Proper requirements planning prior to the sprint eliminates potential verification rework.
Requirements Partitioning
Requirements partitioning starts by understanding that an agile process will be used. This drives iterating on architectural and planning decisions to get the best breakdown of the iterative development backlog. Partitioning adjusts the architectural design, linking subsystem interactions and sprint planning. Considering the architecture with sprint planning drives efficiency and minimizes rework.
In this iterative partitioning process, review of the interactions between system requirements or features drives scheduling and planning. Features depending upon multiple subsystems need to be scheduled later in the cycle of iterations. Schedule features without many dependencies early. When the partitioning doesn’t look right, revisiting the architecture may be required.
In a sense, partitioning creates a new iterative cycle. The team iterates on or requirements decomposition to get the best structure for the backlog prior to starting the sprints for development.
The Agile Pipeline
The pipeline for agile development incorporates the following
- Requirements Elaboration – Creation of the requirements for the next development cycle happens prior to the development
- Subsystem/Sprint Development– the actual iterative development cycle
- Verification Design – Parallel creation of verification protocols for the current iteration features/requirements
- Verification Execution– Verification of the development output integrates with pipeline
This cycle is shown below
As shown, Separate teams develop requirements, verification design and verification results artifacts. Without integrating verification with the development cycle, a post-development verification cycle negates the advantages of an agile process. Achieving this integration requires
- The verification design and the development teams work from the requirements developed by the requirements team prior to the iterative development cycle kickoff.
- At the end of the cycle the system, as developed by the team and the test designs are handed to the verification execution team.
Summary
Medical device development can use an agile process. The needs for a structured verification introduces an additional iterative cycle for the requirements and architecture. This cycle reworks the partitioning to address the upcoming iterative cycles. Adjusting to this need for requirements and verification with cycles eliminates a separate post-development verification cycle. the iterative workflow must accommodate the need for requirements for each development cycle and parallel verification.
With medical devices, a few simple adjustments enable an effective iterative approach.