home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr4 / proceedings / detex / joos.detex < prev    next >
Text File  |  1992-04-05  |  13KB  |  244 lines

  1.  [12pt] article  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.    Software Reuse in an Industrial Environment 
  13.  
  14.    Rebecca Joos, Ph.D. 
  15. Motorola, Inc. 
  16. 6501 William Cannon Drive 
  17. Austin, Texas 78735  
  18. 512/891-3617 
  19.  
  20. beckyj@oakhill.sps.mot.com 
  21.  
  22.    
  23.  
  24.  
  25.  
  26.  
  27.   
  28. When trying to establish software reuse in an industrial environment, many roadblocks occur 
  29. beyond the normal problems of just reusing software. For example, in a hardware oriented company, 
  30. reuse is accepted as a normal part of doing business; however, hardware reuse is different than 
  31. software reuse and the engineers and their management must be introduced to the software 
  32. concepts. Software reuse has been introduced and discussed at every level within Motorola from the 
  33. CEO to the software engineers. Subject matter experts have been employed, task forces have been 
  34. formed, and educational programs have been initiated. This position paper briefly describes the 
  35. initiation and development of a software reuse program at Motorola, Inc. and what activities are 
  36. being implemented to achieve successful software reuse.
  37.  
  38.   0.3in 
  39.  
  40.    Keywords : reuse organization, reuse roles, reuse process 
  41.  
  42.  
  43.   Initial Effort 
  44. A coordinated effort to establish a software reuse program in Motorola began with the CEO 
  45. requesting that a Reuse Task Force be formed to investigate and make recommendations about 
  46. software reuse for Motorola. Task force members included a leading technician from each section of 
  47. the company and a Corporate subject matter expert (the author). The task force considered the 
  48. need and requirements for reuse organizational issues, education, methods, technology, and 
  49. implementation. The task force's conclusions fell into 4 general categories: education, motivation, 
  50. organization, and technology. 
  51.  
  52. The educational recommendations briefly outlined the need for a strong software engineering 
  53. base that will be provided by Motorola University. Additionally, training courses for engineers 
  54. and management specifically targeted at the skills and techniques required for effective software 
  55. reuse. The set of motivation recommendations emphasized a career path, job descriptions, 
  56. metrics, and rewards. The organizational recommendations revolve around the need for each group 
  57. within Motorola to establish a reuse program. Also provided are the allocation of responsibilities 
  58. for the Software Engineering Steering Committee, and its subcommittees, the individual reuse 
  59. programs, and the corporate functions. Technology recommendations discussed issues such as the 
  60. need for specific software development processes, which reuse approach to employ, the 
  61. development of standards, the requirements for tools,  and finally the issues of research both within 
  62. Motorola and at outside institutions.
  63.  
  64. The task force recommended approaching reuse from two perspectives.   One approach is design 
  65. recovery and subsequent re-engineering which enables software engineers to recover reusable 
  66. components from existing requirements, design, code, etc. and populate the reuse databases.   The 
  67. second approach is forward engineering (or design) for reuse where special efforts are taken to 
  68. make newly developed software reusable. 
  69.  
  70. Based on this information, the CEO recommended to the business groups that they pursue a 
  71. software reuse practice. It is the Motorola culture that major changes are driven bottom-up i.e., from 
  72. the production engineers rather than filtered from the top down. Although the group has CEO 
  73. support, there is no corporate mandate thus the software engineers in the business units are the 
  74. driving force of the company program. In other words, Motorola's reuse program is being introduced 
  75. and implemented at the software engineering level. 
  76.  
  77.  
  78.   Commitment and Support 
  79.  
  80. One point that is continually stressed is: to be successful software reuse must be a long term 
  81. commitment. In order to make software reuse successful it must become an integral part of the 
  82. software development process. Software engineers must design with and for reuse. Rather than trying 
  83. to find a reusable component that matches a design module at the coding phase of the software life 
  84. cycle, software engineers should look for reusable components at the specification phase and 
  85. continue the process through the analysis, design, coding, and testing phases. All experiences from 
  86. concepts to algorithms involved with the software development should be captured for future 
  87. reference i.e., reuse.
  88.  
  89. Software engineers must be taught formal reuse techniques and management must support them 
  90. completely. Successful software reuse is dependent upon the support from all levels of the 
  91. production staff (from senior management to software engineers) and the realization that a great deal 
  92. of intellectual capital, real capital, and time must be invested before reuse begins to pay off 
  93. significantly.
  94.  
  95.  
  96.   Reuse Working Group 
  97.  
  98. To foster the necessary commitment and facilitate software reuse at Motorola, the Reuse Task 
  99. Force proposed a Reuse Working Group (RWG) whose main task is to provide the development 
  100. and subsequent communication of reuse guidelines/standards to software engineers and their 
  101. management.
  102.  
  103. In general terms the charter of the Reuse Working Group is to implement guidelines and 
  104. recommended practices for software reuse within Motorola. As stated by the Reuse Task Force: "We 
  105. must determine an optimal reuse process and control it via the use of metrics. We must allow for 
  106. the knowledge gained in one area to be available to the developer who needs it in another. We 
  107. must develop a paradigm for development that formally makes use of what we already know - we 
  108. must FORMALLY REUSE." These high level abstract goals are being expanded into a detailed 
  109. process by the RWG.
  110.  
  111. The RWG consists of a group of engineers who are working together to develop a best-in-class 
  112. reuse program. The group must represent all of the Motorola software community. Each member of 
  113. the RWG has become the reuse champion for his/her location and targeted projects for potential 
  114. reuse. Thus the reuse program at Motorola is a bottom-up implementation. Cooperation, 
  115. coordination, and communication are the three most important elements in the group. 
  116.  
  117. The RWG's primary interests are education, guidelines, technology, and implementation of 
  118. software reuse at Motorola. However, the group has determined that education is the most important 
  119. activity and without it the others will not come to fruition. Therefore, the group has dedicated its 
  120. initial efforts to the indoctrination and training of software engineers and their management. The 
  121. RWG is facilitating this through an aggressive seminar and workshop program for software reuse.
  122.  
  123. Seminars are a quick way to introduce people to the basics of reuse. The informal seminars are 
  124. being used to establish common terminology and definitions, and to discuss the concepts of a reuse 
  125. organization and what part it will play in software development. Once Motorola has reached a 
  126. consistent level of reuse knowledge, seminars will become a forum for external reuse experts and 
  127. researchers.
  128.  
  129. Training workshops provide instruction on the development and use of reusable components and 
  130. the operation of the reuse organization. There will be a series of training workshops: object-
  131. oriented design, reuse for software engineers, and reuse for software engineering managers. The 
  132. group is developing workshops under the guidance of a subject matter expert(s). 
  133.  
  134.  
  135. Additionally, Motorola reuse conferences are being held in conjunction with other internal 
  136. software conferences (e.g.,the Object Oriented conference). 
  137.  
  138.  
  139.   Process 
  140.  
  141. Figure 1 is a model for the reuse process/organization that Motorola is developing. The key 
  142. concept is that there will be a support organization that takes the burden of finding, implementing, 
  143. and developing reusable components off the software engineers and placing it on reuse experts. 
  144. The support group provides help when needed. It is expected that as the software engineers 
  145. become more adept at reusing software they will need less and less help. Thus the support team's 
  146. responsibilities will shift to more development and maintenance.
  147.  
  148.  
  149.   Reuse Organization 
  150.  
  151. Because of the difficulty of reusing software components, each software development facility 
  152. should have a support organization that is responsible for software reuse. This organization can 
  153. range from one person (a champion of reuse) to a focus group to an entire department depending 
  154. upon the size and needs of the facility. 
  155.  
  156. The reuse organization is a support group that promotes the effective reuse of software in order to 
  157. improve the quality and lower cost of software development, integration, and maintenance. The 
  158. users of the department are the software engineers responsible for developing new product and 
  159. support software. 
  160.  
  161. In general the group implements and supports a set of reuse policies and procedures that not only 
  162. provides users with guidelines for the use of the reuse facilities, but also assures the quality of the 
  163. reusable components. The group is responsible for restructuring software designed by the project 
  164. software engineers into reusable components, and act as software architects for the users (i.e., 
  165. software engineers). Specifically the members are responsible for training and user support, 
  166. development and maintenance of reusable components, acquisition of reusable components, 
  167. acceptance and validation of all reusable components, self-evaluation and improvement, policy 
  168. definition, and maintaining and monitoring the library. This requires a knowledge of the domain 
  169. or domains and extensive software engineering expertise. The success of the reuse organization 
  170. is dependent upon the quality and stability of its members. 
  171.  
  172.   
  173.  
  174.    
  175.  
  176. There are three basic roles within the support group: reuse architect, reuse engineer, and 
  177. librarian. For a large reuse organization there may be more than one person assigned to each role. On 
  178. the other hand, in a small reuse organization one person may have responsibility for all roles. 
  179. Figure 2 lists the roles with their expertise, qualifications, and responsibilities.
  180.  
  181.  
  182.   Getting Started 
  183.  
  184. It became very apparent during the discussions of current activities that there are a lot of reuse 
  185. efforts throughout the company. By sharing information the groups have been able to benefit from 
  186. each others' experiences, failures and successes. To help facilitate reuse programs in the groups, 
  187. the RWG has proposed the following plan to software managers:
  188.  
  189.   
  190.  
  191. Find a champion (for reuse) for each role in the reuse organization (i.e., manager, reuse 
  192. engineer, reuse architect, and librarian). They must have strong software engineering backgrounds.
  193.  
  194. Provide the above personnel with reuse training (i.e., object-oriented analysis and design, 
  195. software reuse, and domain analysis).
  196.  
  197. Analyze the initial target domain.
  198.  
  199. The reuse working group should establish standards (templates, documentation,
  200. classification), and the department personnel should initiate.
  201.  
  202. Select and obtain state-of-the-art tools for the department.
  203.  
  204. Have the personnel become expert with the tools.
  205.  
  206. Populate a reuse repository.
  207.  
  208. Collect and record the baseline metrics data.
  209.  
  210. Start training other software engineers how to use the tools.
  211.  
  212. Begin designing all software with reuse and for reuse from day 1.
  213.  
  214. Provide incentives for reuse
  215.  
  216.  
  217. Currently, the RWG is concentrating on 2 and 3 with initial activities in the others. As the 
  218. individual reuse programs are maturing, the RWG is evaluating the reusable components for reuse 
  219. across the company. Despite the diverse nature of the software groups, there are already software 
  220. components that can be reused. As this collection expands the RWG proposes to establish a 
  221. corporate-wide repository of reusable components where components are knowledge, analysis, 
  222. designs, code, tests, etc.
  223.  
  224.   
  225.  
  226.    
  227.  
  228.  
  229.   About the Author 
  230.  
  231. Dr. Joos conducted her graduate studies at Texas A M University where she completed her 
  232. dissertation entitled "A Software Development Environment That Assists in the Use and Design of 
  233. Reusable Modules." Upon graduating Dr. Joos joined Motorola Corporate R D where she has 
  234. been instrumental in organizing a reuse initiative and program. In 1990, Dr. Joos became the 
  235. Motorola shareholder representative to MCC and moved to Austin where she pursued her interests in 
  236. reverse engineering and domain analysis tools while transferring MCC technology into Motorola 
  237. business units. Recently, Dr. Joos has joined the RISC software design group in Motorola's 
  238. Microprocessor and Memory Group. She is currently designing test suites and facilitating the quality 
  239. assurance program. She will also be initiating pilot programs for reverse engineering and domain 
  240. analysis to build reusable components for the group.
  241.  
  242.  
  243.  
  244.