발표자는 코드를 한 줄씩 또는 함수 단위로 읽어나가고 해당 부분이 무엇을 의미하는지 설명한다. 검토자들은 의문 사항은 무엇이든 질의하며 동료 검토에 비해 다수의 인원이 참여하는 형태이기 때문에 검토 준비와 규칙 준수는 매우 중요하다. 발표자는 검토 결과를 작성하고 발견되 버그에 대한 처리 계획을 명기하는 것이 중요하다. 실행시간은 짧으며, 참여자의 수도 소규모이다.
워크스루의 목적은 소프트웨어의 특정 부분을 검토하는 것이며, 각각의 상세 설계 내용에 대해 검토한다.
시스템 개발의 각 단계에서 실시하는 기술적 검토 회의이며, 오류의 조기 검출에 목적을 두고 있다.
=> 개발자가 동료개발자들(5명내외) 앞에서 격식을 갖춰(프리젠테이션 수행) 자신이 짠 소스 코드를 직접 설명하면서 검토.
정형 기술 검토(FTR:Formal Technical Review)
소프트웨어가 배포된 후에 결함이 되는 오류들을 프로세스 동안에 발견하는 것
기본지침
1) 제작의 결과를 검토하고, 논쟁과 반박을 제한한다.
2) 의제를 정하고, 그 범위을 유지한다.
3) 제기된 문제는 바로 해결하지 않고 검토 모임 후로 미룬다.
4) 참가자의 수를 제한하고 사전준비를 한다.
5) 각 체크 리스트를 작성하고, 자원과 시간 일정을 할당한다.
6) 검토자에 대해 교육을 수행한다.
7) 검토 과정과 결과를 재검토한다.
검사는 검토 방법 중 가장 공식적인 형태이다.
고도로 구조화되었으며 각 참석자는 교육을 필요로 한다. 검사는 동료 검토나 워크스루와 달리 발표나 코드를 읽는 사람이 코드 개발자가 아니다. 따라서 또 다른 누군가가 발료 자료를 배우고 이해하여야 하며, 이로 인해 잠재적으로 검사 회의에서는 다소 다른 견해와 해석이 제공될 수 있다.
나머지 참석자들은 검사관이라 부르며 각 검사관은 사용자, 테스터 등 서로 다른 입장에서 코드에 대한 검토를 임무로 한다.
또다른 검사관들은 진행자나 기록자의 임무를 수행하여 규칙들이 준수되고 있고 검토가 효과적으로 이루어지고 있는지 확인한다.
검사 회의가 열리고 난 이후, 검사관들은 다시 만나서 발견된 결함들에 대해 의논하고 진행자와 함께 결과 보고서를 작성하고 문제를 밝히기 위해 재작업이 필요한지도 검토한다. 그 이후 프로그래머는 코드를 수정하고 수정 결과는 진행자에 의해 검증된다.
인스펙션은 발견된 결함에 대한 해결책을 찾아내는 것이 아니라, 결함이 있다는 사실을 합의하는 것이 주목적이며 이것만으로도 충분히 해결책을 찾는 동기가 된다. 해결책 찾는 일과 수정은 담당자의 권한으로 존중되어야 한다.
인스펙션의 종류: 시스템 설계 인스펙션, 상세 설계 인스펙션, 코드 인스펙션
1. 계획(Panning) : Producer및 Moderator가 주도. 미팅 시간, 일정, 방법 계획. Inspection Package 수집
2. 사전교육(Overview) : Producer 주도로 30 - 60분 정도 (옵션)
3. 준비(Preparation) : 가능한 개인적으로 진행하고, Ad Hoc 형태가 안되게 유의. Inspector에게 파트별 주제를 선 정하는 것도 괜찮음
4. 인스펙션 회의(Inspection Meeting) : 반드시 Issue Log를 작성한다.
5.Third Hour
6. 수정(Rework)
7. 후속조치(Follow-Up) : Rework 결과 확인. 처리여부만 확인하고 Why, How에 대해서는 언급하지 않는다.
8. 원인분석(Causal Analysis) : Process Brainstorming. 개인이 아니라 조직관점에서 Performance 분석
'정보처리기사' 카테고리의 다른 글
| 1과목 소프트웨어 설계(20문제) - 3 (0) | 2023.06.22 |
|---|---|
| 1과목 : 소프트웨어 설계(20문제) - 1 (0) | 2023.06.16 |
| 형상관리(Software Configuration Management) (0) | 2023.05.12 |