Test suite reduction is an important test maintenance activity that attempts to reduce the size of a test suite with respect to some criteria. Emerging trends in software development such as component reuse, multi-language implementations, and stringent performance requirements present new challenges for existing reduction techniques that may limit their applicability. A test suite reduction technique that is not affected by these challenges is presented; it is based on dynamically generated language-independent information that can be collected with little run-time overhead. Specifically, test cases from the suite being reduced are executed on the application under test and the call stacks produced during execution are recorded. These call stacks are then used as a coverage requirement in a test suite reduction algorithm. Results of experiments on test suites for the space antenna-steering application show significant reduction in test suite size at the cost of a moderate loss in fault detection effectiveness. 1.

Development of a software system from existing components can surely have various benefits, but can also entail a series of problems. One type of problems is caused by a limited exchange of information between the developer and user of a component. A limited exchange and thereby a lack of information can have various consequences, among them the requirement to test a component prior to its integration into a software system. A lack of information cannot only make test prior to integration necessary, it can also complicate this tasks.

The use of components in development of complex software systems can surely have various benefits. Their testing, however, is still one of the open issues in software engineering. Both the developer of a component and the developer of a system using components often face the problem that information vital for certain development tasks is not available. Such a lack of information has various consequences to both. One of the important consequences is that it might not only obligate the developer of a system to test the components used, it might also complicate these tests. This article gives an overview of component testing approaches that explicitly respect a lack of information in development.

Commercial-off-the-shelf (COTS) software tends to be cheap, reliable, and functionally powerful due to its large user base. It has thus become highly desirable to incorporate COTS software into software products (systems) as it can significantly reduce development cost and effort, while maintaining overall software product quality and increasing product acceptance. However, incorporating COTS software into software products introduces new complexities that developers are currently ill equipped to handle. Most significantly, while COTS software frequently contains programmatic interfaces that allow other software components to obtain services from them on a direct call basis, they usually lack the ability to initiate interactions with other components. This often leads to problems of state and/or data inconsistency. This paper presents a framework for integrating COTS software as proactive components within a software system that maintain the consistency of the state and data they share with other components. The framework utilizes a combination of low-level instrumentation and high-level reasoning to expose the relevant internal activities within a COTS component required to initiate the communication needed to maintain consistency with the other components with which it shares state and data. We will illustrate these capabilities through the integration of IBM's Rational Rose into a design suite and demonstrate how our framework solves the complex data synchronization problems that arise from this integration.

COTS-based development (CBD) raises a spectrum of issues, from requirements negotiation to product selection and product integration. The studies on this topic are often in disagreement, lack details about products and projects, and are based on uncritically-accepted assumptions. This was confirmed by an analysis of the literature from which we derived a list of characterizing features for CBD. In order to explore these issues from an empirical perspective, we conducted an exploratory study, based on structured interviews to projects in small and medium- enterprises in Europe. From them we derive two results: key points in COTS based development as it happens in companies; and a definition of COTS product capable of capturing these key points. Keywords: COTS-based development, COTS products, empirical study. 1

Abstract. In recent years component-based development has in resent years become an established approach. Component-based Software Engineering (CBSE) that deals with the entire lifecycle of component-based products has been focused on technologies related to design and implementation of software components and systems built from software components. The experience has shown that pure technologies alone are not enough. A CBSE approach requires certain changes in development and life cycle processes. However very few CBSE works, either research or practical, have addressed these topics. This paper describes principle differences of component-based and noncomponent based processes. Also we an overview of a case study from a company that applies component-based approach. Keywords. Component-based software Engineering, Life cycle processes

For a growing population of researchers in software engineering, empirical studies have become a key approach of research. Empirical studies may be used, for example, to evaluate technologies and help to direct further research by revealing what problems and difficulties people have in practice. Without empirical studies, we have to rely only on intuition or educated opinion. Individual empirical studies often yield interesting results for their particular context, but typically this context is not described in sufficient detail to decide whether another context is similar enough to apply the conclusions of the study also there. We argue instead that families of experiments with a common framework for collecting context data are necessary in order to abstract conclusions at a useful level of detail. This paper describes a method to plan, conduct, and analyze coordinated, or concerted, families of experiments. The goal of the method is to maximize the quality and benefit of the individual empirical studies as part of the family and to minimize the effort for researchers by reusing experiment know-how. This is achieved by providing, for all studies of the experiment family, a common framework for context measurement, study preparation, material, and analysis. We apply the method to describe the planning steps for an experiment family on the influence of context on the effectiveness of defect reduction techniques. We focus on a particular technology, reading techniques for inspections, to instantiate this work. The first step of this experiment family is a broad survey of software companies on the state of the practice of inspection process and inspection techniques. The second step is to benchmark state-of-the-art inspection techniques with the participating organization's own documents and inspection techniques.

Among the main activities involved in COTS-based development there are identification, evaluation, and selection of COTS products. Several techniques have been developed for these activities; all of them are based on measurement of attributes. The effort devoted to these activities is more valuable if the attributes can be reused. Since the evaluation of COTS is a very project-specific activity, the definition of reusable attributes is difficult. Several studies show that it is possible and convenient to develop a reusable attribute framework. We propose a set of simple and generic criteria can be used to validate the set of attributes and improve them.

Development of a software system from existing components can surely have various benefits, but can also entail a series of problems. One type of problems is caused by a limited exchange of information between the developer and user of a component. A limited exchange and thereby a lack of information can have various consequences, among them the requirement to test a component prior to its integration into a software system. A lack of information cannot only make test prior to integration necessary, it can also complicate this tasks. However, difficulties in testing can be avoided if certain provisions to increase testability are taken beforehand. This article describes a new form of improving testability of, particularly commercial, components, the self-testing COTS components (STECC) strategy. KEY WORDS COTS components, self-testing components.

Abstract. To gain competitive advantages software organizations are forced to develop systems quickly and cost-efficiently. Reusing components from thirdparty 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. 1