[SystemSafety] Koopman replies to concerns over Toyota UA case

[Steve Tockey]

Andrew,
There will always be drones who can¹t think beyond a given rule. But that
being the case, the solution should not be to completely throw it out.
Let¹s modify the rule set:

*) Bring in appropriate ³global² complexity metrics to supplement the
existing ³local² complexity metrics. Shut the door on people playing the
accounting game. Yes, more research is required here. But don¹t throw out
all focus on structural complexity until we understand it 100% because it
will take many years before we can say we really fully understand it.

*) Incorporate allowances for CASE statements so a statement with 25 cases
doesn¹t get charged the full 25. I could suggest charging the log of the
number of cases as a starting point, but that¹s just to give a sense of
what such an allowance might look like.

*) Set the complexity limit at a point where it is not debatable as to
whether the code is bad any more. If a reasonably conservative limit for
Cyclomatic complexity might be, say, 15, then set the MISRA C limit at 30.
It¹s hard to argue that 30 should be acceptable in light of a reasonable
allowance for CASE. Now the QA Clipboad Monitors can check boxes and be
comfortable knowing that if the box isn¹t checked then the code should not
be accepted. A more mature organization can set their limits more
conservatively if they are beyond the Clipboard mentality.


‹ steve





-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of Andrew Banks <andrew at andrewbanks.com>
Date: Tuesday, January 2, 2018 at 11:21 PM
To: "paul_e.bennett at topmail.co.uk" <paul_e.bennett at topmail.co.uk>,
'Bielefield Safety List' <systemsafety at techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Koopman replies to concerns over Toyota UA case

On 30 December 2017 21:25, Paul Bennett wrote

	Specifying a McCabe Code Complexity limit for individual software
components is, in my eyes,
	more of a trigger to begin asking the questions that need to be
asked. If the development policy
	set the MCC at say 9, then any component submitted for review with a
number above that should
	begin to get questions asked.

In theory this is a sound idea... similarly with Source Lines of Code
(another broadly useless/arbitrary metric) - however...

As we in the MISRA C Working Group know from painful experience, too many
QA
Peeps put aside common sense, and apply blind adherence and a tick-box
mentality to rules - eg the frequent requirement for 100% MISRA C
compliance, with no deviations (which is, generally, infeasible for
non-trivial projects) which can potentially in some cases result in more
complex conforming code, than the non-conforming code - especially when the
Advisory Rules are followed blindly.

So in the suggested case, the QA Clipboard Monitors will simply
"non-compliant" any module with a MCC above X (without permitting
debate/concession)


Kind regards
Andrew Banks 

Embedded Software Manager
Frazer-Nash Research Ltd
http://www.frazer-nash.com

and Chairman
MISRA C Working Group
http://www.misra.org.uk




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