Continuous Software Engineering Research Articles

The never-ending story–How companies transition to and sustain continuous software engineering practices

The never-ending story–How companies transition to and sustain continuous software engineering practices

Natural Language Processing For Requirement Elicitation In University Using Kmeans And Meanshift Algorithm

Data Driven Requirement Engineering (DDRE) represents a vision for a shift from the static traditional methods of doing requirements engineering to dynamic data-driven user-centered methods. Data available and the increasingly complex requirements of system software whose functions can adapt to changing needs to gain the trust of its users, an approach is needed in a continuous software engineering process. This need drives the emergence of new challenges in the discipline of requirements engineering to meet the required changes. The problem in this study was the method in data discrepancies which resulted in the needs elicitation process being hampered and in the end software development found discrepancies and could not meet the needs of stakeholders and the goals of the organization. The research objectives in this research to the process collected and integrating data from multiple sources and ensuring interoperability. Conclusion in this research is determining is the clustering algorithm help the collection data and elicitation process has a somewhat greater impact on the ratings provided by professionals for pairs that belong to the same cluster. However, the influence of POS tagging on the ratings given by professionals is relatively consistent for pairs within the same cluster and pairs in different clusters.

Experiences and challenges from developing cyber‐physical systems in industry‐academia collaboration

SummaryCyber‐physical systems (CPSs) are increasing in developmental complexity. Several emerging technologies, such as Model‐based engineering, DevOps, and Artificial intelligence, are expected to alleviate the associated complexity by introducing more advanced capabilities. The AIDOaRt research project investigates how the aforementioned technologies can assist in developing complex CPSs in various industrial use cases. In this paper, we discuss the experiences of industry and academia collaborating to improve the development of complex CPSs through the experiences in the research project. In particular, the paper presents the results of two working groups that examined the challenges of developing complex CPSs from an industrial and academic perspective when considering the previously mentioned technologies. We present five identified challenge areas from developing complex CPSs and discuss them from the perspective of industry and academia: data, modeling, requirements engineering, continuous software and system engineering, as well as intelligence and automation. Furthermore, we highlight practical experience in collaboration from the project via two explicit use cases and connect them to the challenge areas. Finally, we discuss some lessons learned through the collaborations, which might foster future collaborative efforts.

A Maturity Level Framework for Practicing Machine Learning Operations in CI/CD For Software Deployment

Significantly shorter software development and deployment cycles have been made possible by the adoption of continuous software engineering techniques in business operations, such as DevOps (Development and Operations). Data scientists and operations teams have recently become more and more interested in a practice known as MLO (Machine Learning Operations). However, MLO adoption in practice is still in its early stages, and there aren't many established best practices for integrating it into current software development methods. In order to give a frame that outlines the way necessary in espousing MLO and the stages through which business capes process as they come riper and sophisticated, we achieve a methodical literature study as well as a slate review of literature in this composition. We test this approach in three example businesses and demonstrate how they were able to embrace and incorporate MLO into their massive software development businesses. This study offers three contributions. To give an overview of the state of the art in MLO, we first examine recent publications. Based on this analysis, we create an MLO framework that outlines the steps taken in the ongoing creation of machine learning models. Second, we define the several stages that businesses go through as they develop their MLO practices in a maturity model. Third, we map the firms to the maturity model phases and test our methodology using three embedded systems case companies. The main objective is to create an MLO framework.

Continuous Software Engineering Practices in {AI/ML} Development Past the Narrow Lens of {MLOps}: {A}doption Challenges

Background: Continuous software engineering practices are currently considered state of the art in Software Engineering (SE). Recently, this interest in continuous SE has extended to ML system development as well, primarily through MLOps. However, little is known about continuous SE in ML development outside the specific continuous practices present in MLOps. Aim: In this paper, we explored continuous SE in ML development more generally, outside the specific scope of MLOps. We sought to understand what challenges organizations face in adopting all the 13 continuous SE practices identified in existing literature. Method: We conducted a multiple case study of organizations developing ML systems. Data from the cases was collected through thematic interviews. The interview instrument focused on different aspects of continuous SE, as well as the use of relevant tools and methods. Results: We interviewed 8 ML experts from different organizations. Based on the data, we identified various challenges associated with the adoption of continuous SE practices in ML development. Our results are summarized through 7 key findings. Conclusion: The largest challenges we identified seem to stem from communication issues. ML experts seem to continue to work in silos, detached from both the rest of the project and the customers.

