APls (Application Programming Interfaces) playa crucial role in modern software engineering, where CI/CD (Continuous Integration/Continuous Deployment) pipelines are closely aligned, enabling automated workflows across source control, builds, secrets management, and deployment. However, these same APls can expose serious security risks, especially when tokens are overprivileged, secrets are hardcoded, or configurations are left open. This paper reviews 33 studies to examine how such vulnerabilities appear across different pipeline stages. We identified recurring issues, including dependency confusion attacks, misconfigured Y AML files, and credential leaks caused by API misuse. Despite the availability of tools and best practices, most research focuses on static checks and overlooks runtime behaviours, multi-stage attack paths, and privilege escalation risks. Based on these patterns, we propose a practical threat taxonomy that connects API threats to specific CI/CD stages and attacker goals, aiming to support more grounded threat modelling in DevOps environments.

Security is becoming a pivotal point in cloud platforms. Several divisions, such as business organisations, health care, government, etc., have experienced cyber-attacks on their infrastructures. This research focuses on security issues within Continuous Integration and Deployment (CI/CD) pipelines in a cloud platform as a reaction to recent cyber breaches. This research proposes a blockchain-based solution to enhance CI/CD pipeline security. This research aims to develop a framework that leverages blockchain's distributed ledger technology and tamper-resistant features to improve CI/CD pipeline security. The goal is to emphasise secure software deployment by integrating threat modelling frameworks and adherence to coding standards. It also aims to employ tools to automate security testing to detect publicly disclosed vulnerabilities and flaws, such as an outdated version of Java Spring Framework, a JavaScript library from an unverified source, or a database library that allows SQL injection attacks in the deployed software through the framework.

Background: Everything as Code (EaC) is an emerging paradigm aiming to codify all aspects of modern software systems. Despite its growing popularity, comprehensive industry standards and peer-reviewed research clarifying its scope and guiding its adoption remain scarce. Aims: This study systematically analyzes existing knowledge and perceptions of EaC, clarifies its scope and boundaries, and provides structured guidance for researchers and practitioners. Method: We conducted a largescale multivocal literature review (MLR), synthesizing academic and grey literature sources. Findings were analyzed quantitatively and thematically. Based on this analysis, we developed a taxonomy and conceptual model of EaC, validated through collaboration with industry experts. Results: The resulting taxonomy comprises$\mathbf{2 5}$distinct EaC practices organized into six layers based on industry awareness and functional roles. The conceptual model illustrates focus areas, overlaps, and interactions among these EaC practices within the software delivery lifecycle. Additionally, practical code examples demonstrating the implementation of these practices were developed in collaboration with industry experts. Conclusions: This work addresses the current scarcity of academic discourse on EaC by providing the first comprehensive taxonomy and conceptual model. These contributions enhance conceptual clarity, offer actionable guidance to practitioners, and lay the groundwork for future research in this emerging domain.

Cloud-native technologies enable the development of scalable, secure, and resilient applications in diverse cloud environments. However, deploying and configuring these technologies can be complex and error-prone. Existing reusable Infrastructure as Code (IaC) solutions often suffer from inconsistent structures, limited customization, and potential vendor lock-in, hindering their effectiveness and usability. To mitigate this, this paper presents a framework for creating standardized and reusable IaC templates for deploying and configuring cloud-native infrastructure components. We conducted a needs analysis to identify key developer requirements and established ten design principles for creating reusable IaC templates. Additionally, we conducted a multivocal review of relevant literature to summarize best practices for implementing these principles. Leveraging these insights, we developed five IaC templates and evaluated their effectiveness and usability against existing solutions. This proposed framework integrates conceptual guidance with practical implementations of reusable templates to simplify cloud-native infrastructure setup and enhance developer productivity.

