협력적인 구현

1. 협력적인 개발 방법의 개요
2. 짝 프로그래밍
3. 형식적인 정밀 검사
4. 다른 종류의 협력적인 개발 방법

1. 협력적인 개발 방법의 개요
"협력 구현"은 짝 프로그래밍, 형식적인 정밀 검사, 비형식적인 기술적 검토, 문서 읽기뿐만 아니라 개발자들이 코드 작성과 제품 개발에 관련된 다른 작업에 대한 책임감을 공유하기 위한 다른 기법들을 가리킨다.

1.1 다른 품질 보증 기법을 보완하는 협력적인 구현.
ㅇ 협력적인 구현의 목적은 소프트웨어의 품질을 향상시키는 것이다.
ㅇ 협력적인 구현의 부차적인 혜택은 개발 시간이 줄어든다는 점이다.
ㅇ 짝 프로그램의 연구 사례.
 0. IBM은 한 시간의 정밀 검사가 약 100시간의 관련 작업(테스트와 결함 수정)을 예방한다는 것을 발견.( Holland 1999)
 0. Reytheon은 정밀 검사에 초점을 맞춘 개발을 통해서 결함 수정(재작업) 비용을 프로젝트 총 비용의 40%에서 20% 줄였다.( Haley 1996)
 0. Hwelett-Packard는 정밀 검사 프로그램이 연간 2150만 달러의 비용을 절감( Grady and Van Slack1994)
 0. Imperial Chemical Industries는 약 400개의 프로그램에 대한 포트폴리오의 유지 비용이 정밀 검사를 하지 않는 프로그램 유지 비용의 10% 수준이라는 것을 발견하였다.( Gilb and Graham 1993)
 0. 큰 프로그램들에 대한 한 연구는 정밀 검사에 1시간을 투자하면 평균 33시간의 유지 보수 작업을 줄일 수 있으며, 테스트보다 20배 이상 효율적이라는것을 발견( Russell 1991)
 0. 한 소프트웨어 유지 보수 조직에서는 코드 검토를 도입하기 전에는 한 줄을 유지 보수하는데 55% 정도가 잘못되었지만, 검토를 도입한 후에는 2% 정도가 잘못되었다.( FreeDman 과 Weinberg  1990)
 0. 같은 사람들에 의해서 개발된 11개의 프로그램이 모두 제품으로 출시되었다. 처음 다섯 개의 제품은 검토 없이 개발되었고 100줄의 코드당 평균 4.5개였다. 나머지 6개의 제품은 정밀 검사를 했으며 100줄의 코드당 평균적으로 오류가 0.82 검토를 통해서 80%정도의 오류에 대해 제거 효과가 있다.(FreeDman 과 Weinberg 1990 )
 0. 모든 소프트웨어 프로젝트가 99% 이상의 결함 제거율을 달성했으며, 모든 프로젝트가 형식적인 정밀 검사를 사용했다고 보고하였다. 또한 75%이상의 결함 제거율을 달성한 프로젝트는 모두 형식적인 정밀 검사를 사용.( Jones 2000)

1.2 협력적인 구현은 협동 문화와 프로그래밍 경험을 제공한다.
ㅇ 검토는 프로그래머들에게 자신의 코드에 대한 피드백을 제공하는 메카니즘이다.
ㅇ 피드백 뿐만 아니라 주관적인 측면에서 형식 / 주석 / 변수 이름 / 지역 변수와 전역 변수 / 설계 방법 수행하는 행동양식등이 있다.

1.3 공동 소유권을 협력적인 구현의 모든 형태에 적용한다.
ㅇ 공동 소유권을 적용 SVN and CVS 와 같은 Repository 리소스를 공유함으로 여러 가지 혜택을 받을 수 있다.
" 모든 협력적인 구현 기법을 아우르는 기본 개념은 공동 소유이다. 어떤 개발 모델에서는 프로그래머가 자신이 작성한 코드를 소유하고 다른 사람들의 코드를 수정하는데 공식적으로 또는 비공식적으로 제약이 따른다. 공동 소유는 협력 작업, 특히 형상 관리의 필요성을 증가시킨다."
 0. 여러 사람이 코드를 보고 코드를 다루면 코드의 품질이 좋아진다.
 0. 누군가가 프로젝트를 그만두더라도 여러 사람들이 코드에 대해서 잘 알고 있기 때문에 그 충격이 줄어든다.
 0. 모든 프로그래머가 동등하게 버그를 수정할 수 있기 때문에 결함 수정 주기가 전체적으로 짧아진다.

