Compliance is the common thread that runs through this whole Playbook, but there are a few specific areas that are worthy of deeper explanation.
Software Development Lifecycle (SDLC)
We follow a bespoke SDLC, which we’ve created to meet the needs of building a brand new SaMD product:
Traceability
Traceability is a good thing—having full documentation of how a product is intended to function, alongside the evidence that it does indeed perform in that manner, is something that would improve the quality of the majority of complex software, even outside healthcare.
But we’ve found that it is often implemented in a way which causes great frustration for all involved, burying everyone in a mountain of messy paperwork, which is hard to understand and maintain and provides little value. This makes it difficult to adopt an effective agile process and improve the product over time.
It doesn’t have to be that way. As with our SDLC, we’ve found ways to integrate traceability into our process in a way that makes it easy for us to keep specifications, documentation and tests current as the product evolves, while remaining compatible with an agile process.
Here’s how that looks as it flows through the product:
- Design Inputs are determined and documented in collaboration with the client’s human factors and safety teams. These are stored in Jira.
- Requirements are created, to translate the Design Inputs into functional needs. These act as written specifications, documenting how the product should behave. They’re the primary source of truth on the project and also exist in Jira, linked back to the Design Inputs. Each time functionality changes, the Requirements will be updated. Developers critique the Requirements as they implement them, allowing us to fine-tune them and ensure they accurately reflect the functionality we’re building.
- Tests are drafted by developers as they build out functionality. While unit tests and static analysis are tracked, we don’t consider these to be a traceable output as they are not directly connected to Requirements. Instead we write end-to-end tests (both automated and manual), which are imported into Jira and linked back to Requirements. This ensures that every Requirement is covered by at least one end-to-end test. These form a Test Plan, which can be exported as a PDF to create a permanent record for each release.
- Test Executions for each test are automatically recorded for every release that is produced. These contain the execution status, along with the environment (and app version/release). They’re imported into Jira.
Since each of these elements is directly linked to the one which precedes it (either in the code itself, or via software tools such as Jira and Xray), we are able to generate an accurate Traceability Matrix for every release version of the product. This is reviewed and signed off prior to the release being distributed.
This not only allows us to track our progress as we build the product (i.e. “60% of Requirements are currently implemented”), but also enables each release to be confidently distributed with significantly reduced V&V effort.