Context: Research software is instrumental in producing research results. It plays a special role in advancing scientific discovery through tasks such as data analysis, simulation, and visualisation. However, despite its importance, the organisations that produce research software face challenges in managing research software projects. Existing frameworks for software engineering often overlook the needs of research software, including research software engineering practices and open science principles. Without clear guidance, organisations that produce research software must develop and invent new techniques for research software engineering, which is a slow and costly process. Objective: This work presents RSMM, a maturity model designed to improve organisational practices in research software project management. Methods: The initial version of RSMM was developed through a systematic literature review. Expert interviews were then conducted to evaluate and refine the model. Finally, multiple case studies were carried out to validate RSMM and demonstrate its applicability in real-world settings. Results: The final version of RSMM (v1.0) comprises 79 best practices, 17 capabilities, and 10 maturity levels, organised into 4 focus areas: ‘Software Project Management’ , ‘Research Software Management’ , ‘Community Engagement’ , and ‘Software Adoptability’ . We provide a comprehensive analysis of RSMM v1.0 and demonstrate its practical applicability through two illustrative case studies. Conclusion: The RSMM is designed to help organisations in evaluating and improving their research software project management by assessing a project’s current maturity level and providing best practices across four focus areas to guide its progression.

Serverless computing is an umbrella paradigm that encompasses multiple service categories, including Function-as-a-Service (FaaS) and Backend-as-a-Service (BaaS). It has reshaped cloud application development by abstracting infrastructure management tasks such as provisioning, scaling, and operational maintenance from developers, thereby enabling greater focus on application logic. To realize these benefits, organizations need to select among various FaaS platforms such as AWS Lambda, Google Cloud Functions, Azure Functions, and Apache OpenWhisk to develop their serverless applications. Nevertheless, the increasing number of available FaaS platforms and their heterogeneous characteristics (e.g., timeout constraints, cold-start behavior, memory and package size limits, and event-source integration) make platform selection complex and knowledge-intensive for the decision makers. The main objective of this study is to support decision-makers in selecting appropriate FaaS platforms by designing an effective and systematic decision model. The model aims to simplify the selection process, reduce time and effort, and provide deeper insights into platform suitability based on specific organizational requirements. We employed a mixed-method research design to develop a decision model for the FaaS platforms selection problem. The model contains a mapping of 219 features across 16 FaaS platforms. The model was evaluated through five real-world case studies conducted at different software development companies. It suggests and prioritizes more than one FaaS platform based on the participants’ requirements. The case study participants reported that the model offered valuable insights and significantly simplified the selection process by reducing the time and costs associated with the decision-making process. We observe in the empirical evidence that decision-makers can make more rational, efficient, and effective decisions with the decision model. Additionally, the model provides reusable insights that can support future research, such as developing new frameworks and solutions for emerging challenges in serverless computing.

Context: The process of selecting machine learning models is complex for research software engineers, requiring careful consideration of factors like trainability and comprehensibility to ensure long-term usability and success. Objective: This study aims to develop and evaluate a data-driven decision model that supports research software engineers in systematically selecting suitable ML models for integration into research software. Method: A meta-model was created to guide model selection, drawing from systematic literature reviews, expert interviews, case studies, and design science. Each phase contributed valuable insights and refined the decision-making framework. Results: The study analyzed 43 models across 72 attributes, resulting in a taxonomy of ML paradigms, approaches, and domains. Key findings include trends in model selection, combinations, evaluation metrics, and datasets. The decision model was further refined through expert feedback and validated with 11 case studies. Contribution: This data-driven decision model supports research software engineers in selecting optimal ML models for integration into research software. Continued development is recommended to enhance its accuracy and applicability across varied research scenarios.

ABSTRACT Software ecosystem services are essential for the sustainability and functionality of software ecosystems, but they lack comprehensive categorization, hindering further study. This study explores the concept of software ecosystem services through a systematic literature review and brief survey. Drawing analogies from natural ecosystems, we define software ecosystem services as the conditions and processes through which software ecosystems create, provide, and sustain innovation and value creation via software. Software ecosystem services are categorized into four primary types: provisioning, regulating, cultural, and supporting services. Our findings highlight the crucial role of services that do not directly add customer value but are essential for the software ecosystem's functionality, such as authentication and authorization services, collaboration and communication platforms, and app stores. By highlighting these vital yet often overlooked services, the research identifies potential sustainability threats for software ecosystems, such as the dominance of a few major players, which mirrors the risks of monocultures in natural ecosystems. This study lays the groundwork for further research aimed at ensuring the long‐term sustainability and resilience of software ecosystems.

