Commercial Off-The-Shelf (COTS) 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
Transcript
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.