locked
Bug vs Defect in MSF for CMMI

    Question

  • How are Bugs and Defects used differently within MSF for CMMI? It appears that Defects apply to all work products except for actual software defects, and that software defects are tracked as Bugs and not Defects. Is this correct?

    Also, how do Change Requests and Defects/Bugs interact? If a defect is found in a product, do I enter in a Defect and then associate a Change Request to it? Would I do the same for a Bug? Any help would be greatly appreciated.

    Monday, March 12, 2007 9:39 PM

Answers

  • Answers to your questions:

    1 - They are the same.

    2- Yes, if a defect/bug is found in the product, a bug work item is created and a change request work item is created from it.

    The word defect is a more formal word for "bug", and they can be used interchangeably in the MSF context. I will work with the MSF team to tag this as a documentation bug. It is used in just a few places in the documentation, so it will be easy to replace all "defects" for "bugs".

    What is confusing is the reference to "defect work item" in the "Create Change Request" activity:

    "Examine the defect work item. Determine which baselines must change to correct the defect. For example, if the defect describes an existing requirement that must be updated with new information from the user, the requirements baseline will be affected."

    There are no defect work items in the process template, only bug work items. So for instance the following text from "Manage Change Requests" workstream should be changed accordingly from:

    "All change requests are initiated as the result of a defect found in a baseline. For example, if a meeting with the user uncovers new requirements, a defect is created documenting that the current requirements baseline is out-of-date."

    To

    "All change requests are initiated as the result of a bug found in a baseline. For example, if a meeting with the user uncovers new requirements, a bug is created documenting that the current requirements baseline is out-of-date."

    As an example of the proper usage, take for instance the documentation for the Link field of a change request:

    "This field shows the other work items that have been linked to the change request. A change request should be linked to the bug work item it was created from, and any tasks created to implement the change."

    Regards,

    Clementino Mendonca - MSF Champion

     

     

    Wednesday, March 14, 2007 9:00 PM

All replies

  • Answers to your questions:

    1 - They are the same.

    2- Yes, if a defect/bug is found in the product, a bug work item is created and a change request work item is created from it.

    The word defect is a more formal word for "bug", and they can be used interchangeably in the MSF context. I will work with the MSF team to tag this as a documentation bug. It is used in just a few places in the documentation, so it will be easy to replace all "defects" for "bugs".

    What is confusing is the reference to "defect work item" in the "Create Change Request" activity:

    "Examine the defect work item. Determine which baselines must change to correct the defect. For example, if the defect describes an existing requirement that must be updated with new information from the user, the requirements baseline will be affected."

    There are no defect work items in the process template, only bug work items. So for instance the following text from "Manage Change Requests" workstream should be changed accordingly from:

    "All change requests are initiated as the result of a defect found in a baseline. For example, if a meeting with the user uncovers new requirements, a defect is created documenting that the current requirements baseline is out-of-date."

    To

    "All change requests are initiated as the result of a bug found in a baseline. For example, if a meeting with the user uncovers new requirements, a bug is created documenting that the current requirements baseline is out-of-date."

    As an example of the proper usage, take for instance the documentation for the Link field of a change request:

    "This field shows the other work items that have been linked to the change request. A change request should be linked to the bug work item it was created from, and any tasks created to implement the change."

    Regards,

    Clementino Mendonca - MSF Champion

     

     

    Wednesday, March 14, 2007 9:00 PM
  • This is helpful to know, however, I have a question about another confusing area related to the MSF for CMMI process guidance that hopefully you (or someone) can shed some light on:

    When to create a Change Request (CR) vs. a Requirement vs. a Bug?

    According to the documentation for MSF for CMMI, a CR always gets created as a result of a Bug found in a baseline.  That brings to question when is a baseline really ever "final"?  When a project is first designed and requirements are identified, it's easier to understand.  But after the 1.0 release, wouldn't every new feature and every change to the application as future versions progress all be changes to the baseline?  If so, it seems like you would end up with hundreds of Bugs titled "Baseline is out of date".

    So if I'm understanding it correctly, anytime there is a new feature or improvement to the application after the initial 1.0 release, a Bug should be created which in turn gets a corresponding Requirement created which in turn gets a CR created for it?

    I'm struggling on this MSF for CMMI as to when to create a Requirement, when to create a Bug, and when to create a CR, how they relate and in which order?


    We are a smaller development shop and would probably be following the MSF for Agile process if it wasn't for the government regulations that our projects fall under (this is why we are seeking CMMI Level 3 compliance). 

    Bottomline, we want to create as little work and extra documentation as possible, but there is something to be said for having some "rules of thumb" to go off.  For example, if it was recommended that for CMMI you never make any code changes unless there is a CR, then while that might be a little more work (creating a Bug, then a CR), it might actually save time because you don't have this internal debate in your mind everytime there is a new feature/requirement/bug.

    Tuesday, March 20, 2007 9:16 PM