Suppose you are the manager of an IT department whose software development staff needs more agility in its process to meet market requirements. The level of ceremony should be balanced with the scale and distribution of development, technical complexity of projects, and the need for documentation. The approach you adopt should focus on early risk mitigation, including technical risks. You strive to increase end user satisfaction by introducing iterative development. To meet these requirements, you and your development team have decided to use the Rational Unified Process®, or RUP®, in your future projects. You have made an important decision, but there are many more decisions to make now, which can be especially challenging for project managers who are new to RUP.
RUP contains an extensive library of artifacts, many of which you won't be needing. No organization requires them all. In fact, the first Key Principle of the latest version of RUP (7.0) is "Adapt the Process," so you need to tailor RUP to the size and needs of your organization and its projects. The result of this tailoring is part of what RUP calls a development case. In a development case, you describe all activities, roles, artifacts, and templates that are to be used in your projects.
Each selected supporting artifact (deliverable) will require resources to produce it. Each addition to the development case should be balanced with the expected benefits in terms of time saving, quality gain, or providing a basis for project estimation, planning, and scope management. In other words, too big a development case will unnecessarily drain money from your project. The question is: How do you proceed in getting your development case right? Are you going to find out how to tailor RUP by yourself, or are you going to hire an external RUP consultant or process engineer? Proceeding on your own, with your team looking to you for guidance, can be difficult without prior hands-on experience in tailoring RUP. You will have to spend quite some time figuring out which artifacts to skip, which to add, and determine how they should be used to fit into your project, department, or organization. In fact, you need to learn all of RUP to be able to tailor it in a useful way, so you'll be very busy for the coming six months.
On the other hand, you might hire a RUP consultant, someone who can advise you on what artifacts are mandatory and which are only needed in particular situations. The consultant can assist in modifying RUP templates to your needs and optimally using them as a tool for creating useful artifacts. But an external RUP consultant will have limited knowledge about your business, not to mention your organization or company culture. This means that the consultant will either use a considerable amount of (expensive) time learning your business -- or not, in which case you will end up with a development case that is not tailored to the needs and peculiarities of your company.
We have played the role of external RUP consultant and have defined successful development cases for a variety of companies. As consultants, we believe in the value of outside expertise in tailoring RUP, and we have developed a technique that helps speed up the tailoring process and at the same time addresses the specific needs of the organization. We introduce two concepts: the Responsibility Matrix and the Artifact Flow.
We use a goal-oriented approach to tailoring RUP, based on establishing "what" and "who." We start investigating what (which artifacts) a project should deliver. A strong advantage of starting with artifacts is that an artifact is a tangible thing. Project progress can easily be checked by looking at which artifacts have received a baseline status (have been formally approved).
An artifact must always be useful. This may sound trivial, but in many cases we have found artifacts written by people who have no idea what these were being used for. The question we always ask is, "What will go wrong when the artifact is not produced?" The answer to this question clarifies the goal of the artifact. If you cannot find a concrete answer to this question, chances are high that the artifact is superfluous.
After deciding on what artifacts to produce, we then investigate who (which role) is responsible for creating each artifact. We put the artifacts, roles, and responsibilities together in what we call a Responsibility Matrix. In the left column we put the artifacts; in the top row we put the roles. On the intersections we put symbols representing various responsibilities. This leads to a matrix as shown in Figure 1.
Figure 1: Example Responsibility Matrix
The author of an artifact is not the only one involved in its creation. To complete the matrix, we also investigate which roles support the creation process and which are responsible for formally accepting an artifact. Supporting roles give input through interviews, workshops, and reviews. We could, of course, distinguish finer-grained responsibilities, but this is rarely useful. Note that the role responsible for an artifact (for putting it to paper or assembling it) is the actual author. Since this involves special skills, this responsibility is not easily delegated. For instance, we take care not to assign too many artifacts to the project manager. He or she should only write down and be responsible for management artifacts.
The Responsibility Matrix facilitates the process of getting our development case right. It provides several advantages:
- We can fill in the Responsibility Matrix in one (or more) sessions, attended by all stakeholders. This makes it a joint effort that everyone agrees upon.
- We don't need a lot of knowledge of the business to support the creation of a Responsibility Matrix.
- The Responsibility Matrix can be used as part of the development case, to provide an overview of the main building blocks of the tailored RUP in a very concise and readable way.
The Responsibility Matrix can be filled in using different approaches. We will take a look at three of them.
The usual starting point is a set of standard RUP artifacts and roles. The RUP consultant takes an educated guess regarding what RUP artifacts and roles are needed in the organization and fills in all the responsibilities in a Responsibility Matrix. This Responsibility Matrix is then used as the basis for discussion with the stakeholders.
However, there are two downsides to this approach:
- There is no correlation with company experience. The Responsibility Matrix does not use roles and artifacts that are familiar to the stakeholders.
- From the stakeholders point of view, RUP introduces all new vocabulary. The Responsibility Matrix can therefore be hard to follow and understand. This is solved by giving people specific RUP training, tailored to their development case.
In the half-way strategy, the RUP consultant provides a reasonable set of artifacts and roles, including some company-specific artifacts and roles if needed, and fills these in on the Responsibility Matrix. But no intersections are filled in. The RUP consultant should see to it that any company-specific artifacts and roles do not overlap those already identified in RUP. After an explanation of the artifacts and roles, they can be shifted, renamed, or replaced, and responsibilities can be divided by completing the Responsibility Matrix.
The use of company-specific artifacts and roles, and the fact that the stakeholders choose their responsibilities makes it easier for them to identify with the new development case. However this approach has a downside too:
- Business knowledge is required to come up with a reasonable set of artifacts and roles. This means the RUP consultant has to spend time acquiring this knowledge.
We prefer a "start from scratch" strategy. The RUP consultant starts with an inventory session, during which all the stakeholders within the company are present. In this session, artifacts and roles that exist within the company are discussed and put into the Responsibility Matrix. The reason why an artifact or role is used by the company should also be discussed. Usually, when the participants explain the intention of existing artifacts and roles, lively discussions emerge in which gaps, overlaps, and inconsistencies in roles and artifacts are identified. In this scenario, the RUP consultant plays the role of a mediator, accepting the roles and artifacts presented by the stakeholders and trying to find corresponding RUP roles and artifacts. It is crucial that stakeholders eventually agree on every role and artifact.
The advantage of this approach is that stakeholders (outsiders to the RUP) can start with familiar artifacts and roles and clearly explain their intention to each other and to the RUP consultant. The RUP consultant (an outsider to the business) can then use his or her knowledge of the RUP to translate the stakeholders' input to RUP where possible and identify company-specific roles and artifacts that should be retained.
RUP has many detailed roles and artifacts. It can be useful to extend or reduce the contents of RUP artifacts to meet the needs of the company. It is also possible to combine responsibilities of several roles into one role or divide responsibilities of one RUP role among several existing ones. For instance, RUP has one administrator role, the system administrator. In many companies, this is split into two roles: one responsible for hardware and operating systems and another responsible for administering applications.
During the process of creating the Responsibility Matrix, it is useful to map the artifacts and roles in the new Responsibility Matrix on their counterparts as used in the original company setup. This will help people relate what is expected from them within the new RUP approach with their current work.
The result of this approach is a Responsibility Matrix defined as much as possible in terms of RUP roles and artifacts. This means every team member can utilize the vast RUP documentation in gaining a better understanding of the new approach. Also, new team members with some knowledge of RUP can quickly find their way in the project. At the same time, however, the Responsibility Matrix is strongly rooted in the company's existing best practices.
As soon as there is agreement upon which roles and artifacts to use, and how to call them, the RUP consultant can proceed by allocating responsibilities in the Responsibility Matrix. Usually, we do this in a separate session. Every artifact should at least have one role (the actual author) given the "write" responsibility (W), and most artifacts receive the contribute/review responsibility (C) as well. Some artifacts, moreover, must be formally accepted (A). See Figure 1 for an example.
After defining the Responsibility Matrix with all the stakeholders present, the next step is to add more detail. In this stage, we focus on the relationships among the artifacts that we have defined in the Responsibility Matrix.
In general, an Artifact Flow is set up in a separate session, in which the relationships among artifacts is established. Suppose we have reached agreement upon the following artifacts: Vision, Use-Case Model, Software Architecture Document, Use-Case Specification, Use-Case Realization, and Components. It is then quite easy to do a proposal concerning their relationships. We only concentrate on the relationships among artifacts, not on which roles work together or are responsible for their production. See Figure 2 for an example using the artifacts mentioned.
Figure 2: Example Artifact Flow
The relationship between Vision and Use-Case Model is a straightforward, one-way relationship. The Use-Case Model is derived from the Vision. This doesn't mean that the Use-Case Model can only contain elements from the Vision. A Use-Case Model should present the same scope as the Vision, only in more detail. Any Use-Case Model element outside the scope of the Vision should lead to a discussion on adjusting the Vision or removing the out-of-scope element from the Use-Case Model.
The Software Architecture Document (SAD) is also derived from the Vision, and the same observations made above are valid here as well. The Software Architecture Document receives input from the Use-Case Model as well, since in the SAD, we need a statement of which use cases are to be regarded as architecturally significant -- i.e., which form the heart of the system. The Use-Case Model in turn is the source for the subsequent Use-Case Specifications. Again, details about use cases are supposed to turn up, but if there is functionality in the use case details that is not within the scope of the Use-Case Model, we need to decide if the Use-Case Specification or the Use-Case Model should be adjusted.
In the Use-Case Realization, we meet both functional and non-functional specifications, i.e. Use-Case Specification and SAD. The Use-Case-Realization only contains the elements that follow from the Use-Case Specification but do not follow from the SAD. In other words, if the directions in the SAD together with the actual Use-Case Specification are sufficient for the developer to build the code of the use case, the Use-Case Realization is empty. In practice, we put the Use-Case Realization document in place as a reference. In that case (so we agree with all stakeholders), we build the code, and test and document it following the SAD.
The Artifact Flow has one big advantage. The main flow within a project is directly visible in a concise format. The main flow that will otherwise appear in an activity flow is directly visible.
The Responsibility Matrix and the Artifact Flow give a concise, yet complete overview of the main parts of the development case. When they are defined using the strategy explained in this article, they also ensure that the new RUP approach is rooted in the best practices the company has acquired over the years.
Remi-Armand Collaris is a project manager and RUP consultant at Ordina, based in The Netherlands. He has managed Java EE/RUP software development projects for a number of financial and semi-government institutions. An important part of his work at Ordina is contributing to the company’s RUP development case and giving presentations and workshops on RUP and project management. With co-author Eef Dekker, he wrote the book RUP op Maat, Een praktische handleiding voor IT-projecten in Dutch, translated as RUP Tailored, A Practical Guide to IT Projects, published in 2006.
Eef Dekker is a systems analyst and RUP consultant at Ordina, based in The Netherlands. With co-author Remi-Armand Collaris, he wrote the book RUP op Maat, Een praktische handleiding voor IT-projecten in Dutch, translated as RUP Tailored, A Practical Guide to IT Projects, published in 2006.