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

[Les Chambers]

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-----
From: paul_e.bennett at topmail.co.uk [mailto:paul_e.bennett at topmail.co.uk] 
Sent: Thursday, March 17, 2016 3:07 PM
To: Les Chambers; 'Steve Tockey'; 'Derek M Jones'; systemsafety at lists.techfak.uni-bielefeld.de
Subject: RE: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

On 17/03/2016 at 1:23 AM, "Les Chambers" <les at chambers.com.au> wrote:
>
>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://Paul_E.Bennett@topmail.co.uk>
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..
********************************************************************