Hi Everyone,
I mentioned in the last call that I would better explain the problems
with modified TAs. Much of this is coming from experience at Sun
trying to manage Specification Analysis over Specification revisions,
as well as associated tests. Much of my discussion is based on the need
to maintain metrics, metrics that show (to specification writers, and
testing leads) that the amount of a specification being analyzed and
tested is increasing. My group at Sun has been laboring to produce a
tool for gathering these metrics, and maintaining TA analysis across
spec revisions.
The important factor here is 'in order to track the evolution of
a TA, it is important to preserve the TA's ID across revisions of the
specification'. This is important because it is also
important to maintain the relationship between a TA, and the tests
associated with that TA.
We have found that TAs can change in many ways from specification to
specification:
TA's may change:
1.) Location (we often call this a context change)
This may mean that the normative text in a spec may move, causing
potentially different implications of the TA.
2.) Insignificant changes
This may mean that slight changes to the normative text (eg.
formatting, superflous wording, etc) may change, but the overall
meaning of the TA does not change. There may be slight refinements to
the meaning of a TA, but at some arbitrary point, semantic changes
become significant.
3.) Significant change
A.) Assertion Strengthening
eg "A widget that weighs alot must be colored blue" => "A
widget that weighs >= 5 pounds must be colored Blue".
B.) Assertion Weakening (or generalization)
eg "A widget that weighs >= 5 pounds must be colored
Blue" => "A widget that weighs alot must be colored Blue".
C.) Significant Meaning change
eg " A widget must fit thru a square hole" => "A widget
must fit thru a round hole"
Arguably, significant meaning changes should be accompanied by drop/add
of TAs, where the TAs should have a different ID.
Still, it is important to change the tests (implementation) that may be
associated with changed assertion, therefor, it is important to
maintain a history trail of where an assertion (change) may have
derived from.
One idea that came up at the last meeting was to use another "Version"
event, "VersionReplaceID". "VersionReplaceID" would be distinguished
from "VersionAdd in the following regard:
VersionAdd - distinctly used to Add a newly identified assertion, due
to newly added or newly analyzed normative text.
eg. Assertion: ID = 100
VersionAdd = rev 15
VersionReplace - Used to describe the assertion where this one has
derived from
eg.
Assertion: ID = 100
VersionAdd = rev 15
VersionDrop= rev 18
Assertion: ID = 101
Version Add= rev 18
Version ReplaceID = 100
This allows us to identify that Assertion 101 is a "changed" version of
Assertion 100, and that any tests associated with Assertion 100 may be
related / changed to address the normative text in Assertion 101.
Hope this helps, Regards,
Kevin L
0D4373E9E1236F42AB63FD6B5B306AA38DDD96@SV-EXCHANGE.fjcs.net"
type="cite">
Test assertions that are modified are trickier to handle. One could
treat the modified test assertions as two separate test assertions and
tag them with the appropriate VersionAdd and VersionDrop tags.
Unfortunately, this approach does not provide any indication that the
updated assertion is related to the test assertion in the prior
specification.
<JD> I would not worry about the above
modification case: a modified TA is a new TA ... Why not just say that the
TAs themselves probably should not be versioned.
<!--[endif]-->
|