🚀 go-pugleaf

I have been involved in software reusability for a number of years.
During this time I have:

	- conducted research in various aspects of software
	  reusability (e.g., domain analysis, reusability metrics, and
	  reusable software construction)

	- conceived of, implemented, and sold on a commercial basis a
	  large (>512K lines of source code) library of reusable
	  components

	- developed and delivered a number of software applications
	  which made conscious and extensive use reusable components

	- developed and delivered a number of courses on software
	  reusability 

	- provided consulting on software reusability to a number of
	  clients

	- authored a number of papers, and chaired a few sessions on
	  the topic

I do not consider myself an expert on software reusability, but I
would say that I have some experience in the area.

One thing that continues to amaze me is the lack of understanding as
to just what "software" is. Before one can discuss reusing something,
you must know what that something is. When software reuse is
discussed, very often one gets the impression that "software" is:

	a. source code

	b. object code

and nothing else.

I submit that software encompasses much more than mere source code and
object code. For example, I consider all of the following to be
software: 

	- code fragments
	- modules (in the subroutine/procedure/function sense)
	- packages (in the package/module/class sense)
	- large collections (in the library/subsystems sense)
	- applications (in the complete, stand-alone sense)
	- scaffolding code (produced during development, but not
	  part of the delivered product)
	- test data
	- software quality assurance information
	- the deliverable products of feasibility studies
	- the deliverable products of analysis efforts
	- designs
	- plans
	- standards
	- tools
	- environments

You will note that not everything on this list is code software.
Non-code software includes such things as test data, designs, plans,
software quality assurance information, standards, the products of
analysis efforts, and the products of feasibility studies.

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.

The reuse of non-code software involves different issues than does the
reuse of code software. For example, non-code software may contain
graphical information, as well as textual information. Many so-called
reusability systems are not set up to handle graphical
representations. The taxonomies, evaluation criteria, and
interconnections of non-code software are often different from the
same items for code software.

Reusability technology tells us that:

	- The larger a component is, the higher will be the payoff
	  from the reuse of that component, however

	- The larger a component is, the lower will be the probability
	  that component will actually be reused.

This means that domain analysts (i.e., those charged with identifying,
documenting, and configuration managing reusable components) must
constantly balance the size of a component against its potential for
reuse. They must find both the granularities of components, and the
mix of components, which will provide the highest return.

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), we need to ask:

	What should the granularity of analysis and design products be
	to maximize their reusability, and thus our investment in
	making them reusable?

Of course, there are many other issues, e.g., taxonomies, software
engineering approaches (e.g., object-oriented), horizontal vs.
vertical reuse, and documentation styles.

I propose a thread of discussion focusing on the reuse of non-code
software. Further, I propose that, at least at the start, one of the
main topics be the reuse of analysis and design, and, more
specifically, what types of analysis and design products provide a
suitable granularity (i.e., one which has a high potential for a
return on investment (ROI)).

I have some ideas on the subject, but I will wait to see if there is
any interest.

				-- Ed Berard
				   Phone: (301) 353-9652
				   FAX:   (301) 353-9272

P.S.: I know it will seem strange to discuss reusable software
      components in comp.sw.components (sometimes referred to as
      alt.software-eng), but, trust me, it will be worth it. ;-)