Findings from a Corporate Reuse Incentive Program Jeffrey S. Poulin Federal Systems Company International Business Machines Corporation 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. _____________________________________________________________________________ Finally, the paper presents a way to organize for reuse so it can 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. ____________________ 1.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 organ- ization such as IBM complicates providing this source of reusable assets. IBM's many activities involve numerous different programming languages, dif- ferent programming tools, and different areas of application. Every organ- ization in IBM, and in many cases individual sites and projects, have 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 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 IBM's experiences with a corporate-wide incentive program to develop reusable software for the RSL. Finally, the paper presents a way to organize for reuse to 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. 2.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 [5]. Although the theory behind creating a central software repository sounds 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 [7] 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 [8]. 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 [6]. 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 causes a number of problems because of the difficulty of quickly extracting the relevant reuse information from the plethora of other data [16]. Unfortunately, using an extensive classification scheme also requires the user to have a working knowledge of the issues and techniques surrounding software classification [17], and to especially have an under- standing of the scheme used by his particular RSL [20]. 3.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. 3.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 IBM if they made portions of the soft- ware "reusable." To incent organizations to make this determination, the program funded development organizations to study their project and the busi- ness issues related to reuse [15]. 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 [18], 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 IBM RSL, and, o maintaining the parts. 3.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 in achieving one of our first two goals: identifying candidate projects to develop software for use across IBM. Out of 25 proposals submitted, only 3 had the potential to create software that might prove useful outside its spe- cific domain. Despite our efforts, we discovered that the incentive program would not create software for corporate-wide reuse because of the very narrow scope of that collection of software. Because we lacked suitable proposals to develop domain-independent software, 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 (completed a domain analysis) an area for future software development. While these projects resulted in several useful deliverables, they did not contribute to the corporate reuse inventory. Table 1 gives a summary of the projects funded by the Parts Stimulation program. +------------------------------------------------------------------+ | 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 | +--------------------------------------------------+---------------+ 4.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)(1) 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 future applications using this standard set of rou- tines. However, this software has limited application outside of this par- ticular area in 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: __________ --------------- (1) 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 | +----+--------------------+--------------------+-------------------+ These 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 specific task. The above model simply underscores that the state-of-the-art in the practice of software reuse lies in constructing pro- grams from building blocks of reusable components, and that most components have a specific range of use. ____________ 5.0 Balancing Corporate RSLs with Domain-Specific RSLs 5.1 Parts at the corporate level A low-risk way to capitalize on reuse would make it easy to build programs out of domain-independent reusable components. Corporate-level groups must concentrate on supplying this software. IBM 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 interface (GUI), system functions, and operating system services. 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. 5.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. 5.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 [9]: 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 considerable 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. 5.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 [11]. 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 "ASA" macros and the use of Boeblingen Building Blocks [10]. Japanese corporations report very impressive reuse achievements with domain libraries consisting of only 70-100 assets [19]. Recent feedback on the effectiveness of large corporate versus small domain libraries in other companies shows similar results [5], [13]. Furthermore, successful experiences in a wide variety of domains such as telecommuni- cations [2], avionics [3], distributed systems [4], and simulation/modeling [12], appear with regularity. 6.0 Organizing for Domain-Specific Reuse We find the best place to develop these domain libraries lies where we find the expertise. Within IBM, 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 [14]. 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. Below we present three requirements of a successful program: 6.1.1 Requirement 1: A management plan A team dedicated to developing reusable software typically consists of one to six programmers; in a larger group one person acts as a team leader. The team reports as a matrixed support organization or directly to a high-level development manager. If the team has a strong technical background in their domain, the corporate group only needs to assist in developing a management plan containing methods to distribute, market and handle business issues, such as allowable uses and future maintenance of the software [1]. Technical details of the software and local distribution depend on the tools and lan- guage in use by the team. 6.1.2 Requirement 2: Funding Although it helps to have corporate funding available to establish local reuse centers, we do not have specific funding requirements. The key lies in helping the sites recognize the value of establishing parts centers and having them provide the personnel to initiate the work. The role of the cor- porate group lies in making these reuse centers self-sufficient by helping with suitable cost and business models and through business guidance on how to market and obtain revenue for their work. 6.1.3 Requirement 3: Technical Consulting Most members of the software development community, including managers and executives, believe in the value of software reuse. However, few people can tell them how to do it. The corporate group must provide the knowledge and ___ hands-on, technical consulting to make it actually happen. Although high- level, general overviews serve an important role in the initial phases of a formal reuse program, a corporate group must acquire a staff of reuse con- sultants respected for their technical ability. 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 targeted local development of 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," to appear, IBM Systems ____________ Journal, Vol. 32, No. 4, 1993. ________ [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] 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. [5] Griss, Martin, "Software Reuse: From Library to Factory," to appear, IBM ___ Systems Journal, Vol. 32, No. 4, Fall 1993. ________________ [6] "IBM Reuse Methodology: Classification Standards for Reusable Compo- nents," IBM Document Number Z325-0681, 2 October 1992. ______________________________ [7] "IBM Reuse Methodology: Incentives," IBM Document Number Z325-0692, 2 ________________________________ October 1992. [8] "IBM Reuse Methodology: Qualification Standards for Reusable Components," IBM Document Number Z325-0683, 2 October 1992. ______________________________ [9] 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. [10] 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. [11] 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. [12] 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. ____________ [13] Neumann, Valerie A. "Moving Beyond Library-based Reuse," to appear, 6th ___ Annual Workshop on Software Reuse, Owego, NY, 2-4 November 1993. __________________________________ [14] Ning, Jim Q., "Module Interface Specification and Large-Grain Software Reuse," to appear, 6th Annual Workshop on Software Reuse, Owego, NY, 2-4 ______________________________________ November 1993. [15] 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. [16] Poulin, Jeffrey S., and Kathryn P. Yglesias, "Experiences with a Faceted Classification Scheme in a Large Reusable Software Library (RSL)," to appear, Seventeenth Annual International Computer Software and Applica- _______________________________________________________________ tions Conference, Phoenix, AZ, 3-5 November 1993. _________________ [17] Prieto-Diaz, Ruben and Peter Freeman, "Classifying Software for Reusa- bility," IEEE Software, January 1987, pp. 6-16. ______________ [18] Prieto-Diaz, Ruben, "Domain Analysis for Reusability," Proceedings of ______________ COMPSAC '87, 1987, pp. 23-29. ____________ [19] Tracz, Will, "Software Reuse Technical Opportunities.," Proceedings of _______________ DARPA Software Technology Conference, Los Angeles, CA, April 28-30, ________________________________________ 1992. [20] 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: DOMLIB SCRIPTTR) +++EDF154E Value of WIDTH attribute on the TABLE tag exceeds page width. (Page 5 File: DOMLIB SCRIPTTR) DSMBEG323I STARTING PASS 2 OF 2. +++EDF154E Value of WIDTH attribute on the TABLE tag exceeds page width. (Page 4 File: DOMLIB SCRIPTTR) +++EDF154E Value of WIDTH attribute on the TABLE tag exceeds page width. (Page 5 File: DOMLIB SCRIPTTR)