[SystemSafety] systemsafety Digest, Vol 44, Issue 26

[Roderick Chapman]

On 18/03/2016 11:00, systemsafety-request at lists.techfak.uni-bielefeld.de 
wrote:
> The only issue with this approach is the cost and the technical
> complexity. A very few organisations are ready to pay that cost.
David,
  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.

  - Rod