Toward an engineering discipline of software reuse

Re se a rche r’s CORNER Th i s a r t i c l e st e m s f ro m p a r t i c i p a t i o n i n a p a n e l se ssi o n a t t h e 1 9 9 7 Sy m p o si u m o n So f t w a re Re u sa b i l i t y, a n d d i sc u sse s o p e n re se a r c h i ssu e s, c l a ssi f i e d b y g o a l a n d b y a p p ro a c h . T owar d an E ngineer ing Dis cipl ine of Sof t war e Reuse ALI M ILI AND SHERIF YACOUB, INSTITUTE FOR SOFTWARE RESEARCH EDWARD ADDY, NASA SOFTWARE INDEPENDENT VERIFICATION AND VALIDATION FACILITY HAFEDH M ILI, UNIVERSITY OF QUEBEC S oft ware developm ent cannot possibly becom e an engineering discipline1 so long as it has not perfected a technology for developing product s from reusable asset s in a rout ine m anner, on an indust rial scale. Soft ware reuse cannot, in turn, achieve this status unless we make the following provisions: a sound scientific foundation that encompasses relevant design principles, widely acceptable engineering standards that compile these principles into working practical solutions, and coherent managerial standards that enable the deployment of these solutions under acceptable conditions of product qualit y and process maturit y. Although successful soft ware reuse experiments are increasingly common,2 success is not the norm, soft ware reuse is not a matter of routine practice, the promises of soft ware reuse remain for the most part unfulfilled, and a number of issues remain worthy of further research. The very idea that soft ware reuse is a legitimate research discipline is a paradox: in all other engineering disciplines, reuse is an integral part of good engineering design Ñso integral that it is not even noteworthy. This paradox raises t wo issues: 22 I EEE So f t w a r e Se p t e m b e r / O c t o b e r 1 9 9 9 0 7 4 0 - 7 4 5 9 / 9 9 / $ 1 0 . 0 0 © 1 9 9 9 I EEE Re se a rche r’s CORNER ♦ Why is soft ware reuse an issue and not, for example, hardware reuse? A question as broad as this can elicit a w ide range of responses. Perhaps t he common denominator of all possible answers is that soft ware assets are t ypically very information-rich; hence, it is difficult to characterize t hem , m atch them, and capture their relevant properties. ♦ How is soft ware reuse different from soft ware design? Good soft ware design advocates designing soft ware from reusable assets and producing software systems with the perspective that they might be reused. Soft ware reuse deals w it h producing reusable assets (domain engineering) and exploiting reusable assets (application engineering), so as to make good soft ware design a rout ine pract ice. Also, because there are quantifiable costs associated w it h t he integrat ion of reuse concerns, these costs have to be weighed against reuse benefit s. Soft ware reuse deals w it h the trade-offs involved in such cost–benefit decisions. These decisions influence bot h t he design process and the qualit y of the produced soft ware design. This article presents some of the research issues that we feel are relevant today. The list is neither exhaustive nor perfectly orthogonal, and necessarily reflects our biases. We discuss, in turn, technical aspects and then managerial aspects that we feel are worthy of research attention. practical research to provide profound insights. ♦ Em pirical m ethods are no excuse for dispensing with analytical methods. We can use empirical methods to validate a careful analysis of the phenomena of interest, but cannot use them as a substitute. For example, if we have determined by analytical means that soft ware costs have the form C = A × SB, where S is a m easure of product size and C a m easure of cost, then we can use empirical means to derive A and B, but we cannot use empirical means to determine whether the cost has the form C = A × SB or the form C = A × S + B. ♦ Scient ific research ult im ately affect s and enhances pract ice. Research on st ruct ured program - It is not always realistic to expect theoretical research to be readily applicable, or practical research to provide profound insights. Pr emis es of a S cient ifi c Appr oach As background, to provide a rationale for w hat could be considered worthy of research attention, we present our premises about the role of scientific research in an engineering domain such as soft ware reuse. Without meaning to get entangled in the endless debate of theory versus practice or science versus engineering, we take the following positions regarding the need for sound technical standards: ♦ Concern for practice is no excuse for poor theory. Good pract ice stem s from good t heory. While theoretical research focuses on understanding and modeling, practical research focuses on converting t he insight s gained from t he m odeling t ask into practical, effective solutions. It is not always realist ic to expect t heoret ical research to be readily applicable; it is equally unreasonable to expect m ing during the 1970s and 1980s centered on the simple yet crucial premise that programs are mathem at ical object s, w hich can be t he subject of formal, precise mathematical reasoning. This research produced a large b ody of know ledge ab out program specifications, verification, construction, and language sem ant ics. Alt hough t here is som e deb ate ab out t he d irect im p act of t his b ody of know led ge on t he d ay-to-d ay p ract ice of p rogram m ing, it undoubtedly has had a profound influence on m any aspects of the program m ing discipline, such as t he way we design and evaluate p rogram m ing languages and tools, t he w ay w e define programming-language semantics, the way we underst and and teach program m ing, t he way we sp ecify and verify p rogram s, and, ult im ately, t he way we pract ice program m ing. Hence, scientific research ultimately enhances practice through subt le but last ing influences. ♦ Scaling up is not always realistic. Because of its em phasis on underst anding, t heoret ical research often uses small-scale examples to focus on the phenomena at hand rather than the idiosyncrasies and complexities of large examples. If we think we can apply our experience with small examples to large ones, we face disappoint m ent if com plexit y im pedes scaling up. An alternative interpretation is that we practice on small examples in order not to tackle large examples; although this might sound farcical, there is solid rationale to it, in conjunction with the next premise. Se p t e m b e r / O c t o b e r 1 9 9 9 I EEE So f t w a r e 23 Re se a rche r’s CORNER ♦ Sim plicit y as a pervasive research goal . We view the goal of scientific research as the relentless discovery of simple models behind seemingly complex observations. A model might be complex for a number of reasons: the phenomenon it is trying to capture is intrinsically complex; the phenomenon is sim ple but we have not yet discovered it s sim plicit y; or t he phenom enon is sim ple but t he approach we are using precludes us from discovering its simplicit y. We can legitimately dismiss a research initiative as being too complex if we can establish that the complexit y stems from the third case— but not if the complexit y stems from the first or second case. In light of these premises, we feel there are a number of issues pertaining to soft ware reuse where current understanding is incomplete and can benefit from further insights. We discuss in some detail the topics where we have ideas, and mention those to which we have little meaningful to contribute. Domain E ngineer ing Is s ues There is increasing recognition in the soft ware reuse communit y that domain engineering is a crucial aspect of soft ware reuse, and for good reason: reuse w ill not happen unless reusable asset s are available, and good dom ain engineering is at the center of this requirement. of their structure and uses them on the basis of their advertised function. ♦ Asset s t hat abst ract a st ruct ure. What m akes these assets worthwhile is the structure they have, and the problem-solving experience that this structure embodies. Archet ypical examples of such assets include programming clichés, design patterns, and requirements clichés. This dichotom y has a profound im pact on t he following four aspects of soft ware reuse; along with each aspect, we discuss outstanding issues that we feel require more research attention. ♦ How assets are represented . An asset that embodies a function should be represented by a function that abstracts its most relevant functional (semantic) properties, whereas an asset that embodies a structure should be represented in a way that highlights its relevant structural (syntactic) properties. Current research on reusable assets does not properly acknowledge this distinction and its impact. ♦ How asset s are m atched . An asset t hat em bodies a funct ion is m atched against a query by testing its functional properties against the functional requirements of the query, using some form of subsum ption or equivalence relation. Matching an asset that em bodies a structure is totally different, in term s of how we represent t he query and how we analyze t he asset to determ ine it s relevance w ith respect to the query. Research on representing queries and assessing relevance must acknow ledge t his dichotom y and recognize its im pact. ♦ How asset s are developed . Design for black-box reuse is primarily a specification issue and is determined by the generalit y of the asset’s specification and the genericit y of its implementation. Design for whitebox reuse, on t he ot her hand, is prim arily determ ined by such design issues as m odularit y, sim plicit y, and structuredness. We would expect design life cycles for reuse to depend a great deal on which reuse policy the asset is designed for (black box or white box)Ñyet current research trends do not make the distinction. ♦ How assets are (re)used . By definit ion, asset s t hat em body a funct ion m ight only be used for black-box reuse, where the user has no cognizance of the asset’s internal structure. Assets that embody a structure may or may not have a function associated w ith them ; t ypically, they are geared toward white-box reuse. Packaging mismatch is the main obstacle to the seamless integration of reusable components. Essence of a reusable asset: structure versus function Victor Basili, G. Caldiera, and H.D. Rombach define a reusable asset as the em bodim ent of som e soft ware development experience.3 This definition encompasses a wide range of assets, but if we focus on those stemming from programming or program design experience, we find t wo categories of software assets: ♦ Asset s t hat abst ract a funct ion . What gives these assets their worth is the function they compute and the service that this function renders in host systems. Archet ypical examples of such assets are mathematical routines (in Fortran, for example) and abstract data t ype implementations (in Ada, for instance). The user of such assets has no cognizance 24 I EEE So f t w a r e Se p t e m b e r / O c t o b e r 1 9 9 9 Re se a rche r’s CORNER Packaging a reusable asset: form versus function We can capture the semantics of a soft ware asset through t wo distinct, nearly orthogonal aspects: its funct ion and it s packaging. While t he form er describes the mapping that it defines bet ween inputs and outputs, the latter describes the protocols that define how the asset receives inputs and delivers outputs. Packaging mismatch is the main obstacle to t he seam less integrat ion of reusable components.4 This matter would benefit from more research, and we advocate adopting a semantics approach (considering it an issue of semantic definition and seeking semantics-based methods to address it), in addition to the more common linguist ic approach (considering it an issue of program m ing language and seeking program m inglanguage constructs to address it). We expect that the impact of a formal semantics approach to packaging will be the same as the impact of formal sem ant ics approaches to capt uring t he funct ion of soft ware assets: It will foster crisper, more streamlined language constructs and a more disciplined use of existing constructs. specialized developm ent of soft ware asset s t hat cover the range of needs of the market; its rationale is to be a one-stop shop for the selected market segm ent. This criterion is consum er-focused and reflects the viewpoint of a (marketing) manager. Of course, these criteria are not mutually exclusive: an ideal domain satisfies all three criteria; a poor dom ain sat isfies none. Dom ain engineering processes are dependent on the way in which the An economy-of-scale rationale justifies why and quantifies to what extent a domain is worthy of a domain engineering effort. Characterizing a domain The first and most crucial step in a domain engineering initiative is to delimit the domain of interest by defining t he set of asset s t hat it com prises. Inherent in any domain definition is an economyof-scale rationale, which justifies why and quantifies to what extent this domain is worthy of a dom ain engineering effort. We can t hink of at least three criteria to delimit a domain for the purposes of a domain engineering initiative, each characterized by a distinct economy-of-scale rationale: ♦ Com m on expertise. This criterion identifies a field of dom ain expertise and caters to it through specialized developm ent of soft ware asset s t hat span the range of applications of the expertise at hand. This criterion is producer-focused and reflects the viewpoint of a domain expert. ♦ Common design .This criterion identifies a problem-solving pattern that is embodied in some generic soft ware assets and caters to it through the development of generic assets that can be specialized for specific needs. This criterion is product-focused and reflects the viewpoint of a programming expert. ♦ Common market . This criterion identifies a segment of the soft ware market and caters to it through domain is defined and delimited—yet this is not traditionally acknowledged. It is helpful to analyze domain engineering processes and their relation to the classification just proposed. It is also useful to quantify the economy-of-scale rationale for the domain, w hich m ight lead, in turn, to cohesion m etrics for domains. Software product lines Perhaps the m ost dom inant form of system atic soft ware reuse today is in soft ware product -line development. This t ype of reuse is often generated by a dom ain delim ited using a com m on-m arket approach to dom ain engineering, and is a natural form of reuse within a single organization. The core of the soft ware product line is the generic (or product-line) architecture. All of the issues related to research in system -sp ecific soft ware architect ures apply also to product -line architect ures; in addition, product-line architectures m ust address the issues of expressing com m onalit y and variabilit y. Some of the open technical questions dealing with soft ware product lines and architect ures include the follow ing: ♦ languages for architecture description, ♦ m et hods for evaluat ing soft ware architectures, ♦ m et hods to evolve a soft ware architect ure without degrading its integrit y, ♦ integrat ion of soft ware architect ures w it h hardware and system-level architectures, ♦ m ethods to m anage the com plexit y of configurat ion m anagem ent on m ult iple versions of components and systems, and ♦ methods to effectively and efficiently test system upgrades with new or different components or with a modified generic architecture. Se p t e m b e r / O c t o b e r 1 9 9 9 I EEE So f t w a r e 25 Re se a rche r’s CORNER FURTHER READI NG T. Biggerst aff and C. Richter, “Reusabilit y Fram ework, Assessm ent, and Direct ions,” IEEE Soft ware, Mar. 1987, pp. 41–49. General recom - mendations for soft ware reuse research, focusing primarily on practical goals. C.W. Krueger, “Soft ware Reuse,” ACM Com put ing Surveys, Vol. 24, No. 2, June 1992, pp. 131–183. An exhaust ive soft ware reuse survey, concluding with a presentation of outstanding research issues. We discuss some of these in this article, suggesting that they remain open issues. H. Mili, F. Mili, and A. Mili, “Reusing Soft ware: Issues and Research Direct ions,” IEEE Trans. Soft ware Eng., Vol. 21, No. 6, June 1995, pp. 528–562. Survey of the state of the art and state of the practice in soft ware reuse, including a discussion of som e research issues dealing m ost ly with technical aspects. R.L. Glass, “Reuse: What ’s Wrong w it h This Picture,” IEEE Soft ware, Mar./ Apr. 1998, pp. 57–59. Presenting the thesis that soft ware reuse has intrinsic limitations that are inherent in the nature of soft ware, hence are not dependent on the state of the art in soft ware reuse. Appl icat ion E ngineer ing Is s ues For a long time, mostly during the 1970s and 1980s,most researchers believed that if only we could learn to build correct programs from specifications, all the problems of soft ware engineering would be solved. The realization that there is more to soft ware engineering than writing correct code came gradually, with the observation that soft ware engineering is a multidisciplinary field and that the most crucial bottlenecks come from organizational and managerial aspects rather than technical aspects. Subsequently (in the early to mid 1980s),many researchers neglected the disciplines of program verification and structured programming and flocked in large numbers to the then-greener pastures of knowledgebased systems, expert systems, and fifth-generation systems. In the meantime, the so-called practicing programmers kept writing C code, and years of neglect did not enhance their understanding of program specification, design, and verification. 26 I EEE So f t w a r e Se p t e m b e r / O c t o b e r 1 9 9 9 Recently, program specification and verification have attracted renewed interest, although they now go by a different set of nam es: program understanding, verification and validation, formal methods, and so on. With hindsight, we feel that the problem with program-verification research was not the research itself but rather the unreasonable expectations placed on it. The same thing is happening today in soft ware component storage and retrieval: after spending several years focusing on this topic as though it was the key to all reuse problems (in a recent literature survey5 we counted about 50 proposed solutions), soft ware researchers have been outdoing themselves lately trying to disclaim this field as vehemently as they can. We feel that rumors regarding the death of this area of research are, if not prem at ure, at least grossly exaggerated. Although we agree that soft ware component storage and retrieval is no longer an important issue in the practice of soft ware reuse, some of the problems it raises are interesting in their own right, and their explorat ion is a wort hw hile research goal in t he sense that it enhances our understanding of relevant products and processes. Among the many outstanding issues that we recognize in soft ware component storage and retrieval is the distinction bet ween retrieval and brow sing. There are t wo ways to use the assets in a soft ware component library: ♦ Retrieval: A user submits a well-defined query to a soft ware library and expects the system to identify all the library assets that satisfy the query (recall) and exclude irrelevant assets (precision). The query t ypically refers to the expected functional properties of candidate assets, or sometimes to structural properties, and it might also include requirements about perform ance criteria. Ret rieval is t ypically deployed in conjunction w ith top-dow n soft ware design. ♦ Brow sing: The user has no predefined concept of desirable functional properties but selects assets on t he basis of general relevance guidelines t hat m ight deal w it h applicat ion dom ain, com put ing platform, structural features, problem-solving knowledge, or ot her criteria. Brow sing is t ypically deployed in conjunct ion w it h bot tom -up soft ware design. There is ample evidence to the effect that brow sing is t he m ost predom inant pat tern of library usage, if only because soft ware reuse is consistent with bottom-up soft ware design; this is ironic because most of the past research dealt with retrieval Re se a rche r’s CORNER rather than browsing.5 Indeed, retrieval assumes that a user has clearly defined requirements stemming from a previously formulated design and is seeking assets that satisfy these requirements. It is far more t ypical for users to brow se through a library to get acquainted with available assets, then formulate a design in such a way as to take the best advantage possible of the existing assets. The distinction bet ween retrieval and brow sing m ust be further explored, w it h an em phasis on gaining a better understanding of brow sing. For exam ple, is brow sing an instance of retrieval where the selection criterion is nonfunctional? Is it a form of retrieval where the emphasis is on recall rather than precision? Is it a form of retrieval where the emphasis is on application domain rather than functionalit y? Do we apply retrieval when we are familiar with a library and brow sing when we are not? and so on) are fairly well-understood, we must pay more attention to turning this understanding into rout ine engineering pract ice. The nat ure of COTS components requires black-box testing to be the primary means of verifying that a COTS component is reliable and fit s t he architect ure of t he system or product line. This black-box test ing should be driven by the functionalit y of the COTS component (to verify that all functions work appropriately), the Most decisions that arise in soft ware reuse can and must be justified by some economic rationale. Component-based software Com ponent-based soft ware developm ent has recent ly been touted as a technology facilit ator. CBSD is enabled by the m aturit y of developm ent environments and programming languages (such as Visual Basic, C++, and JavaBeans) that support both the developm ent of the com ponents them selves and the development of applications using components.6 The following features characterize CBSD in contrast with traditional (custom) soft ware development: ♦ The CBSD process is an interface-centered process in w hich com ponent interfaces play t he major role in plugging components together. ♦ The developm ent process is a com posit ion mechanism in which one assembles an application from components. ♦ An application developed from components relies heavily on t he separat ion of concerns and functionalities of the individual components. This is required to decrease t he interdependency bet ween com ponent s and hence im prove system maintainabilit y and reliabilit y. ♦ When an application uses commercial off-theshelf components, it is much more dependent on the vendor, his support, and his upgrade schedule. COTS-based system development While many of the issues that arise during COTS integration (specification of components, verificat ion and validat ion, com posit ion of com ponent s, system’s operational profile, and system-level fault injection.7 Should protective wrappers be used on COTS products to m inim ize the probabilit y of adverse interaction? What risks are alleviated by using COTS product s (such as cost and reliabilit y), and what risks are amplified (such as future compatibilit y and reliabilit y evaluation)? What are the differences bet ween using COTS product s in real-t im e and em bedded system s from t heir use in ot her t ypes of systems? What complexit y is added to the system through the use of multiple COTS products, and does this complexit y increase the risk of errors as the system evolves? Manager ial Is s ues Although we recognize the importance of organizat ional provisions and t he pragm at ic value of human-resource management, we limit our discussion here to the economic aspects of soft ware reuse. Economic considerations are an important aspect of a soft ware reuse policy, as m ost decisions t hat arise in soft ware reuse can and must be justified by som e econom ic rationale. Also, cost is an integral part of any engineering discipline: the essence of a com petent engineer is not so m uch to be able to design a product as being able to do so economicallyhence, economic considerations are inseparable from good engineering. Return-on-investment models for software reuse Many decisions in the practice of soft ware reuse can be rationalized as investment decisions. At the corporate level, corporate m anagem ent com m its resources to initiate a reuse program and expects to Se p t e m b e r / O c t o b e r 1 9 9 9 I EEE So f t w a r e 27 Re se a rche r’s CORNER want to derive: net present value, payback value, average return on Investment costs Reuse infrastructure book value, internal rate of return, and profit abilit y index. Ot her Periodic costs funct ions include ret urn on inDomain engineering cycle vestment, break-even values, proInvestment costs Domain analysis costs ductivit y gains, and qualit y gains. Periodic costs ♦ Cost factors. For a given inComponent engineering cycle vestm ent cycle and a given ecoInvestment costs Periodic costs Periodic benefits nom ic funct ion, t he set of cost Development for reuse Library overhead Sale of asset factors that are taken into account Periodic benefits in a cost m odel is t he m ost im Catering to projects port ant feat ure of t he m odel: it specifies what aspects of the reuse Periodic benefits decision we want to integrate. Application engineering cycle ♦ Reuse organization. Several Investment costs Periodic costs Periodic benefits organizational models are possible Training Reuse overhead Productivity gains Process impact Reuse risks Q uality gains in soft ware reuse;9 the organizational structure has some impact on how costs are determined, charged, and accounted for. F igur e 1. Software reuse cost models. ♦ Hypotheses. Some cost models neglect integrat ion cost s and assume that the cost of building an aggregate reap benefit s in term s of bet ter product qualit y, of t wo com p onent s is t he sum of building each. higher productivit y, and shorter time to market. At Some cost models assume that soft ware developthe (reuse) department level, a manager might comm ent cost s are linear in t he size of t he product. mit resources to initiate a domain engineering iniOthers fail to take into account the discount rate of tiative, expecting to reap benefits by selling (be it resources, w hile st ill ot hers ignore qualit y gains internally) reusable assets to project teams. Project (b ecause t hey are unable to integrate t hem into team s also com m it resources and take risks w hen t heir equat ion) and focus on product ivit y gains. they adopt a reuse discipline; they expect to reap Vir t ually all cost m od els ignore t he inflat ion of benefits in terms of productivit y, qualit y, and timecode size t hat stem s from soft ware reuse, w hen in liness of project completion. Component developfact reusable code tends to be larger than code deers com m it resources to develop a reusable asset velop ed for a sp ecific single use (due to requireand expect to reap benefits by selling the asset to m ent s of generalit y). project teams. In the following discussion, we anaThis variet y of attributes accounts for the abunlyze soft ware reuse investment cycles and highlight dance of econom ic m odels and show s, paradoxitheir interrelationships. cally, that there too few modelsnot too many. The There has been a great deal of research on the solution is not, of course, to invent more models to econom ics of soft ware reuse.8 Interest ingly, even fill the gaps we have identified but rather to investhough these cost models appear to deal with the tigate generic models that can be specialized along same problem, they in fact differ significantly from the dimensions just discussed. This topic is worthy each other. Some of the features that distinguish beof further investigation along the framework illust ween these cost models include the following: trated in Figure 1; it is easy to see in the figure how ♦ Invest m ent cycle. Most soft ware reuse decithe various models feed into each other. For examsions can be modeled as return-on-investment deple, a corporate manager can assess the impact of cisions. We have identified four distinct investment a reuse initiative by taking into consideration the cycles, as shown in Figure 1. Each one is subject to a cost of the reuse infrastructure as well as domain endifferent economic rationale and can be quantified gineering costs (accumulated across different doby means of a ROI model. mains) and can balance these costs against the ben♦ Economic function. John Favaro 8 identifies five efit s reaped from qualit y and product ivit y gains different functions that an economic model might Corporate cycle 28 I EEE So f t w a r e Se p t e m b e r / O c t o b e r 1 9 9 9 Re se a rche r’s achieved in application engineering. Also, a domain manager can assess the impact of a domain engineering effort by considering the cost of producing reusable asset s against t he benefit s reaped from “selling” (so to speak) these assets to project managers. Appropriate incent ive and reward m echanisms must be put in place to give a concrete meaning to t he concept of selling asset s w it hin a corporate organization. The figure also show s the terms that govern component engineering investments and application engineering investments. This figure can serve as a fram ework for classifying and analyzing cost m odels; perhaps we can also use it to perform domain modeling on soft ware reuse cost estimation. G enerality CORNER G enericity Ada Pascal Immediacy F igur e 2. Generality versus immediacy. Cost models for software reuse life cycles The ROI models discussed earlier are of no use unless we have means to quantify the costs involved. The derivat ion of t he ROI m odels is an analyt ical step, w hereas t heir quant ificat ion is an em pirical step. The follow ing t wo aspects of soft ware reuse costs are worthy of research attention: ♦ Estimating the cost of domain engineering. This includes the dom ain-analysis phase, in w hich domain experts and analysts investigate a particular domain to identify a domain-wide system architecture along with commonalities and variabilities bet ween applicat ions of t his dom ain. However, we must also analyze the costs associated with all the act ivit ies t hat precede asset developm ent. While there are some general estimates of this cost, no accurate models exist. ♦ Estimating the cost of developing for reuse. Once domain analysis is complete, individual assets are specified and developed according to t radit ional development life cycles. Current models do provide for est im at ing t he cost s of asset developm ent (w hich begin as soon as an asset ’s requirem ent s specifications are pinned down): Cocomo 2.010 offers estimates of these costs by means of the RUSE factor, and Jeff Poulin 11 sum m arizes current est im ates of t he RCWR (Relat ive Cost for Writ ing for Reuse). Both RUSE and RCWR are derived from empirical observations that show a worrisome lack of convergence, suggest ing perhaps t hat m ore research is needed in this area. Empirical research is needed to provide better estim ation procedures for these costs. We advocate the deployment of three t ypes of empirical research: controlled experiments, case studies, and analysis of production metrics. A basis for measuring reusability It is important to be able to assess the reusabilit y of a soft ware asset by means of quantitative metrics. Such metrics provide a rationale for deciding when to consider an asset reusable. Populating a library with unusable assets can hurt the library’s perform ance: w hen it is not ret rieved, a nonreusable asset will nevertheless affect the efficiency of the retrieval procedure because one more candidate asset has to be considered. When it is retrieved but subsequently ruled out, a nonreusable asset affects the user’s productivit y because of the wasted effort required to analyze the asset. When a user retrieves and reuses a nonreusable asset, it s poor qualit y hurt s t he system in w hich it is integrated. Hence, measuring asset reusabilit y and enforcing reusabilit y standards have a significant economic rationale. Soft ware asset s have t wo qualit ies t hat enhance reusabilit y and thus, if quantified, can serve as a basis for defining a measure of reusabilit y: ♦ Generalit y enhances reusabilit y by making the asset more widely applicable. ♦ Genericit y enhances reusabilit y by reducing the cost of adapting the asset to its host system. When we design an executable asset for reuse, we m ust st rike a com prom ise bet ween t wo conflicting requirements: generalit y, which provides for making the asset as widely applicable as possible; and immediacy, which advocates building specific assets that can be used w ith little or no instantiation effort. For a given programming notation, these requirements are contravariant (that is, each is satisfied at the expense of the other), as shown (very abstractly) in Figure 2. The role of genericit y (as a feature of programming languages) is precisely to Se p t e m b e r / O c t o b e r 1 9 9 9 I EEE So f t w a r e 29 Re se a rche r’s CORNER T abl e 1 Our R ecommendat ions f or R eus e R es ear ch Approach Theoretical Goal Practical Goal Analytical Function vs. structure COTS integration Form vs. function Measuring reusabilit y Empirical ROI design Domain characterization Soft ware product lines Retrieval vs. brow sing Component-based soft ware COTS integration ROI validation Soft ware reuse cost estimation push the curve away from the center. This figure also show s, very schematically, how these lines could be draw n for t wo languages w it h different levels of genericit y. We feel that the interrelationships bet ween generalit y, genericit y, and immediacy ought to be further explored, and possibly quantified; this might lead to better guidelines on how to strike the compromises that arise in design for reuse, in addition to serving as a basis for reusabilit y assessment. T able 1 sum m arizes our recom m endat ions by classifying them according to research goal and suggested research approach; it also distinguishes technical and managerial issues. The goal of theoretical research is to enhance understanding, whereas t he goal of pract ical research is to use understanding to enhance practice. In terms of research approach, analytical research proceeds by analyzing processes of interest, whereas empirical research proceeds by recording observations and deriving pertinent empirical law s. Such law s may be derived without a complete understanding of the processes at hand. The list of topics here is not exhaustive; it reflects our biases as well as our specific understanding of t he soft ware reuse field. The boxed text “Furt her Reading” on page 26 point s to som e alternat ive opinions in the reuse communit y. ❖ ACKNOWL EDGMENTS We thank Steven Atkinson of West Virginia University for reviewing this article and providing feedback. Ali Mili thanks Mansour Zand for involving him in the report of the SSR ’97 panel session. Finally, w e are grateful to the review ers for their constructive feedback and insights. 30 I EEE So f t w a r e Se p t e m b e r / O c t o b e r 1 9 9 9 REFERENCES 1. S. McConnell, “The Art, Science, and Engineering of Software Development,” IEEE Software, Jan./ Feb. 1998, pp. 120, 118–119. 2. S. Isoda, “Experiences of a Soft ware Reuse Project,” J. System s and Software, Vol. 30, No. 3, Sept. 1995, pp. 171–186. 3. V.R. Basili, G. Caldiera, and H.D. Rombach, “The Experience Factory,” Encyclopaedia of Software Eng., John Wiley & Sons, New York, 1994. 4. R. DeLine, “Techniques to Resolve Packaging Mismatch,” Proc. Sym p. Software Reusability, ACM Press, New York, 1999, pp. 44–53. 5. A. Mili, R. Mili, and R. Mittermeir, “A Survey of Software Reuse Libraries,” Annals Software Eng., Vol. 5, 1998, pp. 349–414. 6. W. Brown and K. Wallnau, “The Current State of CBSE,” IEEE Software, Oct./ Nov. 1998, pp. 37–46. 7. E.A. Addy and M. Sitaraman, “Bridging the Gap between COTS Product Reuse and Formal Methods: A Case Study,” Proc. Sym p. Software Reusability, ACM Press, New York, 1999, pp. 83–91. 8. J. Favaro, “A Comparison of Approaches to Reuse Investment Analysis,” Proc. Fourth Int’l Conf. Software Reuse, IEEE Computer Soc. Press, Los Alamitos, Calif., 1996, pp. 136–145. 9. B. Coulange, Software Reuse, Springer-Verlag, London, 1998. 10. B.W. Boehm et al., “Cost Models for Future Software Lifecycle Processes: COCOMO 2.0,” Annals Software Eng., Vol. 1, Sept. 1995, pp. 57–94. 11. J. Poulin, Measuring Software Reuse: Principles, Practices and Econom ic Models, Addison Wesley Longman, Reading, Mass., 1997. About the Authors Ali Mili is a professor of computer science at West Virginia University, a senior scientist at the Institute for Software Research, and a site director of the NSFsupported Software Engineering Research Center. He holds a PhD in computer science from the University of Illinois at Urbana Champaign and a Doctoratès-Sciences d’Etat from the Université Joseph Fourier de Grenoble. Mili was program cochair of the 1999 Symposium on Software Reusability. He is a member of the IEEE Computer Society and the ACM. Contact him at amili@ softwareresearch.org. Sherif Yacoub is a PhD candidate in computer engineering at West Virginia University and a research assistant at the Institute for Software Research. His research focuses on design patterns, software reuse, software architecture, objectoriented analysis and design, and design quality. Sherif received an MSc in electrical engineering and a BSc in computer engineering from Cairo University, Egypt, where he also lectured in software engineering. Contact him at syacoub@softwareresearch.org. Edward Addy is a research associate and PhD candidate in computer science and electrical engineering at West Virginia University, where he is a member of the NASA/ WVU Software Research Laboratory at the NASA Software Independent Verification and Validation Facility. His research interests include verification and validation, software reuse, software safety, and software risk assessment. Addy has a BS in mathematics (education) from Michigan State University and an MA in mathematics from Wake Forest University. He is a member of the IEEE Computer Society and the ACM. Contact him at eaddy@ csee.wvu.edu. Hafedh Mili is an associate professor of computer science at the University of Québec at Montreal. His areas of interest include software reuse, object-oriented software engineering, information retrieval, and knowledge representation. He holds an engineering degree from École Centrale de Paris and a PhD in computer science from George Washington University. Mili has participated in a number of industry-university projects on software reuse. Contact him at mili@info.uqam.ca. The authors can be reached in care of Sherif Yacoub at the Inst. for Software Research, 1000 Technology Dr., Fairmont, WV 26554; syacoub@ softwareresearch.org.