🚀 go-pugleaf

In article <598@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes:

   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)).

OK, I'll pick up the thread with a request for setting the parameters.  It
seems to me that the interpretation of the terms "analysis" and "design" is
less than well settled.  Design, for example, can occur in several settings
and at several levels; it would be useful to distinguish among them, and
discuss reusability in the different contexts.

With regard to analysis, I have a question arising from your message.  Early
on, you say that you've

	- conducted research in various aspects of software
	  reusability (e.g., domain analysis, ......

Later, you say

       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.

I had the impression that "domain analysis" was the sort of thing that would
be done for a class of applications intended to run in a common domain, to
identify common classes of data, algorithms, report types, etc.  Your
characterization of the task of a "domain analyst" seems to be more like
that of a database administrator for a component database.  Where am I
confused?

--
Don Dwiggins				"Solvitur Ambulando"
Ashton-Tate, Inc.
dwiggins@ashtate.uucp
dwiggins@ashtate.a-t.com