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

Tue Mar 1 15:26:16 CET 2016

We've drifted well off the original topic by now. Nonetheless:

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.

Steve: Inspecting code is better than nothing, but not by much. James
Martin says that in a typical software project defect tracking system, 56%
of the defects are caused by bad requirements, 27% are caused by bad
design, and only 7% are really problems with only the code itself. The
remaining 10% are defects logged against test cases, plans, etc. Said
another way,

83% of defects exist before code is written.

I've found inspections of requirements (models) and design (models) to be
far more efficient and effective than code inspections. In several
projects we started with an "inspect everything" philosophy and always
ended up abandoning code inspections quite early because they weren't
worth the trouble. So many of the defects were already inspected out in
requirements and design inspections that there weren't enough to worry
about. The kinds of defects remaining in the code were the kind that were
hard to find by inspection, anyway. They were things that were much better
found by testing.

Bob Grady at HP said his data showed that testing tends to find defects
difficult to find in inspections, and inspections tend to find defects
difficult to find in testing. This is exactly my experience.

The moral of the story is that if the only thing being inspected is to
code, you're missing all of the real leverage of an inspection.

And, Les, part of the requirements inspection does involve inspecting
state machines. You'd be amazed at how many times we find problems in them.

Cheers,

-- steve

-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of Les Chambers <les at chambers.com.au>
Date: Tuesday, March 1, 2016 2:46 AM
To: 'Peter Bernard Ladkin' <ladkin at rvs.uni-bielefeld.de>,
"systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Modelling and coding guidelines:
"Unambiguous	Graphical Representation"

Peter

PBL:First, standards don't mandate. They purport to describe the state of
the art.

Les: Refer EN 50128 Table A.16 - Modelling Referenced by clause 13 (D.5,
Item 2. Finite state machines (highly recommended for SILs 1 - 4))

Les: Close but no cigar. At least this helps the client decide to mandate
the practice given it is highly recommended by a standards body (with some
gumption).

PBL: Standards are mostly concerned to describe checks and balances and
things to ensure which best practice has shown necessary.

Les: Not true. Many life-cycle standards are highly prescriptive describing
activities and deliverables. Document standards take it to the next level
describing what should go in each paragraph of a document.

PBL:I don't know anyone who does that kind of visual pattern recognition
using a state machine.

Les: What you're talking about here is deriving meaning from a transducer
signal. Once the meaning is derived (eg a human has entered protected
space)
this would be fed to a state machine that would change the mode of
operation
of the machine (e.g. a transition to the shutdown state). Further, state
engines are useful in all kinds of contexts, not just control systems
modelling. Anywhere memory is required. For example is the subject moving
to
the left or to the right or away or toward. Figuring this out would require
memory from the last scan and the scan before that and the scan before
that.
A great app for state engines.

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. 

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.

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.

Les

-----Original Message-----
From: systemsafety
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Peter Bernard Ladkin
Sent: Monday, February 29, 2016 4:43 PM
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous
Graphical Representation"

On 2016-02-28 23:53 , Les Chambers wrote:
> I look forward to the day when standards bodies screw up the courage
> to mandate the state engine as the core modelling technique in control
systems.

First, standards don't mandate. They purport to describe the state of the
art.

Second, people who are writing/modifying the international software safety
standards are not keen on telling people how to design and build software.
They mostly come from companies which have their own software development
processes and nobody wants to be told to scrap what they are doing and do
something different, especially when that suggestion comes from a
competitor. Standards are mostly concerned to describe checks and balances
and things to ensure which best practice has shown necessary.

Third, although state machines have been prominent in the most widely-used
development techniques (I use the word "technique" loosely) such as SA-RT,
modern control systems have aspects which cannot effectively be modelled as
transducers. For one example, communications (most control systems nowadays
are distributed in some sense). For another example, the requirement for
industrial robots that, when they are operating, no human shall enter the
protected space is realised today by artificial-vision sensors rather than
by building a metal cage with an interlock on the door. I don't know anyone
who does that kind of visual pattern recognition using a state machine.

> Without these two fundamental approaches I and many people like me
> would have a huge problem understanding our own code two weeks after
> we wrote it

That might be why Fagan inspections are such a good idea.

> When will these standards wonks understand that pussyfooting around
> using terms like "unambiguous graphical representation" is unhelpful,
> creating a massive ambiguity in the standard itself which,

I think you'll find out that that is coming rather than going. People
developing the highest quality software are keen on assuring determinism
and
like to use the word "unambiguous", I think for good reason. And almost
everybody uses graphical representations somewhere during SW development
(the Lustre graphics in SCADE, for example). Why, there is even a YouTube
video explaining to people about Mealy&Moore machines .... and
unsurprisingly it uses what we are calling unambiguous graphical
representations. https://www.youtube.com/watch?v=S352lyPZP00

PBL
Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld,
33594 Bielefeld, Germany Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE