Traceability

Objectives

Traceability is meant to support four main purposes:

  • To begin with, system requirements must be justified and traced back to business goals and stakeholders.
  • Then, project planning will use dependencies to set development schedules and allocate resources.
  • One step further, quality planning will need traceability to design tests and limit regressions.
  • Finally, traceability will be necessary to support maintenance and change management.

Traceability: how did we get here and how to get out.

Traces and Traceability

If the “spaghetti” syndrome is to be avoided, traceability must be layered and supported by built-in mechanisms.Layered traceability organizes dependencies depending on their nature:

Dependencies & Model Engineering

While layered traceability is clearly helpful, it remains a curative policy which doesn’t address the source of the spaghetti syndrome, namely the manual onset of dependencies and the consequent exponential growth of complexity.Ideally, the only effective preventive policy would be to eliminate manually defined links altogether. One would use built-in features to derive traceability links from qualified requirements. That is arguably a very ambitious objective and a staged approach is necessary.A first step would be to classify dependencies depending on their nature:

  • Reference dependencies (functional or structural) are derived from models and can therefore be managed through built-in mechanisms.
  • Inheritance dependencies are the result of modelling decisions (generalization or specialization) and their traceability through built-in mechanisms depends on the rationale supporting abstractions.
  • Engineering dependencies are set along development flows, either by transformation or by decision (analysis or design). The former can be fully documented by the parameters or inputs utilized; the latter must also include the rationale supporting the decision.

Yet, the real prize of layered dependencies would be to manage tiered requirements on a need-to-know basis and by so doing support lean and fit engineering processes.

From Tiered Requirements To Lean Engineering Processes

Whatever the nature, one should always be able to set apart dependencies affecting the architecture. Relevant requirements would be fenced off within a waterproof ring, and then be qualified by non ambiguous architectural constructs with semantics pertaining all along the modelling life cycle.For that purpose it is necessary to qualify requirements with proper representation stereotypes, i.e ones directly meaningful for business analysts while unambiguously useful for system architects and designers.

Engineering processes are set along two perspectives, the first one is synchronic as it must keep business and system models in sync,  the second one is diachronic as it is only concerned with the design and implementation of symbolic artifacts. Arguably, it would help to manage traceability accordingly.

Synchronic traceability can be organized along different layers: containment, representation units, connectors, and artifacts use and reuse.

  • Containment dependencies are set by organization (responsibility for symbolic descriptions of objects and activities) and location (for actual entry points and control units).
  • Representation dependencies describe how actual anchors (objects and processes) are mapped to their system counterpart, persistency units, execution units, roles, and events. That will be used to trace requirements to functional architecture.
  • Connection dependencies are about links between independently identified units: channels (=), references (#), flows (), state transitions (//). Since connectors can be structured using the same set of standard operators used for targeted anchors, transparency and traceability are not hampered.

Representation and connection dependencies

While synchronic  dependencies take roots in business requirements and bind actual objects and processes with their symbolic counterpart (a), diachronic ones are defined between artifacts and introduced at model level:

  • Processing states use events and symbolic activities (b).
  • Processing states are used to describe the behavior of actual or symbolic objects (c).
  • Types and semantics: once identified, persistency and execution units are associated with features and operations whose semantics is defined independently, usually at domain level. Their use can therefore be traced to their different contexts, persistent or transient (d).
  • Structure: persistency and execution units can be structured using the same set of standard operators, enabling transparency across objects and processes structures.
  • Generalization/Specialization.
  • Constraints and rules.

Given the distinction between core syntactic constructs and  layered semantics, those dependencies can be natively supported by UML# modeling tools, providing a built-in traceability of requirements.

Built-in Requirements Traceability

Built-in traceability is a by-product of layered modelling and the stereotyped connectors applied uniformly. With model semantics set under a common roof, from requirements to deployments, dependencies can be weaved within model fabric using the same syntactic constructs and semantic stereotypes.

Built-in traceability: the semantics of stereotyped connectors is set by context.

One step further, assuming object oriented concepts are consolidated all along the engineering process, traceability may be applied selectively to architectural components on one hand, aspects on the second one:

  • Architectural components are identified by business processes (a) and their implementation (d) must support continuity and consistency across architecture layers.
  • Aspects are identified by use cases (b) and their implementation (c) is best managed independently of enterprise architecture.

IT Governance and Traceability

Traceability is only a means to an end, namely the governance of information systems, and that should be done according two criteria: architecture level (enterprise, systems, platforms) and type of risk and dependency (decision-making, development, operational contexts).

cccc

Traceability and Governance

Decisions entail knowledge and authority. At enterprise level it’s about requirements, business or otherwise; at system level it’s about design; and at platform level it’s about deployment.

Development entails information and responsibility. At enterprise level it’s about the way systems are used to support business processes; at system level it’s about the (re)use of software assets; at platform level it’s about transformations and the use of automated tools.

Operational dependencies are about regulations (enterprise level), standards (system level) and interoperability (platform level).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 298 other followers

%d bloggers like this: