[*** This guidline needs refactoring to remove the OpenUP restriction (this should be useful for any open source process content) and to change the terminology used from EPF Composer to just Method Composer.   (OpenUP-specific content can be factored out and contributed from process.openup) ***]

Customization resources

There are a number of use scenarios for OpenUP. The simplest is to use the content available from the EPF project (either the available published Web site or the one that you publish from the available library). You can find those resources at www.eclipse.org/epf.

However, you may be looking for adding, removing, suppressing, or modifying method and process elements to make OpenUP more suitable to your teams' needs, while keeping it consistent and understandable.

The following sections introduce a few fundamental concepts about method content and process, as well as descriptions of typical customization scenarios and links to additional information on how to customize methods.

Method organization

You can use EPF Composer to write, configure, and publish method and process content. EPF Composer organizes the content in a method library. Each method library contains one or more method plug-ins. Plug-ins consist of roles, tasks, work products, guidance, capability patterns and delivery processes.

Method content and processes are organized in the EPF method library according to how they build logical units for useful method configurations. For example, all content belonging to one specific discipline, such as requirements or development, can be found in one content package. Each of these packages might be further divided into sub-packages for specific practices in these disciplines. For example, under Development, you may want to have a package that factors all of the specific information about visual modeling. Thus, you can add or remove visual modeling specifics from Development with just one simple mouse-click by selecting or deselecting the right package.

For more information on method organization, see EPF Composer Overview, Part 1 and Part 2.

Customization scenarios

The following sections describe several possible customization scenarios. For step-by-step instructions, see the Customization Scenarios tutorial.

Use existing plug-ins and packages to build your own process

This is the most straight-forward customization scenario. Based on the content provided by OpenUP, you can use EPF Composer to pick and choose the packages with the content that you want to have published and made available to your team. Removing a method package removes all references to the content of that package from the published process. For example, you can simplify a process to have it contain a minimal subset of its content by removing packages that contain elements of work that you do not want to perform. You do this by creating a new method configuration (or copying an existing one) into your method library. You can select packages as appropriate without affecting the configuration provided.

Add method content that your team needs

Some teams may need to perform a different task that is not contemplated by the out-of-the-box content. Maybe they need to perform an extra step in an existing task, or they may need to add a new guideline for a given technique that they are following. Eventually, they need a new template for a document (or may need to add or remove sections in an existing template).

In such situations, the recommended approach is to create a separate plug-in in your library. It is not a good practice to make changes in the provided OpenUP plug-in (or any plug-in for which you do not have control), because new versions of these plug-ins, when deployed, can override the changes that you have made.

EPF Composer provides a series of mechanisms that allow you to indirectly modify the content in an existing plug-in by using content variability. In your plug-in, you can define an element that contributes, extends, or replaces an element in the existing plug-in. For example, in your plug-in, you can define a task that contributes a new step to an existing task in OpenUP. You can also define a new artifact that replaces one in OpenUP, and this new artifact can have a different name, structure, and associated template, for example.

When you create a new plug-in, it should depend on existing plug-ins to where content will be contributed, extended or replaced. After you have created your plug-in, you add it to a new configuration from which you can finally select the packages with content that you want published. During publication, EPF Composer will resolve the content variability that you defined by adding the new content into the existing content where appropriate, replacing existing content with the content you defined, and so on.

Define a different development lifecycle

Both method content and process are created independently from each other. For example, you create tasks in the method content (and define their inputs, outputs, and responsible roles), but you do not necessarily define the lifecycle of your process, meaning the sequence in which the various tasks will be performed. On the process side, you then define the lifecycle (such as phases, iterations, activities, and tasks), as well as the precedence among these elements.

Some teams may find the method content appropriate without any further customization, but they may want to work by following a different software development lifecycle. Some teams may like the four development phases and iterations from OpenUP, but some may want to develop iteratively, without being tied to the phase structure.

You can add, remove and replace elements in the work breakdown structure of an existing process by applying variability. This is called process contribution, which means that differential changes can be applied to an existing process.

As an alternative to tailoring an existing process, you can write a completely new process that reuses activities from one or more existing processes. In cases where you cannot find any reusable material at all, you can also create a completely new process from scratch. In most cases, however, you will start developing your own process by assembling reusable building blocks from method content, as well as predefined process patterns called capability patterns. The resulting assembled process is called a delivery process.

This newly created delivery process is part of a configuration that you publish and make available to members of your team.

Publish the process Web site

Every customization scenario is finalized by publishing content in a Web site format that can be accessed by practitioners in the project. EPF Composer allows you to publish content based on a given configuration, which will publish all of the content available from the method and process packages selected in that configuration. Another option for publishing is to select only the capability patterns or delivery process of interest. This will make available only the content related to the process packages that you select.

For the published Web site look and feel, you can customize the views and nodes in the directory (tree) browser by defining custom categories that will be part of your configuration.