Re: [AM] Why Traceability? Lean Traceability?

(responding to Brad)

>> (Paul):
>> I hope you're going to write the article ....
>
> (Brad)
> I'm thinking about it ...

I'll take that as a definite ... well, somebody needs to
do it.


>> Yet traceability didn't seem to come into play - the HLD was
>> handed round to everybody concerned, and the architect
>> team knew who these teams were.  Is it your experience that
>> other teams, perhaps larger or more chaotic, need help here?
>
> So you had documented requirements, and an HLD, but hadn't
> yet done any LLD or code or tests? Am I reading that correctly?
> (if so, sounds like you hadn't yet created the mid-level and
> low-level artifacts to be traced to, so obviously they wouldn't
> be of much help)

Not so.  They had already been created for the original 
requirements and updated with any earlier changes.

> If I do have those "traces" in place, then for a given
> requirement (or feature), if I trace down to the deepest level,
> and then from their follow all the traces back up to the top,
> then in theory that is one quick and easy way of generating
> a candidate list of impacted hi-level entities (requirements
> and hi-level design items).

Understood.  However, this *does* seem like a strategy for
use where the ripple effect has not been beaten into
submission.  Though where the changes affect the existing
interface, or the existing 'contracts' on that interface, the
changes may well ripple despite our best prior efforts.

> .... So tracing from the defective or to-be-enhanced feature,
> down to code+tests, and then from there back-up to hi-level
> requirements and HLD elements generates a candidate list
> to more narrowly target an analysis of possible impacts.

Again understood.  This seems to be a strategy for use where
change is feared.  We cannot afford to wait and see what
tests fail - or possibly we cannot rely on the tests to catch all
the things that get broken, or possibly we cannot afford to
run all the tests, it would be cheaper to trace which ones *may*
be pertinent...

> Was that helpful?

It confirms my expectations, I think.



> So, if I'm a large project in a large organization (and lets
> assume I'm not agile, tho not necessarily failing miserably
> either) and maybe also assume the "end product" is a mix of
> both HW+SW, and I frequently get defect reports that have
> such "ripple effect", do you suppose I am more likely to
> try and "fix" the ripple effect, or instead document and
> trace the heck out of it in an attempt to make myself a
> "map" of it, and do that to address "maintainability"
> rather than eliminate or remove the ripple effect itself?

I hope you'd try to do what I would try to do - use traceability
to fix the immediate problems, and do what I could to
increase the decoupling in the areas of code I touched.
Also institute a general task to decouple legacy code
until the problem was licked and the whole lot re-engineered
or replaced (something I've only been given free rein to
do once, to date).

> (how different is your answer if fixing the ripple effect 
> requires cross-organization collaboration rather than
> throw-it-over-the-wall and finger-pointing?)

If the answer involves throw-it-over-the-wall and finger-pointing
then I have something else on my list of things that need to
change.

>> (...  Anyone experiencing 'ripple effect' in the
>> last 10 years is either developing incompetently, or is
>> working with legacy code and has failed to install decoupling
>> mechanisms.  This latter may not be down to incompetence,
>> but I'd be suspicious...)
>
> If developing incompetently includes "managing development
> incompetently, I can buy that. If not, I have a proposed
> addition to your list above :-)

Surely the bulk of the blame must lie with 'management'?
Certainly it must in 'command and control' environments.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------