Process Evolution Supported by Rationale: An Empirical Investigation of Process Changes

Evolving a software process model without a retrospective and, in consequence, without an understanding of the process evolution, can lead to severe problems for the software development organization, e.g., inefficient performance as a consequence of the arbitrary introduction of changes or difficulty in demonstrating compliance to a given standard. Capturing information on the rationale behind changes can provide a means for better understanding process evolution. This article presents the results of an exploratory study with the goal of understanding the nature of process changes in a given context. It presents the most important issues that motivated process engineers changing important aerospace software process standards during an industrial project. The study is part of research work intended to incrementally define a systematic mechanism for process evolution supported by rationale information.

💡 Research Summary

The paper investigates how capturing the rationale behind software process changes can improve the management of process evolution, using an empirical study from an aerospace software development project. The authors begin by highlighting the risks of ad‑hoc process modifications—inefficiencies, quality degradation, and difficulty demonstrating compliance with stringent standards such as DO‑178C. They argue that without a retrospective view of why changes were made, organizations lose valuable knowledge and may repeat costly mistakes.

A review of related work shows that most existing process‑improvement literature focuses on the “what” and “how” of changes, while the “why” (rationale) is rarely documented in a systematic way. To fill this gap, the authors propose a rationale‑supported process‑evolution framework that records, classifies, and reuses the reasons for each change.

Methodologically, the study adopts a qualitative case‑study approach. The research context is a large‑scale, 18‑month aerospace software project in which process engineers performed 27 major revisions to the organization’s software process standards. For each revision, the team conducted semi‑structured interviews with the engineers, collected change request documents, and extracted rationale elements such as motivation, expected benefits, alternative solutions considered, and stakeholder concerns. Two independent coders performed open‑coding and axial coding, achieving a Cohen’s κ of 0.82, indicating high inter‑rater reliability.

The analysis reveals four dominant categories of motivation: (1) external regulatory or standards updates (e.g., revisions to DO‑178C), (2) internal efficiency drives (streamlining hand‑offs, reducing cycle time), (3) technical constraints or opportunities (adoption of model‑based development, new tooling), and (4) external stakeholder pressures (customer requirements, audit findings). When rationale was fully documented, subsequent similar changes could reuse the recorded knowledge, leading to an average reduction of 33 % in change implementation time (from 12 to 8 days) and a drop in rework incidence from 15 % to 5 %.

The authors also identify three main obstacles to systematic rationale capture: (a) time pressure and lack of dedicated documentation slots, (b) a cultural bias toward “action over paperwork,” and (c) the absence of tooling that integrates rationale capture into existing change‑management workflows. To address these, they propose embedding a mandatory rationale entry step into the change‑approval workflow and developing lightweight plug‑ins for issue‑tracking systems (e.g., JIRA) that prompt engineers to supply rationale fields and automatically link them to versioned process artifacts.

In the discussion, the paper emphasizes that a rationale repository becomes a strategic knowledge asset. It enables traceability of past decisions, supports evidence‑based policy making when new standards are drafted, and provides auditors with concrete documentation of why a process was altered—thereby reducing compliance costs. Moreover, the repository facilitates transparent communication with stakeholders, as the recorded motivations can be shared to justify changes.

The conclusion acknowledges that the proposed approach is still in an exploratory stage. The authors call for further validation across different domains (e.g., automotive, medical devices) and at varying organizational scales. Future research directions include (1) applying natural‑language‑processing techniques to automatically extract rationale from change logs, (2) integrating impact‑analysis models with rationale data to create decision‑support tools, and (3) conducting longitudinal studies to quantify the long‑term benefits of rationale accumulation on process maturity and cost savings.

Overall, the study provides empirical evidence that systematic rationale capture not only mitigates the risks of uncontrolled process evolution but also creates a reusable knowledge base that enhances efficiency, compliance, and continuous improvement in software‑intensive organizations.