The cost of standardizing components for software reuse

Abstract

m Software reuse can be an important step towards increasing productivity and quality. A necessary condition for its success is standardization of reusable components at each level of the software lifecycle. Standardization can be looked at in two different ways: externally (the interface), and internally (functionality). Both of these are fundamental, and imply extra costs in the development of components. The external perspective is the usual one—it considers the appearance of the components and the ways they are related to the rest of the world. The internal perspective is strongly related to reuse: here a component is considered standard when its functionality is common among all systems belonging to a particular domain; such components are usually discovered following domain analysis. A qualitative analysis of these two approaches to standards and reuse led us to a simple model showing the extra costs of standardizing reusable software components. he reuse of existing software in the development of new systems is widely studied. Despite its benefits, software reuse is not a guaranteed success, and is generally a cost-intensive investment. Among the many factors that can affect the success of a reuse program is the design and realization of the components likely to be reused, and particularly their adequate standardization. When dealing with standards and resuable software, we must first see a component as not only a code module, but as all the other products of the software lifecycle, as for instance the design and requirements. The higher the level of the component, the greater the benefits of its reuse. Given a software component in a reuse context, we can choose more than one perspective from which to determine whether or not it is standard. We can look at the interface or at its functionality. Both are equally important for the success of a reuse program. In fact, a component without an interface that is immediately understandable and easy to integrate and adapt, i.e., a component not designed with a “plug and play” philosophy, implies adaptation and integration costs which can easily overrun the value of the component. At the same time, a perfect “plug and play” interface can be nearly useless if it is used for a component that is almost unique and thus has practically no chance of being reused. In the following we will define more precisely a standard reusable software component from the two perspectives, and perform a qualitative analysis of the cost of its standardization.