Software Configuration Management. Part 1. Responsibilities and Configuration Definition

Work products are in any project. This can be marketing documentation, requirements for the final product, source codes, tests, support tools. What will be considered a working product depends on the project. Further, each product changes in time (this is the point of development), and these changes must be taken into account somehow: who, when, what exactly he contributed and why he did it. In other words, consider how the product versions appeared.

Software Configuration Management (SCM) is the management of work product sets and their versions. This process is the scope of SCM.

SCM 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) model, the presence of an established configuration management process is a prerequisite for the organization to receive a CMM / CMMI Level 2 certificate.

SCM’s responsibilities

Software configuration management works at all stages of the project lifecycle. When a working product appears (for example, a source file), it enters the SCM activity field. If the product changes – then SCM must provide the means to control the changes and automatically conduct the control itself, where required. If you want to split the work into a team of developers, or even a few – the project SCM provides the rules and tools to work. When there is something to offer the customer – then SCM determines the rules for the stabilization of development products and their release. Need to roll back to an arbitrary release? Again SCM is in the works. If you need metrics for changes or documented policies – again refer to SCM.

So, first of all, SCM is responsible for identifying the work products, i.e. is responsible for determining what will be controlled in the future. In the next section, you will learn more about this.

The product is marked, then the team starts to work. During the work, it is necessary to periodically stabilize the results obtained, underline the operating time, and also determine the basis on which to base the development. This is also part of the scope of SCM.

In addition, SCM is responsible for what is generally called tracking change requests. Most of this area is known as an error tracking system. After all, no changes should be made spontaneously – each of them must be registered and then assigned and tracked correctly – right up to getting into the final product. Here again the last remains SCM. We make changes to products, we need to track them – version control starts to work. Nothing will be lost – SCM is on guard.

Means of monitoring changes and providing versioning create the conditions for parallel development in large teams. This is achieved due to the fact that, by describing 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, as always, “you can not control what can not be measured” – (c) De Marco. About metrics will be told a couple of words too. Where there are dimensions, there will be formalization. In other words, anything related to SCM would be good to document. This will also be mentioned briefly.

So, the software configuration management tasks are:

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

We’ll begin with the basics: how are products and configurations that we will manage to be defined?

Definition of configurations

Work products and configurations

What will be the working products of the project? It is clear that the product will be exactly one for marketing and management – for which the company will receive money. Well, or a few.

We are interested in the “lower level” – what will the task managers, developers, testers and in general each participant in the project operate on. The task of SCM is to define the set of those elements that will be created and changed by the command. At this stage, the notion of a “configuration item” appears – it’s an atomic element that is most conveniently managed within the design. In the future we will call it “CI”.

It includes objects such as:

  • work documents;
  • source files;
  • resource files;
  • files created as a result of the assembly (executable files, libraries, and so on);
  • tools used for development (we also need to consider them for standardization and simplification of teamwork);

Is it possible that CI is any file within the project? No, we are only interested in the files that are necessary and sufficient to create the final product for the customer. Therefore, we do not need the service and intermediate files generated by the compilers, interpreters and IDE. We are also unlikely to be interested in blog posts and forums, project correspondence and other communication products. Of course, the project document for SCM will describe the means of communication within the team – but no more.

Objects that are affected by SCM include any objects supplied externally (installers, marketing materials, etc.). Although they can be obtained from the working products listed above, the end product that is given out to the user also needs identification.

Component development and product lines

How are these configuration elements organized within the project?

They are stacked together according to the architecture of the application itself. After all, developers tend to reduce the complexity of the produced systems. For this purpose, they decompose the created into interconnected parts: classes, components, libraries, subsystems, and so on. We simplify the terminology and in the future, any components of the systems being created will be called components. SCM also takes this organization as the basis and structures the work products appropriately with the help of its tools and policies. Components become new configuration items.

At the same time, the components become independent working units, which are also subject to unified control. In addition, they can even set up their own development process. In this case, SCM practices are necessary in order to control these individual units on their own, receive intermediate versions, stabilize and release them for integration into a product of a higher level.

So, we create a system, we build it out of building blocks. It is not uncommon for a system to be delivered in several versions at once. And often all the difference between different versions / editions of products only in one or several components, or even in the settings. How to be? To do this, we create what we will call product lines for the sake of simplicity of the further presentation. The product line is a branch in the history of product development, which makes it possible to change part of the components independently of other similar branches (here the concept of “product” is used from the marketing point of view).

All according to the theory of evolution – the unicellular one remains unicellular, but as a result of mutations and a chain of accidents (or by malice) gives life to multicellular. There was a ruler of anthropoid primates – the homo sapiens line broke off from it, but the initial breed of monkeys continued to live its own life. “Components” for each “line” almost 99% coincide. And only a few percent (brains and something else in detail) are developed by evolution independently of the parent line and distinguish some species from others.

Scheme 1. The ratio of components, supercomponent and product.

Scheme 1 depicts the component composition of the product. 1-8 are components, 4 is a “supercomponent”, which includes components 5 and 6. As part of product integration, work with it is carried out as with a normal component.

 

Scheme 2. The ratio of components and products when using product rulers.

Scheme 2 shows how the same components can be used when working with product lines. For example, there is a Product 1, consisting of several components and a supercomponent. On its basis, products 2 and 3 are produced.

Product 2 includes all the same components, except for 1 and 6 – they are excluded from the work (or by ignoring the corresponding directories, or by turning off the compilation directives). In addition, component 3 changes – it becomes 3′. Also, a new component is added to the only supercomponent, number 9.

Product 3 also takes as the basis the code base of Product 1, but also takes on the changes from Product 2 – components 9 and 3′. Also changes are made to components 7 and 8, which are now called 7’and 8′, respectively.

What in the end? As a result, we have several components that can be integrated into two or three different products simultaneously. Take, for example, number 2 – it is unchanged in all three products. The inference is that it should be released once and simply “inserted” wherever it is required. So it happens – the component team in the person of the SCM-engineer stabilizes the work and transfers for further integration to the three “product” teams. Similarly, the SCM command of the component 3′ – after making changes on top of the “ancestor” 3, the received release of component 3′ is given to two products.

And the use of one component in different products is not copying the sources from the directories of one product to another. No, the point is that the released configuration of the component was in the version control system and all interested just turned to it as it was included in its code.

In general, in the technical plane, SCM is the link between components and rulers. In the management plane, where architectural decisions are made, managers, team leaders, architects rule, and all technical support for this division is assigned to SCM engineers. It is they who give the final developers instructions (“policies”) about which control systems to add their code, how to put it there, how to register changes in bug-tracking systems, what is the order of uniting components, what to give testers and how to produce the product to the customer. The products themselves become new configuration elements.

The main conclusion of this part: SCM helps to determine which of the bricks we will build the product and give a solution for their binding. The methods of definition and binding we will consider in the second part of this topic.

Leave a Reply

Your email address will not be published. Required fields are marked *