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
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.
 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.
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.
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.
Underestimating the technical risks associated with
selection, evaluation, and integration of software
components can result in long schedule delays and
high development/maintenance cost.
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)
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.
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.
 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.
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.
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.
 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).
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.
 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.
 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.
 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
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.
 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.
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.
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.
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.
Category
Attribute
Possible Values
Source
Origin
In-house < existing external <externally
developed < special version of commercial
<independent commercial
Cost & Property
Acquisition < license < free
Required Modification
Minimal <parameterization <customization
< internal revision <extensive rework
Possible Modification
None or minimal < parameterization
< customization < programming <sourcecode
Interface
None < documentation < API < OO interface
< contract with protocol
Packaging
Source code < static library <
dynamic library < binary component
< stand-alone program
Delivered
Non delivered < partly < totally
Size
Small < medium < large < huge
Functionality
Horizontal, vertical
Architectural level
OS, middleware, support, core, UI
Customization
Bundle
Role
1. Source
 Origin
The possible values that are propose for this attribute are: inhouse, existing external, externally developed, special
version of commercial, independent commercial. We
consider as commercial a product that is generally
available to the public. So are open source and free
software products.
 Cost and property
The COTS can be obtained for a price or free. Obtaining the
COTS could mean acquiring the source code or the
executable code. The possible values we propose for this
attribute are: acquisition, ownership of the product
(including source code) is transferred to the buyer; license,
a use license fee is required to use the product; free, no fee
is required. Related legal / commercial issues are liability
for defects contained in the COTS, responsibility for
maintenance, and export restrictions.
2. Customization
 Required Modification.
This attribute corresponds to the modifiability dimension proposed in [7]. It has
five possible values: extensive reworking, internal code revision,
customization, parameterization, minimal. The first two of them assume
access to code, the second two imply some mechanism built into the COTS
to modify its functionality, the last indicate almost no modification.
 Possible Modification.
This attribute refers to the internal possible customization of the COTS product.
Such kind of modification is not required by the COTS to deliver its basic
functionality. As an example, the open source web server Apache typically
requires only simple parameterization, although its source code is accessible
making any in-depth modification possible. The possible values of this
attribute are:
source code, code is available and can be modified; programming, a complete
set of API or interfaces is provided possibly together with a scripting
language; customization, it is possible to define macros or configuration
files; parameterization, parameters can be defined for the product; none or
minimal, the product cannot be modified.
3. Bundle
 Packaging.
The COTS can be packaged in different ways. Possible values for this attribute are:
source code, statically linkable binary library, dynamically linkable library, binary
component, stand-alone executable program. Packaging is the form in which the
COTS product is used. A standalone program does not preclude access to the
source code.
 Delivered.
Considering the product delivered to a customer or user, a COTS product can be
integrated in it or not. If we consider a project developed in C, the C compiler is
not part of the delivered system. However, some tools usually associated with
the C compiler (e.g. the library of I/O functions) are probably integrated in the
final product. Possible values for this attribute are: non-delivered, partly,
completely.
.
3. Bundle (cont.)
 Size.
An important factor is the size of the COTS, we propose a simple
classification in 4 groups ranging from small, like UI widgets, to
huge, like the Oracle 8 DBMS or the Windows NT operating system.
The approach we adopt is based essentially on the size of the COTS
product (the figures in MB are indicative): small
means less than 0.5 MB, medium means from 0.5MB to 2MB, large
means from 2MB to 20MB, huge means more than 20MB. An
alternative measure is based on the number of use cases supported by
the product[9]. While this method has the potentiality to become a
good measure of the computational size of software products, it has
several drawbacks. The size and complexity of each use case may
vary greatly and thus the measure of the size could be inaccurate.
Besides, use cases for COTS products usually are not available.
4. Role
4.1 Type of functionality
COTS offer a variety of functions, however they can be classified in two
broad categories.
a. horizontal, the functionality is not specific to a domain, but can
be reused across many different application domains (e.g DBMSs,
GUIs, networking protocols, web browsers);
b. vertical, the functionality is specific to a domain, and can be
reused only in the domain (e.g. financial applications, accounting,
Enterprise Resource Planning, manufacturing, health care
management, and satellite control).
Horizontal COTS have been available on the market for a long time,
experience and know how about them are usually widely available. As
a result, using horizontal COTS is usually less risky and more common
than using vertical COTS.
4.2 Architectural Level
This attribute is somewhat similar to the previous one, but it
refers to a generic layered computing architecture. The levels we
propose are:
 Operating System; Middleware, software which enable
communication and integration; Support, elements that cover a
well defined and standardized role in the architecture but do
not provide vertical functionality; Core, products which
provide domain specific functionalities; User Interface, highly
reusable user interface components.
COTS in System Development
 The question whether to buy or develop a component
can require an extensive examination in the case of
each component in order to determine buy or build. In
order to make decisions, several aspects of COTS usage
must be understood and evaluated. Moreover, the
general benefits and challenges should be understood.
 This section presents an overview of general
benefits and challenges together with issues related to
specific aspects of COTS development.
COTS Driving Forces
The main driving factors for using COTS components rather
than developing the whole system in-house Includes:
1. Industrial competition for delivering more reliable systems in
shorter time frames.
2. A demand for larger and more complex software solutions,
which often can not be effectively implemented in a timely
manner by a single software development organization.
3. Increase in availability of reusable COTS components.
4. Increased degree of standard compliance among COTS
software products that enables reduction of product
integration time.
5. Increasing research in better software component “packaging”
techniques and approaches.
6. Increasing recognition that software reuse is one of the most
important means to achieve better software solutions with
minimum development cost.
COTS Challenges
There are several challenges when using COTS
components instead of developing in-house.
Assessing functionality, integration, operational profile,
quality for intended use, performance
and other properties may require substantial effort.
Developers must have a good understanding of the
COTS component relevant properties. General
guidelines on which properties are relevant are hard to
present and depend on the system to be developed.
Reliability Issues with COTS
The issue of system reliability differs when using COTS
components compared to traditional
development. The key in integrating COTS components is to
understand the components
properties like its intended environment and the assumptions
under which it was developed. Any
discrepancies must be handled in order to perform a
successful integration. There are several
risks involved when using COTS products.
General issues to consider when
using COTS
 Assure COTS components are applied within their
