Process

It was generally agreed that the tools should support the process rather than dictate it. Many current tools support their own process (some more directly than others) and this process may or may not fit with the processes used by a specific organization. If the tool's process is an improvement over the one in current use then the organization may profit by adapting their process to the one supported by the tool. There may be cultural barriers or large costs to overcome to ensure that such a change is profitable. One way for an organization to avoid this barrier is to select processes with existing tool support. However, more often than not, a tool's process is not better or does not fit the organization.

Many organizations select tools without consideration of the process and only to discover it is very difficult, if not impossible, to change a tool's process. Furthermore, there is also little back/forward compatibility tool version or version or among tools in a once compatible set. Other process issues that hamper reuse are:

1. The interoperability of life cycle phases e.g., products from the requirements phase are not directly supported and utilized in the design phase and so on. Current tools often add to this problem rather that remedy it. Or, one tool supports a phase very well but cannot be used with a tool that supports a different phase.

2. Along these same lines, systematic reuse changes the normal meaning of traceability from its role in assuring consistency from requirements and the implementation of a single product to a role that emphasizes the variability and difference in requirements among products.

3. Reengineering is not treated as part of the reuse process and is a vital source of knowledge and may provide critical reusable assets.

4. Insertion of reuse technology may promulgate change in the processes an organization follows, how the organization is structured, or what requirements are needed in the set of tools used by organization.