traceability: an overview advisor silvio lemos meira srlm@cin.ufpe.br student jorge mascena...

Traceability: An Overview

AdvisorSilvio Lemos Meira

srlm@cin.ufpe.br

StudentJorge Mascenajccpm@cin.ufpe.br

Agenda

• Introduction• Software Maintenance• Change Impact• Traceability• Software Product Families• Summary

Introduction

• [Lago, 2004]•“In software product families, the full benefit of reuse can only be achieved if traceability of requirements to architecture, components and further down to source code is supported.”

Introduction

• Traceability has been generally associated to software maintenance•Source code change propagation

[Hassan, 2004] [Kowalczykiewicz, 2002] [Chen, 2001] [Eisenbach, 2001] [Gwizdala, 2003] [Zimmermann, 2004]

Introduction

• Traceability has been generally associated to software maintenance•Change impact analysis [Antoniol,

1999] [Elbaum, 1998] [Mockus, 2000] [Gall, 1999] [Bohner, 2002] [Clarke, 2003] [Briand, 2003] [Gold, 2003]

Software Maintenance {History}

• [Kilpi, 1997]•“Software industry is developing

strongly towards becoming a product business.”

•“This lays increasing demands for the development of software product management process and its tool support in the companies“

Software Maintenance {History}

• Attempts to manage software development complexity are paperwork-oriented [Kowalczykiewicz, 2002]•“US Dept. of Defense spends about

4% of its IT costs on traceability, getting inadequate value from that money”

• Tool support is restricted basically to version control systems [Kilpi, 1997]

Software Maintenance {History}

• “Software maintenance is an important part of the software lifecycle, typically accounting for at least 50 percent of the total lifetime cost of a software system” [Gold, 2003]

Software Maintenance {Types}

• The type of maintenance has effects on the cost of the change [Mockus, 2000] [Souza, 1998]

• Classifications vary, most common one•Corrective•Adaptive•Inspection•Perfective

Software Maintenance {Types}

•Corrective changes are generally harder than other types [Mockus, 2000]

•Adaptive changes take most of the time during maintenance [Souza, 1998]

•Perfective and inspection changes usually have small impact [Souza, 1998]

Software Maintenance {Models}

•[Souza, 1998]•Quick-fix model is the most used one (no documentation update)

•Metrics-based impact analysis is rarely done

•Source code is the most used source of knowledge

•Most of the time is spent in change comprehension

Change Impact {Cycle}

•[Gwizdala, 2003] [Chen, 2001] Cycle of an incremental change•Change request (free text)•Concept location

•top-down•bottom-up•backward data flow•forward data flow

Change Impact {Cycle}

•[Gwizdala, 2003] [Chen, 2001] Cycle of an incremental change•Concept actualization (implementation)

•Incorporation (replacement of old version)

•Change propagation (keep code consistent)

Change Impact {Metrics}

•[Elbaum, 1998]•“The introduction of new code, however, is just as error prone a process as was the initial code generation”

•Metrics estimate code complexity and fault injection/removal rates

•“The general notion of software test is that the rate of fault removal will generally exceed the rate of fault injection”

Change Impact {Visualization}

•“In evolving through releases, developers modify system structure and properties. Tracking their historical evolution allows the programmer to document the events that influenced the system evolution and to identify the reasons for structural problems” [Gall, 1999]

Change Impact {Visualization}

•Version tracking visualization requires abstraction, navigation and automation [Antoniol, 1999]

•2-D and 3-D graphics are commonly used (time as the third dimension) in conjunction with color scales to alleviate the process of thinking of abstract information [Gall, 1999]

Change Impact {Comprehensibility}

•“The high cost and central role of comprehension within software maintenance has been recognized by many authors and has been attributed to software complexity” [Gold, 2003]

•Source code becomes more complex and documentation becomes outdated as software evolves.

Change Impact {Comprehensibility}

•[Gold, 2003] shows that it’s important to trace concepts to indicators in source code (comments, indentation, variable names, typical code fragments etc.) in order to improve comprehensibility

•Characterization of concept evolution•Add/Delete•Geometry•Assignment

Traceability {Level}

•Most research on traceability is focused on the source code level [Antoniol, 1999] [Hassan, 2004] [Chen, 2001] [Eisenbach, 2001] [Gwizdala, 2003] [Clarke, 2003]

•Recent work shifted focus to the whole development cycle [Briand, 2003] [Kowalczykiewicz, 2002] [Zimmermann, 2004]

•Traceability for product family development is the new trend [Lago, 2004]

Traceability {Change Propagation}

•“… a machine and a mind can beat a mind-imitating machine working by itself” [Chen, 2001]

•Change propagation tools help developers in finding ripple effects of changes•History-based [Hassan, 2004] [Zimmermann, 2004]

