we share our experience in pursuing effective software reuse in a globally distributed software engineering team that uses a lean development methodology. The paper outlines the journey, starting from recognizing the potential for reuse, the steps taken to enable systematic reuse in lean projects, the challenges faced, and the corrective actions taken to ensure effectiveness of systematic reuse. The main lessons learned include: i) identification of relevant domains for reuse, ii) explicitly assigning responsibilities for reuse component development, iii) providing enabling infrastructure, iv) defining more rigorous software development processes for reuse components, and v) establishing a centralized team for developing reuse components. The results of our successful reuse initiative including the significant increase in quality and a 12 percent reuse of total code developed have been presented.
We share our experience in pursuing effective software reuse in a globally distributed software engineering team consisting of about 1,000 engineers distributed across locations in North America, Europe, and Asia.
Our organization develops products in a highly regulated industry. We are involved in developing hardware, software, and firmware for multiple product families. Due to the nature of the industry, these products have long lifecycles and are expected to perform as specified for several decades. In addition, the products must fulfill regulatory requirements that entail conforming to industry standards. Hence, for our products, quality is non-negotiable.
To ensure on-time delivery of high-quality software, the team had switched to lean software development methodology [1,2]. The team had been operating for over 10 years and had addressed the issues encountered in global software development [3,4].
III. INITIAL APPROACH FOR SOFTWARE REUSE
The potential of software reuse within our organization was immediately recognized when we started software development. At that time, reuse was achieved by merely copying source parts from one project into another without any governing process. We soon observed a rapid increase in maintenance effort and growing incompatibility between products. We realized that we required a systematic approach to organize reuse . Subsequently, we explored ways to harness the potential of software reuse and proposed an approach to the management with the following objectives: 1) reducing development time and costs by reusing existing components, 2) ensuring components with the same functionality have identical behavior and look and feel, and 3) increasing quality by systematic reuse of software components.
Our approach focused on four main areas: A) relevant domains for reuse, B) organizing for reuse, C) funding, and ensuring reuse, and D) enabling infrastructure and processes to facilitate reuse.
A. Relevant domains for reuse
In view of the differences of handling reuse in the different technical areas, we identified relevant reuse domains that were aligned with the development technologies and product platforms. These are listed in Table I. Our approach to identifying domains shares the objectives of domain analysis  while being pragmatic without the rigor of formalism.
B. Organizing for reuse
For each reuse domain, we identified members of the different project teams, who were assigned dual roles – one for project related tasks and another for reuse component related tasks. We also defined two new roles: domain owner and component owner. Domain owners are typically architects or subject matter experts who are expected to drive reuse in their domain. For their domain, they are responsible for: 1) assessing proposals for both new reuse components and significant enhancements in existing components, 2) defining a reuse roadmap, and 3) the architecture of the reuse components. On the other hand, component owners are responsible for: 1) design, 2) implementation, 3) testing, 4) release, and 5) maintenance of the reuse component (see Fig. 1).
C. Funding, and ensuring reuse
All activities were funded by the projects on a need basis (see Fig. 1). Further, to ensure support for reuse, the architect team was given a target to reduce costs explicitly through reuse of software. In addition, it was an unwritten understanding that the entire development organization would support the domain owners and the component owners in achieving the goals of reuse.
D. Enabling infrastructure and processes to facilitate reuse
To support systematic software reuse, we invested in enabling infrastructure: 1) configuration management and defect tracking of the reuse components, and 2) web portal to share information related to reuse components, and to highlight the benefits of the reuse initiative.
1) Configuration management, release management, and defect tracking: We aligned the configuration management, release management, and defect tracking of the reuse components with the respective systems in the projects. This allowed different projects to include the reuse components like any other project component. In addition, defect handling was adjusted for reuse purposes, so that all projects could report and track the defects in reuse components.