소프트웨어 검토

Software review
다음에 대한 시리즈 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
연습
도구들
지식의 표준 및 본문
용어집
윤곽선

소프트웨어 검토는 "프로젝트 담당자, 관리자, 사용자, 고객, 사용자 대표자 또는 기타 이해관계자가 의견이나 승인을 위해 소프트웨어 제품을 검토하는 과정 또는 회의"이다.[1]

이 맥락에서 "소프트웨어 제품"이란 "소프트웨어 개발 활동의 결과물로 생산되는 모든 기술 문서 또는 부분 문서"를 의미하며, 계약, 프로젝트 계획 및 예산, 요건 문서, 규격, 설계, 소스 코드, 사용자 문서, 지원 및 유지보수 문서 등의 문서를 포함할 수 있다., 시험 계획, 시험 사양, 표준 및 기타 전문 작업 제품.

다양한 소프트웨어 리뷰

소프트웨어 검토는 세 가지 범주로 나눌 수 있다.

  • 소프트웨어 안전 점검은 저자의 한 명 이상의 동료가 작업의 기술적 내용 및/또는 품질을 평가하기 위해 실시한다.[2]
  • 소프트웨어 관리 검토는 관리 담당자가 수행한 작업의 상태를 평가하고 다운스트림 활동에 관한 의사결정을 하기 위해 실시한다.
  • 소프트웨어 감사 심사는 규격, 표준, 계약서 계약서 또는 기타 기준의 준수를 평가하기 위해 소프트웨어 프로젝트 외부 인력에 의해 수행된다.

다양한 유형의 안전 점검

  • 코드 검토는 컴퓨터 소스 코드의 체계적 검토(종종 동료 검토)이다.
  • 페어 프로그래밍은 두 사람이 동일한 작업대에서 함께 코드를 개발하는 코드 검토의 한 유형이다.
  • 점검은 검토자들이 결함을 찾기 위해 잘 정의된 프로세스를 따르는 매우 공식적인 안전 점검 유형이다.
  • 워크스루(Walksrough)는 작성자가 개발팀 구성원들을 이끌고 다른 이해관계자들이 소프트웨어 제품을 살펴보고 참가자들이 결함에 대해 질문하고 의견을 내는 안전 점검의 한 형태다.
  • 기술 검토는 자격을 갖춘 인력으로 구성된 팀이 소프트웨어 제품이 의도한 용도에 적합한지 검사하고 규격과 표준과의 불일치를 확인하는 안전 점검의 한 형태다.

공식 및 비공식 리뷰

"형식성"은 활동이 합의된 (서면) 규칙에 의해 지배되는 정도를 나타낸다. 소프트웨어 검토 프로세스는 형식적인 스펙트럼 전반에 걸쳐 존재하며, 스펙트럼의 한쪽 끝을 향한 "버디 점검"과 같은 비교적 구조화되지 않은 활동과, 워크스루, 기술 검토, 소프트웨어 검사와 같은 보다 공식적인 접근방식이 있다. IEEE 규격 1028-1997은 소프트웨어 감사와 함께 마지막 세 가지("공식 안전 점검") 각각에 대한 공식 구조, 역할 및 프로세스를 정의한다.[1] IEEE 1028-1997은 IEEE 1028-2008에 의해 계승되었다.[3]

연구 연구는[who?] 공식적인 리뷰가 비공식 리뷰보다 비용 효과 면에서 훨씬 뛰어나다는 결론을 뒷받침하는 경향이 있다. 비공식적인 검토는 불필요하게 비용이 많이 들 수 있으며(초점 부족으로 인한 시간 낭비 때문에) 자주 보안의식을 제공하는데, 이는 비교적 적은 수의 실제 결함으로 인해 상당히 정당화되지 않는다.

IEEE 1028 공식 검토를 위한 일반적인 프로세스

