Tailoring and then deploying your software process is an
important aspect of the Enterprise Unified ProcessTM
Software Process Improvement (SPI) discipline. When it comes to software development, one of my philosophies is
that you should follow the right process for the situation. Because every
situation is different, you will need to follow a unique version of your
software process. The implication is that you need to tailor and then
deploy the process for each development team, yet at the same time you want to
keep this effort as simple and quick as possible. In this article I
discuss the concept of
organization-level development cases which are tailorings of the
meet the specific needs of a category of projects. The article then
describes three strategies for deploying a tailoring of a software process -- a
simple, web-based strategy; an
RPW based strategy, and an EPF-based strategy.
Finally, it overviews configuration
management (CM) issues which are critical to your success.
NOTE: This article will soon be updated to reflect the evolution of EUP to be based on the
Disciplined Agile (DA) tool kit. Please stay tuned.
Table of Contents
- Organization-level development cases
- A simple deployment strategy
- IBM Rational Method Composer (RMC)
- The Eclipse Process Framework (EPF)
- Configuration management issues
In the cycle of defining/tailoring and implementing, you may identify the
need to have slightly different variations of the process. For instance, you may
find it beneficial to define different tailorings of the process for green field
(new development) and commercial off the shelf (COTS) implementations. With the
EUP, these tailorings can be accomplished with organization-level development
A development case is typically defined for each project using RUP. It
defines the particular process tailoring that will be used on that specific
project. This allows teams to create process definitions to meet their
particular needs. An organization-level development case is a development case
with a wider scope; it is applicable to many projects. For example, you may have
organization-level development cases for new development, for COTS installation
projects, for offshoring projects, and for minor enhancement projects. For
example, the organization-level development case for new development projects
may stress business modeling and architecture efforts because new development
projects are riskier, whereas the offshoring organization-level development case
would focus on requirements definition, acceptance testing, and relationship
There are two fundamental strategies to choose from when documenting
organizational-level development cases. One strategy is to define an
organizational-level development case that covers 80% of the material the
projects will use and have each project use this case as a starting point and
modify it as needed. Alternatively, you can develop a fully detailed
organizational-level development case and just have each project note deviations
from it, usually in their software development plans.
One deployment option is to not tailor the RUP material at all, except
perhaps to install plug-ins. As Figure 1 depicts, you can
develop a collection of HTML pages that overviews the procedures that you want
developers to follow. These pages will reference the RUP material, as well as
other process-related materials including the EUP ,
IEEE standards, your own detailed procedures,
as well as agile methodologies such as
Agile Modeling and agile database
Figure 1. A simple process deployment strategy.
There are several advantages to this approach:
Simplicity. You don't need to purchase, learn,
or work with complex process authoring tools.
Ease of maintenance. There are fewer maintenance
headaches when a new version of RUP comes out, which is at least an annual
occurrence. The RUP pages are just like externally developed source code; if
you modify them, then you need to merge the changes from new releases of the
source into your modifications.
Wide scope. You can easily reference other
process material, not just the RUP. This allows you to truly take advantage
of all effective practices, not just the ones included within the RUP.
Ease of tailoring. Your can organization
can quickly tailor your own process because you've kept it simple.
Project teams can easily tailor their own version of the process, such as by
building development cases and by reworking their own copies of these pages.
Organization-level development cases. You
can have several sets of process pages, perhaps one for each major type of
project within your organization. For example, you could have a set of pages
for new projects, a set for maintenance projects, a set for projects taking
approach, and a set for outsourcing efforts.
The main disadvantages are:
- Extensive knowledge is required. Someone needs to initially
learn and understand the RUP so that he or she can develop the initial
pages. This is also true of the RPW or EPF
- Contradictory advice. Your version may be in contradiction
with the RUP, or other process materials, at certain points. Having the
source material available "as is" may cause confusion unless people
understand that you have overridden portions of it. An effective approach is
to set a specific design scheme for your pages and then make sure that
everyone is aware that your pages are official and that all other pages are
simply reference. Your staff members are adults: they can follow this simple
- Complexity. Providing a process where people must
understand the base description and then understand the changes to it at
another location may be confusing for some people.
- You still need to maintain the process. Your organization
needs to maintain your specific process pages. When new process materials,
such as a new version of the RUP, are released, you will want to evaluate
the material and determine what changes (if any) should be made to your
tailored pages. All you can hope to achieve is a significant reduction of
the maintenance burden, not a complete removal of it.
RMC enables the creation of RUP extensions using plug-in technology, amongst
many other things that RMC does.
A RUP plug-in is typically a fraction of a software development process
describing a specific domain, technology, or platform. There are two types of
- Structural plug-ins. This is a portion of a process that
extends the RUP by adding process elements, such as roles, activities,
artifacts, and disciplines. You could have an
Agile Modeling (AM) plug in which
tailors the principles and practices of AM into the RUP, a Data Warehousing
(DW) plug in would tailor the RUP for a DW project, or a
Support plug in which adds a new discipline to the RUP to capture
support processes. Structural plug-ins are typically created using the
RUP Modeler, a component of RPW. Structural plug-ins can be expensive
and time consuming to build, so you should only create one if you truly feel
that many project teams will be able to reuse it.
- Thin plug-ins. This is a mechanism to package their
organization-specific assets, such as templates, guidance, or examples.
Thin plug-ins don't require any modeling and are much easier, and less
expensive, to build as a result.
RMC is also process configuration tool which
enables you to tailor a process by selecting and deselecting plug ins as
In October 2005 IBM Rational announced its intention to support
the EPF, an Eclipse-based
open source tool for developing, tailoring, and deploying process-related
information. Many organizations around the world have adopted EPF since it
was first released. I often recommend that organizations consider it,
particularly those that are new to
software process improvement (SPI).
Fundamentally your process materials are important assets which
should be kept under CM control just as any other asset would be.
Furthermore, in situations where you will be audited to determine whether or not
you have a defined process and are actually following that process, you will
need to also put your project-level development cases under CM control.
For example, American pharmaceutical companies often have IT projects which need
to conform to the Food and Drug Administration (FDA)'s compliance regulations,
and one of the regulations state that you must be able to prove that you
followed your defined process. The implication is that if you have
tailored one of your organization-level development cases to meet the specific
needs of a project team, then you must put that project-level development case
under CM control in case you ever need to prove that the team followed that
specific version of your software process.