\markboth{Burd}{Burd}
\documentstyle[11pt]{article}

\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{Burd}{Burd}
\pagestyle{myheadings}
\parindent=0pt
\parskip=10pt
\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{alpha}
\bibliographystyle{ieeetr}

\title{Risk Management the Key to Successful Reuse}

\author{Elizabeth L. Burd, John A. McDermid\\ \\ Department of Computer
Science,\\ University of York,\\ Heslington,\\ York,\\ YO1 5DD,\\ UK\\
\\ Tel: (+44) 904 432711\\ Fax: (+44) 904 432767\\ Email:
liz@minster.york.ac.uk\\ \\ } \date{}

\maketitle



\begin{abstract}

In this position paper we stress the importance of risk management to
the process of software reuse. We consider the problems that are
associated with reuse and have accounted for its failure to become an
important and respected part of the software development process. We
discuss, in brief, the work that we have carried out. In particular we
concentrate our efforts for this paper on the procedure of reusing risk
assessments to direct a new software development. We then look at some
of the implications that increasing a developer's knowledge of risks
has on the acceptance of reuse to project managers. Finally we indicate
the new directions our work will take.\\

\vspace{0.2in} \noindent {\bf Keywords:} Reuse, Risk, Software life
cycle, Process models.

\vspace{0.2in} \noindent {\bf Workshop Goals:} Listening , learning,
discussing and meeting people

\vspace{0.2in} \noindent {\bf Working Groups:} Reuse process models,
Reuse management, organisation and economics, Reuse maturity models,
Education.

\end{abstract}

\newpage

\section{Background}

From a study of the research conducted into the problems associated
with software reuse and also from the industrial experiences of
companies trying to employ reuse we, in harmony with others, have
identified a basis on which the success of reuse depends. We believe
that for reuse to flourish, it must be viewed as an integral part of
the software life cycle. Changes must be made to the way in which
industry views reuse. Industry needs to move away from simply the reuse
of code and certainly away from the attitude that it is acceptable not
to consider reuse at all. We examined why these attitudes have existed
and our studies have led us to the conclusion that there are a number
of inhibiting factors which limit the appeal of reuse to project
managers and software developers. These inhibiting factors include, at
a technical level:

\begin{itemize} \item \em{development} \em- Knowing what kind of
software is reusable and as equally difficult is knowing how to develop
a software component which is potentially reusable.  \item \em
{storage} \em- Once we have developed an item of reusable software how,
and where, should it be retained for future retrieval and reuse.  \item
\em {retrieval} \em- If we are to reuse software then we must be able
to easily find what we require matching what is available with our
needs.  \item \em {verification} \em- How can we be sure that the
component which we are proposing to reuse actually performs the
functions that it claims it does in the environment in which we use
it.  \item \em {evaluation} \em- How can we judge that the functions we
require from our reusable unit and the functions that it provides are
the same.  \item \em {modification} \em- If our evaluations have shown
that differences exist in the reuse unit's and our requirements then
how do we perform the necessary modifications and what effect will this
have on the reusable unit including the results of previous
verifications.  \item \em {integration} \em- What will the effect be on
the reusable unit of attempting to integrate it into our development.
\end{itemize}

We thus came to the realisation that the underlying technical reason
why reuse was not as successful is that developers would have liked as
the inhibiting factors which we have described above increase
development risks. Since project managers tend towards the path with
the smallest risks they thus often, and rightly given the
circumstances, tend to develop 'from scratch'. We therefore consider
that if reuse is to be successful we need to indicate its tangible
benefits to project managers by reducing the risks associated with
development and especially when reuse is being considered. In addition
it should strive to make reuse a continuous and integral part of the
software development process as this has an effect both on risks and
acceptability of risks.

We acknowledge that there are other factors affecting the take up of
reuse e.g. individual motivations but such issues are outside the realm
of this paper.

\section{Comparison}

Barnes and Bollinger \cite{barnes91,bollinger90} have indicated similar
beliefs about the nature of the problems that are associated with
software developments incorporating reuse. They  advocate the necessity
for a broad spectrum of reuse to be considered and stress the
importance of considering human problem solving as an aspect of
software development that is potentially reusable. Their work has
concentrated on the need for incentives for performing reuse and have
indicated ways in which this can be taken account of in the software
development process. In addition they have indicated that life cycle
integration is likely to one of the key factors which makes reuse truly
effective. This work formed the foundation from which we embarked in
our research One major contribution, and the issue on which we focus
here, is the notion of risk and the reuse of risk assessment - a sort
of human problem solving.

In addition we have also built our work around Boehm's spiral model
\cite{boehm88,boehm91}. We will consider the additions we have made to
the model in more detail below, but in brief we have to base our work
on the spiral model because of its risk based approach to software
development. Our extensions were included to enhance the work of
Boehm's to encourage a life cycle approach to reuse and a broad
definition of reuse.

\section{Position}

We have indicated above that development risks are actually be
increased with reuse. This is probably the most compelling reason to
develop systems 'from scratch'. However, the perceptions of risk may
outweigh the actual risks, and social factors will tend to lead project
managers towards the (perhaps illusory) feeling that developing 'from
scratch' puts then in control' and hence minimises risk. We consider
these apparent increased risks an unnecessary burden for reuse to carry
and believe that given a broader definition of what is reusable from
the software development process then reuse can actually serve to
reduce development risks. Perhaps more importantly by enabling
risk-based decision making about reuse to be explicit, we can help
ensure that decisions  about reuse are balanced and well supported.