As cloud environments become widespread, cybersecurity has emerged as a top priority across areas such as networks, communication, data privacy, response times, and availability. Various sectors, including industries, healthcare, and government, have recently faced cyberattacks targeting their computing systems. Ensuring secure app deployment in cloud environments requires substantial effort. With the growing interest in cloud security, conducting a systematic literature review (SLR) is critical to identifying research gaps. Continuous Software Engineering, which includes continuous integration (CI), delivery (CDE), and deployment (CD), is essential for software development and deployment. In our SLR, we reviewed 66 papers, summarising tools, approaches, and challenges related to the security of CI/CD in the cloud. We addressed key aspects of cloud security and CI/CD and reported on tools such as Harbor, SonarQube, and GitHub Actions. Challenges such as image manipulation, unauthorised access, and weak authentication were highlighted. The review also uncovered research gaps in how tools and practices address these security issues in CI/CD pipelines, revealing a need for further study to improve cloud-based security solutions.

The development of Big Data applications is not well-explored, to our knowledge. Embracing Big Data in system building, questions arise as to how to elicit, specify, analyse, model, and document Big Data quality requirements. In our ongoing research, we explore a requirements modelling language for Big Data software applications. In this paper, we introduce QualiBD, a modelling tool that implements the proposed goal-oriented requirements language that facilitates the modelling of Big Data quality requirements.

There is ample literature that suggests that the field of Big Data is growing rapidly. Also, there is emerging literature on the need to create end-user Big Data applications, as distinct from “data analytics” that typically employs machine learning algorithms to find value in large datasets for the stakeholder. A solid foundation for creating sound applications is a thorough understanding of domain and artefact models that embody artefact types and activities involved in a software project. This paper focuses on the Requirements Engineering (RE) aspect of a Big Data software project. Currently, there are no known RE artefact models to support RE process design and project understanding. To fill this void, this paper proposes a RE artefact model for Big Data end-user applications (BD-REAM). The paper also describes a method for creating the artefact model, including the basic elements and inter-relationships involved in the model.

In this paper, we describe our ongoing research aimed at defining a Requirements Engineering Artefact Model (REAM) in the context of Big Data software applications. This model aims to provide a “big picture” of the Requirements Engineering work products created and used in Big Data software development projects. REAM are important tools that can be used as references for the definition of domain-specific RE models, system life-cycle processes and artefact-centered processes, currently bereft in the Big Data Software Engineering research.

Few would deny today the importance of empirical studies in the field of Software Engineering (SE) and, indeed, an increasing number of studies are being conducted involving the software industry. While literature abounds on empirical procedures, relatively little is known about the dynamics and complexity of conducting empirical studies in the software industry. What are the impediments and how to best handle them? This driver underlies the organisation of the third in a series of workshops, CESI 2015. Apart from structured presentations and discussions from academic and industry participants, this workshop (like predecessor workshops) includes a "wall of ideas" session where all participants asynchronously post their ideas on the wall, literally, which are then analysed. As a tangible output, the workshop's discussions will be summarised in a post-workshop report.

Software maintainers use the traces of field failures to understand and diagnose faulty functions that cause the system to fail. Despite their usefulness, traces from the field can be quite overwhelming, especially for software systems with a vast client base. In the execution of realistic applications, many of them being millions of lines of code, there are just too many traces that are generated. In addition, traces are known to be extraordinarily large, which further complicates matters. Fortunately, not all field failures are caused by new faults. In fact, previous studies showed that 50% to 90% of field failures are due to previously known faults. In this paper, we propose a machine learning approach that automatically detects recurring faulty functions in the traces of new field failures. We achieve our goal by training decision trees on earlier resolved traces of system failures from the current and prior releases of the system. When applied to a large industrial system with 20 million lines of code and 200,000 functions, our approach was able to detect recurring faulty functions in the traces of field failures with an accuracy of 90%, to even 97% in some cases.

The quality of empirical studies is critical for the success of the Software Engineering (SE) discipline. More and more SE researchers are conducting empirical studies involving the software industry. While there are established empirical procedures, relatively little is known about the dynamics of conducting empirical studies in the complex industrial environments. What are the impediments and how to best handle them? This was the primary driver for organising CESI 2013. The goals of this workshop include having a dialogue amongst the participating practitioners and academics on the theme of this workshop with the aim to produce tangible output that will be summarised in a post-workshop report.

