RE: [AM] Why Traceability? Lean Traceability?

(responding to Brad)

>> (Paul)
>> However, a topic that never seemed to reach consensus,
>> or even be given a satisfactory answer, IMHO, was the
>> question of what problem or problems traceability was
>> trying to solve.
>
> (Brad)
> The main problem(s) it addresses are:
>
> 1. Change Impact Analysis

<snip>

> (Paul, If I missed any of your questions, let me know :-)

I hope you're going to write the article when this thread
has run its course on the various forums.

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?

As for conflicting requirements, the analysts seemed to resolve
these as they went.  OTOH, by the nature of my area of expertise
at that time, we were always doing OOA, and the domain expert
had the final say about what the concepts were 'about'.  Abnormal
behaviour was relegated to business rule or controller objects.

Perhaps our large projects were better organised than others, 
it didn't seem that way.

Your comment about traceability from version control tool is
useful, in long-lived systems in particular.

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.

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


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