Purpose

The purpose of the environment discipline is to support the development organization with both processes and tools. This support includes the following:

• Tool selection and acquisition

• Setup of tools and configuration of tools to suit the organization

• Process configuration

• Process improvement

• Technical services to support the process: the information technology (IT) infrastructure, account administration, backup, and so on

Some of the activities related to process implementation and configuration are described in Chapter 17, Implementing the Rational Unified Process.

The activities related to the definition, configuration and implementation of the software development process constitute effectively a process distinct from the software development process ”the Process Engineering Process (PEP). It is an optional component that may not be installed or accessible to all software practitioners .

Configuring the Rational Unified Process

The RUP process framework contains a vast amount of guidance, artifacts, and roles. Because no project can use all of these artifacts, you need to specify a subset of the RUP to use for your project. This is done by selecting or producing a RUP Process Configuration, which constitutes a complete process from the perspective of a particular project's requirements. You can use one of the ready-made configurations "as is," use a ready-made configuration as a starting point for yours, or create a process configuration from scratch.

• A RUP Process Component is a coherent , quasi-independent " chunk " or module of process knowledge that can be named, packaged, exchanged, and assembled with other process components .

• A RUP Library is a collection of Process Components out of which a set of RUP Process Configurations may be compiled with RUP Builder. New process components can be added to a RUP Library through the means of RUP Plug-Ins.

• A RUP Base is a collection of RUP Process Components meant to be extended by applying plug-ins to generate RUP Process Configurations. It resides in a RUP Library.

• A RUP Plug-In is a deployable unit for one or several Process Components that can be readily "dropped" onto a RUP Base to extend it. A RUP Plug-In is encapsulated into a single physical file, allowing it to be moved around and added to a RUP Library with a compatible RUP Base.

To use a programming language analogy, a RUP Plug-In is a "precompiled" RUP Process Component, ready to be "linked" into a RUP Base to create a RUP Configuration.

There are two main RUP Bases:

• One for small, informal projects

• One for larger or more formal projects

And there is a large collection of RUP Plug-Ins available, addressing issues related to domain (real-time, MIS), to technologies and languages (Java, J2EE, NET, and so on). Some plug-ins are developed by IBM/Rational and are delivered with the product, some are available from the IBM Web site, and some are developed by partner companies.

A RUP Configuration also includes Process Views , which are role-based or personalized access to a RUP configuration.

Instantiating the Rational Unified Process

Each project team needs to decide how it is going to use its RUP Configuration, which artifacts will be used and how, which tools will be used and how, which roles will be required and who will play them. This is captured in a Development Case , which is the main artifact produced in the Environment discipline.

You can also create a Project Web Site that acts like a portal to all the actual artifacts used in the project, including the Development Case and the RUP Configuration.

Customizing the Rational Unified Process

Some organizations may need to create RUP Configurations that are different from what can simply be assembled out of RUP Bases and RUP Plug-Ins. They want to include their own process guidance, adding to the RUP, or modifying or extending existing elements of the RUP. They also want to continuously improve their process and capitalize on the lessons learned at each iteration, phase, or project by extending their configurations. They can achieve this by developing their own RUP Plug-Ins.

• A Thin Plug-In does not change the structure of the RUP. It merely substitutes new content to existing process elements or adds some guidance such as guidelines and tool mentors. Such a Plug-In is usually sufficient for capturing company-specific templates, adding steps to activities, or modifying an artifact outline.

• A Structural Plug-In does change process elements and their relationship. It is used to add process elements such as roles, artifacts, workflow, and whole disciplines.

Implementing the Rational Unified Process

The most challenging task of the Process Engineer is undeniably to deploy or "roll out" the Rational Unified Process in an organization. This is often a project in itself, which includes configuring and customizing the RUP, and also involves assessing the current organization, setting up goals, and organizing training and mentoring. See Chapter 17, Implementing the Rational Unified Process.