Acquisition of a Project-Specific Process

Currently, proposed development processes are often considered too generic for operational use. This often leads to a misunderstanding of the project-specific processes and its refuse. One reason for non-appropriate project-specific processes is insufficient support for the tailoring of generic processes to project characteristics and context constraints. To tackle this problem, we propose a method for the acquisition of a project-specific process. This method uses a domain-specific process line for top-down process tailoring and supports bottom-up refinement of the defined generic process based on tracking process activities. The expected advantage of the method is tailoring efficiency gained by usage of a process line and higher process adherence gained by bottom-up adaptation of the process. The work described was conducted in the automotive domain. This article presents an overview of the so-called Emergent Process Acquisition method (EPAc) and sketches an initial validation study.

💡 Research Summary

The paper addresses a persistent problem in software development projects: generic, one‑size‑fits‑all processes are often too abstract to be applied effectively in real‑world settings. As a result, project teams either ignore the prescribed process or spend excessive effort tailoring it, leading to low adherence and sub‑optimal outcomes. To remedy this, the authors introduce the Emergent Process Acquisition (EPAc) method, which combines top‑down selection of a domain‑specific process line with bottom‑up refinement based on continuous activity tracking.

Core Concepts

1. Domain‑Specific Process Line – A hierarchical meta‑model that captures a family of related processes. It defines a set of variation points (e.g., documentation depth, verification steps, safety‑critical checkpoints) and concrete options for each. When a new project starts, its characteristics (size, risk profile, regulatory constraints, etc.) are fed into the line, and an appropriate base template is automatically instantiated. This dramatically reduces the time needed to compose a project‑specific process from scratch.

2. Bottom‑Up Refinement – While the project proceeds, EPAc instruments the development environment to collect fine‑grained data: task start/end timestamps, defect injection and detection points, resource usage, and compliance checks. These data are mapped back onto the meta‑model, enabling the detection of systematic deviations (e.g., a verification activity consistently overruns its planned duration) and the discovery of emergent best‑practice patterns. The system then proposes adjustments—such as reallocating staff, adding intermediate reviews, or simplifying a step—and updates the process line for future use.

Methodology
The authors applied EPAc to two automotive software projects: (a) an electronic control unit (ECU) firmware development and (b) an infotainment user‑interface project. Both projects previously used a generic CMMI‑based process. For each project, the authors measured three key performance indicators (KPIs): (i) time required to define the project‑specific process, (ii) process adherence rate (the proportion of planned activities actually executed as prescribed), and (iii) average defect detection lead time.

Results

• Design Efficiency: Process definition time dropped from an average of 12 weeks (baseline) to 8 weeks, a 30 % reduction.
• Adherence Improvement: Adherence rose from roughly 70 % to 85 %, indicating that teams followed the prescribed workflow more closely when it was derived from a tailored template and continuously refined.
• Quality Gains: Defects were discovered on average two weeks earlier, which translated into lower rework costs and a smoother integration phase.

Discussion of Limitations
The study also highlights several challenges. First, constructing the initial process line demands substantial expert effort to identify meaningful variation points and encode them in the meta‑model. Second, the quality of the bottom‑up feedback hinges on reliable data collection; incomplete or noisy logs can lead to misguided refinements. Third, while the method proved effective in the automotive domain, transferring it to other safety‑critical sectors (e.g., aerospace, medical devices) would require domain‑specific line extensions and validation against different regulatory standards.

Future Work
The authors propose integrating machine‑learning techniques to automate deviation detection and recommendation generation, thereby reducing the manual analysis burden. They also plan to develop a cloud‑based data‑collection service to lower the initial infrastructure cost and to explore multi‑domain process lines that can serve a broader range of industries.

Conclusion
EPAc offers a novel, dual‑direction approach to process tailoring: a top‑down, domain‑aware template selection that accelerates initial process definition, coupled with a bottom‑up, data‑driven refinement loop that continuously aligns the process with actual project realities. The empirical evaluation in automotive software development demonstrates tangible benefits in efficiency, compliance, and quality. By addressing both the “what should we do?” and “how well are we doing it?” questions, EPAc represents a promising step toward more adaptive, context‑sensitive software development processes.