Process Tailoring and Deployment Strategies
Tailoring and then deploying your software process is an important aspect of the Enterprise Unified ProcessTM (EUP)’s 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 RUP/EUP to meet the specific needs of a category of projects.
Table of Contents
1. Organization-Level Development Cases
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 cases.
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 management.
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.
2. A Simple Deployment Strategy
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 techniques.
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 an agile 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 approaches.
- 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 rule.
- 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.
3. Configuration Management (CM) Issues
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.
Recommended Reading
 |
This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context. This book represents leading-edge thinking about enterprise agile, some of which originated in the EUP and RUP. |
 |
This book, The Enterprise Unified Process: Extending the Rational Unified Process, defines the Enterprise Unified Process® (EUP), which was first introduced by myself in 1999 and later enhanced to support a wider variety of clients. The EUP is an extension to the IBM Rational Unified Process (RUP). The EUP extends the RUP to include the operation and support of a system after it is in production and its eventual retirement. Furthermore, because all but the smallest organizations have more than one system, the EUP also handles cross-system enterprise issues such as portfolio management, enterprise architecture, and strategic reuse. |