BUGSENG’s ECLAIR static analyzer could save you its license fee in just one project
You probably know the expression ‘prevention is better than cure’. Nowhere is this truer than in developing safety critical software. We have seen enough accident investigations to know there are no upper limits to the potential costs that errors can incur.
We also know that the early identification of violations of coding rules (such as MISRA or BARR-C) and source code metric thresholds can prevent costly problems later. Effectively such violations are good predictors of the following cost-inflating issues: 1) defects, 2) testing effort, 3) number of future changes, 4) maintenance effort. We’ll look in more detail at all four – starting with the one with the greatest potential for saving time and money: defects.
- Defects
“Finding just one defect early in the life cycle of even a small project could immediately repay the cost of your ECLAIR license.”
The unintended acceleration flaw that affected some Toyota cars cost the company billions in product recalls, litigation fees and brand damage. That might seem like an extreme example but software defects can have major financial impacts on any project: higher project criticalities correspond to higher potential losses. However, you can cut the risk of incurring such costs by identifying and fixing defects early in the software development life cycle – the earlier the better.
Computer Finance Magazine estimates that 35% of all software defects are introduced in the coding phase. Finding and fixing such defects in production can cost six times as much as finding them in the coding phase according to the US National Institutes of Standards and Technology (NIST).
(Image courtesy of NIST)
That estimate may be conservative when you consider that IBM Systems Sciences Institute estimates that late discovery is 15 times as expensive as an early fix.
(Image courtesy of IBM)
The amount you have to pay out in compensation is not the only way defects cost you money. The time cost alone can be substantial. NIST estimates that fixing one defect in the production or manufacturing stage can involve some 15 hours of labor on average, compared with just 5 hours to fix it in the coding phase.
That is why an effective static analysis tool, such as BUGSENG’s ECLAIR, can really help you control project costs and prevent budget overruns. Our customers report that ECLAIR provides an excellent return on investment because it generally helps them find dozens of defects during the coding stage. Bear in mind that finding just one defect early in the life cycle of even a small project could immediately repay the cost of your ECLAIR license.
- Testing effort
Aviation industry experts estimate that software testing may account for as much as 75% of a project’s total costs. When a project violates MISRA guidelines or source code metrics, it is likely to increase the amount of expensive testing required. On top of that, there is the cost of retesting when you have found and resolved defects after the testing phase has already started.
- Number of future changes
Setting aside defects for a moment, think about those companies that create multiple products using common code bases. If your code base violates the MISRA guidelines relating to portability, you will almost certainly have to make more changes to ensure it is suitable for the next product. Those changes will incur repeat testing costs and will also increase the risk of introducing defects.
- Maintenance effort
One final point: it is more difficult to maintain code that violates the MISRA or BARR-C guidelines, or that exceeds the thresholds of source code metrics related to readability and understandability. That’s because every change you make will incur an extra cost due to the added time taken to read and understand the code and due to the higher risk of introducing new defects. This is particularly the case if you find yourself in the undesirable position of being forced to introduce hurried changes after the testing and peer review stages have started.
Effectively, these four issues are all linked and have a compounding effect when it comes to costs and risks. Now you may feel that the MISRA guidelines are overkill for your project. If so, we’d urge you to consider the ECLAIR B package because it supports the BARR-C:2018 guidelines (which have a significant overlap with MISRA C:2012). It also includes support for many source code metrics, the ECLAIR Bug Finder and more.
Of course, ECLAIR B is only the beginning. Many of our customers find that a gentle upgrade to MISRA is the most natural and productive next step. ECLAIR for MISRA is so easy to implement, you will wonder why you didn't use it before!
Take a look at the MC2, MC3 and MP1 packages that cover respectively MISRA C:2004, MISRA C:2012 and MISRA C++:2008.
Have you checked out our new webinar series?
Everyone is welcome to join our webinars. We talk about BARR-C, MISRA compliance, functional safety and so much more. You can browse through the full schedule and register here.
Of course, if you have any questions, please do get in touch.
Roberto Bagnara, PhD is CTO of BUGSENG, a leading provider of solutions and services for static code analysis. He is also a member of the ISO/IEC JTC1/SC22/WG14 - C Standardization Working Group and the MISRA C Working Group.