The role of informal communication in building shared understanding of non-functional requirements in remote continuous software engineering

The role of informal communication in building shared understanding of non-functional requirements in remote continuous software engineering

Architectural support for software performance in continuous software engineering: A systematic mapping study

The continuous software engineering paradigm is gaining popularity in modern development practices, where the interleaving of design and runtime activities is induced by the continuous evolution of software systems. In this context, performance assessment is not easy, but recent studies have shown that architectural models evolving with the software can support this goal. In this paper, we present a mapping study aimed at classifying existing scientific contributions that deal with the architectural support for performance-targeted continuous software engineering. We have applied the systematic mapping methodology to an initial set of 215 potentially relevant papers and selected 66 primary studies that we have analyzed to characterize and classify the current state of research. This classification helps to focus on the main aspects that are being considered in this domain and, mostly, on the emerging findings and implications for future research.Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board. (see [https://www.sciencedirect.com/science/article/pii/S0164121221002168] for an example for where to place the statement and how to format it).

Early Labour App: Developing a practice-based mobile health application for digital early labour support

BackgroundPregnant women in early labour have felt excluded from professional care, and their partners have been restricted from being involved in the birthing process. Expectant parents must be better prepared to deal with fear and stress during early labour. There is a need for evidence-based information and digital applications that can empower couples during childbirth. ObjectiveTo develop and identify requirements for a practice-based mobile health (mHealth) application for Digital Early Labour Support. MethodsThis research started with creating an expert group composed of a multidisciplinary team capable of informing the app development process on evidence-based practices. In consultation with the expert group, the app was built using an agile development approach (i.e., Scrum) within a continuous software engineering setting (i.e., CI/CD, DevOps), also including user and security tests. ResultsDuring the development of the Early Labour App, two main types of challenges emerged: (1) user challenges, related to understanding the users’ needs and experience with the app, and (2) team challenges, related to the software development team in particular, and the necessary skills for translating an early labour intervention into a digital solution. This study reaffirms the importance of midwife support via blended care and the opportunity of complementing it with an app. The Early Labour App was easy to use, the women needed little to no help, and the partner’s preparation was facilitated. The combination of the app together with blended care opens up awareness, thoughts and feelings about the method and provides good preparation for the birth. ConclusionWe propose the creation of the Early Labour App, a mHealth app for early labour support. The preliminary tests conducted for the Early Labour App show that the app is mature, allowing it to be used in the project’s Randomised Control Trial, which is already ongoing.

Continuous Software Engineering: Introducing an Industry Readiness Model

Software is becoming essential for most products, manufacturing processes, and back-office functions. The speed of delivering new features and refining the product is critical to remaining competitive. Software organizations may adopt continuous engineering practices to become more efficient. However, retrofitting an organization with a pipeline is challenging. Importantly, the most significant challenges and opportunities, are related to, but stem from outside the engineering realm and require rethinking customer relationships and business models. This paper presents a hierarchy of continuous engineering benefits and challenges. It is aimed to guide the adoption of continuous practices in an organization to determine the current and target level of adoption, given organizational context, ambitions, and domain constraints.

Infrastructure as Code

This special issue shows how the realm of infrastructure code has evolved to a status which—analyzed from a scientific perspective—can be considered mature, and rich in practices which can be seen as off-the-shelf approaches to continuous software engineering.

Continuous Software Engineering for Augmented Reality

Continuous Software Engineering for Augmented Reality

Continuous design control for machine learning in certified medical systems

Continuous software engineering has become commonplace in numerous fields. However, in regulating intensive sectors, where additional concerns need to be taken into account, it is often considered difficult to apply continuous development approaches, such as devops. In this paper, we present an approach for using pull requests as design controls, and apply this approach to machine learning in certified medical systems leveraging model cards, a novel technique developed to add explainability to machine learning systems, as a regulatory audit trail. The approach is demonstrated with an industrial system that we have used previously to show how medical systems can be developed in a continuous fashion.

Towards cost-benefit evaluation for continuous software engineering activities

Context:Software companies must become better at delivering software to remain relevant in the market. Continuous integration and delivery practices promise to streamline software deliveries to end-users by implementing an automated software development and delivery pipeline. However, implementing or retrofitting an organization with such a pipeline is a substantial investment, while the reporting on benefits and their relevance in specific contexts/domains are vague.Aim:In this study, we explore continuous software engineering practices from an investment-benefit perspective. We identify what benefits can be attained by adopting continuous practices, what the associated investments and risks are, and analyze what parameters determine their relevance.Method:We perform a multiple case study to understand state-of-practice, organizational aims, and challenges in adopting continuous software engineering practices. We compare state-of-practice with state-of-the-art to validate the best practices and identify relevant gaps for further investigation.Results:We found that companies start the CI/CD adoption by automating and streamlining the internal development process with clear and immediate benefits. However, upgrading customers to continuous deliveries is a major obstacle due to existing agreements and customer push-back. Renegotiating existing agreements comes with a risk of losing customers and disrupting the whole organization.Conclusions:We conclude that the benefits of CI/CD are overstated in literature without considering the contextual and domain complexities rendering some benefits infeasible. We identify the need to understand the customer and organizational perspectives further and understand the contextual requirements towards the CI/CD.

Towards privacy compliance: A design science study in a small organization

Complying with privacy regulations has taken on new importance with the introduction of the EU’s General Data Protection Regulation (GDPR) and other privacy regulations. Privacy measures are becoming a paramount requirement demanding software organizations’ attention as recent privacy breaches such as the Capital One data breach affected millions of customers. Software organizations, however, struggle with achieving privacy compliance. In particular, there is a lack of research into the organizational practices and challenges involved in compliance, particularly for small and medium enterprises (SMEs), which represent a sizeable portion of organizations. Many SMEs use a continuous software engineering (CSE) approach, which introduces additional adoption and application challenges. For example, the fast pace of CSE makes it harder for SMEs that are already more resource constrained to prioritize non-functional requirements such as privacy.

Raw-data] Architectural support for Software Performance in Continuous Software Engineering: a Systematic Mapping Study

Raw-data] Architectural support for Software Performance in Continuous Software Engineering: a Systematic Mapping Study