Decentralized Autonomous Organizations (DAOs) have found use in the governance of Open Source Software (OSS) projects. However, the governance of an OSS producing DAO should match the particularities of OSS production while also overcoming the existing challenges of decentralized governance. Existing decentralized governance frameworks do not contain all the governance activities of open source software projects. Therefore, this study presents a governance framework for DAOs that produce open source software. The framework is built upon a total of 34 articles on DAO and OSS governance. The framework was evaluated in three leading DAOs that produce open source software. The evaluation underscored the significance of the framework and proved the potential of the systematic categorization of governance mechanisms. Finally, we list emerging governance practices in various governance domains in this developing field.

Abstract Third‐party software has streamlined the software engineering process, allowed software engineers to focus on developing more advanced components, and reduced time and cost. This shift has led to software development strategies moving from competition to collaboration, resulting in the concept of software ecosystems, in which internal and external actors work together on shared platforms and place their trust in the ecosystem. However, the increase in shared components has also created challenges, especially in security, as the large dependency trees significantly enlarge a system's attack surface. The situation is made worse by the lack of effective ways to measure and ensure the trustworthiness of these components. In this article, we explore current approaches used to evaluate trust in software ecosystems, focusing on analyzing the specific techniques utilized, the primary factors in trust evaluation, the diverse formats for result presentation, as well as the software ecosystem entities considered in the approaches. Our goal is to provide the status of current trust evaluation approaches, including their limitations. We identify key challenges, including the limited coverage of software ecosystem entities; the objectivity, universality, and environmental impacts of the evaluation approaches; the risk assessment for the evaluation approaches; and the security attacks posed by trust evaluation in these approaches.

Abstract Business process modeling is a crucial aspect of domains such as Business Process Management and Software Engineering. The availability of various BPM languages in the market makes it challenging for process modelers to select the best-fit BPM language for a specific process modeling task. A decision model is necessary to systematically capture and make scattered knowledge on BPM languages available for reuse by process modelers and academics. This paper presents a decision model for the BPM language selection problem in research projects. The model contains mappings of 72 BPM features to 23 BPM languages. We validated and refined the decision model through 10 expert interviews with domain experts from various organizations. We evaluated the efficiency, validity, and generality of the decision model by conducting four case studies of academic research projects with their original researchers. The results confirmed that the decision model supports process modelers in the selection process by providing more insights into the decision process. Based on the empirical evidence from the case studies and domain expert feedback, we conclude that having the knowledge readily available in the decision model supports academics in making more informed decisions that align with their preferences and prioritized requirements. Furthermore, the captured knowledge provides a comprehensive overview of BPM languages, features, and quality characteristics that other researchers can employ to tackle future research challenges. Our observations indicate that BPMN is a commonly used modeling language for process modeling. Therefore, it is more sensible for academics to explain why they did not select BPMN than to discuss why they chose it for their research project(s).

Abstract User intent modeling in natural language processing deciphers user requests to allow for personalized responses. The substantial volume of research (exceeding 13,000 publications in the last decade) underscores the significance of understanding prevalent models in AI systems, with a focus on conversational recommender systems. We conducted a systematic literature review to identify models frequently employed for intent modeling in conversational recommender systems. From the collected data, we developed a decision model to assist researchers in selecting the most suitable models for their systems. Furthermore, we conducted two case studies to assess the utility of our proposed decision model in guiding research modelers in selecting user intent modeling models for developing their conversational recommender systems. Our study analyzed 59 distinct models and identified 74 commonly used features. We provided insights into potential model combinations, trends in model selection, quality concerns, evaluation measures, and frequently used datasets for training and evaluating these models. The study offers practical insights into the domain of user intent modeling, specifically enhancing the development of conversational recommender systems. The introduced decision model provides a structured framework, enabling researchers to navigate the selection of the most apt intent modeling methods for conversational recommender systems.

The growing number of employee-introduced IT solutions creates new attack vectors and challenges for cybersecurity management and IT administrators. These unauthorised hardware, software, or services are called shadow IT. In higher education, the diversity of the shadow IT landscape is even more prominent due to the flexible needs of researchers, educators, and students.

The growing usage of research software in the research community has highlighted the need to recognize and acknowledge the contributions made not only by researchers but also by Research Software Engineers. However, the existing methods for crediting research software and Research Software Engineers have proven to be insufficient. In response, we have developed FAIRSECO, an extensible open source framework with the objective of assessing the impact of research software in research through the evaluation of various factors. The FAIRSECO framework addresses two critical information needs: firstly, it provides potential users of research software with metrics related to software quality and FAIRness. Secondly, the framework provides information for those who wish to measure the success of a project by offering impact data. By exploring the quality and impact of research software, our aim is to ensure that Research Software Engineers receive the recognition they deserve for their valuable contributions.

