Catálogo de publicaciones - libros

Commercial off-the-shelf (COTS) software components promise benefits in terms of greater productivity, reduced time to market and reliability. However, their blackbox nature poses significant challenges assessing and managing the impact of change. We propose an approach to help developers to understand the impact of change. It relies on the use of a COTS component-oriented development process and an architecture description language (ADL) for documenting component system architectures; both elements contributing to create a combined approach to impact analysis in COTS-based system.

COTS (commercial off-the-shelf) component designers and developers often envision different usage contexts for their component and, therefore, provide it with adaptation possibilities. These adaptation possibilities are especially important when considering system families. System family engineering is currently an emerging discipline. Variability is a core property of system families which allows deriving different customer-specific applications from a core artifact base. A system family’s core artifact base may also be populated with COTS components. These COTS components then need to support the system family’s variability, i.e. they have to offer the possibility to adapt them to different customer-specific applications. Through their adaptation possibilities COTS components are able to meet this requirement. During COTS evaluation, a system family’s requirements and architecture need to be taken into account. Variability is inherent in both. That is, the question is how to evaluate COTS with regard to variable features. In this paper, we describe variability in architecture in more detail and point out how this variability needs to be reflected in COTS evaluation criteria. The contribution is an extension of ‘traditional’ COTS evaluation criteria in order to consider a system family’s variability.

From an analysis and design perspective, developers of COTS-based systems face many challenges driven by built-in product paradigms as well as the volatility of the marketplace. One way to deal with these challenges is to adopt a spiral development process that allows for concurrent discovery and negotiation of user needs and business processes, applicable technology and components, the target architecture, and organizational constraints. This paper outlines a workflow for Analysis and Design that can be used within spiral-based development processes for building systems from commercial components.

The integration of COTS components into a system under development entails architectural mismatches. These have been tackled, so far, at the component level, through component adaptation techniques, but they also must be tackled at an architectural level of abstraction. In this paper we propose an approach for resolving architectural mismatches, with the aid of architectural reconciliation. The approach consists of designing and subsequently reconciling two architectural models, one that is forward-engineered from the requirements and another that is reverse-engineered from the COTS-based implementation. The final reconciled model is optimally adapted both to the requirements and to the actual COTS-based implementation. The contribution of this paper lies in the application of architectural reconciliation in the context of COTS-based software development. Architectural modeling is based upon the UML 2.0 standard, while the reconciliation is performed by transforming the two models, with the help of architectural design decisions.

Reuse has the potential to substantially decrease the skyrocketing costs of space missions. The European Space Agency sponsored a study on the product assurance aspects of reuse of previously developed software on space projects, called PA-PDS. Several recommendations emerged from this study, along with change proposals to the main standards of software engineering and software product assurance followed by the European space industry. This paper describes those recommendations, the scope of reuse in the existing standards, and provides a justification for the proposed changes to them. A working group has been formed to develop a standard specifically addressing product assurance aspects of reuse.

A Reuse Management Plan defines the strategy for selecting, approving and upgrading common reusable software components The SEI, in conjunction with the U.S. Army, the Boeing Company, and the Fraunhofer USA Center for Experimental Software Engineering, is developing a Reuse Management Plan for a large Army program. Ten critical features of quality Reuse Management Plans have been identified and are presented.

Software components, both Commercial-Off-The-Shelf and Open Source, are being increasingly used in software development. Previous studies have identified typical risks and related risk management strategies for what we will call OTS-based (Off-the-Shelf) development. However, there are few effective and well-proven guidelines to help project managers to identify and manage these risks. We are performing an international state-of-the-practice survey in three countries – Norway, Italy, and Germany – to investigate the relative frequency of typical risks, and the effect of the corresponding risk management methods. Preliminary results show that risks concerning changing requirements and effort estimation are the most frequent risks. Risks concerning traditional quality attributes such as reliability and security of OTS component seem less frequent. Incremental testing and strict quality evaluation have been used to manage the possible negative impact of poor component quality. Realistic effort estimation on OTS quality evaluation helped to mitigate the possible effort estimation biases in OTS component selection and integration.

In this paper we focus on managerial and technical decisions for acquisi tion of OSS and discuss potential approaches to a widespread adoption of OSS. Moving from mainly techni cal issues in procurement to corporate IS governance presents OSS with new challenges beyond outlining a business case for a particular OSS application. We draw parallels to the business case for commercial software products (COTS). Compared with COTS, OSS products seem to have several advantages, but based on existing literature and a case study, we develop and discuss the hypothesis that a major barrier may be the “customer’s” uncertainty and unfamiliarity with OSS vendor relationships. We find that corporate governance and architecture needs to be accounted for in both COTS and OSS. This paper should be seen as a first step researching the fit between procurement and delivery models for OSS.

When referring to Open Source Software (OSS) components, researchers, coders and managers do not feel comfortable in defining them as COTS. Many discussions have been aimed to decide whether or not OSS can be considered a COTS without reaching the unanimous consensus of the different international communities. This paper abandons any theoretical aspect of that question and focuses on the practical steps to follow when assembling component-based systems using also OSS components. All the activities normally performed when integrating COTS in a in-house built software are reviewed with the intention of underlining if the availability of the source code (and its possible exploitation) makes any difference. Moreover this article analyzes all the activities to perform when using OSS in a component-based system that are not necessary when using COTS. The purpose of this paper is to provide a guideline for the correct use of OSS within component-based systems, and not to answer whether OSS are considered or not COTS, leaving this task to the reader.