정형기술검토 (FTR)

I. 소프트웨어 기능 안정성 확보, 정형기술검토

가. 정형기술검토(FTR, Formal Technical Review)

개념	목적
– S/W 개발 산출물 대상 요구사항 일치여부, 표준 준수 및 결함 발생여부를 검토하는 정적 분석기법	– 산출물 요구사항 일치여부 – 시큐어코딩 등 규칙 준수 – 결함발생 여부 검토 – 결함 해결방안 도출

나. 정형기술검토의 특징

정의된 표준 확인	– 표준, 지침 준수율 파악, 기술적 접근 검토 – 아키텍처 품질속성 도출, 기능안정성 확인
개발 초기 수행	– 운영 환경 토대 요구사항 도출, 기술적 접근 – 요구사항 내용 적합 여부 SDLC 단계 별 확인
코딩가이드 준수	– 시큐어 코딩 등 표준 코딩규칙 준수여부 판별 – 정적 분석 기반 전체 주기 기술적 접근 시도

• FTR 수행 시 S/W품질 비용 및 실패비용 최소화

II. 정형기술검토의 종류

가. Peer Review, 동료 검증

• 프로젝트 수행과정에서 각 단계 별 산출물, 제품에 대해 동료들이 상호교차하여 검토 수행 활동

구분	항목	설명
절차	계획	– 관련 자료 수집, 구성원 역할 배정
	사전준비	– 검토 항목, 범위 설정, 검토 설명
	개별 검토	– 개별적 산출물 검토 진행
	검토 회의	– 산출물 오류, 결함, 조치 사항 회의
	재작업	– 오류, 결함 사항 분석, 조치
	후속조치	– 저자가 작성 내용 반영 여부 판별
구성 요소	관찰 대상 범위	– SDLC 단계 별 산출물 범위 확인
	참여자 구성원	– 중재자, 검토자, 저자, 기록자 등
	체크리스트	– 산출물의 추적도, 설계 구현 내용

나. Inspection, 공식적 검토

• 프로그램을 실행하지 않고 개발단계에서 산출되는 결과물을 공식적 자리에서 검토, 결함 발견 기법

구성 요소	설명
이해 관계자	– 개발된 시스템 사용 위한 담당자 참여
중재자	– 계획 작성, 모임 개체, 주행 절차 중재
독자	– 산출물 확인, 결함 도출 전문가 집단
기록자	– 공식적 결함 문서화, 다수 중재자 겸임

• Inspection 수행 절차는 Peer Review와 동일하며, 공식적 자리에서 결함보고, 후속조치

다. WalkThrough, 팀 검토

• 비공식적 검토과정으로 개발에 참여한 팀으로 구성 가능

구성 요소	설명
내부 인원	– 작업자/개발자 참여 검토회의 진행
결함 해결책	– 결함 상호 교환으로 의견 제안
진행	– 회의 진행 일정 공지, 진행 사항 설명

• 인스펙션 경우 결함발생에 대한 해결책을 제시하지 않지만, 워크스루의 경우 해결책 제안

III. 정형기술검토의 비교

구분	Peer Review	Inspection	Walk Through
개념	– 개발단계별 발생산출물대상 동료검토기법	– 산출물대상 결함발견위한 공식검토기법	– 개발 팀 내 결함해결방안 상호검토기법
목적	– 명세서/계획의 적합성 평가	– 결함 발견 – 설계내용협의	– 결함 발견 -해결방안 검토
기법	– 개별 검토 – 검토 회의	– 이해관계자 산출물검사	– 벤치마킹 – 집중검토기법
추천 규모	– 3명 이상	– 3 ~ 6명	– 2 ~ 7명
참석자	경영자, 관리자 개발자	문서화된 공식 참석 대상자	개발자
리더십	선임 관리자	훈련된 중재자	개발자 본인
산출물	기술검토보고서 적합성평가보고	검사보고서 결함목록	결함해결방안 해결방안검토서

 

IV. 정형기술검토의 활용 방안

가. 정형기술검토의 성공조건

구분	성공 조건	설명
계획 수립	검토 시간 확보	– WBS 상에 검토 시간 확보
	경영층 사전동의	– WBS 일정 수행 계획 배포
벤치마킹 수행	기존 검토 분석	– 유사 프로젝트결과 분석
	우수사례 확인	우수 사례 확인 및 관리
적극적 자세	명확한 목표 제시	– 명확한 목표, 정량적 기준
	결함 발견 유도	– 팀원 간 결함 탐색 유도

나. 정형기술검토의 효과

성공 조건	설명
개발 품질 향상	– 총체적 관리 가능성 향상 – 80%까지 초기 판별 목표로 향상
생산성 향상	– Inspection 수행 시 6개월 간 단축 가능, 전체 재작업 비율 절감
비용절감 향상	– 조기 결함 발견으로 비용 절감 – 예방, 평가 비용 수행, 비용 절감