Software Configuration Management // Change Request Tracking

Instead of the foreword

And again, good day!

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

1. A series of articles on the basics of Software Configuration Management . About what is SM, what are its tasks and what is responsible for the project CM-engineer.
2. Software Configuration Management // Configurations and baselines . What is a working product in terms of SCM, what is a configuration, how is it stabilized, and also what are basic configurations - baselines.

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

Change Request Tracking

To begin with, how do changes occur on a project? There are only a few options:

• new product functionality is created;
• functionality or internal structure changes during planned improvements (for example, refactoring);
• found errors are corrected.

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 in order to fix a bug you need to do refactoring or writing functionality eliminates some problems. But in these cases, it all comes down to what process of work on the changes, and what terminology is adopted in the framework of 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 that changes must be controlled.

Depending on the type and product of the change, the source of its request also varies. In the case of new functionality, it will most likely be one of the managers or the end user. In refactoring, a technical manager or project developer. When fixing the 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 movement is to submit a change request. A change request is a product improvement proposal, expressed as an entry 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 found.. In the future, we will use the abbreviation CR (read "siar").

In turn, the change request tracking system is a software environment that allows you to record proposals for product changes and manage responsibility for them. The keywords in the entire term chain are request, 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 is a repository in such systems, where one CR is one record (more often a related set of records) in it. CR after the institution has the following required information:

• who started the record (submitter);
• Short name of the record (subject);
• used version of the changeable system;
• A detailed description of the request or problem.

Just useful information can also be added (it can be declared mandatory, depending on the accepted development process):

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

Further, the entire recording life cycle is the sequential appointment of a person responsible at different stages of work and adding information necessary to solve the problem. As a rule, the device of tracking systems can be reduced to two models:

• finite state machine (machine of states), where each state is characterized by its own set of fields;
• a record in which, as the work progresses, the contents of the existing fields are changed and to which comments are added.

The second is much more than the first. The biggest difference is in the internal structure. Outwardly, 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 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 uncontrollably. Therefore, before starting work, you need to get 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 manage changes within the project within the project. The term Change Control Board and the abbreviation CCB are also sometimes used .

Simple script

For further work, we take a tracking system in the form of a state machine - this will be more obvious. The set of states in Scheme 1 is the minimum necessary; it can be expanded to a larger size and divided into several life cycle patterns. We take this set for further description.


Scheme 1. The life cycle of the change request

The first state in which any record falls, the initial one. In the attached diagram, this is New . At this point, the record creator contributes all the initial data required by the design development process. Next, CR comes into view of the CCB. It decides which of the developers to give the problem to solve.

In order to give CR to work, the record is transferred to the next state - Assigned("Attributed to the responsible"). At the same time, the record 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 needs to be done yesterday. Therefore, when a developer actually begins to engage in a task, he puts the record in the Opened state (“work started”). The CCB, tracking work, sees that the task is 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, which affects the behavior described in CR. Remapping does CCB. In addition, it may turn out that the problem has already been found by someone and its CR has been started. In this case, the problem is duplicated , i.e. it is closed and in the corresponding field is added the number of the record that was established earlier. From this point on, the record is considered closed. It may also turn out 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, nevertheless, 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, he puts the record in the Resolved state (“fixed” or “solution found”). With this step, the person assigned to the solution relieves responsibility and shows those changes that, in his opinion, should solve the problem. In this state, the CCB must again appoint a person in charge. He will verify that the task set in CR is indeed solved correctly and everything works at least as well as before. Therefore, at this stage either one of the testers or the author of the record is appointed. After the appointment, the verifier ( "verifier", “Verifier”), which is often the author of the request, begins the verification. The result is 2 outcomes:

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

After which 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 in the system.

About implementation and fine tuning

By the way, it’s worth adding that change request tracking systems are also used as project assignment and tracking systems. After all, any task arising on a project requires monitoring by the management. And the result of most tasks is, again, some kind of change. Therefore, it is logical to use one system for all purposes. Sometimes task tracking systems are also called the general term help desk . However, the meaning of this does not change - I also rank them as systems for tracking 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 of its types - as much as you need to solve everyday tasks. By the way, this is why they often create separate templates to track the development of new functionality and to track the process of fixing bugs. Just because the development of new features also requires the development of requirements, design, tests - and for this, intermediate states or fields are introduced for the listed purposes.

My opinion is that you need to choose a system that allows you to flexibly set the cycle of work. At least to ensure that the once established by someone unknown scheme of work does not become a dogma for your project. Over time, it’s difficult to go beyond it because of the limitations of the tools and the project begins to become “crowded”. So flexible customization is our choice!

Implementation of systems tracking change requests is almost a favorite pastime of programmers around the world. Someone believes that his system will certainly eclipse all available. 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 anyone does not want to invent their two-wheeled vehicle, they can get acquainted with the existing bike park. Well, pick up a bike that is best suited for its task. By the way, the author happened to take some part in the development of the eTraxis mentioned in the above list . I will recommend it, taking this opportunity.

But what about CM engineers?

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

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

A lot of copies break down over the first task - there are many systems, and you need to choose the optimal one. I have a couple of tips for this case, the relevant material has even been written ... however, it will be published a little later, stay tuned :)

Links to broaden your horizons

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

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

So, to be continued.