1,721,101 research outputs found
A State-of-the-Practice Survey of Off-the-Shelf Component-Based Development Processes
Full text linkTo gain competitive advantages software organizations are forced to develop systems quickly and cost-efficiently. Reusing components from third-party providers is one key technology to reach these goals. These components, also known as OTS (Off-the-Shelf) components, come in two different types: COTS (Commercial-Off-The-Shelf) and OSS (Open–Source-Software) components. However, the reuse of pre-fabricated components bears one major question: How to adapt development processes/methods with refer to system development using OTS components. To examine the state-of-the-practice in OTS component-based development a survey on 133 software projects in Norway, Italy and Germany was performed. The results show that OTS-based development processes are typically variations of well-known process models, such as the waterfall- or prototyping model, mixed with OTS-specific activities. One reason might be that often the process is selected before the use of OTS components is considered. Furthermore, the survey shows that the selection of OTS components is based on two processes: “Familiarity-based” and “Internet search-based”. Moreover, it appears that the lifecycle phase to select OTS components is significantly correlated with a project members’ previous familiarity with possible OTS candidates. Within this paper, we characterize the state-of-the-practice concerning OTS processes, using seven scenarios, and discuss how to decide or modify such processes and how to select OTS components
Identifying and understanding architectural risks in software evolution: an empirical study
No full textSoftware risk management studies commonly focus on project level risks and strategies. Software architecture investigations are often concerned with the design, implementation and maintenance of the architecture. However, there has been little effort to study risk management in the context of software architecture. We have identified risks and corresponding management strategies specific to software architecture evolution as they occur in industry, from interviews with 16 Norwegian IT-professionals. The most influential (and frequent) risk was "Lack of stakeholder communication affected implementation of new and changed architectural requirements negatively". The second most frequent risk was "Poor clustering of functionality affected performance negatively". Architects focus mainly on architecture creation. However, their awareness of needed improvements in architecture evaluation and documentation is increasing. Most have no formally defined/documented architecture evaluation method, nor mention it as a mitigation strategy. Instead, problems are fixed as they occur, e.g. to obtain the missing artefacts.Odd Petter Nord Slyngstad, Jingyue Li, Reidar Conradi, and M. Ali Baba
A State-of-the-Practice Survey on Risk Management in Development with Off-The-Shelf Software Components
No full textAn international survey on risk management in software development with Off-the-Shelf (OTS) components is reported upon and discussed. The survey investigated actual risk-management activities and their correlations with the occurrences of typical risks in OTS component-based development. Data from 133 software projects in Norway, Italy, and Germany were collected using a stratified random sample of IT companies. The results show that OTS components normally do not contribute negatively to the quality of the software system as a whole, as is commonly expected. However, issues such as the underestimation of integration effort and inefficient debugging remain problematic and require further investigation. The results also illustrate several promising effective risk- reduction activities, e.g., putting more effort into learning relevant OTS components, integrating unfamiliar components first, thoroughly evaluating the quality of candidate OTS components, and regularly monitoring the support capability of OTS providers. Five hypotheses are proposed regarding these risk-reduction activities. The results also indicate that several other factors, such as project, cultural, and human-social factors, have to be investigated to thoroughly deal with the possible risks of OTS-based project
Development with Off-The-Shelf Components: 10 Facts
No full textEmpirical studies have revealed a discrepancy between academic theory and industrial practices regarding the selection and integration of commercial off-the-shelf and open source software components in software system developmen
An Empirical Study on Off-the-Shelf Component Usage in Industrial Projects
No full textUsing OTS (Off-The-Shelf) components in software projects has become increasing popular in the IT industry. After project managers opt for OTS components, they can decide to use COTS (Commercial-Off-The-Shelf) components or OSS (Open Source Software) components instead of building these themselves. This paper describes an empirical study on why project decision-makers use COTS components instead of OSS components, or vice versa. The study was performed in form of an international survey on motivation and risks of using OTS components, conducted in Norway, Italy and Germany. We have currently gathered data on 71 projects using only COTS components and 39 projects using only OSS components, and 5 using both COTS and OSS components. Results show that both COTS and OSS components were used in small, medium and large software houses and IT consulting companies. The overall software system also covers several application domains.Both COTS and OSS were expected to contribute to shorter time-to-market, less development effort and the application of newest technology. However, COTS users believe that COTS component should have good quality, technical support, and will follow the market trend. OSS users care more about the free ownership and openness of the source code. Projects using COTS components had more difficulties in estimating selection effort, following customer requirement changes, and controlling the component's negative effect on system security. On the other hand, OSS user had more difficulties in getting the support reputation of OSS component providers
Going Beyond Counting First Authors in Author Co-citation Analysis
Full text linkThe present study examines one of the fundamental aspects of author co-citation analysis (ACA) - the way co-citation
counts are defined. Co-citation counting provides the data on which all subsequent statistical analyses and mappings
are based, and we compare ACA results based on two different types of co-citation counting - the traditional type that
only counts the first one among a cited work's authors on the one hand and a non-traditional type that takes into
account the first 5 authors of a cited work on the other hand. Results indicate that the picture produced through this non-traditional author co-citation counting contains more coherent author groups and is therefore considerably clearer. However, this picture represents fewer specialties in the research field being studied than that produced through the traditional first-author co-citation counting when the same number of top-ranked authors is selected and analyzed. Reasons for these effects are discussed
Risks and risk management in software architecture evolution: an industrial survey
No full textThe effort that has been made to study risk management in the context of software architecture and its evolution, has so far focused on output from structured evaluations. However, earlier research shows that formal, structured evaluation is not commonly used in industry. We have performed a survey among software architects, in order to capture a more complete picture of the risk and management issues in software architecture evolution. Our survey is specifically about their current knowledge of actual challenges they have anticipated and experienced, as well as strategies they have employed in response. We received completely filled questionnaires from 82 respondents out of a total distribution of 511 architects from the software industry in Norway. While many of the risks we have identified can be aligned with results from earlier studies, we have also identified several risks which appear not to fit these risk categories. Additionally, we found a direct link to business risks, as well as a relatively low level of awareness that lack of software architecture evaluation represents a potential risk.Odd Petter N. Slyngstad, Reidar Conradi, M. Ali Babar, Viktor Clerc, Hans van Vlie
- …
