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. Every plug-in consists of two major packages: content
packages and process
packages. Content packages contain content
elements, such as roles,
tasks,
work
products, and guidance.
Process packages contain 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. |