The Trouble with Tracing: Traceability Dissected

is devoted to creating knowledge that transforms fuzzy functional concepts into tangible working results. Software development then becomes the process of transforming theoretical concepts into executable reality.

Armour goes on to describe "The Five Orders of Ignorance" and how, if software development is a process of knowledge-acquisition and knowledge-creation, then it is also ultimately a process of "ignorance reduction" whereby we progressively reduce our ignorance of what the system is, what it needs to do, how it needs to do it, and how we need to do it and manage it. These five orders of ignorance are:

    • 0th Order Ignorance (0OI) – Lack of Ignorance: I know something
    • 1st Order Ignorance (1OI) – Lack of Knowledge: I don’t know something
    • 2nd Order Ignorance (2OI) – Lack of Awareness: I don’t know that I don’t know something
    • 3rd Order Ignorance (30I) – Lack of Process: I don’t know of a suitably efficient or systematic way to find out that I don’t know that I don’t know something
    • 4th Order Ignorance (40I) – Meta Ignorance: I don’t know about the Five Orders of Ignorance

Perhaps it should follow then, as a corollary to all of this, that the goal of traceability is to connect all the dots between these various pieces and "orders" of knowledge to help those of us auditing or reviewing them to learn the lessons of how and why that knowledge came to be created in its current form.

Traceability attempts to reveal knowledge that is otherwise opaque or translucent, and make it transparent so that it is visible to all stakeholders concerned.

To that end, I hereby propose The Five Orders of Traceability :

    • 0th Order Traceability – Existence: Tracking Knowledge Content
    • 1st Order Traceability – Structure: Tracking Knowledge Composition
    • 2nd Order Traceability – History: Tracking Knowledge Context
    • 3rd Order Traceability – Transformation: Tracking Knowledge Creation (causal connection in the knowledge creation/derivation process)
    • 4th Order Traceability – Meta-Traceability: Tracking Knowledge of the Five Orders of Traceability.

It's not entirely clear to me whether I have the 2nd and 3rd items mixed-up in the above (perhaps structure should come after context). When deriving the ordering and identification of the above, I basically took my cue from Armour's 5 orders of ignorance, and made the assumption that it is the intent of a particular "order" of traceability to eliminate or address the corresponding "order" of ignorance! Hence 3rd order traceability should help resolve 3rd order ignorance, 2nd order traceability should help resolved 2nd order ignorance, and so on.

With that in mind, I'll elaborate further upon each of the five orders of traceability I’ve "coined" above ….

0th Order Traceability is merely the existence of knowledge content. There are no additional linkages or associations to navigate through that content. There is no explicit traceability; the content is simply there.

1st Order Traceability is an attempt to structurally organize the knowledge content and provide links that navigate the decomposition from one level of organization/detail to another. This would be like an outline structure and cross-referencing/indexing capabilities. A number of tools give us a means of organizing a particular portion of system knowledge:

    • Basic requirements document management tools provide way of organizing and viewing the requirements, and even design documentation for a project
    • Modeling tools provide a way of organizing and viewing problem-domain and solution-domain abstractions
    • Many interactive development environments give a logical (e.g., object-based) view of the code and/or a physical (e.g., file-based) view of the file and folder structure of the codebase.
    • Many of these tools even provide a way to link from a section of a document to a

About the author

Steve Berczuk's picture
Steve Berczuk

Steve Berczuk is an engineer and ScrumMaster at Humedica where he's helping to build next-generation SaaS-based clinical informatics applications. 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

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 bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

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.