Software Configuration Management Fundamentals Series

Prologue

What is configuration management in software development? Why is it needed? I think few are able to fully and clearly answer this question. Most usually recall version control systems that they themselves use. Someone mentions bug tracking. Someone thinks that CM growth is the peak of growing branches in your favorite version control system. And someone generally goes aside and starts talking about ITIL and how he writes to some database the parameters of all the software that is installed in his company.

It is somewhat strange and a little annoying to watch this. The fact is that I worked in SCM for a total of about 5 years, of which 3 years - as an integrator in Motorola, on one of the projects for developing software for cell phones. Along the way, I read a bunch of materials on this topic and gained extensive practical experience - including working with one of the most powerful version control systems of IBM Rational ClearCase (see linkedin in the profile). As a result, a certain integral picture of what it really is - software configuration management was formed in my head.

And then I saw an article from comrade alternin which he began to talk about SM. His speech went in a slightly different vein - about specific tools and naming configurations. Therefore, having written off with him, so as not to overlap with the topics of our articles, I decided to write about the basics of what is called software configuration management.

Now I have already written material for about 50 thousand characters - these are approximately 5-7 average posts for Habr. And the writing process continues. I am going to post what I have written with a small frequency here and, as questions and discussions are exhausted, post new notes.

The task is to give an overview of what CM is in general, what tasks it solves and what techniques are used. We will not talk about specific version control systems or tools in general - this stuff in bulk on the network. The task is to show the basics universal for all tools.

So let's go.

What is CM and why is it needed

Configuration management

First, let's determine what configuration is , because this word is displayed in the header. Configuration is a collection of work product versions. The keywords are “product versions”.

There are work products in any project - this can be marketing documentation, requirements for the final product, source codes, tests, auxiliary tools. What is considered a work product depends on the project (the definition will be given in the next note). Further, each product changes over time (this is the meaning of development), and these changes must somehow be taken into account - who, when, what exactly made it and why he did it. In other words, consider how product versions appeared.

Version- this is the state of the work product, which can be restored at any time regardless of the change history.

Accordingly, configuration management is the management of work product suites and their versions. This process is the scope of CM.

English literature uses the term Software Configuration Management , abbreviated SCM . Further, for simplicity of presentation, the term configuration management and the abbreviation CM will be used (read: "siem").


Scheme 1. Elements, their versions and sections-configurations.

CM is one of the basic practices of any software development methodology. Suffice it to say that in the SEI CMM / CMMI (Capability Maturity Model Integration), the presence of an established configuration management process is a prerequisite for the organization to receive a CMM / CMMI Level 2 certificate.

I note that Level 2 is the most minimal, initial level of maturity, according to the model CMM Level 1 gets an “automatic” organization that has successfully completed at least one development project. Therefore, the presence of CM is the minimum requirement for certification. By the way, at the second level it is necessary to have, among other things, an established process of testing and requirements management. This suggests that, from the perspective of the CMMI standard, proper configuration management is just as important as competent testing and requirements management.

So what is the value of CM?

Responsibilities CM

Configuration management works at all stages of the project life cycle. A working product has appeared (for example, a file with source codes) - it falls into the field of CM's activity. The product began to change (we are writing functionality) - which means CM should provide the means to control the changes and automatically carry out the control itself, where it is required. It was necessary to break the work into a team of developers, or even into several - the project CM provides rules and tools for work. There is something to offer the customer - then CM determines the rules for stabilizing development products and their release. We need to roll back to an arbitrary release - again in the work of CM. It took metrics for change or documented policies - well, you understand who to turn to.

So, first of all, CM is responsible for the identification of work products, i.e. responsible for determining what will be further controlled. The next article will tell you more about this.

Products highlighted, then the team starts work. In the course of work, it is necessary to periodically stabilize the results obtained, draw a certain line under the developments, and also determine the basis on which the development will be based. All this is also included in the scope of CM'a.

In addition, the CM is responsible for what is generally called tracking change requests. Most of this area is known as bug tracking systems. After all, no changes should take place spontaneously - each of them needs to be registered and then assigned and monitored in the right way - right up to getting into the final product. Here again remains the extreme CM. We make changes to the products, we need to track them - version control starts to work. Nothing will be lost - CM is on guard.

Change control and versioning tools create the conditions for parallelizing development in large teams. This is achieved due to the fact that, having described these tools, we give developers documented procedures that allow us to share responsibility and limit the areas of activity of each of the developers.

Well, and, as always, “one cannot control what cannot be measured” - (c) De Marco. Metrics - a few words will be said about them too. Where there are measurements, there is formalization. In other words, everything related to CM would be nice to document. This will also be briefly mentioned.

So what are the tasks of configuration management?

It:

• identification of work products;
• stabilization of work results and determination of the basis for further work;
• tracking change requests;
• version control;
• ensuring concurrency of development;
• collection of metrics and formalization of applied methods.

Whoever is interested in reading a little more theory and imbued with terms and formal descriptions of the area of ​​responsibility - you should go to CMM / CMMI standards (see links at the end), there it is considered a lot and fruitfully. True, it is not always clear and almost always dry and boring.

Enough for a start. The next part will be devoted to how the products and configurations that we will manage are defined. I will also touch on the issue of component development, product lines and their relationship with SM.

Links for broadening horizons:

1. en.wikipedia.org/wiki/Software_configuration_management Software Configuration Management on Wikipedia.
2. www2.computer.org/portal/web/swebok Software Engineering Book of Knowledge.
3. www.sei.cmu.edu/cmmi SEI CMMI Website.
4. www.cmcrossroads.com CM Crossroads the Configuration Management Community.

To be continued.

UPD : at the request of workers, link to the second part: habrahabr.ru/blogs/pm/67839