19.3 Multivariants

Multivariants or just variants occur when what may seem to be a single configuration item (from a functional point of view) appears in different, almost identical versions simultaneously . This may arise because of

  • Language requirements (e.g., Danish and English)

  • Hardware requirements (e.g., different processors in the same family of products)

  • Legislation requirements (e.g., concerning registration of personal information in different countries )

  • Communication protocols

  • Customer requirements (e.g., the demand for an "economy" model and a "deluxe" model)

Examples

Variants of a Single Configuration Item

A company sells accounting systems all over the world. The system consists of a kernel and a number of modules that may be added to the kernel. One of these modules is calculation of sales tax (ST) to be added when an item is being sold. The legislation in this field varies from country to country, and the module exists in a number of variants. All these variants have the same interface to the kernel, so the complete product can be delivered in different variants.

Variants of Delivery

A company sells a product that may be bought with varying functionality depending on the needs (and the money). The complete product can be delivered with a varying number of configuration items.

Requirements Considerations

Variants are created as a consequence of requirements for the complete product. Analysts may facilitate configuration management by making clear as early as possible which variants are expected and which combinations may occur.

Design Considerations

The creation of variants is a design decision, not a configuration management decision. But the configuration management system must be able to cater to variants when they occur. The design of items that may appear in variants should take maintenance and configuration management into account. This may be done by placing as much as possible of the common functionality in items that do not appear in variants.

In the tax example previously given, the tax module for Denmark should contain only what is strictly relevant to Denmark. This reduces the risk that changes will affect many items. The variants will, however, always have something in commonthe interface at least.

The number of variants may also be reduced by introducing parameter control for a common item, so the variants are tailored to the customer on the basis of a common product. In the example of the product with varying functionality, the deluxe system may be delivered as an economy system by closing off access to "extra" modules. A solution of this kind may, however, result in a need for variants of a parameter file, and then we're back where we started.

Another way of reducing the number of variants is to use conditional compilation (e.g., #ifdef). This may be a good solution when delivery is to different hardware platforms. In the two examples already given, the benefits of simpler configuration management must be weighed against the disadvantage of moving the complexity to the code and thereby also to test and maintenance. Designers may facilitate configuration management by making clear as early as possible how variants will be handled as regards design.

Configuration Management Considerations

Variants may cause configuration management to be complex indeed. Variants of single configuration items must be considered . But variants are always reflected in deliveries: if the configuration items contain variants, the deliveries will too. Furthermore, the deliveries may have variants without variants in the single configuration items, as in the two examples already discussed.

Each variant in a family must be treated as a single configuration itemthat is, it must be possible to release new versions of the item independently of the other variants. For example, the newest version of the sales tax software for Denmark may be 2.3, while the newest version for the U.K. may be 1.8. Variants rarely appear as branches of a configuration item, but it may happen. It may also happen that variants melt into one configuration item, but this is rare for genuine variants. Both these situations are handled as parallel development with regard to configuration management.

Identification

Naming conventions must take variants into account. It must be clear from the metadata for a configuration item that this item is part of a variant family, and which one. Especially for deliveries, the combinations of variants must be considered. A product may, for example, be delivered as PROD_UK-deluxe, PROD_UK-minimum, or PROD_DK-minimum.

It must also be clear from the metadata which configuration items are related variants. It may be necessary to introduce an extra data element to register the family, but this may often be solved by the name alone. In the sales tax example already discussed, the family might be called CALC_ST and the names of the variants could begin with CALC_ST. The variant part of the name could be _aa, where aa follows the international standard for country codes.

Tracing must be performed with care, so that common requirements implemented in all variants are traced to all variants, while requirements pertaining to one variant are traced only to that item.

Storage

In principle, all variants must be stored individually as configuration items, like all other configuration items. It may be an advantage to store different variants in different master libraries, so that variants belonging to Denmark are placed in a Danish master library and the French variants are stored in a French master library, while common items are stored in a common master library. Such a solution may also be combined with multisite development. Separate libraries may make the production of deliveries easier and more secure but may also make it more difficult to handle metadatathat is, to produce information about families.

When collecting deliveries, the proper variants must be included in each one. This applies to deliveries both for test and for operation. Each delivery variant will often have a special production procedure (make-file or the like). It's important to know which variants have been released to whom, so changes may be communicated to relevant stakeholders, and only to them. It may, for example, not be terribly relevant for a Danish user to be informed that the German variant has been updated.

Change Control

Change control must be performed with special care when variants are involved. The configuration control board must have access to information about variants: the board must be able to make out if a given configuration item is a variant and, if so, which other items are in the same family. On the basis of this and relevant tracing information, the board must decide if an event has an effect on all variants in the family, some, or only one. Variants must also be included in an analysis of the consequences of an event. It may not be feasible to introduce a change in a variant if it has significant adverse consequences on other variants.

Status Reporting

Status reporting must take variants into account. It must be possible to get a report that identifies all variants in a family on the basis of a single variant. It must also be possible to identify to whom the variants in a family of deliveries have been released. Furthermore, it must be possible to give a statement of status and history for each variant in a family independently of the others.



Configuration Management Principles and Practice
Configuration Management Principles and Practice
ISBN: 0321117662
EAN: 2147483647
Year: 2002
Pages: 181

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net