Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

From: Les Chambers < >
Date: Fri, 18 Mar 2016 11:04:53 +1000


Paul

RE:
>>2. The authors seem to have no concept of backward compatibility.
>>If you make the mistake of upgrading to the latest version you can
>>trash your complete application: data structure changes, even method
>>name changes. Amazing!#

>Regression testing is part of the regimen and any new version has to pass all the old tests as well as any new ones. >There is a strict notion of how much impact changes at lower levels will have on the upper layers of the application. >I'll happily explain about surfaces to you at some stage.

Thanks for the offer but I'm fully across the concept having been involved in many testing scenarios. The point I was making is that there are people out there who should know better offering software libraries who don't respect this fundamental precept of "good" software product evolution. A friend of mine recently had a similar experience with a development framework that took him a long time to understand. He then committed his entire development environment to it. A new/better version was released. When he attempted to upgrade it destroyed his environment and wasted many hours of his time. The developer in an attempt to be "cool" did a major rethink – remember that word "major rethink" , it's a red flag. What bothers me is: who are these people? where did they get their education? do they have any education other than the school of "cool". They may have been to an agile course. It's a worry.

Les

-----Original Message-----
Sent: Thursday, March 17, 2016 3:07 PM
Subject: RE: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"


>
>Paul
>Please do write the book.

Thanks Les, I shall, based on that encouragements, make sure I do write it. I have some articles and other scraps of writing around that will provide a basis for the work.

> Whether we like it or not we are all
>involved in component based design. My experience with software
>libraries is that there are some good ones out there that are
>quite stable. On the negative side I have two problems with them:
>1. They are almost universally very poorly documented so you can
>waste a day trying to achieve a trivial outcome.

I agree that many examples of software components I have seen have lacked sufficient documentation to be able to make sensible decisions about suitability. I find that if you can chuck it back via the author to get that improved, the documentation improvement is sometimes worthwhile. Otherwise you end up writing it yourself.

>2. The authors seem to have no concept of backward compatibility.
>If you make the mistake of upgrading to the latest version you can
>trash your complete application: data structure changes, even
>method name changes. Amazing!#

Regression testing is part of the regimen and any new version has to pass all the old tests as well as any new ones. There is a strict notion of how much impact changes at lower levels will have on the upper layers of the application. I'll happily explain about surfaces to you at some stage.

>All in all though we are joined at the hip with these things
>because writing from scratch is just not an option. ... Which
>raises huge problems with safety and security critical systems ...

I have a box of (software) components that I tend to use as my starting base. They have all been through the mill a number of times and I know I can trust them (they are all quite simple components just hooked up a specific way). It provides me with a good stable basis that I could push through an integrity review in a couple of weeks.

>How do you validate product that seems to work but has no
>documentation to validate against.

You cannot. The certification should be of the form that states

"I certify that the component "XYZ" has been inspected, tested and found to satisfy the full specification in it's data-sheet within the limitations thereto described".

That is essentially what a Certificate of Conformity implies when you apply it to hardware and it should be no less the case for software.

> I guess if you're automating a
>nuclear reactor the only place to be is at scratch.

The Nuclear Inspectorate are a quite conservative group of people and you have to make a very good case to them before they will accept newer notions. Think technology that has been in mainstream use for at least a decade and they may think that it is still too new to try. It is getting a bit easier now but slowly.

Regards

Paul E. Bennett IEng MIET
Systems Engineer

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email: >
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************



_______________________________________________
The System Safety Mailing List
systemsafety_at_xxxxxx
Received on Fri Mar 18 2016 - 02:05:21 CET

This archive was generated by hypermail 2.3.0 : Thu Apr 25 2019 - 13:17:08 CEST