[trustable-software] How/when to bolt-on trust/evidence on an existing body of work

Andrew Banks andrew at andrewbanks.com
Thu Feb 8 05:46:54 GMT 2018



-----Original Message-----
From: trustable-software [mailto:trustable-software-bounces at lists.trustable.io] On Behalf Of Paul Sherwood
Sent: 07 February 2018 20:30
To: trustable-software at lists.trustable.io
Subject: [trustable-software] How/when to bolt-on trust/evidence on an existing body of work

Hi folks,
>> today it was suggested to me that what 'normally happens' wrt compliance 
>> is:

{snip reasonable summary}

>> How do we justify the costs of collecting evidence, in absence of
>> (awareness of) applicable regulations?

A supplemental question is: what would have been the incremental cost of "doing it right, at the right time"

>> And can anyone here share examples of ways that the gap gets closed in 
>> practice?

Usually this involves lots of retrospective documentation (specs, designs, reports), and testing. That documentation is now pointless, as it doesn't actually help in the development, whereas if done at the "right" time, it would have aided the development.  It is also more expensive to produce, as it involves "systems archaeology" as the new batch of people have to trawl the archives to understand why those who did it, did it that way!

And when the testing inevitably highlights non-conformance, the "we don't have time to fix it now, we'll do it in the next release" or "we'll fix that hardware problem in software" arguments get applied!

By way of example, DOD-2167 and DefStan-498 may have been slow and bureaucratic, but generally produced quality software the first time...

A






More information about the trustable-software mailing list