Blog

All articles

Software Configuration Management. Part 4. Change Requests Monitoring

Software Configuration Management. Part 4. Change Requests Monitoring

In this part we will talk about how to monitor changes in configurations and what tools are used for this. In addition, it will be shown how SCM practices determine the order of tracking changes when working in a team. Also, we will not ignore some formal things, such as collecting metrics and documenting SCM activities.

So, earlier we found out that the task of configuration management is determining what will change in the project, and how we will track the change. Let us consider the second problem.

Change Requests Monitoring

For starters, how does the change in the project work? There are several options:

  • creates a new product functionality;
  • functionality or internal structure is changed during planned modifications (for example, refactoring);
  • corrected errors found.

The first two species are sometimes combined, despite the fact that this is different in meaning. Of course, sometimes it is necessary to refactor to fix the error, or writing functionality eliminates some problems. But in these cases, it all comes down to what process of work on changes and what terminology is adopted within the project.

Any component of the project can change – it can be both source codes, and requirements, tests – in general, all that is listed earlier. It is important that this changes everything and it is necessary to control the changes made.

Depending on the type and product of the change, the source of its request also differs. In the case of new functionality, it will most likely be one of the managers or the end user. When refactoring – the technical manager or developer of the project. When correcting an error – any user of the system, but, as a rule, this is a tester.

So, there is a need for change, and there is one who will voice this need. It remains to start moving. The beginning of the movement is the submission of a change request. A change request is a product improvement proposal, expressed as a record in the change request tracking system.

There is also the term problem or change request (PCR). In the future we will use the abbreviation CR. In turn, the system for tracking change requests is a software environment that allows accounting of proposals for product changes and management of responsibility for them. Keywords in the entire chain of terms: query, change, and liability tracking. In Russian-language sources, the term “error tracking system” is often used. In the English-language literature there are change request management system, bugtracking system, issue tracking system.

Typically, a repository in such systems is a database, where one CR is one record (more often – a linked set of records) in it. CR after the creation has the following mandatory information:

  • who started the entry (submitter);
  • short title of the entry;
  • used version of the system being changed;
  • a detailed description of the query or problem.

Also, useful information can be added (it can be declared as mandatory, depending on the development process):

  • description of the system expected behavior (for errors);
  • software and hardware configuration;
  • fragments of the log of the system (“logs”).

Further, the whole life cycle of a record is a sequential appointment of a person in charge at various stages of the work and adding information necessary to solve the problem. Typically, the device tracking systems can be reduced to two types:

  • a finite state machine, or machine state, where each state is characterized by its own set of fields;
  • a record in which the content of existing fields is changed along the way and to which comments are added.

Systems of the second type are found more often than the first one. Their greatest difference is in the internal arrangement. The external difference is only expressed by whether it is possible to add new structured information as the work progresses over the CR. But, regardless of the type of system, the work on the records is generally the same. After all, the main thing is the organization of the development process, and the tools are a consequence of its choice and optimization.

Let’s look at the typical scenario. The recording is started, you need to start working. However, no changes should be made uncontrollably. Therefore, before starting work, you need to obtain management approval, which is responsible for the functionality affected by the change request. The role of management is performed by the Configuration Control Board (a configuration control group), a group that has project management rights under the project. Also sometimes used is the term Change Control Board and the abbreviation CCB.

For further work, let’s take the tracking system in the form of a state machine – this will be more obvious. The set of states in Scheme 1 is the minimum required, it can be extended and split into several life-cycle templates. We will take this collection for further description.

Software Configuration Management. Part 4. Change Requests Monitoring

The first state that any record falls into is the initial state. In the diagram it is represented as the “New” element. At this point, the writer creates all the initial data required by the design development process. Next CR falls into the field of view of the configuration control group. It decides which of the developers to give the problem for the solution.

In order to give CR to work, the record must be translated to the next state – Assigned (“assigned to the responsible”). Simultaneously, the record is “assigned” to the developer – i.e. he becomes responsible for it.

However, assigning a task to someone else does not mean that the task will immediately be decided. For one developer, after all, several tasks can be assigned – one is very important and everything must be done yesterday. Therefore, when the developer actually begins to deal with the task – he translates the record into the Opened state (“work is started”). CCB, tracking work, sees that the task is taken in turn. The task itself, as a rule, remains “attributed” to the developer.

During the course of the work, the responsible may change, depending on who owns the code that affects the behavior described in the CR. Reassignment does CCB. In addition, it may turn out that the problem has already been found by someone and its CR was established on it. In this case, the problem is duplicated, i.e. closes, and in the corresponding field the number of the entry that was entered earlier is added. From this point on, the record is considered closed. It can also be found out that the described problem is not an error in the work (ie, it is WAD, works as designed) or the requested functionality can not be realized for various reasons. In this case, the record is terminated, i.e. closes with comments about why the work on the problem will not continue.

If, however, the work continues, then sooner or later it ends: the developer has made the necessary changes and is ready to give them for further integration. At this point, it puts the record in the Resolved state (“fixed” or “solution found”). By this step, the engineer assigned to the decision, disclaims responsibility and shows those changes that, in his opinion, should solve the problem. In this state, the CCB must again appoint a responsible person. He will check that the task set in CR is really solved correctly and everything works as a minimum, no worse than it was before it was solved. Therefore, at this stage, the responsible is assigned to either one of the testers, or the author of the record. After the appointment, the verifier, which is often the author of the request, starts the test. The result is the following:

  • transfer to the initial state, if the problem is not solved;
  • the conversion to the Closed state if the bug is fixed or the new functionality described in the request is working.

After that, the changes are integrated into the main product code. This is the responsibility of the SCM project engineer and a separate record is created on the system.

By the way, it’s worth adding that tracking systems for change requests are also used as a system for assigning and tracking project tasks. After all, any such task requires monitoring by management. And the result of most tasks is, again, some changes. Therefore, it is logical for all purposes to use one system. If the proposed life cycle is not suitable for some reason, most of the tracking systems allow this cycle to modify and create several kinds of life cycles – as much as it takes to solve everyday tasks. This is often why some types of templates are created to track the development of new functionality, while others are used to track the process of fixing errors. And because the development of new capabilities requires the development of requirements, design, tests, and also for the convenience of work, intermediate states or fields for these purposes are introduced.

The implementation of systems to track requests for changes is almost the most favorite job of programmers around the world. Someone thinks that his system will surely eclipse everything that is available. Someone is sure that in the others something is missing from what he needs. And someone just does it for their own pleasure. To each his own.

We have learned how to track change requests. And further on SCM-engineers of the project there is a responsibility for:

  • the implementation of tracking systems in the development process;
  • the development of policies for the use of these systems;
  • tracking compliance with established rules.
  • More details about the use of query tracking systems, as well as their overlap with version control systems, will be discussed in the corresponding part.

Tracking systems have been implemented, the rules for tracking change requests have been described. It’s time to learn how to track changes as such and to integrate them. For this, there is control over the version of the configuration items.