RE: [AM] Why Traceability?

Traceability can be a solution to a problem - depending on the problem.  But
then again, so can the number 42.

Whatever the reason traceability is asked for, whether asked for by the
client, government regulation, or internal processes, one thing can be
expected: the good stuff is expensive because it is so labor and time
intensive, and so prone to error and rework.

So, IMHO, having a discussion on traceability will likely not get you
anywhere because the pros and cons, as well as the motivation can be so
broad.

A few questions come to mind: How important is maintenance?  Is there direct
business value associated with the traceability?  If so, where is the
balance between detail and accuracy and business value?  How important is
verification and validation?  How detailed should it be?  What is the budget
concerning traceability efforts?

Increased traceability (as is referred to formerly in this discussion)
pretty much equates to decrease in agility, so we could be splitting hairs
forever.

Traceability is supposed to provide a roadmap from requirements and high
level concepts to source code and V&V - it is having this roadmap that is so
expensive and uncertain - although a necessary evil in some cases.

To understand it I think it is important to understand what is happening in
the industry.  A great divide is growing in the industry... one side is
moving toward BDUF, MDA and increased traceability up front with reduction
in and ultimately an elimination of efforts in actual programming labor
efforts, while the other is an increase in Agile methods, with a growing
trend to have the weight of the traceability efforts at the end through
reverse engineering, and linking TDD and full structural verification.

The former uses documentation and modeling (e.g. requirements, architecture,
design) extensively in the beginning as the canonical traceability framework
and is the basis for specifying the system, which is later built according
to specs (perhaps automatically/programmatically).  However, the latter
(Agile) uses documentation and modeling minimally and with primitive methods
in the beginning not for traceability but as a tool for analysis and
cognitive/creative priming.  The latter portion of the industry can then
focus on automated tools that do not hinder development/evolution and will
link TDD, source code, and V&V using techniques such as embedded code
instrumentation and reverse engineering to provide the roadmap/traceability
of the system after it is built.

The Agile approach (latter) is appealing because it is most amenable to
evolution and maintaining conceptual integrity, and can deliver business
value sooner and more of it in the end because the system was able to evolve
to meet the customer's needs (provided it is accomplished properly.)  It is
also the better solution in most cases because it is extremely difficult and
costly - and inevitably problematic to put forth great efforts up front to
totally specify the system accurately - it is hard to predict the future.
Also, it is impossible to always extract the exact proper form, shape and
details of each system concept before the engineers/developers dive into the
cognitive inner-world of implementing a design (programming.)  However,
generating the traceability roadmap after the fact is simply reporting on
what was already built - no prediction - all fact.

My personal opinion is that this divide is not only bound to happen but is
growing already - the industry cannot go just one way or the other.  FDA,
FAA, GSA and DOD regulations require the up-front specification and
traceability, while much of the bespoke portion of the industry cannot
afford it, which is where Agile methods comes in.

Traceability takes on a different form, meaning and end product depending on
many factors - not the least of which is the position along the gradient
between the two sides of this divide.

IMHO

Mark

-----Original Message-----
From: Paul Oldfield [mailto:[email protected]] 
Sent: Tuesday, March 16, 2004 5:34 AM
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
--^----------------------------------------------------------------
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
--^----------------------------------------------------------------