21.4 Internal Asset Development (Product-Line Approach)

Many companies have embraced the idea of development for reuse, instead of producing each system from scratch every time. This is a sign of a more mature industry, since only mature companies have the foresight, energy, and resources to look for and find patterns in what they are doing. This applies to processes as well as products. Development for reuse is known under a number of names : development of internal assets, development of components , and product-line approach. (The product-line practices initiative, driven by the Software Engineering Institute, provides good guidance on this subject at the Web address given in the bibliography.)

In this section, the term component will refer to objects developed for reuse under the full control of the company itself. A variety of this is development for reuse by a subcontractor, which in principle is no different from the internal form. Characteristics of development for internal reuse are that components

• Are owned centrally in the company

• Are independent of individual products

• Are parts of products

• Are included in deliveries for specific products or projects

• May form the basis for specific objects

• Are not changed in individual projects

Examples

Components may be everything from small modules linked into a product to large platforms, on which entire products are built. A small module may be a routine for calculating interest or the interval between two points in time. A typical example of a component is a data server on a mainframe. This is often used in large administrative systems, such as Web applications. Another example is a platform, which may be a standard apparatus composed of hardware and software, from which new products are developed as small modules that are added to the platform.

Components may also be templates, such as for requirement specifications, where generic requirements are included and just need finalization , perhaps by filling out specific numbers. In the flight industry, generic performance requirements are specified and filled out with actual numbers in each project.

Central Ownership of Components

Components may be created in various waysas the result of a conscious management decision or in a specific project during the development work. Either way, the responsibility and the ownership should be placed centrally in the company, outside the projects where they're used. The collection of components should be regarded as an independent project, on an equal footing with other products, with all this entails in support functions (project management, quality assurance, configuration management).

This is not to say that the development and maintenance of components may not be "farmed out" to specific projects. This will often happen, since the expertise will be present in projects and not always centrally. These cases require extra time in the project plan. A company may have several component projects at the same time, as long as these projects are kept separate from each other and from main projects.

Configuration Management Considerations

Components, which may be either individual configuration items or deliveries, must be placed under configuration management just like other objects, along with related material. This must start at an early stage in their development, and must be performed even more conscientiously than in ordinary projects, if possible.

Ideally, the usage of components should be broader and less cliquish than for objects developed in an isolated project. Components are often developed in a context different from the ones in which they're later used, so it's important to have access to the full background and reasons for their presentation and functionality.

Identification

Components must be identified like all other configuration items, including a version designation. The unique identification should indicate that an item is a component and should avoid conflicts with identification of other items. Metadata can and should be expanded to include more information for each component, such as a description of its purpose and interface. Placement under configuration management should imply a component's approval, but it might be a good idea to include some sort of documentation of the test statusmaybe even a test certificationin the metadata.

Storage

Components must be stored centrally, never with configuration items from other projects. Components of the module or platform type will always be part of a product delivery. Such a component cannot and must not appear as an individual configuration item in projects other than the one to develop and maintain it. This type of component may be part of deliveries at a lower level (a subsystem), which is part of deliveries at higher levels (a software system), which is part of an apparatus. One component will often be part of the total system in several places, as illustrated in Figure 21-2.

Figure 21-2. Usage of Reuse Components in Projects

Projects that use these components must references them in their metadata. Component identifications will be used as the "consists of" element in metadata for deliveries. The components will subsequently be released for usage in connection with the deliveries.

To provide for this, the configuration management system for components must have special facilities to release components when they're needed. This could be in form of a subscription arrangement, so that projects fill out a release request for a component once and can then extract it when necessary.

Components of the template type may be individual configuration items or deliveries. References to them in metadata will be in the "derived from" data element. Such components will be released once as the basis for production of an independent configuration item. It's a little harder to prevent changes to the reuse part of such items, but it's possible with locked text or the like. For all types of components, it's advisable to register to whom they're released for usage. This might be made more manageable by collecting components in (object) libraries, which are then deliveries whose releases are registered.

Change Control

Components must never be changed outside the jurisdiction in which they're developed and maintained . The central owner always decides if a component is to be changed, and how. It may be a good idea to have a representative from the component project on one or more configuration control boards for projects where components are used. These boards must ensure that event registrations can be made to components if necessary. It's the responsibility of these boards to direct event registrations to the component project and follow up on them across the project interfaces. A project cannot raise a change request for a component, since changes in components are outside the jurisdiction of other projects.

This principle is illustrated in Figure 21-3, where a problem in Project 2 causes an event registration to be created and sent to the relevant configuration control board (not shown on drawing). The board finds that C1 is causing the problem and sends an event registration to the central component owner. The configuration control board at the central component owner would decide, in consultation with representatives from the three projects, whether a change request should be issued for C1 or if the registration is to be solved another way, such as by creating a component C2.

Figure 21-3. Event Registration Involving a Component

The configuration control board(s) for the central project where the components are owned will often have many stakeholders, who should be given a say in the handling of event registrations. The registration of who has which components may be used to determine who might be notified of a given event registration and/or implemented changes.

Projects using a component should always be informed when a new version is issued, but the project itself must decide if the new version should be used, because this might have unwanted effects in other parts of a product. New versions of components must never just be released without an explicit release request. This is where the requirement for full and unique identification in subscription arrangements shows its value.

Status Reporting

Status reporting is as important in component projects as in other projects. As with external components, 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 information about who has which components.