🚀 go-pugleaf

In article <229@reuse.USWEST.COM> ken@reuse.USWEST.COM (Kenny A. Chaffin) writes:
>
>... Much of the effort, as you may guess has 
>been  in defining and determining what is reusable and how,  etc. 
>As it turns out we worked with a particular project and ended  up 
>with  several  versions  of  the  assets(our  term  for  reusable 
>software).  The  biggest  problems  seem to be  in  the  area  of 
>determining  what  functionality is appropriate to place  into  a 
>
>We have developed a preliminary domain 
>analysis methodology (my area of work) which helps in identifying 
>reuse  opportunities. We have standards regarding  documentation, 

Ken,

Thaks for sharing your experiences with us. I am looking forward to
reading about them.

What I was particularly looking for was information about what
you are calling asset domain analysis. What wound up being called
assets and what was left as implementation specific? I think that
information like this could be important to our discussions.

One thing that I would like to see this group do is to come up
with a list of things (functions, data structures, what have you)
that we can all agree on as being essential subjects for software
components (assets, ICs, etc.).

For years I have been tanatalized by the idea of an LS7400 which is
a bunch of NAND gates which are made up of transistors, which are
made up of... and just how in the hell was I going to do something
that definate, that flexible, in software? OOP seems to lead in that
direction.

People always use sorting or matrix multiplication as examples
of software components. What else is there? I am currently working
on a schematic capture editor. Things that we use as common functions
are graphical operations, textual menu operations and regular
expression evaluation.

Now that I think of it, these are all things that are supplied
by the operating system or grafix libraries. Hmm... Then what
we are talking about is maybe extending that analogy into what
is sometimes called the 'application' domain. This sounds like
our list of things that are software components could start
with a unix manual, a GKS manual, an SPSS manual and so on.

>... Also managing the  expectations  of  the 
>project  developers  is important. They typically expect  all  or 
>nothing.

I am interested in what you mean by managing developer's expectations.
Was there anything specific about this or was it just another case
of the recipe that is going to save the world not working?

regards

=============================================================
Chesley Reyburn                 ...tektronix!ogccse!cvedc!cmr
ECAE Software, Prime Computer, Inc.   ...sun!cvbnet!cvedc!cmr
14952 NW Greenbrier Parkway              ...sequent!cvedc!cmr
Beaverton, OR 97006                       Phone  503/645-2410
=============================================================