\subsection{Hypothesis}

The hypothesis of the PROM project was therefore: reusing all products
of software development will reduce the risks that are associated with
reuse and that since developers will find reuse more acceptable, if
they are aware of the scale of risks that are involved then reuse will
become a necessary and informative part of software development.

\subsection{Research}

As we indicated above that our work has been based on building
extensions to Boehm's spiral model. This allows us to incorporate our
aims of providing a reuse method which is integral to software
development while supporting reuse continually and also encouraging a
risk based approach to development. These extensions have taken the
form of a 'reuse spiral'. This has a symbiotic relationship the spiral
model; the spiral model encourages a risk based approach to development
and the reuse spiral provides the
'know-how' for reuse. Thus the information which is collected
by one of the spirals is used by the other and vice versa.

Each of the spirals of the two models are split into four quadrants.
The activities that are concerned with these quadrants are as follows:

\begin{center} \begin{tabular}{|l|l|l|} \hline Spiral model & Reuse
spiral & Problems tackled\\\hline

Q1 & & \\ Define system & Use information & Retrieval \\ objectives and
& gathered as & \\ constraints & search criteria & \\\hline

Q2 & & \\ Evaluate  & Reuse risk & Evaluation \\ alternatives &
assessment & Verification\\ identify and & information to & \\ resolve
risks.& aid risk & \\ & management  & \\\hline

Q3 & & \\ Develop and & Reuse products & Development \\ verify next - &
of previous & Modification \\ level product & developments &
Integration \\
 & where possible &  \\\hline

Q4 & & \\ Plan next & Focus record and & Storage \\ phases & commit
decisions & \\
 & to the library & \\\hline \end{tabular} \end{center}


\subsection{Case Study}

We consider that one area which is often disregarded in the field of
reuse research are those activities which are concerned with the second
quadrant of the reuse spiral; mainly that of the evaluation of the
risks associated with a development. We have indicated how important
this is for successful software development and therefore we will
illustrate this process, of reusing risk evaluations, with the aid of
an example derived from a case study of the National Health Service.

In the second quadrant we perform the following activities:
\begin{enumerate}\itemsep -3pt

\item We use information from the similar projects which were located
in the first quadrant and investigate what options are available for
developing a system, and secondly what risk assessments activities were
associated which each option. From this information we are able to
indicate some of the risk criteria which are associated with our new
development. In terms of the health service, typical risk criteria for
developing a system which informs doctors which drugs are functionally
equivalent may be: the doctors reaction to the system; the cost of
development; the accuracy of the information it generates; or the
feasibility of building the system. Typical options may be to: develop
a database application, an expert system or perhaps nothing at all i.e.
retain a manual system.

\item We can now use sensitivity analysis to allow us to evaluate which
is the best option to take for our proposed development. In order to do
this then we evaluate risk criteria individually to obtain the utility
for each risk criteria. The risk criteria for each option may be the
same but their utility will be different. (Here we use utility in a
technical sense, a concept unifying benefit and risk.) In the case of
our drug substitution program the utility for cost will depend on the
expected cost of the individual options and the utility for doctors
acceptance of the system may for instance be greater for the database
option than the expert system since doctors may feel an expert system
is de-skilling their job. Weightings are then placed on the individual
criteria (again information gained from previous projects) in order
that the interaction effects between the individual risk criteria can
be evaluated.

\item By folding back the decision trees the utility for each option
can then be considered and the option with the highest utility, or
greatest expected payoff, can be selected.  \end{enumerate}
\subsection{Conclusions}

Our studies have lead us to conclude that an all round approach to
reuse improves the chances of a product or process definition of a
previous development being reusable. Without taking a risk based
approach to development the type of reuse which we have described would
in most cases be infeasible. Thus we believe that reusing risk
assessment, weightings and prototypes etc. allow more informed
judgements to be made as to the feasibility of various options of
software development and therefore reuse to be, in general, more
successful.


\bibliography{burd}

\section{Biography} {\bf Elizabeth Burd}'s background is in education;
she is a qualified teacher. In 1989 she entered the research community
and after completing a masters in Information processing she
subsequently proceeded to research for a Ph.D. in the Information
Systems group at the University of York. She is currently working on
the PROM project which is concerned with a life cycle approach to
reuse. Her interests in education are very much reflected in the
options she is considering to aid some of the problems associated with
reuse.

Elizabeth is also a member of the British Computer Society Reuse
Special Interest Group committee.

{\bf John McDermid} has been Professor of Software Engineering at the
University of York since 1987.  Prior to coming to York he worked for
SD-Scicon and the Royal Signals and Radar Establishment (now the DRA
Malvern).  At the University he runs the High Integrity Systems
Engineering group, concentrating on safety-critical and dependable
systems.  He is also the technical director of the Dependable Computing
Systems Centre set up by British Aerospace at the Universities of York
and Newcastle and a director of York Software Engineering Ltd.

He is active in the professional community, and has assisted the IEE
and BCS in major studies of safety-critical systems.  He has published
widely, being the author or editor of six books, and the author or
co-author of about one hundred and twenty papers and articles.


\end{document}
