The Trouble with Tracing: Traceability Dissected

recently, SWEBOK adds process management, and build & release management. Susan Dart gives what is probably the definitive description of the functions of Software CM and what it adds to traditional CM . She cites the basic four functions of CM from early standards, and then goes on to add:

• Manufacturing: managing the construction and integration/assembly of product builds and releases for one or more architecture/technology platforms, production environments, test environments, and market/customer variants

• Process Management: ensuring the correct execution of the organization's procedures, policies, and life-cycle model
• Team Work: controlling the work and interactions between multiple developers/engineers and multiple teams collaborating and coordinate their efforts to develop, test and deploy the product

That tells us about what services SCM should be providing, but what does it tell us about who is served by it, and how?

The Six Facets of Traceability
So what are the main stakeholder needs and views that traceability supposedly serves in performing CM and delivering value to the customers and the business? Based on sources like CMMI, SWEBOK, and several others, I think the difference facets of traceability are as follows:

• Change Dependency Analysis : assess the impact and risk of a proposed change to facilitate communication, coordination and estimation {show the "know-how" to "know-what" to change, "know-where" to change it, and "know-who" will change it}
• Product Conformance : assure that necessary and sufficient requirements were implemented, and ensure the implementation of each requirement was verified/validated {prove we "did the right things" and "did the things right"}
• Process Compliance : assure that the necessary procedural activities (e.g., reviews and tests) were executed for each feature/requirement/code-change and ensure they were executed satisfactorily {prove we "walk the walk" and not just "talk the talk"}
• Project Accountability : assure that each change of each artifact was authorized and ensure that they correspond to requested functionality/business-value {safeguard against "gold plating"}
• Baseline Reproducibility : assure that the elements necessary to reproduce each baseline have been captured and ensure that the baselines can be reproduced {so "all the king's horses and all the king's men" can put your fallen "humpty-dumpty" build back together again}
• Organizational Learning : assure that the elements necessary to rediscover the knowledge of the system have been captured and ensure that the rationale behind critical decisions can be reproduced -- e.g., for root-cause analysis, or to transfer system knowledge to a deployment/support team. {"know-why" you did what you did when you did it}

I limited myself to "six" because I view these six as indicative of the canonical set of stakeholder views/dimensions of CM: product, process, project, organization, environment, and evolution (change). (This also somewhat matches the 6 perspectives of the Zachman Information/Enterprise Architecture Framework ).

The Five Orders of Traceability
Thus far, we’ve covered the basics of traceability regarding what it does, why it’s useful, why it’s painful, what functions it serves, and which stakeholders it serves. Now it’s time to delve deeper into what is really happening with traceability, and how much and how deep we really should be attempting to trace.

Phil Armour , in his magnificent book The Laws of Software Process , maintains that software is not a "product" in the usual production-oriented sense of the word, but that software is really a medium for capturing executable knowledge. He then uses this to derive that software is therefore not a product-producing activity but rather a knowledge creating and knowledge acquiring activity.

Couched in these terms, traceability is supposed to help us track and link related pieces of knowledge as we progress through the software development lifecycle. The software development lifecycle