요구사항 검증 방법
1. 리뷰
리뷰는 테스팅 방법의 일종
- 정적 테스팅은 프로그램 실행을 요구하지 않는 반면에 동적 테스팅은 프로그램 실행을 요구
- 정적 테스팅(리뷰)은 문서들을 대상으로 개발 초기 단계에서 사용하여 오류 예방이 가능하나 동적 테스팅은 구현 단계 이후에 사용 가능
- 리뷰와 정적 분석 모두 프로그램 실행을 요구하지 않음
- 정적 분석은 자동화된 도구를 사용하지만 리뷰는 여러 명이 그룹으로 문서들을 검토
- 정적 분석은 큰 규모의 코드를 분석 가능하지만 false positive 결함(결함이 아닌데 결함이라고 판단)이 발생하여 수작업으로 한번 더 검사할 필요가 있음
- 동적 테스트와는 달리 프로그램을 직접 수행하지 않음
- 동료와의 협동 작업을 통한 작업 결과물 검토
- 목적
- 오류 검출
- 표준과의 부합여부 판단
- 대상물의 개선
- 새로운 기술 및 방법에 관한 정보 교류 및 교육
- 대상
- 요구사항 명세서
- 사용자 인터페이스 설계/아키텍처/구조 설계 및 상세 설계
- 코드
- 테스트 계획서/테스트 케이스 및 테스트 절차
- 프로젝트 계획 문서 등
리뷰 vs 동적 테스팅
- 이해용이성/유지보수성 등과 같은 품질 특성을 테스팅으로 평가할 수 있나?
- 동적 테스트는 오류의 직접적인 원인을 찾지 않음. 반면에 동료 검토는 직접적인 원인 탐색
- 동적 테스트는 결함 때문에 더 이상 진전되지 못하는 경우에도 검토는 가능
1. 인스펙션
-
가장 형식적인 동료 검토 방법
-
참가자에 역할 부여(역할이 뚜렷, 책임도 명확)
1.1 개발자(Author)
-
작업 산출 책임
-
인스펙션 요구
-
인스펙션에 필요한 자료들(인스펙션 패키지)을 제출
-
인스펙션 회의 때 질문에 대한 답변
-
미팅에서 검출된 오류 등을 수정(rework 책임)
-
주재자, 리더, 서기가 될 수 없음
-
검토 대상을 만든 사람
1.2 주재자(Inspection Leader)
-
인스펙션 일정 계획
-
참가자 선정 및 역할 부여
-
개발자와 인스펙션 패키지를 취합하여 참가자에게 미리 전달
-
인스펙션 회의 주재
-
재작업(rework) 검증 또는 위임
-
인스펙션 요약 보고서를 작성
1.3 검토인(Inspector)
-
인스펙션 회의를 위해 미리(준비 단계) 인스펙션 패키지를 검토
-
인스펙션 회의 때 문제 발견 및 개선책 등을 제시
-
Check-list 사용 -> 문제 있는지 검출
1.4 리더(Reader)
-
인스펙션 회의 동안에 작업물 발표(프레젠테이션)
-
자신의 이해를 바탕으로 모델 등을 이용
-
질문, 코멘트, 문제 등을 이끌어 냄
-
사서(Recorder)와는 동일인 X
1.5 서기(Recorder)
-
인스펙션 회의 동안에 제기된 모든 논쟁 및 질문 답변을 기록
-
올바르게 기록되는지 확인되어야 함
-
issue log를 작성하는 역할
1.5 검증인(Verifier)
-
인스펙션 회의에서 발견된 모든 결함들을 제대로 수정하였는지 확인(follow up 단계)
-
수정이 안된 결함이 있으면 왜 수정을 안 했는지에 대한 결정이 올바른지를 확인
-
제기된 개선책이 구현되었는지 확인
-
인스펙션 회의 때 논의되지 않았던 사항을 임의대로 추가 및 변경하였는지 확인
-
최종 결과물이 형상 관리 시스템에 제공되었는지 확인
