Managing Reuse Presented by: Aisha Al-Hammadi

Outline Introduction History. The technical and managerial advantages of Reusing Solutions. The main challenges that encounter Reuse. Documenting Reuse The documentation of a reusable solutions. The documentation of the system that is reusing the solution. Assigning Responsibilities The main roles involved in reuse.

Introduction History. SW development started as a craft (job) Represented only a fraction of the hardware With the price of hardware dropping & computing power increasing # of customers & the range of applications has broadened dramatically SW costs increase as applications became more complex Putting a huge economic pressure at the project manager to reduce the cost Systematic reuse of code, designs & processes became an attractive solution This reaches the point of the problem that and

The technical and managerial advantages of Reusing Solutions. Lower development effort. Lower risk. When reusing a solution or a component, many standard errors are avoided. In the case of design patterns, the resulting system is more easily extended and more resilient to typical changes. This results in less development effort & reduce the need for human resources, which can be redirected to testing the software to ensure better quality. When reusing repetitively the same design pattern or component, the typical problems that will be encountered are known & can be anticipated. The time needed to adapt the design pattern or to glue the component is also known, resulting in a more predictable development process & fewer risks. Widespread use of standard terms. The reuse of standard set of design patterns and components fosters the use of a standard vocabulary. as an example, terms such as Adapter, Bridge, Command, or Façade denote precise concepts that all developers became familiar with. This reduce the number of different terms and solutions to common problems & reduce misunderstandings among developers. Increased reliability. Reuse by itself does not increase reliability or reduce the need for testing. Components & patterns solutions that worked in one context can exhibit unexpected failures in other contexts. Culture of reuse in a SW organization can increase reliability for all of the above reasons. Reduced development time can lead to an increased testing effort. Repetitive use of component can lead to a knowledge base of typical problems to be anticipated. Use of standard terms reduces communication failures. Back

The main challenges that encounter Reuse within a development organization. NIH (Not Invented Here) syndrome Process support Training Since SW engineering education emphasizes mostly the design of new solutions, developers often distrust the reuse of existing solutions, especially when the customization of the solution under consideration is limited. Developers believe that they can develop a completely new solution that is better adapted to their specific problem in less time than what they need to understand the reused solution. The processes associated with identifying, reusing, and customizing an existing solution are different than those involved in creating a brand new solution. The 1 st set of activities requires painstakingly sifting through a large and evolving corps of knowledge and carefully evaluating the findings. The 2 nd set of activities requires creativity and a good understanding of the problem. Most SW engineering tools and methods are better adapted to creative activities than to reuse. Given the lack of knowledge support tools for reuse, training is the single most effective method in establishing a reuse culture. The burden of education developers to specific reusable solutions and components falls on the development organization.

Documenting Reuse The documentation of a reusable solutions. It includes not only a description of the solution, but also a description of: (the class of problems it addresses, the traded-offs faced by the developer, alternative implementations, and examples of use). This documentation is typically difficult to produce, as the author of the reusable solution may not be able to anticipate all the problems it can be used for. It is usually generic and abstract and must be illustrated by concrete examples for novice developers to fully understand the parameters of the solution. Documentation each time they reuse a solution is usually not ideal. How can we solve this problem?

Developers can incrementally improve this documentation by adding the following: Reference to a system using the solution. Example of use. Alternative solutions considered. Encountered trade-offs. Minimally, the documentation of the reusable solution should include references to each use. If defects are discovered in the reused solution, these defects can be systematically corrected in all occurrences of reuse. Examples are essential for developers to understand the strengths and limitation of the reused solution. Developers should include a brief summary explaining the problems being solved and the adapted solution. Selecting the wrong pattern can lead to more problems than developing a custom solution. In the documentation of the example, developers should indicate which other candidate solutions they discarded and why. Especially in the case of frameworks and components, often entails making A compromise and selecting a less than optimal solution for some criteria. example, one component may offer an interface that is extensible, and another may deliver better response time.

The documentation of the system that is reusing the solution. The documentation of the system under construction should minimally include references to all the reused solutions. For more explanations, explicitly documenting which classes use which components makes it easier to adapt the client classes to newer versions of the reused components. As an example: A contributing factor for the high cost of change late in the process is the loss of design context so we can find that developers forget quickly the reasons behind designing complicated workarounds or complex data structures during early phases of the process.

Assigning Responsibilities The main roles involved in reuse: Component expert : Pattern expert: Technical writer: Configuration manager: In addition to tracking configurations and versions of individual subsystems, the configuration manager must also be aware of the versions of the components that are used. While newer versions of the components may be used, their introduction requires tests to be repeated and changes related to the upgrade documented. The component expert is familiar with using a specific component. The component export is a developer and usually has received third-party training in the use of the component. The pattern expert is the analog of the component export for a family of design patterns. Pattern experts are usually self-made and acquire their knowledge from experience. The technical writer must be aware of reuse and document dependencies between components, design patterns, and the system. This may require the technical writer to become familiar with the solutions typically reused by the organization and with their associated terms. Individual developers assigned to subsystems will not spontaneously turn to design patterns and components unless they have experience with these topics. The success factors associated with reuse are actually not technical, but managerial. Back

Questions: What is (are) the factor(s) that increase reliability or reduce the need for testing the reusing solutions: a. Lower development effort.b. Lower risk. c. Widespread use of standard terms.d. All of the above. “…………………………….. must be aware of reuse and document dependencies between components, design patterns, and the system. a. Component expert.b. Pattern expert. c. Technical writer.d. Configuration manager. The success factors associated with reuse are: a. Technical & managerial.b. not technical neither managerial. c. Not technical, but managerial.d. none of these. Refer. Slide

Thanks for your attention