Jingyue Li

Development with Off-the-Shelf Components: 10 Facts

Empirical 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 development.

An empirical study of variations in COTS-based software development processes in the Norwegian IT industry

More and more software projects use Commercial-Off-The-Shelf (COTS) components. Although previous studies have proposed specific COTS-based development processes, there are few empirical studies that investigate how to use and customize COTS-based development processes for different project contexts. This paper describes an exploratory study of state-of-the-practice of COTS-based development processes. Sixteen software projects in the Norwegian IT companies have been studied by structured interviews. The results are that COTS-specific activities can be successfully incorporated in most traditional development processes (such as waterfall or prototyping), given proper guidelines to reduce risks and provide specific assistance. We have identified four COTS-specific activities—the build vs. buy decision, COTS component selection, learning and understanding COTS components, and COTS component integration – and one new role, that of a knowledge keeper. We have also found a special COTS component selection activity for unfamiliar components, combining Internet searches with hands-on trials. The process guidelines are expressed as scenarios, problems encountered, and examples of good practice. They can be used to customize the actual development processes, such as in which lifecycle phase to put the new activities into. Such customization crucially depends on the project context, such as previous familiarity with possible COTS components and flexibility of requirements.

CBCD: cloned buggy code detector

Developers often copy, or clone, code in order to reuse or modify functionality. When they do so, they also clone any bugs in the original code. Or, different developers may independently make the same mistake. As one example of a bug, multiple products in a product line may use a component in a similar wrong way. This paper makes two contributions. First, it presents an empirical study of cloned buggy code. In a large industrial product line, about 4% of the bugs are duplicated across more than one product or file. In three open source projects (the Linux kernel, the Git version control system, and the PostgreSQL database) we found 282, 33, and 33 duplicated bugs, respectively. Second, this paper presents a tool, CBCD, that searches for code that is semantically identical to given buggy code. CBCD tests graph isomorphism over the Program Dependency Graph (PDG) representation and uses four optimizations. We evaluated CBCD by searching for known clones of buggy code segments in the three projects and compared the results with text-based, token-based, and AST-based code clone detectors, namely Simian, CCFinder, Deckard, and CloneDR. The evaluation shows that CBCD is fast when searching for possible clones of the buggy code in a large system, and it is more precise for this purpose than the other code clone detectors.

Transition from a plan-driven process to Scrum: a longitudinal case study on software quality

Although Scrum is an important topic in software engineering and information systems, few longitudinal industrial studies have investigated the effects of Scrum on software quality, in terms of defects and defect density, and the quality assurance process. In this paper we report on a longitudinal study in which we have followed a project over a three-year period. We compared software quality assurance processes and software defects of the project between a 17-month phase with a plan-driven process, followed by a 20-month phase with Scrum. The results of the study did not show a significant reduction of defect densities or changes of defect profiles after Scrum was used. However, the iterative nature of Scrum resulted in constant system and acceptance testing and related defect fixing, which made the development process more efficient in terms of fewer surprises and better control of software quality and release date. In addition, software quality and knowledge sharing got more focus when using Scrum. However, Scrum put more stress and time pressure on the developers, and made them reluctant to perform certain tasks for later maintenance, such as refactoring.

Selection of third party software in Off-The-Shelf-based software development-An interview study with industrial practitioners

The success of software development using third party components highly depends on the ability to select a suitable component for the intended application. The evidence shows that there is limited knowledge about current industrial OTS selection practices. As a result, there is often a gap between theory and practice, and the proposed methods for supporting selection are rarely adopted in the industrial practice. This papers goal is to investigate the actual industrial practice of component selection in order to provide an initial empirical basis that allows the reconciliation of research and industrial endeavors. The study consisted of semi-structured interviews with 23 employees from 20 different software-intensive companies that mostly develop web information system applications. It provides qualitative information that help to further understand these practices, and emphasize some aspects that have been overlooked by researchers. For instance, although the literature claims that component repositories are important for locating reusable components; these are hardly used in industrial practice. Instead, other resources that have not received considerable attention are used with this aim. Practices and potential market niches for software-intensive companies have been also identified. The results are valuable from both the research and the industrial perspectives as they provide a basis for formulating well-substantiated hypotheses and more effective improvement strategies.

