Traces and Traceability
As “native” trackers can tell, traceability is all about identifying the origin of the footprint and keeping on with the individuals involved. Applied to software engineering, that would entail a stable and non ambiguous taxonomy of requirements (for categories) and built-in mechanisms (for individuals).
Objectives & Categories
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 regression.
- Finally, traceability will be necessary to support maintenance and change management.
If these different concerns are to be met, the requirements taxonomy should be layered along the corresponding responsibilities: business, architectures, development, operations. That is best achieved within a basic model based systems engineering (MBSE) framework, e.g:
- Business domains and processes described by computation independent models (CIMs)
- Systems functional architecture, described by platform independent models (PIMs)
- Software components, described by platform specific models (PSMs).
Traceability can then be managed with regard to the nature of artifacts (layers) and the nature of connections: business, architectures, development, or deployment.
Individuals & Connections
While layered traceability is clearly helpful, it remains a curative policy which doesn’t address the source of the spaghetti syndrome, namely the onset of cross individual variants and the consequent exponential growth of complexity. Ideally, the only effective preventive policy would be to eliminate manually defined dependencies altogether and fully rely on built-in mechanisms to manage tracks and decisions across layers, from requirements to components. That is arguably a very ambitious objective that can only be through a staged approach. 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 supports (requirements, models, tests, software, etc) on a need-to-know basis and by so doing support lean and fit engineering processes.
From Tiered Requirements To Lean Engineering Processes
Lean systems engineering can be broadly defined with regard to time and inventories:
- Time: delays between identification of business needs and applications delivery is to be minimized.
- Inventories: managed intermediate products or documentation should be justified by governance needs, e.g like regulations or risk management.
Both aims are to be significantly furthered by managing traceability along two perspectives, one is synchronic as it must keep business and system models in sync, the other is diachronic as it is only concerned with the design and implementation of symbolic artifacts.
The aim of synchronic traceability is to map business processes to systems components independently of engineering considerations.
With regard to categories, synchronic traceability can be achieved using functional stereotypes bridging the two realms beyond the intrinsic differences of concerns.
With regard to the continuity of individual identities across layers, synchronic traceability can be achieved using structural stereotypes: 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.
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.
- 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.
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 design is best-managed independently of structures identified (#) at enterprise architecture level (c).
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).
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).
- Models, Architectures, Perspectives (MAPs)
- Architecture Capabilities
- Relating to Functions
- Capabilities vs Processes
- Enterprise Governance & Knowledge
- Enterprise Architectures & Separation of Concerns
- From Processes to Services
- EA & MDA
- EA Documentation: Taking Words for Systems
- Alignment for Dummies
- Alignment: from Entropy to Abstraction