dwiggins@atsun.a-t.com (Don Dwiggins) (11/14/89)
I'd like to raise an issue in another direction from most of the topics I've seen here, but well within the topic of SW components. Given a large number of potential components within an organization, how are they to be organized, made available, kept current, validated, etc.? Roughly, what is the role and task of the "software component librarian"? Here are some questions in this area; you may wish to respond to some of the unstated assumptions as well as the questions themselves. Opinions are welcome, of course, but experience would be even more valuable. How much effort and resource expenditure is worth putting into building and maintaining this library? Is something like the comp.sources.xx archives adequate, with minimal maintenance, reliance on authors for description and quality, and a sort of caveat emptor approach to distribution? In the following questions, I'll assume that a more active approach is called for. What measures of quality should be expected of a component, e.g. freedom from bugs, portability, generality, optimality in some dimension? How are these to be assured? Who's responsible for this: the original authors, the librarian, the user community? It seems to me that separation of functional specification from implementation is at least a Good Thing, if not absolutely necessary for a viable library. This would allow a variety of implementations that meet the spec, and that vary in their performance details (memory, speed, language, operating system, etc.). In addition, there should be a hierarchy of generality of the specs, so that a user can pick the most specific (and thus presumably the most efficient) specification that suits his needs. Is this overkill? Are there problems or pitfalls here? How are improvements/upgrades/fixes to the components to be managed? Do we try to keep track of the folks who've "checked out" components and notify them of the new stuff? Should there be a way to "obsolete" components? Generally, what does configuration management look like in this environment? A final note: these questions are set in the context of a single organization, assuming a cooperative, open community. A similar discussion would revolve around various commercial settings. -- Don Dwiggins "Solvitur Ambulando" Ashton-Tate, Inc. dwiggins@ashtate.a-t.com dwiggins@ashtate.uucp
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/15/89)
From dwiggins@atsun.a-t.com (Don Dwiggins): > what is the role and task of the "software component librarian"? To manage an interface between component producers and component users. > How much effort and resource expenditure is worth putting into building and > maintaining this library? Is something like the comp.sources.xx archives > adequate, with minimal maintenance, reliance on authors for description and > quality, and a sort of caveat emptor approach to distribution? Components should be categorized as to quality; the task of doing this is simplified considerably by the existence of a software components marketplace. Unfortunately, the currently large number of programming languages in production use fragments the market, and has been a major inhibitor. Another problem is the existence of languages which are not standardized and for which no compiler validation capability exists. > What measures of quality should be expected of a component, e.g. freedom > from bugs, portability, generality, optimality in some dimension? How are > these to be assured? Who's responsible for this: the original authors, the > librarian, the user community? All of these should be expected of a professionally written component. Assurances can be obtained in the form of product reviews, explicit guarantees from the manufacturer, etc.; where such quality information is not available (e.g., when the component is locally produced), the librarian should give the component an appropriate classification. If there is sufficient user demand for a component of higher quality, the librarian should consider whether the demand will justify the expenditure of the testing resources needed to achieve a higher classification. > It seems to me that separation of functional specification from > implementation is at least a Good Thing, if not absolutely necessary for a > viable library. This would allow a variety of implementations that meet the > spec, and that vary in their performance details (memory, speed, language, > operating system, etc.). In addition, there should be a hierarchy of > generality of the specs, so that a user can pick the most specific (and thus > presumably the most efficient) specification that suits his needs. Is this > overkill? Are there problems or pitfalls here? It's not overkill; this is one of the big advantages of using a good component catalog. Major problem, IMHO, is the fact that a good-sized market is required to sustain this kind of a selection, and the above- mentioned market fragmentation makes this very difficult to achieve. > How are improvements/upgrades/fixes to the components to be managed? Do we > try to keep track of the folks who've "checked out" components and notify > them of the new stuff? Should there be a way to "obsolete" components? > Generally, what does configuration management look like in this environment? If the components are local, and written in Ada, then Ada already provides configuration management. Otherwise, some sort of tool is needed for local configuration management. If the components are non-local, then arrangements will probably have to be made with the component's manufacturer or distributor. Bill Wolfe, wtwolfe@hubcap.clemson.edu