CMMI용 MSF의 버그와 변경 요청의 차이점은 무엇입니까?

Question

나는 현재 평가 중입니다. MSF for CMMI 프로세스 템플릿 TFS 개발 팀에서 사용하기 위해 별도의 버그 및 변경 요청 작업 항목 유형이 필요한지 이해하는 데 어려움을 겪고 있습니다.

나는 보고서를 생성할 때 버그(오류)와 변경 요청(요구 사항 변경)을 구별할 수 있는 것이 유익하다는 것을 이해합니다.

그러나 현재 시스템에서는 단일 유형의 변경 요청만 있으며 필드를 사용하여 버그, 요구 사항 변경 등인지 여부를 나타냅니다(이 필드는 보고서 쿼리를 작성하는 데 사용할 수 있음).

버그에 대한 별도의 작업 흐름을 가지면 어떤 이점이 있나요?

또한 개발자가 버그에 대한 작업을 제출할 수 있다는 사실이 혼란스럽습니다. 또는 변경 요청이라는 것은 버그가 변경을 할 때 개발자가 참조하는 변경 요청을 생성하는 것이 의도된 작업 흐름이라고 생각했습니다.

Answer 1

@루크

나는 당신의 의견에 동의하지 않습니다. 그러나 이 차이점은 일반적으로 두 가지 유형의 문제를 처리하는 데 사용할 수 있는 두 가지 다른 프로세스가 있는 이유에 대한 설명입니다.

홈 페이지의 색상이 원래 빨간색으로 디자인되었지만 어떤 이유로 파란색이 되었다면 쉽게 수정할 수 있으며 변경을 위해 많은 사람이나 인력이 필요하지 않습니다.파일을 확인하고 색상을 변경한 후 다시 체크인하고 버그를 업데이트하면 됩니다.

그러나 홈페이지의 색상을 빨간색으로 디자인했는데, 누군가는 파란색이어야 한다고 생각한다면, 그건 어쨌든 나에게는 다른 형태의 변화이다.예를 들어, 파란색 배경에 오버레이되는 이미지 및 로고와 같이 이것이 페이지의 다른 부분에 미칠 수 있는 영향에 대해 생각해 본 적이 있습니까?나쁘게 보이는 것에도 국경이 있을 수 있을까?링크 밑줄이 파란색인데 표시되나요?

예를 들어, 나는 적록 색맹입니다. 어떤 것의 색을 바꾸는 것은 나에게 있어서 가볍게 여길 일이 아닙니다.웹에는 나에게 문제를 일으키는 웹페이지가 너무 많습니다.모든 것을 고려하면 가장 사소한 변화라도 사소한 것이 아닐 수 있다는 점을 강조하고 싶습니다.

실제 최종 구현 변경은 아마도 거의 동일할 것입니다. 그러나 나에게는 변경 요청이 있습니다. ~이다 예상대로 작동하는지 확인하려면 더 많은 생각이 필요하기 때문입니다.

그러나 버그는 누군가가 말했다는 것입니다 이게 우리가 할 방법이야 그런데 누군가가 다르게 해냈습니다.

변경 요청은 다음과 같습니다. 하지만 우리는 이 다른 것도 고려해야 합니다...흠....

물론 예외도 있지만 예시를 따로 살펴보겠습니다.

서버가 있었다면 디자인된 300,000,000,000이 넘는 페이지뷰를 처리하려면 예, 그렇지 않은 것이 버그입니다.하지만 그렇게 많은 페이지뷰를 처리할 수 있는 서버를 설계하는 것은 단순히 말하는 것 이상입니다. 우리 서버는 300,000,000,000 페이지뷰를 처리해야 합니다., 다음을 포함해야 합니다. 매우 처리 시간 보장 및 디스크 액세스 평균 시간까지 이를 수행하는 방법에 대한 자세한 사양입니다.코드가 설계된 대로 정확하게 구현되어 예상대로 수행되지 않으면 다음과 같은 문제가 발생합니다. 우리가 잘못 디자인한 걸까요, 아니면 잘못 구현한 걸까요?.

이 경우 설계 결함으로 간주할지 구현 결함으로 간주할지 여부는 기대에 부응하지 못하는 실제 이유에 따라 다르다는 점에 동의합니다.예를 들어, 누군가 디스크가 실제 속도보다 100배 빠르다고 가정하고 이것이 서버가 예상대로 작동하지 않는 이유라고 간주된다면 나는 이것이 설계 버그이므로 누군가 재설계해야 한다고 말하고 싶습니다. .많은 페이지뷰에 대한 원래 요구 사항이 여전히 유지되어야 한다면 더 많은 인메모리 데이터 및 유사한 데이터를 사용하여 대대적인 재설계를 수행해야 할 수도 있습니다.

