Software Configuration Management // tracking change requests

Instead of the preface

And again, good day!

I continue the cycle of notes on the basics of software configuration management. In order not to retell a brief summary of the previous two series for a long time, I offer links to them:

1. Cycle of articles on the basics of Software Configuration Management . CM is an engineer what is SM, what are his tasks and what is the responsibility of the project within the framework of the project.
2. Software Configuration Management // Configurations and baselines . About what a work product is in terms of SCM, what a configuration is, how it stabilizes, as well as what basic configurations are - baselines.

This post discusses what most people call bugtracking systems. We will look at this class of tasks and tools from a more generalized point of view.

Tracking change requests

For a start, how do changes occur on a project? There are only a few options:

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

The first two species are sometimes combined. However, most often it is separated from each other - simply because these are really different things. Of course, it happens that to correct an error, you need to do refactoring, or writing functionality eliminates some problems. But in these cases, it all comes down to what process of working on the changes, and what terminology is adopted within the project.
')
Any work product can change - it can be both source codes and requirements, tests - in general, everything that was listed in previous materials. It is important that this all changes and it is necessary to control the changes made.

Depending on the type and product of the change, the source of its request varies. In the case of new functionality, this will most likely be one of the managers or the end user. When refactoring - technical manager or project developer. 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 voices this need. It remains to start moving. The start of the move is to submit a change request. A change request is a proposal to improve a product, expressed as a record in the change request tracking system. In English sources, such requests are called change request (CR) . The term problem or change request (PCR) is also used . In the future we will use the abbreviation CR (read "Ciar").

In turn, the change request tracking system is a software environment that allows for the recording of product change proposals and the management of responsibility for them. The keywords in the entire chain of terms are query, change, and responsibility tracking . In Russian-language sources, the term “error tracking system” is often used. In the English literature there are change request management system, bugtracking system, issue tracking system .

As a rule, the database in such systems is the database, where one CR is one record (more often - a linked set of records) in it. CR after institution has the following mandatory information:

• who made the post;
• short title of the entry (subject);
• used version of the variable system;
• A detailed description of the request or problem.

It can also be added just useful information (it can be declared as mandatory, depending on the adopted development process):

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

Further, the entire life cycle of a recording is the consecutive assignment of the person responsible at different stages of work and the addition of information necessary for solving the problem. As a rule, the tracking system can be reduced to two models:

• finite state machine (finite state-machine, or state machine), where each state is characterized by its own set of fields;
• a record in which the contents of the available fields change to the course of work and to which comments are added.

The second is much more than the first. The greatest difference is in the internal structure. Externally, it is expressed only by whether it is possible to add new structured information in the course of work on CR. But, regardless of the type of system, work on the records is generally the same way. After all, the main thing is the organization of the development process, and the tools are a consequence of its selection and optimization.

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

Simple script

For further work, we will 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 expanded to a larger size and is divided into several life cycle templates. This set will take for further description.


Scheme 1. The life cycle of a change request

The first state in which any entry falls is the initial one. On the attached chart, this is New . At this stage, the creator of the record contributes all the initial data required by the design development process. CR then comes into view CCB. It decides which developer to give the problem to solve.

In order to give CR to work, the record is transferred to the next state - Assigned ("assigned to the responsible"). At the same time, the entry is "assigned" to the developer - i.e. he becomes responsible for her.

However, assigning a task to someone does not mean that the task will immediately begin to be solved. After all, several tasks can be assigned to one developer - one is more important than the other and everything must be done yesterday. Therefore, when the developer actually begins to deal with the task - he puts the record in the Opened state (“work started”). The CCB, which tracks the work, sees the task taken into circulation. The task itself, as a rule, remains “assigned” to the developer.

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

If all the same work continues, then sooner or later it ends - the developer has made the necessary changes and is ready to give them to further integration. At this point, it puts the record in the Resolved state (“fixed” or “solution found”). By this step, the person appointed for the decision declines the responsibility and shows those changes which, in his opinion, should solve the problem. In this state, the CCB must again assign the person in charge. He will check that the task set in CR is really solved correctly and everything works at least as good as it was before it was solved. Therefore, at this stage either one of the testers or the author of the recording is appointed as responsible. After the assignment, the verifier ( “verifier” , “verifier”), who is often the author of the request, starts the verification. The result is 2 outcomes:

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

After that, the changes are integrated into the main product code. The CM-engineer of the project is already responsible for this and a separate entry is made to it in the system.

On implementation and fine tuning

By the way, it is worth adding that change request tracking systems are also used as a system for assigning and tracking tasks on a project. After all, any task arising on the project requires monitoring by the management. And the result of most tasks is, again, some changes. Therefore, it is logical for all purposes to use one system. Sometimes task tracking systems are also called the common term help desk . However, the meaning of this does not change - I also attribute them to the tracking systems for change requests.

If the proposed life cycle is not suitable for some reason, most tracking systems allow you to modify this cycle and create several types of it - as much as you need to solve everyday tasks. By the way, that is why often create separate templates to track the development of new functionality and to track the process of correcting errors. Just because when developing new features, it is also necessary to develop requirements, design, tests - and for this, intermediate states or fields are introduced for the listed purposes.

My opinion is that you need to choose systems that allow you to flexibly define a work cycle. At least to ensure that the scheme of work that was once laid by someone unknown did not become a dogma for your project. Over time, it is difficult to go beyond its limits due to the limitations of the toolkit and the project begins to become “cramped”. So flexible customization is our choice!

Implementing systems for tracking change requests is perhaps the most favorite activity of programmers around the world. Someone thinks that his system will certainly overshadow all the available ones. Someone is sure that in the rest something is missing from what he needs. And someone just does it for their own pleasure. To each his own. If someone does not want to reinvent his two-wheeled vehicle, he can familiarize himself with the existing bike park . Well, pick up a bike that is best suited for its task. By the way, the author had a chance to take some part in the development of the eTraxis mentioned in the above list. I will recommend him taking this opportunity.

But what about CM-engineers?

Change requests track learned. What is the role of CM project engineers? They are responsible for:

• implementation of tracking systems in the development process;
• developing policies for the use of these systems;
• tracking the implementation of established rules.

A lot of copies breaks over the first task - there are a lot of systems, and it is necessary to choose the optimal one. I have a couple of tips for this case, the relevant material is even written ... but it will be published a little later, stay tuned :)

Links to expand horizons

1. http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems - a comparison of accounting systems for change requests.
2. http://www.etraxis.org/ is a query tracking system, in the creation of which the author took an active part.
3. See also links in previous articles, links to them are present at the beginning of the note.

In the next part, we will discuss the most important manifestation of the SCM practices - version control. By the way, there will again be affected tracking changes requests - without it anywhere.

So, to be continued.