[SystemSafety] Koopman replies to concerns over Toyota UA case

Steve Tockey Steve.Tockey at construx.com
Sat Dec 30 23:28:04 CET 2017


Paul E. 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.²


That is essentially the approach that I take although I extend it a bit. I
prefer to use ³quality zones², as in:

Green zone--Code with a metric in this range is acceptable as-is, no
action is required

Yellow zone--Code with a metric in this range must be accompanied with
clear justification for why the code must be this complex. With adequate
justification, the code can remain as is. Without adequate justification
the code needs to be restructured to drive that metric into the Green zone

Red zone--Code with a metric in this range is unacceptable under any
circumstances. This code is a defect magnet, it must be restructured to
drive that metric into an acceptable range


FYI, for my projects, Cyclomatic complexity zones are set as follows:
Green zone = 1 to 9
Yellow zone = 10 to 14
Red zone = 15 or higher


For Depth of decision nesting:
Green zone = 1 to 4
Yellow zone = 5 to 6
Red zone = 7 or higher



For Number of parameters:
Green zone = 0 to 4
Yellow zone = 5 to 6
Red zone = 7 or higher


Finally, for Fan out:

Green zone = 0 to 7
  
 
 
  
  Yellow zone = 8 to 10
  
 
 
  
  Red zone = 11+
  
 



Of course any organization should be free to set these zones as they feel
appropriate, I think these are a good starting point.


Cheers,

‹ steve




-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of "paul_e.bennett at topmail.co.uk" <paul_e.bennett at topmail.co.uk>
Date: Saturday, December 30, 2017 at 1:24 PM
To: Bielefield Safety List <systemsafety at techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Koopman replies to concerns over Toyota UA case

On 30/12/2017 at 7:33 PM, "Matthew Squair" <mattsquair at gmail.com> wrote:
>
>Hi Derek,
>
>I agree, relying purely on McCabes metric as evidence would be
>unwise, even
>for a forensic exercise.

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.

I have a very nice graph which correlates the required effort in hours to
do
the test of a software component at various MCC's. Considering that each
software component's review includes a full Fagan Inspection, a Functional
Test and a Limitations Test, and that the higher the MCC value
expenonetially
more time is required to thoroughly review the component.

However, some specifications could do with being measured with McCabe to
guide reduction of the inherent complexity specified into a project in the
first
place.


Regards

Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
-- 
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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



More information about the systemsafety mailing list