Software Reuse - Architecture, Process, and Organization

Ivar Jacobson, Martin Griss, Patrik Jonsson

Re uisite !rinci!"es 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. aintain top!management leadership and financial backing over the long term. ". #lan and adapt the system architecture, the development processes, and the organization to the necessities of reuse in a systematic but incremental fashion. $tart with small pilot pro%ects, and then scale up. &. #lan for reuse beginning with the architecture and an incremental architecting process. '. ove 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.

(. )reate and evolve reusable components in a real working environment. *. anage application systems and reusable components as a product portfolio of financial value, focusing reuse on common components in high!payoff application and subsystem domains.

+. ,ealize that ob%ect or component technology alone is not sufficient. -. .irectly address organization culture and change, using champions and change agents. /. Invest in and continuously improve infrastructure, reuse education, and skills. 10. easure reuse progress with metrics, and optimize the reuse program. Introduction 1,euse only succeeds within a structure with separate creator and utilizer teams, and high!level management leadership and support.1 2 artin 3riss4 This assertion suggests a 1dual life cycle1 approach is necessary to meaningfully address reuse. 5ne life cycle focuses on product lines and reusable assets, and is routinely labelled .omain 6ngineering. The other life cycle produces individual products, and is called 7pplication 6ngineering. 8acobsob, 3riss, and 8onsson propose an approach they call the 1,euse!driven $oftware 6ngineering 9usiness1 :,$69;.

The ,$69 does not have an explicit .omain 6ngineering process, but distributes its activities between the first two of the four processes described below. A!!"ication #a$i"% &ngineering 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. 'o$!onent S%ste$ &ngineering designs, constructs, and packages the reusable entities architected in 7pplication =amily 6ngineering 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. A!!"ication S%ste$ &ngineering then selects, specializes, and assembles components from one or more component systems into complete application systems. These applications are largely constrained to 1fit1 the architecture and the components. 7 fourth process, (ransition to a Reuse )usiness, provides advice on establishing a specific reuse business that conforms to the ,euse 9usiness model. It describes a systematic transition, combining business engineering techni>ues with change management and reuse!specific guidelines. A!!"ication #a$i"% &ngineering 1. )apturing re>uirements that have an impact on the architecture =ind out who the customers and the end users are and the needs and expectations they have. ake a first approximation of a product plan and use it to decide which parts to focus on. #erform the first iteration of re>uirements capture and analysis to find actors and use cases. $elect the most important (!"0? of the use cases and describe them. .o some analysis of use case variability. ". #erforming robustness analysis @se the selected use cases to identify candidate application and component systems using a high!level analysis model. &. .esigning the layered system

@se 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, 3@I toolkits, utility class libraries, ob%ect re>uest brokers, and so on. @se interaction diagrams to divide the use cases among the application and component systems in order to precisely define facades and interfaces. .evelop a first version of the concurrency model and the deployment model. '. Implementing the architecture as a layered system @se the product plan to schedule the work on each application and component system. ,eview 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 )ommercial 5ff The $helf :)5T$; systems such as ob%ect re>uest brokers. (. 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. )apture lessons learned. 'o$!onent S%ste$ &ngineering 1. )apturing re>uirements focusing on variability )ollect input from reusers, business models, models of the superordinate system, domain experts, customers, and end users. #repare a use case model of the component system and make sure that variability re>uirements are captured. 7ssess the value and cost of each use case and decide whether or not to include it in the next release. 7lso analyze how best to organize the facades and re>uirements on processes :$6# ! sw enging processes; and the tools :$6#$6 ! sw enging env and tools; to be used with the component system. ". #erforming robustness analysis @se the use cases to identify analysis ob%ects and packages and express variability. @se facades to export the analysis components.

&. .esigning the component system @se the analysis model as an input to prepare a design model of the component system. 7dapt the design model to the implementation environment. @se se>uence diagrams to distribute the use cases among the subsystems in order to precisely define interfaces. @se facades to export the design components. '. Implementing the component system Implement the new version of the component system, review the implementation, and select technology for delivery. @se facades to export the implementation components. (. Testing the component system Test the component system for reuse. *. =inal packaging of the component system .ocument and package the component system and its facades for easy use and retrieval by reusers. A!!"ication S%ste$ &ngineering 1. )apturing re>uirements This is initiated by a customer in order to prepare a use case model of an application system, by reusing use case components. )ollect input primarily from the customer and end users but also from business models and the models of the superordinate system. 7ssess the value and cost of each use case, negotiate and decide whether or not to implement it in the next release. ". #erforming robustness analysis @se the use case model as an input to assemble and specialize analysis model components. 5nly extend the architecture provided by the component systems when necessary. &. .esigning the application system @se the analysis model as an input to assemble and specialize design components. '. Implementing the application system

@se the design model as an input to assemble and specialize implementation components. (. Testing the application system 7ssemble and specialize test specification components and then test the application system. *. #ackaging the application system #ackage the application system for use by the application manufacturers, installers, or end users. (ransition to a Reuse )usiness 1. )reating 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. anagement empowers an initial group of people :the transition team; to envision the reuse business. ". 6nvisioning the new reuse business 9ased on business needs and the initial 7pplication =amily 6ngineering efforts, the ,$69 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 ob%ective statement. $ome transition plans are developed, in which several versions of a reuse business might be defined as intermediate points for incremental adoption. $ignificant communication begins and key stakeholders are engaged in the transition. &. ,everse 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. '. =orward engineering the new reuse business

.evelop the desired software engineering processes :$6#;, organization, and appropriate software engineering environment and tools :$6#$6;. (. Implementing the new reuse business The new model is installed into the business. #eople are trained, and processes, organization, architectures, and systems are :incrementally; replaced. *. )ontinuous #rocess Improvement 7s 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.