결함밀도에 대한 질문
강석천
Number of Known Defects / Size (size 는 LOC 이거나 FP 혹은 module 수 등등)
제가 이해하기로는, 외부에서 버그 등록이 된 뒤 이를 분석하여 실제로
코드 내 결함이 있다고 판명된걸 Defect 라고 하는 것 같은데 (http://dicawoo.com/178 에의 defect
기준)
질문이 두 가지가 있습니다.
1. 자주 사용되지 않은, 유저가 별로 없는 프로그램의 경우 버그 -> 결함 으로 판명되는 수
자체가 적으므로, 본래의 잠재된 결함 밀도보다 더 낮은 수치가 나올 수 있지 않을까?
2. 결함 밀도와 프로젝트 규모 증가량으로 잠재된 결함 수를 추정하는 것이 있던 것 같은데,
아시는 분~
박응주
On Feb 10, 10:42 am, 강석천 <free1...@gmail.com> wrote:
> 아직 제대로 공부를 안해서..; 계산을 해보려고 찾아보고 있는데, 공식이 이랬습니다.
>
> Number of Known Defects / Size (size 는 LOC 이거나 FP 혹은 module 수 등등)
>
> 제가 이해하기로는, 외부에서 버그 등록이 된 뒤 이를 분석하여 실제로
>
> 코드 내 결함이 있다고 판명된걸 Defect 라고 하는 것 같은데 (http://dicawoo.com/178에의 defect
> 기준)
>
> 질문이 두 가지가 있습니다.
>
> 1. 자주 사용되지 않은, 유저가 별로 없는 프로그램의 경우 버그 -> 결함 으로 판명되는 수
>
> 자체가 적으므로, 본래의 잠재된 결함 밀도보다 더 낮은 수치가 나올 수 있지 않을까?
그렇죠. fault가 많아도 아무도 안쓰면 failure로 나타나지 않죠. 또 fault가 blocking failure를 만들
면 더 이상 테스트를 진행하지 못해 failure가 적은 것 처럼 보일 수도 있습니다. 여러 failure의 원인이 하나의
fault일 수도 있고, 여러 fault가 하나의 failure를 유발할 수도 있고 여러 fault가 상쇄하여 failure를
유발하지 않을 수도 있습니다. 시스템에 몇 개의 fault가 남았는지는 직접적으로 알 수는 없죠.
>
> 2. 결함 밀도와 프로젝트 규모 증가량으로 잠재된 결함 수를 추정하는 것이 있던 것 같은데,
일반적인 공식은 의미가 없을 것 같고 fault를 주기적(시간이나 크기 등의 규모를 나타내는 단위로)으로 기록하면 특정한 상황
에 대해서는 추이를 알 수 있지 않을까요?
>
> 아시는 분~
강석천
> 면 더 이상 테스트를 진행하지 못해 failure가 적은 것 처럼 보일 수도 있습니다. 여러 failure의 원인이 하나의
> fault일 수도 있고, 여러 fault가 하나의 failure를 유발할 수도 있고 여러 fault가 상쇄하여 failure를
> 유발하지 않을 수도 있습니다. 시스템에 몇 개의 fault가 남았는지는 직접적으로 알 수는 없죠.
예. 직접적으로 알 수 없는지라.. 어떻게 좀 적당히 추정할 방법이 없을까 궁리중이여서요. 정확도 자체 보다는 뭔가 품질 개선
일을 하고 before-after 평가용으로 이야기할만한 매트릭이 없을까 궁리하다가.. 논문같은 곳에서는 결함 밀도를 많이 체크
하는 것 같은데, 이 또한 좀 한계가 있어보여서요.
> 일반적인 공식은 의미가 없을 것 같고 fault를 주기적(시간이나 크기 등의 규모를 나타내는 단위로)으로 기록하면 특정한 상황
> 에 대해서는 추이를 알 수 있지 않을까요?
말 그대로 '추정' 을 하려고요. ^^ 별 큰 목적은 아닙니다. 릴리즈 뒤의 버그 트래킹을 계속 하고 있고 월 별 증가/감소는
측정하고 있습니다. 단, 버그 트래커에서의 버그의 증/감은.. 코드 자체의 품질 문제 영향도 있겠지만, 고객이 늘었느냐 줄었느냐
가 더 큰 factor 가 되더라는...;;;
처음엔 뭔가 좀 적당히 재고 적당히 품질 개선을 위한 끌개로 써먹자 생각했는데.. 가면 갈수록 얽히는 변수들이 많네요. -
_-;
박응주
QSM에서는 failure를 원인을 추적해서 fault를 찾아 따로 관리하라고 합니다. failure에서 fault 까지 추적하
여 측정을 하면 측정 비용이 더 들겠죠. 그렇게 하더라도 고객이 늘어나 다양한 failure가 발생하면 당연히 원인 fault
도 더 많아지겠죠.
고객의 영향을 배제하려면 고객이 영향을 미치는 지표들은 다 빼야겠죠. 잘 아시겠지만 각종 코드 품질 측정 방법이 있지만 그것들
은 또 그것들 나름대로 문제가 있죠.
QSM: First-Order Measurement 추천합니다. :-)
강석천
> 은 또 그것들 나름대로 문제가 있죠.
그렇다고 현실에 눈을 감을 수는 없으니;; 뭐.. '알아서 잘..' 해야죠.;
> QSM: First-Order Measurement 추천합니다. :-)
한 해 동안 공부 좀 많이 열심히 해야겠다는 생각이..; QSM 나머지 책들도 신청해야겠습니다. ^^
(일단 신청한 책이라도 어여 와야 하는데..)
회사에서 SE 에 관심 많으신 본부장님과 이야기하려면 다 험프리의 책으로 이야기하시는지라..(PSP, CMM ..) 험프리는 험
프리대로..
June Kim
>> 그렇죠. fault가 많아도 아무도 안쓰면 failure로 나타나지 않죠. 또 fault가 blocking failure를 만들
>> 면 더 이상 테스트를 진행하지 못해 failure가 적은 것 처럼 보일 수도 있습니다. 여러 failure의 원인이 하나의
>> fault일 수도 있고, 여러 fault가 하나의 failure를 유발할 수도 있고 여러 fault가 상쇄하여 failure를
>> 유발하지 않을 수도 있습니다. 시스템에 몇 개의 fault가 남았는지는 직접적으로 알 수는 없죠.
>
> 예. 직접적으로 알 수 없는지라.. 어떻게 좀 적당히 추정할 방법이 없을까 궁리중이여서요. 정확도 자체 보다는 뭔가 품질 개선
> 일을 하고 before-after 평가용으로 이야기할만한 매트릭이 없을까 궁리하다가.. 논문같은 곳에서는 결함 밀도를 많이 체크
> 하는 것 같은데, 이 또한 좀 한계가 있어보여서요.
>
다음은 내가 종종 쓰는 방법:
1. 전체 소스 리포지토리에 Quality Metric을 돌린다. (C언어 경우 Cyclometic Complexity를 선호)
2. Metric 수치에 따라 파일/모듈/함수를 몇 개의 그룹으로 나눈다. 예컨대 high/middle/low complexity
3. 각 그룹 내에서 random sampling(stratified sampling)을 한다. (보통 각 그룹당 최소 10개 이상)
4. 샘플들에 대해 다음과 같은 활동을 통해 defect를 측정한다:
4.1. Bug Tracking System에 등록되어 있는 이슈들 중에 이 샘플과 관련 있는 것이 몇 개인가, severity는?
4.2. 코드 인스펙션
4.3. blackbox/whitebox exploratory testing (통상 bug hunt를 써서 하루 정도 날 잡고)
이렇게 하면 일종의 가짜 실험을 비교적 적은 비용으로 할 수 있음. 전체 defect 숫자도 대략적으로 추정 가능함.
June Kim
Capture/Recapture 메소드
호수에 물고기가 몇 마리나 있을까 물어보면 생물학자들은 어떻게 측정을 할까? 일단 물고기 몇 마리를 잡은 다음, 그 물고기에
표시를 하고 다시 풀어준다. 그리고 얼마후에 다시 잡아서 그 중 몇 마리가 표시를 달고 있는지 본다. 그러면 호수에 사는 전체
물고기 숫자를 추정할 수 있다. (확률적으로)
마찬가지로 하나의 모듈을 두 사람의 리뷰어가 검토하다가
N1= 1번 리뷰어가 발견한 전체 defect 숫자
N2= 2번 리뷰어가 발견한 전체 defect 숫자
N12=두 리뷰어 모두에 의해 발견된 defect 숫자
Ntot=N1*N2/N12 (Ntot = 해당 모듈에 있는 전체 defect 숫자)
2009/2/11 June Kim <june...@gmail.com>:
STEN_조현길
결함밀도는 식별된 결함을 대상으로 하는 수치이기 때문에 1번과 같은 문제는
당연히 있을 수 있습니다. 2번에서 말씀하신 것과 같이 결함 밀도와 사이즈를
바탕으로 잔존 결함을 추정하는 방법은 잘모르겠습니다. 케이퍼 존스의
통계자료(http://issuu.com/meade/docs/qualitysurvey2008)를 보면 펑션포인트당
잠재 결함 개수가 나오긴 하는데 한국에서도 통하는 건지는 모르겠습니다.
보통 저같이 테스트 하시는 분들은 결함 관리 시스템의 트렌드를 보고 추정을
많이 합니다. 테스트의 초반부와 후반부에 걸쳐 시기별로 누적결함을 보면
일반적으로 S커브(처음에는 결함이 조금씩 등록되다 중간에 등록양이
기하급수적으로 늘어나고 마지막에는 점점 줄어드는 형태)를 그리는데
이 커브의 형태를 보고 주식예측하듯이(-_-;;) 트랜드를 예측합니다.
만약 릴리즈를 하는 제품이라면 과거 릴리즈의 Defect Detection Percentage
DDP=고객이시장에서발견한결함/(고객이시장에서발견결함+출시전테스트발견결함)
를 보는 것도 도움이 됩니다.
좀더 학술적이고 포멀한 방법으로는 하드웨어쪽에서 많이 하시는
신뢰성 테스트쪽 자료를 참고하시거나 아래와 같은 논문들이
도움이 되실지도 모르겠습니다.
http://unbox.org/promise/2006/talks/HaiderCangussu.ppt
http://software-qa-process.blogspot.com/2008/11/estimation-methods-for-defect.html
그럼 참고 부탁드리며, 항상 에너지 넘치는 하루 되시길 바랍니다.
현길 올림.
On 2월10일, 오전10시42분, 강석천 <free1...@gmail.com> wrote:
> 아직 제대로 공부를 안해서..; 계산을 해보려고 찾아보고 있는데, 공식이 이랬습니다.
>
> Number of Known Defects / Size (size 는 LOC 이거나 FP 혹은 module 수 등등)
>
> 제가 이해하기로는, 외부에서 버그 등록이 된 뒤 이를 분석하여 실제로
>
> 코드 내 결함이 있다고 판명된걸 Defect 라고 하는 것 같은데 (http://dicawoo.com/178에의 defect
강석천
> 안녕하세요. STEN의 조현길입니다. 개인적으로 무쟈게 어려운 주제네요. ^^
>
> 결함밀도는 식별된 결함을 대상으로 하는 수치이기 때문에 1번과 같은 문제는
> 당연히 있을 수 있습니다. 2번에서 말씀하신 것과 같이 결함 밀도와 사이즈를
> 바탕으로 잔존 결함을 추정하는 방법은 잘모르겠습니다. 케이퍼 존스의
> 잠재 결함 개수가 나오긴 하는데 한국에서도 통하는 건지는 모르겠습니다.
>
안녕하세요.~
FP 계산의 경우, 지금 코드가 양이 좀 되는 점이랑, 추후에도 자동화 하기 쉽지 않다는 점이 문제입니다.
그냥 적당히 eLOC 대비 FP 기준으로 적당히 환산하게 되는데.. 차이가 나는 건 어쩔 수 없겠죠.
> 보통 저같이 테스트 하시는 분들은 결함 관리 시스템의 트렌드를 보고 추정을
> 많이 합니다. 테스트의 초반부와 후반부에 걸쳐 시기별로 누적결함을 보면
> 일반적으로 S커브(처음에는 결함이 조금씩 등록되다 중간에 등록양이
> 기하급수적으로 늘어나고 마지막에는 점점 줄어드는 형태)를 그리는데
> 이 커브의 형태를 보고 주식예측하듯이(-_-;;) 트랜드를 예측합니다.
>
> 만약 릴리즈를 하는 제품이라면 과거 릴리즈의 Defect Detection Percentage
> DDP=고객이시장에서발견한결함/(고객이시장에서발견결함+출시전테스트발견결함)
> 를 보는 것도 도움이 됩니다.
>
> 좀더 학술적이고 포멀한 방법으로는 하드웨어쪽에서 많이 하시는
> 신뢰성 테스트쪽 자료를 참고하시거나 아래와 같은 논문들이
> 도움이 되실지도 모르겠습니다.http://unbox.org/promise/2006/talks/HaiderCangussu.ppthttp://software-qa-process.blogspot.com/2008/11/estimation-methods-fo...
>
> 그럼 참고 부탁드리며, 항상 에너지 넘치는 하루 되시길 바랍니다.
>
> 현길 올림.
>
아주 포멀한 것 까진 그리 의미를 두지 않고요. ^^ 그냥 적당한 추이 파악 및 품질 목표 설정을 위한 작업입니다.
DDP 개념은 참고가 될 만 하네요. 감사합니다.~
강석천
감사합니다.~ :)
On 2월11일, 오후3시42분, June Kim <junea...@gmail.com> wrote:
> 이 방법과 혼용해서 쓸 수 있는 것은:
>
> Capture/Recapture 메소드
>
> 호수에 물고기가 몇 마리나 있을까 물어보면 생물학자들은 어떻게 측정을 할까? 일단 물고기 몇 마리를 잡은 다음, 그 물고기에
> 표시를 하고 다시 풀어준다. 그리고 얼마후에 다시 잡아서 그 중 몇 마리가 표시를 달고 있는지 본다. 그러면 호수에 사는 전체
> 물고기 숫자를 추정할 수 있다. (확률적으로)
>
> 마찬가지로 하나의 모듈을 두 사람의 리뷰어가 검토하다가
>
> N1= 1번 리뷰어가 발견한 전체 defect 숫자
> N2= 2번 리뷰어가 발견한 전체 defect 숫자
> N12=두 리뷰어 모두에 의해 발견된 defect 숫자
>
> Ntot=N1*N2/N12 (Ntot = 해당 모듈에 있는 전체 defect 숫자)
>
> 2009/2/11 June Kim <junea...@gmail.com>:
>
> > 2009/2/10 강석천 <free1...@gmail.com>: