Balancing the Need for Large Corporate and Small Domain-Specific Reuse Libraries Jeffrey S. Poulin IBM Federal Systems Company 1.0 Abstract This paper presents IBM's experiences with a corporate Reusable Software ___________________________________________________________________________ Library (RSL) and summarizes the results of a corporate-wide incentive _____________________________________________________________________________ program to develop reusable software for the RSL. The paper then explains _____________________________________________________________________________ why many different organizations can use some software but not all software. _____________________________________________________________________________ In short, successful reuse programs depend on locally administered domain- _____________________________________________________________________________ specific collections of software, not large libraries intended to meet the _____________________________________________________________________________ needs of everyone. The paper concludes that a company must organize for _____________________________________________________________________________ reuse so as to make the most of local domain knowledge and expertise. This _____________________________________________________________________________ approach relies on locally administered parts centers, where individual _____________________________________________________________________________ organizations and sites can best address their needs.(1) ________________________________________________________ KEYWORDS: Software Reuse, Incentives, Domain-specific reuse 2.0 Overview High levels of reuse in any organization depend on a source of reliable and applicable reusable software. The diversity of a business in a large company complicates providing this source of reusable assets. IBM's many activities involve numerous different programming languages, different programming tools, and different areas of application. Every organization, and in many cases individual sites and projects, has dramatically different requirements for reusable parts. These many requirements come from the wide range of problem areas, or domains, in which each organization operates. Unfortunately, this diversity --------------- (1) Proceedings of the Reusability Track of the 1994 ACM Symposium ___ __________________ on Applied Computing (SAC'94) Phoenix, Arizona, 6-8 March 1994, _________________________________ pp. 88-93. __________ limits the type and quantity of reusable assets that apply to more than one problem domain. This, in turn, limits the software that organizations can share or reuse. Experience shows that almost all reuse between organizations comes from a select collection of domain-independent software but the majority of total reuse comes from domain-specific libraries created by the experts in their area. This paper presents IBM's experiences with a corporate RSL and explains why some collections of software find uses in many organizations where other col- lections do not. The paper then summarizes our experiences with a corporate- wide incentive program to develop reusable software for the RSL. The paper concludes that reuse organizations must make the most of domain knowledge and expertise. This approach relies on locally administered parts centers where individual organizations and sites can best address their needs. 3.0 Large Reuse Library Considerations Over the past 10 years, many organizations based their reuse programs on a centrally managed reuse library. However, although the library metaphor has guided early work in classification, storage systems, and other areas of reuse technology, it does not provide the best focus for setting up and running a reuse program. While library-based reuse has worked with stable, well understood, low-level application areas, it simply has not yielded a major change in the way most people develop software [6], [12]. Although the theory behind creating a central software repository seems good, in practice, large RSLs suffer from a number of drawbacks that reduce their effectiveness. For example, RSLs normally contain few or no parts when they start out, making it hardly worthwhile to search them. The organization literally has a "library without books," and has difficulty convincing devel- opers to even look in the library. An initial reaction to this dilemma calls for loading the RSL with whatever software the organization finds at hand. The organization might launch reusable parts "mining" expeditions, and might offer incentive programs [8] to individuals depositing parts into the library. Libraries can fill quickly when an organization focuses exclusively on increasing the number of parts, but as the organization soon learns, developers will still not use the library because they know that it mostly contains software of questionable quality and heritage. An alternative to indiscriminately filling the library lies in coupling the hunt for parts with requirements to comply with reuse quality or certif- ication criteria [9]. While this improves the quality and consistency of the parts in the library, it does not guarantee that anyone other than the ori- ginal developer can use the part. The library may now contain well-tested, well-documented, and possibly supported software, but the organization soon realizes that developers do not use the library because they cannot find software that meets their needs. In summary, the contents of a large corpo- _____ rate reuse library tends to follow the progression: 1. very few parts, 2. many parts of low or poor quality, 3. many parts of little or no use. A further problem with large libraries lies in having to deal with the overhead associated with the formality and rigor needed to manage large quan- tities of data. For example, large RSLs often use an extensive classifica- tion mechanism to describe software components [7]. This mechanism provides detailed information upon which a user can search for and assess the useful- ness of reusable parts. However, the up-front presentation of large amounts of this information makes it difficult to quickly extract the relevant reuse information from the plethora of other data [18]. Unfortunately, using an extensive classification scheme also requires the user to have a working knowledge of the issues and techniques surrounding software classification [19], and to especially have an understanding of the scheme implemented by the user's RSL [22]. 4.0 Filling the Corporate Reuse Library When the IBM Reuse Technology Support Center (RTSC) formed in early 1991, it faced a corporate RSL in the first of the above three phases; in short, it needed more parts. Although some portions of the company made heavy use of the library, user feedback indicated a need for a wider selection of quality and useful software. To meet these needs, the RTSC obtained corporate funding to sponsor the development of reusable software. 4.1 A corporate incentive program From our experiences in the IBM reuse program we recognized the quality issues surrounding the blind acceptance of parts into the RSL. We also wanted to ensure that the parts we sponsored would enjoy a wide area of application. Finally, because of the modest amount of funding (less than one million dollars), we needed to find a way to gain the greatest possible lev- erage in terms of delivered products. We launched the resulting program, called the "Parts Stimulation Program," early in 1992 to accomplish all three of these goals. The Parts Stimulation Program strategy centered on getting development organizations to realize that projects they currently had to complete would prove more valuable to themselves and to the corporation if they made portions of the software "reusable." To incent organizations to make this determination, the program funded development organizations to study their project and the business issues related to reuse [17]. To apply for the program, development organizations submitted proposals describing: o their application domain, o the expected deliverables as a result of the funding, and, o an estimate of required funding. If accepted, the program funded the "front-end" expenses of conducting the reuse study, which included: o performing a domain analysis [20], o developing specifications for the reusable parts, and, o completing a reuse business case detailing who else will benefit and the expected return on the investment. Funding the front-end expenses proved an effective way to leverage our limited amount of funding. Because the organizations would retain responsi- bility for development costs, the program did not have to fund the most expensive portion of creating the parts. Finally, if the business case showed favorable returns the organization would agree to complete the work by: o developing, testing, and deploying the parts, o completing the parts at the highest IBM reuse quality level, o loading the parts into the corporate RSL, and, o maintaining the parts. 4.2 Incentive program results Although the approach of funding reuse studies in existing projects greatly helped us expand the scope of the program, we had immediate difficulty iden- tifying candidate projects to develop software for use across the corpo- ration. Out of 25 proposals submitted, only 3 had the potential to create software that might prove useful outside its specific domain. Despite our efforts, we discovered that the incentive program would not create software for corporate-wide reuse because of the limited kinds of software with such a broad scope. +------------------------------------------------------------------+ | Table 1. Parts Stimulation Program Summary | +--------------------------------------------------+---------------+ | DELIVERABLE | NUMBER FUNDED | +--------------------------------------------------+---------------+ | Create Reuse Standards | 2 | +--------------------------------------------------+---------------+ | Develop a Common Tool | 3 | +--------------------------------------------------+---------------+ | Complete a Domain Analysis | 2 | +--------------------------------------------------+---------------+ | Create Reusable Software | 3 | +--------------------------------------------------+---------------+ | Total accepted= | 10 | +--------------------------------------------------+---------------+ Because we lacked suitable proposals to develop domain-independent soft- ware, we decided to fund alternative projects that, although did not result in software, might otherwise result in benefits to the corporation. These projects created reuse standards documents, developed tools, or studied (com- pleted a domain analysis) an area for future software development. While these projects resulted in several useful deliverables, they did not con- tribute to the corporate reuse inventory. Table 1 gives a summary of the projects funded by the Parts Stimulation program. 5.0 Understanding What Makes Software Reusable The experiences with the stimulation program forced us to focus on the fact that programmers cannot reuse a software asset unless they find it usable. ______ Programmers can only use a very small and select category of software in more than one problem area. To illustrate this, we grouped software into three categories based on range of usefulness. ___________ DOMAIN-INDEPENDENT software comprises the category of software with the widest range of usefulness. Domain-independent software provides the founda- tion for programming; e.g., abstract data types, graphical user interface functions, and math libraries. This software deals primarily with basic operating system functions or accessing prerequisite products such as data- bases. DOMAIN-DEPENDENT software comprises the second category. We see a lot of reuse from this category of software but only within the problem domain. ____________________________ OS/2 Operating System (tm)(2) device drivers, navigational aids for aircraft, and financial services libraries serve as good examples of domain-dependent software. Domain software concentrates on an area of an organization's busi- ness processes. For example, a marketing group might develop a standard set of software routines to handle the configuration of hardware and software products, and develop a family of related applications using this standard set of routines. However, this software has limited application outside of the domain of marketing. APPLICATION-SPECIFIC represents the third and final category. This cate- gory of software handles the specifics of a customer's application; it con- sists of customized code needed to deliver a product. Although opportunities exist to reuse software within an application team, this software tends to deal exclusively with how one application can implement an application-unique function. This software has very limited reuse potential, even within its _______________ own domain. To summarize: __________ --------------- (2) Registered trademark of the International Business Machines Cor- poration. +------------------------------------------------------------------+ | Table 2. The three levels of software | +----+--------------------+--------------------+-------------------+ | | CLASS | POTENTIAL | EXAMPLES | | | | FOR REUSE | | +----+--------------------+--------------------+-------------------+ | 3 | Application- | Very limited, | Custom code | | | Specific | even within domain | written for an | | | | | application. | +----+--------------------+--------------------+-------------------+ | 2 | Domain- | High, but only | Avionics soft- | | | dependent | within domain | ware, Financial | | | | | functions | +----+--------------------+--------------------+-------------------+ | 1 | Domain- | Very high, | Abstract data | | | independent | even across | types, GUI | | | | domains | libraries, Math | | | | | routines | +----+--------------------+--------------------+-------------------+ Reusable software components tend to consist of from 50 to 200 lines of source code, but we do not limit the target software to those providing only a single function or set of variables. Higher-level abstractions may include numerous interrelated functions or data that act together to perform a spe- cific task. The above model simply underscores that the state-of-the-art in the practice of software reuse lies in constructing programs from building blocks of reusable components, and that most components have a specific range _____ of use. ______ 6.0 Balancing Corporate RSLs with Domain-Specific RSLs 6.1 Parts at the corporate level A low-risk way to capitalize on reuse would make it easy to build programs using domain-independent reusable components. Corporate-level groups must concentrate on supplying this software. We has seen highly successful levels of reuse in this category, and the IBM RSL contains numerous (30+) domain- independent libraries for abstract data types (ADTs), graphical user inter- face (GUI), system functions, and operating system services. These components tend to have very high quality; in one well-used library con- sisting of about 80,000 lines of ADT routines, we have never had a single problem reported [4]. With regard to other reuse activities, the corporate group provides standards, resolves reuse issues common to sub-organizations, and provides technical consulting to developers across the sites. 6.2 Parts at the local level We recognize that corporate groups cannot have responsibility for devel- oping software for use by specific organizations or sites. The responsi- bility for developing domain-dependent libraries belongs at the local level. The sites have the people and domain experts most qualified to understand local requirements, environment and customer. Although local developers will turn to the corporate group for supporting standards, education, and con- sulting, they have the knowledge and position to create local reuse libraries where they can best meet their own requirements. 6.3 Selecting a domain We must qualify that the existence of a domain library does not guarantee it will achieve high levels of reuse on our projects. Some domains prove more conducive to high levels of reuse. The best results will come from a domain which [10]: o has limited scope, o we understand, o has matured to the point of relative stability, o requires a lot of custom development based on core functions. Creating domain libraries primarily happens in two ways; top-down and bottom-up. In the a priori, top-down approach, we form a team to study an area and develop a foundation of software before we start our main develop- ment effort. The resulting domain library continues to evolve during devel- opment, but the initial work takes place early in the project. In the bottom-up approach we examine a domain after we have worked in it for a con- siderable time and extract the common elements for our domain-specific toolkit. This work may take place informally by local experts and emerge as a de facto, local standard. 6.4 Experiences with domain libraries Although domain libraries do not necessarily lead to high levels of reuse, experience shows that high levels of reuse requires them. For example, as ________ part of the Advanced Automation System (AAS) for the Federal Aviation Agency, the IBM Rockville site experienced reuse levels of 56% through the use of their avionics domain-specific software [13]. The Mid-Hudson Valley Program- ming Lab experienced reuse levels of 43% in the Basic Control Program of the MVS operating system through the use of their system-services macros and the use of Boeblingen Building Blocks [11]. Japanese corporations report very impressive reuse achievements with domain libraries consisting of only 70-100 assets [21]. Recent feedback on the effectiveness of large corporate versus small domain libraries in other companies shows similar results [6], [15]. Furthermore, successful experiences in a wide variety of domains such as telecommuni- cations [2], avionics [3], distributed systems [5], and simulation/modeling [14], appear with regularity. 6.5 Organizing for Domain-Specific Reuse We find the best place to develop these domain libraries lies where we find the expertise. Our most successful site reuse programs recognize this and designate a group, or "parts center" to develop and maintain a domain library. Other companies have also started to take this approach [16]. Our plan to create reusable software takes advantage of the fact that developing and managing domain-dependent libraries works best as a decentral- ized activity. The "parts center" team typically consists of one to six pro- grammers; in a larger group one person acts as a team leader [1]. The team reports directly to a high-level development manager and has responsibility for collecting requirements, designing, implementing and supporting (both with maintenance and technical consulting) all software shared by the groups they support. 7.0 Conclusion Library-based reuse programs focus organizational reuse efforts on a central repository of reusable assets. Although this approach has enjoyed a lot of attention, programs that base their success on "total lines-of-code in the RSL" find that the quantity of software does not accurately reflect the range of its usefulness. Successful reuse programs tend to make heavy use of locally developed reusable information and software which addresses the spe- cific needs of their application area. Faced with a corporate RSL which we believed required an influx of reusable software, we launched a corporate-wide incentive program to encourage domain- specific projects to develop and deposit domain-independent software into the library. Although our incentive method provided a very effective way to lev- erage a modest resource, we discovered that we tried to develop software with a scope beyond what our programmers could actually use world-wide. Based on the results of this incentive program, we believe that similar programs will have limited success in creating reusable software. Our experience shows that the three-level model of software provides a useful guideline for defining responsibility for reusable parts. The corpo- rate group addresses the needs of domain-independent software and takes the lead in providing standards, resolution of common issues, and technical con- sulting. The group then assists local organizations to establish project and site parts centers for domain-specific requirements. This keeps development close to the domain experts, results in better software, and lets organiza- tions see the benefit of their own investments. 8.0 Cited References [1] Bauer, Dorothea, "A Reusable Parts Center," IBM Systems Journal, Vol. ____________________ 32, No. 4, 1993, pp. 620-624. [2] Ciardi, Mauro, Pierpaolo Marangoni, Cinzia Sternini, "SIP Library Project: A New Methodology for Designing OSI Systems Implementations," Eleventh International Conference on Computer Communication, Genoa, ________________________________________________________________ Italy, 28 Sept- 2 Oct. 1992, pp. 83-88. [3] Cohen, Sholom, "Process and Products for Software Reuse in Ada," Pro- ____ ceedings TRI Ada'90, Baltimore, MD, 3-7 December 1990, pp. 227-39. ____________________ [4] Endres, Albert, "Lessons Learned in an Industrial Software Lab," IEEE ____ Software, September, 1993, pp. 58-61. _________ [5] Gomaa, Hassan, "A Reuse-Oriented Approach for Structuring and Config- uring Distribute Applications," Software Engineering Journal, Vol. 8, ______________________________ No. 2, March 1993, pp. 61-71. [6] Griss, Martin, "Software Reuse: From Library to Factory," IBM Systems ___________ Journal, Vol. 32, No. 4, 1993, pp. 548-566. ________ [7] "IBM Reuse Methodology: Classification Standards for Reusable Compo- nents," IBM Document Number Z325-0681, 2 October 1992. ______________________________ [8] "IBM Reuse Methodology: Incentives," IBM Document Number Z325-0692, 2 ______________________________ October 1992. [9] "IBM Reuse Methodology: Qualification Standards for Reusable Components," IBM Document Number Z325-0683, 2 October 1992. ______________________________ [10] Isoda, Sadahiro, "Experience Report on Software Reuse Project: Its Structure, Activities, and Statistical Results," Proceedings of the ____________________ International Conference on Software Engineering, Melbourne, Australia, __________________________________________________ 11-15 May 1992, pp. 320-326. [11] Lenz, Manfred, Hans Albrecht Schmid, and Peter F. Wolf, "Software Reuse Through Building Blocks," IEEE Software, Vol. 4, No. 7, July 1987, pp. ______________ 34-42. [12] Lubars, Mitchell D. and Neil Iscoe, "Frameworks Versus Libraries: A Dichotomy of Reuse Strategies," Proceedings of the 6th Annual Workshop ______________________________________ on Software Reuse, 2-4 November 1993, Owego, NY. __________________ [13] Margano, Johan, and Lynn Lindsey, "Software Reuse in the Air Traffic Control Advanced Automation System," paper for the Joint Symposia and __________________ Workshops: Improving the Software Process and Competitive Position, 29 ____________________________________________________________________ April-3 May 1991, Alexandria, VA. [14] Miller, Lawrence and Alex Quilici, "A Knowledge-Based Approach to Encouraging Reuse of Simulation and Modeling Programs," Proceedings of _______________ the 4th International Conference on Software Engineering and Knowledge ________________________________________________________________________ Engineering, Capri, Italy, 15-20 June 1992, pp. 158-163. ____________ [15] Neumann, Valerie A. "Moving Beyond Library-based Reuse," 6th Annual __________ Workshop on Software Reuse, Owego, NY, 2-4 November 1993. ___________________________ [16] Ning, Jim Q., "Module Interface Specification and Large-Grain Software Reuse," 6th Annual Workshop on Software Reuse, Owego, NY, 2-4 November _______________________________________ 1993. [17] Poulin, Jeffrey S. and Joseph M. Caruso, "Determining the Value of a Corporate Reuse Program," Proceedings of the IEEE Computer Society ___________________________________________ International Software Metrics Symposium, Baltimore, MD, 21-22 May 1993, _________________________________________ pp. 16-27. [18] Poulin, Jeffrey S., and Kathryn P. Yglesias, "Experiences with a Faceted Classification Scheme in a Large Reusable Software Library (RSL)," Sev- ____ enteenth Annual International Computer Software and Applications Confer- ________________________________________________________________________ ence, Phoenix, AZ, 3-5 November 1993, pp. 90-99. _____ [19] Prieto-Diaz, Ruben and Peter Freeman, "Classifying Software for Reusa- bility," IEEE Software, January 1987, pp. 6-16. ______________ [20] Prieto-Diaz, Ruben, "Domain Analysis for Reusability," Proceedings of _______________ COMPSAC '87, 1987, pp. 23-29. ____________ [21] Tracz, Will, "Software Reuse Technical Opportunities.," Proceedings of ______________ DARPA Software Technology Conference, Los Angeles, CA, April 28-30, _____________________________________ 1992. [22] Yglesias, Kathryn P., "Limitations of Certification Standards in Achieving Successful Parts Retrieval," Proceedings of the 5th Interna- _________________________________ tional Workshop on Software Reuse, Palo Alto, California, 26-29 October ___________________________________ 1992. 9.0 Biography JEFFREY S. POULIN (poulinj@vnet.ibm.com) joined IBM's Reuse Technology Support Center (RTSC), Poughkeepsie, New York, in 1991. His responsibilities on the RTSC included developing and applying corporate standards for reusable component classification, certification, and measurements. He currently works in Open Systems Development for IBM's Federal Systems Company and par- ticipates in the IBM Corporate Reuse Council, the Association for Computing Machinery, and the IEEE Computer Society. A Hertz Foundation Fellow, Dr. Poulin earned his Bachelors degree at the United States Military Academy at West Point, New York, and his Masters and Ph.D. degrees at Rensselaer Polytechnic Institute in Troy, New York. +++EDF154E Value of WIDTH attribute on the TABLE tag exceeds page width. (Page 4 File: SAC94 SCRIPT) +++EDF154E Value of WIDTH attribute on the TABLE tag exceeds page width. (Page 5 File: SAC94 SCRIPT) DSMBEG323I STARTING PASS 2 OF 2. +++EDF154E Value of WIDTH attribute on the TABLE tag exceeds page width. (Page 4 File: SAC94 SCRIPT) +++EDF154E Value of WIDTH attribute on the TABLE tag exceeds page width. (Page 5 File: SAC94 SCRIPT)