By Jonathan Bagot B.C.Sc.
No matter what type of software you’re developing, chances are that you will be asked to make some changes over the software development life-cycle. Change can be problematic when you are dealing with critical code that requires extensive Verification &Validation. You need to be confident that any change has not affected your critical code.
There are some measures that you can take in order to combat against change affecting the performance of your critical code.
The following is a list of guidelines in no particular order:
1. Place your critical code in areas that are never changed or changed infrequently.
2. Use your version control tools to prevent accidental change. For example making critical code files read only requires a developer to make a conscious decision to change them.
3. Centralize your critical code. Do NOT have multiple implementations of your critical code that are used interchangeably.
4. Build redundancy into your software. If possible design and implement independent code that can check the results of your critical code. Use the independent code to trap errors in real-time. The independent code should also be considered critical code. Follow these same guidelines for changes to the independent code.
Examples of software redundancy:
a) Perform a consensus check. Calculate a value twice independently then compare the results.
b) Back calculate the output. Given the output determine what the input was then compare to the actual input.
5. Understand the expected inputs and outputs of your critical code. If there are simple rules that can trap unexpected inputs and outputs, then incorporate them as sanity checks in your software. Just as there are no dumb questions, these rules can never be too trivial.
6. Use Occam’s Razor when developing critical code. “It is vain to do with more what can be done with fewer”. Chances are multiple peers will need to review the critical code. They will thank you.
7. Build audit trails into your software for the inputs and outputs of critical code. You may need to review the audit trail one day.
8. Design your critical code to be unit testable. Unit test your critical code every build. These tests can easily be automated with your build process.
9. If possible make your critical code deterministic. For example if there are two correct answers, always give the same correct answer. Deterministic results also lend to unit testing as described in guideline #8.
10. When changes to the critical code are absolutely necessary. Review the proposed changes, mitigate any risk, review the actual changes, and finally make an informed decision as to what level of regression testing is required.
These simple guidelines can be applied to any critical code whether they pertain to numerical calculations, control logic, business logic, etc. The first step is identifying what is critical to your application.
Jonathan Bagot is a Software Lead at Intelligent Hospital Systems, designer and manufacturer of RIVA a Fully Automated IV Compounding System