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

[paul_e.bennett at topmail.co.uk]

On 01/03/2016 at 10:50 AM, "Les Chambers" <les at chambers.com.au> wrote:

[%X]

>PBL:That might be why Fagan inspections are such a good idea.
>
>Les: If a software mess gets as far as Fagan inspection it's too 
>late. You
>cannot inspect quality into software. Mandating state engines is a 
>proactive
>measure that almost always assures the quality of software before 
>it gets
>anywhere near an inspector. Further, the modern automobile has 
>millions of
>lines of code. Do you honestly believe that even a minute subset 
>of that
>code is inspected in any way shape or form. It's too expensive and 
>it's not
>done. 

Whilst it is true that quality or safety cannot be inspected into a product
the Fagan Inspections can and do prevent bad code going further so
long as the process can keep the bad code from passing by.

Having adopted a "Component Oriented Approach" to the development
of hardware and software (one process for all aspects) I find that a 
decent standards for documentation, coding and hardware practices is
easy to enforce by such rigorous inspections. You cannot inspect without
having a standard reference against which comparison can be made.

>PBL: People developing the highest quality software are keen on 
>assuring
>determinism and like to use the word "unambiguous", 
>
>Les: I spent a decade of my career working with the state engine 
>on a daily
>basis in chemical processing reactor control. I never heard the 
>word
>unambiguous uttered. It was not in our vocabulary. We didn't need 
>to
>consider it. What we were doing was deterministic by design. There 
>were no
>useless debates about an ambiguity or the lack of. For this reason 
>we are
>able to spend more time concentrating on our work which was highly
>deterministic and highly safe.

I work with a language standard that happily declares that some aspects
will be ambiguous and the coder will need to be aware of some deeper 
implementation detail if they want clarity about what will happen in those
circumstances.

>Les: going back to your comment: "standards don't mandate." This 
>is a
>transparently untrue statement for a communications protocol 
>standard, which
>if not followed to the letter will destroy interoperability of 
>systems. My
>point is that this discipline must also be applied to well known 
>and highly
>effective development models and practices to the point where they 
>can be
>validated. It's 2016 and we are still sweating the small stuff - 
>arguing the
>point over ambiguity, when we should be solidifying the basis on 
>which we
>build systems so we can deal more effectively with the massive 
>problems of
>largeness that we all face.

Standards are more than those at the international level. I would 
hope that individual companies have their own internal standards 
that will mandate how things get done.

In the "Component Oriented Approach" the component surfaces 
are the only interfaces that can be utilised for information or effort
transfer between components. Having a unified Development 
process that works across all engineering disciplines helps 
everyone understand where things are in the project. Combining
a simple but robust development process with a triple-repository
information management system that keeps all project 
documentation available at the appropriate status.

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