[SystemSafety] Collected stopgap measures

[Paul Sherwood]

I'm quite enjoying the discussion here, since clearly there are a lot of 
intelligent, opinionated folks in this community and a significant depth 
of experience in safety (which I personally lack).

Interestingly this thread has drifted towards topics that we started 
exploring on the Trustable Software list a couple of years ago. There we 
concluded that trust can only be established with evidence, and that 
we'd prefer to see the evolution of the evidence, including the 
identities of the folks who did the work - not just some end-of-project 
snapshot with an acceptance certificate.

For trust in general, our position (on the rather quieter 
trustable-software list) is that we want to see evidence for all of the 
following:

- functionality
- reliability
- reproducibility
- provenance
- safety
- security
- compliance

We've made some progress on the first four of these, and I landed here 
as part of my journey to understand how best to cope with safety, which 
I now understand to be ** a system property **, not a software property 
(same goes for security).

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.

For safety and security, as I understand it there's no way we could make 
any promises without defining what losses/hazards we aim to address 
(requirements) and then establishing a design (architecture) to 
demonstrate how we intend to achieve our objective.

However, this documentation is often done after the fact (retrofitting 
documentation to existing systems/software), and it seems to me that any 
realistic process or checklist needs to accept that reality.

br
Paul

[1] 
https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software

On 2018-11-02 09:05, Olwen Morgan wrote:
> You know that and I know that. You read standards and I read
> standards. The problem we have is that very few of our colleagues do
> the same.
> 
> I believe in generating ideas and then throwing them into a melee.
> Admittedly, in this case, it's open to all sorts of criticism. I'm
> just floating something to see if we could come up with something that
> might actually find its way into the skull of Joe Lumpenengineer. In
> fact, your email actually states things that could form part of a
> checklist.
> 
> But you're right if you think it smacks of desperation. We are
> confronted in our profession with habitual dysfunctional behaviours.
> 
> How much harm can it do? And that's not a rhetorical question.
> 
> Olwen
> 
> 
> On 01/11/2018 19:56, Steve Tockey wrote:
>> I do think this is a good idea in principle, but I don¹t think it is
>> actually workable in practice. The problem is that unless the 
>> checklists
>> are pretty high-level, e.g.,
>> 
>> *) You need to have documented requirements
>> *) You need to have a documented design
>> *) You need to have controlled source code
>> *) The documented design needs to be consistent with the documented
>> requirements
>> *) The controlled source code needs to be consistent with the 
>> documented
>> design
>> *) . . .
>> 
>> At that high level, all you really end up with is something like 
>> DO-178C.
>> 
>> 
>> On the other hand, if you want to be more prescriptive then decisions 
>> will
>> have to be made about HOW to do certain of the activities. If you want 
>> to
>> document your requirements using a cut-down structured method but I 
>> want
>> to document the requirements using a cut-down OO method then our
>> respective requirements checklists will be very different. So 
>> different,
>> in fact, that one will be useless in the context of the other.
>> 
>> 
>> My two cents,
>> 
>> ‹ steve
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: systemsafety 
>> <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
>> on behalf of Olwen Morgan <olwen at phaedsys.com>
>> Date: Thursday, November 1, 2018 at 8:34 AM
>> To: "systemsafety at lists.techfak.uni-bielefeld.de"
>> <systemsafety at lists.techfak.uni-bielefeld.de>
>> Subject: [SystemSafety] Collected stopgap measures
>> 
>> 
>> One thing that I sense (maybe wrongly?) from recent traffic is that a
>> goodly few of us use our own favourite techniques to help plug the 
>> holes
>> in weak development practices. Cut-down structured and OO methods seem
>> to be a case in point. I'm sure there are others.
>> 
>> Might there be some benefit in gathering here the tricks that many of 
>> us
>> may have used when faced with inadequate processes. Call me
>> simple-minded (many have called me worse) but I'm wondering if there
>> would be value in what might be called a "Software Process Cookbook" 
>> of
>> "Software Process Checklists" for high-integrity developments.
>> 
>> True, I'd prefer something direct, technical and possibly rather dry 
>> but
>> I'm thinking here about an appealing format. I'm wondering if 
>> something
>> like a cookbook or "for Dummies" format would appeal to people who 
>> would
>> otherwise never go near the sources that they need to be accessing to
>> help them do the job better.
>> 
>> 
>> Just a thought,
>> 
>> Olwen
>> 
>> 
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
>> Manage your subscription:
>> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
>> 
>> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription:
> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety