[trustable-software] Evidence Relationships in SDLC
trustable at panic.fluff.org
trustable at panic.fluff.org
Wed Mar 28 16:26:54 BST 2018
Hi
I wonder if you might be able to address this problem for me. I'm sort of
stuck. I've been using the 'trustable' discussion to help get to something
which I can implement.
https://gitlab.com/trustable/workflow/blob/master/markdown/basics.md
we discuss these relationships
So I believe the following to be the case
* each t.test MUST be associated with one or more t.requirement
* t.function is a unit of execution of t.software
* each t.function MUST be associated with one or more t.requirement
* each t.function MUST be validated by t.test
* each t.requirement MUST be unitary/cohesive
* each t.requirement MUST have one or more t.test
So let's agree what a requirement is
https://en.wikipedia.org/wiki/Requirement
And such a requirement should be Unitary and Cohesive. That is to say
that it should address one and only one behavior. Thus if you need to
validate more than one behavior you require more than one requirement.
I'm going to use this definition for t.requirement
Now let's define what a function is. That is to say a callable unit of
executable instruction.
https://en.wikipedia.org/wiki/Subroutine
I'm going to use this definition for t.function
Now let's define what a test is.
https://en.wikipedia.org/wiki/Test_method
That is to say a definitive procedure that determines one or more
characteristics of a given process execution. I'm going to use this as a
definition of t.test
So what relationships are we trying to record
* t.requirement has one or more t.test
* t.requirement has one or more t.function
* t.function has one or more t.test
* t.function has one or more t.requirement
* t.test has one or more t.function
* t.test has one or more t.requirement
* t.test may exercise one or more t.requirement which in turn exercises
one or more t.function
So here is the problem.
We two requirements t.requirement[a] and t.requirement[b]
We have a t.function[1] which is used in the implementation of
t.requirement[a] & t.requirement[b]
We have a t.function[2] which used in the implementation of
t.requirement[a] & t.requirement[b]
We have a t.test[1] for t.function[1]
We have a t.test[2] for t.function[2]
We gain a new requirement t.requirement[c]
We have a t.function[3] which is used in the implementation of
r.requirement[c]
We have a t.test[3] for t.function[3]
We now discover that t.test[1] fails with the addition of
t.function[3]
We now discover that the root cause of t.test[1] failure is the
interaction between t.function[3] and t.function[1]
Problem Constraints
At any moment, we must be able to validate the relationship between
t.requirement, t.function, t.test and the t.change. Ideally this
relationship should not depend on the developer populating the metadata
most likely incorrectly. Ideally this meta data should reside in the
SCM tool perhaps in things like Commit Messages or Notes (git notes).
Here is the question ?
How do we manage the linkage between these things without loosing the
relationship between the t.function[1] and t.requirement[a] ?
Why is this a problem ? During the implementation of t.requirement[c]
we have to refactor the t.function[1] and t.test[1] from
t.requirement[a]
Really value your opinion on this
Edmund
ps I believe I have a horrid HACK to do this but was looking for something
more beautiful
========================================================================
Edmund J. Sutcliffe Thoughtful Solutions; Creatively
<edmunds at panic.fluff.org> Implemented and Communicated
<http://panic.fluff.org> +44 (0) 7976 938841
More information about the trustable-software
mailing list