A "lean" approach of traceability would focus on the following:
1. If one uses single piece flow and makes changes at the granularity that TDD mandates, then software-level requirements, design, coding, and testing are all part of the same task. Tracking them to a single record-id in the change-tracking system and version-control tool would actually go a long way toward traceability. It’s much more work and creates many more intermediate artifacts when these activities are all separated over time (different lifecycle phases), space (different artifacts) and people (different roles/organizations). When traceability efforts noticeably interfere with "flow" is when agilists object. It’s important to minimize intermediate artifacts and other perceived forms of "waste" (over specifying requirements or too much requirements "up front") because fewer artifacts means fewer things to trace.
2. Collocating both people and artifacts, with the former for communication and the latter for locality of reference documentation, as those artifacts that are deemed necessary. This also entails applying single source information whenever possible; a project-wiki is one common, proven way of doing this.
3. Coarse-Granularity and Modularity/Factoring of what is traced. Tracing at the highest practical level of granularity. For example, is it practical to trace to the individual requirement or the use-case? To the line of code, or to the method/subroutine, or to the class/module is about "simple design" and "(re)factoring" as it applies to the structure of the traced entities and their relationships.
4. Transparent, frictionless automation of the terribly taxing and tiresome tedium of traceability. Focus on taking the tedium out of manual traceability and have it streamlined and automated as much as possible. Ideally this would happen seamlessly behind the scenes, like with Jane Huang's event-based traceability (EBT) or thru the use of a common environment "event" catcher within Eclipse or MS Team System server. This would most likely be accomplished by using a task-based, test-driven (TDD) or feature-driven (FDD) approach.
So what are some of these specific ways of attaining lean traceability in accordance with Agile values, lean principles, the value-up paradigm, and of course the basic tenets of sound CM?
Recognize That Traceability is Not Tracing
One of the first ways is to understand and recognize the difference between traceability and tracing. Traceability is the problem that needs to be solved. Tracing is one way of solving it. Unfortunately, many of the known ways of tracing are actually what cause the familiar moans and groans when you utter the dreaded "T-word" to many developers. If we have trustworthy transparency, then traceability requires a systematic means of utilizing that transparency so that we can quickly connect the dots between any two points in the transparent information that has been made available. Trustworthy transparency is great in that it makes all the information available to us. We still have to figure out how to connect those dots, though. That is where traceability fits in: by providing us the ability to identify those paths between the "dots" that we deem to be important.
Use Version-Control and Change-Tracking Tools
What are some of those dots and some "lean ways" of connecting them? First and foremost is the fundamental practice of version control and having it integrated with basic change tracking. The version control system, its repositories, and the change-tracking system (and its repository) are the cornerstone to providing transparency into our process and its lifecycle. They capture and record the residue of our activities and outputs from the moment a request shows up on our radar. This is done through its elaboration and transformation into various lifecycle artifacts and, ultimately, into the code and tests that are integrated and built, tested, released, and promoted/delivered.
Basic Integration between Version-Control and Change-Tracking
One of the most basic ways to help connect and navigate this information is with a task-based approach that links every action and event in the version-control system with a corresponding action and event in the tracking system. This can be as simple as having the identifier of a task in the tracking system associated with every transaction in the version-control system.
As a recent real world example of good industry practice, Robert has been working with Camelot, the UK Lottery operator, on integrating Perforce's SCM tool and Serena's TeamTrack defect/issue tracker. Camelot has stringent audit requirements on their code and change control and, ultimately, is responsible to the UK's National Lottery Commission for the integrity of their systems. Perforce replaced Serena's Version Manager for SCM. The integration ensures that all developer check-ins using Perforce are associated with an approved TeamTrack issue and also with an audit trail of changes to those associations. This combines the benefits of TeamTrack's workflow capabilities with the solid SCM capabilities of Perforce.
Such integrations are successful when you:
- Minimize the replication of information between two systems (following the DRY principle) - so only those fields are replicated which are necessary
- Seek to avoid concurrent updates to particular fields - i.e. make one system the master for any replicated field
- Provide quick and simple ways (URLs work very well) to allow a user to switch from one system to the other viewing the corresponding issue or changelist(s) - manual copy and paste of an identifier, or requiring the user to search in the other system really increases resistance and slows things down
Task-Based Development (TBD)
Use of Principles of Agile Version Control: From OOD to TBD builds upon this foundation by helping to organize the structure of work in the version-control system in a manner that is easily aligned to the change tracking system. Tasks are the common thread linking work-requests to work-outputs. And if all the work-products created across the development lifecycle (requirements, models, code, tests, etc.) are in the version control repositories and are connected in this manner, then the capability to trace activities across lifecycle activities and artifact has been provided.
Test-Driven Development (TDD)
Use of Test-Driven-Development (TDD) in combination with task-based development can provide even stronger traceability support. This is because TDD basically slices the work up into very small, full lifecycle activities where each task touches only the artifacts needed to fully implement a requirement at a time. Contrast this with a strict waterfall approach where the activities that document requirements are separate from the design and code activities. In TDD, the same activity (and its ID) can easily link together all lifecycle artifacts from requirements to design, code and tests.