Literature indicates that 20% of a program's code is responsible for 80% of the faults, and 50-90% of the field failures are rediscoveries of previous faults. Despite this, identification of faulty code can consume 30-40% time of error correction. Previous fault-discovery techniques focusing on field failures either require many pass-fail traces, discover only crashing failures, or identify faulty "files" (which are of large granularity) as origin of the source code. In our earlier work (the F007 approach), we identify faulty "functions" (which are of small granularity) in a field trace by using earlier resolved traces of the same release, which limits it to the known faulty functions. This paper overcomes this limitation by proposing a new "strategy" to identify new and old faulty functions using F007. This strategy uses failed traces of mutants (artificial faults) and failed traces of prior releases to identify faulty functions in the traces of succeeding release. Our results on two UNIX utilities (i.e., Flex and Gzip) show that faulty functions in the traces of the majority (60-85%) of failures of a new software release can be identified by reviewing only 20% of the code. If compared against prior techniques then this is a notable improvement in terms of contextual knowledge required and accuracy in the discovery of finer-grain fault origin.

The role of an existing systems architecture (SA) in requirements engineering (RE) is recognised as important, but under-researched. A recent exploratory study of ours investigated this issue in a laboratory setting involving student participants. While the initial findings are promising, much work still remains to solidify the results. Therefore, we conducted a replication of the study, and its significant extension, on a large-scale prototypical rail project. Specifically, we identify (i) the effects of SA on RE decisions, (ii) the characteristics of the RE decisions and (iii), the impact of such decisions on development activities and the rail system. The findings of this study have implications on tighter RE-SA integration across subsystems, impact analysis of requirements on SA, and planning and risk management. We also propose three emergent hypotheses from this case study as a driver for future empirical work in RE. This case study involved examining the 10-year history of requirements and architecting decisions in several major components of the rail project. The data collected was from numerous project documents and extensive interviews with the developers and planners.

Certain software defects require corrective changes repeatedly in a few components of the system. One type of such defects spans multiple components of the system, and we call such defects pervasive multiple-component defects (PMCDs). In this paper, we describe an empirical study of six releases of a large legacy software system (of approx. size 20 million physical lines of code) to analyze PMCDs with respect to: (1) the complexity of fixing such defects and (2) the persistence of defect-prone components across phases and releases. The overall hypothesis in this study is that PMCDs inflict a greater negative impact than do other defects on defect-correction efficacy. Our findings show that the average number of changes required for fixing PMCDs is 20-30 times as much as the average for all defects. Also, over 80% of PMCD-contained defect-prone components still remain defect-prone in successive phases or releases. These findings support the overall hypothesis strongly. We compare our results, where possible, to those of other researchers and discuss the implications on maintenance processes and tools.

While much research attention has been paid to transitioning from requirements to software architectures, relatively little attention has been paid to how new requirements are affected by an existing system architecture. Specifically, no scientific studies have been conducted on the "characteristic" differences between the newly elicited requirements gathered in the presence or absence of an existing software architecture. This paper describes an exploratory controlled study investigating such requirements characteristics. We found that a multitude of characteristics (e.g., end-user focus, technological focus, and importance) were affected by the presence or absence of an SA, and the extent of this effect. The study results have implications for: RE process engineering, post-requirements analysis, and future empirical work in RE based on emergent hypotheses from this study.

This paper proposes an automatic technique to reduce the time spent in detection of the fault origin from field traces, by discovering hidden patterns in the traces.

The question of the "manner in which an existing software architecture affects requirements decisionmaking" is recognised as important in the research community; however, to our knowledge, this issue has not been scientifically explored. This paper describes an exploratory study on this question. Specific types of architectural effects on requirements decisions are identified, as are different aspects of the architecture together with the extent of their effects. This paper gives quantitative measures and qualitative interpretation of the findings. The understanding gained from this study has several implications in the areas of: project planning and risk management, requirements engineering and software architecture technology, architecture evolution, tighter integration of Requirements Engineering and Software Architecting processes, and middleware in architectures. The study involved six requirements engineering teams (of university students), whose task was to elicit new requirements for upgrading a preexisting banking software infrastructure. The data collected was based on a new meta-model for requirements decisions, which is a bi-product of this study.

In this paper, we overview a new approach to comparing execution traces. Such comparison can be useful for purposes such as improving test coverage and profiling system's users. In our approach, traces are compressed into different levels of compaction and are then compared iteratively from highest to lowest levels, rejecting dissimilar traces in the process and eventually leaving residual, similar traces. These residual traces form an important feedback for improvement or analysis goals. The preliminary results show that the approach is scalable for industrial use.