A case study on building COTS-based system using aspect-oriented programming

More and more software projects are using COTS (Commercial-off-the-shelf) components. Using COTS components brings both advantages and risks. To manage some risks in using COTS components, it is necessary to increase the reusability of the glue-code so that the problematic COTS components can easily be replaced by other components. Aspect-oriented programming (AOP) claims to make it easier to reason about, develop, and maintain certain kinds of application code. To investigate whether AOP can help to build an easy-to-change COTS-based system, a case study was performed by comparing changeability between an object-oriented application and its aspect-oriented version. Results from this study show that integrating COTS component using AOP may help to increase the changeability of the COTS component-based system, if the cross-cutting concerns in the glue-code are homogenous (i.e., consistent application of the same or very similar policy in multiple places). Extracting heterogeneous or partial homogenous crosscutting concerns in glue-code as aspects does not provide benefits. Results also show that some limitations in AOP tools may make it impossible to use AOP in COTS-based development.

Reflections on conducting an international survey of software engineering

Component-based software engineering (CBSE) with commercial-off-the-shelf (COTS) or open source software (OSS) components are more and more frequently being used in industrial software development. We therefore need to issue experience-based guidelines for the evaluation, selection and integration of such components. We have performed a survey on industrial COTS/OSS development in three countries - Norway, Italy and Germany. Concrete survey results, e.g. on risk management policies and process tailoring, are not being described here, but in other papers. This is a method paper, reporting on the challenges, approaches and experiences gained by conducting the main survey. The main contributions are as follows: At best we can achieve a stratified-random sample of ICT companies, followed by a convenience sample of relevant projects. This is probably the ftirst software engineering survey using census type data, and has revealed that the entire sampling and contact process can be unexpectedly expensive. It is also hard to avoid national variations in the total process, possibly leading to uncontrollable method biases

Open Source Collaboration for Fostering Off-The-Shelf Components Selection

The use of Off-The-Shelf software components in Component- Based Development implies many challenges. One of them is the lack of available and well-suited data to support selection of suitable OTS components. This paper proposes a feasible and incremental way to federate and reuse the different efforts for finding, selecting, and maintaining OTS components in a structured way. This is done not only for supporting OTS components selection, but also to overcome reported problems with the integration and maintenance of component repositories. It is based on the “open source collaboration” idea to incrementally build an OTS components reuse infrastructure, enabling automatic support for OTS selection processes.

An empirical study of variations in COTS-based software development processes in Norwegian IT industry

More and more software projects use commercial-off-the-shelf (COTS) components. Although previous studies have proposed specific COTS-based development processes, there are few empirical studies to investigate how to use and customize them to different project contexts. This paper describes an exploratory study of state-of-the-practice of COTS-based development processes. 16 software projects in Norwegian IT companies have been studied by structured interviews. The results are that COTS-specific activities can be successfully incorporated in most traditional development processes (such as waterfall or prototyping), given proper guidelines to reduce risks and provide specific assistance. We have identified four COTS-specific activities - the build vs. buy decision, COTS component selection, learning and understanding COTS components, and COTS component integration - and one new role, that of a knowledge keeper. We have also found a special COTS component selection activity for unfamiliar components, combining Internet searches with hands-on trials. The process guidelines are expressed as scenarios and lessons learned, and can be used to customize the actual development processes, e.g. in which lifecycle phase to put the new activities. Such customization crucially depends on project context, such as previous familiarity with possible COTS components and flexibility of requirements.

An empirical study on decision making in off-the-shelf component-based development

Component-based software development (CBSD) is becoming more and more important since it promotes reuse to higher levels of abstraction. As a consequence, many components are available being either open-source software (OSS) or commercial-off-the-shelf (COTS). However, it is still unclear how the decision for acquiring OSS or COTS components is made in practice. This paper describes an empirical study on why project decision-makers selected COTS instead of OSS components, or vice versa. The study was performed as an international survey in Norway, Italy and Germany. It focused on decision making on using off-the-shelf (OTS) components. We have gathered answers from 83 projects using only COTS components and 44 projects using only OSS components. Results of this study show significant differences and commonalities of integrating OSS or COTS components. Moreover, the study illustrates several research questions that warrant future research.