No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
The Role of Software Trust in Selection of Open-Source and Closed Software
... A set of interviews was conducted to understand common practices in software selection [9]. The interviews were conducted with 24 software practitioners, including 12 Open-Source Software (OSS) selection experts and 12 closed software selection experts, from various domains. ...
... First, when software engineers select a software package, they can query the sentiment of the overall quality of a particular package and the sentiment of specific quality attributes devised in a review. According to previous research, different software engineers have inconsistent quality requirements [9]. For example, OSS engineers place more importance on compatibility and integration, while closed software engineers consider Functionality and Security more important. ...
... • Technical Session 2 -Ecosystems & Systems-of-Systems. Hou et al. [6] initially explained trust factors in open-source and closed software selection from a practitioner's perspective based on semi-structured interviews with 24 software practitioners from different businesses. Schothorst et al. [15] explored partner evaluation and exclusion in SECO by conducting a set of exploratory theory building interviews with partner managers, concluding that exclusion of partners involves the removal of resources and funding. ...
This article reports on the results of the 11th ACM/IEEE International Workshop on Software Engineering for Systems-of-Systems and Software Ecosystems (SESoS 2023) in which researchers and practitioners discussed ideas and experiences on the research and practice for the development and evolution of complex softwareintensive systems, more specifically systems-of-systems (SoS) and software ecosystems (SECO). SESoS 2023 was co-located with the 45th IEEE/ACM International Conference on Software Engineering (ICSE 2023). After a decade running this workshop, the SESoS community is advancing on how to cope with the different dimensions that should be considered in the engineering of those classes of systems (i.e. technological, organizational, and social). In addition, benchmarks for conducting research on the areas as well as approaches for investigating emerging domains (smart ecosystems) and non-functional requirements on those systems were also pointed out as relevant challenges.
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.
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.
The software ecosystem is a trust-rich part of the world. Collaboratively, software engineers trust major hubs in the ecosystem, such as package managers, repository services, and programming language ecosystems. However, trust entails the assumption of risks. In this paper, we lay out the risks we are taking by blindly trusting these hubs when using information systems. Secondly, we present a vision for a trust-recording mechanism in the software ecosystem that mitigates the presented risks. This vision is realized in TrustSECO: a distributed infrastructure that collects, stores, and discloses trust facts about information systems. If our community manages to implement this mechanism, we can create an urgently needed healthy and secure software ecosystem. Finally, we report on the current status of the project.
Background. Open Source Software (OSS) is experiencing an increasing popularity both in industry and in academia. Aim. We investigated models for the selection, evaluation, and adoption of OSS, focusing on factors that affect most the evaluation of OSS. Method. We conducted a Systematic Literature Review of 262 studies published until the end of 2019, to understand whether OSS selection is still an interesting topic for researchers, and which factors are considered by stakeholders and are assessed by the available models. Result. We selected 60 primary studies: 20 surveys and 5 lessons learned studies elicited the motivations for OSS adoption; 35 papers proposed several OSS evaluation models focusing on different technical aspects. This Systematic Literature Review provides an overview of the available OSS evaluation methods, highlighting their limits and strengths, based on the wide range of technicalities and aspects explored by the selected primary studies. Conclusion. OSS producers can benefit from our results by checking if they are providing all the information commonly required by potential adopters. Users can learn how models work and which models cover the relevant characteristics of OSS they are most interested in.
Open source software (OSS) has recently become very important due to the rapid expansion of the software industry. In order to determine whether the quality of the software can achieve the intended purposes, the components of OSS need to be assessed as they are in closed source (conventional) software. Several quality in-use models have been introduced to evaluate software quality in various fields. The banking sector is one of the most critical sectors, as it deals with highly sensitive data; it therefore requires an accurate and effective assessment of software quality. In this article, two pieces of banking software are compared: one open source and one closed source. A new quality in use model, inspired by ISO/IEC 25010, is used to ensure concise results in the comparison. The results obtained show the great potential of OSS, especially in the banking field.
Qualitative research has gained in importance in the social sciences. General knowledge about qualitative data analysis, how to code qualitative data and decisions concerning related research design in the analytical process are all important for novice researchers.
The purpose of this paper is to offer researchers who are new to qualitative research a thorough yet practical introduction to the vocabulary and craft of coding.
Having pooled, their experience in coding qualitative material and teaching students how to code, in this paper, the authors synthesize the extensive literature on coding in the form of a hands-on review.
The aim of this paper is to provide a thorough yet practical presentation of the vocabulary and craft of coding. The authors, thus, discuss the central choices that have to be made before, during and after coding, providing support for novices in practicing careful and enlightening coding work, and joining in the debate on practices and quality in qualitative research.
While much material on coding exists, it tends to be either too comprehensive or too superficial to be practically useful for the novice researcher. This paper, thus, focuses on the central decisions that need to be made when engaging in qualitative data coding in order to help researchers new to qualitative research engage in thorough coding in order to enhance the quality of their analyses and findings, as well as improve quantitative researchers’ understanding of qualitative coding.
The software trustworthiness measurement is one of the hot topics. Software component technology is the mainstream technology of software development. How to get the trustworthy degree of software component efficiently and accurately is a challenge issue for component-based software development. Getting the trustworthy degree of software component needs many users’ success cases. In this paper, we propose a updating model of software component trustworthiness. First, the trustworthy degree of software component is computed based on users’ feedback. Then, the weight of updating is determined by the number of users. Finally, the method of cluster different companies is based on Euler distance. A case study shows that the method is reasonable and effective.
Sample sizes must be ascertained in qualitative studies like in quantitative studies but not by the same means. The prevailing concept for sample size in qualitative studies is “saturation.” Saturation is closely tied to a specific methodology, and the term is inconsistently applied. We propose the concept “information power” to guide adequate sample size for qualitative studies. Information power indicates that the more information the sample holds, relevant for the actual study, the lower amount of participants is needed. We suggest that the size of a sample with sufficient information power depends on (a) the aim of the study, (b) sample specificity, (c) use of established theory, (d) quality of dialogue, and (e) analysis strategy. We present a model where these elements of information and their relevant dimensions are related to information power. Application of this model in the planning and during data collection of a qualitative study is discussed.
Trust has been extensively studied and its effectiveness demon-strated in recommender systems. Due to lack of explicit trust information in most systems, many trust metric ap-proaches have been proposed to infer implicit trust from user ratings. However, previous works have not compared these different approaches, and oftentimes focus only on the per-formance of predictive item ratings. In this paper, we first analyse five kinds of trust metrics in light of the properties of trust. We conduct an empirical study to explore the ability of trust metrics to distinguish explicit trust from implicit trust and to generate accurate predictions. Experimental results on two real-world data sets show that existing trust metrics cannot provide satisfying performance, and future metrics should be designed more carefully.
This paper proposes a fuzzy qualitative and quantitative softgoal interdependency graphs (FQQSIG) model for non-functional requirements (NFRs) correlations analysis in Trustworthy Software (TS), which is considered a critical issue by academia, government, and industry. First, the FQQSIG model constructs an NFRs criteria decomposition hierarchy graph in the complex TS situation. Subsequently, it draws on trapezoidal fuzzy number and introduces a simulation algorithm named RAGE (RAndom GEneration) to transform the qualitative degree of importance assessments on NFRs in the form of experts’ fuzzy linguistic variables into quantitative values. Using a new algorithm named Relationship Matrix, this model can calculate all NFRs contribution values by which developers could make tradeoff decisions among NFRs competing alternatives. The credibility and advantages of the FQQSIG model are discussed and an example is given to illustrate the FQQSIG model.
There has been tremendous interest in the development of formal trust models and metrics through the use of analytics (e.g., Belief Theory and Bayesian models), logics (e.g., Epistemic and Subjective Logic) and other mathematical models. The choice of trust metric will depend on context, circumstance and user requirements and there is no single best metric for use in all circumstances. Where different users require different trust metrics to be employed the trust score calculations should still be based on all available trust evidence. Trust is normally computed using past experiences but, in practice (especially in centralised systems), the validity and accuracy of these experiences are taken for granted. In this paper, we provide a formal framework and practical blockchain-based implementation that allows independent trust providers to implement different trust metrics in a distributed manner while still allowing all trust providers to base their calculations on a common set of trust evidence. Further, our design allows experiences to be provably linked to interactions without the need for a central authority. This leads to the notion of evidence-based trust with provable interactions. Leveraging blockchain allows the trust providers to offer their services in a competitive manner, charging fees while users are provided with payments for recording experiences. Performance details of the blockchain implementation are provided.
Various system metrics have been proposed for measuring the quality of computer-based systems, such as dependability and security metrics for estimating their performance and security characteristics. As computer-based systems grow in complexity with many subsystems or components, measuring their quality in multiple dimensions is a challenging task. In this work, we tackle the problem of measuring the quality of computer-based systems based on the four key attributes of trustworthiness we developed: security, trust, resilience, and agility. In addition to conducting a systematic survey on metrics, measurements, attributes of metrics, and associated ontologies, we propose a system-level trustworthiness metric framework that accommodates four submetrics, called STRAM ( S ecurity, T rust, R esilience, and A gility M etrics). The proposed STRAM framework offers a hierarchical ontology structure where each submetric is defined as a sub-ontology. Moreover, this work proposes developing and incorporating metrics describing key assessment tools, including vulnerability assessment, risk assessment, and red teaming, to provide additional evidence in the measurement and quality of trustworthy systems. We further discuss how assessment tools are related to measuring the quality of computer-based systems and the limitations of the state-of-the-art metrics and measurements. Finally, we suggest future research directions for system-level metrics research toward measuring fundamental attributes of the quality of computer-based systems and improving the current metric and measurement methodologies.
Reputation is crucial to enabling human or software agents to select among alternative providers. Although several effective reputation assessment methods exist, they typically distil reputation into a numerical representation, with no accompanying explanation of the rationale behind the assessment. Such explanations would allow users or clients to make a richer assessment of providers, and tailor selection according to their preferences and current context. In this paper, we propose an approach to explain the rationale behind assessments from quantitative reputation models, by generating arguments that are combined to form explanations. Our approach adapts, extends and combines existing approaches for explaining decisions made using multi-attribute decision models in the context of reputation. We present example argument templates, and describe how to select their parameters using explanation algorithms. Our proposal was evaluated by means of a user study, which followed an existing protocol. Our results give evidence that although explanations present a subset of the information of trust scores, they are sufficient to equally evaluate providers recommended based on their trust score. Moreover, when explanation arguments reveal implicit model information, they are less persuasive than scores.
Context: Component-based software systems require decisions on component origins for acquiring components. A component origin is an alternative of where to get a component from. Objective: To identify factors that could influence the decision to choose among different component origins and solutions for decision-making (For example, optimization) in the literature. Method: A systematic review study of peer-reviewed literature has been conducted. Results: In total we included 24 primary studies. The component origins compared were mainly focused on in-house vs. COTS and COTS vs. OSS. We identified 11 factors affecting or influencing the decision to select a component origin. When component origins were compared, there was little evidence on the relative (either positive or negative) effect of a component origin on the factor. Most of the solutions were proposed for in-house vs. COTS selection and time, cost and reliability were the most considered factors in the solutions. Optimization models were the most commonly proposed technique used in the solutions. Conclusion: The topic of choosing component origins is a green field for research, and in great need of empirical comparisons between the component origins, as well of how to decide between different combinations of them.
This book describes the state-of-the-art of software ecosystems. It constitutes a fundamental step towards an empirically based, nuanced understanding of the implications for management, governance, and control of software ecosystems. © Slinger Jansen, Sjaak Brinkkemper and Michael A. Cusumano 2013. All rights reserved.
The IEEE defines reliability as "The ability of a system or component to perform its required functions under stated conditions for a specified period of time." To most project and software development managers, reliability is equated to correctness, that is, they look to testing and the number of "bugs" found and fixed. While finding and fixing bugs discovered in testing is necessary to assure reliability, a better way is to develop a robust, high quality product through all of the stages of the software lifecycle. That is, the reliability of the delivered code is related to the quality of all of the processes and products of software development; the requirements documentation, the code, test plans, and testing.
The growing tendency to embed software in powerful and invasive physical devices brings greater risk, especially in medicine, where software can save lives but also kill. Software problems led to the recall of 200,000 implanted pacemakers and defibrillators between 1990 and 2000. In the 20 years prior to 2005, the US Food and Drug Administration recorded 30,000 deaths and 600,000 injuries from medical-device failures. How many of these incidents can be attributed to software is unclear, though separate studies have found that about 8% of medical-device recalls are software-related. This article argues that developers should produce direct evidence of their software's dependability. The potential advantages of this approach are greater credibility (as the claim is not contingent on the effectiveness of the practices) and reduced cost (because development resources can be focused where they have the most impact). The direct approach, by definition, is straightforward. The desired dependability goal is explicitly articulated as a collection of claims that the system has some critical properties.
Cambridge advanced learner’s dictionary
- C Dictionary