소프트웨어 인스펙션 기법이란?

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. **

인스펙션 기법의 놀라운 점

• 인스펙션 기법의 뛰어난 성능
• 30년 전부터 적용되었다는 점
• 상식적이고 기본적인 내용으로 이루어진 점

인스펙션 기법 -Fagan

• 인스펙션: 3~6명의 관련자들이 적당한 준비 후 모여서 결함을 찾기 위한 집중적인 검토 모임을 갖는 것
• 인스펙션은 하루에 최대 두 번, 한 번에 최대 두 시간씩 제한하도록 추천
• 참여자들의 역할: Moderator(사회자), Reader, Inspector, Recorder 등
• 오류를 찾기 위한 목적에 집중할 수 있도록 노력하는 것

인스펙션 기법의 과정

• Planning & Overview: 참여자들에게 "product" 설명하는 단계 (소스코드, SRS, 설계 문서 등의 product)
  product를 이해하는 데 필요한 자료를 제공하고 적절한 설명을 제공하는 것이 바람직하다
• Preparation: 인스펙션 수행 전 개인적으로 준비하는 시간, 자료 검토에 집중 + 효율을 위해 checklist 활용
  최대 2시간의 인스펙션 회의를 위해 약 1시간의 준비 시간을 추천함 -Team Software Process (TSP)
• Inspection/Examination: 참여자들이 모여서 역할을 나누어 오류의 가능성이 있는 부분에 대해 짧게 토론 후 결론
  1. 몇 명이 인스펙션? 2. 대면 회의가 필수? 3. reader의 설명을 들으며 순차적으로? 4. 미묘한 분위기를 어떻게 대처?
• Edit & Follow-up: 인스펙션 후 회의록에 오류의 위치와 내용이 정리됨. 개발자는 이를 바탕으로 수정
  사소한 것이 대부분이라면 Moderator와 검토 후 다음 단계로 넘어가도 됨

인스펙션 기법의 효과

• 80~90년대 산업체: 코드 오류 탐지율 50% ~ 90%
• Embedded System: Manual Review (단계별 Inspection +a)와 Manual testing 비교
  1. Defect-removal effectiveness 결함 제거 효율: 인스펙션 (70~80%) vs 테스팅 (25~50%)
  2. Bad fix injection 새로 생길 수 있는 오류의 가능성
      - 인스펙션 (판단 착오로 오류로 판단), 테스팅 (수정 시 오류가 포함된 코드 추가, 모듈간의 상호의존성 고려 필요)

인스펙션 기법의 주의해야 할 점

• 오류를 발견하기 위한 목적이므로 짧고 간단하게 토론한다. 수정 및 해결책은 논의하지 않는다. (모던 코드 리뷰)
• 효율적인 토론을 위해  불필요한, 과도한 토의로 변질될 것 같다면 Moderator가 미팅의 목적을 상기시켜야 한다.
  그러나 직급의 차이가 있다면... 어려울지도
• 개인적인 공격이나 비판은 삼가한다. 동료들의 도움에 고마워하는 태도를 가져야 하며, 논쟁보다는 의견 설명으로!
• 인스펙션의 목적은 오류 발견이지 검토 능력을 평가하거나 과시하기 위한 자리가 아니다.
  인스펙션 내용으로 요업무 능력 평가 자료로 쓰지 않는 것이 좋다, 할 것이라면 팀 단위로 격려
• 논리적인 오류와 옳지 않은 출력으로 이어질 가능성이 있는 Major 오류에 집중한다.
• 결과의 정리 및 인스펙션 과정으로 온라인 도구를 사용한다
  - 온라인 도구 종류: gerrit, codeflow, Visual Studio 2017, Scrub (NASA)
  - NASA에 따르면... 회의 전 온라인으로 의견을 검토하면 시간을 60% 절약 가능 (동의/비동의/논의로 표시 후 회의)
• Preparation 단계가 인스펙션 효율을 결정하는 가장 중요한 요소이며, 준비가 덜 됐다면 인스펙션을 미뤄야 한다.
• 개발자들이 모르거나, 심리적으로 거부감을 갖는 경우가 있다.
  교육과 설득, 규정 등을 통해 사용하도록 유도해야 한다.

 

---

추가 자료 리스트

• Article "Embedded software: Facts, Figures, and Future" - Ebert&Jones, IEEE Computer (2009)