[SystemSafety] Collected stopgap measures

[paul_e.bennett at topmail.co.uk]

On 01/11/2018 at 3:34 PM, "Olwen Morgan" <olwen at phaedsys.com> wrote:
>
>One thing that I sense (maybe wrongly?) from recent traffic is 
>that a 
>goodly few of us use our own favourite techniques to help plug the 
>holes 
>in weak development practices. Cut-down structured and OO methods 
>seem 
>to be a case in point. I'm sure there are others.
>
>Might there be some benefit in gathering here the tricks that many 
>of us 
>may have used when faced with inadequate processes. Call me 
>simple-minded (many have called me worse) but I'm wondering if 
>there 
>would be value in what might be called a "Software Process 
>Cookbook" of 
>"Software Process Checklists" for high-integrity developments.
>
>True, I'd prefer something direct, technical and possibly rather 
>dry but 
>I'm thinking here about an appealing format. I'm wondering if 
>something 
>like a cookbook or "for Dummies" format would appeal to people who 
>would 
>otherwise never go near the sources that they need to be accessing 
>to 
>help them do the job better.
>
>
>Just a thought,

The biggest failing I see is lack of adequate review at all stages of the
development process. With a new project, I try to get them to adopt
my simplified process. The shock is that some companies, who do
purport to have a decent ISO9000 process in place can point to a
shelf of quite dusty manuals that it becomes obvious nobody is
following.

It is all very well having a process, with reviews built in, but if the
auditors do not detect that vital reviews were skipped ofr glossed
over, then the process is worth less than the paper it is printed on.
Some of this is down to attitudes within the company though.

I have a simple process myself, that is illustrated on a simple flow
chart, and uses just four forms and a register to manage, police
and audit. Using the four forms, the process drips the trails of
evidence of how the process has been applied. It usefully collects
data that can become ripe for statistical analysis and be used to
score how well the process has been applied to projects.

It shouldn't take a very thick book to get over the idea of how to
build dependable systems.

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..
********************************************************************