%%%%%% TEMPLATE.TEX for WISR'93, version 1.2.1, 10/3/93 %%%%%%
%%%%%% Updated by Jeffrey S. Poulin,  May 1993          %%%%%%
%%%%%% Updated by Larry J. Latour     and               %%%%%% 
%%%%%%            Steve L. Philbrick, October 1993      %%%%%%
%%%%%%
\markboth{Matsumoto}{Matsumoto}
\documentstyle[11pt]{article}
 
% Standard Spacing for WISR - do not change!!
%
% Page dimensions.
%
\oddsidemargin  0.26in % Leave enough for binding margin
\evensidemargin 0.26in %
\topmargin      -1.00in % (adjusted for printer bias)
\headheight      .00in  % (no headers)
\headsep         .75in  % (top margin + headers + skip)
\footheight     12.0pt  % ??? (seems to work ok)
\footskip       25.0pt  % ??? ( "   "  )
\textheight     9.425in % (instructions: 9 1/8" min, 9 7/16" max)
\textwidth      6.5in   %

\markboth{Matsumoto}{Matsumoto}
\pagestyle{myheadings}
%
% Paragraph changes.
%
\parindent=0pt
\parskip=10pt
%
% can make the title box even smaller
%
\def\@maketitle{\vbox to 2.6in{\hsize\textwidth
    \linewidth\hsize \vfil \centering
    {\large \@title \par}
    \vskip 2em
    {\normalsize
    \begin{tabular}[t]{c}\@author
    \end{tabular}\par}
    \vfil}
}
 
\begin{document}
 
\bibliographystyle{ieeetr}
 
\title{A Nation-Wide Evaluation of Software Components Reusability}

\author{Masao J. Matsumoto\\
\\
C\&C Software Development Group\\
NEC Corporation\\
Shibaura 2-11-5, Minato\\
Tokyo 108 Japan\\
Tel: +81.1.5476.1090\\
Fax: +81.1.5476.1095\\
Email: matumoto@ccs.mt.nec.co.jp\\
\\
Atsuko Ishida\\
\\
Institute of Advanced Business Systems\\
Hitachi, Ltd.\\
890 Kashimada, Saiwai, Kawasaki\\
Kanagawa 211 Japan\\
Tel: +81.44.549.1530\\
Fax: +81.44.549.1528\\
Email: ishida@iabs.hitachi.co.jp\\
}
\date{}
\maketitle
\begin{abstract}
 
Much discipline is needed in order to enable software engineers to develop 
versatile reusable components.  There is need for a set of criteria 
which enable software builders to evaluate software component reusability 
both quantitatively and qualitatively 
across domains.  This position paper describes the
evaluation criteria, proposed methods, and related considerations,
surveyed in a study circle with  participation from
experts in both industry and academia.  However, since 
reuse disciplines defined through this
time survey have not been properly verified, 
followup studies are needed.

\vspace{0.2in}
\noindent
{\bf Keywords:} Reusability evaluation criteria, Software quality 
characteristics, Reuse discipline.
 
\vspace{0.2in}
\noindent
{\bf Workshop Goals:} Learn and exchange information on recent reuse research 
results.
 
\vspace{0.2in}
\noindent
{\bf Working Groups:} Standard guidelines for reuse, Quantitative evaluation
 
\end{abstract}
 

\newpage
\section{Background}

As a member of NEC's Software Engineering Central Group, M.J. Matsumoto 
has facilitated the development and exploitation of software reuse libraries
in the management information systems domain. He has undertaken the
role of architect
in the development of a software engineering environment which
integrates reuse supports for office server systems during 1980's. As
chair of numerous software quality research circles at the Japan Union of
Scientists and Engineers, he has promoted several research thrust
programs (including software reuse), attended by delegates from many
leading industries and academia. Ms. A. Ishida from Hitachi Ltd. has
headed the software reuse-related study teams.  These joint study
activities provide not only an opportunity for members to have
insight on reuse issues, but also a chance to explore possibilities for
forming a nation-wide consensus on the discipline of 
reuse engineering.
 
 
\section{Position}

Not all reusable components are reused at the same frequency.  Some are very 
frequently reused, while the others somewhat less.  What does this mean?  For a 
given component, no reuse for a certain time period means perhaps
that the component does not have enough versatility, with the
more frequently reused
component having more versatility.  The reuse frequency is an index 
that can be used for evaluating the value of a reusable component, 
though the frequency itself does not mean the 
amount of money savings which the reuser can obtain at each
reuse time.