Decentralized autonomous organizations are a new form of smart contract based governance. Decentralized autonomous organization platforms, which support the creation of such organizations, are becoming increasingly popular, such as Aragon and Colony. Selecting the best fitting platform is challenging for organizations, as a significant number of decision criteria, such as popularity, developer availability, governance issues, and consistent documentation of such platforms, should be considered. Additionally, decision-makers at the organizations are not experts in every domain, so they must continuously acquire volatile knowledge regarding such platforms. Supporting decision-makers in selecting the right decentralized autonomous organizations by designing an effective decision model is the main objective of this study. We aim to provide more insight into their selection process and reduce time and effort significantly by designing a decision model. This study presents a decision model for the decentralized autonomous organization platform selection problem. The decision model captures knowledge regarding such platforms and concepts systematically. The decision model is based on an existing theoretical framework that assists software engineers with a set of Multi-Criteria Decision-Making problems in software production. We conducted three industry case studies in the context of three decentralized autonomous organizations to evaluate the effectiveness and efficiency of the decision model in assisting decision-makers. The case study participants declared that the decision model provides significantly more insight into their selection process and reduces time and effort. We observe in the empirical evidence from the case studies that decision-makers can make more rational, efficient, and effective decisions with the decision model. Furthermore, the reusable form of captured knowledge regarding Decentralized Autonomous Organization Platforms can be employed by other researchers in their future investigations.

Abstract The worldwide software ecosystem is a trust-rich part of the world. Throughout the software life cycle, software engineers, end-users, and other stakeholders collaboratively place their trust in major hubs in the ecosystem, such as package managers, repository services, and software components. However, as our reliance on software grows, this trust is frequently violated by bad actors and crippling vulnerabilities in the software supply chain. This study aims to define software trust in the worldwide SECO, that is, to determine what signifies a trustworthy system, actor, or hub. We conduct a systematic literature review on the concept of trust in the software ecosystem. We acknowledge that trust is something between two actors in the software ecosystem, and we examine what role trust plays in the relationships between end-users and (1) software products, (2) package managers, (3) software producing organizations, and (4) software engineers. Two major findings emerged from the systematic literature review. To begin, we define trust in the software ecosystem by examining the definition and characteristics of trust. Second, we provide a list of trust factors that can be used to assemble an overview of software trust. Trust is critical in the communication between actors in the worldwide software ecosystem, particularly regarding software selection and evaluation. With this comprehensive overview of trust, software engineering researchers have a new foundation to understand and use trust to create a trustworthy software ecosystem.

Context: Organizations are increasingly connecting software applications using Application Programming Interfaces (APIs) to share data, services, functionality, and even complete business processes. However, the creation and management of APIs is non-trivial. Aspects such as traffic management, community engagement, documentation, and version management are often rushed afterthoughts. Objective: In this research, we present and evaluate a focus area maturity model for API Management (API-m-FAMM). A focus area maturity model can be used to establish the maturity level of an organization in a specific functional domain described through a number of areas. The API-m-FAMM addresses the areas Lifecycle Management, Security, Performance, Observability, Community, and Commercial. Method: The model is constructed using established methods for the design of a focus area maturity model. It is grounded in literature and practice, and was developed and evaluated through a systematic literature Review, eleven expert interviews, and five case studies at software producing organizations. Result: The model is described in detail, and its application is illustrated by six case studies. Conclusions: The evaluations are reported on, and show that the API-m-FAMM is an efficient tool for aiding organizations in gaining a better understanding of their current implementation of API management practices, and provides them with guidance towards higher levels of maturity. The detailed description of the construction of the API-m-FAMM gives researchers an example to further support the available methodologies, specifically how to combine design science research with these methodologies. Additionally, this study’s unique case study design shows that maturity models can be successfully deployed in practice with minimal involvement of researchers. The focus area maturity model for API Management is maintained on www.maturitymodels.org , allowing practitioners to benefit from its useful insights.

Software ecosystem orchestrators have insufficient insight and lack academic guidance in the partner selection criteria and methods available to aid them in their partner selection process. Therefore, orchestrators fail to vet, select, and engage suitable partners for their software ecosystem. Through six case studies with software orchestrators, we extract six industry methods for partner selection. Using situational method engineering, we create PALERMO: the PArtner seLEction Reference MethOd, which is subsequently evaluated by three different experts in the context of three more case studies. The method is composed and described using method engineering, and a list of partner selection criteria. Together, the method and list of criteria aid orchestrators in organizing and optimizing the partner selection process. The evaluation of the method in three extensive case studies, shows that the method is complete, effective, useful, and easy to use.

