Software Configuration Management // Metrics and Documentation

Hello again.
Continuing a series of notes about SCM . Last time, the topic of using version control systems was raised . Judging by the advantages received from the contingent, the topic remains relevant for many. There is an intention to continue the story about version control, to consider centralized and distributed control systems. But before that I step aside a little and talk a little about the formal aspects of configuration management in order to cover general theoretical topics (and move on to holivars, hyhe).

So - about formalization. The other day I conducted a survey to find out what metrics people use in their projects. It turned out scary. Of those who generally decided to choose something (i.e., without abstaining), halfnot only does not collect metrics, but also does not. Presumably, documenting processes is even worse.

Therefore, I am addressing today's note to those who think a little about where his project is going and how efficiently the team works.

Metrics collection

What is important for the manager when the whole picture of what is happening in the project should unfold before his eyes? Of course, these are numbers. To control the situation, the leader must see not only what is currently available, but also what was previously. Accordingly, it is only by having integrity and denie, one can predict the future of the project, adjust the timing - just live a normal management activities.

What does CM have to do with it? Despite the fact that he controls the changes. If we consider that any project is a change in work products, then through CM all changes of the entire project pass . Therefore, it is precisely the software configuration management tools that can give managers a vision of how a project changes over time. Usually such a vision is expressed as numbers.

What numerical indicators ( metrics ) can be obtained from what passes daily through the hands of CM-engineers?
First of all, this is all about accounting for product change requests:

• total number of open / closed / in-service requests;
• slices of requests for each participant - what exactly is everyone puzzled with, and in what state of work;
• the time spent by requests in different states - both average and for each request.

Any project manager begins with this - he looks at who is busy with what. Who works, and who blows pears with a bolt.

Further, general information about the code is always interesting, such as: the number of lines of product code and components. Usually they are counted in CLOC, NCLOC. Interested in everything regarding the changes:

• delta sizes (LOC) in each release;
• delta sizes for individual change requests (if the toolkit allows).

More exotic query options are possible, depending on the capabilities of the tools and the needs of the project:

• cyclomatic complexity;
• occupied memory size (RAM, ROM);
• changes in the occupied memory in time.

The last couple of metrics are, as a rule, of interest to those teams that work with systems that have resource limits. For example, I happened to see this in Motorola Mobile Devices Software. The amount of memory is always critical for cell phones, especially when it comes to new chipsets and architectures. And SM just allows you to collect these data at the stage of preparation of resizov.

By the way, reports on the work done by the CM engineers themselves may also be interesting:

• how many integration requests have been processed;
• how many releases made;
• what is the average time taken to release.

Of course, all the data is issued not only in the form of text reports, but also in the form of a variety of diagrams - fortunately, there were many types of them. In addition, for many indicators, one can track the evolution of values ​​over time.

Total: collecting metrics is an integral part of CM in large projects. For small projects, collecting metrics is simplified, or even reduced to nothing. However, the more the project management knows about what is happening at the lower levels (in the code), the more effectively you can build everyday work.

CM Activity Documentation

All policies, procedures and rules that are established by the CM-engineer of the project must be communicated to all project participants. The form of providing this information is not very important - the main thing is that it should be provided on time and be constantly available to everyone. As a rule, everything that is described and formalized in CM is usually combined with the term “ project configuration management plan ”. English sources use the abbreviation SCMP - Software Configuration Management Plan .

This plan describes everything with which the project configuration management operates. This includes the following information:

• Description of all elements of the project configuration: what types, where they lie, who uses and who changes.
• Tools used on the project. Describes the purpose and provides links for download and installation.
• The system for tracking change requests is described separately: request life cycles, user groups, their rights, and usage rules. The composition of the groups is usually determined in the systems themselves and there is no need to list it in the document.
• The procedure for working with the version control system is described. What tools to use, where are the instructions for installing the client part, which user groups. Separately describes the naming formats of branches and labels, this is one of the most important parts from the point of view of a simple developer.
• Repositories for releases and other elements that are not subject to the version control system are determined, and the procedure for working with them is described.
• The description of the processes of stabilization of the configuration and release of basic releases is given - by whom it is initiated, what procedures are applied, where it lies and who is responsible for the release. This also includes a description of the collection of metrics.
• If several components or product lines are developed within the project, then procedures specific to their CM activities are described.

SCMP can be executed both as a separate document and as a series of publications in the used workflow system of the development team - for example, in the Wiki. The main thing is that the information is complete, timely and accessible to the end user.

Instead of a conclusion

The formal aspects of SCM, metrics and documentation, were discussed above. I hope this will give someone reason to think and, possibly, make some kind of movement in the right direction.

The information given is taken from 1) life and personal experience 2) standard SEI CMM / CMMI

Ask questions.

Well, about SCM as a whole - to be continued.