[SystemSafety] Koopman replies to concerns over Toyota UA case
Steve Tockey
Steve.Tockey at construx.com
Wed Jan 3 20:13:43 CET 2018
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
More information about the systemsafety
mailing list