In software ecosystems, partner management concerns establishing and maintaining meaningful relationships with partners to improve ecosystem health. At the same time, software ecosystem orchestrators have insufficient insight into partner management tools. Because of this, they fail in attracting and maintaining partnerships with software producing organizations, ultimately hindering their ability to build healthy software ecosystems. This research presents a classification for partner management activities to aid orchestrators in establishing and maintaining partnerships. We contribute (1) a methodology to assess partner management in software ecosystems, (2) a classification of knowledge and activities for partner management, and (3) a starting point for the development of theory regarding partner management activities. The classification and the activities are evaluated in five case studies of software platform orchestrators.

Abstract Quality requirements are vital to developing successful software products. However, there exist evidence that quality requirements are managed mostly in an “ad hoc” manner and down-prioritized. This may result in insecure, unstable, slow products, and unhappy customers. We have developed a conceptual model for the scoping process of quality requirements – QREME – and an assessment model – Q-REPM – for companies to benchmark when evaluating and improving their quality requirements practices. Our model balances an upfront forward-loop with a data-driven feedback-loop. Furthermore, it addresses both strategic and operational decisions. We have evaluated the model in a multi-case study at two companies in Sweden and three companies in The Netherlands. We assessed the scoping process practices for quality requirements and provided improvement recommendations for which practices to improve. The study confirms the existence of the constructs underlying QREME. The companies perform, in the median, 24% of the suggested actions in Q-REPM. None of the companies work data-driven with their quality requirements, even though four out of five companies could technically do so. Furthermore, on the strategic level, quality requirements practices are not systematically performed by any of the companies. The conceptual model and assessment model capture a relevant view of the quality requirements practices and offer relevant improvement proposals. However, we believe there is a need for coupling quality requirements practices to internal and external success factors to motive companies to change their ways of working. We also see improvement potential in the area of business intelligence for QREME in selecting data sources and relevant stakeholders.

Software development is a continuous decision-making process that mainly relies on the software engineer’s experience and intuition. One of the essential decisions in the early stages of the process is selecting the best fitting programming language ecosystem based on the project requirements. A significant number of criteria, such as developer availability and consistent documentation, in addition to the number of available options in the market, lead to a challenging decision-making process. As the selection of programming language ecosystems depends on the application to be developed and its environment, a decision model is required to analyze the selection problem using systematic identification and evaluation of potential alternatives for a development project. Recently, we introduced a framework to build decision models for technology selection problems in software production. Furthermore, we designed and implemented a decision support system that uses such decision models to support software engineers with their decision-making problems. This study presents a decision model based on the framework for the programming language ecosystem selection problem. The decision model has been evaluated through seven real-world case studies at seven software development companies. The case study participants declared that the approach provides significantly more insight into the programming language ecosystem selection process and decreases the decision-making process’s time and cost. With the decision model, software engineers can more rapidly evaluate and select programming language ecosystems. Having the knowledge in the decision model readily available supports software engineers in making more efficient and effective decisions that meet their requirements and priorities. Furthermore, such reusable knowledge can be employed by other researchers to develop new concepts and solutions for future challenges.

Event sourced systems are increasing in popularity because they are reliable, flexible, and scalable. In this article, we point a microscope at a software architecture pattern that is rapidly gaining popularity in industry, but has not received as much attention from the scientific community. We do so through constructivist grounded theory, which proves a suitable qualitative method for extracting architectural knowledge from practitioners. Based on the discussion of 19 event sourced systems we explore the rationale for and the context of the event sourcing pattern. A description of the pattern itself and its relation to other patterns as discussed with practitioners is given. The description itself is grounded in the experience of 25 engineers, making it a reliable source for both new practitioners and scientists. We identify five challenges that practitioners experience: event system evolution, the steep learning curve, lack of available technology, rebuilding projections, and data privacy. For the first challenge of event system evolution, we uncover five tactics and solutions that support practitioners in their design choices when developing evolving event sourced systems: versioned events, weak schema, upcasting, in-place transformation, and copy-and-transform.