IEEE 규격 1028은 "공식" 검토에 대한 공통적인 활동 집합을 정의한다(특히 소프트웨어 감사에 대해 일부 변형과 함께). 활동의 순서는 주로 마이클 페이건이 IBM에서 처음 개발한 소프트웨어 검사 과정을 바탕으로 한다.[4] 다양한 유형의 검토가 가혹함의 정도에 따라 이 구조를 적용할 수 있지만, 모든 활동은 검사를 위해 필수적이다.

  • 0. [진입 평가]: 검토 리더는 성공적인 검토를 위해 최적의 조건이 존재하는지 확인하기 위해 입력 기준의 표준 체크리스트를 사용한다.
  • 1. 경영준비: 책임 있는 경영진은 검토가 직원, 시간, 자료 및 도구로 적절하게 재조달되고 정책, 표준 또는 기타 관련 기준에 따라 수행되도록 보장한다.
  • 2. 검토 계획: 검토 리더는 검토의 목적을 확인하거나 확인하고, 검토팀을 구성하며, 검토 수행에 필요한 모든 자원을 팀이 갖추어지도록 한다.
  • 3. 검토 절차 개요: 검토 책임자 또는 다른 자격을 갖춘 사람은 모든 검토자가 검토 목표, 검토 절차, 이용할 수 있는 자료 및 검토 수행 절차를 이해하도록 (필요하다면 회의에서) 보장한다.
  • 4. [개별] 준비: 검토자들은 검토 대상 업무의 성격과 목표에 따라 달라질 「어노미」(잠재적 결함)에 대해 면밀하게 검토하여 개별적으로 그룹 심사를 준비한다.
  • 5. [그룹] 검사: 검토자는 계획된 시간에 만나 준비 활동의 결과를 취합하고 검토 중인 문서(또는 활동)의 상태에 대한 합의에 도달한다.
  • 6. 재작업/추적: 작업 산출물의 작성자(또는 다른 지정인)는 결함 수리에 필요한 조치를 취하거나 시험 회의에서 합의된 요건을 충족한다. 검토 리더는 모든 조치 항목이 마감되었는지 검증한다.
  • 7. [평가 종료]: 검토 리더는 성공적인 검토에 필요한 모든 활동이 수행되었고 검토 유형에 적합한 모든 산출물이 완료되었는지 검증한다.

리뷰의 가치

소프트웨어 검토(특히 공식적인 검토)의 가장 분명한 가치는 시험이나 현장 사용("결함 감지 프로세스")[citation needed]으로 파악될 문제보다 더 일찍, 그리고 더 저렴하게 문제를 식별할 수 있다는 것이다. 잘 전도된 검토에 의한 결함의 발견 및 고치는 비용은 시험실행이나 현장에서 동일한 결함을 발견한 경우보다 1~2회 정도 적은 순서가 될 수 있다.[citation needed]

두 번째, 그러나 궁극적으로 더 중요한 소프트웨어 검토의 가치는 매우 낮은 결함 문서의 개발에서 기술 저자를 양성하는 데 사용될 수 있으며 결함을 조장하는 공정의 부적절성("결함 방지 프로세스")을 확인하고 제거하는 데 사용될 수 있다는 것이다.

특히 작업이 완료될 때까지 기다리지 않고 작업 샘플에 대해 조기에 그리고 자주 수행되는 경우 안전 점검의 경우가 이에 해당한다. 소규모 작업 샘플에 대한 초기 및 빈번한 검토는 저자의 작업 프로세스에서 체계적인 오류를 확인할 수 있으며, 이는 추가적으로 잘못된 작업이 이루어지기 전에 수정할 수 있다. 이러한 저자 기술 향상은 고품질의 기술 문서를 개발하는 데 걸리는 시간을 획기적으로 단축할 수 있으며, 다운스트림 프로세스에서 문서를 사용하는 데 있어 오류율을 획기적으로 줄일 수 있다.

일반적인 원칙으로서, 기술 문서가 조기에 작성될수록, 기술 문서가 하류 활동과 그 작업 제품에 미치는 하자의 영향은 더 클 것이다. 따라서 마케팅 계획, 계약, 프로젝트 계획, 일정 및 요구사항 명세와 같은 문서의 초기 검토에서 가장 큰 가치가 창출될 것이다. 연구자들과 실무자들은 버그와 보안 문제를 발견하는데 있어서 검토 과정의 효과를 보여주었다.[5]

참고 항목

참조

  1. ^ a b IEEE 규격 . 1028-1997, "IEEE Standard for Software Reviews", 조항 3.5
  2. ^ Wiegers, Karl E. (2001). Peer Reviews in Software: A Practical Guide. Addison-Wesley. p. 14. ISBN 0201734850.
  3. ^ "IEEE Standard for Software Reviews and Audits". IEEE STD 1028-2008: 1–53. 2008-08-15 [2008]. doi:10.1109/IEEESTD.2008.4601584. ISBN 978-0-7381-5768-9.
  4. ^ Fagan, Michael E: "Design and Code Inspections to Reduce Errors in Program Development", IBM Systems Journal, Vol. 15, No. 3, 1976; "Inspecting Software Designs and Code", Datamation, October 1977; "Advances In Software Inspections", IEEE Transactions on Software Engineering, Vol. 12, No. 7, July 1986
  5. ^ 찰스 P.Pfleeger, Shari Lawrence Pfleeger. 컴퓨팅의 보안. 제4판. ISBN 0-13-239077-9