소프트웨어 구현 방법론 - Software Inspection & peer review

SW peer review란 

소프트웨어 개발자가 아닌 3자가 소프트웨어 작업관련 산출물을 검사하고 결함을 발견하고 개선 기회를 제공하는 활동이다. 보통 이런게 쓸모 없다고 생각하는 경우가 많지만 나중에 나온 소프트웨어가 잘못나왔을때 있는 손해를 생각해보면 이것이 잘못된 것임을 알 수 있다. 소프트웨어가 잘못 나오게 되면 그에 따른 손해는 훨씬 크기 때문이다. 

 

먼저 Inspection에 대한 대상은 코드 뿐만이 아니라 모든 문서가 대상이된다.

문서를 모두 다같이 검토하는 것이다.

명세서, 설계서, 소스코드가 모두 inspection의 대상이 된다.

 

Inspection을 위해서는 우선 진입 기준이 있는데 Inspection을 시작할 수 있는 산출물의 최소 조건이 이것이다. 근거문서가 검토되고 베이스라인이 설정되어야 하며 표준 템플릿 및 형식을 준수한 양식이 필요하다.

 

Inspection의 시점은 단위 테스트 이후 모듈에 대한 오류가 없음이 확인 되었을때 실행하는것이 좋으며 명세서에 번호별로 미리 참여자들이 결함을 정한 후에 리뷰를 진행하는것이 정석이다. 

 

Inspection의 단계

1. Planning 중재자가 문서를 작성한 Autor와 협의 대상을 파악한 후 preparation, inspection일정 수립, 참여자 확보, 준비를 진행한다.

2. Inspection 계획서(2시간 이내) -> 요구사항(2시간 이내) -> 설계서(1시간 이내) -> 소스코드(1시간 이내) 순서대로 진행한다. 

3. Inspecion 요약 보고서 작성

 

Inspection을 위의 과정처럼 하게되면 준비하는 사람입장에서는 준비를 하게 되며 자연스럽게 리팩토링이 이루어지게 되며 산출물이 정리되는 효과가 있다고 하는데 이게 가장 큰 것 같다.

 

회사에서 하는 이번 프로젝트도 Instpection을 한번 추진해 봐야 겠다는 생각이든다.