[trustable-software] Exploring the "Hypothesis for software to be trustable"

Paul Sherwood paul.sherwood at codethink.co.uk
Wed Jan 3 16:42:08 GMT 2018



On 2018-01-03 11:32, Daniel Silverstone wrote:
> On Tue, Jan 02, 2018 at 11:41:00 +0100, Paul Sherwood wrote:
> [snip]
> 
>> # t.change
>> 
>> - a t.change is is any change to standards, requirements, tests, code,
>>   documentation, or other materials that affect the project
>> - a t.change specifically includes the initial upload of any component 
>> of
>> any
>>   materials
> 
> This seems to stand alone rather than being linked in.  How about 
> adding to
> the top of t.software:
> 
> - t.software is composed of one or more t.changes

How would this work for the situation where we are trying to retrofit 
our ideas/process/magic on existing software?

> Since that way we know that all of t.evidence etc etc all apply to 
> t.change
> through t.software.
> 
>> # t.build
>> 
>> - a t.build consists of any compilation, reformation, rearrangement,
>>   or copying of any sources to generate any artefacts that may become
>>   subject to test or deployment
> 
> s/any sources/t.inputs/
> s/artefacts/t.artefacts/

Yup.
> 
> 
> # t.inputs
> 
> - a t.input is any source code or binary artefact used by a t.build
> - the environment in which a t.build is run is also a t.input
> - a t.artefact from one t.build may be a t.input to another t.build
> - a t.input MUST be uniquely identifiable

Yup.

> # t.artefact
> 
> - a t.artefact is any output from a t.build (including logs or other
>   material) which is retained to be used as input to another t.build,
>   as part of a release of t.software, or as t.evidence
> - a t.artefact MUST have t.evidence of the t.inputs and t.build used
>   to construct it.

Nice.

>> # t.process, t.effect, t.friction, t.value
>> 
>> - t.process is a set of practices to increase the trustability of 
>> software
>> - adding t.process to a project MUST lead to t.measurable t.effects
>> - t.effects are t.measures and/or t.metrics
>> - t.friction is negative t.effects
>> - t.value is positive t.effects
>> - the t.effects of adding t.process to any project MUST be 
>> t.measurable
> 
> This is a repeat of the second bullet in this section.
> 
>> - adding t.process to a mature infrastructure project must
> 
> Why 'infrastructure' here?

I need to find better wording. My thought was for software that's 
already trusted, irrespective of our attempts to 
classify/measure/improve it.

>>   - provide t.measurable t.value
>>   - involve acceptable (minimal) t.friction
>>   - be justifiable to be used upstream and/or
>>   - be applicable downstream
>> 
>> # t.reproduce
> 
> Perhaps this ties into some of what I said above about t.build,
> t.input, and t.artefact ?

Yup.

tvm
Paul



More information about the trustable-software mailing list