[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