그러나 누군가가 RAID 디스크 작동 방식과 스트라이프 미디어의 올바른 이점을 고려하지 못한 경우 이는 버그이므로 수정하기 위해 큰 변화가 필요하지 않을 수 있습니다.

다시 말하지만, 물론 예외가 있을 것입니다.

어쨌든 내가 말한 원래의 차이점은 대부분의 경우 사실이라고 내가 확인한 차이점입니다.

Answer 2

TFS에 대한 작업 항목 형식 정의의 일부는 작업 항목의 상태와 상태 간 전환을 의미하는 "워크플로"의 정의라는 점을 명심하세요.이는 보안 역할에 의해 보호될 수 있습니다.

따라서 일반적으로 말하면 "변경 요청"은 조직에서 상대적으로 높은 위치에 있는 사람(시스템에 (아마도 매우 큰) 변경을 수행하기 위해 리소스를 소비하는 것과 관련된 "후원" 권한을 가진 사람)에 의해 시작되고 승인됩니다.궁극적으로 이 사람이 변경이 성공적으로 수행되었음을 승인하는 사람이 됩니다.

그러나 "버그"의 경우 애플리케이션의 모든 사용자가 버그를 시작할 수 있어야 합니다.

내가 TFS를 구현한 조직에서는 부서장만 "변경 요청"의 발신자가 될 수 있습니다. 그러나 "버그"는 "헬프 데스크" 티켓에서 생성되었습니다(자동화되지 않고 프로세스를 통해서만...).

Answer 3

일반적으로 CMM에 대해 말할 수는 없지만 변경 요청과 버그는 일반적으로 애플리케이션 수명주기의 다른 부분을 참조하기 때문에 다르게 처리되고 고려됩니다.

버그는 프로그램 구현의 결함입니다.예를 들어, 두 개의 숫자를 더하고 사용자에게 합계를 제공할 수 있도록 프로그램을 설계하면 음수를 올바르게 처리하지 못하는 결함이 발생하므로 버그가 됩니다.

변경요청은 설계상의 하자가 있는 경우입니다.예를 들어, 프로그램이 음수를 처리해서는 안 된다고 구체적으로 말했을 수도 있습니다.그런 다음 해당 부품을 재설계하여 다시 구현하기 위해 변경 요청이 제출됩니다.설계상의 결함은 고의가 아닐 수도 있지만, 처음 프로그램을 설계할 때 그 부분을 고려하지 않았기 때문일 수도 있고, 원래 설계 당시에는 없었던 새로운 사례가 발명되거나 발견되었기 때문일 수도 있습니다. 부터.

즉, 프로그램이 설계된 대로 정확하게 작동할 수 있지만 변경이 필요할 수 있습니다.변경요청입니다.

---

일반적으로 버그 수정은 변경 요청을 실행하는 것보다 훨씬 저렴한 작업으로 간주됩니다. 버그는 프로그램의 일부로 의도된 것이 아니기 때문입니다.그러나 디자인은 그랬습니다.

따라서 두 가지 시나리오를 처리하려면 다른 워크플로가 필요할 수 있습니다.예를 들어, 변경 요청과 달리 버그를 확인하고 제출하는 방법이 다를 수 있으며, 이로 인해 변경 결과를 배치하는 데 더 많은 작업이 필요할 수 있습니다.

Answer 4

버그는 구현을 위해 이미 승인된 요구 사항에서 깨진 것입니다.

변경 요청은 해당 변경에 대한 영향과 노력을 평가하는 주기를 거쳐야 하며, 작업을 시작하기 전에 구현 승인을 받아야 합니다.

CMM에서는 이 두 가지가 근본적으로 다릅니다.

Answer 5

변경 요청이 버그에서 생성되어야 한다는 내 가정이 잘못된 것인가요?모든 버그가 구현을 위해 자동으로 승인되어야 한다고 생각하지 않기 때문에 혼란스럽습니다. 버그는 사소한 것일 수 있으며 적어도 우리의 경우에는 개발자에게 할당되기 전에 변경 요청과 동일한 검토 프로세스를 거칩니다.