Re: [AM] Why Traceability? Lean Traceability?

On Wed, Mar 17, 2004 at 05:25:45AM -0500, Paul Oldfield wrote:
> I hope you're going to write the article when this thread
> has run its course on the various forums.

I'm thinking about it ...

> I think some more work on why traceability aids impact analysis
> would be in order.  Having worked on 200+ people projects,
> I recall we could not do impact analysis from the bare
> requirements - that is, we could not estimate the work needing 
> to be done in 'our' area from the bare requirements.  The
> requirements needed some analysis, and the architect needed
> to produce a high level design.  Until then, nobody knew just
> how much their part of the system would be asked to do.
> Without this, you might get several parts of the system giving
> estimates for duplicated work.  (You mention analysis, but
> IMHO some design is also needed if going this route).
> 
> 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)

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).

I've seen that done a LOT for enhancement requests, and for
defects (Here we assume an "enhancement" is an "add on" to the
specified behavior of an existing feature). 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.

Was that helpful?

> One topic that other posters made more of was the need to know
> what needed to be re-tested when something changed.  If
> we really need to know everything that uses something we
> change, then traceability is necessary.  Of course, this need
> is an indication that we have failed to control the ripple effect;
> also that our testing is still so expensive that we need to cut out 
> the tests that cannot have changed.

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

> (This should also address your comments on my "rant mode"
> in another posting.  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 :-)

-- 
Brad Appleton <[email protected]> www.bradapp.net
  Software CM Patterns (www.scmpatterns.com)
   Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

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
--^----------------------------------------------------------------