[SystemSafety] Collected stopgap measures
Matthew Squair
mattsquair at gmail.com
Fri Nov 16 03:57:18 CET 2018
A version of this argument is the great debate about the need for what are called Low level Requirements for the higher assurance levels in DO-178. You start with high level software requirements (the software specification) and for greater assurance you add in low level requirements (the software design document).
One answer as to why we need specifications is not that they're needed to develop a software product but because we need to demonstrate to a third party that we have been duly diligent. To do that defensibly we need to provide objective evidence and that evidence has traditionally been in the form of documentation. So no you don’t ‘necessarily’ need a software specification to develop a software product but to convince a regulator that you haven’t broken the chain of custody from system specification to source code* you’ll need to bring evidence. And as we know strong claims demand strong evidence. Conversely if the only person I really have to convince that my sprint is good is the team lead, well the burden of proof is going to be much lower*. Not so strong claims require less evidence as a corollary.
*Remember the Mars Polar Lander!
**As much because the team lead is that much closer to the design artefact.
> On 16 Nov 2018, at 12:42 pm, Paul Sherwood <paul.sherwood at codethink.co.uk> wrote:
>
> On 2018-11-15 10:22, Chris Hills wrote:
>> I have been reading Bruce Schneier's new work "Click Here to kill
>> everybody" on cyber security in the current state of computing.
>> He is even more despondent than the safety industry about attitudes
>> like this below.
>
> I'm despondent too...
>
>>> -----Original Message-----
>>> > For the software only properties, it's obvious that we DO NOT need documented requirements, or documented design. Software is often (almost
>>> always, these days, in agileworld?) successfully evolved and consumed without either of these.
>
> ... but I still stand by this statement.
>
> Once more unto the breach...
>
> AFAIK there were never any a-priori requirements or architecture for:
>
> - linux kernel
> - openssh
> - gcc
> - llvm
> - python
>
> ... or most of the software that Google runs internally (i'm sure others can provide many additional examples).
>
> The fact that such software exists and is widely relied upon and trusted is enough to justify the statement.
>
> I didn't (and don't) claim that software is generally **better** done this way.
>
> I can't see how anyone could claim to have engineered a system for safety or security without stating what losses/hazards/threats that aim to address (requirements) and how the solution is supposed to be achieved (architecture). But these are system properties etc etc.
>
>> Whereas most safety related systems have been done to rigorous
>> standards, and some recognisable security systems too, he suggests
>> that most software is so badly constructed with lack of requirements,
>> design and rigour the world seems happy to accept substandard software
>> as the norm. This means that almost any system with software in it is
>> insecure. If it is not in itself insecure then is it connected to at
>> least one very weak and insecure link.
>
> Sadly, but unavoidably, true.
>
> And yet I keep on encountering supposedly expert safety folks who are happy to claim things like "with this 'safe' hypervisor you can run untrusted code in an internet-facing guest alongside safety critical functions."
>
>> His view seems to be that we should, rather than moving to less
>> documentation, design etc, move all software towards aircraft
>> standards! Capers Jones book on the Economics of Software Quality
>> shows that it is cost effective to engineer software properly.
>> It is NOT obvious that we do not need documented requirements or
>> designs but in fact the opposite is true.
>
> I'm going to continue to disagree, because there is so much trusted software in the world which has arisen without these artifacts.
>
>> What IS obvious is that we need to move software from "coding" to
>> Engineering and improve standards and working practices greatly.
>
> I agree with that.
>
> br
> Paul
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
More information about the systemsafety
mailing list