Best practices for change management based on RUP

Tian haili

 

Software Engineering is not only a theoretical discipline in books, but also very practical. Software Engineering originated from Western management science theories and knowledge and has been put into practice in many Western companies. I have more than 10 years of work experience, served the world's leading giant companies, and also waited for the majority of domestic companies. From software engineering, we can see that the theoretical knowledge learned in the school can be actually implemented in western companies, and the results are good. However, many domestic companies have almost no rules to do things, and the situation will continue. Changing this situation is a systematic process, and what our generation can do is to start from scratch and gradually improve.

 

This article describes how to customize the change management policies and working mechanisms Suitable for your teams and projects based on the change management recommended by the rational process (rationalunified process.

 

1. Change Request/Cr Management in RUP

 

The following two figures show the activity diagram of change management (figure 1) and the State Diagram of Cr (figure 2 ).

Figure 1. Examples of change management activities in RUP

 

 

Figure 2. Status chart of the change request in RUP

 

The information described in the two figures is clear and will not be elaborated here.

 

Ii. Change management practices

 

The following describes the essence of change management in the RUP. However, many organizations customize or weaken them in actual customization.

 

1) All stakeholders can submit a change request (CR)

 

All project-related personnel should be able to submit Cr. Because any person in the project may have their own opinions on the project, this should be an exit, submit this idea to Cr, and Cr can be a new requirement or a bug. The new CR does not need to be implemented in the current iteration cycle, and must be reviewed and determined by CCB.

If the CR submitter is not a tester, the test Manager is required to designate the tester to verify during subsequent Cr tracking.

 

All project-related personnel should submit the CR and should not stay on the permit, but should establish a mechanism to encourage such behavior.

In the actual implementation process, other non-testers often do not pay attention to the submission and execution of Cr. Later, we will find that, except the testers submit Cr, others do not submit the submission, this may have missed many good ideas and opportunities for improving projects.

 

2) CCB and CCB review meetings

 

InCCB (Change Control Board) Change Control Board. The Committee monitors the change process and consists of representatives of all stakeholders, including customers, developers and users. In small projects, a project manager or software architect can assume this role.

CCBReview Meeting-The role of this meeting is to reviewSubmitted. The content of the change request will be reviewed initially at the meeting to determine whether it is a valid request. If so, based on the Group's priority, schedule, resources, effort, risk, severity, and any other relevant standards, determine whether the change is within or outside the scope of the current release version. This meeting is generally held once a week. If the number of change requests increases significantly or the release cycle ends, the meeting may open once every day. The CCB Review Meeting is generally a member of the test Manager, Development Manager, and marketing department. Participants will be added as needed.

 

Highlights of CCB and CCB review meetings:

• All developers and testers at the Conference, especially at the implementation stage, can further communicate with Cr on the definition, style, and progress of the project/product to make the goal more consistent. The CR submitted in the future will be more targeted and of higher quality.
• The subsequent State changes of Cr are the result of discussion with the participants. The allocation of Cr is not prone to the same problem assigned to different personnel; or many invalid or poorly defined Cr are assigned to developers, and they cannot make a decision. In turn, assign gives others such repeated turnover. These problems have been solved before CCB is assigned here.
• The granularity proposed by Cr will be consistent after the CCB review meeting. In different phases of the project, the granularity is inconsistent. For example, in the initial phase of a project, the implementation is incomplete and the granularity is very rough. in the later stage of the project, the problem may be submitted very fine. This is not completely consistent, but after continuous communication, the granularity of different people submitting CR at a certain stage will be consistent.
• Regardless of the CR, the change is also reviewed to confirm whether the change is valid and to assess the priority, schedule, resources, risks and severity.
• A meeting may not process all the CR (including the newly submitted Cr/the CR that supplemented the updated information/the Cr of postponed in the previous week to be considered in this iteration cycle ). Therefore, before the meeting, CCB can entrust a representative to make a list of these Cr Based on the priority or severity level and process the CR in this order.

 

