The document proposes five repositories to support the COTS selection process: 1) a COTS repository to store information on screened products, 2) a user repository for stakeholder preferences, 3) a discussions repository for sharing ideas, 4) a lessons-learned repository, and 5) a historical information repository. It describes designing and implementing a database integrated into a decision support system to provide distributed access and persistence of information across the various repositories during COTS selection.

1. REPOSITORIES FOR COTS
SELECTION
Asheesh Ranjan 2K11/SE/012
Gaurav Sharma 2K11/SE/028
Pranav Jetley 2K11/SE/049
Varun Kalra 2K11/SE/082

2. ● In the context of COTS selection, knowledge
management refers to the process of storing and
retrieving data and information generated by the
various activities of the COTS selection process.
● The issue of putting in place techniques and
procedures for setting up and maintaining COTS
repositories, has not attracted attention
Introduction
2

3. ● Initial suggestions for COTS repos included web
components repository which consisted of:
o The components store
o The metadata store
o The search/browsing tool
● CeBASE lessons-learned repository for CBSD is
another web-based repo, and it has lessons-learned
that were extracted from various sources (Journals,
reports etc.)
Some COTS Repo
3

4. ● Existing COTS selection repositories were specialized
in nature and they can not act as a single stop point
for CBSD.
● Standardised set of repositories that are necessary
for the effective execution of the COTS selection
process. The repositories can be integrated into a
CSDSS.
Problem and Solution
4

5. ● COTS selection repositories
● Design of the COTS selection repositories
● Implementation of the COTS selection
repositories
● COTS Selection Decision Support System
(CSDSS)
Outline
5

6. COTS Selection
Repositories

7. • The COTS repository stores the information about the
screened COTS alternatives, as well as the requirements
of the system being developed.
• For CSDSS, the repository is designed as a searchable
database that can accommodate multiple projects.
COTS Selection Repositories
7

8. COTS Selection Repositories
8

9. Module A: This module stores general
models used to collect and organize the
information in Module B and Module
C.
COTS Selection Repositories
9

10. • Module B: This module contains all relevant
information about each alternative COTS
product.
• This information is stored according to the
models provided by Module A.
• The main source of information for Module B
is the vendors of COTS products.
COTS Selection Repositories
10

11. • Module C: This module contains the association information of
alternative COTS products.
• Part of this information is the software architecture features of
the COTS products, which include the following types of COTS
attributes:
1. Ports:-Interface of component to the outside world
2. Resources:-Entities that are exchanged by the ports
3. Connections:-Measure of the degree of connectivity between two
COTS products
The main sources of information for Module C are the
designers and the domain experts.
COTS Selection Repositories
11

12. • Module D: Information in Module B and Module
C is integrated by the designers and experts to
generate the characteristics of various system
configurations.
• The characteristics of the configurations are
stored in Module D.
COTS Selection Repositories
12

13. • MODULE E: The evaluation criteria, and the
performance descriptions and rankings of the COTS
products and/or designs in every criterion, are stored
in Module E.
• The CSDSS we developed use semantic net as the
knowledge representation language of this module.
COTS Selection Repositories
13

14. Design of COTS Selection
Repositories

15. Each user needs to be allocated a repository where
he/she stores his/her user preference models and the
associated preference value functions.
At the end of the project, the final user preference model
and the final preference value function is transferred to
historical information repository, where it is stored
according to the domain of the project (e.g. accounting
software) and the role of the user (stakeholder, e.g.
customer).
User Repository
15

16. • The discussions repository allows the stakeholders to store
and retrieve their discussions.
• The user can search the repository according to date of
posting, topic, role, and/or name of the person who posted
the discussion.
• Besides enabling swapping of thoughts among stakeholders,
the repository assists in the post mortem analysis of the
COTS selection process.
Discussion Repository
16

17. The lessons-learned repository associated with the COTS
selection framework we developed has three types of
components:
1. Local component which is allocated to each COTS selection
stakeholder,
2. Social component which stores the lessons-learned from a
particular project, and the
3. Grand component that stores the lessons-learned from COTS
selection processes associated with various projects.
Lessons-Learned Repository
17

18. Lessons-Learned Repository
18

19. Information generated during COTS selection is transferred
to the repository of historical information for future use.
This repository has two main components:
1. Grand lessons learned component
2. Historical COTS and user information component which contains:
 User preference models and values functions
 COTS information in Module E of the COTS repository
 Project description information such as project domain, cost, and
schedule
Repository of Historical
Information
19

20. • The database is designed to store knowledge about COTS
products as well as the user information
• It can be extended to accommodate the information
associated with all the repositories
The database design encompasses four main areas:
1. COTS information storage and evaluation
2. System authentication and data persistence
3. Data extraction
4. Negotiation algorithm support
Design of the COTS Selection
Repositories
20

21. Implementation of COTS
Selection Repositories

22. • The database can be implemented using the Oracle
database system for data storage and extraction and
the appropriate Java Database Connectivity (JDBC)
libraries for collecting and presenting the data to the
system.
• Data extraction from the database is regulated through
the use of standard naming schemes and access of the
data dictionary to provide generic and complete entry
points for the JDBC function calls
Database Implementation
22

23. • An API can be implemented using a variety of Java classes as
data containers as well as various static function calls.
• Basic user permissions can be integrated into the API which
ensured that only users authorized to use various API
functions could use those functions.
• In this way another layer of security was added in that the
database would only be accessible by the appropriate users,
allowing greater integration.
Database Implementation
23

24. COTS Selection Decision
Support System
24

25. ● CSDSS is based on multi-agent technology
● Agents have to manage COTS selection
database
● Repositories provide persistence of
stakeholder configuration, preferences and
negotiation
● Database has a component for tracking the
COTS selection process.
CSDSS
25

26. CSDSS based on agent technology
26

27. Summary

28. ● Selecting COTS products is a challenging
process that utilizes and generates a lot of
information.
● Five different repositories for the COTS
selection process :
o COTS repository
o user repository
o discussions repository
o lessons-learned repository
o historical information repository
Summary
28

29. ● Supports distributed contribution and
access to the repositories.
● Database that was implemented as part
of a Decision Support System (DSS) for
the selection of COTS products.
Summary
29

30. References
● Repositories for COTS Selection, Tom
Wanyama and Behrouz Homayoun