Component-based development (CBD) can be an appealing proposition to globally distributed software development teams because of the almost endless possibilities to recombine and reuse components in new products. It has been suggested that CBD will improve globally distributed software development practices by allowing each site to take ownership of components, resulting in reduced inter-site communication and coordination activities. Such an approach may indeed overcome breakdowns in inter-site coordination efforts; however, it may also lessen opportunities to share knowledge between sites and may hamper opportunities to reuse existing components. A case study approach, exploratory in nature, was adopted to explore knowledge aspects in global component-based software development. Evidence collected at several globally distributed CBD projects suggests that the true potential of
CBD, which relates to reusing components, can also be achieved when components are developed in a joint manner (i.e. by several sites) by accessing and utilizing expertise regardless of its geographical location. To improve the rate of component reuse, the studied teams developed capabilities in three areas: inter-site coordination, communications, and knowledge management. The paper concludes by discussing the links between component reuse, CBD principles and organizational capabilities, and offers managers and engineers some guidelines to consider in their CBD projects.
Founded in 1964 by Walter Lecroy, a physicist, Lecroy Research Systems (in 1980 the name was changed to Lecroy Corporation) was quickly recognized as an innovator in instrumentation. In 1972 the company established an instrument design and production facility in Geneva, Switzerland. In 1976 the corporate headquarters moved to its present location in Chestnut Ridge, New York (NY). Initially, Lecroy developed technology to capture, measure, and analyze sophisticated electronic signals in a stringent scientific environment. In 1985, the company began transferring this technology to a popular line of general-purpose instruments. Growth in the commercial test and measurement market really took off when the company introduced its first digital storage oscilloscope products. Since that time the core business of Lecroy has been the design and production of oscilloscopes and oscilloscope-like instruments – signal analyzers, signals generators and others (see Appendix 2 for general information about oscilloscopes and products of Lecroy Corporation).
During the last 20 years, Lecroy has opened several sales offices in Europe (in France, Italy, Germany, Switzerland, and the UK). These offices are responsible for sales in all Europeans countries. There are also offices in Japan, South Korea, China, and Singapore.
(Q1). The major challenges Lecroy software managers faced during the various stages of system re-engineering
Data degradation over time, the quality of data tends to decline. Changes to the data introduce errors, duplicate values may have been created and changes to the external environment may not be reflected in the data. This is inevitable because data lifetimes are often very long. For example, personal banking data comes into existence when an account is opened and may have to persist for at least the lifetime of the customer. As the customer's circumstances change, these changes may not be properly included in the bank's data. Program re-engineering can bring data quality problems to light and thus highlight the need for associated data re-engineering.
Inherent limits that are built into the program when originally designed, developers of many programs included built-in constraints on the amount of data which could be processed. However, programs are now often required to process much more data than was originally envisaged by their developers. Data re-engineering may be required to remove the limitations. For example, Rochester and Douglas (Rochester and Douglass, 1993) describe a funds management system that was originally designed to handle up to 99 funds. The company running the system were managing more than 2000 funds and had to run 23 separate copies of the system. They therefore decided to reengineer the system and its associated data.
Architectural evolution if a centralized system is migrated to a distributed architecture it is essential that the core of that architecture should be a data management system that can be accessed from remote clients. This may require a large data re-engineering effort to move data from separate files into the server database management system. The move to a distributed program architecture may be initiated when an organization decides to move from file-based data management to a database management system.
(Q2). Strategies that Lecroy implemented to deal successfully with these challenges
Designing for reuse
For Lecroy this practice aims to increase reuse of software components across several products in the long term. This involves analysis and long-term planning for future products and product families and making strategic decisions about the granularity level of components. The need to facilitate reuse through design derives from the major goal of Lecroy software managers:
• ‘We wanted to have a system that really is Object Oriented and reusable and modular and all these good words […]. We developed this architecture [Maui] to be built on for years in the future.'
• ‘The whole idea is that we can take the bunch of different components and create a different instrument, within weeks is kind of optimistic, but within a few months rather than in a few years' (Larry Salant).
Investing in ‘advanced development'
The development of the Maui platform was treated at Lecroy not as a typical product development project where product requirements are defined in the very beginning, but as a research project: ‘we were really trying to determine if we can build a product on it [Microsoft COM] and doing some essentially pure research - what people would call ‘advanced development' (Larry Salant).
Advanced development included learning about available technologies, and conducting a feasibility study aiming to test whether or not a ‘proof of concept' for the product can be achieved by applying available technology: When Maui project started, we didn't really have a product in mind, not in the sense of the product that you can ship. But we knew that we wanted to use this [Maui platform] on several products that would be defined in the future (Anthony Cake).
(Q3). A “good” software system architecture:
Software Architecture is the global organization of a software system, including the division of software into subsystems/components, policies according to which these subsystems interact, the definition of their interfaces.
Maui has been called several things. It is an operating system for scopes. But it is an application, consisting of a collection of hundreds of components, each of which could have a place in the oscilloscope, or in oscilloscope-like instruments. In other words, Maui is also a component tool box: it is a repository of components; a scope is built by selecting from and integrating these components. ‘That is Maui.
However, with those components you do not have a scope' (Larry Salant, Director of Software Engineering).
There are four types of components in products based on the Maui architecture. One category is called processors, with hundreds of mathematical functions, one component per functionality. A second category is Graphical User
Interface (GUI), components that are combined to provide the user interface. The third category of components is the core components that allow the systems to work together and provide the basic instrument capabilities. And finally, there are the components that comprise the acquisition board driver. These are responsible for controlling the acquisition hardware.
The components are written in C++ and the interfaces between them are in COM.
Maui describes these interfaces, they are part of Maui architecture: I guess, really the root of Maui are these interfaces. There are 30, 40, 50 interfaces which describe how these components talk to each other. That is really the heart of Maui. If you want to make a component for Maui - whether it will be something to display waveforms, to control the front panel, an acquisition system, any of these things – in order to integrate them into the system and to attach to the rest of the system, they have to implement or use one of the Maui interfaces. It is a bunch of standards, and it is a tool kit (Anthony
(Q4). Characteristics the Maui architecture
It was developed having characteristics of a good system architecture, this is because of the deep set of a deep set of integrated debug and analysis tools help identify problems and find solutions quickly. Unsurpassed integration provides critical flexibility when debugging. Solve problems fast with powerful analysis tools.
(Q5). Competitive advantages did Lecroy gain from having a component-based product architecture
The main goal and the main advantage anticipated from the component-based Maui architecture was to ‘take the bunch of different components and create a different instrument – within weeks is kind of optimistic – but within a few months rather than in a few years' (Larry). It was a long-term planning that aimed at reducing time-to-market and lowering costs while delivering state-of-the-art products. Therefore, the story would not be complete without reflecting on what has happened since the launch of Aladdin (the first Wave Master) in January 2002 and reflecting on the progress of Maui and the technical, marketing, and financial evaluation of products based on the Maui architecture since 2002 and until 2006. From a technical perspective, comparing expectations and actual achievements several years later (until 2006), it is safe to say that the Maui architecture has been a remarkable success. So far, the expectations of the Lecroy software team have come true. Larry reflected on the products released in 2002:
Requirements for tools to support (globally) distributed CBD
• A need to decide on required documentation: what should be included in the documentation?
• Interfaces – how should interfaces be described? Should UML be used for interface documentation (van Hillegersberg, 2003)? There are no widely accepted standards and guidelines about this (Bass et al. 2000; Vitharana, 2003).
• How detailed should documentation be? Documenting in-house developed components for internal reuse takes time and is often considered as an administrative overhead. However, documentation is needed to ensure that a component and the logic behind it can be understood in case modifications or bug fixes are needed.
...(download the rest of the essay above)