This appendix discusses what variants of systems are, and how to manage them. You do not need to read this to understand the Rational Unified Process; on the contrary, it should be treated as an extension to the Rational Unified Process. The last section briefly discusses how the Rational Unified Process would be affected by the introduction of variants, and variability.
This is an area in which the Rational Unified Process will improve and expand in the future. This appendix gives a first taste of that.
Variants of Systems
Many systems are delivered in more than one variant. This means that the system is configured, packaged and installed differently for different (classes of) customers. Sometimes different variants can be achieved by simply installing and adapting the system differently. Other times the variability is achieved by delivering different parts of the system to different customers. The following sections contain some examples of variants.
Different Parts of the System
Different parts of the complete system are delivered to different classes of customers. For example, a banking system is delivered as two different products. Variant 1 of the system, contains everything about telephone banking; and variant 2, contains everything about teller account management. The executables are defined in the subsystems in the applications layer. This means, that a variant (variant 1 in the following figure) is a build with, for example, the subsystem Teller Account Management, and all the subsystems it needs to compile and execute (that is, all the subsystems it imports directly or indirectly).
A banking system which is developed as two variants.
If the system is produced for different languages, for example, English, French and Japanese, you want to deliver a variant of the system for each language. The difference between the variants is that all text, such as menus, and help texts, should be in the specific language.
One way of handling the different languages, is to collect all texts in a file, and have one file for each language. To deliver a system for a specific language means to deliver everything, plus the file containing the texts for the specific language. This file is then read by the software at startup time, and all the relevant variables are initialized.
If the system supports multiple, incompatible platforms, then one variant of the system is needed for each platform. For example, if a system runs on both Windows NT and UNIX, then two variants of the system are produced.
In the example below the platform-specific code is located in one subsystem. In this case two variants of subsystem are developed. A compilation file (a 'makefile') specifies which version of each source code file should be compiled together. You could also say that a 'makefile' specifies which variant of each subsystem should be part of the build. Therefore, you need one 'makefile' for each platform.
A system is developed to run on several platforms.
Sometimes it is necessary to develop a patch release of the system. This is normally done in parallel with a development project. This means that the patch release is another variant of the system; it exists in parallel with the "main" version of the system.
The development of a patch release is done in parallel with the main development project. Gray squares indicate future releases and baselines.
The changes you need to make are located in one or several implementation subsystems. Because a normal development project is going on in parallel you need to develop variants of these subsystems in parallel with the main development effort. To create a build, you specify in a 'makefile' which variant of each subsystem should be part of the build.
A patch-release build is created with a variant of the subsystem that contains the patch.
This kind of variant normally has a short life span. After the patch is released, this variant is not developed any further, and all code changes of value are incorporated into the main development path.
The relevant changes in the patch release are merged into the main development path, when it is convenient.
Variants of Subsystems
The examples above show that you often need two or more variants of one specific subsystem. These variants will have some components in common, while other components are unique for each subsystem variant.
Two variants of an implementation subsystem called Report Management. One component is decided to be the same in both variants. The other components, are unique for each variant.
Often each variant of a subsystem is developed by one implementer, and the subsystems variants are developed in parallel. If the component is changed by one implementer developing one variant, the change should be propagated to the other variant. To make this possible, you need tool support from a configuration management and version control tool (CMVC), to manage the components that should be identical in the two variants.
Mechanisms for Variability
There are several mechanisms to create system variants. Some of them have been mentioned in the previous sections. Each mechanism has different characteristics. Normally, you use a combination of these mechanisms to create variability in your system.
Effect on the Rational Unified Process
This section briefly describes how the Rational Unified Process would be affected by the introduction of variants.
Effect on the Implementation Workflow
The Implementation workflow needs to be extended in the following areas:
Other implementation activities may also be affected.
Effect on Other Workflows
Developing variants, or families of systems, affects all workflows. In the previous sections some affects on the Implementation workflow have been discussed. The following is a brief list of how the other workflows will be affected: