Review Process

Typical Approach

• 대부분의 조직에서 테스트 단계 이후에서 결함을 발견하고 제거함

결함관리 원칙

1. 가장 좋은 것은 개발 프로세스에 결함이 유입되는 것을 방지하는 것이다.(L5)
2. 결함이 유입되었을 때, 가능한 한 빨리 개발 프로세스의 테스트 단계 전에서 최대한 결함을
   제거하여야 한다. 이를 위해 체계적인 검토 프로세스가 구축되어야 한다.(L3)
3. 설계와 코딩 단계가 끝났으면 통합 테스트 전에 단위 테스트에서 이전에 발견하지 못한 결함을 제거하여야 한다. 즉 단위 테스트가 처음부터 일을 올바르게 하는 마지막 기회이다

Effective Approach to quality

• 처음부터 제대로 하라 (Do it Right the First Time)
• ouput을 개발하는 데 사용되는 프로세스를 개선하라 (Improve the Process that is used to Develop the Output)

What is Inspection?

소프트웨어 개발 과정에서 품질을 보장하기 위한 공식적인 그룹 리뷰 절차

• 제품의 모든 결함을 찾아서 수정 (Find and Fix All Defects in the Product)

• 제품 결함을 일으키는 개발 프로세스의 모든 결함을 찾아서 수정 (Find and Fix All Defects in the Development Process that Cause Product Defects)

How Software Development goes.

• 요구 사항 정의 (Specify Some Requirements)

• 코드 작성 (Write a Little Code to Satisfy a Selected Subset of Those Requirements)
  전체 요구 사항 중 일부를 선택하여 해당 기능을 구현하는 코드를 작성합니다. 이는 모든 요구 사항을 한꺼번에 구현하는 대신, 점진적으로 코드를 작성하는 접근법입니다.

• 유닛 테스트 (Unit-Test Pieces of Code, Which Together Satisfy the Requirements Subset)
  작성된 코드의 개별 단위를 테스트합니다. 유닛 테스트는 코드가 올바르게 동작하는지 검증하는 단계로, 기능별로 독립적으로 테스트를 수행합니다.

• 코드 통합 (Integrate Each Subset of Code into a System)
  개별적으로 작성된 코드를 시스템에 통합합니다. 이 과정에서는 서로 다른 코드 부분이 함께 작동하는지 확인합니다.

• 시스템 테스트 (System-Test the Code in the System)
  통합된 전체 시스템을 테스트합니다. 시스템 테스트는 소프트웨어가 전체적으로 올바르게 동작하는지, 모든 요구 사항을 만족하는지 검증합니다.

• 설계 명세 작성 (Abstract Design from the Code and Write It in the Form of a Design Specification)
  코드가 선택된 요구 사항을 만족하면, 해당 코드를 기반으로 추상적인 설계를 도출하고 이를 설계 명세서로 작성합니다. 이는 코드와 설계 간의 일관성을 유지하기 위함입니다.

• 다른 요구 사항 선택 및 반복 (Select Another Requirements Subset, and Continue Until All Reqs Are Satisfied)
  다른 요구 사항 하위 집합을 선택하여 동일한 과정을 반복합니다. 모든 요구 사항이 만족될 때까지 이 과정을 반복합니다.

• 사용자 문서 작성 (Write User Documents to Address All the Requirements Subsets that Are Included)
  구현된 기능을 설명하는 사용자 문서를 작성합니다. 이는 최종 사용자에게 소프트웨어 사용 방법을 안내하는 문서입니다.

• 시스템 배포 (Ship System to Users)
  소프트웨어를 사용자에게 배포합니다. 이는 소프트웨어가 실제 환경에서 사용될 수 있도록 하는 단계입니다.

• 사용자가 보고한 결함 수정 (Fix Defects Reported by Users – While Developers Work on the Next Release)

• 설계 시작과 통합 종료 사이의 디자인 및 코드 엔티티의 완전성을 측정하고 추적하는 것은 불가능했다 (To Measure and Track the Completeness of Design and Code Entities Comprising a Function Between Design Start and Integration End Was Infeasible)

Challenges in SW Development

• Challenges
  • Unmanageable software development
    관리 불가능한 소프트웨어 개발
    • Absence of commonly agreed-upon, measurable completion criteria for requirements, design, and code
      요구 사항, 설계 및 코드의 완료 기준 부재
    • To measure and track the completeness of design and code entities comprising a function between design start and integration end was infeasible
      기능을 구성하는 설계와 코드 엔티티의 완전성을 설계 시작부터 통합 종료까지 측정하고 추적하는 것은 매우 어렵습니다.
  • Pressure to reduce the number of defects delivered to customers
    소프트웨어 제품의 품질을 높이기 위해 고객에게 전달되는 결함 수를 줄이는 압박이 존재합니다. 이는 개발 팀에 큰 스트레스를 주고, 개발 과정의 효율성을 저하시키는 요인이 될 수 있습니다.
• Inspection Process as a Solution
  • Measurable exit criteria for all development process operations
    각 개발 단계마다 명확하고 측정 가능한 종료 기준을 설정하여, 작업이 언제 완료되었는지를 명확히 정의합니다
    • Work product which satisfies exit criteria is the First building block
  • Minimize defect rework
    결함 재작업을 최소화하는 것
    • defect rework was 30 ~ 80% of total development effort
      결함 재작업은 전체 개발 노력의 30%에서 80%를 차지

Inspection

저자 및 동료가 표준 위반, 명세와의 차이 등 결함을 발견하기 위하여 소프트웨어 요구사항, 설계, 코드, 테스트설계서, 사용자 메뉴얼 등 소프트웨어 개발과정의 산출물을 육안으로 조사하는 공식적인 검토기법

Types of Review

• Management Review
  • 목적 : 진척 모니터링, 계획대비 실적 확인, 관 방안의 효과성 평가
  • 주요 결과물 : 프로젝트의 범위 조정, 리소스 할당 조정등 시정조치항목에 대한 의사결정

• Technical Review
  • 목적 : SW Product의 적절성 평가. 주로 해당 분야 기술적 전문가 또는 팀이 수행
  • 주요 결과물 : SW Product 의 기술적 상태. 경영층에게 기술적 상태를 객관적으로 제시하는 수단
  • 제안사항 및 여러 대안에 대한 평가를 제시하기도 함

• Walkthrough
  • 목적 : SW Product의 평가. 평가대상 SW Product의 작성자가 주도하여 개발 팀 또는 관련 팀과 수행함
  • 주요 결과물 : 결함 또는 제안사항, 참여자의 SW Product에 대한 이해도 증진
  • 종종 교육 목적으로 수행되기도 함

• Inspection
  • 목적 : SW 결함 발견. Inspection 교육받은 Facilitator(Moderator) 의 주도로 진행되는 Formal 동료검토
  • 주요 결과물 : 결함 및 이후 조치(수정, 세부 조사 등)에 대한 결정
  • 결함여부를 결정하며, 이를 해결하기 위한 솔루션에 대해서는 논의/결정하지 않음

Inspection Process Flow

Review Team

Minimum team size : 3 persons (moderator/recorder, reader, author),
but…
Maximum team size : 7 persons (author포함)

Roles

• Moderator
  • Responsible for coordinating, controlling, and managing the Inspection within allocated time frame
  검토 과정을 조정하고, 관리하며, 할당된 시간 내에 진행
• Author
  • The person who created the work product being inspected
  검토 대상이 되는 작업물을 생성한 사람
  • The person who usually conducts the overview
  일반적으로 검토 과정에서 개요를 진행하고, 세부 정보를 기록
  • Captures detailed information during the defect discussions
  결함 토의 중에는 상세한 정보를 제공하고, 문제 해결을 위한 자료를 제공
  • To clarify, not justify
• Reader
  • The person who leads the Inspection team through the work product
  검토 팀을 이끌어 검토 대상물을 살펴보고, 관리
  • Usually Paraphrasing rather than reading it literally
  주로 원문을 글자 그대로 읽는 것보다 의도를 파악하여 다시 표현하는 역할
• Recorder
  • The person collecting the data for subsequent data analysis
  검토 과정에서 수집된 데이터를 기록하고, 이를 향후 데이터 분석에 활용할 수 있도록 준비
• Inspector
  • All of the inspection team members are inspectors, include the author, moderator, regardless of their other procedural roles
  • Detect defects, not offer solutions
  주된 역할은 결함을 발견하고 기록하는 것입니다. 해결책을 제안하지는 않습니다.

Planning