PROCESS & COMPLIANCE
Everything we do is based on an iterative approach. We understand the V-Model as a documentation model, rather than a process model. Our process model allows backsliding, as well as an iterative and incremental development.
Our lean software development process
We follow a development process that allows us to promote the development of a software that is:
- developed in a short and predictable time
- secure and achieves the specified quality criteria
- compliant with regulatory requirements (in particular IEC 62304)
- avoids unnecessary iterations, improvements and coordination efforts.
Our Software Development process is based on a phases approach. Each of the phases needs to be finished with a defined output which is a prerequisite to start the next phase. The phases are defined as follows:
I Project Initialization – We create a project development plan which includes the intended use, the assigned team members, a milestone plan with due dates and results, references to code guidelines, deviations from the standard configuration management and the feedback and defect tracking process. Stakeholder requirements are defined and the prototype is fully designed and estimated. Project costs get approved.
1 Prototype – While the first spike is taking place to have first prototyping results the software requirements, architecture and detail designs are written. For software requirements we follow the black box approach. First input to the risk analysis is generated.
2 Development – We have understood that the agile development should not be abused, to compensate for incompetence in meeting the requirements. Likewise, we are convinced that the architecture should be produced as “upfront” as possible. Also to take into account the prohibition of IEC 62304 of “adhoc design decisions”. With this understanding we have actively chosen to follow an iterative approach.
3 Verification – Based on the executable code and the software requirement specifications we plan the software system tests, perform the software system tests and verify the usability. We do functional and robustness, i.e. fault based, testing.
4 Validation – The validation of standalone software is mainly the validation of usability. The validation of algorithms (if necessary at all) is done for medical devices within the framework of a clinical evaluation. We carry out the planning, implementation and documentation of validation of usability.
5 Market Introduction & Maintenance – Remaining anomalies are evaluated. All documentation gets cross-checked. Traceability matrices are updated. If required CE mark / FDA Submission tasks are triggered. After market introduction we collect and analyze data from multiple SOP defined sources and plan whether and which changes to the software should be implemented in the next release.
6 Market Removal – Costumer communication is prepared and sent. System gets phased out.
Our technical documentation is stored in a generalized format. This makes sure that we can fulfill the requirements of IEC 62304 as well as for a FDA submission.