\documentstyle[12pt]{article}
\topmargin=-0.25in
\textheight=8.75in
\oddsidemargin=-0.25in
\evensidemargin=-0.25in
\textwidth=7.0in

\begin{document}
\title{Software Engineering and Reuse}
\author{E.M. Dusink\\
	TU Delft, Dept. Computer Science\\
	Julianalaan 132\\
	2624 BL Delft\\
	The Netherlands\\
	e-mail: betje@dutiaa.tudelft.nl
	}
\date{}
\maketitle

\begin{abstract}
This article contains relevant concepts of cognitive
psychology and software psychology and
a framework of the software engineering method based on these concepts.
Cognitive psychology was studied with special attention for the differences
between problem solving with help of existing (partial) solutions (reuse)
and without help of existing (partial) solutions (no reuse).

\vspace{0.3in}
\noindent
{\bf Keywords:} reuse supporting method, cognitive psychology, software
psychology
\end{abstract}

\section{Introduction}

This article contains relevant concepts of cognitive
psychology and software psychology and
a framework of the software engineering method based on these concepts.
Cognitive psychology studies how humans solve problems.
Software psychology studies a.o. specialised problem solving methods
for software engineering.
And thus can be seen as applied cognitive psychology.
Cognitive psychology was studied with special attention for the differences
between problem solving with help of existing (partial) solutions (reuse)
and without help of existing (partial) solutions (no reuse).
In a later stage the framework will be completed
with insight from software engineering and reuse to a software engineering
method which supports reuse.
The method will be verified with a statistical experiment.

A rational for the use of cognitive psychology is given.
The used concepts of cognitive psychology and software psychology are described
with their literature references as they are no common knowledge in the
software engineering society.
They are also described
to provide the reader with the necessary
information for criticising the used ideas,
our interpretation of the ideas, or our usage of the ideas.
For an overview of our findings in the field of cognitive psychology
see \cite{dusink1}.

The software engineering method being developed
has to support compositional reuse
and has to result in at least the same quality products as existing software
engineering methods.
The goal, group, application domain, metrics, and
the way of testing the method are described in \cite{dusink2}

\section{Why Cognitive Aspects in Software Engineering}

The software engineering process can be seen as the capturing of information
and the solving of problems with humans as the driving force.
In this view it is of interest how {\em humans} work with information and
how they solve problems.
Problem solving is the creative activity of finding
a correct implementation given certain requirements.
Within this view on software engineering cognitive psychology can be a
help.

Humans tried to formalise and control the problem solving aspect
of software engineering by developing the waterfall model.
This conventional life cycle model can be traced to the reductionist mode of
inquiry in planning and logistics. Planning and logistics
were emerging as organised and
systematic approaches to problem solving \cite{agrestiOverview}.
The waterfall model is nothing more or less then a general problem solving
method stated in software engineering terms.

As software systems grew complexer and larger,
a systematic and organised approach for problem solving on a more
detailed level was needed.
An approach to fill this need was
in the form of increased attention on intermediate products and verification
steps of the transition \cite{agrestiOverview}.
This verification is a step which was already
accentuated in cognitive psychology \cite{polya57}.
That need could already have been fulfilled before feeling it.

As software had to be written for more divers systems and for less
well informed people problems occurred with stating all the requirements
beforehand and taking all design decisions beforehand.
This was already known in cognitive psychology from experiments with problem
solvers. But than in the form
that a problem can only be stated in the direction of
a possible solution \cite{letovsky}.
An example is with students who do not understand a lecture, they only can
tell you that they do not understand the lecture but not in what way or what
part of the lecture was outside their comprehension.

Another part of this problem, not yet understood by software engineers,
is caused by the fact that only experienced people can work top
down and give a good structured solution. Less experienced people have
to go forwards and backwards in abstraction level to be able to solve
a problem.

Software engineers now try to fill this need in very divers ways:
spiral model; rapid prototyping; transformational approach;
incremental development; etc.
As the evaluation of what caused the problem only gave part of the cause,
this solution is only partial and in the near future software engineers will
see that rapid prototyping does not solve all of the problem.

Because of all the reasons for changing the conventional life
cycle model and the fact that it is faster to use knowledge already in
existence, in this paper the software engineering process
will be redeveloped with help of knowledge from the cognitive psychology
in order to profit from
things which are already correct and to get knowledge about what to avoid.

\section{Why Cognitive Aspects in Reuse}

