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
1839118838
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.