Why Traceability? Can it be Agile?
- I was reading a book review of "Practical Software Engineering"
at www.therationaledge.com and it said something about the
"importance of traceability":
Emphasizes the importance of traceability
Throughout the book, Manassis discusses the importance of
requirements traceability. The last chapter, Traceability at
Work, demonstrates how traceability helps to keep projects
on track and on schedule. The greatest practical function
of traceability, he claims, is that it facilitates impact
analysis. It allows you to predict and identify what will
change if you modify the system at any level.
For example, with traceability you can:
* Identify the source of inputs for each artifact.
* Include traceability information as part of an artifact
where appropriate (e.g., in many UML model diagrams).
* Use techniques that help you link two artifacts to each other.
For example, you can see how to link the .NET role-based
security attributes in code with the UML use-case model,
actor diagram, and sequence diagrams, through the role-based
* Whenever you make a code change, identify all artifacts you
need to change, and understand how to make those changes.
[end of excerpt]
In the past, I've mention the three main uses/needs for traceability:
1. Assist change impact analysis (and hence estimation accuracy)
2. Ensure conformance to specs
3. Mandated (by legal/contractual obligation or market industry)
Most of the time it comes up on this list, people use or assume
the 2nd item above and claim its not needed in XP/Agile when I
can show that all my tests pass and all my tests are easily
traceable to the corresponding story (I think part of this is
also not calling a development task "done" until it passes
the tests). I also think that is largely true!
As I look at the impact-analysis use of traceability as described
above, one of the first things that strikes me is that its very
"up front" thinking instead of adaptive. It tries to predict what
will/might happen instead of using feedback upon executable results
to see what does happen.
I think a more adaptive approach would say: create or simulate
the change in an isolated environment, observe see what happens,
then respond to it. If I could do such a "simulation" - would
traceability for the purpose of impact analysis be obsolete?
(do I really need to know which artifacts/entities are touched
if I know what the effects are? Is it still useful for estimation?)
What might be a TDD-way of doing such an executable impact
analysis that didn't take significantly more time to do than to
simply "mock up" all or part of the requested change? (or to
help me find out all the areas of code that would be touched?)
How could I answer the question "what physical [files/classes] and
functional [stories] characteristics are impacted if I add/change
this story or part of a story?" and how can I answer that in an
agile fashion with small and tight rapid-feedback loops that gave
me back an answer without adding too much additional time to my
estimation activity? [I can see how a really nice MDD environment
could be helpful here]
The second question (which really should be the first question)
is, do I really need to answer the "impact" question in the
first place? How much does it help me and my customer to be
able to do that? How much would it improve my estimates, my
team's velocity, our ability to collaborate, and give rapid
executable feedback to our customer if I could do this thing?
[I don't have any ready answers for this - am interested in
opinions from those who actually have or had had this ability
in previous projects (agile or otherwise) and how much their
agile project's would truly benefit from it (or not).
Functionally speaking - why is impact an issue at all? I think
its because it presumably reveals key insights as to the cost
of making the change. But what if my code is maximally well
factored AT ALL TIMES? What if my functional architecture
(e.g., classes, interfaces, packages) my physical architecture
(e.g., files, directories, headers) could:
- maximize encapsulation and localization
- easily correlate my abstractions (e.g., domain objects)
with their corresponding stories/use-cases (as opposed
to trying to trace at the finer-grained level of
line-item requirements and routines/lines of code)
and hence to their corresponding tests
If I aggressively manage and minimize dependencies thru
refactoring and encapsulation, and if I worry about tracing
only at a more coarse-grained level of stories (features)
to abstractions (classes/interfaces), might that not be
enough? Might that be "barely sufficient" to meet most
mandatory/obligatory requirements for formal traceability?
And in the cases where it didn't, how might I take a
simulation/TDD-based approach to impact analysis and
effort estimation for a requested change?
I gave a presentation on "Agile SCM" last week, and several
in the audience asked be about "traceability", and how
to meet mandated traceability in an "agile" fashion (especially
now that things like Sarbanes-Oxley are prompting increasingly
more shops to mandate - a phenomenon which several in the
audience seemed to agree has already started and is growing).
I suggested that agile projects address concerns of traceability
by doing things like:
- Having tests directly traceable to stories (sometimes even
on the same card)
- Minimizing the number of artifacts produce (fewer items means
fewer items and fewer inter-relationships to track and manage)
- Knowing which stories (features) each "commit" is for, and being
able to associate them in the version-control tool if necessary
in order to automate code-level traceability (e.g., a checkin comment)
- Aggressively managing dependencies with (encapsulation/refactoring)
- Using concepts of domain-driven design to ensure the easy correlation
between stories and objects.
- Managing traceability at the level of stories (feature or use-case)
and objects instead of individual line-item requirements and
lines of code (something which good encapsulation makes possible
because low-coupling and high-cohesion increase the odds that
few other objects will be impacted, but the few that are might
At the time I said that, I hadn't yet pondered the simulation/TDD-based
approach for traceability hinted at above (nor of the applicability of
Mock-Objects and even AOP to ease t he ability to do so comprehensively).
I would be very interested in hearing if others have done it, or of
how it might be done.
Brad Appleton <brad@...> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
- Brad Appleton wrote:
> Mike Beedle wrote:Brad:
>> Reversibility and traceability are great concepts but are hard to
> Sure - at the level you are claiming is being asked for. Problem is
> that's NOT what's being asked for! It IS POSSIBLE to do
> lightweight/lean traceability. I've done it, Alistair said he's seen
> it done. And I know of many others that done it too. No one here asked
> for "perfect" traceability or "full" - just plain old "good enough"
> and "barely sufficient" traceability. Alistair described one way. I
> described another. So let's get off the "IMPOSSIBLE" kick shall we
> because its already been disproven.
I would like to see a couple of working examples to really assess
Please don't misunderstand me, I like the idea of doing:
just plain old "good enough" and
"barely sufficient" traceability.
(That's I am trying to do with Balanced Agility with Scrum, "good
and "barely sufficient" Agile Software Development ;-) But
I also think we should present the arguments as to *why*
thorough traceability and reversibility are impossible, at least
with our current tools and environments.
Perhaps a good Open Source Eclipse plug-in will do for bare-bones
traceability .... with some minimal automated "registration
system" per class? I don't know of such a thing, unfortunately.
NOTE: If most people are wondering why the "fireworks" are
going off in this thread, is because it was *precisely* this kind
of arguments about software being "traceable and reversible"
from many artifacts that fueled the movement of Agile Software
Through the 90's some proponents in the industry claimed that
their processes and tools would deliver "traceable and
reversible software" across many artifacts, but many of us at
the other side of the fence were asking:
1) at what cost?
2) with what purpose?
3) with what benefits?
That is a significant part of the "Agile soapbox",
"Writing is re-writing."