Software engineers working in large projects must navigate complex information landscapes. Change Impact Analysis (CIA) is a task that relies on engineers' successful information seeking in databases storing, e.g., source code, requirements, design descriptions, and test case specifications. Several previous approaches to support information seeking are task-specific, thus understanding engineers' seeking behavior in specific tasks is fundamental. We present an industrial case study on how engineers seek information in CIA, with a particular focus on traceability and development artifacts that are not source code. We show that engineers have different information seeking behavior, and that some do not consider traceability particularly useful when conducting CIA. Furthermore, we observe a tendency for engineers to prefer less rigid types of support rather than formal approaches, i.e., engineers value support that allows flexibility in how to practically conduct CIA. Finally, due to diverse information seeking behavior, we argue that future CIA support should embrace individual preferences to identify change impact by empowering several seeking alternatives, including searching, browsing, and tracing.
In the 2000s, the growing interest in agile development methods made many organizations downplay traceability. Agile developers often consider traceability management to be a burdensome activity that does not generate return on investment @cite_8 . Still, traceability remains non-negotiable in development of safety-critical systems. Safety standards such as ISO 26262 in the automotive industry ISO 26262-1:2011 Road vehicles -- Functional safety and IEC 61511 in the process industry sector IEC 61511-1 ed. 1.0 Safety Instrumented Systems for the Process Industry Sector explicitly requires traceability through the development lifecycle.
@cite_8
2964064835 1839118838 2766319419 1555930296
Software and systems traceability is widely accepted as an essential element for supporting many software development tasks. Today's version control systems provide inbuilt features that allow developers to tag each commit with one or more issue ID, thereby providing the building blocks from which project-wide traceability can be established between feature requests, bug fixes, commits, source code, and specific developers. However, our analysis of six open source projects showed that on average only 60 of the commits were linked to specific issues. Without these fundamental links the entire set of project-wide links will be incomplete, and therefore not trustworthy. In this paper we address the fundamental problem of missing links between commits and issues. Our approach leverages a combination of process and text-related features characterizing issues and code changes to train a classifier to identify missing issue tags in commit messages, thereby generating the missing links. We conducted a series of experiments to evaluate our approach against six open source projects and showed that it was able to effectively recommend links for tagging issues at an average of 96 recall and 33 precision. In a related task for augmenting a set of existing trace links, the classifier returned precision at levels greater than 89 in all projects and recall of 50 . Agile methods are becoming an increasingly mainstream approach to software development. They are characterized by short iterations with frequent deliverables, test-driven development, lightweight documentation, and frequent interactions with the customer. Perhaps unsurprisingly, traceability is often seen as unnecessary and therefore unwanted in agile projects. This is due to the perceived overhead of creating and maintaining traceability links and the assumption that agile developers have sufficient understanding of a project to implement a change without the support of previously defined traceability links. This chapter explores the challenges, benefits, techniques, and processes of tracing across a broad spectrum of agile projects. Traceability provides support for diverse software engineering activities including safety analysis, compliance verification, test-case selection, and impact prediction. However, in practice, there is a tendency for trace links to degrade over time as the system continually evolves. This is especially true for links between source-code and upstream artifacts such as requirements --- because developers frequently refactor and change code without updating the links. In this paper we present TLE (Trace Link Evolver), a solution for automating the evolution of bidirectional trace links between source code classes or methods and requirements. TLE depends on a set of heuristics coupled with refactoring detection tools and informational retrieval algorithms to detect predefined change scenarios that occur across contiguous versions of a software system. We first evaluate TLE at the class level in a controlled experiment to evolve trace links for revisions of two Java applications. Second, we comparatively evaluate several variants of TLE across six releases of our in-house Dronology project. We study the results of integrating human analyst feed back in the evolution cycle of this emerging project. Additionally, in this system, we compare the efficacy of class-level versus method-level evolution of trace links. Finally, we evaluate TLE in a larger scale across 27 releases of the Cassandra Database System and show that the evolved trace links are significantly more accurate than those generated using only information retrieval techniques. Traceability is a key issue to ensure consistency among software artifacts of subsequent phases of the development cycle. However, few works have so far addressed the theme of tracing object oriented (OO) design into its implementation and evolving it. This paper presents an approach to checking the compliance of OO design with respect to source code and support its evolution. The process works on design artifacts expressed in the OMT (Object Modeling Technique) notation and accepts Cpp source code. It recovers an “as is” design from the code, compares the recovered design with the actual design and helps the user to deal with inconsistencies. The recovery process exploits the edit distance computation and the maximum match algorithm to determine traceability links between design and code. The output is a similarity measure associated to designdcode class pairs, which can be classified as matched and unmatched by means of a maximum likelihood threshold. A graphic display of the design with different green levels associated to different levels of match and red for the unmatched classes is provided as a support to update the design and improve its traceability to the code.