1. 문제점의 수명주기

* 사용자 -> 제작사 문제점 보고
* 문제점 재현
* 문제 상황 격리
* 코드에서 결함을 찾고 교정
* 교정 결과물을 사용자에게 돌려줌

--> 수명주기의 조직화 필요

1. 문제점이 드러나 있는지 (소프트웨어에 결함이 존재)
2. 가장 심각한 문제점은 무엇인지 (심각도 순서대로 교정 필요)
3. 과거 문제점 사례발생 여부 (기존의 해결책 이용 가능성)

[ 대규모 디버깅 공정을 어떻게 조직화할 것인가? ]

2. 문제점 보고

* 문제점 보고 (Problem Report) == 변경요청 == 버그리포트
* 문제점 보고에 쓸데없지 않은 것만 포함시켜야 함
  --> 그러기 위해서 '유관사실'만을 판별하고, 구체적 항목으로 목록화

* 문제점 보고에 포함시켜야 할 내용 (기본원칙)

3. 문제점 관리

* 한번에 오직 한 사람만 문제점 문서를 다루어야 한다.
    - 버전 관리 시스템에서는 분리 병합
* 이전의(교정된) 문제점에 대한 내력이 사라진다.
    - 버전 관리 시스템에서는 변경 내력 유지 가능
* 규모 가변성이 없다.
    - 하나의 통합된 문서 형태로 관리가 가능해야 함.
       ---> 그러기위해서, 문제점 데이터베이스에 모든 문제점 보고들을 저장
              ex) BugZilla

4. 문제점 분류

# 각 애트리뷰트별로 문제점을 분류

* 심각도 (Severity) - '차단, 치명, 주요, 보통, 부차, 사소' 레벨이 부여
* 우선순위 (Priority) - 개발/문제해결 공정을 조절하는 핵심 기준
* 식별자 (identifier) - 특정 문제점 지칭용
* 주석 (comment) - 문제환경 정보 기입 / 해결책 논의
* 통지
   - 문제점보고시 이메일주소 첨부 --> 문제점보고 변경시 자동통지 받음

# 이상적인 제품은 심각한 문제점을 모두 고친 후에 출시 되어야 함.

5. 문제점 처리

* Unconfirmed (아직 누구도 재현해 보지 않은 상태)
* New (문제점 보고가 있어야 유효함 , 유관 사실이 포함되어 있어야 함)
* Assigned (개발자에 배정됨)
* Resolved (해소됨)
* 처리결과
    - fixed
    - Invalid (문제점이 아니거나 유관 정보가 없음)
    - Duplicate
    - WONTFIX (교정 불가)
    - WorksForme(재현 불가)
    - VERIFIED (교정 후 검증 성공)
    - Close (제품의 새 릴리즈가 만들어짐)
    - Reopen (동일 문제 발생시는, new가 아닌 reopen)

6. '문제점 추적' 관리

* 문제점 정리/보관자는?
* 문제점 보고 분류자는?
* 우선순위 설정자는?
    - 문제점 발생 가능성
    - 영향을 받는 사용자수
    - 피해 가능성
* 문제점 처리자는?
* 문제점 종결자는?
* 문제점 수명주기는?

7. '문제점 == 요구사항'

* 문제점은 개발 과정에서 사용 가능
* 요구사항이 주요 문제점
* 요구사항에 따른 중요도 선정
* 계통구조를 지원 해야 함 (세분화 지원)

8. 중복의 관리