If it is true that each component has its own reuse frequency, where 
does this frequency come from?  Is it inherent to
the component itself or to the characteristics of the reusers?  
Not enough surveys
have been made for making judgements on what the major factors are
that affect this frequency distribution.

There seem to  be several factors which prevent software
engineers from reusing software components, some of a
managerial and some of a technical
nature.  The technical factors must be at least three-fold: factors
pertaining to the component itself, factors pertaining 
to the reusers of the component, and factors 
pertaining to the environment in which the component is reused.
This time
survey focused on the component factor, while the other factors
need further preliminary investigation before surveys can be started.
The primary
aim of this time survey was  to find relationships between
characteristics and reusability (reuse frequency) for a given component.

\section{Comparison}
\subsection{Evaluation Criteria}

There are few well-defined sets of criteria for evaluating software component 
reusability that have been commonly agreed upon in the reuse
community.  One possible set could be 
the 21 characteristics 
defined in ISO/IEC 9126 Annex A~\cite{ISO91}.  This set was originaly defined 
for evaluating software quality from viewpoints such as 
functionality, reliability, usability, efficiency, maintainability and 
portability.  Since the ISO 9126 is a criteria which is used for evaluating 
software quality, it should be helpful for finding relationships between 
the reusability of given components when reviewed from the 
viewpoint of quality.  This is the hypothesis we have taken as our
position.

\begin{quote}
  HO: The ISO 9126 could be used as a criterion for 
      evaluating the reusability of software components.
\end{quote}

The REBOOT criteria for software reusability might be another candidate which 
could be used for this evaluation purpose~\cite{dM92}.  Metrics defined in 
the REBOOT might be of help in measuring each criterion quantitatively.  The
REBOOT
criteria, however, have not yet widely been recognized as standards at the
international level.

\subsection{Proposed Method to Quantify Reusability}

A set of reusable components was carefully examined, each component
of which was reused 
frequently and with considerably high reputation. 21 components were 
sampled from this set.
Another set of seldomly reused ``reusable'' components was examined,
and five components were sampled from this set.
Several member companies offered sample 
reusable components under these two distinctively defined categories:
frequently reused and seldomly reused~\cite{Interim92}.

For each of these two distinctive sets, we gave scores to each of the 
components
using five ranking methods, one  for each of the ISO 9126 
sub-characteristics.  Comparing the
component scores for these two sets, we  have tried to find properties or 
quality characteristics which each category of components commonly holds.

\subsection{Considerations}

We found that the characteristics we must pay attention to in terms of
factors which affect component reusability may vary depending on
the software size, execution environment, development methods, and
machine type.  Consequently, guidelines for better reuse design should
be established for each of these circumstances.  We are however able
to point out some disciplines, for example, where there is a big gap between
two frequency categories in terms of functionality, reliability,
usability and efficiency.

Accuracy, connectivity and understandability are thought to be
factors independent of reusable component circumstances.  On the
other hand, characteristics which are thought to be inmportant
vary largely
from one domain to another. For example, understandability is thought
to be important in the downsizing systems domain, while it is not in 
the embedded or
communication systems domain.  This example shows that further studies
must be undertaken for defining disciplines which can be commonly used
across domains.

\bibliography{matsumoto}

\section{Biography}

{\bf Masao J. Matsumoto} joined NEC, Tokyo, Japan, in 1963.  His 
responsibilities on the NEC Software Engineering Laboratory included modeling, 
developing, and exploiting integrated software development environments
for and 
with reusable components under the
SEA/I project.  He had helped formalize and 
simplify software reuse libraries under the
post STEPS, SSPL and SPar projects.  
He currently works in the C\&C Software Development Group, NEC,
 and participates in 
corporate software engineering programs.  He is developing software 
engineering curricula encompassing reusability, quality and productivity for 
the NEC Institute of Technology Education.  He also chairs the Software 
Quality Study Programs at the 
Japan Union of Scientists and Engineers.  He gives 
lectures on software engineering at 
Yamanashi University, School of Engineering 
and Tsukuba University, Graduate School.  Dr. Matsumoto earned his bachelor's 
degree in Mathematics  Science at Waseda University, and his Ph.D.degree in 
Information Engineering from Kyushu University.

{\bf Ms. Atsuko Ishida} joined Hitachi, Ltd. in 1972 after graduating from 
Tokyo University, Faculty of Sciencei, earning
 earning her bachelor's degree in Mathematics.
She has led several successful
 projects in software development and engineering.
Ms. Ishida has also headed software reusability study groups at the JUSE.
 
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