intended profile.
 Understand and document how the COTS components
behave in a faulty situation.
 Use guidelines and tools to deal with supplier changes and
upgrades of the COTS
component.
 Determine if future releases of the COTS component are
backward compatible.
 Investigate what development procedure has been used
and if it complies with any reliability
standards.
Development Process Issues
The principal danger of using COTS components in safety
critical applications lies in the discontinuity it creates in the
understanding of the system as a whole . The designer of the
component may not have full knowledge of the application
or systems where their component is to be used. Moreover,
the application developer may not fully understand the
component’s intended use and underlying assumptions.
When developing an application and including COTS
components, it may be beneficial to set up teams consisting
of both application developers and the COTS developers to
geta common understanding of the COTS behavior and
intended use. Such teams facilitate better relationships
between the user and the supplier, which makes
investigation of the supplier’s development process easier.
Development Process Issues(cont.)
Any COTS components intended to be used insafety-critical
applications should be thoroughly tested in its intended
environment. If unreliable or superfluous sections are
found, it can be possible to wrap those parts with
protective code. One way of performing tests of COTS
components is to use fault injection that can reveal the
consequences of failures in COTS components on the rest
of the system.
COTS APPLICATION
We have defined the attributes in Table 1with an exhaustive
approach, including all attributes that, by speculation,
could be relevant to characterize and distinguish COTS
products. Table 2shows that the proposed attributes are
able to discriminate products that any practitioner
considers as COTS, but also as very different from one
another, not only in terms of the functionality offered,
such as operating system, file sharing utility, or user
interface widget. For lack of space we limit the list to
three products.
However, some attributes could be useless to characterize
certain COTS products, or the number of attributes could
be too high for any practical use. We need to
discriminate the necessary and sufficient attributes.
COTS product
Attribute
MS Windows NT MS Samba
Chart Control
MS Chart Control
Origin
Indep. Comm.
Indep. Comm
Indep. Comm.
Cost & Property
License
Free
License
Required
Modification
Parameterization
Parameterization
Minimal
Possible
Modification
Programming
Source code
Programming
Interface
API
API
Contract
Packaging
Standalone
Standalone
Binary Component
Delivered
Completely
Completely
Completely
Size
Huge
Large
Small
Functionality
Horizontal
Horizontal
Horizontal
Architectural Level
OS
Middleware
UI
Hypotheses
We identified a set of hypotheses about the possible
impact of the attribute values on the development
process of the delivered system. An overview of these
hypotheses is presented in Table 3.
Role
Bundle
Customization
Source
Attribute
Impact on the process
Origin
ease of change, availability of certification, control on
product customization, marketplace competition
Cost & Property
acquisition and maintenance costs
Required
Modification
customization cost, comprehension effort, integration effort
Possible
Modification
adaptability, ease of integration
Interface
ease of integration, language/middleware lock-in,
architectural contstraints and mismatches
Packaging
porting and adaptation effort, configuration management,
platform constraints
Delivered
redistribution issues (both legal and commercial)
Size
learnability, setup effort
Functionality
Reusability across projects, availability of required
functionality
Architectural
level
the choice of the product can be dictated by external
factors, different integration problems
Conclusion
System development with a CBSE approach can be complex
process, as several issues must be
considered before deciding to buy or to develop a wanted
component. Generally, it is often better to buy generalpurpose components, e.g. operating systems, databases
and user interface components and to develop domain
specific components. Many different aspects must be
considered before choosing an existing component over an
internal.
The development of proprietary components takes
resources, requires maintenance and support, but gives
better freedom as to the exact specification. Buying a
component on the other hand, saves development time,
but may require substantial effort in integration and
perhaps negotiation of the requirements.
Before making decisions on buy/build issues for CBSE
development, the following questions and thoughts should be
considered:
 The functionality provided by a COTS component may not
remain the same with newer versions of the component. This
may force creation of wrappers for the component, which provide
or prevent functionality. If the support from the component
vendor is inadequate, this could be a serious issue. If unwanted
functionality is removed, the price may be paid unnecessarily.
 Even if the source code is available from the component vendor,
can our organization maintain it if something goes wrong?
 If an external component is customized for a product, it makes
the product strongly dependent on the component vendor. The
vendor can then set his own price for continued support of the
component
There are many issues surrounding CBSE to be addressed
before making decisions on how to design a system with
components. These are some of them:
 Create good and long term relations with the supplier for
better cooperation.
Limit the number of partners and suppliers. Too many will
increase the costs and the dependencies.
 Buy “big” components where the profit is greatest. The
management of too many small components can consume
the profit.
 Adjust the development process to a component-based
process.
 Have key persons assigned to supervise the component
market, monitoring new components and trends.
(Cont.)
 Try to gain access to the source code. Through special
agreements with the vendors etc.
 Test the components in the target environment.
 Assure COTS components are applied within their intended
profile.
 Understand and document how the COTS components
behave in a faulty situation.
 Use guidelines and tools to deal with supplier changes and
upgrades of the COTS component.
These recommendations do not provide a complete solution to
all the problems that may occur, but they indicate that
developing for and with components must be performed
carefully.