1.4 협력을 구현 전 만큼이나 구현 후에도 적용한다.
ㅇ 측정 / 계획 수립 / 요구 사항 / 아키텍처 / 테스트 / 유지 보수 작업에도 적용된다. 

2. 짝 프로그래밍( Pair Programming )
짝 프로그래밍은 원래 Extreme Programming에 의해서 알려졌지만, 이제는 보다 널리 사용되고 있다.

2.1 짝 프로그랭의 성공 요건
ㅇ 코드 작성 표준으로 짝 프로그래밍을 지원하라.
ㅇ 짝 프로그래밍이 감시가 되지 않도록 하라.
ㅇ 짝 프로그램을 강요하지 마라.
ㅇ 정기적으로 짝과 작업을 교대하라.
ㅇ 짝이 서로의 속도를 맞출 수 있도록 하라.
ㅇ 파트너 모두 모니터를 볼 수 있는지 확인하라.
ㅇ 서로 좋아하지 않는 사람들 짝으로 만들지 말라.
ㅇ 초보자들끼리 짝을 만들지 않는다.
ㅇ 팀의 리더를 선정하라.

2.2 짝 프로그래밍의 혜택
ㅇ 혼자 개발시 보다 개발 압박에서 더 잘 견딘다. 또한 엉성한 코드 발견시 품질 향상을 높일 수 있다.
ㅇ 코드의 가독성과 이해성에서 팀에서 가장 훌륭한 프로그래머의 수준으로 올라가는 경향이 있다.
ㅇ 일정을 단축 시킨다. 짝 프로그래밍은 보다 빠르게 작성하면서 오류는 더 적은 코드를 작성하는 경향이 있다.
ㅇ 협력 문화 보급 / 신참 프로그래머의 교육 / 공동 소유 장려와 같은 협력적인 구현의 모든 혜택 제공한다.

3. 형식적인 정밀 검사
ㅇ정밀 검사는 결점을 발견하는데 있어서 매우 효율적이며, 테스트에 비해서 상대적으로 경제적인 것으로 알려진 검토 방식이다.
ㅇ 형식적인 정밀 검사는 다음과 같다.
 0. 체크 리스트는 과거에 문제가 있었던 영역에 대해 검사자가 관심을 갖도록 한다.
 0. 정밀 검사는 결함의 수정이 아니라 발견에 중점을 둔다.
 0. 검사자는 사전에 정밀 검사 미팅을 준비하고 그들이 발견한 문제점 목록을 준비하여 참석한다.
 0. 명료한 역할이 모든 참석자에게 할당된다.
 0. 정밀 검사의 중개자는 정밀 검사중인 제품의 작성자가 아니다.
 0. 중개자는 정밀 검사의 중개를 위한 특정한 훈련을 받는 사람이다.
 0. 정밀 검사 미팅은 모든 참석자가 적당하게 준비한 경우에만 개최된다.
 0. 데이터는 정밀 검사에서 모아지며 결과를 향상시키기 위해서 다음 번 정밀 검사에 제공된다.
 0. 프로젝트 일정이나 경영자 관련 사항들을 정밀 검사하지 않는다면, 일반 경영자는 정밀 검사 미팅에 참석하지 않는다. 기술 전문가는 참석한다.

3.1 정밀 검사로부터 어떤 결과를 기대할 수 있는가
ㅇ 평균 60%의 결함을 찾아 낼 수 있으며, 프로토파이핑과 대량 베타 테스트 이외의 다른 기법들 보다 높은 수치이다.
ㅇ 설계 정밀 검사와 코드 정밀 검사를 조합하면 일반적으로 한 제품에 있는 결함 중에서 70~85%, 또는 그 이상을 제거하는 효과를 가진다.
ㅇ 정밀 검사는 잠재적으로 오류를 내포하고 있는 클래스를 초기에 규명한다.
ㅇ 설계자와 코드 작성자는 정밀 검사에 참여하여 자신의 업무를 향상시키는 방법을 배워야 한다. 정밀 검사는 생산성을 20%정도 높이는 효과를 가진다.
ㅇ 한 프로젝트에서 설계와 코드에 대한 정밀 검사를 수행한다면 프로젝트 예산의 10~15%정도의 비용을 차지할 것이다. 이는 전체 프로젝트 비용을 줄여주는 효과를 가진다.

