The Journey Through Traceability to Process Control

Traceability

Traceability is a cornerstone of change management. It tells you why things have changed. It lets you identify the level of verification for particular changes. It links the Requirements and Requests of customers and product managers down through code, test cases and test run data.

Granularity

Here's an example of a fully traced system development.

• Requirement R1: Build a CM system.
• Request Q1: Make it easier to use.
• Request Q2: It's not working - We need it to work
• Activity A1: Implement R1
• Activity A2: Implement Q1
• Problem P1: It doesn't work spawned from Q2
• Problem P2: Testing failed - see R1
• Change C1: Implement A1 part 1
• Change C2: Implement A1 part 2
• Create Build B1 using C1 and C2
• Change C3: Implement A2 and fix P1 and P2
• Create Build B2 using B1 and C3
• Testcase T1: Test the system to ensure it meets R1
• Testrun TR1: System Failed T1 Testing run on B1 - Created P2
• Testrun TR2: System Passed T1 Testing run on B2

It doesn't really matter which system you're developing, you can probably shoe-horn your system into this template. The problem is, although I have full traceability, the granularity of my traceability makes the data all but useless. Granularity will certainly dictate how useful the data is.

Although the above example gives little traceability information, it does cover a lot of bases. It identifies the fact that Requirements (Rs) and Requests (Qs) are needed for development to proceed. It shows that the Rs and Qs spawn design Activities (As) and Problem Reports (Ps). It shows that Changes (Cs) address the As and Ps. It shows that Builds (Bs) are created with certain Cs. It shows that Test Cases (Ts) address Rs. It shows that Test Runs (TRs) run Ts using Bs and spawn Ps where necessary.

There are a lot of traceability items here - and we haven't even mentioned source code. The goal is to get the right level of granularity and process so that this simple example expands to adequately express your development.

Process and Relationships

Many newer projects are afraid of all of these relationships. They just want files glued together with Make files. That's how their developers work after all. And there's nothing wrong with that - as long as the developers design whatever they want and never deliver it to anyone.

But all of these relationships are required (and perhaps a few more). The business decides what business it's in and develops products to meet the target market. Product requirements are broken down and turned into design activities. These are implemented as a series of changes, perhaps broken up into several major and minor releases. And so forth.

So where do you start? We can start from the inside out. Have developers work on and check in changes. A change packages new revisions of files together for a particular reason (or set of reasons if you allow less granular traceability). Start there. Make sure you're starting with change packages so that you can manage changes through your system. Otherwise you'll be managing file revisions through your system and that's a much more complex task (although maybe it's easier for a basic version control tool, like CVS or VSS, to support).

Then formalize your reasons. When a change is created, have a rule that it must have reasons. That is, it must reference one (or more) problem report or activity. Problem reports should always be reproducible problem descriptions. Activities may be coarse granularity to start out, but you'll quickly find the benefit of sub-dividing such activities into smaller tasks.