Abstract Model-driven development platforms shift the focus of software development activity from coding to modeling for enterprises. A significant number of such platforms are available in the market. Selecting the best fitting platform is challenging, as domain experts are not typically model-driven deployment platform experts and have limited time for acquiring the needed knowledge. We model the problem as a multi-criteria decision-making problem and capture knowledge systematically about the features and qualities of 30 alternative platforms. Through four industry case studies, we confirm that the model supports decision-makers with the selection problem by reducing the time and cost of the decision-making process and by providing a richer list of options than the enterprises considered initially. We show that having decision knowledge readily available supports decision-makers in making more rational, efficient, and effective decisions. The study’s theoretical contribution is the observation that the decision framework provides a reliable approach for creating decision models in software production.

Workload intensity in terms of arrival rate and think-time can be used accurately simulate system performance in traditional systems. Most systems treat individual requests on a standalone basis and resource demands typically do not vary too significantly, which in most cases can be addressed as a parametric dependency. New frameworks such as Command Query Responsibility Segregation and Event Sourcing change the paradigm, where request processing is both parametric dependent and dynamic, as the history of changes that have occurred are replayed to construct the current state of the system. This makes every request unique and difficult to simulate. While traditional systems are studied extensively in the scientific community, the latter is still new and mainly used by practitioners. In this work, we study one such industrial application using Command Query Responsibility Segregation and Event Sourcing frameworks. We propose new workload patterns suited to define the dynamic behavior of these systems, define various architectural patterns possible in such systems based on domain-driven design principles, and create analytical performance models to make predictions. We verify the models by making measurements on an actual application running similar workloads and compare the predictions. Furthermore, we discuss the suitability of the architectural patterns to different usage scenarios and propose changes to architecture in each case to improve performance.

Software architecture is a knowledge-intensive field. One mechanism for storing architecture knowledge is the recognition and description of architectural patterns. Selecting architectural patterns is a challenging task for software architects, as knowledge about these patterns is scattered among a wide range of literature. We report on a systematic literature review, intending to build a decision model for the architectural pattern selection problem. Moreover, twelve experienced practitioners at software-producing organizations evaluated the usability and usefulness of the extracted knowledge. An overview is provided of 29 patterns and their effects on 40 quality attributes. Furthermore, we report in which systems the 29 patterns are applied and in which combinations. The practitioners confirmed that architectural knowledge supports software architects with their decision-making process to select a set of patterns for a new problem. We investigate the potential trends among architects to select patterns. With the knowledge available, architects can more rapidly select and eliminate combinations of patterns to design solutions. Having this knowledge readily available supports software architects in making more efficient and effective design decisions that meet their quality concerns.

For software companies performance testing is an essential part of new application development. In this paper we present a performance engineering method that extracts the workload of an existing legacy ERP application with more than 1 million users and generates workload for a radically new version of the application. The workload is used to classify groups of end user organizations, i.e., enterprises whose customers are end users of the application, with unsupervised machine learning techniques. The method shows that (1) workload for new application testing and architecture validation can be generated from legacy application behavior, (2) end user organizations have significantly different usage patterns, and (3) for ERP applications, high-level operations, such as a salary calculations, provide a useful method for analyzing and generating workload, as opposed to for instance low level page views. The method is evaluated within a Dutch software company, where it is found to be accurate and effective for performance engineering.

In a microservice architecture, each service is designed to be independent of other microservices. The size of a microservice, defined by the features it provides, directly impacts its performance and availability. However, none of the currently available approaches take this into account. This paper proposes an approach to improve the performance of a microservice architecture by workload-based feature clustering. Given a feature model, the current microservice architecture, and the workload, this approach recommends a deployment that improves the performance for the given workload using a genetic algorithm. We created MicADO, an open-source tool, in which we implemented this approach, and applied it in a case study on an ERP system. For different workloads, the resulting generated microservice architectures show substantial improvements, which sets the potential of the approach.

Evolving software systems includes data schema changes, and because of those schema changes data has to be converted. Converting data between two different schemas while continuing the operation of the system is a challenge when that system is expected to be available always. Data conversion in event sourced systems introduces new challenges, because of the relative novelty of the event sourcing architectural pattern, because of the lack of standardized tools for data conversion, and because of the large amount of data that is stored in typical event stores. This paper addresses the challenge of schema evolution and the resulting data conversion for event sourced systems. First of all a set of event store upgrade operations is proposed that can be used to convert data between two versions of a data schema. Second, a set of techniques and strategies that execute the data conversion while continuing the operation of the system is discussed. The final contribution is an event store upgrade framework that identifies which techniques and strategies can be combined to execute the event store upgrade operations while continuing operation of the system. Two utilizations of the framework are given, the first being as decision support in upfront design of an upgrade system for event sourced systems. The framework can also be utilized as the description of an automated upgrade system that can be used for continuous deployment. The event store upgrade framework is evaluated in interviews with three renowned experts in the domain and has been found to be a comprehensive overview that can be utilized in the design and implementation of an upgrade system. The automated upgrade system has been implemented partially and applied in experiments.

