[SystemSafety] Collected stopgap measures
Paul Sherwood
paul.sherwood at codethink.co.uk
Fri Nov 16 07:05:06 CET 2018
On 2018-11-15 18:57, Matthew Squair wrote:
> 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.
I enjoy debate as much as the next person, but mainly I'm trying to get
to actual engineering.
> You start with high level software requirements (the software
> specification) and for greater assurance you add in low level
> requirements (the software design document).
If that's the chosen management method, fine.
> 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.
Agreed.
Any reasonable diligence on software shows that
pre-specifying/architecting is a minority sport. The drill-downs I've
done personally lead me to conclude that in many of the cases where
folks claim that they applied this approach, the evidence doesn't stack
up. Often the documents are retrofitted.
I'm not suggesting that folks who insist here that they get spec, and
arch, and software, right first time (in that order) are lying. However
I do think they are in a small minority.
> To do that defensibly we
> need to provide objective evidence and that evidence has traditionally
> been in the form of documentation.
Yup - if someone claims 'safety' or 'security' they need (documented)
evidence of what they are safe/secure against, and how that
safety/security is (supposed to be) achieved.
I just think that this documentation can be (and often is) created while
(or after) the software part of the system is created. I'm not alone,
since many safety folks seem happy to bless the idea of software as
'safety element out of context'.
> 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.
This is new to me... what's the value of "chain of custody from system
specification to source code"?
Are you saying that the system spec has to lead to the existence of
source code somehow?
> 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.
That's not the kind of situation we are considering, I thought?
Let's keep focusing on 'system safety'... I remain hopeful that I could
(as duty-holder) put my signature on (say) a Linux-based system, with
appropriate documentation about the losees/hazards/risks, and the
expected/demanded behaviours for the Linux kernel in context.
This hope is inspired in part by the knowledge that others have already
deployed Linux-based software in safety-critical systems, and in part by
my perception of the futility of starting from scratch to re-implement
Linux-equivalent functionality and performance by constructing new
software from scratch, to a new architecture and based a new set of
requirements.
More information about the systemsafety
mailing list