Activity: Tailor the Process for the Project Purpose To right-size the software development process according to the specific needs of the project To provide a relevant and accessible process description for the members of the project Role:  Process Engineer  Frequency: The bulk of the work takes part at the onset of the project. May repeat as necessary in any iteration Steps Analyze the Project Define the Scope of the Process Extend the Process Framework (optional) Configure the Process Prepare the Process for the Project Introduce the Process to the Project Members Maintain the Process Input Artifacts:  Development Process Resulting Artifacts:  Development Process Tool Mentors:  More Information:  Concept: Agile Practices and RUP Concept: Iteration Guideline: Process Discriminants Guideline: Process Tailoring Practices Concept: Tailoring a Process for a Small Project Workflow Details:    Analyze the Project Purpose:  To get a feel for the problem at hand, and the resources available to the project. It is crucial for the success of the project that the development process is relevant for the project at hand, and for the size and formality requirements of the project. Too much process tends to get in the way of creativity and efficiency. Too little process can lead to a chaotic environment, typically leading individual project members to make local decisions that may result in inefficient, inconsistent and unpredictable results. Process ceremony varies a lot in different development organizations. Some are very process mature, and have dedicated process groups to look after the definition and improvements of the development process throughout the organization. Others are concerned with project-specific tailoring only. These projects will typically start with one of the predefined configurations that come with the RUP product, and from there instantiate the process for every project. The approach taken to tailor the process for the project, depends heavily on several factors, for instance : The development organization's process maturity. The size of the project in terms of calendar time and number of development resources. The project members previous exposure to similar processes. The formality requirements of the project. See Guideline: Process Discriminants for details.   Define the Scope of the Process Purpose:  Define which process areas to cover in the project-specific process. The results of analyzing the project resources and their experience with similar software development projects helps identify the scope of the tailoring effort. A project-specific process does not have to include all the disciplines in RUP, nor should it be necessary to cover all the roles defined in the RUP. Keep in mind that the RUP is a process framework suitable for a wide range of project types, and thus will be too much for one specific project to follow. Which areas you select to cover in the project's process, depends heavily upon the existing skill sets of the project members, and the nature of the project at hand. Below are some typical considerations to make when defining the scope of the tailoring effort. Areas where the project members already have a common way of working, where it is not necessary to introduce a new process and tools. For example, if they know how to test, it can be a good idea to not introduce the Test discipline of the RUP to limit the number of new factors. You can focus on introducing some parts of the RUP, to correct problems in their existing process.  See Concepts: Implementing a Process in a Project, section "Improving Process and Tools", for details.  Areas (disciplines) where the project must introduce new process and tools, because there is no existing way of working. In some cases there is no existing process and tools to fall back on, and it is necessary to introduce most of the RUP, together with supporting tools. See Concepts: Implementing a Process in a Project, section "Change Everything", for details.  Problems in the existing process. Focus on improving areas in which the organization has had problems. Which tools to use ? If the project has decided to use certain tools, the development process should normally cover the corresponding areas of the RUP. The project's capacity to change. When looking at the organization's problems there is a tendency to try to fix everything at once, especially since many of these problems occur together. This is usually a fatal trap. Organizations just like individuals can accommodate change but only within a limited range. If the capacity to change is low, you have to go slower, and maybe just introduce one or two disciplines of the RUP in the first project. Areas where the project's members lack knowledge, or are weak. Let the development process cover these areas. Make sure that it is easy to find the right information in the RUP. Identified improvement areas must not necessarily be introduced for the first time in the same project. Reduce the number of unknown factors and look at areas where the development organization has experienced the most pain in the past. We recommend that you implement the RUP iteratively, as described in the Concepts: Implementing a Process in a Project. Although there might be discovered needs for improvements within several disciplines, consider the option of introducing them iteratively over the course of several projects rather than aiming for a change-everything-at-once approach. One example of such a tradeoff is to introduce Requirements with Use-cases and defer the introduction of a new CM process, if previous projects have struggled with unclear and/or insufficient requirements, or if major complaints have been made by end-users that the delivered product does not meet their needs. The tradeoffs made should be documented to communicate the scoping decisions to external stakeholders. When creating the configuration in the RUP Builder product, these decisions can be documented as a description of the configuration and will surface in the published Website.   Extend the Process Framework (optional) Purpose:  To add additional process know-how to the project-specific process, in areas where the coverage in the RUP process framework is deemed insufficient for the project. One of the strengths of the RUP process framework is that it is applicable to a wide range of projects and environments. But this may at the same time be perceived as a disadvantage too, because the process description tends to become a bit too generic. The RUP plug-in technology is designed to overcome some of these issues by allowing tool or technology vendors and individual companies to create more specific process descriptions through plug-ins. You will find an up-to-date list of plug-ins available for download in the RUP section of developerWorks®: Rational®. The Rational Process Workbench™ (RPW) product enables the creation of RUP extensions using the RUP Plug-in technology. Following the recommendations for this technology, the RUP framework can be extended in two ways. You either create a structural plug-in to extend the RUP process model, or you create extensions that will provide a development organization's relevant reusable assets to the project through thin plug-ins. Creating a RUP plug-in (structural) should be treated as a project in its own right, with separate plans, budget and control mechanisms. You should define a business case for it, based on return-on-investment analysis. The actual development of the plug-in will benefit from following the lifecycle and disciplines in the RUP. We recommend that you try out the main ideas behind the plug-in on a real project before you start the project to develop the plug-in. See Guideline: RUP Tailoring, section Extend the RUP, for more information.   Configure the Process Purpose:  To right-size the process to support the exact needs of a project. The RUP framework is built up of a set of process components and plug-ins, each component contains a set of related process elements. Creating a RUP configuring means selecting between a set of process components. Selecting the right set of components for a given project is not a trivial task. To be effective, the process needs to be relevant and right-sized along different dimensions, like project size (resources and calendar time), formality, technological platform, domain, just to mention a few. For more detailed information on configuring RUP, refer to Concept: RUP Tailoring, section Create a RUP Configuration The Process Engineering Process (PEP) component of the Rational Process Workbench™ (RPW) product   Prepare the Process for the Project Purpose:  To define how the configured process is enacted in the project. A process description configured for a project is often not at the level of details ready to be enacted. For example, the process defines a set of artifacts to use based on a selection of relevant process components (as described in the previous section Create a RUP Configuration), but it does not specify timing and formality requirements of the artifacts for this particular project. Prescriptive guidelines and partially instantiated artifact templates are also considered to be part of an instantiated project-specific process. The required effort to perform this step is highly dependent on the precision of the configured process. Any such deviation from the underlying process should be justified and documented as part of the project-specific process. Sub-topics: Define Lifecyle Breakdown Tailor Artifacts Prepare Artifact Resources Define Lifecycle Breakdown The work of instantiating the configured process on the project involves deciding on a lifecycle model for the project to follow, including the breakdown into phases and iterations. For this part of the tailoring work, the process engineer should collaborate closely with the project manager since the chosen lifecycle model will lays the groundwork for the project planning process. Depending on the nature of the project, there might be a need to adjust the RUP lifecycle to better match the specific needs. For example, green field development usually requires more effort in Inception than a maintenance project. Thus, the lifecycle description should be adjusted according to the nature of the project. See Concept: Iterations for a discussion on various types of lifecycle models. Tailor Artifacts The configured process contains descriptions of the artifacts expected to be produced by the project. Since the configuration is likely to be defined to fit a certain type of project, this selection should be challenged as part of the instantiation process. Don't plan to produce an artifact if you can't explain why you need it. Artifacts should also be qualified with information, such as In which phase will this artifact be created or updated What is the required formality of the artifact (for example, does it need a sign-off by the customer) Which tools should be used to produce them This information may be kept in a spreadsheet or document accessible from the process Website, or it can be made an integral part of the process description. Prepare Artifact Resources for the Project As a part of any project-specific process, there should be a set of available resources tailored to provide specific help and reference material for producing project artifacts. Examples of such resources are : Common guidelines for how to produce certain artifacts, for example Use-Case Modeling Guidelines. Templates customized for use across projects. These will be partially instantiated with project information. Artifact examples relevant to the project's defined set of deliverables and chosen technology. Reusable assets, such as design patterns and code libraries. At the onset of the project, the Project Manager typically works with the Process Engineer to select the appropriate set of resources, and make them available to the project members as part of the project-specific process. The need for additional resources is revisited at the beginning of each iteration.   Introduce the Process to the Project Members Purpose:  To make the project-specific process available to the project's members. After the initial tailoring work is done, the resulting process needs to be published into a consumable format. The RUP Builder product provides a means to publish the configured process resulting in a RUP Website that contains only the selected process components and resources. The Process Engineer needs to work with the Project Manager to make the project-specific process public, and decide on how to educate the project members. This can vary from an informal 2 hour presentation to more formal training, depending on the size of the project and the project members' familiarity with similar development processes. Every significant update of the process during the project lifecycle, should be re-launched to the project, focusing on the changes. The Website for the project-specific process can be published to a Web server on the organization's network, or installed on each individual team member's computer. If the project members are connected to the network most of the time, then deploying the RUP Website to a Web server is recommended to avoid any overhead associated with updates to the process during the project lifecycle.   Maintain the Process Although the bulk of the tailoring work is done in the early days of the project, it should be kept up-to-date continuously, as the project teams uncover obstacles and other issues in the process. Assessments made during the project are important input to improving the process. Minor adjustments are typically handled by the project, and updates to the project-specific process are made as part of preparing the development environment for the upcoming iteration. More complex issues are raised as change requests on the process. This is usually handled by a process group outside the boundaries of the project, that has the responsibility of the software development process on an organizational basis. One of the major benefits of iterative development is that it allows the project teams to gradually improve the way they develop software. We recommend that every project include process engineering micro-cycles consisting of the following steps : Define process Perform project work based on defined process Assess your work Refine process The Process Engineering Process within the Rational Process Workbench product contains information on Process Improvement in an organizational setting. © Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process