[SystemSafety] Collected stopgap measures

Steve Tockey Steve.Tockey at construx.com
Thu Nov 1 20:56:45 CET 2018


I do think this is a good idea in principle, but I don¹t think it is
actually workable in practice. The problem is that unless the checklists
are pretty high-level, e.g.,

*) You need to have documented requirements
*) You need to have a documented design
*) You need to have controlled source code
*) The documented design needs to be consistent with the documented
requirements
*) The controlled source code needs to be consistent with the documented
design
*) . . . 

At that high level, all you really end up with is something like DO-178C.


On the other hand, if you want to be more prescriptive then decisions will
have to be made about HOW to do certain of the activities. If you want to
document your requirements using a cut-down structured method but I want
to document the requirements using a cut-down OO method then our
respective requirements checklists will be very different. So different,
in fact, that one will be useless in the context of the other.


My two cents,

‹ steve




-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of Olwen Morgan <olwen at phaedsys.com>
Date: Thursday, November 1, 2018 at 8:34 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: [SystemSafety] Collected stopgap measures


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,

Olwen


_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
Manage your subscription:
https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety



More information about the systemsafety mailing list