페이건 검사

Fagan inspection

페이건 검사는 소프트웨어 개발 프로세스의 다양한 단계에서 문서(소스 코드나 형식 사양 등)의 결함을 찾아내는 과정이다.정식 소프트웨어 검사의 창안자로 인정받는[1] 마이클 페이건의 이름을 딴 것이다.

페이건 검사는 공정을 미리 정해진 출입 기준을 가진 특정 활동으로 정의한다[citation needed].진입 및 출구 기준이 지정되는 모든 프로세스에서 Fagan 검사를 사용하여 프로세스의 출력이 프로세스에 지정된 출구 기준을 준수하는지 검증할 수 있다.Fagan 검사는 그룹 검토 방법을 사용하여 주어진 공정의 산출물을 평가한다.[citation needed]

예

Fagan 검사를 사용할 수 있는 활동의 예는 다음과 같다.

  • 요구사항 명세서
  • 소프트웨어/정보 시스템 아키텍처(예: DYA[clarification needed])[citation needed]
  • 프로그래밍(예: XP 또는 DSDM의 반복)
  • 소프트웨어 테스트(예: 테스트 스크립트 생성 시)

사용법

소프트웨어 개발 과정은 페이건 검사의 대표적인 응용이다.초기 작업 시 결함 수리비가 정비단계 결함 수리비 대비 최대 10~100배 가량 적기 때문에 최대한 삽입 지점에 가까운 결함 찾기가 필수적이다.[2]이 작업은 각 작동의 출력을 검사하고 이를 해당 작동의 출력 요건 또는 출구 기준과 비교함으로써 수행된다.

기준

입력 기준은 특정 프로세스를 입력하기 위해 충족되어야 하는 기준 또는 요건이다.[3]예를 들어 페이건 검사의 경우, 상위 및 하위 문서는 공식 검사 프로세스에 사용하기 전에 특정 입력 기준을 준수해야 한다.

종료 기준은 특정 프로세스를 완료하기 위해 충족해야 하는 기준 또는 요건이다.예를 들어, 페이건 검사의 경우, 개발 프로세스를 다음 단계로 진행하기 전에 하위 수준 문서가 특정 출구 기준(고위 수준 문서에 명시된 내용)을 준수해야 한다.

출구기준은 상위 문서에 명시되어 있으며, 이후 점검 시 작업결과(하위 문서)를 비교하는 기준으로 사용된다.낮은 수준의 문서가 높은 수준의 문서에 명시된 높은 수준의 요건을 충족하지 못하는 것을 결함이라고[3] 부른다(중대한 결함 또는 사소한 결함으로 더 분류할 수 있다).사소한 결함은 소프트웨어의 정확한 기능을 위협하지는 않지만, 철자 오류나 그래픽 사용자 인터페이스에서 조정기의 미관적인 위치와 같은 작은 오류일 수 있다.

일반적인 작업

일반적인 페이건 검사는 다음과 같은 작업으로 구성된다.[3]

  • 계획
    • 재료준비
    • 참가자 배열
    • 회의 장소 정리
  • 개요
    • 검토 중인 자료에 대한 참가자의 집단 교육
    • 역할 할당
  • 준비
    • 참가자는 점검할 항목과 지원 자료를 검토하여 회의 준비 시 질문 사항이나 결함을 기록한다.
    • 참가자가 각자의 역할을 준비한다.
  • 점검회의
    • 실제 결점 발견
  • 재작업
    • 재작업은 소프트웨어 검사의 단계로서 검사 회의 중에 발견된 결함을 작성자, 설계자 또는 프로그래머가 해결한다.하자의 리스트에 근거하여 상위 문서의 요건이 충족될 때까지 하위 문서를 수정한다.
  • 후속 조치
    • 소프트웨어 검사의 후속 단계에서 검사 회의에서 발견된 모든 결함은 수정되어야 한다(재작업 단계에서 고쳐졌으므로).감속자는 이것이 사실인지 확인할 책임이 있다.초기 결함을 수정하는 동안 모든 결점이 고정되어 있고 새로운 결점이 삽입되어 있지 않은지 확인해야 한다.프로젝트 후반기에 고치는 비용이 현재 비용보다 10배에서 100배 정도 높아질 수 있기 때문에 모든 결함을 바로잡는 것이 중요하다.[2]
페이건 검사 기본 모델

후속 조치

