Background

From a study of the research conducted into the problems associated with software reuse and also from the industrial experiences of companies trying to employ reuse we, in harmony with others, have identified a basis on which the success of reuse depends. We believe that for reuse to flourish, it must be viewed as an integral part of the software life cycle. Changes must be made to the way in which industry views reuse. Industry needs to move away from simply the reuse of code and certainly away from the attitude that it is acceptable not to consider reuse at all. We examined why these attitudes have existed and our studies have led us to the conclusion that there are a number of inhibiting factors which limit the appeal of reuse to project managers and software developers. These inhibiting factors include, at a technical level:

• development - Knowing what kind of software is reusable and as equally difficult is knowing how to develop a software component which is potentially reusable.
• storage - Once we have developed an item of reusable software how, and where, should it be retained for future retrieval and reuse.
• retrieval - If we are to reuse software then we must be able to easily find what we require matching what is available with our needs.
• verification - How can we be sure that the component which we are proposing to reuse actually performs the functions that it claims it does in the environment in which we use it.
• evaluation - How can we judge that the functions we require from our reusable unit and the functions that it provides are the same.
• modification - If our evaluations have shown that differences exist in the reuse unit's and our requirements then how do we perform the necessary modifications and what effect will this have on the reusable unit including the results of previous verifications.
• integration - What will the effect be on the reusable unit of attempting to integrate it into our development.

We thus came to the realisation that the underlying technical reason why reuse was not as successful is that developers would have liked as the inhibiting factors which we have described above increase development risks. Since project managers tend towards the path with the smallest risks they thus often, and rightly given the circumstances, tend to develop 'from scratch'. We therefore consider that if reuse is to be successful we need to indicate its tangible benefits to project managers by reducing the risks associated with development and especially when reuse is being considered. In addition it should strive to make reuse a continuous and integral part of the software development process as this has an effect both on risks and acceptability of risks.

We acknowledge that there are other factors affecting the take up of reuse e.g. individual motivations but such issues are outside the realm of this paper.