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 / martin.detex < prev    next >
Text File  |  1992-04-05  |  14KB  |  382 lines

  1.  [12pt] article 
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.   Software Reuse Across Continents 
  11.  
  12.   Roland Martin 
  13.        Hewlett-Packard GmbH
  14.        Waldbronn Analytical Division 
  15.        Hewlett-Packard Str. 
  16.        D7517 Waldbronn, Germany 
  17.        email: rmartin@hpwadrd.wad.hp.com 
  18.         
  19.        Gary Jackoway 
  20.        Hewlett-Packard Co.
  21.        Avondale Division 
  22.        P.O. Box 900 
  23.        Avondale PA. 19311 
  24.        email: gary@avo.hp.com 
  25.         
  26.        Charu Ranganathan 
  27.        Hewlett-Packard Co.
  28.        Scientific Instrument Division 
  29.        1601 California Avenue 
  30.        Palo Alto, CA. 94304 
  31.        email: cr@sid.hp.com  
  32.  
  33.    
  34.  
  35.  
  36.   
  37.   The Analytical Products Group of Hewlett-Packard Co. is practicing
  38. software reuse at its three sites, located in the US and Europe.
  39. This paper describes the organization, goals, processes and results of a
  40. reuse program. Data from two example projects illustrate the approach.
  41. Lessons learned from these and other examples, as well as key factors
  42. for economic success, are presented.
  43.  
  44.   0.3in 
  45.  
  46.    Keywords:  software reuse, reuse without modification, 
  47. component library, economics
  48.  
  49.  
  50.  
  51.  
  52.   Introduction 
  53.  
  54. Hewlett-Packard (HP) Analytical Product Group (APG) supplies 
  55. instrumentation, software
  56. and systems  for a wide range of analytical techniques including Gas 
  57. Chromatography, Liquid
  58. Chromatography, Mass Spectrometry, Spectrophotometry and Automated Sample 
  59. Preparation.
  60.  
  61. Single-user workstations
  62. and multi-user data systems with software for instrument control, data analysis,
  63. automation
  64. and information management are essential elements of APG's business.
  65.  
  66. APG has divisions at Palo Alto, CA., Avondale, PA. and Waldbronn, Germany. Each
  67. site
  68. has worldwide business responsibilty for a subset of above techniques, and does
  69. research and
  70. development (R+D) for instrumentation and software for their business segments.
  71.  
  72. Sharing of software workproducts across APG organizations began as early as 1982
  73.  with
  74. voluntary design for reuse and cooperative efforts among design teams. 
  75. APG's motivation for practicing reuse has two major elements:
  76.  
  77. 1. Enhance value to customers through consistency and compatibility across 
  78. products
  79.  
  80. 2. Improve productivity  by reducing redundant development efforts
  81.  
  82. In late 1988, the first author was assigned to further stimulate and lead these
  83. reuse activities
  84. with small project teams at all three sites funded by and reporting to the 
  85. APG R+D manager.
  86.  
  87. Activities include improving the infrastructure for multi-site reuse, 
  88. identification of workproducts for reuse,
  89. re-engineering existing workproducts for reuse, 
  90. new designs for reuse,
  91. consultation to projects designing with reuse, and maintenance of reusable 
  92. and reused workproducts.
  93.  
  94. Activities are organized in a multi-site program, i.e. a set of related 
  95. and coordinated, but
  96. independently managed projects.
  97.  
  98.    Reuse Program Outline 
  99.  
  100. The mission of this multi-site reuse program is to create a set of 
  101. software components for
  102. reuse without modification in APG products. A subset of these
  103. components is designed for multiple platforms (i.e. hardware and operating
  104. system), others are
  105. specifically designed for one platform. APG software products are developed for
  106. HP-UX/X-Window, MS-DOS/MS-Windows, and firmware platforms.
  107.  
  108. Reusable components are expected to meet the following criteria:
  109.  
  110. * Functionality is generic within our domain: meet the need of at least
  111. three products.
  112.  
  113. * Platform dependencies are isolated.
  114.  
  115. * Internal elements, in particular data structures, are hidden through 
  116. encapsulation.
  117.  
  118.  
  119. Workproducts and services other than just code are essential to facilitate
  120. reuse across platforms, products and organizations. The following items are
  121. provided together with reusable components:
  122.  
  123. * Documentation: Specifications, Application Programmer's Interface, 
  124. Installation Guide.
  125.  
  126. * Test suites at component level for quality control independent of an
  127. application.
  128.  
  129. * An example application.
  130.  
  131. * Consultation to consumers.
  132.  
  133. * Commitment for maintainance over several years of component lifetime.
  134.  
  135.  
  136. The content of a reusable component is very similar to that of a software
  137. product. The same is true for its development process, i.e. the component 
  138. life cycle.
  139. We are using a scaled down software product life cycle to create and maintain
  140. software components. A panel of R+D section managers from all three sites 
  141. chaired
  142. by the  program manager reviews the projects and approves phase transitions.
  143. This panel holds telephone or video conferences every two week for this 
  144. purpose.
  145. A council consisting of all APG R+D Managers meets
  146. three times per year and provides strategic
  147. guidance and funding for the reuse program.
  148.  
  149.    Results 
  150.  
  151. The program started in 1989 and produced an asset of about 50 000 lines of
  152. code plus the additional workproducts for reuse without modification in multiple
  153. software products. This asset covers more than 10 percent of the lines of 
  154. code released
  155. with APG software products. With the currently active producer and 
  156. consumer projects we
  157. expect to increase the asset to near 150 000 lines covering more than
  158. 30 percent of the code shipped with APG software products.
  159. On average each component is reused in 4 products.
  160.  
  161.    Examples 
  162.  
  163.    Signal Processing Algorithms 
  164. A set of signal processing algorithms to calculate quantitative information from
  165. chromatograms was created in the early 1980's in Pascal. It was carefully 
  166. designed
  167. for portability. Several software products made use of this library.
  168. The creator was reassigned to other projects after completion.
  169. The library was subsequently ported to new operating systems by product 
  170. development
  171. teams and adapted to other analytical techniques. This resulted in six different
  172. versions with subtle differences. Once a defect was found in one of the 
  173. versions,
  174. it was a challenge to verify and fix all others.
  175.  
  176. Another effect was observed: the code size grew with each port or adaption.
  177. The biggest growth in code size came during a port from Pascal to C using
  178. a translator program. The original 3 kNCSS grew to 9 kNCSS, essentially without
  179. any additional functionality.
  180.  
  181. The first project within the components program was set up to re-engineer this
  182. library for strict black box reuse in all software products.
  183.  
  184. The result: size is down to 5 kNCSS, speed improved by a factor of two.
  185.  
  186. The project took about one year for two engineers (one of them the original 
  187. creator).
  188. This effort included a detailed assessment of the requirements of all
  189. potential consumer projects and the creation of an extensive test suite 
  190. with test cases
  191. from all analytical techniques which need this type of algorithm.
  192.  
  193. After release of this component, four products on two platforms replaced their
  194. individual versions with this one common stream of code. More products are under
  195. development using the same source without modification.
  196.  
  197. Meanwhile, the component development team added new capabilies to the 
  198. library and
  199. is responsible for all maintenance activities for this component.
  200.  
  201.  
  202.    Command Processor 
  203.  
  204. Like the first example, the command processor (CP) concept was created in
  205. early 1980's. It started as a mechanism to coordinate a collection of
  206. small programs and evolved into a language interpreter.
  207. During this evolution process the CP concept was adopted by the majority
  208. of APG R+D teams and became a key element for the
  209. architecture of APG's software products and systems. The development teams
  210. adapted code from other projects to fit the requirements of their product.
  211.  
  212. Different from the algorithm example, the perceived needs for CP 
  213. capabilities
  214. are significantly different from project to project. Over time, projects
  215. teamed up and shared the same code for a few product releases but afterwards
  216. felt the pressure to implement those extensions that were most important for
  217. their product's customers. The extent of adaption ranged from small enhancements
  218. to almost complete re-writes. In the late 1980's we found ourselves
  219. with around a dozen sets of CP code.
  220. All versions do support the same core capabilities but with small,
  221. sometimes annoying differences.
  222.  
  223. It was impractical to create one single set of code for Unix and DOS.
  224. For each environment one version was identified for re-engineering.
  225. The core capabilities were identified and described in a rigid syntax guide.
  226. Product-specific elements were eliminated from the core. Mechanisms
  227. were designed and implemented that allow addition of product-specific 
  228. capabilities
  229. without modifying the core source code.
  230.  
  231. Both versions of the CP library are currently in the test phase and each have
  232. delivered pre-release versions to two consumer projects. More project teams
  233. plan to use the same code without modification.
  234. An essential
  235. shared deliverable is one common validation suite to check compliance with
  236. the syntax guide mentioned above.
  237.  
  238. Size of both libraries is about 20 kNCSS.
  239. We spent about two person years for each of the two libraries.
  240. This included the creation of the syntax guide and a
  241. validation suite shared between the two.
  242.  
  243. The CP teams will continue to enhance and maintain the two components
  244. for a growing number of consumer products.
  245.  
  246.    Other Reuse Activities 
  247.  
  248. Ten other software component libraries of similar nature and size covering
  249. other funtions needed by three or more APG projects are in progress and 
  250. could have
  251. served as examples as well. Some of them are new designs, others do
  252. re-engineering of existing functions. Many of them are sponsored and funded
  253. by APG divisions and complement those funded by Group R+D.
  254.  
  255.  
  256.    Some Lessons We Learned 
  257.  
  258. From the above examples our organization learned a few lessons, including:
  259.  
  260.  
  261. 1. White-box reuse (i.e. reuse with modification) has marginal economic 
  262. benefits.
  263.  
  264. 2. Black-box reuse (i.e. reuse without modification) help us to achieve 
  265. our goals, i.e. (a) to achieve consistency across products and (b) to
  266. reduce redundant development and maintenance efforts.
  267. However, it requires sustained attention
  268. over the full life cycle of components and products using these components.
  269.  
  270. 3. Unsustained black-box reuse degenerates within 2 years.
  271.  
  272. 4. Voluntary and cooperative reuse efforts do not last in a tough business
  273. environment. Management support and some organizational structure is 
  274. necessary to sustain reuse.
  275.  
  276.    Key Success Factors 
  277.  
  278.    Products 
  279. APG products cover a diverse range of analytical techniques, but share many
  280. functions, not only in software, but also in hardware.
  281. Identifiction of these commonalities is rather obvious.
  282. End users strongly demand consistency across products for
  283. these common functions.
  284.  
  285.    Culture 
  286. During years of steady growth, APG built a strong base of experienced people.
  287. Best practices are exchanged among teams worldwide through formal and
  288. informal channels.
  289. This exchange of best practices results for example in:
  290.  
  291. * One product development life cycle is practiced by all teams
  292.  
  293. * The same operating systems are used by all new products
  294.  
  295. * All new code is developed in C.
  296.  
  297. * Reasonably consistent software development tools exist at all sites.
  298.  
  299.  
  300.    Management Support 
  301. Upper management supports and expects reuse and allows for
  302. the necessary investment within reasonable constraints.
  303. Significant effort has been spent, and will be necessary in the future to
  304. provide the environment for reuse across projects, organizations and
  305. continents, including:
  306.  
  307. * Communication tools (telephone and video conferencing, fax)
  308.  
  309. * Common development tools
  310.  
  311. * Global controlled access to reused workproducts
  312.  
  313. * Defect tracking for components
  314.  
  315. * Keeping track of who is using what (configuration management)
  316.  
  317. * Common business goals for the participants of a reuse program
  318.  
  319. * Consensus on technical concepts (architecture, user interface style)
  320.  
  321. * Compatible ways of doing things (processes)
  322.  
  323. * Validation of compatibility
  324.  
  325.  
  326.    People 
  327. Definitely the most important factor for the success of a reuse program
  328. are good working relationships among qualified,
  329. dedicated and experienced people in all roles and levels.
  330.  
  331. No technology can compensate for the lack of this key factor. 
  332.  
  333. Unfortunately
  334. we cannot give a simple recipe for achieving this. 
  335. Regular face-to-face meetings
  336. between the key people are definitely important to build and maintain such
  337. relationships. We have experienced some difficulties in our program whenever
  338. more than two months passed without personal contacts between two
  339. project teams.
  340.  
  341.  
  342.  
  343.    Conclusions 
  344.  
  345. Software reuse is more than just creating and/or obtaining workproducts for/from
  346. a public domain. In order to get economic benefits, it requires upfront investment
  347. and sustained effort. More than any particular technology, the consensus
  348. between producers and consumers of reusable workproducts is essential for success.
  349.  
  350. Hewlett-Packard Analytical Products Group (APG) has made a two year
  351. investment in software reuse and is beginning to see economic benefit from this
  352. program. We are prepared to sustain that effort.
  353.  
  354.    Biography 
  355. Roland Martin, born 1946 is managing the APG reuse program. He holds a Ing.(grad)
  356. degree in electrical engineering from Fachhochschule fuer Technik, Esslingen, Germany.
  357. He joined HP's Boeblingen division in 1969 and relocated to the newly
  358. created Waldbronn Analytical Division in 1975. His past assignments included
  359. production engineer, starting up a PC board test facility, design of hardware,
  360. firmware and software for liquid chromatography, project- and section manager.
  361. He is single, lives 5 minutes from work in a small village
  362. at the edge of the black forest. Between his
  363. frequent trips to the US, he tries to keep his skills as a glider pilot
  364. up to date.
  365.  
  366. Gary Jackoway, is an R+D software engineer.  He holds a Master's degree in
  367. Computer Science from Duke University, and a Bachelor's degree in Mathematical
  368. Sciences from Stanford University.  Before joining Avondale Division, Gary
  369. worked on automatic routing and placing algorithms for printed circuit
  370. board design.  Gary is an avid volleyball player, and a contract bridge
  371. Life Master.
  372.  
  373. Charu Ranganathan has been a software engineer at Scientific Instuments Division
  374. of Hewlett-Packard (Palo Alto) for the past 2 1/2 years.
  375. She is currently working on the Command Processor and will continue to be 
  376. part of the reuse program at HP. She holds a BS in Computer Science from 
  377. Bangalore University, Bangalore, India and an MS in Computer Science from 
  378. University of South Western Louisiana, Lafayette, LA. She is an Indian
  379. classical musician (vocalist) and is interested in painting/sketching.
  380.  
  381.  
  382.