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 / wisr6 / proceedings / ascii / matsumoto.ascii < prev    next >
Text File  |  1993-10-19  |  10KB  |  237 lines
  1.  
  2.  
  3.  
  4.  
  5. A  Nation-Wide  Evaluation  of  Software  Components  Reusability
  6.  
  7.  
  8.  
  9.                                             Masao J. Matsumoto
  10.  
  11.  
  12.  
  13.                                    C&C Software Development Group
  14.  
  15.                                                NEC Corporation
  16.  
  17.                                           Shibaura 2-11-5, Minato
  18.  
  19.                                                Tokyo 108 Japan
  20.  
  21.                                              Tel:  +81.1.5476.1090
  22.  
  23.                                             Fax: +81.1.5476.1095
  24.  
  25.                                    Email: matumoto@ccs.mt.nec.co.jp
  26.  
  27.  
  28.  
  29.                                                   Atsuko Ishida
  30.  
  31.  
  32.  
  33.                                 Institute of Advanced Business Systems
  34.  
  35.                                                   Hitachi, Ltd.
  36.  
  37.                                     890 Kashimada, Saiwai, Kawasaki
  38.  
  39.                                             Kanagawa 211 Japan
  40.  
  41.                                              Tel:  +81.44.549.1530
  42.  
  43.                                             Fax: +81.44.549.1528
  44.  
  45.                                      Email: ishida@iabs.hitachi.co.jp
  46.  
  47.  
  48.  
  49.                                                      Abstract
  50.  
  51.  
  52.        Much discipline is needed in order to enable software engineers to develop versatile reusable
  53.    components. There is need for a set of criteria which enable software builders to evaluate software
  54.    component reusability both quantitatively and qualitatively across domains. This position paper
  55.    describes the evaluation criteria, proposed methods, and related considerations, surveyed in a
  56.    study circle with participation from experts in both industry and academia.  However, since
  57.    reuse  disciplines  defined  through  this  time  survey  have  not  been  properly  verified, followup
  58.    studies are needed.
  59.  
  60.  
  61.    Keywords: Reusability evaluation criteria, Software quality characteristics, Reuse discipline.
  62.  
  63.  
  64.    Workshop Goals: Learn and exchange information on recent reuse research results.
  65.  
  66.  
  67.    Working Groups: Standard guidelines for reuse, Quantitative evaluation
  68.  
  69.  
  70.  
  71.                                                   Matsumoto- 1
  72.  
  73.  
  74. 1      Background
  75.  
  76.  
  77.  
  78. As a member of NEC's Software Engineering Central Group, M.J. Matsumoto has facilitated the
  79. development and exploitation of software reuse libraries in the management information systems
  80. domain.  He  has  undertaken  the  role  of  architect  in  the  development  of  a  software  engineering
  81. environment which integratesreuse supports for office server systems during 1980's.  As chair of
  82. numerous software quality research circles at the Japan Union of Scientists and Engineers, he has
  83. promoted several research thrust programs (including software reuse), attended by delegates from
  84. many leading industries and academia.  Ms.  A. Ishida from Hitachi Ltd.  has headed the software
  85. reuse-related study teams. These joint study activities provide not only an opportunity for members
  86. to have insight on reuse issues, butalso a chance to explore possibilities for forming a nation-wide
  87. consensus on the discipline of reuse engineering.
  88.  
  89.  
  90.  
  91. 2      Position
  92.  
  93.  
  94.  
  95. Not all reusable components are reused at the same frequency.  Some are very frequently reused,
  96. while the others somewhat less.  What does this mean?  For a given component,  no reuse for a
  97. certain time period means perhaps that the component does not have enough versatility, with the
  98. more frequently reused component having more versatility.  The reuse frequency is an index that
  99. can be used for evaluating the value ofa reusable component, though the frequency itself does not
  100. mean the amount of money savings whichthe reuser can obtain at each reuse time.
  101.  
  102.  
  103. If it is true that each component has its own reuse frequency, where does this frequency come from?
  104. Is it inherent to the component itself or to the characteristics of the reusers?  Not enough surveys
  105. have been made for making judgements on what the ma jor factors are thataffect this frequency
  106. distribution.
  107.  
  108.  
  109. There seem to be several factors which prevent software engineers from reusing software compo-
  110. nents, some  of  a  managerial  and  some  of  a  technical  nature.  The  technical  factors  must  be  at
  111. least three-fold: factors pertaining to the component itself, factors pertaining to the reusers of the
  112. component, and factors pertaining to the environment in which the component is reused. This time
  113. survey focused on the component factor, while the other factors need further preliminary investi-
  114. gation before surveys can be started. The primary aim of this time survey was to find relationships
  115. between characteristics and reusability(reuse frequency) for a given component.
  116.  
  117.  
  118.  
  119. 3      Comparison
  120.  
  121.  
  122.  
  123. 3.1     Evaluation Criteria
  124.  
  125.  
  126.  
  127. There are few well-defined sets of criteria for evaluating software component reusability that have
  128. been commonly agreed upon in the reuse community.  One possible set could be the 21 character-
  129. istics defined in ISO/IEC 9126 Annex A [1]. This set was originaly defined for evaluating software
  130. quality from viewpoints such as functionality, reliability, usability, efficiency, maintainability and
  131. portability. Since the ISO 9126 is a criteria which is used for evaluating software quality, it should
  132. be helpful for finding relationships between the reusabilityof given components when reviewed from
  133. the viewpoint of quality. This is the hypothesis we have taken as our position.
  134.  
  135.  
  136.  
  137.                                                       Matsumoto- 2
  138.  
  139.  
  140.        HO: The ISO 9126 could be used as a criterion for evaluating the reusability of software
  141.        components.
  142.  
  143.  
  144.  
  145. The REBOOT criteria for software reusability might be another candidate which could be used for
  146. this evaluation purpose [2].  Metrics defined in the REBOOT might be of help in measuring each
  147. criterion quantitatively.  The REBOOT criteria, however, have not yet widely been recognized as
  148. standards at the international level.
  149.  
  150.  
  151.  
  152. 3.2     Proposed Method to Quantify Reusability
  153.  
  154.  
  155.  
  156. A set of reusable components was carefully examined, each component of which was reused fre-
  157. quently and with considerably high reputation. 21 components were sampled from this set.  Another
  158. set of seldomly reused "reusable" components was examined, and five components were sampled
  159. from  this  set.  Several  member  companies  offered  sample  reusable  components  under  these  two
  160. distinctively defined categories: frequently reused and seldomly reused [3].
  161.  
  162.  
  163. For each of these two distinctive sets, we gave scores to each of the components using five ranking
  164. methods, one for each of the ISO 9126 sub-characteristics.  Comparing the component scores for
  165. these two sets, we have tried to find properties or quality characteristics which each category of
  166. components commonly holds.
  167.  
  168.  
  169.  
  170. 3.3     Considerations
  171.  
  172.  
  173.  
  174. We found that the characteristics we must pay attention to in terms of factors which affect com-
  175. ponent reusability may varydep ending on the software size, execution environment, development
  176. methods, and machine type. Consequently,guidelines for better reuse design should be established
  177. for each of these circumstances. We are however able to point out some disciplines, for example,
  178. where  there  is  a  big  gap  between  two  frequency  categories  in  terms  of  functionality, reliability,
  179. usability and efficiency.
  180.  
  181.  
  182. Accuracy, connectivity  and  understandability  are  thought  to  be  factors  independent  of  reusable
  183. component circumstances. On the other hand, characteristics which are thought to b einmp ortant
  184. vary largely from one domain to another. For example, understandability is thought to be important
  185. in  the  downsizing  systems  domain, while  it  is  not  in  the  embedded  or  communication  systems
  186. domain. This example shows that further studies must be undertaken for defining disciplines which
  187. can be commonly used across domains.
  188.  
  189.  
  190.  
  191. References
  192.  
  193.  
  194.  
  195. [1]  "International Standard Information Technology - Software Product Evaluation - Quality Char-
  196.      acteristics and Guidelines for Their Use, First Edition," Tech. Rep. ISO/IEC 9126, ISO/IEC,
  197.      1991.
  198.  
  199.  
  200. [2]  A. de Mora etal, "A Metrics Approach to the Software Reuse Problem," in Proceedings of the
  201.      Third European Conference on Software Quality, 1992.
  202.  
  203.  
  204. [3]  Interim Report:  Software Reusability in The 8th Year-Round Workshops on Software Quality
  205.      Studies, pp. 133-141.  Japan Union of Scientists and Engineers, 1992.  (in Japanese).
  206.  
  207.  
  208.  
  209.                                                       Matsumoto- 3
  210.  
  211.  
  212. 4      Biography
  213.  
  214.  
  215.  
  216. Masao  J.  Matsumoto  joined  NEC,  Tokyo,  Japan,  in  1963.   His  responsibilities  on  the NEC
  217. Software  Engineering  Laboratory  included  modeling,  developing,  and  exploiting  integrated  soft-
  218. ware development environments for and with reusable components under the SEA/I project.  He
  219. had helped formalize and simplify software reuse libraries under the p ost STEPS, SSPL and SPar
  220. projects.  He currently works in the C&C Software Development Group, NEC, and participates in
  221. corporate software engineering programs. He is developing software engineering curricula encom-
  222. passing reusability, quality and productivity for the NEC Institute of Technology Education.  He
  223. also chairs the Software Quality Study Programs at the Japan Union of Scientists and Engineers. He
  224. gives lectures on software engineeringat Yamanashi University,School of Engineering and Tsukuba
  225. University,Graduate School.  Dr.  Matsumoto earned his bachelor's degree in Mathematics Science
  226. at Waseda University, and his Ph.D.degree in Information Engineering from Kyushu University.
  227.  
  228.  
  229. Ms. Atsuko Ishida joined Hitachi, Ltd. in 1972 after graduating from Tokyo University, Faculty
  230. of Sciencei, earning earning her bachelor's degree in Mathematics. She has led several successful
  231. projects in software development and engineering. Ms.  Ishida has also headed software reusability
  232. study groups at the JUSE.
  233.  
  234.  
  235.  
  236.                                                       Matsumoto- 4
  237.