- Email: [email protected]
Software reuse in Japan
ELSEVIER
Information
and Software
Technology
38 (1996) 165-171
Software reuse in Japan Sadahiro Isoda* Toyohashi University
ofTechnology, Toyohashi, Japan
Abstract Software reuse in Japan has been mainly carried on by mainframers as a means to develop effectively their business applications. Each of the Japanese mainframers has developed its own integrated software development environments that support software reuse as one of their major functionalities. Now that they have succeeded in reusing program code and design, they are trying to broaden the target of reuse to include software architectures. The importance of the managerial aspect of software reuse is now being understood. Some companies are putting much stress on the technology transfer issue of software reuse, and others are applying incentive systems to encourage software engineers who participate in software development. This paper outlines the current status of the research and practice of software reuse in Japanese industries and research organizations. Keywords:
CASE; Domain analysis;
Software
reuse
1. Introduction Software reuse was first discussed publicly in 1969 at the NATO Conference, where McIlroy of Bell Laboratories proposed the industrialization of software development based on code reuse [l] . For ten years after his proposal there were no significant research reports on software reuse, before Lanergan reported a successful software reuse project at Raytheon in 1979. They attained a 15% to 85% reuse ratio in the COBOL business application development by combining standard program patterns and functional components. Triggered by his report, research on software reuse became active in the 1980s. An ITT Workshop on Reusability in Programming, the first grand scale conference on software reuse, was held in 1983. Two major technical journals published special issues on software reuse in 1984 and 1987 [2,3]. Two tutorial books containing a variety of original and reprinted research papers on software reuse were published successively in 1987 and 1988 [4,5]. The interest in software reuse continues to grow in the 1990s and it is broadening worldwide. The first international workshop on software reuse was held in Dortmund, Germany, in 1991, and the second one in Lucca, Italy, in 1993 [6,7]. In 1994, the international conference on software reuse, a successor of the two workshops, was held in Rio de Janeiro [ 81. It was also in the 1980s that software reuse became active in Japan. As software development in Japan is mainly carried on by mainframers and their subsidiaries, research and practice of software reuse grew in their major domain,
*email:[email protected]
0950-5849/96/$15.00 0 1996 Elsevier Science B.V. All rights reserved SSDI 0950-5849(95)01070-X
i.e. the business applications. By the end of the 198Os, each of the Japanese mainframers developed its own CASE, or integrated software development environments, that support software reuse as one of their major functionalities. This paper discusses Hitachi’s case to see what their CASEbased software reuse is. Domain analysis is the task of analysing a group of similar application programs to obtain data structures and functionalities that are common to the programs. Component development based on domain analysis is likely to result in large-scale and highly reusable components. Therefore, domain analysis is a key to the success of software reuse. Each of the Japanese mainframers has been performing software reuse based on domain analysis in their major target application areas. This paper outlines Toshiba’s case. Now that Japanese mainframers have succeeded in reusing program code and design, they are trying to reuse software architectures, which are more abstract logical entities than design. We can perform requirement analysis more efficiently if we use (reuse) application architectures. This paper discusses Fujitsu’s approach. When it is performed by an individual or a small group, software reuse is an easy task. However, when it is to be performed by many people in an organization, there appear many factors that hinder software reuse. These are managerial factors, including organizational, people, and economical factors. The success and failure of organizational software reuse is greatly influenced by these managerial factors. This paper presents NTT’s practical research that revealed the importance of the managerial aspect of organizational software reuse. Japanese mainframers are generally believed to be advanced in software reuse, but it is rather unlikely that
166
S. Isodallnformation and Software Technology 38 (19%) 165-l 71
every one of their software developing departments is enjoying high reusability. As it is, technology transfer is one of the major issues in institutionalizing software reuse. The paper sketches Toshiba’s case. Independent software houses are at a disadvantage with software reuse because they have to work in various domains and on several platforms in compliance with their customers’ needs. This is liable to discourage them from accumulating reusable components. In spite of all these adverse factors, there are several companies which have been continuing persistent efforts with software reuse. The paper outlines Nippon Novel’s case. 2. CASE-based software reuse Software development in Japan is mainly carried on by mainframers and their subsidiaries, and their major products are custom business applications. This is a peculiar difference from the US, where independent software houses, selling general purpose software packages, are dominant in the software business. This situation has greatly influenced the Japanese software reuse evolvement. Each of the Japanese mainframers, i.e., NEC, Hitachi, Fujitsu and Toshiba, had developed its own CASE, or integrated software development environments, by the end of 198Os, and their CASES provide the functionality for software reuse as one of their most important features. Hitachi has been using their own CASE environment, called EAGLE, since the early 1980s [9]. EAGLE allows software engineers to reuse standard program patterns (often called skeletons) and functional procedures in order to develop business applications written in COBOL or PL/I. It provides two sets of program patterns, one for batch programs and the other for on-line programs. The former consists of 31 types, including file conversion, editing, updating, and report generation, and the latter consists of 45 types, including inquiry, database updating and data entry. The capability of EAGLE is limited in the sense that software engineers have to add own-coding to the EAGLE-generated programs or modify them. The generation rate, which is defined as the ratio of the size of the generated lines of code (LOC) to the total LOC of the complete program, is between 50% and 80%. Hitachi has been continuing to improve their CASE’s reuse capability [ lo] . In 1990, they released a workstation-based software development system called SEWB (software engineering workbench), which is a successor to EAGLE that works on mainframe computers. In the 198Os, the functional decomposition was Hitachi!s customary design approach. They noticed, however, that it was rather difficult to build a standard component library based on the functional decomposition approach because how to decompose a function into subfunctions varies greatly from designer to designer. They observed that data items comprising a system are more stable than functionalities because they have good correspondence to the entities in
the real world. Encouraged by this observation, they developed a program generator based on a new approach, called the data-oriented (DOA) approach. A library of data components called ‘standard data dictionary’ was developed in the following steps. They first assembled 20000 data items from 200 existing business applications, and extracted 1600 standard data items from them. They developed data components capsuling the name and attributes of the data item together with their accessing routines including input and output data conversion, and data validation. Then they arranged the data components into a standard data dictionary and provided it with development projects. Each development project customizes the standard data dictionary to make their own data dictionary that suits their applications. The DOA generator makes application programs by choosing appropriate data components from the data dictionary and embedding them into program patterns. The information available for the standard pattern generation system of the 1980s EAGLE was program patterns and program specifications. This limited EAGLE to generate code only up to the level of record manipulation and not of finer levels. The DOA generator, on the contrary, is more powerful. It can generate program code for checking data items and converting them for input and output because the information on how to handle data items is available from the DOA components. This new feature is effective in reducing most of the code which used to be own-coded with EAGLE. The generation rate, which used to be 50% to 60% with EAGLE, improved to as much as 80% to 90%. The rate, of course, varies for different kinds of programs. The highest rate, of 98 % , is attained by report generation programs. On the average, 10% to 20 % increase in the generation rate is attained by the DOA generator in comparison with EAGLE. The DOA generator also brings higher reliability and productivity in addition to the higher generation rate. The bug density at testing phase decreased to about two-thirds of that when using EAGLE, and the productivity improved by 30 % to 90%. 3. Library construction based on domain analysis One of the key factors for successful organizational software reuse is to perform domain analysis and then to develop reusable components based on the domain analysis. Domain analysis is the task of analysing a group of similar application programs to obtain a domain model consisting of data structures and functionalities that are common to the programs. Component development based on domain analysis is likely to result in large-scale and highly reusable components. Therefore, domain analysis is a key to the success of software reuse. The first thing we have to consider before beginning domain analysis is to select such a domain that is appropriate for software reuse. Generally, whether an organizational software reuse project succeeds or not largely depends on the nature of the target domain. It would be
S. Isoda I Information and Sofware Technology 38 (19%) 165-I 71
useless to apply software reuse to a bad domain. When looking at the world’s successful reuse case, what is common is that the target domain satisfies the following requirements:
(1) Comparatively narrow. (2) Well understood. technology is stable and does not (3) The underlying change in a short period. (4) Many programs will be developed in the near future. The first three requirements facilitate domain analysis and component development, and the fourth one allows the cost to be covered by repeated reuses. Toshiba has compiled a domain-analysis manual that prescribes the activities of their software reuse [ 111. It states that domain analysis and software reuse should proceed in the following way. (1) Select a series of applications that production plans. (2) Apply them to a domain analysis ation architecture. (3) Develop standard components in architecture. (4) Reuse the components during series of applications.
have two to five-year to obtain an appliccompliance development
with the of the
The selection standard (item 1) satisfies the requirements for good domains listed above. The manual also states what should be the input information to the domain analysis. The information ranges from specifications of existing applications to requirements for the future applications, and to advice from domain specialists. A questionnaire may be sent out to users to acquire future images of the target domain if it is possible to identify specific users. The manual also recommends that the success and failure cases of similar products should be compared. The software architecture that Toshiba prescribes is a structure consisting of five layers: Layer 1. Target Layer 2.
Layer 3.
Layer 4. Luyer 5.
platform. Operating systems, language processors, etc. Target tools. Database management systems, graphical user interfaces including window management systems, communication protocols, etc. Common features specific to the target domain, such as business processing, process control, embedded microcomputer control, etc. Standard features common to series of applications. Inherent features to each application.
Toshiba applies the object modelling technique of Rumbaugh for analysing the target domain. The three major models of OMT, i.e. the object, behavioural and functional models, are used for specifying the results of analysis. Toshiba reports a case study of applying their domain oriented software reuse to a series of process control systems. The domain analysis followed by development of standard
167
components proceeded in a close link with the development of the first application product of the series. For the first half year they discussed how. to perform domain-oriented software reuse. Then, another half year in advance of the product development, they started domain analysis. They developed standard components and provided them in time for the product development. They report that the schedule allowed them enough time to improve reliability of the components. The number of the standard components was 489, and its breakdown into the layers was 59,29, 156, 181 and 64 for the layers 1 to 5, respectively. The reason why they developed components of layers 1 and 2 was that the target platform did not provide enough functionalities. Some metrics of the first product development using the standard library are reported. The size of the program is 200 thousand lines of code; it consists of 151 programs; each program consists of 32 components on the average; the average frequency of components is 6.0; the component usage ratio is 60%. Here, the usage ratio of components is defined as the ratio of the sum of the frequencies of all the standard components to the total number of the components comprising the application. It should be noted that the usage of a standard component in two different programs is counted as twice. They estimate that thanks to the reuse about 30% of the development cost was reduced. Toshiba has been applying their approach to many projects. They report some basic metrics (shown below) based on the experience. These will be of great importance for those organizations that are willing to apply the domain-oriented software reuse. Man-month and period of time. Planning and specifications of standard components requires a few people, at most five, and a period of half a year. One year is the average length of time from planning to testing. It costs 30% to 50% more to develop standard components than to develop usual software modules. This extra cost is attributable to the requirements for more flexible design, more detailed documentation, and more thorough testing. These requirements come from the fact that the standard components have to be designed prior to their actual usage. The usage ratio of components can be more than 60% if similar products have been developed before and the standard components are developed based on that experience. The critical number of usage frequency is between three and five. If the standard components are used more than this number on the average, the development cost will be covered.
4. Reuse of application
architecture
Now that Japanese mainframers have succeeded in reusing program code and design, they are trying to reuse software
168
S. Isodallnformation and Software Technology 38 (19%) 165-I 71
architectures, which are more abstract logical entities than design. An application architecture is the common structure of application programs in a certain domain. We can reuse an application architecture as a basis for requirements specifications. That is, for each application development we select an appropriate application architecture, identify differences between what is required for the system to be developed and the application architecture, and then customize the application architecture to obtain the requirements specifications of the system to be developed. This will help reduce defects of the specifications, allowing the reuse of more domain-specific and large components in the design. That is, by reusing application architecture, we can: . make requirement analysis efficient; . make more reliable specifications; and . maximize software reuse of program code and design. The most advanced domain in terms of the reuse of application architectures is business applications, which are to computerize miscellaneous activities in corporations, such as accounting, personnel, payroll, inventory, and order entry. This is because the applications for these business activities are very similar among corporations and in great demand. Application architectures are constructed usually by analysing many existing programs, extracting those features that are common among them, and then integrating them to form a standard architecture (or top level design) that are applicable to most applications in the target domain. This activity is often called the domain analysis. Application architectures are reused by way of system requirements analysis. That is, when we have an application to be developed, we select an application architecture that is most similar to the application, analyse the difference between it and the user’s requirements, and then customize it to suit the user’s requirements. Fujitsu’s approach to constructing application architectures is to analyse an existing business package [ 121. Application packages are generally designed to suit the requirements of users as much as possible by parametrizing those features that can vary depending on users requirements. The parameters are to be replaced with certain values when the package is installed. However, parametrization of packages is not always applicable. It well applies to those existing domains that are prescribed in detail by the tradition, law and regulations and standards, or ad hoc ones of the business area, because users will not have much freedom in choosing features. It will not be applicable, however, to those new domains that have fewer regulations and restrictions because the differences among users’ requirements are too broad to be covered by parametrization. If we should apply a business package to the latter domain and want to meet the specific requirements of users, we have to change its code, thereby almost losing the merit of the package.
Fujitsu has been selling packages together with customization service. The problem with this business is that it takes a considerable effort to customize a package for each customer. For example, it took 30 man-months to customize a production management package on ‘office computers’ or small-scale mainframes for medium-sized manufacturers, consisting of 500 COBOL programs. This large cost triggered them to think of reusing application architectures for package customization. Fujitsu’s approach for constructing application architectures is to analyse packages in the reverse way, in a sense to extract the fundamental mechanisms and business rules contained in the packages and then to reconstruct a standard architecture. They analysed the package, got information from the developers of the package and also from the system engineers who had customized it. They spent three months on this stage. Then they experimented reusing the architecture for the system analysis Qf a typical application system. Three system analysts and two people representing the customer participated in the experiment. It turned out that the job was completed in only four days, while the conventional method without using any model architectures took 35 days. A standard representation schema is required for modelling the application architecture. Fujitsu prescribed a standard representation schema for modelling the three different aspects of the business, namely function, control and data. The scheme consists of 22 different charts and tables such as business function structure graphs, business transaction flows, and business transaction file tables. The size of the final documentation amounted to several hundred pages for the case mentioned above. Encouraged by this favourable result, Fujitsu developed a methodology and its associated CASE tool, called AA/BRmodeller (Application Architecture/Business Rule Modelling). They are now energetically introducing it to their software developments. Their plan was to introduce it to as many as 200 projects by the end of March 1995.
5. Managerial
aspect of software reuse
When it is performed by an individual or a small group, software reuse is an easy task as it has been performed by experienced software engineers since just after software was born. They have their own reusable entities in their own file directories, or they customize existing software they themselves developed to make new versions. However, when it is to be performed by many people in an organization, the situation changes completely. There appear many factors that hinder software reuse. These are managerial factors, including organizational, people, and economical factors. The importance of managerial factors of software reuse is now being understood by those who have not been involved in software reuse as well as by those who have.
S. IsodalInformation and Sofware
NTT Software Laboratories have performed an organizational software reuse project which lasted for four years, involving as many as 600 engineers [ 131 . The object for reuse was program code modules, and the target domain was the software development support tools, which is different from the usually reported COBOL business applications. Over the four years, they observed a growth in some important aspects of software reuse, including the reuse ratio, reused component size, origin of reused components, and usage of the library. Z&e average reuse ratio. The average reuse ratio increased each year, beginning at 3% in the first year, and then gradually increasing to 16% in the fourth year. It seemed, however, to saturate at around 20%. EJre average size of reused components. The average size of reused components went up each year. In the fourth year, the average size of reused components was about 600 lines of code, which was about twice that of the second year. This is very important because reusing larger components is an effective way to attain higher reuse ratios. 7?re origin of the reused components. The software development projects increasingly used more and more components deposited by other projects. In the second year, the ratio was about lo%, but in the fourth year it increased to as much as 70%. The ratio of components retrieved from the library was 100% in the fourth year. This meant that all the reused components came from the library. 77re usage of the library. The average reuse frequency is defined as the ratio of the total count of component reuses in a year to the number of components stored in the library. The average reuse frequency increased each year, beginning at 0.18 in second year and increasing to 0.28 in the fourth year. 7&e active component ratio. The active component ratio is defined as the ratio of components reused at least once each year to the number of components stored in the library. The active component ratio stayed almost stationary, at about 0.2. This low ratio suggested that not a small portion of the library might be just a junk and some way of screening was required. They report that the reuse project proceeded but not without impediments. Some people actively worked, some followed the leaders reluctantly, and others made little contribution. The issues impeding software reuse can be grouped into the following three categories:
Technology 38 (19%) 165-I 71
(f) jobs could be done without software reuse. (3) Psychological issues (g) reluctant because of unpredictable benefits; (h) repulsion to top-down activities. The first impediment, or inadequate library, was the biggest problem because what can be reused must be available prior to its use. If there is no component library containing enough components, reuse cannot happen easily. However, construction of even a modest library is very difficult because a large initial investment is required. The third and fourth issues imply that the organization was not well designed to encourage software reuse, but rather to hinder its progress. It is necessary to supply project managers with enough resources to consider reuse during their software development and also to educate software engineers about the importance of software reuse. Some incentive system would be effective to trigger a cultural change in an organization. The fifth impediment is caused by contracts specifying payment by LOC or effort. The solution to this problem is to change the contract so as to consider the productivity improvement by contract developers. The sixth means that whether to apply software reuse or not is usually up to the software engineers and the project manager because the internal design is hidden from outside. Unless they find their own benefit from applying software reuse to their development project, they will not perform reuse of their own free will. The seventh and eighth are psychological issues. The only way to solve these impediments is to make a persistent effort to change the organizational culture so that project managers and software engineers are willing to cooperate for the benefit of the organization. They claim that these impediments originate from the essential nature of software reuse, i.e. (a) software reuse is against individual’s natural conduct; and (b) software reuse is beyond individual’s capability. That is, individual software engineers and project managers do not want to make the effort to start software reuse, and cannot do so if they remain in the conventional way of management. Therefore, software reuse is inherently a managerial issue [ 51 . Based on the experience, NTT Software Laboratories conclude that the success and failure of organizational software reuse are greatly influenced by its managerial aspects, and that the key factors for success are:
(1) Selection (1) Reuse library issues (a) inadequate library; (b) component functionality and reliability are not understood. (2) Organizational issues (c) no additional resource to consider reuse during development; (d) no direct benefit to component developers; (e) no benefit to contract developers;
169
of an appropriate domain that has many similar programs to be developed. This ensures existence of common and frequent functionalities. (2) Systematic development of reusable components based on domain analysis. This ensures easier acquisition of large and highly reusable components. commitment. This ensures the (3) Senior management managerial problems to be solved. (4) Several years’ continuous effort to do these three items 1141.
S. Isodallnformation and Software Technology 38 (19%) 165-I 71
170
5. Technology
transfer
Technology transfer is one of the major issues in the managerial aspects. Japanese mainframers are generally believed to be advanced in software reuse, but it is rather unlikely that every one of their software developing departments is enjoying high reusability. A more probable picture might be that there are some which are successful with software reuse, but for several reasons the majority are reluctant to apply it. Toshiba is one of the forerunners of software reuse in Japan. Their Fuchu Factory made a great success in applying the library-based software reuse to their process control software in the early 1980s. However, as Toshiba is a large organization, covering from large-scale information processing systems and process control systems to electrical appliances, not every department is applying software reuse. Their System and Software Engineering Laboratory, which is responsible for developing software reuse methodology and tools, has developed an educational course on software reuse targeting at managers and senior engineers. They hope the course will facilitate the transfer of their developed technology in their company. The course lasts two days, consisting of lectures, hands-on exercises, and discussion. The subjects are the fundamentals of software reuse, reuse-oriented software development, domain analysis for application families, managerial aspects of software reuse, and so forth. They hold courses not only at the central location but also at local development sites [ 151.
6. Independents Independent software houses are at a disadvantage with software reuse because they have to work in various domains and on several platforms in compliance with their customers’ needs, and this is liable to discourage them from accumulating reusable components. In spite of all these adverse factors, there are several companies who have been continuing persistent efforts with software reuse. Nippon Novel is a small software house with about 100 software engineers, developing versatile kinds of software including measuring, process controlling, CAD/CAM, communications, and factory automation. Since 1987, they have been performing a software reuse program steadily [ 161. Their success is proved by the increase in the total reuse size per year, the average size of reused components, and the average size of registered components. What is interesting with Nippon Novel is that they employ a very materialistic incentive system, without putting obligations of any kind to the engineers. They give cash to the software engineers on a line-of-code (LOC) basis. The rate is five cents per LOC when registering a component, and, when reusing a component, five cents per LOC for the reuser and one cent per LOC for the developer of the component. The total amount of the incentive money
last year accumulated to about $8,000. The incentive money is paid quarterly every year. The best engineers of the year in each of the three categories are also awarded. The most frequently reused component is 3000 LOC of size and has been reused 40 times. Some statistics of 1992 are as follows: 16 components were registered, 59 components were reused. The average size of the registered components is 1.5 thousand LOC. The average size of the reused components is 1.4 thousand LOC. The average reuse ratio is 10% to 15%. They claim that their success in software reuse could not have been realized without this incentive system.
7. Conclusion
This paper outlines the current status of the research and practice of software reuse in Japanese industries and research organizations. Software reuse in Japan has been mainly carried on by mainframers as a means to develop effectively their business applications. Now that Japanese mainframers have succeeded in reusing program code and design, they are trying to broaden the target of reuse to include the software architecture. The importance of the managerial aspect of software reuse is now being understood. Some companies are putting much stress on the technology transfer issue of software reuse, and others are applying incentive systems to encourage engineers who participate in software development. As Cusumano reports, software reuse is one of the distinguishing features of Japanese software development [ 171. The idea of software reuse is never a Japanese-made technology, but they have continuously improved it to completion. One of the reasons for the Japanese success with software reuse is that the i&erent nature of software reuse is well in accordance with the Japanese tendency of groupism and gradualism. That is, software reuse requires collaboration of individuals who work for the whole and continuous kaizen of several years. The so-called not-invented-here syndrome, which American researchers often cite as a reason why people do not like software reuse, is not so evident in Japan. People seem to have less reluctance to use somebody else’s program code. This may be another symptom of Japanese tendency to groupism and gradualism. All the software reuse cases sketched in this paper are publicly reported in journals, magazines and at symposiums. These cases may be just an outline of the leading edge of the research and practice on software reuse in Japan. It is therefore hard to deny that ad hoc software reuse might be prevailing in most organizations. However, by seeing the fact that there is a sharp increase in the number of symposiums and research papers on software reuse, we can expect that the average level of software reuse will continue to go up.
S. Isodallnformarion
and Sofiware
Technology 38 (19%) 165-I 71
References [ I] M D McIlroy ‘Mass produced software components’,
1969 NATO Conf on Sofr. Eng. (1969) pp 88-98 [2] IEEE ‘Special issue on software reusability’, IEEE Trans. SOB. Eng. Vol SE-IO No 5 (1984) [3] IEEE ‘Special issue on software reusability’, IEEE Sof. Vol 4 No 2 (1987) [4] P Freeman, Tutorial: Sofrware Reusability IEEE Computer Society Press (1987) [ 51 W Tracz, Tutorial: So&are Reuse: Emerging Technology IEEE Computer Society Press (1988) [ 61 R Prieto-Diaz, et al. The First lnternafional Workshop on So&are Reusability University of Dortmund, Dortmund, Germany (1991a) [ 71 R Prieto-Diaz and W B Frakes, Advances in Software ReuseSelected Papers from the Second International Workshop of Sofrware Reusabiliry IEEE Computer Society Press (1993) [8] W B Frakes, (ed) The Third International Conference on Software Reuse IEEE Computer Society Press (1994) [9] M Tsuda, et al. ‘Productivity analysis of software development with an integrated CASE tool’, 15rh Int. Conf on Soft. Eng. (May 1992) pp 49-58. [lo] M Tsuda, ‘Evolution of software reuse technology’, Symposium on
[ 111
[ 121 [ 131
[ 141 [ 151
[ 161
[ 171
171
Software Tools, Japan Information Service Association (1994) pp 99-102 (In Japanese) K Matsumura, ‘A software reuse case study based on a standard library approach’, in Software Modeling and Software Reuse Kyoritsu Shuppan (1995) pp 62-83 (In Japanese) A Yoshioka and K Hashimoto, ‘A practice in reuse of business model’, Symposium on Sofware Reusability Information Processing Society of Japan (1992) pp 11-17 (In Japanese) S Isoda, ‘Experience report of software reuse reuse project: its structure, activities, and statistical results’, 15th Znt. Conj on So@. Eng. (May 1992) pp 320-326. R Prieto-Diaz, ‘Making software reuse work: an implementation model’, ACM SIGSOFT Sofr. Eng. Nores Vol 16 No 3 (1991) pp 61-68 N Munechika and K Matsumura, ‘Development of education course on software reusability’, Symposium on Sofrware Reusability, Information Processing Society of Japan (1992) pp 33-41 (In Japanese) M Kikumoto, ‘Report on an organized software reuse project’, in Sofware Modelling and Software Reuse Kyoritsu Shuppan (1995) pp 47-61 (In Japanese) M A Cusumano, Japan’s Soffware Facfories Oxford University Press (1991)
Information
and Software
Technology
38 (1996) 165-171
Software reuse in Japan Sadahiro Isoda* Toyohashi University
ofTechnology, Toyohashi, Japan
Abstract Software reuse in Japan has been mainly carried on by mainframers as a means to develop effectively their business applications. Each of the Japanese mainframers has developed its own integrated software development environments that support software reuse as one of their major functionalities. Now that they have succeeded in reusing program code and design, they are trying to broaden the target of reuse to include software architectures. The importance of the managerial aspect of software reuse is now being understood. Some companies are putting much stress on the technology transfer issue of software reuse, and others are applying incentive systems to encourage software engineers who participate in software development. This paper outlines the current status of the research and practice of software reuse in Japanese industries and research organizations. Keywords:
CASE; Domain analysis;
Software
reuse
1. Introduction Software reuse was first discussed publicly in 1969 at the NATO Conference, where McIlroy of Bell Laboratories proposed the industrialization of software development based on code reuse [l] . For ten years after his proposal there were no significant research reports on software reuse, before Lanergan reported a successful software reuse project at Raytheon in 1979. They attained a 15% to 85% reuse ratio in the COBOL business application development by combining standard program patterns and functional components. Triggered by his report, research on software reuse became active in the 1980s. An ITT Workshop on Reusability in Programming, the first grand scale conference on software reuse, was held in 1983. Two major technical journals published special issues on software reuse in 1984 and 1987 [2,3]. Two tutorial books containing a variety of original and reprinted research papers on software reuse were published successively in 1987 and 1988 [4,5]. The interest in software reuse continues to grow in the 1990s and it is broadening worldwide. The first international workshop on software reuse was held in Dortmund, Germany, in 1991, and the second one in Lucca, Italy, in 1993 [6,7]. In 1994, the international conference on software reuse, a successor of the two workshops, was held in Rio de Janeiro [ 81. It was also in the 1980s that software reuse became active in Japan. As software development in Japan is mainly carried on by mainframers and their subsidiaries, research and practice of software reuse grew in their major domain,
*email:[email protected]
0950-5849/96/$15.00 0 1996 Elsevier Science B.V. All rights reserved SSDI 0950-5849(95)01070-X
i.e. the business applications. By the end of the 198Os, each of the Japanese mainframers developed its own CASE, or integrated software development environments, that support software reuse as one of their major functionalities. This paper discusses Hitachi’s case to see what their CASEbased software reuse is. Domain analysis is the task of analysing a group of similar application programs to obtain data structures and functionalities that are common to the programs. Component development based on domain analysis is likely to result in large-scale and highly reusable components. Therefore, domain analysis is a key to the success of software reuse. Each of the Japanese mainframers has been performing software reuse based on domain analysis in their major target application areas. This paper outlines Toshiba’s case. Now that Japanese mainframers have succeeded in reusing program code and design, they are trying to reuse software architectures, which are more abstract logical entities than design. We can perform requirement analysis more efficiently if we use (reuse) application architectures. This paper discusses Fujitsu’s approach. When it is performed by an individual or a small group, software reuse is an easy task. However, when it is to be performed by many people in an organization, there appear many factors that hinder software reuse. These are managerial factors, including organizational, people, and economical factors. The success and failure of organizational software reuse is greatly influenced by these managerial factors. This paper presents NTT’s practical research that revealed the importance of the managerial aspect of organizational software reuse. Japanese mainframers are generally believed to be advanced in software reuse, but it is rather unlikely that
166
S. Isodallnformation and Software Technology 38 (19%) 165-l 71
every one of their software developing departments is enjoying high reusability. As it is, technology transfer is one of the major issues in institutionalizing software reuse. The paper sketches Toshiba’s case. Independent software houses are at a disadvantage with software reuse because they have to work in various domains and on several platforms in compliance with their customers’ needs. This is liable to discourage them from accumulating reusable components. In spite of all these adverse factors, there are several companies which have been continuing persistent efforts with software reuse. The paper outlines Nippon Novel’s case. 2. CASE-based software reuse Software development in Japan is mainly carried on by mainframers and their subsidiaries, and their major products are custom business applications. This is a peculiar difference from the US, where independent software houses, selling general purpose software packages, are dominant in the software business. This situation has greatly influenced the Japanese software reuse evolvement. Each of the Japanese mainframers, i.e., NEC, Hitachi, Fujitsu and Toshiba, had developed its own CASE, or integrated software development environments, by the end of 198Os, and their CASES provide the functionality for software reuse as one of their most important features. Hitachi has been using their own CASE environment, called EAGLE, since the early 1980s [9]. EAGLE allows software engineers to reuse standard program patterns (often called skeletons) and functional procedures in order to develop business applications written in COBOL or PL/I. It provides two sets of program patterns, one for batch programs and the other for on-line programs. The former consists of 31 types, including file conversion, editing, updating, and report generation, and the latter consists of 45 types, including inquiry, database updating and data entry. The capability of EAGLE is limited in the sense that software engineers have to add own-coding to the EAGLE-generated programs or modify them. The generation rate, which is defined as the ratio of the size of the generated lines of code (LOC) to the total LOC of the complete program, is between 50% and 80%. Hitachi has been continuing to improve their CASE’s reuse capability [ lo] . In 1990, they released a workstation-based software development system called SEWB (software engineering workbench), which is a successor to EAGLE that works on mainframe computers. In the 198Os, the functional decomposition was Hitachi!s customary design approach. They noticed, however, that it was rather difficult to build a standard component library based on the functional decomposition approach because how to decompose a function into subfunctions varies greatly from designer to designer. They observed that data items comprising a system are more stable than functionalities because they have good correspondence to the entities in
the real world. Encouraged by this observation, they developed a program generator based on a new approach, called the data-oriented (DOA) approach. A library of data components called ‘standard data dictionary’ was developed in the following steps. They first assembled 20000 data items from 200 existing business applications, and extracted 1600 standard data items from them. They developed data components capsuling the name and attributes of the data item together with their accessing routines including input and output data conversion, and data validation. Then they arranged the data components into a standard data dictionary and provided it with development projects. Each development project customizes the standard data dictionary to make their own data dictionary that suits their applications. The DOA generator makes application programs by choosing appropriate data components from the data dictionary and embedding them into program patterns. The information available for the standard pattern generation system of the 1980s EAGLE was program patterns and program specifications. This limited EAGLE to generate code only up to the level of record manipulation and not of finer levels. The DOA generator, on the contrary, is more powerful. It can generate program code for checking data items and converting them for input and output because the information on how to handle data items is available from the DOA components. This new feature is effective in reducing most of the code which used to be own-coded with EAGLE. The generation rate, which used to be 50% to 60% with EAGLE, improved to as much as 80% to 90%. The rate, of course, varies for different kinds of programs. The highest rate, of 98 % , is attained by report generation programs. On the average, 10% to 20 % increase in the generation rate is attained by the DOA generator in comparison with EAGLE. The DOA generator also brings higher reliability and productivity in addition to the higher generation rate. The bug density at testing phase decreased to about two-thirds of that when using EAGLE, and the productivity improved by 30 % to 90%. 3. Library construction based on domain analysis One of the key factors for successful organizational software reuse is to perform domain analysis and then to develop reusable components based on the domain analysis. Domain analysis is the task of analysing a group of similar application programs to obtain a domain model consisting of data structures and functionalities that are common to the programs. Component development based on domain analysis is likely to result in large-scale and highly reusable components. Therefore, domain analysis is a key to the success of software reuse. The first thing we have to consider before beginning domain analysis is to select such a domain that is appropriate for software reuse. Generally, whether an organizational software reuse project succeeds or not largely depends on the nature of the target domain. It would be
S. Isoda I Information and Sofware Technology 38 (19%) 165-I 71
useless to apply software reuse to a bad domain. When looking at the world’s successful reuse case, what is common is that the target domain satisfies the following requirements:
(1) Comparatively narrow. (2) Well understood. technology is stable and does not (3) The underlying change in a short period. (4) Many programs will be developed in the near future. The first three requirements facilitate domain analysis and component development, and the fourth one allows the cost to be covered by repeated reuses. Toshiba has compiled a domain-analysis manual that prescribes the activities of their software reuse [ 111. It states that domain analysis and software reuse should proceed in the following way. (1) Select a series of applications that production plans. (2) Apply them to a domain analysis ation architecture. (3) Develop standard components in architecture. (4) Reuse the components during series of applications.
have two to five-year to obtain an appliccompliance development
with the of the
The selection standard (item 1) satisfies the requirements for good domains listed above. The manual also states what should be the input information to the domain analysis. The information ranges from specifications of existing applications to requirements for the future applications, and to advice from domain specialists. A questionnaire may be sent out to users to acquire future images of the target domain if it is possible to identify specific users. The manual also recommends that the success and failure cases of similar products should be compared. The software architecture that Toshiba prescribes is a structure consisting of five layers: Layer 1. Target Layer 2.
Layer 3.
Layer 4. Luyer 5.
platform. Operating systems, language processors, etc. Target tools. Database management systems, graphical user interfaces including window management systems, communication protocols, etc. Common features specific to the target domain, such as business processing, process control, embedded microcomputer control, etc. Standard features common to series of applications. Inherent features to each application.
Toshiba applies the object modelling technique of Rumbaugh for analysing the target domain. The three major models of OMT, i.e. the object, behavioural and functional models, are used for specifying the results of analysis. Toshiba reports a case study of applying their domain oriented software reuse to a series of process control systems. The domain analysis followed by development of standard
167
components proceeded in a close link with the development of the first application product of the series. For the first half year they discussed how. to perform domain-oriented software reuse. Then, another half year in advance of the product development, they started domain analysis. They developed standard components and provided them in time for the product development. They report that the schedule allowed them enough time to improve reliability of the components. The number of the standard components was 489, and its breakdown into the layers was 59,29, 156, 181 and 64 for the layers 1 to 5, respectively. The reason why they developed components of layers 1 and 2 was that the target platform did not provide enough functionalities. Some metrics of the first product development using the standard library are reported. The size of the program is 200 thousand lines of code; it consists of 151 programs; each program consists of 32 components on the average; the average frequency of components is 6.0; the component usage ratio is 60%. Here, the usage ratio of components is defined as the ratio of the sum of the frequencies of all the standard components to the total number of the components comprising the application. It should be noted that the usage of a standard component in two different programs is counted as twice. They estimate that thanks to the reuse about 30% of the development cost was reduced. Toshiba has been applying their approach to many projects. They report some basic metrics (shown below) based on the experience. These will be of great importance for those organizations that are willing to apply the domain-oriented software reuse. Man-month and period of time. Planning and specifications of standard components requires a few people, at most five, and a period of half a year. One year is the average length of time from planning to testing. It costs 30% to 50% more to develop standard components than to develop usual software modules. This extra cost is attributable to the requirements for more flexible design, more detailed documentation, and more thorough testing. These requirements come from the fact that the standard components have to be designed prior to their actual usage. The usage ratio of components can be more than 60% if similar products have been developed before and the standard components are developed based on that experience. The critical number of usage frequency is between three and five. If the standard components are used more than this number on the average, the development cost will be covered.
4. Reuse of application
architecture
Now that Japanese mainframers have succeeded in reusing program code and design, they are trying to reuse software
168
S. Isodallnformation and Software Technology 38 (19%) 165-I 71
architectures, which are more abstract logical entities than design. An application architecture is the common structure of application programs in a certain domain. We can reuse an application architecture as a basis for requirements specifications. That is, for each application development we select an appropriate application architecture, identify differences between what is required for the system to be developed and the application architecture, and then customize the application architecture to obtain the requirements specifications of the system to be developed. This will help reduce defects of the specifications, allowing the reuse of more domain-specific and large components in the design. That is, by reusing application architecture, we can: . make requirement analysis efficient; . make more reliable specifications; and . maximize software reuse of program code and design. The most advanced domain in terms of the reuse of application architectures is business applications, which are to computerize miscellaneous activities in corporations, such as accounting, personnel, payroll, inventory, and order entry. This is because the applications for these business activities are very similar among corporations and in great demand. Application architectures are constructed usually by analysing many existing programs, extracting those features that are common among them, and then integrating them to form a standard architecture (or top level design) that are applicable to most applications in the target domain. This activity is often called the domain analysis. Application architectures are reused by way of system requirements analysis. That is, when we have an application to be developed, we select an application architecture that is most similar to the application, analyse the difference between it and the user’s requirements, and then customize it to suit the user’s requirements. Fujitsu’s approach to constructing application architectures is to analyse an existing business package [ 121. Application packages are generally designed to suit the requirements of users as much as possible by parametrizing those features that can vary depending on users requirements. The parameters are to be replaced with certain values when the package is installed. However, parametrization of packages is not always applicable. It well applies to those existing domains that are prescribed in detail by the tradition, law and regulations and standards, or ad hoc ones of the business area, because users will not have much freedom in choosing features. It will not be applicable, however, to those new domains that have fewer regulations and restrictions because the differences among users’ requirements are too broad to be covered by parametrization. If we should apply a business package to the latter domain and want to meet the specific requirements of users, we have to change its code, thereby almost losing the merit of the package.
Fujitsu has been selling packages together with customization service. The problem with this business is that it takes a considerable effort to customize a package for each customer. For example, it took 30 man-months to customize a production management package on ‘office computers’ or small-scale mainframes for medium-sized manufacturers, consisting of 500 COBOL programs. This large cost triggered them to think of reusing application architectures for package customization. Fujitsu’s approach for constructing application architectures is to analyse packages in the reverse way, in a sense to extract the fundamental mechanisms and business rules contained in the packages and then to reconstruct a standard architecture. They analysed the package, got information from the developers of the package and also from the system engineers who had customized it. They spent three months on this stage. Then they experimented reusing the architecture for the system analysis Qf a typical application system. Three system analysts and two people representing the customer participated in the experiment. It turned out that the job was completed in only four days, while the conventional method without using any model architectures took 35 days. A standard representation schema is required for modelling the application architecture. Fujitsu prescribed a standard representation schema for modelling the three different aspects of the business, namely function, control and data. The scheme consists of 22 different charts and tables such as business function structure graphs, business transaction flows, and business transaction file tables. The size of the final documentation amounted to several hundred pages for the case mentioned above. Encouraged by this favourable result, Fujitsu developed a methodology and its associated CASE tool, called AA/BRmodeller (Application Architecture/Business Rule Modelling). They are now energetically introducing it to their software developments. Their plan was to introduce it to as many as 200 projects by the end of March 1995.
5. Managerial
aspect of software reuse
When it is performed by an individual or a small group, software reuse is an easy task as it has been performed by experienced software engineers since just after software was born. They have their own reusable entities in their own file directories, or they customize existing software they themselves developed to make new versions. However, when it is to be performed by many people in an organization, the situation changes completely. There appear many factors that hinder software reuse. These are managerial factors, including organizational, people, and economical factors. The importance of managerial factors of software reuse is now being understood by those who have not been involved in software reuse as well as by those who have.
S. IsodalInformation and Sofware
NTT Software Laboratories have performed an organizational software reuse project which lasted for four years, involving as many as 600 engineers [ 131 . The object for reuse was program code modules, and the target domain was the software development support tools, which is different from the usually reported COBOL business applications. Over the four years, they observed a growth in some important aspects of software reuse, including the reuse ratio, reused component size, origin of reused components, and usage of the library. Z&e average reuse ratio. The average reuse ratio increased each year, beginning at 3% in the first year, and then gradually increasing to 16% in the fourth year. It seemed, however, to saturate at around 20%. EJre average size of reused components. The average size of reused components went up each year. In the fourth year, the average size of reused components was about 600 lines of code, which was about twice that of the second year. This is very important because reusing larger components is an effective way to attain higher reuse ratios. 7?re origin of the reused components. The software development projects increasingly used more and more components deposited by other projects. In the second year, the ratio was about lo%, but in the fourth year it increased to as much as 70%. The ratio of components retrieved from the library was 100% in the fourth year. This meant that all the reused components came from the library. 77re usage of the library. The average reuse frequency is defined as the ratio of the total count of component reuses in a year to the number of components stored in the library. The average reuse frequency increased each year, beginning at 0.18 in second year and increasing to 0.28 in the fourth year. 7&e active component ratio. The active component ratio is defined as the ratio of components reused at least once each year to the number of components stored in the library. The active component ratio stayed almost stationary, at about 0.2. This low ratio suggested that not a small portion of the library might be just a junk and some way of screening was required. They report that the reuse project proceeded but not without impediments. Some people actively worked, some followed the leaders reluctantly, and others made little contribution. The issues impeding software reuse can be grouped into the following three categories:
Technology 38 (19%) 165-I 71
(f) jobs could be done without software reuse. (3) Psychological issues (g) reluctant because of unpredictable benefits; (h) repulsion to top-down activities. The first impediment, or inadequate library, was the biggest problem because what can be reused must be available prior to its use. If there is no component library containing enough components, reuse cannot happen easily. However, construction of even a modest library is very difficult because a large initial investment is required. The third and fourth issues imply that the organization was not well designed to encourage software reuse, but rather to hinder its progress. It is necessary to supply project managers with enough resources to consider reuse during their software development and also to educate software engineers about the importance of software reuse. Some incentive system would be effective to trigger a cultural change in an organization. The fifth impediment is caused by contracts specifying payment by LOC or effort. The solution to this problem is to change the contract so as to consider the productivity improvement by contract developers. The sixth means that whether to apply software reuse or not is usually up to the software engineers and the project manager because the internal design is hidden from outside. Unless they find their own benefit from applying software reuse to their development project, they will not perform reuse of their own free will. The seventh and eighth are psychological issues. The only way to solve these impediments is to make a persistent effort to change the organizational culture so that project managers and software engineers are willing to cooperate for the benefit of the organization. They claim that these impediments originate from the essential nature of software reuse, i.e. (a) software reuse is against individual’s natural conduct; and (b) software reuse is beyond individual’s capability. That is, individual software engineers and project managers do not want to make the effort to start software reuse, and cannot do so if they remain in the conventional way of management. Therefore, software reuse is inherently a managerial issue [ 51 . Based on the experience, NTT Software Laboratories conclude that the success and failure of organizational software reuse are greatly influenced by its managerial aspects, and that the key factors for success are:
(1) Selection (1) Reuse library issues (a) inadequate library; (b) component functionality and reliability are not understood. (2) Organizational issues (c) no additional resource to consider reuse during development; (d) no direct benefit to component developers; (e) no benefit to contract developers;
169
of an appropriate domain that has many similar programs to be developed. This ensures existence of common and frequent functionalities. (2) Systematic development of reusable components based on domain analysis. This ensures easier acquisition of large and highly reusable components. commitment. This ensures the (3) Senior management managerial problems to be solved. (4) Several years’ continuous effort to do these three items 1141.
S. Isodallnformation and Software Technology 38 (19%) 165-I 71
170
5. Technology
transfer
Technology transfer is one of the major issues in the managerial aspects. Japanese mainframers are generally believed to be advanced in software reuse, but it is rather unlikely that every one of their software developing departments is enjoying high reusability. A more probable picture might be that there are some which are successful with software reuse, but for several reasons the majority are reluctant to apply it. Toshiba is one of the forerunners of software reuse in Japan. Their Fuchu Factory made a great success in applying the library-based software reuse to their process control software in the early 1980s. However, as Toshiba is a large organization, covering from large-scale information processing systems and process control systems to electrical appliances, not every department is applying software reuse. Their System and Software Engineering Laboratory, which is responsible for developing software reuse methodology and tools, has developed an educational course on software reuse targeting at managers and senior engineers. They hope the course will facilitate the transfer of their developed technology in their company. The course lasts two days, consisting of lectures, hands-on exercises, and discussion. The subjects are the fundamentals of software reuse, reuse-oriented software development, domain analysis for application families, managerial aspects of software reuse, and so forth. They hold courses not only at the central location but also at local development sites [ 151.
6. Independents Independent software houses are at a disadvantage with software reuse because they have to work in various domains and on several platforms in compliance with their customers’ needs, and this is liable to discourage them from accumulating reusable components. In spite of all these adverse factors, there are several companies who have been continuing persistent efforts with software reuse. Nippon Novel is a small software house with about 100 software engineers, developing versatile kinds of software including measuring, process controlling, CAD/CAM, communications, and factory automation. Since 1987, they have been performing a software reuse program steadily [ 161. Their success is proved by the increase in the total reuse size per year, the average size of reused components, and the average size of registered components. What is interesting with Nippon Novel is that they employ a very materialistic incentive system, without putting obligations of any kind to the engineers. They give cash to the software engineers on a line-of-code (LOC) basis. The rate is five cents per LOC when registering a component, and, when reusing a component, five cents per LOC for the reuser and one cent per LOC for the developer of the component. The total amount of the incentive money
last year accumulated to about $8,000. The incentive money is paid quarterly every year. The best engineers of the year in each of the three categories are also awarded. The most frequently reused component is 3000 LOC of size and has been reused 40 times. Some statistics of 1992 are as follows: 16 components were registered, 59 components were reused. The average size of the registered components is 1.5 thousand LOC. The average size of the reused components is 1.4 thousand LOC. The average reuse ratio is 10% to 15%. They claim that their success in software reuse could not have been realized without this incentive system.
7. Conclusion
This paper outlines the current status of the research and practice of software reuse in Japanese industries and research organizations. Software reuse in Japan has been mainly carried on by mainframers as a means to develop effectively their business applications. Now that Japanese mainframers have succeeded in reusing program code and design, they are trying to broaden the target of reuse to include the software architecture. The importance of the managerial aspect of software reuse is now being understood. Some companies are putting much stress on the technology transfer issue of software reuse, and others are applying incentive systems to encourage engineers who participate in software development. As Cusumano reports, software reuse is one of the distinguishing features of Japanese software development [ 171. The idea of software reuse is never a Japanese-made technology, but they have continuously improved it to completion. One of the reasons for the Japanese success with software reuse is that the i&erent nature of software reuse is well in accordance with the Japanese tendency of groupism and gradualism. That is, software reuse requires collaboration of individuals who work for the whole and continuous kaizen of several years. The so-called not-invented-here syndrome, which American researchers often cite as a reason why people do not like software reuse, is not so evident in Japan. People seem to have less reluctance to use somebody else’s program code. This may be another symptom of Japanese tendency to groupism and gradualism. All the software reuse cases sketched in this paper are publicly reported in journals, magazines and at symposiums. These cases may be just an outline of the leading edge of the research and practice on software reuse in Japan. It is therefore hard to deny that ad hoc software reuse might be prevailing in most organizations. However, by seeing the fact that there is a sharp increase in the number of symposiums and research papers on software reuse, we can expect that the average level of software reuse will continue to go up.
S. Isodallnformarion
and Sofiware
Technology 38 (19%) 165-I 71
References [ I] M D McIlroy ‘Mass produced software components’,
1969 NATO Conf on Sofr. Eng. (1969) pp 88-98 [2] IEEE ‘Special issue on software reusability’, IEEE Trans. SOB. Eng. Vol SE-IO No 5 (1984) [3] IEEE ‘Special issue on software reusability’, IEEE Sof. Vol 4 No 2 (1987) [4] P Freeman, Tutorial: Sofrware Reusability IEEE Computer Society Press (1987) [ 51 W Tracz, Tutorial: So&are Reuse: Emerging Technology IEEE Computer Society Press (1988) [ 61 R Prieto-Diaz, et al. The First lnternafional Workshop on So&are Reusability University of Dortmund, Dortmund, Germany (1991a) [ 71 R Prieto-Diaz and W B Frakes, Advances in Software ReuseSelected Papers from the Second International Workshop of Sofrware Reusabiliry IEEE Computer Society Press (1993) [8] W B Frakes, (ed) The Third International Conference on Software Reuse IEEE Computer Society Press (1994) [9] M Tsuda, et al. ‘Productivity analysis of software development with an integrated CASE tool’, 15rh Int. Conf on Soft. Eng. (May 1992) pp 49-58. [lo] M Tsuda, ‘Evolution of software reuse technology’, Symposium on
[ 111
[ 121 [ 131
[ 141 [ 151
[ 161
[ 171
171
Software Tools, Japan Information Service Association (1994) pp 99-102 (In Japanese) K Matsumura, ‘A software reuse case study based on a standard library approach’, in Software Modeling and Software Reuse Kyoritsu Shuppan (1995) pp 62-83 (In Japanese) A Yoshioka and K Hashimoto, ‘A practice in reuse of business model’, Symposium on Sofware Reusability Information Processing Society of Japan (1992) pp 11-17 (In Japanese) S Isoda, ‘Experience report of software reuse reuse project: its structure, activities, and statistical results’, 15th Znt. Conj on So@. Eng. (May 1992) pp 320-326. R Prieto-Diaz, ‘Making software reuse work: an implementation model’, ACM SIGSOFT Sofr. Eng. Nores Vol 16 No 3 (1991) pp 61-68 N Munechika and K Matsumura, ‘Development of education course on software reusability’, Symposium on Sofrware Reusability, Information Processing Society of Japan (1992) pp 33-41 (In Japanese) M Kikumoto, ‘Report on an organized software reuse project’, in Sofware Modelling and Software Reuse Kyoritsu Shuppan (1995) pp 47-61 (In Japanese) M A Cusumano, Japan’s Soffware Facfories Oxford University Press (1991)