Reuse is the use of existing partial solutions (components)
by humans in such a way that combined together given requirements are fulfilled.
Several cognitive problems prevent users from successfully exploiting
reusable components, a.o. understanding what a reusable component does
and when to apply it.
In this view reuse is also problem solving.

Understanding a component is done by learning (about) the component.
>From cognitive psychology we know that there are basically
two ways of understanding a component, the broad general notion of the
features which makes it possible to use the component outside the scope of
learning (important for reuse) and the functional fixedness understanding
which prevents use outside the scope of learning (hinders reuse).
In the first kind of learning a brick has volume, weight, colour, ....,
in the second kind of learning a brick can be used for building buildings.
This different perception makes that the question: "give thirty different
usages of a brick" is easier to answer if the first kind of learning has
occurred.
In cognitive psychology it is known how to learn about things in order to
get the first kind of learning and how to stimulate the second kind of
learning.
This problem is not yet recognised in the reuse world,
but it is not necessary to encounter the problem
if we profit now from knowledge of cognitive psychology.

The other problem, when to apply a component, is already encountered.
In an experiment with reuse Maiden and Sutcliffe \cite{maiden} saw that without
guidelines reuse was degraded to copying without understanding why and
what was used.
And therefor not the right usage was made of the reusable components.
It was a form of mental laziness.
This phenomenon was already known for at least {\em twenty}
years in cognitive psychology \cite{luchins}.
So, once again, problems relevant for reuse
were already known in cognitive psychology before they were known within the
software engineering/reuse field.
And, in cognitive psychology a solution for these problems exist \cite{mayer75}
where we,
software engineers and reusers, have to start with looking for a solution.

As we want our field of science to mature as quickly as possible,
let's make use of the knowledge of cognitive psychology
now we know it exists and now we know it is applicable to both
the software engineering process as well as to reuse.

\section{Main Conclusions from Cognitive Psychology}

The main conclusions are on the field of problem solving methods,
how reusable components have to be learned and how to stimulate creativity.
They are described in this section.

Depending on the understanding of the description of the problem
(ie. requirements) and the familiarity with the reusable components,
there exist three kinds of obstacles for finding a solution.
The three kinds are: interpolation problem, dialectic problem, and
synthesis problem \cite{dorner}.
An interpolation problem occurs when the combination of
a good understanding of the problem and the components happens.
A dialectic problem occurs when the combination of
a good understanding of the components and a low understanding of
the problem happens.
A synthesis problem occurs when the combination of
a bad understanding of the components and
a high understanding of the problem happens.
A combination of dialectic and synthesis problem exist in case of a
low understanding of the problem and of the components.
The problem solving methods which one has to follow depending
on the kind of obstacle are described in \cite{dorner}.
General problem solving methods are described in
\cite{polya57,polya68,wickelgren}.

Two kinds of learning of components can be of importance for the reuser.
The first kind of learning is the acquisition of broad,
non-specific, general notions about the properties of the component
experienced.
This seems to provide the knowledge repertoire essential for productive
($\sim$creative) thinking.
The second kind of learning is the acquisition of experiences
which provides perceptions of specific, limited, functional characteristics.
This seems to lead to ``functional fixedness'' in problem solving perceptions.
Such fixedness limits the range of perceptual organisations capable of
being developed by the reuser and so interferes with problem solving
\cite{birchw}.

It is clear that the functional fixedness kind of learning is of little use
for a reuser, but it is of use for a problem solver who only solves one
kind of problems.
The discrepancy between usefulness and uselessness of functional fixedness
can be overcome by learning basic specific facts
coupled with general problem solving techniques.
In \cite{mayer75} it is advised to learn first the global concepts used by
the component before the mechanics.

The main difference for problem solving with and without existing components
was lain in the fact that components could be seen as giving a hint as in
which direction to look for a solution.

The solving of problems asks for creativity.
By accepting the idea
that the long term memory is associative \cite{wickelgren79}
and that knowledge in
the long term memory is clustered into schemata \cite{mayer}
and that the retrieval of knowledge from the long term memory is
keyword-based \cite{wickelgren79} we can sketch
an approach for being creative \cite{wickelgren79}.
The memory has to be prepared to meet the conditions required for creativity.
By storing a lot of questions in the memory answers will be recognised when
they come along. Thus during the process of learning one has to ask
oneself all the ``w''-questions, why, when, where, etc.
One also has to try to relate new information to the own schemata
\cite{wickelgren79}.
If a rich store of novel integrative schemata and unanswered questions exists
in memory, and if good cognitive plans for playing
with ideas exist, ideas can be created on demand much as any other skill
can be performed \cite{wickelgren79}.

