Tuesday, April 14th, 2015 by Christian Johner
We understand the term code review as the checking of the non-compiled source code by other people, for example in the context of inspections or walkthroughs.
Regulatory requirements for code reviews
The IEC 62304 does not require explicit code reviews. But it does see code reviews as a way to test software units. However, written test criteria for code reviews must be available and the code review should be documented in writing as well.
The FDA does not require code reviews, but writes the following in the Software Validation Guidance Document:
Source code should also be evaluated to verify its compliance with the corresponding detailed design specification. […] Source code evaluations are often implemented as code inspections and code walkthroughs. Such static analyses provide a very effective means to detect errors before execution of the code. They allow for examination of each error in isolation and can also help in focusing later dynamic testing of the software. […] Source code evaluations should be extended to verification of internal linkages between modules and layers (horizontal and vertical interfaces), and compliance with their design specifications. Documentation of the procedures used and the results of source code evaluations should be maintained as part of design verification.
Whoever develops software for medical devices without having code reviews carried out, should be asking whether he/she is in the correct industry and if software development is right for him/her. Renouncing code reviews has nothing to do with professional programming.
Tips for practical implementation
General rules for code reviews
One of the most important ways to have a significant breakdown in the error rate within my team was with code reviews. In fact, it was consistent with all the code. But that only works if you do it properly and comply to a few rules:
- A code review should not take longer than 30 minutes.
- A code review should examine the code based on predetermined and possibly programming-specific criteria, including compliance with previously (automatically) determined metrics and coding guidelines.
- A code review should take into account the test code (including code coverage).
- A code review should be documented. More on that in a moment.
- A code review can also be performed in reverse. More on that in a moment.
Reverse Code Review
During the reverse code review, the author does not explain his code to his reviewer, but vice versa. The reviewer explains what he believes he understands. This has great advantages:
- The reviewer is focused, because he has to explain the code to the author.
- The author is soon tired of the alleged slowness of the reviewer and writes code in the future that even the reviewer will understand. This leads to an understandable and maintainable code.
- The boss can be sure that there is a second person who also understands the code. This reduces dependence on a developer.
Four eyes see more than two. You should also do code reviews. It’s best to do them in reverse!
Documentation of code reviews
Document all code reviews but make it very concise. Either use a tool like TFS or MedPack or if you have a form (a sheet with front and back-side), which is included on every desk or in a drawer of every developer. During the review, the reviewer fills out the form. Once a week the developer throws the completed forms in the tray of the quality manager. Done. The overhead for the formalities should be in the range of a few seconds!
Checklists for code reviews
Code Reviews: Does the FDA require a signature? From whom?
"Who needs to sign a code review, according to the FDA? Only one person, for example, the reviewer, or the moderator, or everyone involved, so the developer, reviewer and moderator?
To answer this question, we must briefly highlight the concept of code review: There is no such thing as "the" code review, but a lot of different methods of static testing of the source code. For example
- the walkthrough,
- the technical review,
- informal review and
- the inspection.
The FDA notes these processes partially in the software validation guide, without explicitly demanding one of them. The methods also differ by the people who are to be involved. A moderator does not exist, for example, at an informal review.
The statutory requirement for reviews can be found in 21 CFR part 820. Here, too, no specific method is named.
This, then, gives us the answer: You describe, as a manufacturer, in your 820-compliant quality management system, what kind of reviews you will make. And according to that, you need to document what people are involved - by signature.