3.2 정밀 검사에서의 역할
ㅇ 중개자
 0. 정밀 검사의 진행 속도를 충분히 생산적일만큼 빠르고 가장 많은 오류를 찾을 수 있는 만큼 유지하는 역할을 담당
 0. 중개자는 기술적으로 유능해야 한다.
 0. 정밀 검사를 받고 있는 설계나 코드에 대한 전문가일 필요는 없다. 단, 세부사항에 대해서는 이해할 수 있어야 한다.
 0. 검토될 설계나 코드의 분배, 정밀 검사 항목의 분배, 회의실 준비, 정밀 검사 결과 보고, 정밀 검사 회의에서 진행된 지난 회의록 검토와 같은 정밀 검사의 다른 측면들을 관리한다.

ㅇ 작성자
 0. 설계나 코드를 작성한 사람은 정밀 검사에서는 비교적 역할이 작다.
 0. 정밀 검사의 목표 중 일부는 설계나 코드가 분명한지를 확인하는 것이다.
 0. 만약 설계나 코드가 분명하지 않은 것으로 밝혀지면, 작성자에게 설계나 코드를 분명히 하기 위한 일이 할당될 것이다. 혹은 분명하지 않은 설계나 코드 부분을 설명하고 오류처럼 보이는 것들이 실제로는 타당한 이유에 대해서 설명해야 한다.
 0. 프로젝트 검토자에게 낯설다면, 정밀 검사 미팅을 위해서 프로젝트의 개요를 설명해야 할 것이다.
ㅇ 검토자
 0. 검토자는 설계나 코드에 대해서는 관심이 있지만 작성자는 아닌 사람이다.
 0. 설계의 검토자는 아마도 설계를 구현할 프로그래머일 것이다.
 0. 검토자의 역할은 결함을 찾는 것이다.
 0. 보통 준비 단계와 설계나 코드가 정밀 검사 회의에서 논의될 때 결함을 발견하고, 전체적으로 볼 때 상당히 많은 결함을 발견한다.
ㅇ 서기
 0. 발견된 오류와 정밀 검사 회의 중에 있었던 조치 항목들을 기록한다. 작성자나 중개자는 서기가 될 수 없다.
ㅇ 경영자
 0. 정밀 검사에 경영자는 참여하는 것은 일반적으로 좋은 생각이 아니다. 순수한 기술적 검토라는 점에 유의하자.
 0. 경영자가 참여하면 사람들의 반응이 달라진다. 검토를 하는 대신 평가를 받고 있다는 점을 들고 있다. 이렇게 되면 기술적보다 정책적인 부분에 관심이 쏠린다.
 0. 허나 경영자는 정밀 검사의 결과를 알아야 할 권한이 있고, 경영자가 알 수 있도록 정밀 검사 보고서를 준비하자.
ㅇ 성능 평가는 완성되지 않은 작업이 아니라 완성된 제품에 기반을 두어야 한다.
ㅇ 인원 : 참여자는 3명 이상으로  중개자 / 작성자 / 검토자 역활이 중복이 되어서도 안되고, 6명으로 추천할 만한다.

3.3 정밀 검사의 일반적인 절차
정밀 검사는 여러 가지의 단계로 구성된다.
ㅇ 계획 
 0. 작성자는 설계나 코드를 중개자에게 전달한다.
 0. 중개자는 누가 검토할 것인지와 언제 어디서 정밀 검사 회의를 진행할 것인지를 결정한다.
 0. 중개자는 설계나 코드 그리고 정밀 검사의 관심을 끄는 체크 리스트를 분배한다. 
 0. 내용물은 회의 진행 시 오류를 빠르게 찾을 수 있도록 줄 번호와 함께 출력되어야 한다.
ㅇ 개요
 0. 작성자가 설계나 코드가 작성된 기술적인 환경을 한시간 정도 설명할 수 있다.
 0. 개요를 설명하게 되면 설계나 코드에서 분명하지 않은 사항들을 속일 수 있기 때문에 위험한 습관이다.
 0. 설계나 코드는 스스로를 말해야 한다.
