Slide 1

1 Introduction 1.1 Definition 2 COTS based system 2.1 COTS product attribute 2.2 Advantages of COTS 3 COTS characterization framework 4 COTS in System Development 5 COTS APPLICATION

Slide 2

Introduction COTS products are highly related to component based software engineering (CBSE). So before introducing COTS lets have a look in CBSE ? In component-based software engineering, The system is assembled from existing components. CBSE approach emphasize on acquisition and integration of components to accomplish complex and large-scale software solutions.

Slide 3

The vision of CBSE is that a new system should be built by assembling components and that the new system should be functional with little effort since the components are already developed, tested, and matured by long execution in many different contexts.

Slide 4

Traditional development is changed to focusing on selection, evaluation, integration, and evolution of reusable software components. Today some systems include such complex components that developing them from scratch would be impossible if a profit is required.

Slide 5

Benefits of CBSE system quality improvement, shorter time-to-market, and improved management of complexity of software. However, the focus of development move to issues like selection, integration, evaluation and evolution of components in the system.

Slide 6

Underestimating the technical risks associated with selection, evaluation, and integration of software components can result in long schedule delays and high development/maintenance cost.

Slide 7

Back to COTS Many software developers have define COTS and some of these are mentioned below: Oberndorf It is defined as something that one can buy, ready-made, from some manufacturer's virtual store shelf. It carries with it a sense of getting, at a reasonable cost, something that already does the Definition and classification of COTS: a proposal Accepted at ICCBSS, Orlando (FL) February 4-6, 2002. - 3 / 10 - job. The main characteristics of COTS are: (1) it exists a priori, (2) it is available to the general public or (3) it can be bought (or leased or licensed)

Slide 8

Oberndorf define it as: It is defined as something that one can buy, ready-made, from some manufacturer's virtual store shelf. It carries with it a sense of getting, at a reasonable cost, something that already does the job. The main characteristics of COTS are: (1) it exists a priori (2) it is available to the general public or (3) it can be bought (or leased or licensed) The meaning of the term commercial is a product customarily used for general purposes and has been sold, leased, or licensed (or offered for sale, lease or license) to the general public. As for the term off-the-shelf, it can mean that the item is not to be developed by the user, but already exists.

Slide 9

Vidger provides a different definition of COTS products. He says: COTS are pre-existing software products; sold in many copies with minimal changes; whose customers have no control over specification, schedule and evolution; access to source code as well as internal documentation is usually unavailable; complete and correct behavioral specifications are not available.

Slide 10

According to the perspective of the SEI, COTS product is: sold, leased, or licensed to the general public; offered by a vendor trying to profit from it; supported and evolved by the vendor, who retains the intellectual property rights; available in multiple, identical copies; and used without source code modification.

Slide 11

Basili and Boehm According to their definition, COTS software has the following characteristics: (1) the buyer has no access to the source code, (2) the vendor controls its development, and (3) it has a nontrivial installed base (that is, more than one customer; more than a few copies). This definition does not include some kind of products like special purpose software, special version of commercial software, and open source software.

Slide 12

COTS-based Systems Carney: he identifies three types of COTS systems as a function of the number of COTS used and their influence on the final system: turnkey systems are built around a (suite of) commercial product(s); intermediate systems are built around one COTS but integrate other components; integrated systems are built by integrating several COTS, all on the same level of importance.

Slide 13

A similar classification of COTS-based systems is proposed with the concepts of COTS-solution systems (one substantial product (suite) is tailored to provide a turnkey solution) and COTS-intensive systems (many integrated products provide system functionality).

Slide 14

COTS products attributes Carney and Long [7] propose two attributes to characterize COTS, origin and modifiability, and provide some examples. There is no discussion of cost and property issues, which seems to be sometimes mixed with the origin axis, while in our opinion it should be discussed separately. No distinction can be found between what needs to be modified in order to make a product work and what can be modified in order to better integrate it into the delivered system.

Slide 15

COCOTS A classification of COTS products could be derived from the COCOTS models [1]. Some cost drivers could be used to identify COTS products categories: product maturity, supplier willingness to extend product, product interface complexity, supplier product support, supplier provided training and documentation. Most of these attributes are related to the supplier and market conditions and not to technology.

Slide 16

Yakimovich Several researches addressed the integration problem of COTS products; in particular the work by Yakimovich et al. [20] proposes a set of criteria for classifying software architectures in order to estimate the integration effort. The same characteristics are used to classify both the components and the systems.

Slide 17

Egyed et al. A methodology for evaluating the architectural impact of software components is proposed by Egyed et al. Such a method allows the selection of both the components and of a suitable architectural style. The key point is the identification of architectural mismatches. A.Egyed, N.Medvidovic, C.Gacek. Component-based perspective on software mismatch

Slide 18

Advantages of using COTS components Functionality is instantly accessible to the developer. Components may be less costly than those developed in-house. The component vendor may be an expert in the particular area of the component functionality.

Slide 19

Although, using COTS Components can save valuable development time, insight in the COTS component functionality and properties must be evaluated for its intended use. In order to integrate a COTS component in a system, the developers must consider relevant properties of the component like operational limitations, temporal behavior, preconditions, robustness and many forms of underlying assumptions on the intended environment. To determine its properties, extensive testing of the component may be necessary.

Slide 20

A summary of disadvantages includes Often, only a brief description of its functionality is provided with a COTS component. A component, often, carries no guarantee of adequate testing for the intended environment. There is no, or only a limited description of the quality of the component and the quality must be assessed in relation to its intended use. The developer, typically, does not have access to the source code of the component.

Slide 21

To make the decision to buy or to build is not easy, knowing all the disadvantages. COTS components are typically black boxes without their source code or other means of introspection available. Developers must assess a number of properties of the wanted COTS component to integrate it properly with a system under development. Examples of relevant properties are functionality, fault behavior, temporal behavior, preconditions, robustness and performance. To determine its properties, extensive testing of the component may be necessary. There are various approaches to this kind of testing, e.g. random, black-box and white-box test generators.

Slide 22

COTS characterization framework In Table 1 we propose a characterization framework for COTS. We propose a number of attributes and possible values to characterize a COTS product. A COTS product is described by a single value on each attribute. The attributes are grouped into four categories: 1. Source: where the product comes from. 2. Customization: how much the product can or should be customized. 3. Bundle: in what form the component is delivered, both to the integrator and to the customer of the system 4. Role: what is the intrinsic role the product can assume in the final system All of the attributes we propose are of ordinal type, except those in the role category, which are of nominal type.

Slide 23

CategoryAttributePossible Values SourceOriginIn-house < existing external