Software Reuse - the REBOOT consortium
Andre Karlsson et al

How do you develop FOR reuse?

These steps are generic and can be applied at any stage in the development process and system structure. They do not necessarily form a strict sequence - we may iterate over steps 4 to 8 several times. The resources we put into each of these steps depends on the size of the component:
  1. Capture the initial requirements, collecting the set of requirements to make an initial solution.

  2. Define an initial solution or identify previous solutions to the same set of requirements. It is best to keep the solution in a form that customers can understand and validate. In the case of re-engineering, the result of this step should be the identification of previous solutions. A cost estimation for developing the actual solution should be made or updated at this time.

  3. Identify possible generalizations. This is the inventive step in which we try to see the generality in our requirements and our solution, based on both the requirements and the initial solution. At this step the component's reuse potential should be discussed with the product management and the plan for following steps should be refined.

  4. Identify potential reusers and collect their requirements. Potential reusers are important to ensure that the generality we include in our component is really justified.

  5. Estimate the cost and benefit of added functionality. For each added requirement we must estimate:

    Each potential reuser should also estimate the effort needed to develop the functionality he needs from scratch, and the probability that he will reuse the component.

  6. Analyze the added requirements with respect to invariants and variation. This is the step that involves making a requirements hierarchy such as that illustrated in Figure 78. The hierarchy usually impacts the initial solution, and we should therefore be prepared to modify it if necessary.

  7. Propose a generalized solution with specializations and cost estimates. Here we reconcile the different requirements into one solution by applying techniques to represent generality from the appropriate models.

  8. Present the solution to reusers and reuse experts for validation and approval. Each reuser must ensure that the solution covers his requirements. He should also refine the estimate of how much it will cost him to reuse the component. The reuse expert's role is to ensure that the solution is satisfactory, to check that the proposed specializations are appropriate.

    Based on this input, we can decide if we will develop the component for reuse. All the estimates made during the analysis of requirements and solutions should be saved to enable comparison with actual data (see Chapter 4). Note that this step is taken before we start the bulk of the development effort.

  9. Develop and document the solution. This is the final step where we implement the component or system. If we are developing a high-level component (Figure 76) we may repeat this process for reusable subcomponents. We discuss the documentation needed separately in Section 7.7.

Development FOR reuse guidelines

Analysis Architectural Design Detailed Design Implementation Test

How do you develop WITH reuse?

These steps are equally applicable at any level of the system structure (the customer for lower-level components will be the designer at the level above the component). Steps 2, 3 and 4 may need to be iterated until we find a suitable component. For subcomponents, these activities can be run in parallel with the search and adaptation of the component. For example, we may know that we need a graphical library, and start searching for it immediately.
  1. Identify the components needed to build the application and which could be reused, derived, or adapted from existing reusable components.

    These components can be of several types:

    Note that in some cases (e.g. in a mature domain), guidelines, standards and application generators may be of benefit, but here we mainly deal with components which will compose the application.

  2. Formalize the requirements for these components in terms of search conditions, and search for candidate components. The search for components can start as soon as we have some idea of the needed functionality. Early retrieved components can serve as a basis for refining the requirements.

  3. Evaluate the retrieved candidates. During the analysis phase it may be possible to negotiate requirements with the customer. If the customer can save 90% of the cost by sacrificing 10% of the functionality, he should at least be aware of the option. It might also be that the retrieved components provide some functionality which the customer might want in addition to the functionality he has specified.

  4. Choose the best candidate and investigate the chosen component thoroughly. Detailed understanding may lead you to reject the chosen component and consider another candidate.

  5. Adapt the component if necessary, and integrate it (possibly with adaptation) into the application.

Development WITH reuse guidelines

Analysis guidelines Architectual Design guidelines Implementation guidelines