The authors of this paper are co-editors of the COTS area within the IEEE SE Online portal [1]. Since their mission is to provide a unified view of the research and best practices regarding CBD .... Meanwhile a problem domain expert has to analyze the problem ... a choice. First of all a make-or-buy option must be selected for.
Towards a Reference Framework for COTS-Based Development: A Proposal Xavier Franch Department de Llenguatges i Sistemes Informàtics Universitat Politècnica de Catalunya Spain franch@lsi.upc.edu
Marco Torchiano Dipartimento di Automatica e Informatica Politecnico di Torino Italy marco.torchiano@polito.it We do no propose complete process models, only reference processes, loose enough to accommodate several concrete processes proposed in the literature.
ABSTRACT The literature about COTS-based development suffers from two main problems: there is no common terminology and it is not clear whether different techniques address the same issues and to which extend they overlap. In this paper we describe a reference model that sets the basis for a COTS-based development ontology and terminology. It should allow a systematic organization of published studies and an easier comparison of proposed approaches.
2. RELATED WORK Several works have been devoted to defining reference process for CBD. One of the earliest attempt to model the CBD process can be found in [13]: a process actually used in a project is analyzed and some improvements are proposed.
Keywords COTS components, COTS-based development.
In [15] the authors present a measurement based detailed process for COTS selection, where several screening steps are performed and information is stored for future reuse.
1. INTRODUCTION The literature about COTS-based development (CBD) addresses several development issues and is very heterogeneous in terminology.
In [2] there are a set guidelines for developing CBD processes, it is a sort of cookbook for building a customized process.
There is no clear way of understanding how to combine together different techniques and methods proposed by independent researchers. The problem is that it is not clear witch issues are covered by which method and how they overlap.
In [11] we can find a formalized approach for the evaluation and selection of COTS products.
In [6] there is an iterative process for COTS evaluation.
In [7] an architectural framework for the acquisition of COTS is proposed.
Often studies that address the same issue use very different terminologies, therefore it is not easy to compare or integrate them.
These and other widespread [5, 10, 12] COTS selection processes and frameworks share many similarities which supports our motivation of defining a general reference model in which all of them can fit.
Therefore, we need a unifying framework to describe the work done in the CBD area plus a consistent terminology. The authors of this paper are co-editors of the COTS area within the IEEE SE Online portal [1]. Since their mission is to provide a unified view of the research and best practices regarding CBD they strongly need such a reference model.
3. REFERENCE FRAMEWORK We describe the framework in terms of generic processes taking place in the development of a CBS. First we will set the context concerning CBD and then we will present the two main phases: procurement of COTS products and implementation of the CBS.
The reference model includes: • • •
In this paper, we will focus on the COTS-related issues only, therefore the details that are common to all traditional software development processes will be left outside the current reference framework. It should be mentioned that the activities not present in the framework also play a very important role in CBD and in fact they also may be affected with the use of COTS products.
a common basic terminology, a definition of the context of interest, a set of reference process models.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MPEC’05, May 21, 2005, St. Louis, Missouri, USA. Copyright 2005 ACM 1-58113-000-0/00/0004…$5.00.
3.1 Terminology We define next the essential terminology required to understand the rest of the reference framework. COTS: Commercial Off-The-Shelf
1
are summarized in Table 1 together with their activities.
COTS product (aka COTS component, software package, out-of-the-box product, shrink-wrap solution): A piece of software that is not developed inside the project, but acquired from a vendor and used “as-is”, or with minor modifications.
The overall procurement process is described in Figure 2. There are two preliminary activities that are required for procurement: on the one side, we need to identify the suitable COTS products, while on the other side we have to analyze the problem domain.
COTS-based software system (CBS): A software system that is built mainly as the composition of COTS products, or as the customization of one single COTS product.
SOFTWARE ENGINEERING TEAM
PROVIDER
COTS-based Development (CBD): the processes that lead to the development of a COTS-based software system, by extension also the enactment of such processes.
CUSTOMER
PRODUCE
PROCURE
REQUIRE
3.2 Context The context of the CBD process can be represented as shown IMPLEMENT
in Figure 1; we focus on the activities performed by the software engineering team that delivers the CBS. From a very abstract point of view, the software engineering team first procures and then implements the CBS.
Figure 1. CBD Context. A COTS marketplace expert performs the initial identification of COTS products and COTS domains, taking information from the overall marketplace. This activity has the goal of narrowing the further steps to a reduced set of products that can potentially be suitable for the development of the CBS. During this activity the classification of COTS products becomes an important issue [3, 4, 14, 16].
The COTS components are produced by a COTS provider. They can belong to one or more domains; the set of all COTS domains form the COTS marketplace. The customer that requires the system formulates a system requirements document that will guide the software engineering team in their work.
Meanwhile a problem domain expert has to analyze the problem and model it. The resulting problem domain model is used later for the selection of the COTS products to be integrated into the CBS.
3.3 Procurement The procurement phase involves several roles both internal and external to the development team. The concerned internal roles
* Contracts
CUSTOMER
LAWYER
Negotiate PROVIDER MARKETPLACE EXPERT * CBS Architecture COTS Marketplace
PROBLEM DOMAIN EXPERT
Selected COTS Products
Identify
Analyze
Select *
* Problem domain model
COTS Products Selected COTS Domains
EVALUATOR * Evaluate
COTS Evaluations
Figure 2. Procurement.
2
System Requirements Document
Table 1. Procurement roles. Role Activity Marketplace Expert Identify COTS domain and products Problem Domain Expert Analyze the problem Evaluator Evaluate and select COTS products Lawyer Negotiate a contract
3.4 Implementation As the previous phase, the implementation phase involves several roles both internal and external to the development team. The concerned internal roles are summarized in Table 2 together with their activities. The overall implementation process is described in Figure 3. There two stages in the implementation: first the components defined by the architecture of the system must be prepared and then they can be integrated into the CBS and delivered to the customer. One of the problems related with integration is COTS interaction, and therefore communication means (e.g., XML data or APIs) should be identified and included in the detailed CBS architecture.
An evaluator assesses (evaluates) the previously identified candidate COTS products producing a set of COTS evaluations. Then on the base of the evaluations, the system requirement document and the problem domain model, it is possible to make a choice. First of all a make-or-buy option must be selected for the components of the architecture of the CBS. In the cases a buy option has been selected, the best COTS product has to be selected.
The selected COTS products may need a customization before the integration into the final system. In general for commercial software an installation is sufficient, while for other system more work can be required.
The result of this activity is a list of selected COTS products that will be integrated into the final CBS. In addition a draft software architecture of the system is produced [9]. Both the selection process and the architecture should deal with COTS interaction issues. During selection, this means that integration requirements play an important role.
The COTS products can be integrated with components developed in-house. Such components can be developed ad-hoc for the project or can be reused from other project within the organization. In the former case one or more developers start coding as soon as the architecture of the system has been defined. In the latter case the component can be modified to be adapted to the needs of the CBS (this is a sort of white-box customization as opposed to the black-box customization or tailoring of COTS products).
The final activity of the procurement phase consists in the negotiation of contracts both with the COTS providers, if necessary, and with the customer. The negotiation should be carried on by a lawyer that is expert with legal matters supported by the information produced in the earlier activities.
CBS Architecture CBS
* Selected COTS Products
Customise
* Customised COTS Products
Integrate * In-house Components
Code PROVIDER
Glue Code
INTEGRATOR Accept
DEVELOPER
CUSTOMER
Figure 3. Implementation.
3
Role Developer Integrator
Table 2. Implementation roles. Activity Develops in-house components and glue code Integrates COTS products, in-house components and glue-code
[6]
[7]
The components of the system may have some problems in cooperating as they are. Such problems range from compliance with different versions of standards or their bad implementation [17], to architectural mismatches [8]. Usually adding some code to mediate between components is the solution to these problems: such code is called glue-code.
[8]
[9]
Once the components are ready they can be integrated into the CBS by an integrator. Eventually the CBS must be accepted by the customer.
[10]
4. CONCLUSIONS We presented development.
a reference framework for COTS-based [11]
This framework can provide a high-level and unified view of what happens with CBD.
[12]
In our intentions, this work fosters better communication among researchers in the field and a homogeneous terminology.
[13]
This work is open for discussion, modification and enrichment. As a further work we plan to link the activities defined in the reference framework to methods that have been proposed in the literature.
[14]
Our intention is to include this framework in the COTS area of the IEEE SE Portal as a map of the contents.
5. REFERENCES [1]
[2]
[3]
[4]
[5]
[15]
IEEE SE Portal, available at: http://billing.computer.org/portal/site/seportal/ (last access April 4, 2005), L. Brownsword, T. Oberndorf, and C. A. Sledge, "Developing New Processes for COTS-Based Systems" IEEE Software, 17 (4): 48-55, July/August 2000. D. Carney and F. Long, "What Do You Mean by COTS? Finally a Useful Answer" IEEE Software, 17 (2): 83-86, March/April 2000. J. P. Carvallo, X. Franch, C. Quer, and M. Torchiano, "Characterization of a Taxonomy for Business Applications and the Relationships among them" Proc. of Int. Conf. on COTS Based Software Systems (ICCBSS 2004), Redondo Beach (CA), USA, 1-4 February, 2004 L. Chung and K. Cooper, "COTS-Aware Requirements Engineering and Software Architecting" Proc. of Software
[16]
[17]
4
Engineering Research and Practice Conference (SERP), 2004 S. Comella-Dorda, J. Dean, E. Morris, and T. Oberndorf, "A Process for COTS Software Product Evaluation" Proc. of 1st International Conference on COTS Based Software Systems (ICCBSS), Orlando (FL), February 4-6, 2002, pp. 86-96. B. Craig Meyers and P. Oberndorf, Managing Software Acquisition – Open systems and COTS products: Addison Wesley, 2001. D. Garlan, R. Allen, and J. Ockerbloom, "Architectural mismatch: why reuse is so hard" IEEE Software, 12 (6): 17-26, November 1995. L. Jaccheri and M. Torchiano, "Integrating Architecture and Familiarization in CBD Processes" Proc. of MPEC'04, Edinburgh (UK), May 25, 2004, pp. 53-56. J. Kontio, "A Case Study in Applying a Systematic Method for COTS Selection" Proc. of IEEE-ACM 18th International Conference on Software Engineering, Berlin, Germany, March 25-29, 1996, pp. 201-209. P. Lawlis, K. Mark, D. Thomas, and T. Courtheyn, "A Formal Process for Evaluating COTS Software Products" IEEE Computer, 34 (5): 58-63, May 2001. N. Maiden and C. Ncube, "Acquiring COTS Software Selection Requirements" IEEE Software: 46-56, March/April 1998. M. Morisio, C. Seaman, A. Parra, V. Basili, S. Condon, and S. Kraft, "Investigating and Improving a COTS-Based Software Development Process" Proc. of 22nd International Conference on Software Engineering, Limerick, Ireland, June, 2000, pp. 32-41. M. Morisio and M. Torchiano, "Definition and classification of COTS: a proposal" Proc. of 1st International Conference on COTS Based Software Systems (ICCBSS), Orlando (FL), February 4-6, 2002, pp. 165-175. M. A. Ochs, D. Pfahl, G. Chrobok-Diening, and B. Nothhelfer-Kolb, "A COTS Acquisition Process: Definition and Application Experience" Proc. of 11th ESCOM Conference, Shaker, Maastricht, 2000, pp. 335343. M. Torchiano, L. Jaccheri, C.-F. Sørensens, and A. I. Wang, "COTS Products Characterization" Proc. of Conference on Software Engineering and Knowledge Engineering (SEKE'02), Ischia, Italy, July 15-19, 2002, pp. 335-338. M. Torchiano and M. Morisio, "Overlooked Aspects of COTS-Based Development" IEEE Software, 21 (2): 8893, March/April 2004.