Previous studies have emphasized the necessity for software platform owners to govern their platform ecosystem in order to create durable opportunities for themselves and the app developers that surround the platform. To date, platform ecosystems have been widely analyzed from the perspective of platform owners. However, how and to what extent app developers collaborate with their peers needs to be investigated further. In this article, we study the interfirm relationships among app developers in commercial platform ecosystems and explore the causes of variation in the network structure of these ecosystems. By means of a comparative study of four commercial platform ecosystems of Google (Google Apps and Google Chrome) and Microsoft (Microsoft Office365 and Internet Explorer), we illustrate substantial variation in the extent to which app developers initiated interfirm relationships. Further, we analyze how the degree of enforced entry barriers to the app store, the use of a partnership model, and the domain of the software platform that underpins the ecosystem affect the properties of these commercial platform ecosystems. We present subsequent explanations as a set of propositions that can be tested in future empirical research.

Software modernization has been extensively researched, primarily focusing on observing the associated phenomena, and providing technical solutions to facilitate the modernization process. Software modernization is claimed to be successful when the modernization is completed using those technical solutions. Very limited research, if any, is reported with an aim at documenting the post-modernization impacts, i.e., whether any of the pre-modernization business goals are in fact achieved after modernization. In this research, we attempt to address this relative absence of empirical study through five retrospective software modernization case studies. We use an explanatory case study approach to document the pre-modernization business goals, and to decide whether those goals have been achieved. The intended benefits for each of the five cases we considered were all (partially) met, and in most cases fully. Moreover, many cases exhibited a number of unintended benefits, and some reported detrimental effects of modernization.

Topic modeling has seen a surge in use for software comprehension. Although the models inferred from the source code are a great source of knowledge, they fail to fully capture the conceptual relationships between the topics. Here we investigate the use of interactive topic modeling for source code analysis by feeding-in information from the end-users, including developers and architects, to refine the inferred topic models. We have implemented a web-based toolkit called ITMViz to provide support to interpret the topic models, and use the results to cluster modules together. A medium-sized Java project is used to evaluate our approach in understanding the software system.

Unsupervised software clustering is the problem of automatically decomposing the software system into meaningful units. Some approaches solely rely on the structure of the system, such as the module dependency graph, to decompose the software systems into cohesive groups of modules. Other techniques focus on the informal knowledge hidden within the source code itself to retrieve the modular architecture of the system. However both techniques in the case of large systems fail to produce decompositions that correspond to the actual architecture of the system. To overcome this problem, we propose a novel approach to clustering software systems by incorporating knowledge from different viewpoints of the system, such as the knowledge embedded within the source code as well as the structural dependencies within the system, to produce a clustering. In this setting, we adopt a search-based approach to the encoding of multi-view clustering and investigate two approaches to tackle this problem, one based on a linear combination of objectives into a single objective, the other a multi-objective approach to clustering. We evaluate our approach against a set of substantial software systems. The two approaches are evaluated on a dataset comprising of 10 Java open source projects. Finally, we propose two techniques based on interpolation and hierarchical clustering to combine different results obtained to yield a single result for single-objective and multi-objective encodings, respectively.

Existing research in legacy system modernization has traditionally focused on technical challenges, and takes the standpoint that legacy systems are obsolete, yet crucial for an organization's operation. Nonetheless, it remains unclear whether practitioners in the industry also share this perception. This paper describes the outcome of an exploratory study in which 26 industrial practitioners were interviewed on what makes a software system a legacy system, what the main drivers are that lead to the modernization of such systems, and what challenges are faced during the modernization process. The findings of the interviews have been validated by means of a survey with 198 respondents. The results show that practitioners value their legacy systems highly, the challenges they face are not just technical, but also include business and organizational aspects.

Increasingly, small to medium software producing organisations are working together in collaboration networks to supply complex compositions of their products and services to customers. In this paper, we present a case study of two software companies that are evolving their partnership towards the creation of a software ecosystem. We investigate the impacts of their tightening partnership on software product management, with a focus on requirements engineering practices. We observe that the requirements definition and negotiation processes are directly affected by their fluid collaborative and competitive relationships. Power disputes, volatile roles and mismatches in release synchronisation are also aspects observed in the studied software ecosystem.We extract several observations from the case study that support small to medium software firms in making decisions within their software ecosystem.