•Structure-based [Chen, 2001] [Eisenbach, 2001] [Gwizdala, 2003] [Briand, 2003]

•Protocol-based [Kowalczykiewicz, 2002]

Traceability {Change Propagation}

•Precision and recall are used to estimate the performance of change propagation detection methods

•Statistics and heuristics to prune false positives

Traceability {Change Propagation}

•May be used to prevent error caused by missing changes [Zimmerman, 2004]•Must keep false alarms at a low rate to avoid spoiling developers confidence on the tool

Software Product Families

•[Lago, 2004]•“The development of a product family is time-consuming and expensive, and repayment can happen only if its features, architecture and components are used several times…”

Software Product Families

•Still open issues•How to trace features all the way down to source code

•Be certain that a proper set of variable features are incorporated in a product

•Tool support is mandatory•Current notations don’t have tool support

Software Product Families

•Mapping features to an architectural style for a new product of the family

•Mapping features to components•Feature clustering reduces the number of combinations

•Product Family level•Product family feature map (PF FM)

Software Product Families

•Product level•Product feature map•Product component map (CM)

•Implementation level•COTS•Source code•Documentation

•Top-down and bottom-up traceability

Software Product Families

•Versioning still not supported•Relies on developer to populate the

families manually

Summary

•Traceability is fundamental for maintenance and reuse (product families)

•Fully automated traceability is not practical

•Tool support still not a reality•Focus must shift from source code to

a broader context (top-down and bottom-up traceability)

References

• [Kilpi, 1997] Kilpi, Tapani. New Challenges for Version Control and Configuration Management: A Framework and Evaluation. IEEE,1997.

• [Lago, 2004] P. Lago, E. Niemela, H. Van Vliet. Tool Support for Traceable Product Evolution. Proceedings on the Eigth European Conference on Software Maintanance and Reengineering. IEEE, 2004.

• [Hassan, 2004] Ahmed E. Hassan, Richard C. Holt. Predicting Change Propagation in Software Systems. Proceedings of the International Conference on Software Maintenance. IEEE, 2004.

• [Kowalczykiewicz, 2002] Krysztof Kowalczykiewicz, Dawid Weiss. Traceability: Taming uncontrolled change in software development. IV Krajowa Konferencja Inzynierii Oprogramowania. Poznan, 2002.

• [Chen, 2001] Kunrong Chen, Václav Rajlich. RIPPLES: Tool for Change in Legacy Software. 2001.

• [Eisenbach, 2001] Susan Eisenbach, Chris Sadler. Changing Java Programs. 2001.

References

• [Gwizdala, 2003] Steve Gwizdala, Yong Jiang, Václav Rajlich. Jtracker: A Tool for Change Propagation in Java. Proceedings of the Seventh European Conference on Software Maintenance and Reengineering. IEEE, 2003.

• [Zimmermann, 2004] Thomas Zimmermann, Peter Weizgerber, Stephen Diehl, Andreas Zeller. Mining Version Histories to Guide Software Changes. Proceedings of the 26th International Conference on Software Engineering. IEEE, 2004.

• [Antoniol, 1999] G. Antoniol, G. Canfora, A. De Lucia. Maintaining Traceability During Object-Oriented Software Evolution: a Case Study. 1999.

• [Elbaum, 1998] Sebastian G. Elbaum, John C. Munson. Code Churn: A Measure for Estimating the Impact of Code Change. 1998.

• [Mockus, 2000] Audris Mockus, Lawrence G. Votta. Identifying Reasons for Software Changes Using Historic Databases. 2000.

• [Gall, 1999] Harald Gall, Mehdi Jazayeri, Claudio Riva. Visualizing Software Release Histories: the Use of Color and Third Dimension. 1999.

References

• [Bohner, 2002] Shawn A. Bohner. Software Change Impacts: An Evolving Perspective. Proceedings of the International Conference on Software Maintenance. IEEE, 2002.

• [Clarke, 2003] Peter Clarke, Brian Malloy, Paul Gibson. Using A Taxonomy Tool To Identify Changes In OO Software. Proceedings of the Seventh European Conference On Software Maintenance And Reengineering. IEEE, 2003.

• [Briand, 2003] L. C. Briand, Y. Labiche, L. O’Sullivan. Impact Analysis and Change Management of UML Models. Proceedings of the International Conference on Software Maintenance. IEEE, 2003.

• [Gold, 2003] Nicolas Gold, Andrew Mohan. A Framework for Understanding Conceptual Changes in Evolving Source Code. Proceedings of the International Conference on Software Maintenance. IEEE, 2003.

• [Souza, 1998] Maria João Castro Souza, Helena Mendes Moreira. A Survey on the Software Maintenance Process. IEEE, 1998.