\section{Main Conclusions from Software Psychology}

The main conclusions are about the existence of cognitive processes
in software engineering, necessary mental make-up,
how to understand problems and what the problems are with reuse.

Software engineering can be seen as a special form of problem solving.
The splitting of the software lice cycle into several steps is the division
of a problem into subproblems (a general problem solving method).
The use of program plans \cite{rist,littman,yu,wiedenbeck}
can be compared with the schemata \cite{mayer}.
Functional fixedness in programming was proved by \cite{mayer75}.
All these findings supported the idea that conclusions from cognitive psychology
can be used in software engineering.

A different mental make-up was needed in the different
stages of the software engineering process.
The ability to live with uncertainties
and the ability to make decisions
is necessary in the beginning of the life cycle,
whereas the ability of convulsive preciseness is necessary at the end
\cite{shneiderman}.

Without knowledge of problem-related concepts, the memory quickly reaches its
limits when trying to understand code \cite{shneiderman}.
This is because the knowledge can not be related to existing schemata
and thus has to be stored as separate facts (for the time being
in the short term memory which is non-associative
and can contain up till 7 items) \cite{newell,wickelgren79,shneiderman,miller}.
Thus documentation of code has to give the used concepts of the application
domain and the used concepts of the computer domain.

There are different approaches when trying to understand code,
a systematic strategy and an ad hoc strategy \cite{littman,pinto}.
In the systematic approach first the total documentation is studied in a
systematic manner. In the ad hoc approach documentation is read at random.
The systematic approach can take
too much time for large pieces of program and the ad hoc strategy gives
poorer results when adapting a program.
Therefor documentation has to be in such a way that it is easy
to combine both strategies in an intelligent manner.
The documentation has also to be in such a way that
the limits of the memory are not reached very quickly.
The documentation is best understood if it is in a very succinct
symbology \cite{sheppard}, the spatial arrangement is of less importance.

In \cite{maiden} mental laziness is remarked as one of the problems with
reuse. In \cite{luchins} some experiments are done about how to prevent that
the habit masters the individual instead of the individual mastering
the habit. It appears that by promoting productive thinking the problem
of mental laziness could be overcome.
If a solution is actively verbalised transformation to new situations
becomes easier \cite{mayer}.
This improves reuse.
The active participation in finding a solution improves the recognition
of the possibility of applying the solution to other areas \cite{mayer}.

\section{A Framework for a Software Engineering Method}

Although software engineering life cycles can differ very much,
they all have about the same division in analysis, requirements, design,
implementation, testing and debugging. These same phases,
although not necessarily in this order or with the same emphasis,
are the phases of the framework.
In this section concrete use is made from the findings described in
the former two sections.

Before modification is possible, the part of the product to be modified
has to exist.
Before debugging, tests have to be applied.
Before it is possible to test, design and/or
implementation has to be done, etc.
But, is it necessary to have the requirements finished before looking at the
design phase? As humans can be seen as opportunistic processors \cite{letovsky},
and as we always use past experience, the answer is ``no''.
Before the requirements are finished, it has to be known whether they are
implementable. For making a choice between alternatives with regard to reuse,
ease of implementation, and risks one has to look ahead.
Also because a problem can only be stated in the direction of
a possible solution one has to look ahead \cite{rohr}.
And of course, because of changing insights and bugs one has to go
back to previous phases and
one has to look back to be able to learn.
Because of all these reasons a yoyo approach is suggested as an ordering of
the phases, where the going down and up is steered by an ``as-needed''
strategy.

In every phase the understanding of the problem, the focusing on reuse,
and learning are stressed.
Understanding is emphasised because the right problem has to be solved.

Components have to exist in the environment to be able to reuse.
A components base
is coupled with a means to select potentially useful components.
In an experiment \cite{mayer}
2.4 minutes were necessary to find a solution when
only useful components were given, 7.5 minutes were necessary when all
components where given and hints about which ones were useful,
and 15.2 minutes were necessary when the same components were given
as to the former group but no attention was drawn
to potential useful components.
This means that the selection mechanism is critical.

The method emphasises learning as only components which are known can be
used correctly and as things which one has learned can be reused easier
than things fairly unknown to the (re)user.
Possible ways to integrate learning are:
\begin{itemize}
\item
The organisation of persons on jobs has to be done in such a way that a junior
software engineer is mentored by a senior one.
In this way real-time feedback on the work of the junior is possible.
\item
Feedback from next stages has to reach the engineer also
as one learns most from ones own errors.
\item
All software engineers have regular sessions to play with the (new) reusable
components, in order to learn them in a context free way.
\item
The software engineers have to learn general problem solving techniques
to improve their creativity.
\end{itemize}

A possible manner to help learning passively is by documenting.
Documentation has to state the relations among concepts
backgrounds and why's. Also alternatives with their pro's and con's
and the reason for their disregarding have to be documented.
This emphasises learning.
The experienced software engineers
in the application domain have to contribute to be sure the information
is already computer oriented formulated.

\section{Conclusion}

A framework for a software engineering method was retrieved
from cognitive psychology and software psychology,
without any considerations on management, economics,
and current software engineering practices.
The resulting idea corresponds with current developments in software engineering
practice about rapid prototyping and operational approach \cite{agresti}.
The way of working when developing the framework was the same as suggested in
the framework. This first ``evaluation'' gave the impression of
an ergonomic and tailorable whole in which much reuse was done.
Work has to be done on the software engineering side of the method.

\begin{thebibliography}{10}

\bibitem{agrestiOverview}
William~W. Agresti.
\newblock {The Conventional Software Life-cycle Model: Its Evolution and
  Assumptions}.
\newblock In Agresti \cite{agresti}, pages 2--5.

\bibitem{agresti}
W.W. Agresti, editor.
\newblock {\em {New Paradigms for Software Development}}.
\newblock IEEE Computer Society Press, 1986.

\bibitem{birchw}
H.G. Birch and H.S. Rabinowitz.
\newblock {The Negative Effect of Previous Experience on Productive Thinking}.
\newblock In Wason and Johnson-Laird \cite{wason}, chapter~3.