The software ecosystem is providing a new way of interpreting the software industry. Primarily, software ecosystem modeling, one of the most studied areas in the software ecosystem domain, is an emerging field. However, modeling software ecosystems present several challenges: (a) How can value chains be identified in an ecosystem? (b) What are the typical roles that an actor plays in an ecosystem? (c) How can a boundary in an ecosystem be described?

Legacy systems are vitally important for the continuation of business in an enterprise as they support complex core business processes. However, legacy systems have several well-known disadvantages such as being inflexible and hard to maintain, so momentum is growing to evolve those systems into new technology environments. Recently, service-oriented architecture has emerged as a promising architectural style that enables existing legacy systems to expose their functionality as services, without making significant changes to the legacy systems themselves. A significant number of the legacy to service migration approaches address the technical perspective (i.e., supporting technology) to expose the legacy code as services. The other approaches focus on determining the feasibility of the migration that includes economical and technical feasibility, based on the characteristics of existing legacy system and the requirements of the target SOA system. In this paper, a legacy to SOA migration method that does not single out the migration feasibility and technical perspectives, but combines these two perspectives of migration, is proposed. Method engineering is used to develop the migration method by reusing method fragments from existing service-oriented development methods. Then, concept slicing is used to develop the service by extracting the relevant parts of the legacy code. The method is evaluated and enhanced by interviewing experts and further validated with two case studies. The method is found to be appropriate and effective in extracting services from legacy code with the aim of reusing these services in new configurations.

Knowledge of in-the-field software operation is acquired by many software-producing organizations nowadays. While vendors are effective in acquiring large amounts of valuable software operation information, many are lacking methods to improve their software processes with such information. In this paper, we attempt to improve the software maintenance process by proposing a software operation summary: an overview of a vendor's recent in-the-field software operation, designed to support software processes by providing software operation knowledge. Particularly, we strive to improve prioritization of software maintenance tasks by fostering the reach of consensus between involved employees on such prioritization. Through an extensive survey among product software vendors in the Netherlands, we confirm the need for a software operation summary, and identify which crash report data are considered relevant as a basis for the summary when it is used for prioritization of software maintenance tasks. By means of a case study at a European software vendor, a software operation summary composed using crash report data is empirically evaluated. Results confirm the lack of consensus experienced between engineers and managers, and illustrate the value of the summary in fostering reach of consensus between employee roles, particularly in preparation of sprint planning and bug fixing activities.

Software vendors depend on suppliers to provide the underlying technology for domain specific solutions. As a consequence, software vendors cooperate with suppliers to deliver a product. This cooperation results in supplier dependence, but also leads to opportunities. We present the results of an exploratory research based on twenty-seven case studies, identifying supplier strategies and resulting trade-offs. Strategies range from fully depending on large software ecosystem orchestrators to a minimal dependency strategy. Furthermore, we identify factors at play when selecting suppliers for different components. These factors include; ecosystem health indicators, product and license type and intensive support and maintenance flows. The results presented in this paper can be used by software vendors to assess their software supply network to review supplier relationships, but also for future research.

The Apple ecosystem is divided into three sub-ecosystems: iPhone, iPad and Mac. This paper analyses the behavior of companies that target more than one of these sub-ecosystems, aptly named multi-homers, using statistical analysis and a short survey. The set of companies analyzed is composed of the publishers of the top 300 free and paid applications within the three ecosystems' App Stores in May 2011. Findings showed that there is a strong relationship between the number of platforms a company targets and the type of applications it publishes and the number of these applications. The most encountered trend was of first targeting the iPhone platform and then the iPad. Multi-homing from a strategic perspective is motivated mainly by a wider customer base and the portability the Apple sub-ecosystems offer.

Keystone players, the company that occupies the crucial hubs, need to nurture its inhabitants to keep the ecosystem active. Many modern ecosystems have communities of practice where knowledge is transferred by collaborative problem solving, sharing of ideas, software components or configurations. In recent years a widely spread medium for communities of practice is the use of online discussion boards. This research proposes a method to analyze the relationship between software releases and activity in a community. This paper explains how software ecosystem Keystone companies can use software product release management to cultivate communities of practice using an illustrative case study. In this case study a comparison is made between two communities in the Android ecosystem. The results show peaks in community activity coinciding with the software releases. The release not only revitalizes the activity of the developers but the heterogeneous community in its entirety.

