Difference between revisions of "Main Page"

From Coest Body of Knowledge
Jump to: navigation, search
m (What is Traceability?)
(What is Traceability?)
(36 intermediate revisions by 2 users not shown)
Line 4: Line 4:
 
== What is Traceability? ==
 
== What is Traceability? ==
  
There are many definitions of software traceability; however we define 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."
+
Software traceability is "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."  
  
Navigable links must be created between artifacts that are otherwise disconnected. Establishing these links can enable a better evaluation of a system. (Is the system doing what it was built to do?)
+
Traceability is a '''required component of the approval and certification process''' in most safety-critical systems. For example, the DO-178C
 +
standard, which the USA Federal Aviation Administration (FAA) has established as the means of certifying that software aspects of airborne systems comply with airworthiness requirements, specifies a very detailed set of traceability requirements including the need to provide traceability between source code and low-level requirements" in order to enable verification of the absence of undocumented source
 +
code and verification of the complete implementation of the low-level requirements." Similarly, the USA Food and Drug Administration (FDA) states that traceability analysis must be used to verify that the software design implements the specified software requirements, that all aspects of the design are traceable to software requirements, and that all code is linked to established specifications and test procedures.
  
Traceability helps to determine whether or not a given system is doing its job.
+
Traceability involves four primary activities of [[strategic planning]], [[link creation]], [[link maintenance]], and [[link usage]].
 +
IMAGE COMING HERE.  
  
 +
Watch this space as we start to populate it with news of exciting traceability projects.
  
Example:  Every system that you design has what are called ''requirements''.  These are the things that the system needs to be able to do.  For example, Facebook needs to have mechanisms for people to post, and then for people to see others' posts and leave comments.  The program controlling the temperature in an isolette in a hospital must have a Thermostat that sets its temperature. This would be listed as a system requirement. We'll call this system requirement 1, or SR1.
+
CoEST has created a [http://coest.org/index.php/traceability/glossary glossary of traceability terms.]
  
SR1: The thermostat must set the value of the heat control.
+
   
  
Here are some more system requirements:
 
  
SR2: The thermostat function must set the value of the operator feedback (What does that mean)
 
  
SR3: The isolette shall include an independent Thermostat Function that maintains the current temperature within the desired temperature range inside the isolette(Note: this requirement is derived from SR1.)
+
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 retrievableA user-friendly system for processing and understanding these links must be developed.
  
SR4:  An independent monitor function shall activate an alarm within 5 seconds whenever the current temperature inside the Isolette falls below or rises above the Alarm temperature range. (Derived)
+
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?]
  
SR5: An alarm shall sound when the current temperature is flagged as invalid. (Derived)
+
Traceability design must respond to the particular needs of a system's stakeholders; a traceability system built to suit all needs would be prohibitively expensive.
  
What are the things that could go wrong in such a system?  In this case, the isolette could have the wrong temperature, and expose the infant to unsafe heat or cold.  We'll identify this as Hazard 1, or H1. This hazard is the result of a system requirement that has not been met, in this case SR4. (SR5?)
+
 
 +
 
 +
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 ==
 
== Components of Traceability ==
  
'''Trace Artifact: ''' units of data that are amenable to being traced. Often, what constitutes an artifact (the project as a whole? Some element of the project?) is not predetermined, which makes traceability within the project more challenging. 
+
'''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.]
 +
 
 +
==Options for Traceability Design ==
 +
 
 +
'''Trace capture:''' implies the creation of trace links ''concurrently'' with the artifacts that they associate
 +
vs.
 +
'''Trace recovery:''' implies the creation of trace links after the artifacts that they associate have been generated and manipulated.
 +
 
 +
 
 +
'''Continuous traceability maintenance:'''  The update of impacted trace links immediately following changes to trace artifacts.
 +
vs.
 +
'''On-demand traceability maintenance:''' A dedicated and overall update of the trace set, generally in response to some explicit trigger.
 +
 
 +
 
 +
'''Vertical tracing''':links artifacts at differing levels of abstraction vs '''Horizontal tracing:'''liking artifacts at the same level of abstraction at different moments in time to accommodate versioning and rollback.
 +
 
 +
 
 +
'''Trace granularity:''' The level of detail at which a trace is recorded and performed.
 +
 
 +
==Requirements for an Effective Traceability Strategy ==
 +
 
 +
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?
  
'''Source Artifact:''' Where the trace starts.
+
Which tracing activities should be manual? Which should be automatic?
  
'''Trace:''' The data in question.
+
Making links within a massive volume of data, and then understanding the implications of those links.
  
'''Target Artifact:''' Where the data ends up.
+
Categorizing and storing the links.
  
== Examples ==
+
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 that those designing traceability strategy in a system understand the needs of that system's stakeholders.
  
== Challenges ==
 
Tracing is often done ad-hoc, after the fact.  Since it can be costly to make a system exhaustively traceable, it must be determined what the needs are of the system or stakeholder: what information needs to be tracked?
 
  
  

Revision as of 01:49, 6 May 2014

Under Construction


What is Traceability?

Software traceability is "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."

Traceability is a required component of the approval and certification process in most safety-critical systems. For example, the DO-178C standard, which the USA Federal Aviation Administration (FAA) has established as the means of certifying that software aspects of airborne systems comply with airworthiness requirements, specifies a very detailed set of traceability requirements including the need to provide traceability between source code and low-level requirements" in order to enable verification of the absence of undocumented source code and verification of the complete implementation of the low-level requirements." Similarly, the USA Food and Drug Administration (FDA) states that traceability analysis must be used to verify that the software design implements the specified software requirements, that all aspects of the design are traceable to software requirements, and that all code is linked to established specifications and test procedures.

Traceability involves four primary activities of strategic planning, link creation, link maintenance, and link usage. IMAGE COMING HERE.

Watch this space as we start to populate it with news of exciting traceability projects.

CoEST has created a glossary of traceability terms.



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 retrievable. 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 particular needs of a system's stakeholders; a traceability system built to suit all needs would be prohibitively expensive.


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

Options for Traceability Design

Trace capture: implies the creation of trace links concurrently with the artifacts that they associate vs. Trace recovery: implies the creation of trace links after the artifacts that they associate have been generated and manipulated.


Continuous traceability maintenance: The update of impacted trace links immediately following changes to trace artifacts. vs. On-demand traceability maintenance: A dedicated and overall update of the trace set, generally in response to some explicit trigger.


Vertical tracing:links artifacts at differing levels of abstraction vs Horizontal tracing:liking artifacts at the same level of abstraction at different moments in time to accommodate versioning and rollback.


Trace granularity: The level of detail at which a trace is recorded and performed.

Requirements for an Effective Traceability Strategy

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 that those designing traceability strategy in a system understand the needs of that system's stakeholders.










MediaWiki has been successfully installed.

Consult the User's Guide for information on using the wiki software.

Getting started