Software Configuration Management // Metrics and Documentation
Hello again.
Continuing a series of notes on SCM . Last time, the topic of using version control systems was raised. Judging by the pluses 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’ll step aside and talk a little about the formal aspects of configuration management, in order to close general theoretical topics (and go to the holivars, hyhy).
So - on the formalization. The other day I conducted a survey in order to find out what kind of metrics people use in their projects. It turned out terrible. Of those who decided to choose something at all (i.e., without abstentions), half of them do not just collect metrics, but do not assemble either. Presumably, documenting processes is still worse.
Therefore, I am addressing today's note to those who think a little about where his project is going and how effectively the team is working.
')
What is important for a manager when the whole picture of what is happening in a project should unfold before his eyes? Of course, these are numbers. To control the situation, the manager must see not only what is currently available, but also what was previously present. Accordingly, only with this holistic vision can one predict the future of the project, adjust the time frame - in general, conduct normal management activities.
What does CM have to do with it? With that, he controls change. If we consider that any project is a change in work products, then all changes of the entire project pass through CM. Therefore, it is software configuration management tools that can give managers a vision of how a project changes over time. Usually such a vision is expressed in the form of numbers.
What are the numerical indicators ( metrics ) that can be obtained from what passes daily through the hands of CM-engineers?
First of all, this is all that concerns the consideration of requests for product changes:
Further, the general information about the code is always interesting, such as: the number of lines of product code and components. They are usually counted in CLOC, NCLOC. Interested in everything related to the changes:
By the way, there may also be interesting reports on the work done by the CM engineers themselves:
Of course, all the data is given out not only in the form of text reports, but also in the form of a variety of diagrams - the good, they have come up with many types. In addition, in many respects it is possible to track the development of values over time.
Total: collecting metrics is an integral part of CM in large projects. For small projects, the collection of metrics is simplified, or even generally reduced to nothing. However, the more the project management is aware of what is happening at the lower levels (in the code), the more effectively you can build daily work.
All policies, procedures and rules that the CM-engineer of the project establishes should 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 at all 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 Management Plan .
This plan describes everything that the project configuration management operates on. This includes the following information:
SCMP can be issued both as a separate document and as a series of publications in the workflow system used by the development team - for example, in the Wiki. The main thing is that the information is complete, timely and accessible to the end user.
Above, we considered the formal aspects of SCM - metrics and documentation. I hope this will give some reason to think and, perhaps, make some moves in the right direction.
The given info is taken from 1) life and personal experience 2) standard SEI CMM / CMMI
Ask questions.
Well, about SCM as a whole - to be continued.
Continuing a series of notes on SCM . Last time, the topic of using version control systems was raised. Judging by the pluses 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’ll step aside and talk a little about the formal aspects of configuration management, in order to close general theoretical topics (and go to the holivars, hyhy).
So - on the formalization. The other day I conducted a survey in order to find out what kind of metrics people use in their projects. It turned out terrible. Of those who decided to choose something at all (i.e., without abstentions), half of them do not just collect metrics, but do not assemble either. Presumably, documenting processes is still worse.
Therefore, I am addressing today's note to those who think a little about where his project is going and how effectively the team is working.
')
Metrics collection
What is important for a manager when the whole picture of what is happening in a project should unfold before his eyes? Of course, these are numbers. To control the situation, the manager must see not only what is currently available, but also what was previously present. Accordingly, only with this holistic vision can one predict the future of the project, adjust the time frame - in general, conduct normal management activities.
What does CM have to do with it? With that, he controls change. If we consider that any project is a change in work products, then all changes of the entire project pass through CM. Therefore, it is software configuration management tools that can give managers a vision of how a project changes over time. Usually such a vision is expressed in the form of numbers.
What are the numerical indicators ( metrics ) that can be obtained from what passes daily through the hands of CM-engineers?
First of all, this is all that concerns the consideration of requests for product changes:
- total number of open / closed / pending requests;
- cuts of requests for each participant - exactly what each of them is puzzled about, and in what condition the work;
- time spent for queries in different states - both average and for each query.
Further, the general information about the code is always interesting, such as: the number of lines of product code and components. They are usually counted in CLOC, NCLOC. Interested in everything related to the changes:
- delta sizes (LOC) in each release;
- delta sizes for individual change requests (if the toolkit allows).
- cyclomatic complexity;
- occupied memory size (RAM, ROM);
- changes in occupied memory over time.
By the way, there may also be interesting reports on the work done by the CM engineers themselves:
- how many integration requests have been processed;
- how many releases made;
- what is the average time spent on release.
Of course, all the data is given out not only in the form of text reports, but also in the form of a variety of diagrams - the good, they have come up with many types. In addition, in many respects it is possible to track the development of values over time.
Total: collecting metrics is an integral part of CM in large projects. For small projects, the collection of metrics is simplified, or even generally reduced to nothing. However, the more the project management is aware of what is happening at the lower levels (in the code), the more effectively you can build daily work.
Documenting CM activities
All policies, procedures and rules that the CM-engineer of the project establishes should 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 at all 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 Management Plan .
This plan describes everything that the project configuration management operates on. This includes the following information:
- Description of all project configuration elements: which views, where they are located, who uses and who changes.
- Tools used on the project. Describes the purpose and provides links for download and installation.
- Separately, a system for tracking change requests is described: the life cycles of requests, groups of users, their rights, and rules of use. The composition of the groups is usually determined in the systems themselves and there is no need to list them in the document.
- Describes how to work with the version control system. What tools to use, where the instructions for installing the client part, which user groups. The formats for naming branches and tags are described separately; this is one of the most important parts from the point of view of a simple developer.
- Stores are defined for releases and other elements that are not subject to the version control system, and describes how to work with them.
- A description of the processes of stabilization of the configuration and the release of basic releases is given - who initiates, what procedures are applied, where it is and who is responsible for the release. This also includes a description of the collection of metrics.
- If a project develops several components or product lines, then procedures specific to their CM activities are described.
SCMP can be issued both as a separate document and as a series of publications in the workflow system used by 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 conclusion
Above, we considered the formal aspects of SCM - metrics and documentation. I hope this will give some reason to think and, perhaps, make some moves in the right direction.
The given info is taken from 1) life and personal experience 2) standard SEI CMM / CMMI
Ask questions.
Well, about SCM as a whole - to be continued.
Source: https://habr.com/ru/post/69666/
All Articles