Re: [SystemSafety] systemsafety Digest, Vol 44, Issue 26

From: Roderick Chapman < >
Date: Fri, 18 Mar 2016 16:45:43 +0000

On 18/03/2016 11:00, systemsafety-request_at_xxxxxx wrote:
> The only issue with this approach is the cost and the technical
> complexity. A very few organisations are ready to pay that cost.
  I'm not sure what you mean by those points.

What cost? Of tools or training? Do you have any data to support that? What reduction in defect density (and thus downstream cost saving in other verification activities and re-work) is required to justify adoption of a more formal approach?

My experience is that almost no organisations have such data, and therefore can't just justify the RoI argument to change their ways. The default behaviour is "do the same as last time, but promise to be more careful" ... even if "last time" was a horrible mess.

What's "technical complexity" mean? Of what?

I imagine Frama-C suffers from all the same adoption hurdles as SPARK, possibly worse in some areas. For example - Frama-C requires _more_ user-added contracts than SPARK to make up for the deficiencies in C's underlying type system.

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Fri Mar 18 2016 - 17:45:54 CET

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