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

Munns, Jon jmunns at jaguarlandrover.com
Wed Jan 3 10:51:55 GMT 2018


If a requirement isn't testable.. then how would you possibly know if you
have achieved it or not?

On 3 January 2018 at 10:39, Colin Robbins <Colin.Robbins at nexor.com> wrote:

> Hi Paul,
>
> Happy new year to you.
>
> I think the approach looks good where the outcome is deterministic.
>  I.e., there are t.tests for each t.requirement.
>
> On to the attributes of trustable is secure.   The challenge with secure,
> is that it non-deterministic, and changes over time.
> So I suggest we need to add an element of "when" the tests were performed,
> and the state of the "known set of vulnerabilities" at that time.
>
> Regards,
>
> Colin Robbins
> Nexor
> Tel: +44 (0) 115 953 5541
>
> -----Original Message-----
> From: trustable-software [mailto:trustable-software-
> bounces at lists.trustable.io] On Behalf Of Paul Sherwood
> Sent: 02 January 2018 10:41
> To: trustable-software at lists.trustable.io
> Subject: [trustable-software] Exploring the "Hypothesis for software to be
> trustable"
>
> Hi folks,
> over the break I was thinking about the hypothesis that Edmund expressed
> last year [1], and found myself attempting to codify some of the context
> and underlying assumptions, as you can see below.
>
> I've gone for a shorthand of t.* to denote things that seem to be either
> required or implied by the 'Trustable Software' discussions and concepts.
>
> Note that:
> - I'm not even confident yet that the hypothesis is generally correct.
> - I think that the specifics of the hypothesis are probably not all correct
> - I'm completely sure that following statements contain bugs and I would
> appreciate any/all review feedback
>
> br
> Paul
>
> # t.software
>
> - we assess the trustability of t.software based on t.evidence
> - t.software MUST have t.requirements
> - t.software MUST satisfy its t.requirements
> - there MUST be t.measurable t.evidence that t.software satisfies its
> t.requirements
>
> # t.requirements (derived from wikipedia [2])
>
>    - t.requirements MUST be unitary
>    - t.requirements MUST be atomic (non-conjugated)
>    - t.requirements MUST be complete
>    - t.requirements MUST be consistent
>    - t.requirements MUST be traceable
>    - t.requirements MUST be current
>    - t.requirements MUST be unambiguous
>    - t.requirements MUST be verifiable
>    - t.requirements MAY be graded by priority/importance
>
> # t.tests
>
> - t.requirements MUST exist
> - all t.requirements MUST have t.tests
> - all t.tests MUST pass
> - the scope of the t.requirements MUST be t.measurable
> - the scope of the t.tests MUST be t.measurable
> - we MAY t.estimate the scale or scope of missing t.requirements
> - we MAY t.estimate the scale or scope of missing t.tests
>
> # t.evidence
>
> - t.evidence is machine-parseable metadata associated with t.software
> - t.evidence MUST include t.evidence of its own integrity/correctness
> - t.evidence MUST include t.identity for author(s)
> - t.evidence MUST include t.identity for committer/uploader
> - t.evidence MUST include creation/modification/commit time-and-date
> - t.evidence MAY include text description and/or comments
> - t.evidence MAY include t.identity for reviewer(s)
> - t.evidence MAY include t.identity for review comments
>
>
> # t.identity, t.identify
>
> - t.identity is a kind of t.evidence
> - t.identity MUST map to a single t.contributor
> - a t.contributor is a uniquely identifiable person, organisation or
> software program
> - t.contributors contribute to t.software and/or t.evidence
> - t.contributors are responsible and accountable for their contributions
>
> # t.measure, t.measureable, t.estimate, t.measurement, t.metrics
>
> - t.measurements MUST be derived from t.evidence via automation
> - t.estimates MUST be derived from t.evidence via automation
> - t.measurements MUST be believed to be factually correct
> - t.estimates are known to be uncertain
> - we t.measure all available t.evidence about t.software, producing
> t.metrics
> - we t.measure multiple t.metrics, including signals for some (ideally
> all) of
>    - engineering cost/effort
>    - project scale
>    - project value
>    - project quality
>    - project software performance/efficiency
> - we use t.estimates to check t.measurements or fill in gaps in t.evidence
> - we look conflicts between t.metrics
>    - we evaluate the conflicts
> - we aim to identify gaps in t.metrics
>    - we seek new t.evidence to close them
> - all t.metrics MUST be meaningful
>    - for t.software, all t.metrics are acceptable
> - we can aggregate/manipulate t.metrics to provide a t.measure of
> trustability
>
> # t.provenance
>
> - t.evidence MUST t.identify the authors of the t.software
> - t.evidence MUST t.identitify the reviewers of the t.software
> - t.evidence MUST t.identify the integrators/mergers of the t.software
> - FIXME add hypothesis provenance logic here
>
> # 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
>
> # 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
> - FIXME add hypothesis build logic here
>
> # 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
> - adding t.process to a mature infrastructure project must
>    - provide t.measurable t.value
>    - involve acceptable (minimal) t.friction
>    - be justifiable to be used upstream and/or
>    - be applicable downstream
>
> # t.reproduce
>
> - FIXME add hypothesis reproduction logic here
>
> # t.function
>
> - FIXME add hypothesis functionality logic here
>
> # t.update
>
> - FIXME add hypothesis update logic here
>
> # t.context
>
> - t.context is written information which states or clarifies relevant
> ideas for t.software
> - [trustable software
> discussions](https://lists.trustable.io/pipermail/trustable-software/)
> - [wikipedia requirement](https://en.wikipedia.org/wiki/Requirement)
> - [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)
> - virtually all existing software does not satisfy the [trustable software
> hypothesis](https://gitlab.com/trustable/overview/wikis/
> hypothesis-for-software-to-be-trustable)
>    - but a lot of software is widely trusted
> - to be useful, the t.software concepts must be
>    - easy to understand
>    - justifiable
>    - practical and realistic
>    - applicable to existing software
>      - collecting t.evidence needs to be low friction
>      - t.measures and t.metrics for widely trusted software existing
> software  should be good
>
>
> [1]
> https://gitlab.com/trustable/overview/wikis/hypothesis-for-
> software-to-be-trustable
> [2] https://en.wikipedia.org/wiki/Requirement
>
>
> _______________________________________________
> trustable-software mailing list
> trustable-software at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software
> _______________________________________________
> trustable-software mailing list
> trustable-software at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software
>



-- 
Kind Regards,

Jon Munns MBA
Chief Engineer Vehicle Domain Controller
Jaguar Land Rover Electrical
Int Tel: 8794 9812
Tel: +44 7880 401 047


Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20180103/1437657e/attachment.html>


More information about the trustable-software mailing list