[SystemSafety] Collected stopgap measures

Fri Nov 16 13:50:58 CET 2018

Nick Tudor wrote:

“The issue seems to be the pressure to get something apparently 'working' asap, which drives the inevitable behaviour of software teams ( i hope this is not new to most).”

That is certainly part of it, but it is also not all of it.

“So the trick is do to something that, from an engineering perspective is sound, but makes the commercial case.  If I can show that an approach saves time (which apparently equals money), then the software engineer has no excuse to not use that approach.”

See my previous email:
*) The software gets delivered in about half the time as normally expected for that scope of functionality
*) The cost of delivering the software is also cut in about half
*) The users encounter no more than one tenth of the number of defects they would normally encounter, usually even less
*) The long-term maintenance costs of the software drop by somewhere between a factor of 4 and a factor of 8

These results are consistent back to the 1980’s. So in spite of the fact that it has been demonstrated on numerous of projects that an engineering approach is superior, the “highly paid amateur” approach still dominates.

I would claim that there is also a huge cultural component. The biggest excuse I keep hearing is, “But that’s not the way we’ve always done it”.

— steve

From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>> on behalf of Nick Tudor <njt at tudorassoc.com<mailto:njt at tudorassoc.com>>
Date: Friday, November 16, 2018 at 3:56 AM
To: Martyn Thomas <martyn at thomas-associates.co.uk<mailto:martyn at thomas-associates.co.uk>>
Cc: The System Safety List <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: Re: [SystemSafety] Collected stopgap measures

Neat summary Martyn.

I have been working this for a few years now and getting close to a solution (note: 'a' solution; there will be others).

The issue seems to be the pressure to get something apparently 'working' asap, which drives the inevitable behaviour of software teams ( i hope this is not new to most).  So the commercial case is what it's all about rather than the engineering case.  Many of the threads recently have expressed frustration about why the great and good have not been listened to and we still have rubbish (...unsafe...?...insecure...?...late?....costly?...pick your favourite!...) software; and IMO it's because of the commercial case.  So the trick is do to something that, from an engineering perspective is sound, but makes the commercial case.  If I can show that an approach saves time (which apparently equals money), then the software engineer has no excuse to not use that approach.  This is and will remain a very hard case to sell initially as everyone points to the lack of track record.  Once that inertia is overcome, then....

As I said, ...working on it...

Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com<http://www.tudorassoc.com>
[http://www.tudorassoc.com/wpimages/wpb4e71a5c_0f.jpg]

77 Barnards Green Road
Malvern
Worcestershire
WR14 3LR
Company No. 07642673
VAT No:116495996

www.aeronautique-associates.com<http://www.aeronautique-associates.com>

On Fri, 16 Nov 2018 at 10:27, Martyn Thomas <martyn at thomas-associates.co.uk<mailto:martyn at thomas-associates.co.uk>> wrote:

I think this discussion is missing the point.

To summarise: Paul Sherwood observed that most successful software lacked the basic requirements of a professional engineering design process, specifically documented requirements or documented design. He also said that in his opinion this was not the right way to develop software, especially for safety functions. He further observed that some safety-related software incorporates components that lack documented requirements or documented design. I agree with these statements.

I interpreted Paul's emails as a request for help because he would like to be able to argue for better software engineering but finds himself frustrated by a software industry that mostly does not use rigorous engineering and gets away with it.

In response he received a measure of abuse and quotations from international standards that are known to be flawed, rather than a reasoned discussion of the issues that he had raised.

I would like the discussion to focus on what we might be able to do to radically improve software engineering standards across industry, when those companies that do follow a professional engineering design process find themselves regularly underbid by less professional competitors who rely on being able to persuade the customer to extend the project budgets and timescales when the absence of documented, complete and consistent requirements make that necessary.

Martyn

On 16/11/2018 08:41, Peter Bernard Ladkin wrote:

I have just come back from a meeting of the 61508 MTs in Grenoble and this feels to me like a
parallel universe.

On 2018-11-16 02:42 , Paul Sherwood wrote:

-----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.

IEC 61508 and (as far as I am aware) ISO 26262 require there to be a software safety requirements
specification. In IEC 61508 there is a whole subclause, 7.2, specifying it, which is 3.5pp long.

So are we talking about so-called "safety" applications which, through some magic, do not have to
conform to applicable safety standards? Or are we talking cowboy developers who claim they are
producing software for "safety" applications but in fact aren't?

The people who commission, install and operate safety-related systems in any sector except medical,
automotive and aerospace do not, as far as I am aware, commission software from companies which are
not able to produce conformance documentation.

So where are all these software engineers producing software for safety applications who don't
produce documentation?

I can all but guarantee they are not producing software for market-leading safety-related systems
developers and integrators, because all of those of which I am aware require adherence to the
applicable safety standards, otherwise one accident and the lawyers will force them to close up shop
(and in the UK the Board would have to work hard to stay out of jail).

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.

No it is evidently not. It is enough to justify the statement that relatively reliable software has
been developed for some applications without documented requirements or documented design. It does
not follow from that that all software for all applications can be developed without.... The fact
that I don't need a map to travel around Bielefeld doesn't mean I don't need maps for other places.

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.

I can't parse the first sentence, but you are right that a risk analysis is required, and safety
requirements based on this risk analysis must be formulated, and the software design must be
accompanied by documentation showing how the software safety requirements are met. None of these are
"system properties etc etc". They are documentation.

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."

It is not at all clear what you mean here by "expert safety folks". Lots of people want to talk
about E/E/PE system safety, but that doesn't mean they are expert. I have found a handy rule of
thumb is to ask a question involving "E/E/PE" to see if they know what it means.

I once saw an advertisement for a conference on safety of software, with some moderately well-known
computer-science theoreticians on the program committee - and not a single person recognised in the
"safety community". So I mailed one of these distinguished people to ask how come she could help
organise a conference on safety without a safety expert? What would they be discussing? She evaded
the question, referring me to the committee chairman. I imagine it was another bunch of people
wanting to talk to each other about reliability of such systems - the usual confusion. (Not that it
is at all bad to talk about reliability!)

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de<http://www.rvs-bi.de>

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto: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<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181116/e7a9fdce/attachment.html>