[SystemSafety] Collected stopgap measures

[Paul Sherwood]

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.