Guideline: RUP Tailoring








var backPath = './../../../';
var imgPath = './../../../images/';
var nodeInfo=[{view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_jD8dUAIbEdqEutyfYo0quQ", "_2ClPcDIcEdqDs_9ORT1Rig", "_8rV68EdLEdqul7OS-EQhrQ"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', false, false, false);










Guideline: RUP Tailoring















This guideline provides recommendations for tailoring the RUP for an organization or project.






Main Description



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.





©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();