21.3 External Reuse Component Development

External reuse refers to items developed and maintained entirely outside a company, such as those bought from other companies or downloaded from the Internet. External components that are changed within the company become either internal components or product-specific configuration items. This will change the way the items are treated from a configuration management point of view. The handling of external components is related to the handling of internal components for reuse that are developed and maintained in the company.

External components should be owned centrally , even if they are (initially) only used in one project. Central ownership is administrationno changes are connected with it.

Examples

In connection with Web applications, it's becoming more usual to use external components of the "Flash plug-in" type, for animated graphics. External components with ready-made graphics are also used extensively, such as pretty buttons with various functionality. Another example is the buying of complete class libraries for specific purposes, such as scientific or economic data handling, where the classes are used in the company's products.

Configuration Management Considerations

Only limited configuration management may be performed for external components. However, it may be important to the stability and maintenance of the company's own products to place external components under internal configuration management on a more or less equal footing with items developed internally. Configuration management of external components should be performed centrally.

Identification

It may be useful to define an internal unique identification for components. The supplier's identification must still follow the component, but that should not be used internally, to ensure unique identification within the company and avoid clashes with other components and items.

Extended metadata may accompany external components from the supplier, such as information about deployment and interface. These metadata must be made available to possible users of external components. When registering metadata, make sure it is connected to the correct componentfor example, that the storage location is correct, especially where components are accessible only in executable form (as .exe files), which makes it impossible to check them directly.

Storage

External components should always be in controlled storage centrally. An external component may never be stored in more than one place. External components may, of course, be released for usage and kept in any number of copies in static libraries (depending on license agreements). They may be released to form the basis for production, such as if a component is needed to support a test or a local object is to be based on a component. A new version of the components must not be produced internally. If the need (or the temptation ) for this arises, the new objects must be treated as independent internal objectsand not necessarily internal components.

Change Control

Change control of external components is special, in the sense that the company doesn't directly influence the implementation of changes. Configuration control boards must be especially careful in handling event registrations where external components are in use, creating special registrations if necessary. The boards are responsible for creating such registrations the way the supplier wants them and directing them to those responsible for external components, either at the company or at the supplier, if possible.

Change requests cannot be created for external components, as decisions for changes in these components will always be outside the company's jurisdiction (at least formally ). A special effort may be necessary to describe workarounds for problems originating in external components.

It's not always possible to communicate directly with a supplier of external components, so that information about new versions of external components accrues automatically. Often, a company must keep itself informed about changes and take new versions in, such as from the Internet. External components should always be taken into the company at a central place, preferably with an acceptance test procedure to approve them before distribution to the rest of the company.

Registration of who has which external components will identify those who should be informed of changes. Projects that use these components should always be informed of new versions, but deploying them must be a local decision. New versions must never be automatically released into unsuspecting projects.

Status Reporting

Status reporting is as important for external components as for internal configuration items, though the nature of the reports is different. It may be a good idea to provide a special status report in the form of a catalogue for available components, with extended information (purpose, prerequisites). Status reports may also include a usage matrix (as in Figure 21-1) or similar stakeholder matrix about who has which components.

Figure 21-1. Usage Matrix