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:
-
Maintain top-management leadership and financial backing over the long
term.
-
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.
-
Plan for reuse beginning with the architecture and an incremental
architecting process.
-
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.
-
Create and evolve reusable components in a real working environment.
-
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.
-
Realize that object or component technology alone is not sufficient.
-
Directly address organization culture and change, using champions and
change agents.
-
Invest in and continuously improve infrastructure, reuse education, and
skills.
-
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
- 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.
- Performing robustness analysis
Use the selected use cases to identify candidate application and
component systems using a high-level analysis model.
- 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.
- 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.
- 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
- 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.
- Performing robustness analysis
Use the use cases to identify analysis objects and packages and
express variability. Use facades to export the analysis components.
- 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.
- 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.
- Testing the component system
Test the component system for reuse.
- 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
- 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.
- 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.
- Designing the application system
Use the analysis model as an input to assemble and specialize
design components.
- Implementing the application system
Use the design model as an input to assemble and specialize
implementation components.
- Testing the application system
Assemble and specialize test specification components and then test
the application system.
- Packaging the application system
Package the application system for use by the application
manufacturers, installers, or end users.
Transition to a Reuse Business
- 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.
- 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.
- 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.
- Forward engineering the new reuse business
Develop the desired software engineering processes (SEP),
organization, and appropriate software engineering environment and
tools (SEPSE).
- 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.
- 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.