Simplify the tailoring of RUP: introduce responsibility matrix and workpiece Flow

Imagine that you are the manager of an IT department. Development Staff meet the market Requirement The process requires more flexibility. The process level should be balanced by the development scope and distribution, the technical complexity of the project, and the document requirements. Your approach should focus on reducing risks early, including technical risks. By introducing iterative development, you will strive to increase the satisfaction of end users. To meet these requirements, you and your development team have decided to use Rational Unified Process in your future projects ?, Or, it is called "rup ?. You have made an important decision, but now you have more decisions to make, especially for project managers who are not familiar with RUP.

Dilemma

RUP contains an extension library of artifacts, many of which you don't need. No organization needs all the content. In fact, the first key principle of the latest version of RUP (7.0) is "Adapting processes to organizations and projects ", therefore, you need to tailor the RUP according to the size and needs of your organization and its projects. The result of this tailoring is part of the RUP, known as the development case ). In the development case, you will describe all activities, roles, artifacts, and templates used in the project.

Each selected supporting workpiece (deliverable) requires resources to produce it. Every element added to a development case should be balanced based on the expected benefits. You need to consider the following aspects: time saving,QualityObtain, or provide a basis for project evaluation, planning, and scope management. In other words, too many development cases will waste the project money without any need. Q: How do you continue to make your development case normal? Do you want to find out how to tailor the RUP, or do you want to hire a consultant or process engineer from outside? It is very difficult for your team to handle the tailoring by yourself so that your team can wait for your guidance. You will have to spend some time figuring out which artifacts are to be omitted, which one is to be added, and how to use them for your project or organization. As a matter of fact, you need to understand all of the RUP before you can properly tailor it, so you will be very busy in the next six months.

In another way, you can hire a RUP consultant who can guide you in what artifacts are mandatory and what artifacts are needed under specific circumstances. Consultants can help modify the RUP templates as needed and use them most appropriately to create useful artifacts. However, external RUP consultants have limited understanding of your business, not to mention the culture of your organization or company. This means that the consultant will spend a considerable amount of time learning about your business-otherwise, the result will be tailored development cases that do not meet your company's needs and features.

We have assumed the role of an external RUP consultant and have successfully defined development cases for various companies. As a consultant, we believe in the value of tailoring the external expert experience of RUP, and we have developed technologies that help accelerate the tailoring process while describing the specific needs of the Organization. We will introduce two concepts: responsibility matrix and workpiece flow.

Responsibility Matrix

