Re: [SystemSafety] Qualifying SW as "proven in use" [Measuring Software]

From: David Crocker < >
Date: Mon, 01 Jul 2013 20:45:56 +0200

I've been following this thread with interest. Two points:
  1. Implementing a piece of functionality with a complex specification (whether or not there is a good specification to start with) will naturally tend to result in functions with high cycolomatic complexity. The implementation of complex functionally is also I believe more likely to be incorrect. So there is probably a correlation between cyclomatic complexity and bug density. In which case, cyclomatic complexity may serve as an indicator on where to focus code review and similar activities. If such a focus results in a clearer and simpler specification being implemented, then the metric has proved its worth. OTOH if it merely results in the code being refactored into several smaller functions to satisfy some coding standard, is that likely to reduce the number of errors?
  2. Commercial application development is very different from safety-critical software development. I have worked in both. In typical application development, shipping the product late is far more expensive than shipping it with a significant number of minor bugs. Users expect new releases to contain bugs, and customer satisfaction experts will tell you that how well you respond to a complaint often matters more than how well your product performs in the first instance. So shipping a product that contains bugs and then issuing patches speedily when the customer complains may result on greater customer satisfaction than shipping a bug-free product in the first place.

What this means is that the sort of programmers who are great at writing a new commercial application and gaining first mover advantage have completely the wrong personality for writing safety critical software. These are two different jobs, requiring two different skill sets. It's like the difference between an artist (who may draw a beautiful structure that is unsound from an engineering viewpoint) and and engineer (who by himself produces something that is cumbersome and perhaps ugly but sound). The best commercial apps are produced by teams that have both sorts of developers.

Regards - David (sent from mobile)


"most systems that use any COTS would be ruled out of safety-related applications."

As well they should be. If my safety depended on the quality of the software produced in Redmond, I'd be running in the opposite direction.

"We can't become an engineering profession in one step - but I'd like us to be clearly starting the journey."

I completely agree that it can't happen in one step. But maybe people aren't aware of how much work has already been done. The journey has started, IMHO.

From: Martyn Thomas <martyn_at_xxxxxx Reply-To: "martyn_at_xxxxxx Date: Monday, July 1, 2013 10:21 AM
Cc: "systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Qualifying SW as "proven in use" [Measuring Software]

I agree. And I'd like to see COTS software supplied with a statement of complexity, against some standardised metric.

But it's a huge change you are asking for: most systems that use any COTS would be ruled out of safety-related applications.

We can't become an engineering profession in one step - but I'd like us to be clearly starting the journey.


On 01/07/2013 18:16, Steve Tockey wrote:

My preference would be that things like low cyclomatic complexity be considered basic standards of professional practice, well before one even started talking about a safety case. Software with ridiculous complexities shouldn't even be allowed to start making a safety case in the first place.

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon Jul 01 2013 - 20:48:58 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:05 CEST