Architectural Support for Software Performance in Continuous Software Engineering: A Systematic Mapping Study

Architectural Support for Software Performance in Continuous Software Engineering: A Systematic Mapping Study

Raw-data] Architectural support for Software Performance in Continuous Software Engineering: a Systematic Mapping Study

Raw-data] Architectural support for Software Performance in Continuous Software Engineering: a Systematic Mapping Study

Raw-data] Architectural support for Software Performance in Continuous Software Engineering: a Systematic Mapping Study

Raw-data] Architectural support for Software Performance in Continuous Software Engineering: a Systematic Mapping Study

Continuous Software Engineering and Unit Testing: From Theory to Practice

With the Agile development approach, the software industry has moved to a more flexible and continuous Software Development Life Cycle (SDLC), which integrates the stages of development, delivery and deployment. This trend has exposed a tendency of increasing reliance on both unit testing and test automation for the fundamental quality-activities during the code development. To implement Continuous Software Engineering (CSE), it is vital to assure that unit-testing activities are an integral and well-defined part of a continuous process. This paper focuses on the initial role of actual testing – viewing unit testing as a quality indicator during the development life cycle. We review the definition of unit-testing from the CSE world, and describe a qualitative study in which we examined implementation of unit testing in three software companies that recently migrated to CSE methodology. The results from the qualitative study corroborate our argument that under the continues approach, quality-based development practices such as unit testing are of increasing importance, lacking common set of measurements and KPI's. A possible explanation to this may be the role of continuous practices as well as unit testing in the software engineering curriculum

Towards Regulatory-Compliant MLOps: Oravizio\u2019s Journey from a Machine Learning Experiment to a Deployed Certified Medical Product

Agile software development embraces change and manifests working software over comprehensive documentation and responding to change over following a plan. The ability to continuously release software has enabled a development approach where experimental features are put to use, and, if they stand the test of real use, they remain in production. Examples of such features include machine learning (ML) models, which are usually pre-trained, but can still evolve in production. However, many domains require more plan-driven approach to avoid hazard to environment and humans, and to mitigate risks in the process. In this paper, we start by presenting continuous software engineering practices in a regulated context, and then apply the results to the emerging practice of MLOps, or continuous delivery of ML features. Furthermore, as a practical contribution, we present a case study regarding Oravizio, first CE-certified medical software for assessing the risks of joint replacement surgeries. Towards the end of the paper, we also reflect the Oravizio experiences to MLOps in regulatory context.