We use a target-oriented method to tailor the RUP based on what and who. We started to look at what the project should deliver (which artifacts ). One of the major advantages starting from the workpiece is that the workpiece is tangible. It is easy to check the project progress by observing which artifacts obtain the baseline status (which has been officially approved.

The workpiece must always be useful. This may sound insignificant, but in many cases we have discovered artifacts written by people who do not know what the purpose of the artifacts is. The question we often ask is, "If no workpiece is generated, what will happen ?" The answer to this question clarifies the purpose of the workpiece. If you cannot find the specific answer to this question, it is likely that this is redundant.

After deciding which workpiece to generate, we will study who (which role) is responsible for creating each workpiece. We put the artifacts, roles, and responsibilities together in our responsibility matrix. We place the workpiece in the leftmost column and the role in the top row. In the cross section, we place the symbols that indicate various responsibilities. This forms the matrix shown in 1.

Responsibility matrix instance

 

The creator of the workpiece involves not only the person who created the workpiece. To complete the matrix, we also need to study which roles support the creation process and which roles are responsible for formally receiving an workpiece. Support role input through interviews, seminars, and comments. Of course, we can identify fine-grained responsibilities, but this is rarely useful. Note that the role responsible For the workpiece (writing it on paper or collecting the workpiece) is the actual author. This involves special skills, so this responsibility is not easy to delegate. For example, do not assign too many artifacts to the project manager. He or she should only write and manage the artifacts.

The responsibility matrix will simplify the process of obtaining appropriate development cases. It provides many advantages:

◆ We can fill in the responsibility matrix at one (or more) meeting attended by all stakeholders. This makes it a joint work that everyone agrees.
◆ We do not need to have a lot of knowledge about the business to support the creation of the responsibility matrix.
◆ Responsibility matrix can be used as part of development cases to provide an overview of the main building modules of the tailored RUP in a very concise and easy-to-read manner.

Fill in responsibility matrix

The responsibility matrix can be entered in different ways. Let's take a look at three of them.

Policy 1: Starting from 100% RUP

Generally, the starting point is a set of standard RUP artifacts and roles. The RUP consultant makes a rational speculation about the required RUP artifacts and roles in the Organization, and fills in all responsibilities in the responsibility matrix. This responsibility matrix is subsequently used as the basis for discussion with stakeholders.

However, this method has two disadvantages:

It is irrelevant to company experience. The responsibility matrix does not use roles and artifacts familiar to the stakeholders.
From the public's point of view, RUP introduces all new words. Therefore, the responsibility matrix is hard to understand. This problem can be solved by providing specificTrainingAccording to the development case.

 

Policy 2: Starting from the middle

In this policy, the RUP consultant provides a reasonable set of artifacts and roles, including specific company artifacts and roles, if necessary, and writes these in the responsibility matrix. But do not fill in the cross section. The RUP consultant should try to prevent all the unique artifacts and roles of the company from overwriting the content already identified in the RUP. After interpreting the artifacts and roles, you can move, rename, or replace them and divide responsibilities by completing the responsibility matrix.

The use of unique artifacts and roles of the company, as well as the fact that the stakeholders select their responsibilities, makes it easier to identify new development cases. However, this method also has an disadvantage:

Providing a reasonable collection of artifacts and roles requires business knowledge. This means that the RUP consultant has to spend time learning business knowledge.

Policy 3: from scratch

We like the "starting from scratch" strategy. Throughout the process, all stakeholders of the company will be present at the R & D meeting starting from the R & D meeting. In this meeting, we will discuss the artifacts and roles in the company and add them to the responsibility matrix. We should also discuss the reasons for using a specific workpiece or role. Generally, when participants describe existing artifacts and role intentions, there will be active discussions about the differences, overlaps, and inconsistencies between the identified roles and artifacts. In this situation, the RUP consultant plays the role of an intermediary, accepts the roles and artifacts proposed by the stakeholders, and tries to find the corresponding roles and artifacts of the RUP. It is vital that stakeholders ultimately agree to each role and task.

The advantage of this method is that the stakeholders (the RPA) can start from familiar artifacts and roles, and can clearly explain their intentions to the RPA. The RUP consultant (a business layman) can then use his or her knowledge of the RUP to Transform stakeholder inputs into the RUP wherever possible, and identifies the roles and artifacts specific to the company that should be retained.

RUP has many detailed roles and artifacts. It may be useful to extend or reduce the content of the RUP artifacts to meet the company's needs. It is also possible to combine the responsibilities of several roles into one role, or to separate the responsibilities of one of the many existing roles. For example, RUP has an administrator role as a system administrator. In many companies, this role is divided into two roles: one is responsible for hardware and the other is responsible for managing applications.Program.

In the process of creating a responsibility matrix, it is useful to map the artifacts and roles in the new responsibility matrix to the original responsibility settings of the company. This will help people to associate what they expect in the new RUP method with their current work.

The result of this method is to determine as much as possible the responsibility matrix of the rational roles and artifacts. This means that each team member can use a large number of RUP documents to gain a better understanding of the new method. At the same time, new team members with some RUP knowledge can quickly find their roadmap in the project. At the same time, however, the responsibility matrix is rooted in the company's existing best practices.

Once an agreement is reached on which roles and artifacts are to be used and how they are called, the RUP consultant can continue to assign responsibilities in the responsibility matrix. We usually do this in a separate meeting. Each workpiece should have at least one role (actual author) with "write" Responsibility (w), and most of the artifacts should receive both Contribution/review responsibilities (c ). In addition, some artifacts must be formally accepted (). See the example in Figure 1.

Workpiece Flow

After determining the responsibility matrix with all stakeholders on site, the next step is to add more details. In this phase, we focus on the relationships between artifacts that have been defined in the responsibility matrix.

Generally, the workpiece flow is set in a separate meeting and the relationship between the artifacts is established. Imagine that we have reached an agreement on the following artifacts: foreground, case model, software architecture document, Case Specification Description, case implementation, and components. It is very easy to make a proposal on the relationship between them. We only focus on the relationship between artifacts, not on which roles use them, or are responsible for creating them. See the example in Figure 2, where the mentioned artifacts are used.

Workflow instance

 

The relationship between the foreground and the use case model is direct and unidirectional. The Use Case model comes from the foreground. This does not mean that the use case model can only contain elements from the foreground. The Use Case model should indicate the same scope as the foreground, but is more detailed. The Use Case model elements outside the scope of any foreground should lead to a discussion about adjusting the foreground or removing out-of-range elements from the use case model.

The software architecture Document (SAD) also comes from the foreground, and the observations above are also valid here. The software architecture document also receives input from the use case model. In sad, we need to consider which use case is very important-that is, which is from the core of the system. The Use Case model is the source of subsequent use case specification descriptions. A detailed description of the use case should appear again. However, if the use case details contain functions beyond the scope of the use case model, we need to determine whether to adjust the use case specification or use case model.

In the case implementation, we meet the functional and non-functional specifications, that is, the case Specification Description and sad. Use Case implementation only contains elements from the use case Specification Description but not from the sad. In other words, if the instructions in sad, together with the actual use case specifications, are sufficient for developers to build Use CasesCodeThe Use Case implementation is empty. In practice, we use the example implementation document as a reference. In that situation (we reach an agreement with all the stakeholders), we build code andTestAnd document preparation.

The workpiece flow has an advantage. The main stream in the project is directly visible in a concise format. In addition, the main stream that appears in the Active Stream is also directly visible.

Conclusion

The responsibility matrix and workpiece flow provide a concise but complete overview of the main parts of the development case. When using the policies described in this article, make sure that the new RUP method is rooted in the best practices accumulated by the company over the years.