[SystemSafety] Another question

[paul_e.bennett at topmail.co.uk]

On 20/09/2018 at 9:35 PM, "Steve Tockey" <Steve.Tockey at construx.com> wrote:
>
>Olwen,
>I was more reacting to what you wrote:
>
>“why do people pay only lip-service to adopting coding styles that 
>seek proactively to minimise the size of relevant test coverage 
>domains?”
>
>With,
>
>“Why do people not even pay any attention to what their process 
>performance is telling them in the first place?”
>
>
>While "adopting coding styles that seek . . .” is PART of the 
>solution, I fear it is really only a small part. The majority of 
>software defects aren’t code-level defects. They are caused by 
>vague, ambiguous, incomplete requirements. They are caused by 
>ineffective and inefficient designs. Trying to address fundamental 
>requirements and design problems with a coding style solution 
>isn’t going to be very effective, I am sorry to say.
>
>The overall process needs to change in a way that exposes 
>requirements and design defects while requirements and design work 
>is being done. In fact, the process needs to change in a way that 
>seeks to prevent requirements and design mistakes from even 
>happening in the first place because that’s a lot more cost-
>effective than even early defect detection.
>

Which should always lead to the question why leave testing so late in
the process? We would be far better starting to test at the beginning.
The question of what is there to test at the start? Why the requirements
themselves of course.

The stated requirement -- "it has to be faster than the previous model"
should really yield questions of what that statement really means. How
much faster? will it taking 1ms less time to process a result be sufficient?

Having requirements that are "Clear", "Concise", "Correct", "Coherent",
"Complete" and "Confirm-able (Testable)" is the main goal in the early
stages. If the requiements are unclear or not in a form that will enable
a test to give a positive indication of pass or fail, then they need to be
questioned until the definite intent is known.

I know that until we do this, we will always be trying to remove "errors"
in our coding.

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: Due to relocation - new number TBA. Please use Mobile.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************