어떤 버그를 해결하면 최대의 비용 혜택을 얻을 수 있습니다.

해결하기 쉽고 얼마나 많은 혜택을 주 었는지에 따라 버그를 분류하는 아이디어를 얻고 싶었습니다. 예를 들어, 해결하는 데 1 시간 (더블 파일 닫기 등)이 걸리는 버그가있는 경우 하루가 걸리는 버그 (세그먼트 결함)가 있습니다. 그러나 첫 번째 버그를 해결하는 것이 그다지 중요하지 않은 경우 아마도 두 번째 버그로 작업 할 것입니다.

비용 편익 또는 이와 유사한 메트릭을 기반으로 버그를 분류하는 연구 논문이 있습니까?

보안 취약점, 메모리 오류, 논리 오류 등과 같은 버그 특성을 기반으로 버그를 분류 할 수 있다고 가정 해 봅시다. 다른 차원에서는 어려움 (쉬운, 중간, 하드)과 같은 매개 변수가있을 수 있습니다. 찾고 싶은 다른 치수가 있습니까? 일을 단순화하기 위해 두 가지를 가정 할 수 있습니다.

1. 팀의 모든 프로그래머는 버그를 똑같이 해결할 수 있습니다
2. 마감일이 없습니다

일반적인 버그 추적 시스템에는 버그 비용 편익 비율을 식별하는 두 개 또는 세 개의 필드가 있습니다.

1. 우선 순위 (비즈니스 소유자가 할당)
2. 심각도 (버그 분류-낮음에 중요)
3. 예상 시간 (시간이 얼마나 걸리는지 추측)

아시다시피, 이것은 어떤 버그가 중요한 버그인지 식별합니다.

이 시스템은 PEF / REV : 다차원 버그 추적 메트릭으로 비즈니스 및 개발자 구성 요소에 대한 정보를 추가하여 버그 비용 이점을 제공합니다.

모든 값은 1 .. N 스케일 (각각 동일한 최상위 값)입니다.

PEF는 사업체에 의해 식별됩니다.

• P의 아인 - 버그가 얼마나 고통스러운
• E의 ffort - 그것은 버그를 해결하는 데 걸리는 많은 노력
• F의 requency - 얼마나 자주 버그가 발생

REV는 개발자가 제공합니다.

• R의 ISK - 시스템에 수정이 얼마나 위험하다
• E는 ffort - 얼마나 많은 노력이 버그를 수정하는 것입니다
• V의 erifiability - 그것은 버그 수정을 확인하는 방법을 쉽게

예를 들어, 해결하기 쉬운 충돌이 거의 발생하지 않으면 (자동 저장 켜기) PEF 7,1,1 (점수 9) 일 수 있습니다. 고정하는 동안 코어 모듈을 변경하고 9,3,2 (점수 14)의 REV를 가질 수 있습니다.

반면에 사소한 수정 (1,1,3-점수 5)이있는 항상 성가심 (3,3,9-점수 15)이있을 수 있습니다.

이 예에서 성가심은 더 나은 비용 / 혜택으로 보입니다.

당신이 묘사하는 문제는 매우 흔하며 가장 좋은 대답은 "장 느낌을 사용하는"것일 수 있습니다.

나는 일반적으로 버그를 크 래싱, 성가신, 화장품 (실제로 중요하지 않은 1, 2, 3이라고 부를 수 있음)의 세 가지 범주로 나눈 다음 모든 버그를 수정하는 데 필요한 시간에 대한 전체 추정치를 내려 놓습니다 (모든 버그는 항상 대략적인 추정치 업데이트).

버그를 해결하면 Crashing> Annoying> Cosmetic을 시작한 다음 가능한 한 많은 초기 처리량을 얻기 위해 "가장 짧은 작업"을 수행합니다.

매우 엄격한 범위의 유급 일자리가 아니라면 버그를 해결함으로써 직접적인 재정적 이익을 계산하는 것이 매우 어렵다는 것을 알았습니다.

당신이 필요로 할 수있는 한 가지 참고 사항은 당신이 정말로 Joel Test 에서 다섯 번째 요점까지 살아야한다는 것입니다. 이것은 팀 규모와 다른 "지역"이슈들 사이의 분포에 영향을받을 수 있습니다. 그러나 이것은 일반적으로 좋은 습관의 표시입니다.

다른 고려 사항은 버그 및 수정의 영향과 비용을 결정할 때 버그를 발견하는 테스트 또는 테스트 조직의 유형일 수 있습니다. 단위 또는 기능 테스트는 설계에서 변경해야 할 사항을 지적 할 수 있으므로 조기에 수정하는 것이 나중에보다 쉽고 비용이 적게 듭니다. 시스템 또는 통합 테스트는 더 광범위한 고객에게 영향을 미치는 것을 가리킬 수 있습니다. 또한 표준 테스트는 많은 고객에게 중요하지 않은 경우가 많지만 수정하지 않으면 인증이 손실되고 비즈니스에 부정적인 영향을 줄 수 있습니다.

