Part of our research on software reuse has focused on
how the software development process can be enhanced to improve
reuse. Evaluation of the process steps has highlighted the
importance of analogies to help designers understand the problems
at hand. These analogies include:
- Standard forms? Unlike integral calculus, software
engineering has not evolved to the point where detail can be
avoided entirely. For example, tables of software forms are
not readily available for easy identification nor are software
simplification techniques standard. A civil engineer, for example,
does not go back to first principles to derive solutions to general
integral forms. Instead the problem is reduced to a standard form
by a simplification technique, such as integration by parts; partial
fractions; or coordinate transformations. Then an analytic solution
can be derived from a set of tables or a numerical solution calculated.
Software reuse has not evolved to this level of standardization either
from a solution framework perspective or standard software forms.
This is probably a characteristic of the immaturity of software
engineering as a discipline rather than software reuse specifically.
- With Reuse or For Reuse? The analogy of plastic
building blocks appears appropriate. A child, when given blocks to
play with, can implement the most innovative designs. However, if a
child is asked to create a new block type, the interest and the
motivation would not be there (nor are the necessary skills and
production facilities). In software reuse, the analogy is that
designers have different personal values and motivating influences.
These should be recognized and fostered. Core reuse groups
can be created to specialize in facilitating reuse. With this model of
reuse, the necessary rework and support required is viewed as an
important deliverable, rather than an overhead that can be sacrificed
to meet market pressures.
From our experience, it is not possible to stop the product delivery
process to introduce reuse in one step. The greatest
challenge with our research is to introduce the benefits of a planned
program of software reuse without jeopardizing current market
deliverables. A balance must be struck between resources required
to meet today's deadlines and those required for the for system
longevity.