Assumptions and Concepts

Reuse makes particular assumptions about the nature of software work. In addition, research results and reports of practical experience offer numerous insights into reuse. The following points are particularly relevant to this project:

1. Reuse is a promising idea, but general applicability is hard to determine.

   Researchers have reported encouraging results for formal reuse systems in a few production environments. However, some of the most encouraging results are based on judgement not measurement [Lane 84], and some reports offering measurements do not clearly define the measures [Lenz 87]. In addition, there are indications that several of the production environments studied may have unusual characteristics [Mats 90]. These factors make it difficult to evaluate the results.

2. Reuse requires substantial commitment.

   Adopting a formal reuse strategy has major financial and organizational implications. The financial issues include:

   1. Reusable components are more expensive to produce [Lenz 87]. In part, this is due to the cost of domain analysis [Prie 90]. There is also overhead associated with the system for managing reusable components.
   2. The size and useful life of components may limit the value of reuse. Larger components tend to be more specific and so less likely to be needed repeatedly [Bigg 87]. In addition, as technology changes and as the organization changes, the probability that a component will be useful diminishes.
   3. Common business practice may prevent the development of component collections large enough to support a viable level of reuse [Luba 86]. Ratcliffe concluded that ``.. the whole western economic system may be against reuse'' [Ratc 86].

      If sharing components is not a realistic alternative, perhaps reuse is a viable strategy for only the small number of organizations that have very, very large software portfolios or very high recurrence of software needs.

   There are also organizational issues:

   1. Software workers may resist reuse. Cavaliere and Lenz both encountered this resistence [Cava 83,Lenz 87].
   2. Reuse affects the many aspects of software work. Meyers relates reuse and extendibility [Meye 87]. Basili relates reuse and maintenance [Basi 90]. On a different level, Tracz notes that software reuse effects elegance, quality, and discipline of software work [Trac 88]. In short, reuse affects what we do, what the artifact looks like, and how we think about the process.

   Reuse requires substantial management and financial commitment [Bigg 89]. Any organization considering a formal reuse approach must weigh this commitment against potential benefits that are not clear overall and harder still to predict within the context of a single organization.

3. Reuse assumes recurring need for software artifacts.

   The potential value of reuse depends on the amount of recurrent need. If a high percent of all software work is repeated, the potential value of reuse is higher. If the percent is low, the potential is lower too.

   The potential value of reuse also depends on the exact nature of similarity and difference each time a ``similar'' need recurs. Differences require adjusting the existing artifact for the new need. This adjustment lowers the value of reuse.

4. Software portfolios may provide a way to explore reuse potential.

   Predicting recurrent need for software requires that we know what software will be requested in the future. While we do not know the future, we do know what needs were met in the past. We can use our knowledge of the past to suggest the nature of future needs.

   This study uses software portfolios as a representation of past software needs. Analysis of the portfolio should provide indication of both the level of recurrence and the nature of differences.