Knowledge of in-the-field software operation is still unrecognized as an essential pulse in the veins of software ecosystems. Although software-producing organizations are aware of the ecosystems in which they operate and their relationships with other ecosystem participants, all too often, vendors are unsuccessful in recognizing the potential value and role of such knowledge in their software ecosystems. This paper presents a classification of successful operational software ecosystem practices that may help software-producing organizations to effectively utilize and propagate knowledge of the in-the-field operation of their software, and therewith address challenges that result from ecosystem participation. Analysis of these practices confirms that infrastructures for acquisition, utilization and propagation of such knowledge, allow ecosystem participants to use the 'power of many' in increasing the quality and robustness of their software, and provide them with competitive advantage in terms of software quality, end-user satisfaction, ecosystem stability and ecosystem attractiveness.

Now a days, more and more open source software developers are starting to create software in decentralized communities. For these software ecosystems and their many end-users it does not always guarantee contributions where needed. This paper maps the influential factors that determine developer participation with a case study on the open source software Debian website. Data was gathered on potentially influential events and all commits in the year 2000 to 2011. The two previous data results are compared in a correlation study to derive relationships. In 11% of the types of events that were studied, there was a reoccurring relation with in-or decreased developer participation. Ecosystem project leaders can stimulate or prevent these events to prevent missing in action developers and welcome new developers.

Product software vendors are regularly challenged with identifying and selecting the requirements of upcoming product releases. Companies struggle to involve their customers and have a hard time selecting the right requirements from the enormous number of candidate requirements. This paper presents a practical approach to overcome these problems by including customers in the requirements management process through different types of involvement. The presented case illustrates how software requirements are gathered from customers, by involving them on three different levels. Based on the industrial experiences we present six lessons from customer involvement in large scale requirements management.

Software vendors and system administrators experience similar problems when sharing software knowledge, such as software updates, commercial information, and software feedback, with end-users about software products. These problems incur high workloads for both software vendors and system administrators and often force them to use rigid and restricted methods of software knowledge delivery. Pheme, a new infrastructure for software knowledge delivery, provides both software vendors and system administrators with a generic software knowledge delivery solution. By using the Pheme infrastructure, software vendors and system administrators can gain full control and flexibility of their software knowledge delivery process without much extra effort.

The implementation and continuous support of a software product at a customer with evolving requirements is a complex task for a product software vendor. There are many customers for the vendor to serve, all of whom might require their own version or variant of the application. Furthermore, the software application itself will consist of many (software) components that depend on each other to function correctly. On top of that, these components will evolve over time to meet the changing needs of customers. To alleviate this problem we propose to alleviate the software release and deployment effort and reduce risks associated with it. This will be achieved by explicitly managing typical knowledge about the software product, such as configuration and dependency information, thereby allowing software vendors to improve the customer configuration updating process. The proposed solution of knowledge management at both the customer and vendor site, is validated through industrial case studies.

For software vendors the processes of release, delivery, and deployment to customers are inherently complex. However, software vendors can greatly improve their product quality and quality of service by applying a model that focuses on customer interaction if such a model were available. This paper presents a model for customer configuration updating (CCU) that can evaluate the practices of a software vendor in these processes. Nine extensive case studies of medium to large product software vendors are presented and evaluated using the model, thereby uncovering issues in their release, delivery, and deployment processes. Finally, organisational and architectural changes are proposed to increase quality of service and product quality for software vendors

This paper describes how the company Cordys avoids the ERP problems from the last 15 years by improving the software release, delivery, deployment, and maintenance processes. These ERP problems, such as costly ERP migrations and highly complex maintenance procedures, are circumvented by the introduction of a staging area. This staging area is a software control system that enables a customer to manage software, 3rd party/home developed products, and knowledge such as manuals, licenses and updates, explicitly

Abstract The maintenance of enterprise application software at a customer site is a complex task for software vendors. This complexity results in a significant amount of work and risk. This article presents a case study of a product software vendor that tries to reduce this complexity by integrating product data management (PDM), software configuration management (SCM), and customer relationship management (CRM) into one system. The case study shows that by combining these management areas in a single software knowledge base, software maintenance processes can be automated and improved, thereby enabling a software vendor of enterprise resource planning software to serve a large number of customers with many different product configurations. Copyright © 2006 John Wiley & Sons, Ltd.

The maintenance of enterprise application software at a customer site is a potentially complex task for software vendors. This complexity can unfortunately result in a significant amount of work and risk. This paper presents a case study of a product software vendor that tries to reduce this complexity by integrating product data management (PDM), software configuration management (SCM), and customer relationship management (CRM) into one system. The case study shows that by combining these management areas in a single software itnowledge base, software maintenance processes can be automated and improved, thereby enabling a software vendor of enterprise software to serve a large number of customers with many different product configurations.