Software Reuse - Architecture, Process, and Organization
Ivar Jacobson, Martin Griss, Patrik Jonsson

Requisite principles

In recounting the experience of many organizations with reuse in this chapter, we encountered a number of principles that appeared to be common to most of them. To achieve systematic software reuse, an organization must keep this set of principles in mind:
  1. Maintain top-management leadership and financial backing over the long term.

  2. Plan and adapt the system architecture, the development processes, and the organization to the necessities of reuse in a systematic but incremental fashion. Start with small pilot projects, and then scale up.

  3. Plan for reuse beginning with the architecture and an incremental architecting process.

  4. Move to an explicitly managed reuse organization which separates the creation of reusable components from their reuse in application systems, and provides an explicit support function.

  5. Create and evolve reusable components in a real working environment.

  6. Manage application systems and reusable components as a product portfolio of financial value, focusing reuse on common components in high-payoff application and subsystem domains.

  7. Realize that object or component technology alone is not sufficient.

  8. Directly address organization culture and change, using champions and change agents.

  9. Invest in and continuously improve infrastructure, reuse education, and skills.

  10. Measure reuse progress with metrics, and optimize the reuse program.

Introduction

"Reuse only succeeds within a structure with separate creator and utilizer teams, and high-level management leadership and support." [Martin Griss] This assertion suggests a "dual life cycle" approach is necessary to meaningfully address reuse. One life cycle focuses on product lines and reusable assets, and is routinely labelled Domain Engineering. The other life cycle produces individual products, and is called Application Engineering. Jacobsob, Griss, and Jonsson propose an approach they call the "Reuse-driven Software Engineering Business" (RSEB). The RSEB does not have an explicit Domain Engineering process, but distributes its activities between the first two of the four processes described below.

Application Family Engineering determines how to decompose the business's core applications into a suite of application systems and supporting component systems. The process architects the layers, facades, and interfaces of the subsystems and component systems that support the complete family of related applications.

Component System Engineering designs, constructs, and packages the reusable entities architected in Application Family Engineering into component systems. The process will use appropriate code, templates, models, dictionary, documents, and perhaps custom tools. The goal is a consistent model that explicitly expresses commonality and variability across the suite of applications that will reuse these components.

Application System Engineering then selects, specializes, and assembles components from one or more component systems into complete application systems. These applications are largely constrained to "fit" the architecture and the components.

A fourth process, Transition to a Reuse Business, provides advice on establishing a specific reuse business that conforms to the Reuse Business model. It describes a systematic transition, combining business engineering techniques with change management and reuse-specific guidelines.

Application Family Engineering

  1. Capturing requirements that have an impact on the architecture

      Find out who the customers and the end users are and the needs and expectations they have. Make a first approximation of a product plan and use it to decide which parts to focus on. Perform the first iteration of requirements capture and analysis to find actors and use cases. Select the most important 5-20% of the use cases and describe them. Do some analysis of use case variability.

  2. Performing robustness analysis

      Use the selected use cases to identify candidate application and component systems using a high-level analysis model.

  3. Designing the layered system

      Use the first version of the analysis model to prepare a prototype design model that defines the layered system in terms of application and component systems. Take advantage of legacy systems, third-party products, GUI toolkits, utility class libraries, object request brokers, and so on. Use interaction diagrams to divide the use cases among the application and component systems in order to precisely define facades and interfaces. Develop a first version of the concurrency model and the deployment model.

  4. Implementing the architecture as a layered system

      Use the product plan to schedule the work on each application and component system. Review the architecture and the plan. Implement the first version of the most important and risk-sensitive application and component systems, facades, interfaces, and processes. Integrate legacy systems and Commercial Off The Shelf (COTS) systems such as object request brokers.

  5. Testing the layered system

      Test each application and component system both by itself and also as part of the layered system as a whole. Testing the layered system is particularly important for application systems that interoperate. Test against the most notable risks and measure its performance. Capture lessons learned.

Component System Engineering

  1. Capturing requirements focusing on variability

      Collect input from reusers, business models, models of the superordinate system, domain experts, customers, and end users. Prepare a use case model of the component system and make sure that variability requirements are captured. Assess the value and cost of each use case and decide whether or not to include it in the next release. Also analyze how best to organize the facades and requirements on processes (SEP - sw enging processes) and the tools (SEPSE - sw enging env and tools) to be used with the component system.

  2. Performing robustness analysis

      Use the use cases to identify analysis objects and packages and express variability. Use facades to export the analysis components.

  3. Designing the component system

      Use the analysis model as an input to prepare a design model of the component system. Adapt the design model to the implementation environment. Use sequence diagrams to distribute the use cases among the subsystems in order to precisely define interfaces. Use facades to export the design components.

  4. Implementing the component system

      Implement the new version of the component system, review the implementation, and select technology for delivery. Use facades to export the implementation components.

  5. Testing the component system

      Test the component system for reuse.

  6. Final packaging of the component system

      Document and package the component system and its facades for easy use and retrieval by reusers.

Application System Engineering

  1. Capturing requirements

      This is initiated by a customer in order to prepare a use case model of an application system, by reusing use case components. Collect input primarily from the customer and end users but also from business models and the models of the superordinate system. Assess the value and cost of each use case, negotiate and decide whether or not to implement it in the next release.

  2. Performing robustness analysis

      Use the use case model as an input to assemble and specialize analysis model components. Only extend the architecture provided by the component systems when necessary.

  3. Designing the application system

      Use the analysis model as an input to assemble and specialize design components.

  4. Implementing the application system

      Use the design model as an input to assemble and specialize implementation components.

  5. Testing the application system

      Assemble and specialize test specification components and then test the application system.

  6. Packaging the application system

      Package the application system for use by the application manufacturers, installers, or end users.

Transition to a Reuse Business

  1. Creating a directive to reengineer the software business

      The management of the company creates and publicizes a reengineering directive, as a clear statement of the high-level reuse business goals and their rationale. The directive defines and communicates the initial business, process, architecture, organization, and reuse goals. It defines the scope of the changes and establishes accountability. Management empowers an initial group of people (the transition team) to envision the reuse business.

  2. Envisioning the new reuse business

      Based on business needs and the initial Application Family Engineering efforts, the RSEB transition team develops a high-level vision of the new architecture, software business processes, and organization. They identify stakeholders, champions, and early adopters. The specific goals are documented in an objective statement. Some transition plans are developed, in which several versions of a reuse business might be defined as intermediate points for incremental adoption. Significant communication begins and key stakeholders are engaged in the transition.

  3. Reverse engineering the existing software development organization

      The transition team identifies and studies the existing architecture, software assets, software processes, organization, tools, and baseline measures. The goal is to understand and baseline current software engineering practice, identify assets, determine the status of reuse, and understand organization issues.

  4. Forward engineering the new reuse business

      Develop the desired software engineering processes (SEP), organization, and appropriate software engineering environment and tools (SEPSE).

  5. Implementing the new reuse business

      The new model is installed into the business. People are trained, and processes, organization, architectures, and systems are (incrementally) replaced.

  6. Continuous Process Improvement

      As the new business becomes operational, collect and analyze reuse process and product metrics to measure progress, identify key areas for further improvement, and then make small process changes.