What is Traceability?
There are many definitions of software traceability; CoEST defines it as "the ability to interrelate any uniquely identifiable software engineering artifact to any other, maintain required links over time, and use the resulting network to answer questions of both the software product and its development process."
To make a system traceable, navigable links must be created between artifacts that are otherwise disconnected, i.e. requirements, code, and test cases. [Example]. These links must be documented,stored and easily retrieval. A user-friendly system for processing and understanding these links must be developed.
Traceability is a required component of the approval and certification process in most safety-critical systems, where systems must demonstratively meet a set of standards and mitigate any potential hazards. Codes and test cases must be linked to a requirement of the system. [Expand on this with isolette example?]
Traceability design must respond to the needs of a system's stakeholders; a traceability system built to suit all needs would be prohibitively expensive.
In practice, relatively few systems have meaningfully benefited from traceability. Producers of medical equipment, for example, typically create and document traceability information immediately prior to the certification process, and the resulting data is often incomplete, incorrect, or contradictory.
CoEST's vision is that traceability strategy become a built-in, implicit part of systems in a way that is cost-effective and responsive to the needs of stakeholders.
Components of Traceability
Trace Artifact: units of data that are amenable to being traced. The granularity of a trace artifact can vary, even within a given project.
Source Artifact: The origin of a trace.
Trace link: Association between source and target artifacts.
Target Artifact: The destination of that trace. [Example?]
Link direction: Either primary (source to target) or reverse (target to source).
Trace: A specified triplet of elements: the source artifact, trace link, and target artifact. This can also be referred to as an atomic trace.
A chained trace refers to a group of atomic traces strung in a sequence, where a target artifact becomes the source artifact for another target artifact. [Illustration here.]
Types of Traceability Design
Trace capture: implies the creation of trace links concurrently with the artifacts that they associate
Trace recovery: implies the creation of trace links after the artifacts that they associate have been generated and manipulated.
A traceability strategy must be designed to enable the following:
Retaining artifacts within a system
Developing capacity to establish meaningful links between the artifacts
Making links between different types of artifacts (regulations and code, for example)
Developing procedures for analyzing traces.
What granularity is the project working at? How are we categorizing these artifacts? How are we storing them?
Which tracing activities should be manual? Which should be automatic?
Making links within a massive volume of data, and then understanding the implications of those links.
Categorizing and storing the links.
Deciding what should be automated and what should be manual, and then deciding who should be responsible for maintaining traceability within the system.
It is essential to understand the needs of the stakeholders when creating a traceability strategy.
MediaWiki has been successfully installed.
Consult the User's Guide for information on using the wiki software.