ㅇ 준비
 0. 검토자는 설계나 코드에 오류가 있는지를 정밀하게 조사하기 위하여 혼자 일한다.
 0. 검토자는 검토의 대상이 되는 사항들을 살펴보기 위해서 체크 리스트를 사용한다.
{{{
ㅇ 응용프로그램은 시간당 500줄 / 시스템 코드 검토는 시간당 125줄 코드만 준비한다.
ㅇ 가장 효과적인 비율은 매우 다양하기 때문에, 가장 효율적인 비율을 결정하기 위해서 여러분이 속한 분비율을 기록하도록 한다.
ㅇ 검토자마다 특정한 관점이 주어졌다면 검사가 보다 효율적으로 검토 할 수 있다.
}}}
ㅇ 정밀 검사 회의
 0. 중개자는 설계를 설명하거나 코드를 읽기 위해서 작성자 이외의 누군가를 선택한다.
 0. 논리적인 구조의 세부 항목을 포함한 모든 논리 구조가 설명된다.
 0. 회의중 해결책을 논의하지 않는다. 그룹은 결함을 식별하는데 초점을 두고 진행한다.
ㅇ 검사 보고
 0. 중개자는 결함의 유형과 정도를 포함하여 결함을 나열하는 검사 보고서를 작성한다.
 0. 모든 결함의 수정을 돕고, 조직에 중요한 문제를 강조하는 체크 리스트를 만들기 위해 사용이 되어 진다.
ㅇ 수정
 0. 중개자는 결함을 수정하기 위해서 누군가에게 할당한다.(작성자에게) 결함을 할당 받은 사람은 목록에 있는 결함을 해결하도록 노력한다.
ㅇ 후속조치
 0. 중개자는 할당된 모든 작업에 대해 지켜볼 책임이 있다.
 0. 오류 정도에 따라 검토자가 전체 제품을 다시 검사하거나 검토자가 수정된 부분만 다시 검사하거나, 또는 작성자가 별도의 후속 조치 없이 오류를 완료하도록 하는 후속 조치를 취해야 한다.
ㅇ 추가회의
 0. 정밀 검사를 진행하는 중에 참여자들이 제기된 문제에 대한 해결책을 논의할 수 없을지라도 누군가를 그렇게 하고 싶어할 것이다.
 0. 공식적인 검사가 끝나고 난후 관심 있는 사람들이 해결책을 논의할 수 있도록 비형식적인 추가 회의를 열 수 있다.

3.4 정밀 검사에서의 자존심
ㅇ 요점은 설계나 코드를 작성한 사람을 비판해서는 안된다는 것이다. 이로인해 프로그램 개선에 대한 확신과 무언가에 배울 수 있는 경험이 긍정적인 효과를 가져온다.
ㅇ 작성자는 실제로 결함이 아닌 결함들과 논쟁의 여지가 있는 결함들에 대한 비평을 듣기 위해서 참여해야 한다.
ㅇ 작성자는 작업에 대해 방어를 하려고 해서는 안된다. 검토가 끝나고 나서 작성자의 개인적으로 각각의 결점에 대해서 생각하고 그것이 타당한지를 결정할 수 있다.

3.5 정밀 검사와 Code Complete
{{{
책의 예로 출판을 하기 위해 초안을 작성하고 오류를 수정하였다. 그리고 나서 검토를 하기 위해 12명의 동료들에게 개정된 장을 유포하였으며, 마지막으로 원고를 출판사에 제출했다. 그리고 출판사에서 원고 정리 및 검토를 하였다. 이후에 독자들로부터 오류 200개를 보내어 받았다.
}}}

3.6 정밀 검사 요약
ㅇ 규격화된 체크 리스트와 규칙들이 있기 대문에 정밀 검사 진행 과정은 체계적이다.
ㅇ 체크 리스트를 개선하고 준비 작업과 정밀 검사율을 검토하기 위해서 형식적인 피드백 과정을 사용하기 때문에 스스로 최적화된다.
ㅇ 소프트웨어 공학 연구소( Software Engineering Institue, SEI)는 역량 성숙도 모델(Capability Maturity Model, CMM)을 정의하였다.

4. 다른 종류의 협력적인 개발 방법
협력 작업은 워크-쓰루(work-throughs), 코드 읽기, 프리젠테이션(dog-and-pony shows)이 있다.

