Home | Industry Information | Business News | Browse by Publication | I | IBM Systems Journal

Model traceability.

Publication: IBM Systems Journal
Publication Date: 01-JUL-06
Format: Online
Delivery: Immediate Online Access

Article Excerpt
INTRODUCTION

Models are used in software development to manage complexity and communicate information to many stakeholders. There are models for business processes, system requirements, architecture, design, and tests. Each model has its own notation, representation, tools, and users. and...

View more below

Read this article now - Try Goliath Business News - FREE!   
You can view this article PLUS...

  • Over 5 million business articles
  • Hundreds of the most trusted magazines, newswires, and journals (see list)
  • Premium business information that is timely and relevant
  • Unlimited Access

Now for a Limited Time, try Goliath Business News - Free for 7 Days!
Tell Me More   Terms and Conditions

Purchase this article for $4.95

Already a subscriber? Log in to view full article

...Thus developers, tools, artifacts, processes are largely isolated and only weakly integrated. Interconnections are largely implicit, opening the door for inconsistencies and making it difficult to propagate change. End-to-end integration can make these relationships explicit and maintain traceability information throughout.

Model-driven development (MDD) provides an opportunity to automate both the creation and discovery of traceability relationships, and to maintain consistency among the heterogeneous models used throughout the system-development life cycle. The formality or semiformality of models makes it possible to apply analysis methods, which may then serve as a basis to automate traceability. In addition, model transformations (forward, like code generation, or backward, like reverse engineering) can be the source of generated links or mappings.

OVERVIEW

The IEEE Standard Glossary of Software Engineering Terminology (1) defines traceability as follows:

(1) The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another; for example, the degree to which the requirements and design of a given software component match; (2) The degree to which each element in a software development product establishes its reason for existing; for example, the degree to which each element in a bubble chart references the requirement that it satisfies.

This definition is strongly influenced by the originators of traceability--the requirements management community. Gotel and Finkelstein (2) define requirements traceability as follows:

... the ability to describe and follow the life of a requirement, in both a forward and backward direction; i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases.

We suggest a much broader definition of traceability. We regard traceability as any relationship that exists between artifacts involved in the software-engineering life cycle. This definition includes, but is not limited to the following:

[] Explicit links or mappings that are generated as a result of transformations, both forward (e.g., code generation) and backward (e.g., reverse engineering)

[] Links that are computed based on existing information (e.g., code dependency analysis)

[] Statistically inferred links, which are links that are computed based on history provided by change management systems on items that were changed together as a result of one change request

Traceability is achieved by defining and maintaining relationships between artifacts involved in the software-engineering life cycle during system development. In this paper, we use the words relationship and link interchangeably to denote a traceability relationship.

Traceability is mandated by many standards, such as MIL-STD-498, IEEE/EIA 12207, and ISO/IEC i2207. These standards derive from the waterfall methodology in which the role of traceability stemmed from the need to show that the resulting system met contractual agreements. Such standards reflect the view that traceability practice is a measure of system quality and software process maturity. This view is illustrated by the Software Engineering Institute's concept of Capability Maturity Model **. (3)

Different stakeholders in the software development process have different traceability goals. The project manager (4) perspective is that traceability supports demonstrating that each requirement has been satisfied and that each system component satisfies a requirement. From the perspective of requirements management, traceability facilitates linking requirements to their sources and rationales, capturing the information necessary to understand the evolution of requirements, and verifying that the requirements have been met. During design, traceability enables designers and maintainers to keep track of what happens when a change request is implemented before a system is redesigned. (5) With complete traceability, more accurate costs and schedules of changes can be determined, rather than depending on the programmer to know all the areas that will be affected by these changes.

Although the advantages are well documented, traceability practice is not widespread. The commonly stated reason is the high cost of manual creation and maintenance of traceability information. (6) In addition, the lack of guidance as to what link information should be produced and the fact that those who use traceability are commonly not those producing it also diminishes the motivation of those who create and maintain traceability information.

The development and use of techniques to trace requirements originated in the early 1970s to provide the means to answer a range of questions, such as: Is this requirement necessary? Why is the design implemented this way, and what were the other alternatives? What is the impact of changing a requirement?

The first method used to express and maintain traceability was cross-referencing. This involves embedding phrases like "see section x" throughout the project documentation. Since those days, many different techniques have been used to represent traceability relationships including standard approaches such as matrices, (7,8) databases, (9) hypertext links, (10) graph-based approaches, (11) formal methods, (12) and dynamic schemes.

Automated support for traceability began with general-purpose tools such as word processors, spreadsheets, or database systems and became easier to use with the advent of hypertext technology. Still, the major drawback of this method remains: The traceability information is created and maintained manually, as is the responsibility for managing its validity with respect to change. Thus, the traceability information quickly becomes outdated as the system evolves.

Special-purpose requirements management tools, such as IBM RequisitePro * (14) and Telelogic DOORS **, (15) is introduced more advanced traceability solutions, which support the management of traceability information validity by monitoring changes of linked elements and indicating suspect links. They also support integration with other software development tools to facilitate traceability from requirements to other products of the software life cycle. Despite these advances, the burden of keeping traceability information current remains a manual task because requirements, most commonly expressed as informal text, require a human to understand and determine link validity. In addition, most tools do not provide rich traceability schemes, thus allowing only simple forms of reasoning about traces.

STATE OF THE ART

In this section, we review the state of the art of traceability technology and methodology and the potential that MDD brings to the field. We discuss technologies to implement traceability, the latest advancements in the automatic discovery of trace relationships, and the complexities of managing traceability relationships as software artifacts evolve.

Technology

When building traceability support into their tools tool developers face several challenges. Some of the major issues stem from the need to reference software artifacts that are...

NOTE: All illustrations and photos have been removed from this article.



More articles from IBM Systems Journal
Model driven development for business performance management., July 01, 2006
UML 2: a model-driven development tool., July 01, 2006
Feature-based survey of model transformation approaches., July 01, 2006
Using logical data models for understanding and transforming legacy bu..., July 01, 2006
Multilevel models in model-driven engineering, product lines, and meta..., July 01, 2006

Looking for additional articles?
Search our database of over 3 million articles.

Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication name or publication date.

About Goliath
Whether you're looking for sales prospects, competitive information, company analysis or best practices in managing your organization, Goliath can help you meet your business needs.

Our extensive business information databases empower business professionals with both the breadth and depth of credible, authoritative information they need to support their business goals. Whether it be strategic planning, sales prospecting, company research or defining management best practices - Goliath is your leading source for accurate information.