What is Software Reuse?
Copyright Lombard Hill Group
The purpose of this document is to provide a brief introduction to software reuse. It defines software reuse and its basic mechanics, describes what motivates organizations to pursue reuse and how the engineer's and manager's tasks will change with reuse, and explains how to get started in reuse. If you feel that you would like more information after having read this document, please feel free to contact the Lombard Hill Group at firstname.lastname@example.org.
WHAT IS SOFTWARE REUSE?
Software reuse is the use of existing assets in some form within the software product development process. More than just code, assets are products and by-products of the software development life cycle and include software components, test suites, designs and documentation. Leverage is modifying existing assets as needed to meet specific system requirements. Because reuse implies the creation of a separately maintained version of the assets, it is preferred over leverage.
Current thinking is that reuse is most effective when it is practiced systematically. Systematic reuse is when reuse of assets is planned with well-defined processes and life cycles, commitments for funding, staffing, and incentives for production and use of the reusable assets.
Reuse can be achieved through different modes. Compositional reuse involves constructing new software products by assembling existing reusable assets, while generative reuse involves the use of application generators to build new applications from high level descriptions.
Leveraging involves the modification of previously developed software for a new product. When managed correctly, leveraging can be advantageous over creating software from scratch in that it requires less time and effort. On the other hand, because it is difficult to correctly predict the impact of modifications, leveraging may result in lower quality software. It can also lead to multiple versions of a software component and consequently, an increased maintenance burden.
MOTIVATIONS FOR REUSE
Today's organizations face competitive pressures in shortening the time required to bring a product to the market, reducing software development and maintenance costs, and increasing the quality of their software. While not a panacea, organizations have increasingly turned to a reuse strategy in order to meet their business goals. Implemented appropriately, reuse can aid in achieving some or all of the following goals:
* Increase productivity
After an initial investment, reuse of existing assets will enable projects to decrease the cost of developing and maintaining software. Hewlett-Packard (HP) reuse projects have reported productivity increases from 6 to 40%.
* Shorten time-to-market
By reusing software to shorten the critical path in delivering a product, organizations within HP have reported a reduction in time-to-market from 12 to 42%.
* Improve software quality
Software that has been used multiple times will possess fewer defects than freshly coded components. One HP organization had mature reused code that had a defect density which was ten times better than new code. Quality improvements in HP products from reuse have ranged from 24 to 76%.
* Provide consistency and interoperability across products
Standard interfaces and common use of components across products facilitates ease of use and interoperability. For example, when several software products reuse the same user interface scheme, terms and conventions are used consistently. Reuse also contributes to interoperability. For example, when a component that contains an error-message handling routine is reused by several systems, these systems can expect consistent behavior.
* Ensure product/system conformance with user requirements through prototyping
Because the availability of reusable components facilitates prototyping, user requirements may be more easily validated. This prototyping will also enable detection and resolution of defects earlier in the software life cycle - avoiding more costly fixes later in the life cycle.
* Reduce risk
Risk in creating new software is reduced when available reusable components already encompass the desired functionality and have standard interfaces to facilitate integration.
* Leverage technical skills and knowledge
Reuse enables specialists to optimize software architectures and assets which may then be reused by others who are focussing on meeting product features and market needs.
* Improve functionality and/or performance
Reuse allows for the investment of time to improve functionality and/or performance. Because this time can be amortized over multiple uses of the assets, this investment for such improvements is more economically justified than the case where they would only be for single product.
PROCESS OF REUSE
Experience has shown that reuse is not merely creating a repository, having engineers deposit assets and hoping that other engineers will reuse the repository's contents. Rather, successful implementation of reuse requires an infrastructure to support reuse. A critical aspect of the infrastructure is the process of reuse.
In its simplest form, the process of reuse consists of four major activities: manage the reuse infrastructure (MRI), produce reusable assets (PRA), broker reusable assets (BRA) and consume reusable assets (CRA). A few terms are defined to facilitate our discussion: Producers are those who create reusable assets with the specific goal of reusability. Consumers are those who use reusable assets to produce enduser products or further reusable assets. Each of the four major activities are now briefly defined.
The function of Manage the Reuse Infrastructure (MRI) is to establish the reuse rules, roles, and goals in the infrastructure to support reuse. MRI drives the reuse process. This includes designating conventions and standards; approving additions, deletions, and changes to the library; commissioning component construction; coordinating schedules and resources and aligning reuse goals to business goals. This function also establishes and awards incentives, interprets metrics data, and implements economic models. Overall, MRI is responsible for the planning of the reuse effort.
The Produce Reusable Assets (PRA) activity develops, generates, or reengineers assets with the specific goal of reusability. PRA includes domain analysis and domain engineering. Domain Analysis is the process of identifying, collecting, organizing, analyzing and representing the commonality and variability among systems in an application domain and software architecture from the study of existing systems, underlying theory, emerging technology and development theories within the domain of interest. Domain Engineering is the construction of components, methods, and tools and their supporting documentation to solve the problems of system/subsystem development by the application of the knowledge in the domain model and software architectures.
The Broker Reusable Assets (BRA) activity aids the reuse effort by qualifying or certifying, configuring, maintaining, promoting and brokering reusable assets. This process also includes classification and retrieval for assets in the reuse library.
The Consume Reusable Assets (CRA) activity occurs when systems are produced using reusable assets. Users utilize the library and associated tools to gain an understanding of the reusable assets available to them; identify and retrieve needed components; integrate the components into their system; and provide feedback to the librarian on existing and needed components.
Reuse requires new job roles and different tasks for the engineer. This will be illustrated with an analogy to the task of home construction. The advent of prefabricated parts for home construction has provided home builders with a less costly alternative to construction from scratch. Home builders can rely upon standard parts which may be used to construct homes in a much shorter time than historically possible. However before such prefabricated parts are made available to the home builder, they must be specified, designed and created.
Analogously, one of the roles necessary with reuse is the producer engineer who creates the reusable assets. Among, the changes that the producer engineer will find in the task of creating reusable software relative to regular software product development are:
* Increased design time
In constructing prefabricated home parts, designing a door for a single instance of use is generally less complex than designing one that would accommodate usage for several rooms in a home or in several types of homes. Likewise, designing software for a one time use generally takes less time than that required to make the software reusable. The new challenge lies in designing the software for multiple products. New roles created include the domain expert and domain analyst who perform analyses to specify the requirements prior to the design of the assets. A is a domain expert person who is very knowledgeable about a particular domain. This person will generally be aware of existing and planned products in the domain. A domain analyst extracts and analyzes information about a domain from existing components, product plans, domain experts and other sources to produce domain models.
* Understanding of multiple contexts of use
Just as a home parts builder anticipates the conditions and contexts of how a door will be used (e.g. weather conditions), the producer engineer needs to anticipate how the asset will be used in future reuses.
* Reallocation of time
Without reuse, the engineers' time is spent developing software from scratch. With reuse, user engineers spend more of their time locating, understanding and integrating reusable components.
* Increased documentation
In order to facilitate understanding and therefore reuse of software, adequate documentation is required for the user.
The consumer engineer employs the reusable assets. Just as a home builder designs a home with the knowledge of what prefabricated parts are available, the user engineer practices asset-centered design, designing a product which takes advantage of the available reusable assets. Among the changes that the user engineer will find in the task of reusing software relative to regular software product development are:
* More time allowed for innovation
Reuse allows the engineer to avoid creating redundant assets, freeing time for the innovative aspects of development.
* Greater potential for prototyping
Having an existing set of assets encourages rapid prototyping to validate end-user requirements.
Engineers may also participate in a "reuse software evolution" or steering committee. This committee is the mechanism to bring the disparate producers and consumers together to facilitate decision making regarding the evolution of the reusable assets.
New tasks and roles will also be created for the managers. All managers will need to focus not just their own projects but also on how they can contribute to the success of the organization's portfolio of projects. An essential aspect of this view is to understand that reuse is a strategic investment requiring long term commitment which will pay back in the long run.
Managers of both producer and user engineers will find themselves helping or managing efforts at identifying commonality, utilizing metrics, and conducting assessments and reviews to ensure that the necessary assets are produced and used.
The new roles of reuse sponsor, champion, or manager may also be created.
The sponsor is usually a manager(s) who authorizes and reinforces the reuse program. The primary job of the sponsor is to oversee and ensure that the reuse program has adequate resources.
The reuse champion is the individual or group who advocates and supports the reuse program. This champion, who may be a manager or engineer, is an evangelist for software reuse and has the key role of convincing and selling the reuse concept to constituencies. Successful reuse champions are usually individuals who are well-respected for their technical and personal leadership.
The reuse manager has the overall responsibility for reuse planning, managing the flow of information and assets between producers and consumers, and for ensuring that the infrastructure supports the reuse effort. This manager may be directly responsible for the mechanics of reuse or indirectly through a reuse council, steering committee or review board. An effective reuse manager has the ability and skills to understand and handle process issues, coordinate collaboration of several different organizations, recognize and balance short and long term goals, identify and solve cultural and organizational impediments, and communicate and influence at multiple managerial levels.
It is important to note that many or a single individual can serve any or all of these roles.
A successful program in reuse starts with the recognition of reuse potential. If your organization has substantial duplication across existing or new product lines and/or within a given product, then your situation may warrant further investigation into the feasibility of reuse. Stable, mature and well-understood domains offer the best possibilities for reuse. Assuming that the necessary management and resource commitments exist, the steps to implement reuse briefly consist of:
* Assess organizational readiness
Understand the people, process, product, technology, asset, economic, metric and management facets of the organization and how reuse will impact each of these aspects.
* Identify and collect metrics
While this activity is done throughout the reuse effort as necessary, collecting metrics early will enable us to benchmark the organization and show the impact when reuse is implemented. Metrics are identified based on those business goals reuse is assisting the organization in reaching.
* Select a target set of users and pilot project
Identify a set of product efforts that may be good candidates for reuse. Factors to consider include the readiness of the engineers and managers to apply reuse, whether reusable components can be made available to them within their development schedule, etc.
* Identify domains in the organization
Enumerate a list of domains that are in common within the organization. These may include horizontal domains (e.g., graphical user interfaces, error handling) and vertical domains (e.g., manufacturing applications, medical imaging).
* Collect an inventory of existing material
Locate candidate components for each identified domain.
* Analyze the domain
An informal domain analysis may be conducted for the chosen domain. This analysis includes determining features common to systems in the domain and assessing the range of variability.
* Examine the existing organizational structure
Consider establishing an independent producer group. This would dedicate resources to ensure that the necessary assets are created, managed and supported.
* Create and manage reusable assets
Make, buy or re-engineer existing assets for users. Bring these assets under a source control and configuration management system.
* Establish a process for producing, managing and using the reusable assets
After obtaining a clear understanding of the current process for software product development, determine a process for producing, managing and using reusable assets that address the particular needs of the organization.
* Utilize tools, technology, and standards
Examine whether to create or use existing tools, technology and standards for your reuse program.
* Conduct reviews and walkthroughs to reinforce reuse
Throughout the product development life cycles, perform reviews to ensure adherence to reusability objectives.
* Pursue continuous process improvement
Continuously monitor and pursue incremental improvements to the reuse program. Explicitly solicit feedback from the users, end-users and other participants in the reuse effort.
The Lombard Hill Group provides expertise in practical implementation and improvement of software reuse programs. For further information, please contact email@example.com.