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

Daniel Silverstone daniel.silverstone at codethink.co.uk
Wed Jan 3 11:32:42 GMT 2018

On Tue, Jan 02, 2018 at 11:41:00 +0100, Paul Sherwood wrote:

> # 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

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/

# 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

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

> # 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?

>   - 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 ?


I'll have to think about the rest another time.

Daniel Silverstone                           http://www.codethink.co.uk/
Solutions Architect               GPG 4096/R Key Id: 3CCE BABE 206C 3B69

More information about the trustable-software mailing list