즉, 특정 테스트 조직에 테스트 실패가 있다고해서 자동으로 버그를 "치명적인"것으로 만들면 안됩니다. 예를 들어, "모든 시스템 테스트는 배송 전에 통과해야하므로 자동으로 실패하는 시스템 테스트는 심각하고 심각도가 높은 버그가 발생합니다."와 같은 유혹이있을 수 있습니다. 어떤 조직도 그 진술을하지 않기를 바라지 만 (좋은 시험 종료 기준은 다른 토론), 요점은 버그의 심각도를 고객의 위치,시기보다는 고객, 제품 또는 회사 이미지에 미치는 영향으로 판단해야한다는 것입니다. 밝혀졌다.

이를 해결하는 한 가지 가능한 방법은 "심각도"와 "긴급"을 구분하는 것입니다. 예를 들어 릴리스 날짜가 다가옴에 따라 심각도가 낮은 버그로 인해 많은 고객이 영향을받을 수 있는지 여부를 결정해야하는 시간이 가중되어 버그가 더 큰 "긴급"상태가되고 해당 버그에 대한 작업이 다른 버그보다 높아질 수 있습니다. 적어도 그 결정이 내려 질 때까지. 경험과 좋은 판단과 함께이 둘 사이의 적절한 균형은 시간과 노력이 소비되는 곳을 지시하는 데 도움이 될 것입니다.

다른 사람들이 버그 분류 등에 관해 말한 것 외에도 특정 버그가 나타내는 치명도 수준을 결정하기 위해 Afferent Coupling (Ca)을 살펴보십시오. Ca 수가 많은 모듈에 버그가 있으면 시스템의 다른 구성 요소에 도움이 될 수 있으므로 먼저 수정하십시오. Ca는 책임 레벨을 결정하는 데 도움이되고 버그가있는 책임 모듈은 전체 애플리케이션을 손상시킵니다 (Ca에 대한 자세한 정보는 http://www.ibm.com/developerworks/java/library/j-cq04256/index.html). ).

이를 염두에두고 버그를 분류하여 고객에게 미치는 영향에 따라 우선 순위를 정하는 경향이 있습니다. 고객은 다양하지만 토론에 참여하게되면 궁극적으로 다른 버그를 수정해야하는 원인이됩니다. 그것은 과학적인 것은 아니지만 전체 팀으로서 버그의 우선 순위와 분류에 대해 합의하는 경향이 있으며, 모든 사람들은 "큰 것들"(모든 이해 관계자가 입력 할 수 있음)에 대한 의견을 가지고 있으며, 우리는 거기에서 쌓이고 쌓입니다.

모든 버그의 실제 비용을 결정할 수는 없습니다. 일부는 수량화하기가 매우 어렵습니다. 예를 들어, 버튼의 모든 텍스트가 약간 잘못 정렬되는 버그가 있다고 가정합니다. 1.0 제품이 약간 조잡 해 보입니다. 이로 인해 프로그램이 중단되거나 사용자가 데이터를 잃지 않습니다. 아마도 꽤 싼 버그일까요?

이제 귀하의 모든 고객이이 문제를 발견하고 모든 검토자가 해당 제품을 검토 할 때이를 언급하면 ​​어떻게됩니까? 이 버그가 버전 1.0에서 1.1 및 1.2로 넘어 가면 어떨까요? 귀하의 회사는 이제 품질 관리면에서 다소 조잡하다는 평판을 얻었습니다. 향후 제품에 대한 귀사의 판매 손실 가능성 측면에서이 간단한 버그가 얼마나 비쌀 수 있습니까? 또는 이것이 제품이받는 검토에 어떤 영향을 줄 수 있습니까? 제품이 고객의 요구를 완벽하게 충족시킬 수 있지만 약간 부주의 해 보이기 때문에 10 명 중 9 명만 얻습니다.

따라서 특정 버그의 비용을 수정하는 데 드는 비용과 사용자에게 직접적인 영향을 미치는 관점에서 볼 필요가있을뿐 아니라 제품의 인식에 미치는 영향에 대해 더 큰 맥락에서 고려해야합니다. 시장에서 이러한 인식이 향후 판매에 미치는 영향

이것은 많이 가져온 것처럼 보이지만 그렇지 않습니다. 이 글을 쓸 때 Apple이 캘린더 아이콘의 "1"을 한두 픽셀 씩 움직 인 방법에 대한 기사가있는 웹의 다른 사이트로 이동할 수 있습니다. 검색하면이 작은 버그에 대한 몇 가지 부정적인 기사가 표시됩니다. 물론 이것은 애플의 결론에 직접적으로 영향을 미치지는 않았지만 좋은 디자인의 정점으로 자신을 홍보하므로 디자인 버그가 있으면 약간의 인식에도 영향을 미칩니다.