Continuous software engineering and its support by usage and decision knowledge: An interview study with practitioners

Abstract

Continuous software engineering (CSE) emerged as a process that is increasingly applied by practitioners. However, different perceptions impede its adoption in industry. Furthermore, opportunities through utilizing usage and decision knowledge remain unexploited. We conducted a semi‐structured interview study with 24 practitioners from 17 companies to study how practitioners apply CSE during software evolution and how usage and decision knowledge can support CSE. Regarding the application of CSE, we identified five perspectives on CSE with tool‐ and methodology‐driven definitions most prevalent. Automated tests, involved users, and shared rulesets are perceived as most relevant for CSE. Practitioners report more positive than negative experiences; however, more than half of their responses were neutral. Practitioners' future plans for CSE focus on enhancement, expansion, and on‐demand adaption. Regarding the integration of usage and decision knowledge into CSE, practitioners perceive accountability and traceability as major benefits, while raising concerns about its feasibility and user groups. As short‐term extensions, practitioners expect improvements regarding automation and role aspects, while long‐term additions to integration and experimentation capabilities are demanded. We conclude that CSE remains partially difficult to capture for practitioners, while their attitude toward integrating usage and decision knowledge into CSE is positive.

Identifying Key Characteristics of Business Rules That Affect Software Project Success

“…The definition of BR and especially business terms must be understandable to business users (e.g., using SBVR [9,25]) and developers (e.g., platform-specific BR, like Ilog, Bonita, etc.). BR should be specifically prepared for a particular project [4,12].…”

“…One of the main causes of software implementation project failure [49] are poorly defined requirements, which also include poorly defined BR for the project. Consequently, we should improve understanding of BR (RQ4) by standardizing their content and form e.g., a shared rule set facilitates successful work [12]. Based on this finding, the more general BR in the form of good practices can be developed [50,51].…”

“…Authors [12] found that consistent BR positively affect software implementation project success since consistent BR promotes coordination [29].…”

“…Wheatcraft et al [31] consider BR as a specific type of requirements, which should be well-defined, since they have to be understood similarly by a wide range of different stakeholders in activities such as programming, planning, maintenance, developing test plans, etc. Johanssen et al [12] consider well-defined shared rulesets as very important for software engineering. Boyer and Mili [32], and emphasize the importance of well-defined BR that make sense and do not have logical conflicts.…”

“…The theory emphasizes that BR need to be well defined [5,11], consistent [12], and written [12,13] to positively affect software implementation project success. The Standish Group found that when an application team focuses on BR rather than technology, it can reduce the time and resources needed to integrate applications [13].…”