These goals are not, of course, unique (cf. [5,8]). However, they imply some important and not so obvious side conditions we have not encountered in other research efforts. These side conditions will be discussed later on. First, please bear with us while we make some remarks on the goals in order to provide some insight into what we mean by them.
By the characteristic properties of an effective reuse repository we do not only mean technical properties such as the component classification mechanism, tools for component retrieval and the kind of version management, but also more ``managerial'' ones such as the quality control process and incentive schemes. Characteristic properties should therefore be taken in the widest possible sense.
There is a surprisingly large number of issues that needs to be addressed before any repository can be constructed (see [1,4]). We will give two examples. First, it is generally agreed that a repository containing only code components has limited benefits ([1]); design or even requirement reuse is expected to have a higher pay-off potential. There is a practical question-mark, however: source code has a natural representation, but what (formal) language is used to represent designs? There are many possible choices, but little is known about their effectiveness in transporting knowledge from the author of a design to a possible reuser.
The other example is the issue of white-box reuse versus black-box reuse: in the case of black-box reuse the reuser cannot change a code component, whereas in the white-box case he or she has the possibility to change it. The advantages of black-box reuse are that (1) the documentation does not need to be written or rewritten (it is already there), (2) the understanding of the program during maintenance or bug fixing is facilitated and (3) more support can be given in the event of an error being found in a component. The advantages of white-box reuse are that the likelihood that a component can be (partially) reused increases and that partial reuse is more effective than writing from scratch. Although many advocate white-box reuse, in this instance, too, it is not yet clear what the most cost-effective alternative is or, more generally, what the essential factors that are determine which alternative to take.
The second goal takes the reuse technology a step further than the first. The intention of the second goal is to make the construction of an effective repository a clearly defined and manageable task. Moreover, it should make it a repeatable effort, not relying on reuse researchers. A great deal of effort has already been put in this topic, see, for example, [5,8].
For the second goal, totally different, but nevertheless related, issues than for the first goal need to be addressed. For example: a characteristic property will be the way in which domain knowledge is represented. For the second goal it will be necessary to describe the process of acquiring such knowledge. Another example concerns the components. For the first goal it is sufficient to know that a component can be a piece of source code or a piece of design (or ...). A question that needs to be answered for the second goal is how components are constructed. Are they developed from scratch or are they to be found in the existing software (salvaging)? If the latter is the case, the question arises as to what kind of tools, techniques, and methods are needed. Furthermore, little is yet known about which alternative is in the long run economically the most attractive: development for reuse or software salvaging.
In the remainder of this paper we will discuss some important properties of software development at the Laboratory, our approach to fulfill the goals as stated in the foregoing, and we will conclude with some remarks.