RE: [AM] Why Traceability?

The need for a traceability matrix increases the heavier you travel because 
when you maintain the same information in several places you need to update 
it when something changes.  With documentation-heavy processes traceability 
appears to be an important thing as a result, but as you move to 
documentation-effective processes such as AM the need to trace reduces 
because there is less to keep in sync.

There is inherent traceability in some artifacts:
1. In code based artifacts (e.g. tests which invoke business code)  you can 
determine the traceability via examining the code.
2. In model-based artifacts created within a sophisticated modeling tool 
the models are often related to one another which gives you your 
traceability (e.g. this use case is described by these three sequence 
diagrams, which in turn depict operations and classes which appear on the 
design class model, Class X is described by this state machine diagram 
which was used to generate this source code, ...

When you use simple tools (whiteboards, cards, ...) to model you lose 
explicit model traceability and "unfortunately" have to rely on the people 
involved (e.g. talk to Sally if you want to find out how that works), or 
rely on code-based artifacts, or develop a traceability matrix.

I would treat a traceability matrix like any other document -- it should be 
treated as a requirement (estimated, prioritized, ...) and created only if 
your stakeholders are willing to invest in it.  I would also create an 
agile document which is just barely good enough.  I wrote a bit about this 
on the AM site a few years ago.

- Scott


At 07:13 AM 3/16/2004, you wrote:
>IME traceability offers an understanding of impact of change and allows
>you to actually somewhat measure that change.
>
>If I change this use case I will also have to review these classes and
>those classes being changed will affect this component and if that
>component changes I have to rerun these tests to ensure that everything
>"still" works correctly...
>
>Is that too simplistic an answer? That seems to me to be the real value.
>Of course you can go in the other direction too...this machine went down
>so that service is no longer available...blah blah...
>
>-pjm-
>-----Original Message-----
>From: Tina Erwee [mailto:[email protected]]
>Sent: Tuesday, March 16, 2004 7:04 AM
>To: [email protected]
>Subject: RE: [AM] Why Traceability?
>
>Hi
>
>I think the only real stick traceability ever gave anyone, was the stick
>to hit the client over the head with: "You can't have this, you dirty
>little client. You did not ask for this (2 years ago)!"
>
>Oh, of course traceability generates work. Keeping your requirements and
>models in sync (explicit traceability) can be so much work that you will
>need an extra resource just to manage the docs, unless you use a tool
>(that cost more than the resource)!
>
>That's about it!
>Tina
>
> > -----Original Message-----
> > From: Paul Oldfield [mailto:[email protected]]
> > Sent: 16 March 2004 13:34
> > To: INTERNET:[email protected]
> > Subject: [AM] Why Traceability?
> >
> >
> > Hi, all.
> >
> > There has been a thread over several agile forums in the
> > last 10 days or so about Traceability.
> >
> > There seemed to be some consensus reached that
> > traceability is a solution to a problem, one that may no
> > longer hold true (as in no longer the best solution) in an
> > agile environment.
> >
> > 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.
> >
> > Given the apparent number of greybeards on this forum,
> > (younger folk can also respond, please?) can anyone
> > give an opinion as to why traceability is wanted - what does
> > it give us?
> >
> >
> > Paul Oldfield
> > www.aptprocess.com
> >
> > For more information about AM, visit the Agile Modeling Home
> > Page at www.agilemodeling.com
> >
> >
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>For more information about AM, visit the Agile Modeling Home Page at 
>www.agilemodeling.com

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

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