Lean-Agile Traceability: Strategies and Solutions

[article]

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.

<--pagebreak-->
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.

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03