Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.sw.components
Subject: Re: What should a component library loo
Message-ID: <7182@hubcap.clemson.edu>
Date: 25 Nov 89 21:04:33 GMT
References: <DWIGGINS.89Nov20154941@atsun.a-t.com>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 52

From dwiggins@atsun.a-t.com (Don Dwiggins):
> I can envision a number of reasonable organizational and procedural 
> arrangements that would lead to different degrees of "coupling" between 
> the producers, librarian, and consumers.  [can you clarify assumptions?]

    My assumptions were essentially a production environment, but I
    would certainly be interested in hearing about these different 
    arrangements you visualize relative to the degree of coupling. 

> I'm thinking of a software development organization that produces 
> "products" (where the consumers may be outside customers or internal 
> users), and has several projects going on at once (some of which may be 
> related).  Rather than having a separate group of "component producers", 
> components would be produced as spinoffs of normal development activity.  

    Under my scenario, this would occur whenever the component librarian
    determines that it would be more efficient to produce a component
    locally (rather than purchase it on the open market).  The work order
    would then go out to an engineer for production; generally if a series
    of similar components are to be produced, related work orders would be
    routed to the same location. 

    This assumes, of course, that a requirement has already been established
    for a given component.  From the passage, I infer that you may be talking
    about producing components simply because the production costs are low
    due to the existence of related work.  This is where the librarian and
    the reuse community must confer during the evaluation of the marginal
    production cost and the anticipated future value, the latter being an
    extremely difficult quantity to assess accurately.  Where component 
    production orders are approved, it is extremely important that a) the 
    marginal production costs be tracked separately and NOT billed to the 
    customer, and b) these production costs are closely monitored by the
    librarian along with the usage benefits, in order to develop heuristics
    which will maximize the cost-effectiveness of such decision-making. 

    One of the heuristics most likely to be productive in this respect is
    to follow closely the research stemming from what I consider to be a 
    landmark paper on the topic: "Domain Analysis -- From Art Form to 
    Engineering Discipline", by Guillermo Arango of UC-Irvine's Advanced
    Software Engineering Project.  It's on pages 152-159 of ACM SIGSOFT
    Software Engineering Notes, Volume 14, Number 3, May 1989 -- I heavily 
    recommend it to any and all readers of this newsgroup. 


    Bill Wolfe, wtwolfe@hubcap.clemson.edu

    [ P.S. -- Ralph Johnson and I are having an interesting discussion 
      of specification vs. implementation topics via e-mail, and I would 
      like to publicly apologize for the strong tone of my initial reaction 
      to his article.  It was not initially apparent to me that he supported 
      the general principle of separating specification from implementation,
      so I shall include a bit of crow in all of my turkey sandwiches!!! :-) ]