* 최대한 많은 사실을 포함
* 중복을 찾기 위해서는 최대한 적은 사실들이 바람직
* 교정의지 없는 문제점: 개발자가 더이상 지원의사 없음 (BugZilla: Won't Fix)
    - 오래된 딱 한번 발생한 문제점
    - 오직 내부에서만 발생한 문제점

9. 문제점과 교정의 연계

* 개발자가 버전별 소스/도구를 사용가능 해야함
  --> 그래야만 개발자 PC에서 재현 가능
* 임의의 구성(형상)을 언제라도 재현할 수 있어야 함
* 소프트웨어 형상관리는 버전 관리 시스템을 이용

10. 문제점과 테스트의 연계

* 실패한 테스트와 문제점을 어떻게 동기화할 것인가?
* 테스트 결과와 문제점 보고를 분리하도록 권장
    - 테스트 결과는 자주 생성됨.
    - 테스트는 결과를 굳이 어딘가에 저장할 필요가 없음
    - 테스트 실패 시 만일 즉시 교정 가능하면 기록의 필요가 없음.
* 테스트 케이스들은 문제점 보고를 퇴물로 만든다.
* 문제점 발생시 재현 가능한 테스트 케이스를 작성

< Why Programs Fail >

1. 결함 ------> 실패

* 프로그래머가 결함(감염 발생할 수 있는 코드 일부)을 만듬
  - 예측 불가능 / 복수의 모듈간에 인터페이스 비호환

* 결함에서 감염이 발생 (반드시 발생하는 건 아님, 가능성)

* 감염의 확산

* 실패의 발생 (실패: 프로그램 실행시 겉으로 드러나는 오류)

2. 시공의 디버깅

* 디버깅 7단계 (TRAFFIC)

* 실패 발생 원인은 F.F.I 에서 발견하게 된다.

* 시간/공간 조사  (온전-->감염으로 전이가  언제/어떻게? ; 디버깅 목표임)
  - 변수/참조 수가 늘수록 탐색해야할 시공간 방대
  - 확실한 지점 (온전한 초기점 / 일부가 감염된 지점)
  - 온전과 감염의 분리, 유관과 무관의 분리

* 의존 사슬: 실패에서부터 이전 변수값들로 이어지는 의존 관계 사슬
* 프로그램 코드/상태 구조화: 함수,모듈,객체..

3. 프로그램이 이상해요

* 실패 경로:  결함(Defect) --> 감염(Infection) --> 실패(Failure)

* 최초 버그 1947.09.09 하바드 마크 II, 나방이 끼어 죽음

* 프로그램 결함은 프로그래머로 인함.

4. 실패 ---> 교정

* 문제점 추적:  문제보고서를 기록/보관하는 일
  - 실패과정도 문제재현 절차에 포함

* 복잡한 프로그램의 경우, 실패 재현의 자동화 필요 (사람이 일일이 재현하기 힘듬) - (3장,5장)

* 감염원 후보 찾기
  - 출력이 0이 되는 원인 찾는다
  - 연역(7장)이 어려울 때는, 실패 과정 관찰(8장)
  - 가능성의 영역을 좁혀나감 (수사 과정)
  - 프로그램 실행 도중의 상태관찰 수단 필요

* 유력 후보 감염원에 촛점 맞추자

* 감염원 격리

* 결함 정정 :  이렇게 수정한 후 실패가 안 나타나면, 역시나 그 결함이 실패원인이었음이 입증됨.

5. 자동화 디버깅 기법

* 입력 단순화 (델타디버깅 - 5장)

* 프로그램 슬라이스 (오류 연역 - 7장): 프로그램 실행시 발생 가능/불가능한 사건을, 코드로부터 도출 (추상 ---> 구체)

* 상태 관찰 (사실 관찰 - 8장): 디버거 이용, 프로그램의 특정 상태에 정지시켜 관찰 가능 / 프로그램 변경이나 리컴파일 없이 실행중 관찰 가능

* 상태 감시 (8장): 상태 일부가 실행도중 어떻게 변하는지 관찰 (변수의 감염 순간 포착 가능)

* 단언 (기대의 단언 - 10장): 관찰값/의도값 비교, 함수나 프로그램 전체에서 성립해야 하는 불변식

* 비정상 (비정상 검출 - 11장): 정상/실패 실행간의 차이로부터 비정상을 식별해냄.

* 인과 사슬 (인과사슬의 격리 - 14장): 프로그램 상태에 델타디버깅 적용. 인과관계 원인이 반드시 오류는 아님, 실패요인을 좁혀나갈 수 있다.

* 여러 기법 종합 사용 (결함 고치기 - 15장): 앞의 언급한 다양한 기법들을 연동

* 기타 (실패추적-2장, 자동검사-3장, 실패재현-4장, 여러추론기법결합-6장, 실패원인체계적탐색-12장)

6. 용어 비교/차이

(1) 버그: 사람이 제어가능하거나, 사람에게 책임이 없는 '어떤 것' 암시 / 의미 불분명 / 프로그램의 부정확한 상태,코드,동작 모두를 구분없이 두루두루 지칭하여 혼동을 일으킴 (원인과 증상의 모호)

(2) 결함: 부정확 코드

(3) 감염: 부정확 상태

(4) 실패: 눈에 보이는 수행/동작 버그

# 코드 --> 상태 --> 실행 (버그 발견시, 버그 추적, 버그 교정)
따라서, 용어 의미 불분명으로 혼란스러움,, 아래와 같이 고치면...
# 결합 --> 감염 --> 실패 (실패 발견시, 감염 추적, 결함 교정)

(5) 결점: 전반적 설계/구조 결함  (결함보다 심각)

# 버그:  프로그래머가 그저 짜증스러움에서 대충 뭉뚱그려 사용하는 표현
- 정확한 용어선택으로 실패 근원을 구체화
- 버그라는 용어는 웬지 소프트웨어에 이유없이 자동발생하는 것처럼 느껴짐
- 오류/잘못: 웬지 명백한 인간만의 잘못인 듯한 뉘앙스
- 결함/감염: 반드시 인간의 실수만은 아닌 듯한 느낌, 불필요한 죄책감 모면