This is something that many organizations do not do and will often encounter:

• The same problems described by different phenomena are constantly submitted or repeatedly submitted by different people;
• The newly submitted Cr is directly assigned to the developer. Developers have different understandings and do not need to change the Cr. If there is sense for the project as a whole, the reassign will make decisions for the relevant person, some people directly make changes regardless of November 21. In addition, assign is usually used to determine the module based on the symptom, but the reason may be the same. In this way, it is inevitable that different people are making the same change, but they do not know each other.

 

This has nothing to do with the level of personal understanding and knowledge cognition. As an organization, it must be guaranteed by institutional and institutional strategies.

Cr is an important basis for personnel evaluation. If there is a problem with the mechanism, the evaluation system for people should be based on objective data. It is obvious that the enthusiasm and morale of team members will be a blow.

 

3) repeated (duplicate)/rejected (rejected) Cr Processing

CCB determines that duplicate/rejected CR should have the opportunity for the submitter to supplement the information. CCB determines that duplicate/rejected Cr is not necessarily invalid. This should be confirmed by the submitter. It may be because the submitted information is ambiguous and the request is deemed as duplicated/rejected. After the submitter updates the CR, the CR will be reviewed by CCB to determine whether it is valid and to assess the priority, schedule, resources, risks and severity ..

The rejected or duplicated Cr can be disabled by the submitter.

 

4) postponed Cr Processing

The so-called delayed Cr means that Cr is valid, but is not changed in the current iteration version. Therefore, at the beginning of the next iteration cycle, the previously deferred Cr will be reviewed by CCB together with the newly submitted Cr and updated Cr to determine whether it is valid, the priority, schedule, resources, risks, and severity are also evaluated.

 

5) resolved (resolved) and verified (verified) Cr

There are two versions in the version of the test and the official release of the version, so there are two States for the CR resolved and verified.

The requested changes to artifacts (not limited to code, but also requirements, analysis design, implementation, creation of user support materials, design testing, etc, after review and unit test activities, Cr is confirmed and marked as resolved.

In the beta version, if the resolved Cr is included, the CR will be verified in the beta version. The verification passes the authentication and marks the Cr as verified, which can be officially released.

The verified Cr can be closed only after it is confirmed in the released version ).

 

According to the organization's scale, release frequency, and quality requirements, not all organizations may have two versions. However, this can further confirm the quality of released versions and customize the change management policies as needed.

However, no matter what the final custom result is, it is best to have two figures similar to the above, and be fully understood and executed within the organization!

 

3. Tools selection and customization

The key to change management is the idea and customization of policies suitable for your organization and projects. tools are not the most important, but good selection of suitable tools is a tool to improve efficiency and enhance communication. Currently, many free or commercial change management tools can be customized to meet the following requirements:

 

User Management

The change management tool should be able to manage users based on role configurations. This is a basic requirement and can be met by general tools.

Cr status and corresponding conversion can be customized

Generally, the CR status can be added or changed according to the customization in the tool;

In addition, there are several paths in the transition process from one State to another. The possible next state selection should be given based on the transition diagram;

It is recommended that the corresponding owner be automatically changed based on the new status after the CR state is changed.

Email Notification

The change management tool should have a basic email notification mechanism. When Cr changes, you can promptly notify the persons interested in CR by email. The email list of the persons you are interested in should be manually added.

Reports

Convenient and powerful report functions are crucial to project Cr tracking and data analysis.

Combined with configuration management

It is the best combination of change management tools and configuration management tools. Rational clearcase and clearrequest are configuration management tools and change management tools, which can be seamlessly integrated. However, as commercial software, the price is unacceptable to many companies. However, this is not necessary. You can add a field in the change management tool to point to the change information in the configuration tool.

Distributed Web Access

This is not an absolute requirement. However, if your company has multiple offices or needs to work at home, this is necessary.