What is the difference between error and change request in MSF for CMMI?

Question

I am currently evaluating the MSF for CMMI process template in the TFS section for use in my development team, and I am having trouble understanding the need for separate types of request and change work items.

I understand that when creating reports it is useful to distinguish between errors (errors) and requests for change (change of requirements).

However, in our current system, we have only one type of change request and simply use the field to indicate whether this is an error, change of requirements, etc. (this field can be used to create reports requests).

What are the benefits of having a separate workflow for errors?

I am also confused by the fact that developers may submit a work with an error or change request, I thought that the alleged workflow was for errors to generate change requests, which are what the developer says when changes are made.

Answer 1

@Luke

I do not agree with you, but this difference is usually explained by why there are two different processes for handling two types of problems.

I would say that if the color of the homepage was originally designed to be red, and for some reason it is blue, it is easy to quickly fix and does not require the involvement of many people or man-hours change. Just check the file, change the color, check it and update the error.

However, if the color of the home page was designed as red and red, but someone believes that it should be blue, that is, it doesn’t matter to me, a different type of change. For example, has anyone thought about the effect this may have on other parts of the page, such as images and logos overlapping a blue background? Could there be borders to things that look bad? The link is underlined in blue, will it be displayed?

As an example, I am the red / green color of the blind, the color change of something for me is not something that I take lightly. There are enough web pages on the Internet, which creates problems. Just to indicate that even the most trivial changes can be nontrivial if you all think.

The actual final change in the implementation is probably almost the same thing, but for me the change request is a different beast, precisely because it needs to be thought of to make sure that it will work as expected.

However, the mistake is that someone said that we were going to do it , and then someone did it differently.

The change request is more like , but we need to consider this other thing ... hmm ....

Of course there are exceptions, but let me distract your examples.

If the server was designed to handle more than 300 million page views, then yes, this is an error that it is not. But the development of a server to handle the fact that many page views are more than just saying that our server should process 300 million page views, it should contain detailed specifications very much how this can be done, up to guarantees of processing time and disk access average time. If the code is then implemented exactly as it was designed, and cannot execute as expected, then the question arises: did we create it incorrectly or did we implement it incorrectly?

I agree that in this case, this should be considered a design flaw or implementation flaw, depending on the actual reason why it does not live up to expectations. For example, if someone suggested that the drives were 100 times faster than they actually are, and this is considered the reason why the server is not working properly, I would say that this is a design error, and someone needs in a redesign, If the initial requirement that many pageviews still need to be done, a large redesign with a lot of data in memory, etc. may be required.

However, if someone simply did not take into account how RAID disks work and how to use striped media correctly, this is a mistake and might not be needed for this big change.

Again, of course, there will be exceptions.

In any case, the original difference that I have outlined is the same that I discovered in most cases as the truth.

Answer 2

Keep in mind that part of the definition of a work item type for TFS is the definition of "Workflow", which means the states in which a work item can exist and transitions between states. This can be provided by the security role.

So, generally speaking, a “change request” will be initiated and approved by someone relatively high in the organization (someone with Sponsorship rights associated with spending resources to make a (possibly very large) change to the system Ultimately, this the person will approve that the change was successfully implemented.

However, for an “error”, ANY application user must be able to initiate an error.

In the organization in which I implemented TFS, only department heads can initiate a “change request,” but “Errors” were created from Help Desk tickets (not automated, only through the process ...)

Answer 3

Typically, although I can't talk about CMM, change requests and errors are handled and treated differently because they usually refer to different parts of the application life cycle.

Error in your implementation of the program. For example, if you create your program in order to be able to add two numbers and give the user a sum, then the defect will be that it does not correctly process negative numbers and, therefore, an error.

A change request is when you have a design flaw. For example, you could say that your program should not process negative numbers. The change request is then sent for reorganization, and thus overrides this part. A design flaw may not be deliberate, but it can easily be caused by the fact that you simply did not consider this part when you originally developed your program, or new cases were created that did not exist at the time when the original design was created since then .

In other words, a program can work just like it was designed, but it needs to be changed. This is a change request.

---

As a rule, fixing a bug is considered a much cheaper action than executing a change request, since the bug was never intended to be part of your program. The design, however, was.

And thus, a different workflow may be required to process two different scenarios. For example, you may have a different way of acknowledging and reporting errors than you have for change requests, which may require additional work to state the consequences of the change.

Answer 4

An error that is violated in a requirement that has already been approved for implementation.

The change request must go through a cycle in which the impact and effort must be evaluated for this change, and then it must be approved for implementation before work on it begins.

These two are fundamentally different from CMM.

Answer 5

Is my assumption wrong that change requests are due to errors? I am confused because I do not think that all errors should be automatically approved for implementation - they can be trivial, and at least in our case the same review process will take place as the change request before it is assigned to the developer .

Answer 6

Implementation always comes from requirements. It may be from a product manager, it may be from some random thoughts. It can be documented, it can be from some kind of conversation. In the end, even in such a simple thing as a := a + 1 , the “real” implementation will be based on a compiler, linker, processor, etc., Which depends on the physical law of real life.

A mistake is what is implemented against the ORIGINAL requirement. In addition, this is a change request.

If the requirement has changed, and the implementation must also be changed, this is a change request.

If the dependency has been changed, for example, the web browser has ceased to support some tags, and you need to make some changes, this is a request for change.

In fact, anything that is not properly documented should be considered a change request. Did the product manager forget to add something to the story? Sorry, this is a change request.

All change requests must be properly evaluated and indicated. Developers are paid for making changes, not for errors and fixing their mistakes.