4.1 워크-쓰루(work-throughs)
 0. 개괄적인 검토로 인기 있는 검토 방법이다.
 0. 설계는 코드에 대해서 논의하는 두 명 이상의 사람이 참여한다.
 0. 화이트보드 주위에서 즉석으로 토론하는 방식
 0. 기술 부서에 의해서 준비된 프리젠테이션으로 회의를 진행하고 결론을 경영진에게 전달하는 것처럼 공식적으로 보인다.
 0. 세부사항은 다음과 같다.
   - 워크-쓰루는 일반적으로 검토중에 있는 코드나 설계의 작성자에 의해서 진행되고 조절된다.
   - 워크-쓰루는 기술적인 문제에 초점을 맞춘다. 즉, 워크-쓰루는 업무 회의이다.
   - 모든 참석자는 설계나 코드를 읽고 오류를 찾음으로써 워크-쓰루를 준비한다.
   - 워크-쓰루는 수석 프로그래머가 신입 프로그래머에게 자신의 경험과 협력 문화를 전달할 수 있는 기회 제공
   - 워크-쓰루는 일반적으로 30 ~ 60분 동안 진행
   - 오류에 대한 수정이 아니라 발견을 중시한다.
   - 경영진은 참여치 않는다.
   - 워크-쓰루 개념은 유연하며, 조직이 사용하는 특정한 요구에 맞게 수정될 수 있다.
 0. 부정적인 측면은 다음과 같다.
   - 지나치게 많은 비용이 든다.
   - 프로젝트를 진행하는 사람들에게 워크-쓰루 기법을 지속적으로 적용하라고 하기는 어려우며, 프토젝트의 압박이 증가하여 결국 불가능하다는것을 발견한다.
   - 검토함으로써 얻게 되는 결과가 형식적인 정밀 검사의 오버헤드를 정당화하지 못한다면, 회의의 오버헤드를 전혀 정당화하지 못한다.

4.2 코드 읽기
ㅇ 코드 읽기는 정밀 검사와 워크-쓰루의 대안이다.
ㅇ 소스코드를 읽고 오류를 찾는 방식으로 설계나 방식 / 가독성 / 유지 보수성 / 효율성과 같이 코드의 질적인 측면에 대해서 이견을 제시한다.
ㅇ NASA 소프트웨어 공학 연구실에서의 연구에서는 코드 읽기가 시간당 3.3개의 결함을 찾는다는것을 발견하였다. 테스트는 약 1.8개의 오류를 발견하였다.
ㅇ 테스트 방법보다 약 20 - 60% 정도 더 많은 오류를 발견하였다.
ㅇ 코드 읽기는 다음과 같이 진행하는 방법이다.
 0. 회의를 준비할 때, 코드의 작성자는 소스 코드를 검토자에게 전달한다. 코드는 1,000 ~ 10,000줄이다. 보통 4,000줄
 0. 두 명 이상의 사람들이 코드를 읽는다. 검토자끼리의 경쟁을 유발하기 위해서 최소 두명이 필요하다. 만약 두 명 이상의 사람을 사용한다면, 여분의 사람들이 얼마나 기여했는지를 알 수 있도록 기여도를 측정한다.
 0. 검토자는 코드를 개별적으로 읽는다. 하루에 약 1,000줄 정도 평가한다.
 0. 검토자는 코드 읽기를 마쳤을 때, 코드 읽기 회의가 작성자에 의해 주최된다. 회의는 한 시간이나 두 시간 정도 진행되며, 검토자들에 의해서 발견된 문제를 집중적으로 다룬다.
 0. 코드 작성자는 검토자에 의해서 규명된 문제를 수정한다.
ㅇ AT&T에서 진행된 13번째 검토 연구 결과에 따르면 검토 회의 자체의 중요성이 지나치게 높다는 것을 발견하였다. 검토 회의를 준비하면서 90% 결함을 발견하였구, 10%만이 검토 자체를 진행하는 중에 발견하였다.

4.3 프리젠테이션(Dog-and-Pony Shows)
ㅇ 프리젠테이션은 소프트웨어 제품을 고객에게 보여주는 검토 방식이다.
ㅇ 기술적인 품질 개선을 위해서는 정밀 검사, 워크-쓰루, 또는 코드 읽기에 의존한다.

4.4 협력적인 구현 기법의 비교