Using Developer-tool-Interactions to Expand Tracing Capabilities Dennis Ziegenhagen1;2, Andreas Speck1 and Elke Pulvermuller¨ 2 1Department of Computer Science, Christian-Albrechts-University Kiel, 24098 Kiel, Germany 2Institute for Computer Science, Osnabrueck University, Postfach 4469, 49069 Osnabruck,¨ Germany Keywords: Traceability, Tracing Data Generation, Tool Integration, Developer-tool-Interaction. Abstract: Expanding current software traceability methodologies offers opportunities to significantly support develop- ment activities. State-of-the-art traceability frameworks use tracing data at specific points in time. This data includes information about development artefacts and their relations, which may be used for analysis, visuali- sation and similar purposes. In between those points in time, developers create, modify or delete requirements, diagrams, source code and other relevant artefacts. We propose to capture such artefact interactions in order to enrich the tracing data. By applying existing approaches in the field of developer-tool interaction analysis to the enriched data, we aim at supporting the developer’s work. In this paper, we present the overall approach, along with our development of a modular framework which may be used to capture the desired data from various tools, manage it and finally enable the execution of developer-interaction analyses. 1 INTRODUCTION details on how they are changed during development. In our approach, changing an artefact leads to an auto- Applying traceability methodologies to software de- mated updating of the respective tracing data. For this velopment allows project members to gain insights reason, we call this enrichment dynamic tracing data into the involved processes and results. Depending as opposed to “static tracing”. Of course, in current on the goals of the traceability implementation, infor- traceability applications the data also changes over mation about various types of requirements, source time (and thus is not completely static), but we use code, test cases and other artefacts is collected in a this denomination to emphasise the fundamental idea structured way. Identifying, managing and updating of combining artefacts, their relations and developer- their relations throughout the development is a core tool-interactions which influence them. task in order to create the desired trace links. For a Capturing this data allows to integrate various ex- basic application, these steps may be done manually. isting approaches and findings on the interactions be- Additionally, (semi-) automated approaches are avail- tween developers and their tools. Amongst others, able, e.g. by utilising information retrieval for recov- these include supporting the developer by providing ering traceability links. Yet traceability is not broadly helpful information for accomplishing a specific task used and current analyses state necessary researches (Maalej and Sahm, 2010) and suggesting error solv- and problem areas (Cleland-Huang et al., 2014). ing solutions (Hartmann et al., 2010). Besides an ex- Since software development involves various tools tension of traceability features, the goal is to use the for particular tasks, the approach which we present combined dynamic and static data in order to enable here tries to take advantage of this. A number of them further analysis, research, and finally assist the users. offer interfaces, e.g. APIs, that can be used to access An example usage is the detection of correlating prop- the contents which the user creates using the tools. erties across tool boundaries, e.g. interdependent real- Furthermore, these interfaces may not only provide time constraints which are modelled using different data, but also enable the execution of internal func- tools (Noyer et al., 2017). tionalities. As an example, many IDEs are extensi- In this paper, we motivate the idea of capturing ble via plug-in mechanisms along with correspond- interaction events to enrich current traceability data. ing APIs. We utilise such possibilities in order to re- For this, related work in the fields of traceability and ceive information about interactions which influence interaction analysis is considered. In order to intro- traced artefacts. Thus, we enrich tracing data with duce our approach, the overall goals and general, ini- 518 Ziegenhagen, D., Speck, A. and Pulvermüller, E. Using Developer-tool-Interactions to Expand Tracing Capabilities. DOI: 10.5220/0007762905180525 In Proceedings of the 14th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2019), pages 518-525 ISBN: 978-989-758-375-9 Copyright c 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved Using Developer-tool-Interactions to Expand Tracing Capabilities tial thoughts are summarised. They form the basis age data, and “online” approaches which directly for presenting our environment for capturing and us- monitor interactions when they occur. Examples for ing the combined data. Briefly summarised, it is a the first type can be found at (Snipes et al., 2015) and modular solution to enable a flexible bridging of both (Damevski et al., 2017), who utilise data collected by areas: software traceability and developer-tool inter- IDEs. (Roehm and Maalej, 2012) show an example action analysis. An example scenario is provided to for the second type. The authors, along with others, illustrate the framework and its intended application. also present an application to support developers by using the monitored data (Roehm et al., 2013). An interesting approach of considering the mo- 2 RELATED WORK mentary used set of tools and artefacts as a context for performing a task is presented by (Maalej and Sahm, 2010). Thus, the developer’s work is struc- Considering available traceability solutions, those tured into tasks for which the involved artefacts are containing an automated tracing data generation are captured in a history-like manner. This idea has been most important for us. For example, (Neumuller¨ and carried further to analyse the suiting of traceability Grunbacher,¨ 2006) present lessons learned from de- methods for specific tasks contexts by (Li and Maalej, veloping and introducing a specialised traceability 2012). Though focusing on visualisation techniques, framework in a small company. Because the avail- their findings also provide insights in how developers able traceability environments didn’t suit the intended interact with artefacts in various tasks, e.g. design, purposes, they built a custom solution with a fo- implementation and testing. cus on automated trace acquisition. Amongst oth- ers, the authors motivate the success of their project with smoothly integrating existing development tools. Also, they preferred automating selected features in- 3 CURRENT STATE OF stead of adopting a commercial product with many TRACEABILITY probably unused functions. An overview of retrospective and prospective soft- The term traceability is used in many areas and thus ware traceability is provided by the work of (Asun- may include different scopes and methodologies, de- cion et al., 2010). The authors combine these tech- pending on the actual purpose of its usage. For ex- niques by applying topic modelling to tracing data ample, requirements traceability usually puts the life- which is recorded using various tool adapters. A dif- cycle of a project’s requirements into focus and en- ference to our approach can be found in the way work- ables forward and backward tracing of these (Go- ing with multiple projects is integrated. While Asun- tel and Finkelstein, 1994). This aims at answer- cion et al. aim at separating the tracing data of each ing higher, project-related questions, e.g. whether project from other projects, we instead use it to iden- all specified requirements have been implemented or tify cross-project relations and e.g. to provide devel- which requirements are affected by an erroneous soft- opers with problem solutions from other projects. ware module. Regarding model-driven development “SAT Analyzer” (Palihawadana et al., 2017) is an as another example, the view on traceability is a example for traceability management environments. bit more general and emphases the tracing of gener- It supports predetermined artefact types. By including ated artefacts, e.g. created during model transforma- DevOps practices, it is able to track artefact changes tion (Walderhaug et al., 2006) (Haouam and Meslati, between builds and to create tracing data based on 2016). these changes semi-automatically. Due to these varying aspects, first of all, it is Extending traceability with a developer action has necessary to define the term traceability itself and been realised by (Mahmoud and Niu, 2013). The au- its scope. Our approach considers various roles thors analyse the impact various types of refactoring of project members and their work during different have on the traceability of a software project. De- phases of software development. To enable this, we pending on the type, they observed both, positive use a broad definition of the term, which for example and negative effects during refactoring. This con- Aizenbud-Reshef et al. propose: “We regard trace- firms our assumption that considering developer in- ability as any relationship that exists between arti- teractions may be a valuable extension to the tracing facts involved in the software-engineering life cycle” methodologies. (Aizenbud-Reshef et al., 2006). Research on developer-interaction-analysis can By considering