While the relationship between Requirements Engineering and software architecture (SA) has been studied increasingly in the past five years in terms of methods, tools, development models, and paradigms, that in terms of the human agents conducting these processes has barely been explored. This paper describes the impact of requirements knowledge and experience (RKE) on SA tasks. Specifically, it describes an exploratory, empirical study involving a number of architecting teams, some with requirements background and others without, all architecting from the same set of requirements. The overall results of this study suggest that architects with RKE perform better than those without, and specific areas of architecting are identified where these differences manifest. We discuss the possible implications of the findings on the areas of training, education and technology.

The interaction between software architecture (SA) and requirements engineering (RE) processes is generating interest within the research community. We explored the role of SA documentation in requirements decision-making. This paper describes the findings from this study.

Software maintainers need appropriate information concerning the change they are about to make to a software system so that they can make suitable choices in their decisions. In this paper, we describe a method (called ESDM) for developing evolutionary scenarios that provide information concerning the impact historical changes of different types have had on the quality of software architectural elements of interest. This information can aid in the decisions maintainers are about to make concerning the change at hand. The effectiveness of the method for developing evolutionary scenarios has been validated through an empirical study on an open source software system (Apache HTTP Server 1.3). Initial support from maintainers for the value of the developed scenarios is a major boost for further work in this area

While most software defects (i.e., bugs) are corrected and tested as part of the lengthy software development cycle, enterprise software vendors often have to release software products before all reported defects are corrected, due to deadlines and limited resources. A small number of these defects will be escalated by customers and they must be resolved immediately by the software vendors at a very high cost. In this paper, we develop an Escalation Prediction (EP) system that mines historic defect report data and predict the escalation risk of the defects for maximum net profit. More specifically, we first describe a simple and general framework to convert the maximum net profit problem to cost-sensitive learning. We then apply and compare several well-known cost-sensitive learning approaches for EP. Our experiments suggest that the cost-sensitive decision tree is the best method for producing the highest positive net profit and comprehensible results. The EP system has been deployed successfully in the product group of an enterprise software vendor.

Enterprise software vendors often have to release software products before all reported defects are corrected, and a small number of these reported defects will be escalated by customers whose businesses are seriously impacted. Escalated defects must be quickly resolved at a high cost by the software vendors. The total costs can be even greater, including loss of reputation, satisfaction, loyalty, and repeat revenue. In this paper, we develop an Escalation Prediction (EP) system to mine historic defect report data and predict the escalation risk of current defect reports for maximum ROI (Return On Investment). More specifically, we first describe a simple and general framework to convert the maximum ROI problem to cost-sensitive learning. We then apply and compare several best-known cost-sensitive learning approaches for EP. The EP system has produced promising results, and has been deployed in the product group of an enterprise software vendor. Conclusions drawn from this study also provide guidelines for mining imbalanced datasets and cost-sensitive learning.

Many researchers have emphasized the importance of documenting assumptions (As) underlying software requirements (Rs). However, As and Rs can change with time for reasons such as: (i) an A or R was elicited incorrectly and subsequently needs to be changed; (ii) operational domain changes induce changes in the A and R sets; and (iii) the change in validity of an A, or desirability of an R, respectively, causes the validity of another A or desirability of an R to change. In Section 2, we describe our model and how it works. To put such a model into practice, we need to consider at least two scenarios. One is intra-release cycle-time, where invalidity risk is predicted at the start of the project for times between the inception and completion of the project. This would give us intra-release risk trends. The second scenario is prediction over multiple releases. This would give us a risk trend over a longer period of time. The full paper describes an algorithm to cover both of these scenarios and gives an example (from a banking application) of how the model could apply in practice. Here, we consider only the first scenario due to limitation of space.

The architecture of a software system is a key asset for a software business. While there are several architecting and evaluation methods, literature and practice are devoid of architecture-centric concernanalysis (ACCA) methods analogous to causal analysis methods for software defects. A concern is any aspect of an architecture considered undesirable. This paper describes an ACCA method which uses at its core a Concern Traceability map (CT-map) that captures architectural design decisions starting from software requirements and links them to identified architectural concerns. The CT-map essentially forms a net of design decisions, sandwiched between requirements and architectural concerns. Analysis of the root causes of a concern is then conducted on the CT-map. The ACCA method is empirically validated through a case study on a sizeable architecture of a banking application.

