ABSTRACT Accurate estimation of software development effort remains a persistent challenge in software engineering. Traditional parametric models such as COCOMO provide structured estimation mechanisms but often fail to capture the nonlinear interactions among project cost drivers. Machine learning approaches improve predictive accuracy but typically sacrifice the interpretability that practitioners require for managerial decision‐making. Recent advances in learning architectures, specifically Kolmogorov–Arnold Networks (KAN), offer a function‐based modelling paradigm that learns structured, data‐adaptive nonlinear relationships while preserving symbolic interpretability through post‐training spline analysis. This paper proposes KAN‐SEE , a KAN‐based software effort estimation framework that maps four heterogeneous benchmark datasets—COCOMO81, China, NASA93, and ISBSG—into a unified 16‐dimensional COCOMO feature space consisting of 15 standard effort multipliers and one log‐transformed size feature. The proposed model is evaluated on 7015 software projects using fivefold cross‐validation. Experimental results demonstrate that KAN‐SEE achieves a mean of 0.9652 ( 0.0094) in log‐transformed space.These findings suggest that function‐learning architectures represent a principled and practically viable direction for advancing effort estimation: combining the interpretability of COCOMO with the predictive flexibility of modern machine learning.
ABSTRACT Solutions and business architects play a fundamental role in the process of selecting software solutions that satisfy their organizations' objectives and needs to implement a change. These practitioners are often faced with the challenge of selecting the most suitable software among a set of candidate solutions. For that, they often perform a comparative study based on a set of criteria to select the software that best meets the specific needs of their organizations and customers. The software selection is a decision process that plays a crucial role in organizations' digital transformation. However, existing methods have limitations related to their usability and implementation complexity. This paper provides architecture practitioners with a novel method that automatically prioritizes software solutions in order to select the most suitable one. The prioritization process of the solutions is based on: (i) the functional requirements they implement and (ii) the desired goals (business objectives and non‐functional requirements) they satisfy. The proposed method is goal‐oriented. It uses the Goal‐oriented Requirement Language (GRL) that links the candidate software to the requirements to be implemented and the goals to be met. The use of GRL allows the method to automatically compute satisfaction scores that measure the effectiveness of candidate software solutions in implementing requirements and satisfying the desired goals. The satisfaction score is used to rank the software solutions. An experimental study was conducted to evaluate the method's usability. Results demonstrated its effectiveness and alignment with expert expectations in solutions, business architecture, and business analysis.
ABSTRACT Remote and hybrid work has become a permanent feature of the technology sector. Retaining software developers, however, remains a major challenge. Managers often focus on workload, performance, or compensation. A less visible yet critical risk is organizational dehumanization, defined as employees perceiving themselves as “replaceable” or “just numbers.” In this study, we examine early emotional risk signals associated with dehumanization and their impact on turnover. We conducted surveys and case studies with 246 software developers across nine companies in Türkiye to understand how management practices affect experiences of dehumanization, loneliness, and stress. Our findings show that dehumanization operates as a hidden managerial risk. It can increase employees' feelings of loneliness, intensify work‐related stress, and ultimately trigger a chain of risks that may lead to turnover intentions. Based on these insights, we propose the Humanization Model for Remote and Hybrid Teams (H‐MRHT), a structured framework for diagnosing and addressing early signs of dehumanization. The model integrates practices for preventing dehumanization, identifying emerging risks, addressing employee needs, and sustaining human‐centered practices. Our study offers practical recommendations for human resources and engineering managers aimed at strengthening feelings of appreciation, support, and belonging among remote and hybrid teams.
ABSTRACT CI/CD pipelines have become an essential part of modern software development, enabling teams to deliver software faster, more reliably, and with less effort. While prior work has examined CI/CD adoption and workflow‐file changes, less is known about when higher level CI/CD activities are introduced during development, and how structural pipeline characteristics evolve across comparable development stages. This study analyzes most‐starred open‐source Java repositories on GitHub using GitHub Actions. We identify automated development activities and extract structural pipeline metrics from 339 repositories with CI/CD pipelines. We compare pipeline evolution across equivalent stages of development for 107 repositories. Using our activity‐detection procedure, build was the most frequently identified automated activity (93.5%), followed by release (44.8%), test (37.2%), analyze (22.7%), and deploy (14.2%). Build was typically detected earliest, with test and release following later, and analyze and deploy were detected in fewer projects and generally closer to the midpoint of active development. Pipeline‐modifying commits accounted for a mean of 4.15% of repository commits (median = 2.25%), suggesting that CI/CD pipelines require ongoing maintenance but that this maintenance represents a comparatively small share of overall repository commit activity in most repositories. Structural changes occur throughout development, with lines of code changing most frequently across timeline checkpoints, while secrets, comments, and conditionals show a secondary increase in later stages. Overall, the findings show that CI/CD pipelines evolve continuously and that both activity inclusion and structural pipeline changes follow recognizable lifecycle patterns.
Low-Code Development Platforms (LCDPs) and DevOps share a common motive to increase agility during the software development process. DevOps focuses on automation, continuous delivery, and rapid response, whereas LCDPs support these practices by simplifying automation through visual programming and rapid prototyping, enabling teams to focus their expertise on decision-making and other strategic tasks. To investigate how the crossroads of LCDPs and DevOps are valuable in achieving better agility and efficiency, we have conducted interviews with 12 IT project team members who deal with LCDPs and the DevOps environment. The objective of this study is to understand the concept of DevOps with LCDPs and to explore how their integration can contribute to the software development process and organizational agility from practitioners' perspectives. To analyze the interview data, we employed a Grounded Theory (GT) approach to systematically code the data and identify emerging categories and themes. The findings suggested that the crossroads of DevOps and LCDPs serve as an effective channel to operationalize the concept of continuous everything in a more efficient manner. However, to achieve this integration successfully, organizations must consider factors such as bridging gaps between talent needs and the available employment pool, governance, scalability, and a collaborative culture. Finally, we discussed the implications of our findings for practitioners and researchers, as well as opportunities for future research.
