🚀 go-pugleaf

|>From: eberard@ajpo.sei.cmu.edu (Edward Berard)
|
|I submit that software encompasses much more than mere source code and
|object code. 

Absolutely.  I refer you to Ted Biggerstaff's article in IEEE Computer
(July, 1989).  He stresses the use of a wide scope of software work
products to recover the design issues for source code.  It's not quite
to the point you make, but is the only work I know of that explicitly
tries to draw from sources other than raw code for reuse.

|Unfortunately, most of the effort in software reusability systems
|seems to be focused on code software. Ironically, this is the area
|where the return on investment seems to be the lowest. For example, if
|analysis and design consume a significantly larger share of the
|software life-cycle than does coding, reuse of analysis and design can
|potentially provide significantly greater returns than the mere reuse
|of code.
|[...]
|Given that reuse of analysis and design may potentially provide more
|benefits than the simple reuse of source code (in fact, may even drive
|the structure and selection of reusable source code), [...]

It can go the other way too.  The availability of reusable code
components can drive the analysis and design.

A common mistake in software reusability systems is the assumption that
the management of software projects will remain the same.  If you are
consciously striving to reuse existing software the processes and
proportion of time spent on these processes will change.  

For example, time must now be spent finding and assessing reusable
components.  This is not accounted for in traditional software
management techniques.  If you believe my above statement and also
realize that time must also be spent on indexing new code for future
reusability, I think you can see that SE techniques must adapt to the
very different programming techniques involved in reusing software.


-- Scott
   scotth@boulder.colorado.edu