Ensuring that software systems evolve in a desired manner has thus far been an elusive goal. In a continuing effort towards this objective, in this paper we propose a new approach that monitors an evolving software system, or its evolution process, against evolutionary policies so that any feedback obtained can be used to improve the system or its process. Two key concepts that make this possible are: (1) a mechanism to detect policy violations; and (2) a contextual framework to support activities of evolving a software system beyond the next release. Together, they could provide a wide and deep scope for managing software evolution. The benefit of our approach is that it would help in: sustaining the quality of a software system as it evolves; reducing evolutionary costs; and improving evolutionary processes.

If there is anyone in our community who has been driving with the “high beams” on, right from the start of the journey of software engineering, then in my mind this is, unquestionably, Professor Manny Lehman. While most of us were either in our infancy or fire-fighting software problems, Lehman had his sight set far ahead –on the programming process, as evidenced by a seminal paper published in 1969 [1]. For about thirty-five years now, Lehman has been concerned about, amongst other issues, software’s longterm health, in effect, beyond the next release, while most others – in practice and in research – have had “low beams” on as if the next release is the final release of the software product or system. It needs no further explanation as to why we encounter surprises when we drive in the pitch-dark roads of software engineering. While it mattered little to the society at large in those early years that software systems were not so reliable and were of very limited use, this is not the case today with our society’s already heavy and ever increasing dependence on software. There is no turning back, however, and we must search for ways to create, and evolve, software systems that will provide sustained quality service over long periods in our dynamic environments. Fortunately, many in practice and in research have begun to realise the importance of software evolution and that short-term thinking has an enormous economic and service quality price-tag on it. This panel session isn’t about software evolution in general, although I have no doubts that some discussion might drift that way. It is about Lehman’s laws of software evolution, in the context of the others’ experiences. Lehman has empirically studied the evolution of a number of actual software systems over the years: OS/360-70 and other systems between 1968 [1] and 1985 [2], and more recently in the FEAST (Feedback, Evolution And Software Technology) projects (19962001) [3, 4] (in collaboration with ICL, Logica, MoDDERA, Matra-BAe Dynamics, Lucent Technologies, BT Labs, and with associates, notably Turski, Perry and Ramil [5,6]), he has been able to confirm, refine and extend the earlier results. It is through these relentless efforts, over a long period, that Lehman has formulated and refined eight laws of software evolution (see Table – reproduced from [7]). Slowly, but surely, over the years these laws have gained recognition to varying degrees in pedagogy, industrial circles and in research. It is not my intention to discuss these laws here although I have no doubt that they will be addressed by the panelists, but it is interesting to note that the term law was selected because [7]:

We describe a case study of requirements changes due to an evolving environment. The Congruence Evaluation System was a proof of concept (CES POC) system which was part of a constantly evolving environment, and this change in the environment dictated the fitness of the CES POC system in the environment. The system served excellently for basic research purposes, but failed seriously in the long-term goal of evolvability with the set of coexisting research tools. We assessed the state of the system requirements, as well as that of the environment, at different times during system development and redevelopment. From this assessment we gained a detailed insight into how environmental evolution affects system survivability in terms of requirements changes. In this case study, we also found some empirical support for Lehman's (Lehman and Ramil, 2001) seventh law of software evolution, which has until now, neither been empirically supported nor refitted.

The construction of software cost estimation models remains an active topic of research. The basic premise of cost modeling is that a historical database of software project cost data can be used to develop a quantitative model to predict the cost of future projects. One of the difficulties faced by workers in this area is that many of these historical databases contain substantial amounts of missing data. Thus far, the common practice has been to ignore observations with missing data. In principle, such a practice can lead to gross biases and may be detrimental to the accuracy of cost estimation models. We describe an extensive simulation where we evaluate different techniques for dealing with missing data in the context of software cost modeling. Three techniques are evaluated: listwise deletion, mean imputation, and eight different types of hot-deck imputation. Our results indicate that all the missing data techniques perform well with small biases and high precision. This suggests that the simplest technique, listwise deletion, is a reasonable choice. However, this will not necessarily provide the best performance. Consistent best performance (minimal bias and highest precision) can be obtained by using hot-deck imputation with Euclidean distance and a z-score standardization.

