Welcome back to our blog series on Controlled Software Development for medical devices! In our last post, we looked at the significant Input phases of software development; this post, we’ll start to look at the first wave of Outputs – beginning with Architecture and Design documents, then moving to Implementation and successive Testing activities.
Architecture and Detailed Design
There are many different architectural approaches for designing a software system. Examples include data-driven, event-based, rules-based, state-based, service-oriented, and more. Parsing out which to use for a given project is beyond the scope of this series; from a controlled-development perspective, what’s most important is that your architecture and detailed design documents be directly traceable back up to the requirements and risk documents you produced during the input phases.
To this end, it’s helpful to design a numbering system that can maintain continuity between these documents. If your numbering convention includes a 1:1 component, it creates high visibility from designed modules back to requirements, enabling rapid confirmation that every requirement is covered by appropriate software elements, and every software element has been analyzed for risk and appropriately mitigated.
Implementation
At this point in the software development process, actual coding begins. The coding platform(s) your developers will use was determined as a part of the requirements and risk management phases, and functional units were identified in detailed design. Thanks to your robust configuration management system, different functional units can be worked on in parallel by different teams or individuals at this point.
It is important to note that there should be regular risk review meetings during this phase in order to keep risk management forefront throughout.
Code Reviews, Static Analysis, & Unit Testing
Each part of the code should be tested as it is written. It is critical – especially in large, complex systems – to make sure it is possible to exercise individual units as thoroughly as possible. This may require creating a simulated system that can interact with the code or even a physical test apparatus. Test needs will be determined both by software design and risk management and will have been previously documented as a subsection of the system Testing Plan (not covered in this series).
Unit testing is a formal discipline. There should be documentation that shows the planned test procedure, date tested, personnel who performed the test, and results of the test. Unit tests should be traceable back to design and requirements documents to prove complete coverage of the requirements with tested software. In addition, there should be documented proof that unit test personnel were adequately trained and capable of conducting unit testing.
To learn more about Code Reviews and software Testing, refer to our blog series on Static and Dynamic Analysis. We also have a free white paper available to download, as well as configuration instructions and a plug-in kit for our preferred Unit Testing tool, Parasoft.
Integration Testing
As individual units pass testing, move to test them as integrated units. You’ve proven that these units function as expected in isolation; now, you are systematically integrating and testing them to verify that they work as expected in combination with one another. Throughout this process, your Test Plan will require that you repeatedly ask “what could possibly go wrong” with each unit integration and ensures that you have devised reliable means to check.
Micro Penetration Testing
Penetration testing systematically attacks your system under controlled conditions mimicking anticipated use cases and environments to identify cybersecurity vulnerabilities. Traditionally, this is performed at the end of the development lifecycle, just prior to or concurrent with verification and validation testing. However, this practice produces a report too late in the development lifecycle to fix many vulnerabilities cost-effectively. Although it does provide the information needed for FDA and intentional regulations, it does not do it in a timely fashion optimized for most software development companies’ business models.
Velentium has successfully pioneered an alternative approach, dubbed “micro penetration testing,” which scopes cybersecurity test activities to particular areas of the overall system and performs them concurrent with implementation. With this approach, reports generated can be fed back immediately into designing and implementing cybersecurity mitigations before they become expensive to address.
In our final series installment, we’ll look at the final testing and documentation that has to take place before your medical device software is ready for regulatory review. If you’d rather not wait, click here to download our free white paper!