\bibitem{dorner}
D.~D{\"o}rner.
\newblock {\em {Probleml{\"o}sen als Informationsverarbeitung}}.
\newblock Kohlhammer Standards Psychologie, Teilgebiet Denkpsychologie. W.
  Kohlhammer, Stuttgart, 2. Auflage Edition, 1979.

\bibitem{dusink1}
E.M. Dusink.
\newblock {Cognitive Psychology, Software Psychology, Reuse and Software
  Engineering}.
\newblock Technical report, TU Delft, Delft, the Netherlands, 1991.
\newblock to appear.

\bibitem{dusink2}
E.M. Dusink.
\newblock {Testing a Software Engineering Method Statistically}.
\newblock Technical report, TWI, TU Delft, Delft, the Netherlands, 1991.
\newblock to appear.

\bibitem{letovsky}
S.~Letovsky.
\newblock {Cognitive Processes in Program Comprehension}.
\newblock In Soloway and Iyengar \cite{soloway86}, pages 58--79.
\newblock (Human/Computer Interaction Series).

\bibitem{littman}
D.C. Littman, J.~Pinto, S.~Letovsky, and E.~Soloway.
\newblock {Mental Models and Software Maintenance}.
\newblock In Soloway and Iyengar \cite{soloway86}, pages 80--98.
\newblock (Human/Computer Interaction Series).

\bibitem{luchins}
A.S. Luchins and E.H. Luchins.
\newblock {New Experimental Attempts at Preventing Mechanization in Problem
  Solving}.
\newblock In Wason and Johnson-Laird \cite{wason}, chapter~6.

\bibitem{maiden}
Neil Maiden and Alistair Sutcliffe.
\newblock {The Abuse of Re-use: Why Cognitive Aspects of Software Re-usability
  are Important}.
\newblock In Liesbeth Dusink and Patrick Hall, editors, {\em {Software Re-use,
  Utrecht 1989: Proceedings of the Software Re-use Workshop, 23-24 November
  1989, Utrecht, The Netherlands}}, chapter~10. Springer-Verlag, 1991.

\bibitem{mayer75}
R.E. Mayer.
\newblock {Different Problem-Solving Competencies Established in Learning
  Computer Programming With and Without Meaningful Models}.
\newblock {\em Journal of Educational Psychology}, (67):725--734, 1975.

\bibitem{mayer}
R.E. Mayer.
\newblock {\em {Thinking, Problem-Solving, Cognition}}.
\newblock W.H. Freeman and Company, 1983.

\bibitem{miller}
Georg~A. Miller.
\newblock {The Magical Number Seven--- Plus or Minus Two: Some Limits on our
  Capacity for Processing Information}.
\newblock {\em Psychological Review}, (63):81--97, 1956.

\bibitem{newell}
Allen Newell and Herbert~A. Simon.
\newblock {\em {Human Problem Solving}}.
\newblock Prentice-Hall, Engle Wood Cliffs N.J., 1972.

\bibitem{pinto}
J.~Pinto and E.~Soloway.
\newblock {Providing the requisite Knowledge Via Software Documentation}.
\newblock In Soloway et~al. \cite{soloway88}, pages 257--262.
\newblock special issue of the ACM/SIGCHI Bulletin.

\bibitem{polya57}
G.~Polya.
\newblock {\em {How to Solve It}}.
\newblock Garden City N.Y., 1957.

\bibitem{polya68}
G.~Polya.
\newblock {\em {Mathematical Discovery}}, volume II: On Understanding, Learning
  and Teaching Problem-Solving.
\newblock Wiley, New York N.Y., 1968.

\bibitem{rist}
R.S. Rist.
\newblock {Planning in Programming: Definition, Demonstration, and
  Development}.
\newblock In Soloway and Iyengar \cite{soloway86}, pages 28--47.
\newblock (Human/Computer Interaction Series).

\bibitem{rohr}
A.R. Rohr.
\newblock {\em {Kreative Prozesse und Methoden der Probleml{\"o}sung}}.
\newblock Beltz Monographien. Beltz, Weinheim, 1975.

\bibitem{sheppard}
S.B. Sheppard, J.W. Bailey, and E.K. Bailey.
\newblock {An Empirical Evaluation of Software Documentation Formats}.
\newblock Human/Computer Interaction, chapter~6. Ablex, Norwood, New Jersey,
  1984.

\bibitem{shneiderman}
B.~Shneiderman.
\newblock {\em {Software Psychology: Human Factors in Computer and Information
  Systems}}.
\newblock Little, Brown Computer Systems Series. Little, Brown \& Company,
  1980.

\bibitem{soloway88}
E.~Soloway, D.~Frye, and S.B. Sheppard, editors.
\newblock {\em CHI'88 Conference Proceedings, Human Factors in Computing
  Systems, May 15-19, 1988 Washington, DC.,}, 1988.
\newblock special issue of the ACM/SIGCHI Bulletin.

\bibitem{soloway86}
E.~Soloway and S.~Iyengar, editors.
\newblock {\em Empirical Studies of Programmers, papers presented at the First
  Workshop on Empirical Studies of Programmers, June 5-6, 1986, Washington,
  DC.} Ablex, 1986.
\newblock (Human/Computer Interaction Series).

\bibitem{wason}
P.C. Wason and P.N. Johnson-Laird, editors.
\newblock {\em {Thinking and Reasoning, Selected Readings}}.
\newblock Penguin Modern Psychology. Penguin Books, 1968.

\bibitem{wickelgren}
W.A. Wickelgren.
\newblock {\em {How to Solve Problems: Elements of a Theory of Problems and
  Problem-Solving}}.
\newblock A Series of Books in Psychology. W.H. Freeman and Company, San
  Francisco, 1974.

\bibitem{wickelgren79}
W.A. Wickelgren.
\newblock {\em {Cognitive Psychology}}.
\newblock Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1979.

\bibitem{wiedenbeck}
S.~Wiedenbeck.
\newblock {Processes in Computer Program Comprehension}.
\newblock In Soloway and Iyengar \cite{soloway86}, pages 48--57.
\newblock (Human/Computer Interaction Series).

\bibitem{yu}
C.-C. Yu and S.P. Robertson.
\newblock {Plan-Based Representations of Pascal and Fortran Code}.
\newblock In Soloway et~al. \cite{soloway88}, pages 251--256.
\newblock special issue of the ACM/SIGCHI Bulletin.

\end{thebibliography}


\section{About the Author}


Liesbeth Dusink has been working at Delft University of Technolgy since 1985.
She got het MD in Biology from Utrecht University.
At the moment she teaches courses on programming, software engineering,
and programming support environments.
Her research concentrates on software engineering methods which supports
compositional reuse and on software measurement and
software process measurement.




\end{document}

