인스펙션을 효과적으로 할 수 있는 방법들

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

최근 개발되는 소프트웨어의 크기가 증가하면서, 현실적으로 모든 소프트웨어에 대해 실시하는 것은 불가능하게 되었다. 모든 소프트웨어에 대해 인스펙션을 시행하는 것이 불가능할 때 선별적으로 중요한 산출물만이라도 인스펙션을 실시한다. Fagan에서 추천하는 속도는 시간당 150~200줄 정도이다.

모든 소프트웨어에 대해 인스펙션을 시행할 수 없을 경우

• 소스코드의 중요도를 상, 중, 하로 분류하고 상은 필수, 중은 선택, 하는 walkthrough없이 일반 테스팅만 걸친다
• 만약 모든 중요도를 중, 하로 분류한다면? 동료 개발자의 도움을 받아 품질을 확인해주는 편법을 쓴다면?
  - 편법은 통하지 않는다. PM이 무능하지 않다면 당연히 알아챌 것이다. + 장기적으로는 능력의 한계를 숨길 수 없다.
  - 소프트웨어 개발은 "노동집약적, 창의성과 성실성을 요구하는" 작업이고 "실명제"로 관리하기에 책임을 져야 한다

자발적인 인스펙션

• 구글에서는 동료들이 서로 돕는 것을 권장할 뿐만 아니라 인사고과를 결정하는 요소로 고려한다.
• 성숙하지 못한 조직은 본인의 업무만을 평가하기 때문에 동료를 잘 돕지 않는다.
  - 그렇다고 인스펙션 참여도에 따라 가산점을 주면 회의의 내용보다는 참석 그 자체에 의의를 둘 것이다.
• 소수의 개발자들이 성능을 경험하고 동료들에게 추천한다면 자발적으로 하게 될 것이다.

전문 분야 인스펙션

• 모든 참가자들이 모든 오류를 찾는 것이 아닌, 전문 분야에 대한 오류만을 찾는 것이다.
• 보안 전문가에게는 소프트웨어 취약점 분석을 시킨다

Checklist 내용

• 일반적 내용이 아닌, 과거에 발견된 적 있는 유사한 오류에 검토를 집중할 수 있도록 특화한다.
• 문서가 양식에 따라 잘 작성되어 있는지 / 논리적인 오류가 있는지 등 목적에 따라 내용이 달라질 수 있다.
• 내용이 너무 많다면 활용하지 않을 가능성이 크다.
• NASA safety checklist: 구체적이며 과거의 경험에서 얻은 체크리스트 사용 (60%가 요구사항의 오류)
  - 대부분 예외 상황에 해당하는 요구사항 (out-of-range, Timeout, input arrives,,, 등)
  - Out-of-range value의 경우: 입력값의 범위가 요구사항에 명시되어 있었다면 오류가 없었을 것이다

 

높은 수준의 개발 역량, 체계적인 프로세스를 갖추고 경험이 풍부한 NASA에서도
오류를 발견하지 못했다는 것은 고품질 소프트웨어 개발이 어렵다는 점을 시사한다.

같은 실수를 반복하지 않고 실수로부터 배우려는 성숙한 자세를 가져야 하며,
체크리스트, 수정 전후의 코드, 버그리포트 등을 검색할 수 있는 환경을 구축하는 것이 좋다.