페이건 검사의 후속 단계에서는 재작업 단계에서 고정된 결함을 검증해야 한다.감속자는 보통 재작업을 검증할 책임이 있다.때로는 결점이 사소한 경우처럼 검증되지 않고 고정 작업을 수락할 수 있다.비사건의 경우 전체 재점검은 검사팀(의장뿐 아니라)이 수행한다.

검증이 실패하면 재작업 프로세스로 돌아가십시오.

역할

점검과정은 일반적으로 사업을 시행하고 있는 같은 팀의 구성원에 의해 수행된다.참가자는 검사 프로세스 내에서 다른 역할을 수행한다.[4][5]

  • 저자/디자이너/코더 : 하급서류 작성자
  • 독서자: 낮은 단계의 문서를 패러프레이션
  • 검토자: 테스트 관점에서 낮은 수준의 문서 검토
  • 의장: 점검 세션 담당, 코치의 역할 수행

이점 및 결과

검사를 사용함으로써 최종 제품의 오류 수가 현저하게 감소하여 더 높은 품질의 제품을 만들 수 있다.향후 팀은 설계와 코딩에서 가장 빈번하게 발생하는 오류에 대한 통찰력을 제공하므로 오류를 피할 수 있을 것이다.검사 과정을 지속적으로 개선함으로써 이러한 통찰력을 더욱 사용할 수 있다.[3]

위에 언급된 주요 "비용 개선"과 함께, 오류의 회피와 조기 발견이 프로젝트의 후반 단계에서 디버깅에 필요한 자원의 양을 줄일 수 있기 때문에, 주요 "비용 개선"에 도달할 수 있다.

실제로 IBM과 같은 대기업에서는 매우 긍정적인 결과가 보고되어 80~[citation needed]90%의 결함을 발견할 수 있고 최대 25%의 자원 절감에 도달할 수 있는 것으로 나타났다.[3]

개선사항

페이건 검사 방식이 매우 효과적이라는 것이 증명되었지만,[citation needed] 복수의 연구자에 의해 개선안이 제시되어 왔다.예를 들어, Genuchten은[6] 긍정적인 결과를 가지고 회의의 생산성을 향상시키기 위한 전자 회의 시스템(EMS)의 사용을 연구해왔다.

다른 연구자들은 탐지된 오류의 데이터베이스를 유지하고 이러한 일반적인 오류에 대해 프로그램 코드를 자동으로 스캔하는 소프트웨어의 사용을 제안한다.[8]이것은 다시 생산성 향상으로 귀결될 것이다.

참조

  1. ^ "Code Inspection". 25 July 2016.
  2. ^ a b Fagan, M. E. (1976). "Design and code inspections to reduce errors in program development". IBM Systems Journal. 15 (3): 182–211. doi:10.1147/sj.153.0182. ISSN 0018-8670.
  3. ^ a b c d e Fagan, Michael E (2001) [1986]. "Advances in Software Inspections" (PDF). Pioneers and Their Contributions to Software Engineering. pp. 335–360. doi:10.1007/978-3-642-48354-7_14. ISBN 978-3-540-42290-7.
  4. ^ M.E., Fagan (1976). "Design and Code inspections to reduce errors in program development" (PDF). IBM Systems Journal. 15 (3): 182–211. doi:10.1147/sj.153.0182.
  5. ^ Eickelmann, N.S; Ruffolo, F; Baik, J; Anant, A (2003). "An empirical study of modifying the Fagan inspection process and the resulting main effects and interaction effects among defects found, effort required, rate of preparation and inspection, number of team members and product 1st pass quality". 27th Annual NASA Goddard/IEEE Software Engineering Workshop, 2002. Proceedings. p. 58. doi:10.1109/SEW.2002.1199450. ISBN 978-0-7695-1855-8. S2CID 114935466.
  6. ^ https://ieeexplore.ieee.org/author/37621969200
  7. ^ Genuchten, M; Cornelissen, W; Van Dijk, C (Winter 1997–1998). "Supporting Inspections with an Electronic Meeting System". Journal of Management Information Systems. 14 (3): 165–179. doi:10.1080/07421222.1997.11518179.
  8. ^ Doolan, E.P. (February 1992). "Experience with Fagan's Inspection Method". Software: Practice and Experience. 22 (2): 173–182. doi:10.1002/spe.4380220205. S2CID 942973.

Ron Radice, 고품질, 저비용 소프트웨어 검사, 패러독스콘 출판(2001년 9월 21일)