These guidelines describe some things to consider when tailoring the RUP. 

For a description of the overall process for tailoring the RUP, see Concept: Tailoring RUP. 

For a description of some general best practices related to process tailoring, see Guideline: Process Tailoring Practices.

Defining the Scope of the Tailoring Effort

Defining the scope of the tailoring effort is where you identify what you want to change and how you want to change it.

On order to define the scope effectively, it is important that you familiarize yourself with RUP.  For more information, see Introduction to RUP.

How much of the process you decide to tailor, as well as the level of tailoring you decide to undertake, both depend on a number of factors. These factors are described in Guideline: Process Discriminants.  

Variable Elements in Software Engineering Processes

This section reviews the constituents of a process that are likely to be modified, customized, added or suppressed as part of a RUP tailoring effort.

• Disciplines
  A software project would rarely skip one of the disciplines, such as Analysis & Design, Implementation, and so on, completely. In exceptional cases, some disciplines, such as Requirements or Deployment, may have been executed by other organizations. However, it's more likely that specific workflows within or across disciplines would be modified.  
  
• Work Products
  Projects are far more likely to differ by the work products that they have to produce, update, and deliver. At one extremity of the range, imagine a totally paperless project that electronically maintains only a small number of work products, is supported by tools such as spreadsheets, design tools, programming tools, and testing tools, and only delivers software and documentation electronically on disk, CD or over the World-Wide Web. At the other extreme, there are projects that must produce and maintain a much larger set of printed documents for contractual, regulatory or organizational reasons. In some cases, complete models can be omitted.
  
• Tasks
  Tasks are likely to vary for at least two reasons. Tasks that use work products as input and produce, or update, work products as output are affected by the modification of these work products; in particular, if some work product, or some element of information in a work product, is no longer necessary, the corresponding steps maybe suppressed or significantly modified. Tasks are also modified to introduce specific techniques, methods, and tools that pertain to the specific application domain or development expertise, such as design steps, programming languages, automatic code generation tools, measurement techniques, and so on.

At a more detailed level, other method elements can be modified, added or suppressed:

• Roles
• Steps in tasks
• Guidelines and guidance for tasks
• Notations, such as using subsets of the UML or using stereotypes to address some specific need for some, or all, models
• Checklists for reviews
• Tool support to automate some tasks
• Terminology changes, for instance to adapt the process to the organizational context

In summary, the process engineer must make a wide range of decisions when tailoring the RUP. RUP may have to be adjusted to take advantage of certain well-established company practices and standards, such as documents, terminology, and so on.

Difficult Tailoring Scenarios

Certain tailoring scenarios are difficult to implement and must be considered very carefully. For example:

• Change in process architecture
  Wide-ranging repackaging of the tasks into another set of disciplines to match an existing process or organization may lead to a lot of effort for very little gain. Often, it's more practical to simply establish a mapping to assess whether all aspects are covered by the RUP. Remember that the disciplines are not phases sequentially executed-they are containers for tasks, and are executed again and again in each iteration, often concurrently within one iteration.
  
• Changes in terminology
  Although substituting one word for another may sound like a trivial exercise in word processing, such changes must be considered very carefully. In the domain of software engineering, organizations often use the same word with slightly different meanings, or different words that mean the same thing. Making isolated changes in the RUP may lead to a process that is very difficult to understand. One solution is to create a "translation table" for the terminology that translates between the RUP terminology and the organization's terminology.

Examples of dangerous words are system, phase, role, activity, task, model, and document.

If the process results are captured in a language other than English, the terminology issues are more complex where you must translate the descriptions of work products, documents, reports, and possibly other parts of the RUP to this other language.