Implementations of requirements change processes in large system projects face many difficulties. We present a method for analysing requirements change processes to identify implementation weaknesses and their causes. This method relies on prescriptive process models and tracing actual change proposals through the process model. We apply the method in the analysis of the requirements change process for a large real time system within a Canadian government agency. This allowed us to identify the process implementation problems, and the process, organisational, and people causes of these problems. Based on that experience, we draw general conclusions about the proposed method and its applicability

To make recommendations for improving requirements engineering processes, it is critical to understand the problems faced in contemporary practice. We describe a field study whose general objectives were to formulate recommendations to practitioners for improving requirements engineering processes, and to provide directions for future research on methods and tools. The results indicate that there are seven key issues of greatest concern in requirements engineering practice. These issues are discussed in terms of the problems they represent, how these problems are addressed successfully in practice, and impediments to the implementation of such good practices.

Central to understanding and improving requirements engineering processes is the ability to measure requirements engineering success. The paper describes a research study whose objective was to develop an instrument to measure the success of requirements engineering processes. The instrument developed consists of 32 indicators that cover the two most important dimensions of requirements engineering success. These two dimensions were identified during the study to be: quality of requirements engineering products and quality of requirements engineering service. Evidence is presented demonstrating that the instrument has desirable psychometric properties, such as high reliability and validity.

The authors present a framework, called the process cycle, which can assist in supporting and controlling process maintenance. The process cycle incorporates engineering management, performance, and improvement of processes by human agents subjected to desirable goals and policy constraints. Process maintenance is supported by incorporating feedback cycles so that processes, goals, and policies can be assessed and improved. In particular the authors address the identification of the reasons why processes change, the overall process change process, and the issue of policy improvement. Furthermore, they assess the applicability of the process cycle framework by relating it to current process maintenance practices. It is pointed out that an implication of using the process cycle for process maintenance is that there is a clear logical separation of concern in the various roles played by people, tools used, activities carried out, goals, and policies specified.>

A software development environment supports a complex network of items of at least the following major types: people, policies, laws, resources, processes and results. Such items may need to be changed on an on-going basis. The authors have designed in the Prism project a model of changes and two supporting change-related environment infrastructures with the following key features: separation of changes to the described items from the changes to the environmental facilities encapsulating these items; a facility, called the dependency structure, for describing various items and their interdependencies, and for identifying the items affected by a given change; a facility, called the change structure for classifying, recording, and analyzing change-related data and for making qualitative judgments of the consequences of a change; identification of the many distinct properties of a change; and a built-in mechanism for providing feedback. The author's approach to the problem of change and its rationale is described.>

The Prism model of engineering processes and an architecture which captures this model in its various components are described. The architecture has been designed to hold a product software process description the life-cycle of which is supported by an explicit representation of a higher-level (or meta) process description. The central part of this paper describes the nine-step Prism methodology for building and tailoring process models and gives several scenarios to support this description. In Prism, process models are built using a hybrid process modeling language that is based on a high-level Petri net formalism and rules. An important observation is that this environment should be seen as an infrastructure for carrying out the more difficult task of creating sound process models.>

The author introduces a novel basis for programming environments that encourages development of software in fragments of various types, called fragtypes. Fragtypes range from a simple expression type to a complete subsystem type. As a result, they are suited to the development of software in an enlarged scope that includes both programming in the small and programming in the large. The author shows how proposed operations on fragtypes can achieve unusual effects on the software development process. Fragtypes and their associated construction rules form the basis of the programming environment MUPE-2, which is currently under development at McGill University. The target and the implementation language of this environment is the programming language Modula-2.>

Abstract While the control structures in recent programming languages are structured, the data structures are still primitive. This paper examines data structures and operations on them, and proposes some new features in programming languages. These new features are principally in the areas of data description and data usage. In data description, the emphasis is on a global view of dynamic data structures; in data usage, semantic relationships between data items are innate in the operations on these data structures. Finally, example data descriptions and algorithms using some of the new features are contrasted with those using conventional features.