[Full modeling] How to use configuration management tools

This article is selected from the second version of "Software Engineering refers to full modeling implementation". Different from the previous article, this section of text is newly written and compiled from the configuration management aspects in the blog, because the manuscript has not been completed yet, I am sorry for my friends and want to share some of the content with you.

Note: Because images cannot be uploaded, no matching images are provided in this document.

1.1.1 Introduction

The document about configuration management tools that we can find on the Internet is described as follows:

What is configuration management?

What configuration management tools are available?

Configuration management tools.

Select a configuration management tool.

How to develop and execute the configuration management plan.

And so on.

In the above topics, configuration management tools are used independently or related to configuration management.

This section does not aim to introduce the general usage or the above content of the configuration management tool. The purpose of this article is mainly to solve the problem of coordination between the configuration management tool and the general documentation, as well as between the modeling tool and even the development coding tool, how can we use this to verify the authenticity of information in the configuration management tool and prevent fraud in software development.

1.1.2 reasons for using the configuration management tool

 

Problem:

In the final CMM review attended by the author in 2001, the chief evaluators from India asked the design team to provide the design change request materials and design change results after the dialogue, we promised on the spot.

We did the design change, but because it was a small tool product development at that time, there were only a few design changes, because the entire development cycle was only three months of small projects. During these changes, we adopted the negotiation method and did not send emails as a mark or other change documents. So we told the chief evaluators, we used the Lotus Notes internal OA system to send an internal change application email and an approval email. The chief evaluator asked us to print the relevant email content for his review.

Solution:

After we left the conversation, it took 15 minutes to issue two emails (because one of my friends is a top notes expert ), even the calibration time and date are completely in line with the "actual" situation. As a result, this only weakness was approved by the chief evaluators. We analyzed that all the design teams were up to standard.

 

The problem of such a case has also been staged in many companies and has occurred in many review processes, but the types are slightly different, and the fake content is different.

Then, there are two points of view on how to solve this problem:

One aspect is that as a non-developer, How do you avoid being cheated? Whether you are a manager of an enterprise, a so-called chief evaluator/ISO prereviewer, or a related role, or even a tendering reviewer or a customer/user, you need to know what the technicians are doing. Is it true?

On the other hand, how to effectively use configuration management tools for technical personnel so that enterprise managers can know that they are not wasting time and how to let customers/users know that they are working hard, you know how many steps you have taken to find such a quick path to implement the functions you need-many times code refactoring, it is a process of finding a destination faster on the winding road. These winding paths are inevitable. However, non-developers can only see your results, they generally do not see the intermediate process and hardships. Therefore, there are a lot of reselling/selling code in China, and even a very large-scale complex system (the price can exceed 10 million in foreign countries) the price is only several hundred thousand or even several thousand yuan.

Solution

To address this problem, we, as technicians, must objectively reflect the difficulties and processes we have experienced in our technology and R & D processes, and be more pragmatic. All readers of this book can see that this book has a distinctive revision history, this historical record records the author's self-written independent articles, the subsequent merger, and the first official publication, later, I wrote new articles and the process of re-integrating these completed texts with the entire book. This revision history list is also applied to China Telecom MSS system specification documents at the end of 2002. The following section describes the revision history list of this document as an example:

Figure 8 ‑ 14 starting part of the Revision list of china telecom mss system specification document

The middle part is omitted, and the content of some designer's name is covered. Other content is retained to provide authentic and reliable information of this document for readers.

Figure 8-15 revision list of china telecom mss system specification document

During the development process, we can copy the content of these revision instructions in the document to the comment of the configuration management tool. The two correspond to each other to form the reliability verification of all documents.

During the review, the reviewer can check whether the keynote in the revision record of the document is consistent with the comment content of the document in the configuration management tool. If the number of versions in the configuration management tool is too small, or the revision time corresponding to the comment content is different from the revision time in the document, so that the document can be identified as fake. If the gray-haired chief evaluators in India opened the configuration library and conducted such validation searches, or commissioned his assistant to do the work, then the problem will be discovered.

For a technician, if such a document is placed in front of a reviewer of any level, he cannot deny the work you have done in the work process. On this basis, no one will be tempted, at least it adds a sense of sympathy for your work. In the final review of China Telecom group, all the leaders participating in the review will say the first sentence when they give their opinions, we can see that the Sichuan Design Institute has made a lot of effort in the group's work on this project.

In addition, this content corresponds to the development performance in the measurable performance management model, the basic data of performance computing in the corresponding configuration library can be obtained from this method.

Other questions are there any one-to-one correspondence between the revision instructions in the document and the comments in the configuration library?

A:

No one-to-one correspondence is required. However, all comments in the configuration library should appear in the revision instructions of the document, that is, the number of versions in the configuration library should be less than or far less than the actual number of revisions to the document.

This is because the document extracted from the configuration library may be submitted only after half a day for revision to form a comment content. In addition, technical personnel may also take the documents home or discuss with the customer about revisions to non-development sites. At this time, the number of revisions to the documents will increase, A revision description should be added for each addition, instead of a revision description generated only when it is submitted to the configuration library.

If the number of the two items is the same, there must be something tricky here. You should doubt the authenticity of the document content and the revision content.

Some people may ask, How do I perform the code or other operations?

A:

For code and UML
During the Model Revision process, we can also form a version number on the code, because code development rarely leaves the work site, so, we can associate each revision with the configuration library and fill in the corresponding comment content.

In addition, the revision content of the code and model files can be very specific. Generally, a single task can be described as follows:

First, when checking out, the content of this task should be included in the comment;

Second, in the submission of incomplete tasks, the revised content for this submission should be stated in the comment, and the unfinished task should be indicated;

Finally, the submission after completion should indicate in the comment that all the content of the revision of this task has been completed, or that the content is not considered for the time being due to any changes.

In this way, the code configuration management is basically complete.

1.1.3 conclusion

Configuration management tools are one of the core tools for software engineering activities. They are important to everyone who has participated in actual project development. However, most technical staff are confused about how to make good use of configuration management tools. The recommended method in this section does not waste a lot of time. After all, you can complete such a text in a few seconds at the end of each working time, and more is copying and pasting, it does not increase the workload, but can achieve quite good results.