소프트웨어 피어 리뷰
Software peer review| 다음에 대한 시리즈 일부 |
| 소프트웨어 개발 |
|---|
소프트웨어 개발에서 동료 검토는 작업 제품의 기술적 내용과 품질을 평가하기 위해 작업 제품(문서, 코드 등)을 저자의 동료가 검토하는 소프트웨어 검토의 일종이다.null
목적
안전 점검의 목적은 역량 성숙도 모델에 따라 "소프트웨어 아티팩트의 결함을 감지하고 수정하며, 현장 운영으로 유출되는 것을 방지하기 위한 절제된 엔지니어링 관행"을 제공하는 것이다.null
각 소프트웨어 개발 프로세스 활동의 일부로 수행될 때 안전 점검은 라이프사이클 초기에 해결할 수 있는 문제를 식별한다.[1]즉, 요구사항 분석 활동 중 요구사항 문제를 식별하는 안전 점검은 소프트웨어 아키텍처 또는 소프트웨어 테스트 활동보다 더 저렴하고 쉽게 해결할 수 있다.null
국가 소프트웨어 품질 실험은 안전 점검의 효과를 평가하면서 "[2]소프트웨어 검사에 대한 투자 수익률이 유리하며, 절감액은 4 대 1의 비용을 초과한다"고 밝혔다.달리 말하면, 소프트웨어 문제를 나중에 확인하고 수정하는 것은 평균적으로 4배의 비용이 든다.null
다른 유형의 소프트웨어 검토와의 차별성
동료 검토는 동료가 아닌 경영 대표가, 기술평가보다는 관리·통제 목적으로 실시하는 경영검토와는 구별된다.또한, 규격, 표준, 계약서 계약서 또는 기타 기준의 준수를 평가하기 위해 프로젝트 외부의 인력에 의해 실시하는 소프트웨어 감사 검토와도 구별된다.null
프로세스 검토
안전 점검 프로세스는 형식적인 스펙트럼 전반에 걸쳐 존재하며, 주파수 한쪽 끝을 향한 "버디 점검"과 같은 비교적 구조화되지 않은 활동과 보행시선, 기술 안전 점검 및 소프트웨어 검사와 같은 더 비공식적인 접근 방식이 있다.IEEE는 마지막 세 가지 각각에 대해 공식적인 구조, 역할 및 프로세스를 정의한다.[3]null
경영진은 특정한 기술적 전문지식으로 인해 포함되거나 검토 중인 작업 산출물이 경영진 수준 문서인 경우를 제외하고 일반적으로 안전 점검 수행에 관여하지 않는다.이것은 특히 검토에 참여한 다른 참가자들의 라인 매니저들에게 해당된다.null
소프트웨어 검사와 같은 공식적인 안전 점검 프로세스, 각 참가자에 대한 특정 역할 정의, 진입/출구 기준의 단계 수량화, 안전 점검 프로세스에 대한 소프트웨어 메트릭스 캡처.null
"오픈 소스" 리뷰
자유/오픈 소스 커뮤니티에서는 컴퓨터 소프트웨어의 엔지니어링과 평가에서 동료 검토와 같은 일이 일어났다.이런 맥락에서, 동료 검토의 근거는 라이너스의 법칙에 상당하는 것으로, 흔히 "안구를 충분히 주면, 모든 버그는 얕다"라고 표현하는데, 이는 "검토자가 충분하다면, 모든 문제를 해결하기 쉽다"는 뜻이다.에릭 S. Raymond는 소프트웨어 개발의 동료 검토에 대해 영향력 있는 글을 썼다.[4]null
참조
- ^ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 261. ISBN 978-0-470-04212-0.
- ^ 국가 소프트웨어 품질 실험 리소스 및 결과
- ^ IEEE 규격 1028-2008, "IEEE 소프트웨어 검토 및 감사 표준"
- ^ Eric S. Raymond. "The Cathedral and the Bazaar".
{{cite journal}}:Cite 저널은 필요로 한다.journal=(도움말)
