[SystemSafety] Collected stopgap measures

Fri Nov 2 10:58:22 CET 2018

Hi all,

I've had (very) bad experiences with "agile" people trying to make safety software. In each case, I had to re-train them completely or discard their work, since they would not provide the safety evidence required to demonstrate the safety of their software, and it was blindingly easy to find defects in so-called validated software that the value of their whole process was shown as nil, from the point of view of safety. "Standard" agile people don’t know how to write requirements, and they don’t know how to architect a system for durability, they introduce a large technical debt which leads to huge maintenance costs, and in the end, they don't how to test for safety, and from beginning to end, they don't know how to produce evidence as part of their daily work. Sadly. No other engineering discipline works like that. In fact, standard agile is not engineering at all, it is the opposite of engineering.

Also, there was a time in a my life when I was producing high-reliability software and systems, not necessarily safety software, and my teams were in competition with "Agile" teams. We were beaten on price on first delivery, although we were able to compete on schedule. No Agile team was ever able to beat my teams on a firm-fixed price project with 3 to 5 years warrantee, either on price or on schedule, after the first run. We kept the customers who understood what that meant. And we gained the customers that were "burnt" by the "Agile" teams the second time around. Making good requirements is a job, following up into design, into writing sources, and good test plans are also a job. We did that with a streamlined and (semi-)automated software factory that worked quite well. One element in it, that other people have commented elsewhere, is the value of well-done reviews performed at the different stages of development. Another element is that our sources were not implementation-like sources, but design-level sources, using the higher abstraction and higher readability languages I have mentioned earlier. Basically, we discarded one phase of the software development : implementation and went directly from detailed design to integration and testing. That reduces a huge amount of work, to implement, to remove defects, and even a lot of unit testing, even if it is automated.

Making documentation after the fact is very onerous, and less competitive than having a streamlined and automated software factory that is designed for producing high reliability software from the beginning.

On the other hand, I've had no problems using Agile-like processes for making discardable prototypes, if the need arose to clarify requirements, check performance, validate architecture, design GUI's or whatever else was missing to complete the project.

Best regards,
Thierry Coq
DNV GL
+33 (0)6 80 44 57 92

-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de> On Behalf Of Paul Sherwood
Sent: Friday, November 2, 2018 10:30 AM
To: Olwen Morgan <olwen at phaedsys.com>
Cc: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Collected stopgap measures

>>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).
...
>>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
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************