Efficient Configuration Management Plan

According to IEEE 828 and CMM/cmme, A Configuration Management Plan is often considered a document. Indeed, for a large project, it is often necessary to develop a configuration management plan of the project.
But not all organizations are software outsourcing organizations, and not every project targets different customers.
In an efficient software development organization that does not outsource software, the recommended configuration management plan should have three layers.
The first is at the organizational level. Generally, it provides unified Configuration Management Services and does not allow each team to build their own Configuration Management Servers. Therefore, the organization-level Configuration Management Service should be agreed on, including:
How to create a project document directory?
How to create a product-level directory?
How to Create a code directory?
How to name configuration items?
How does one configure database backup and recovery? Who will do it?
What is the pull-down branch? Under what circumstances will it be merged into the trunk? The branch trunk should be provided in multiple modes, or the product line or project group should be selected.
How to make changes? Generally, definitions and releases should be made at the organizational level. At the project level, the change process is too laborious. Of course, some large projects have sufficient budgets and special circumstances that require special definition of project-level changes.
How to carry out configuration audit on product lines and projects?
What are the recommended configuration management practices?
The update frequency of organization-level configuration management procedures or guidelines is about once a year.
The second is the product line layer. There are already a large number of source code and documentation for a specific product line. What are the conventions of this product line in terms of configuration management and storage?
For example, you can describe code configuration items and non-configuration items. Do not assume that every new team member is a code Configuration Manager. Be careful when you are a self-righteous newbie and add some self-righteous spam. Although it can be deleted, it is a cost to delete it.
For example, which dependencies are worth storing?
For example, which regions are confidential and the permissions are managed separately?
For example, if the code is the core code, senior personnel should review the changes.
What are the trunk and branch strategies of this product line? Daemon trunk? Or pioneer trunk? No branch? Or a single branch? Or multiple branches?
For example, to agree on a uniform working environment of the team: install Java in C:/Java, and install eclipse in D:/eclipse.
At the project level. After the above organization-level and product-level Configuration Management Conventions are met, the most important thing in the project-level Configuration Management Plan is to clarify the personnel, baseline, and special project configuration items. The baseline arrangement must match the project's lifecycle selection. Most importantly, it must match the milestone.
In such a three-tier structure, it is efficient for the project. You do not need to write the Configuration Management Plan of the project separately. You only need to write the project-level configuration management conventions into the project plan, generally, the length cannot exceed 1 page.
Link: http://www.51testing.com/html/89/n-866189.html

Efficient Configuration Management Plan