소프트웨어 공학 (Software Engineering ) 계획 (Planning) 문양세 강원대학교 IT 대학 컴퓨터과학전공

1. 소프트웨어 공학 (Software Engineering) 계획 (Planning) 문양세 강원대학교 IT대학 컴퓨터과학전공

2. In this chapter … (1/2) 계획 (Planning) • 소프트웨어 공학의 계획을 논하기에 앞서서… • 만사에 있어서 계획이 없으면 이룰 것이 없다. • 많은 계획들 중에 있어서도 가장 중요한 계획은 자기 자신 인생의 장중단기 계획이다. • 사랑하는 학생 여러분 가슴에 손을 올리고 생각해 보세요. • 나는 10년 후에 무엇이 되고 싶은가?  장기 계획 • 10년 후를 위해서, 올 한해 나는 무엇을 추구하고 달성할 것인가?  중기 계획 • 올 한해 목표를 달성하기 위해서, 나는 이달에, 오늘 무엇을 해야 하나?  단기 계획  그래 고민되니까 오늘까정만 술 한잔?

3. In this chapter … (2/2) 계획 (Planning) • 소프트웨어 공학에서의 계획이란, • 개발하고자 하는 문제에 대한 정확한 이해 및 정의를 하고, • 여러 가지 필요한 작업들을 도출하고, 그 작업들의 순서를 결정하며, • 어떻게 개발해 나갈 것인지 일정을 계획하며, 이에 따른 비용을 추정하는 것이다. • 그리고, 궁극적인 결과(output)로는 계획서를 작성하는 것이다. • We will cover … • 프로젝트 관리 • 문제의 정의 • 노력 추정 • 일정 계획 • 위험 분석 • 계획서 작성

4. In this chapter … 계획 (Planning) 프로젝트 관리 3.1 문제의 정의 3.2 노력 추정 3.3 일정 계획 3.4 조직 계획 3.5 위험 분석 3.6 계획서 작성

5. 프로젝트 관리 (Project Management) 계획 (Planning) 프로젝트 관리란?소프트웨어 프로젝트를1) 조직하고(organizing) – 어떠한 일이 있는지 파악하여, 관련 사람들을 어떻게 끌어 모으고,2) 계획하고(planning) – 어떠한 일정으로 얼마의 비용으로 어떻게 사람을 넣어서 진행하며,3) 일정관리(scheduling)하는 것이다. – 잘 진행되는지 항시 점검하고 피드백하는 것이다.

6. 프로젝트 관리의 중요성 계획 (Planning) • 수입과 지출에 직결되는 경제 관련 작업(economic activity) • 기술 외적인 부분(경영, 경제)이 많음 • 기술력 최고? 이것보다는 적기에, 쓸만한 것을, …  온라인 게임 열풍, 앵그리버드, 애니팡 • 관리가 잘된 프로젝트도 실패하는 경우가 있음관리가 잘 안 되는 프로젝트는 실패로 끝날 가능성이 많음 • 결과적으로, 프로젝트에 있어서 관리는 필수적 개념임 • 그래서, 아무리 잘난 사람이 많아도 조직에는 과장, 팀장, 부장이 존재하는 것임 • 관리 작업에 대한 방법을 일부 이론적으로 다룸 • 관리를 실제 배우는 일은 현장감이 중요 • 관리에, 특히 인간 관리에 정도는 없음  경험을 바탕으로 융화할 수 있어야

7. 계획 (1/2) 계획 (Planning) • 계획의 부재 • 불확실성  중간에 무엇을 하고 있는지, 어디까지 되어가는지 파악할 길이 없음 • 일정의 차질, 경비의 초과, 저품질, 높은 유지보수 비용 • 위험 (risk) • 결과적으로는… 프로젝트의 실패 • 소프트웨어 프로젝트 계획 수립“소프트웨어 개발 과정과 일정, 비용, 조직, 생산 제품에 대하여 사전에 계획” • 문제를 이해하고 정의 • 필요한 소작업(activity)을 정의하고 순서를 결정 • 일정 예측 • 비용 예측 • 위험 분석 계획서 작성

8. 계획 (2/2) 계획 (Planning) • 계획 수립의 결과 소프트웨어 개발 계획서 • 사업관리자, 개발자, 사용자들에게 사업의 범위, 필요 비용, 필요 자원, 개발 일정, 위험 요소 등에 대한 정보를 제공하는 산출문서(deliverable) • 주의할 점 • (계획자는) 시스템에 대한 충분한 이해가 있어야 함, 그러나 변경의 여지도 있음 • 현실적, 구체적 계획  보여주기 위한 계획이 아닌 실질적인 계획 • 득실 관계 저울질 기간 vs. 비용 • 기술적인 측면 고려  제품의 난이도, 투입 엔지니어의 능력

9. In this chapter … 계획 (Planning) 프로젝트 관리 3.1 문제의 정의 3.2 노력 추정 3.3 일정 계획 3.4 조직 계획 3.5 위험 분석 3.6 계획서 작성

10. 문제의 인식 • 문제 범위와 원인 파악 기본 요건 분석 • 문제를 둘러싼 조직, 제도, 시설, 인원, 기술에 관한 현황 파악 시스템 조사 및 정보 수립 • 현재의 시스템 조사, 업무 흐름 정책 등을 파악 • 면담과 서류로 심층 분석 (고객 상담, 현업의 분석, 작업의 체험) 현 시스템의 이해 • 목표 시스템의 정의 신규 시스템의 정의 문제 정의 (1/2) 계획 (Planning) 문제의 이해:대상 업무나 문제를 사용자가 이해하는 용어로 정확히 기술한 것(개발자가 아닌 고객의 관점에서 정확히 기술해야 함)

11. 문제 정의 (2/2) 계획 (Planning) • 문제를 정의한 후에는 해결 방법에 대한 대책을 수립함 • 신규 시스템의 목표 설정  기능과 우선순위 (투자 효과를 분석) • 해결 방안 모색(사용자 요구, 개발 여건, 기술적 능력 고려) • 문제(개발 시스템)의 정의 요소 • 문제의 기술 (교수용 온라인 게임을 만든다.) • 시스템의 필요성 (교수들도 가끔 즐길 권리가 있다.) • 시스템의 목표 (전국 교수들을 모두 매혹시킨다.) • 제약 사항 (근데, 컴퓨터를 다룰 줄 모르는 분은 불행히 제외한다.) • 시스템의 제공 기능 (3D와 FullHD는 기본이고, 사운드는 5.1 채널 지원이다.) • 사용자의 특징 (애덜이 아니라 대부분 중년이다.) • 개발, 운용, 유지보수 환경 (전화 Claim이 비교적 많을 것이니, ARS 응대가 필요하다.)

12. 타당성 분석 (Feasibility Analysis) 계획 (Planning) • 경제적 타당성 • 투자 효율성 ( 본전은 뽑을 수 있어야 …, 본전은 뽑지 못해도, 고객은 확보해야 …) • 시장성 ( 판매가 가능하고, 시장이 열려 있어야…) • 비용과 수익의 비교 • 기술적 타당성 (사용자 요구 기능 및 성능 vs. 제공 가능성) • 사례 연구 (case study) • 실패 사례 연구 실패는 성공의 어머니, 他山之石 (타산의 아무 쓸모 없는 돌도 다듬으면 옥…) • 모의 실험 (simulation) • 프로토타이핑 • 법적 타당성 • 사용 도구들의 법적 권한  1000억짜리 (불법) 툴을 사용하여 하루에 끝내자.  Oh! No. • 시장, 관행들에 대한 조사 아무 메일이나 잡아내는 소프트웨어를 개발하자.  Oh! No.

13. In this chapter … 계획 (Planning) 프로젝트 관리 3.1 문제의 정의 3.2 노력 추정 3.3 일정 계획 3.4 조직 계획 3.5 위험 분석 3.6 계획서 작성

14. 노력 추정이란? 계획 (Planning) • 얼마나 노력이 들어가느냐, 결국 개발 비용을 추정하는 것이다. • 소프트웨어 개발 비용 예측 • 정확한 비용 예측은 매우 어려움 • 알려지지 않은 요소가 산재  에러 발생, 성능 저하, 엔지니어의 이직, … • 원가의 계산이 어려움 (결국, 인건비인데, 이것 자체의 추정이 어려움) • 과거의 (경험적) 데이타가 필요 • 단계적 비용 산정 방법도 사용 (초기 10억원, 프로토타입 이후 11.5억원 등) • 예산 • 인건비: MM(인원/월)를 기초  관리자를 포함한 엔지니어의 인건비를 의미함 • 경비: 여비, 인쇄비, 재료비, 회의비, 공공요금 • 간접 경비: 오버헤드(overhead)  회사에는 회계, 기획, 경영 등 많은 파트가 있음

15. 비용에 영향을 주는 요소 계획 (Planning) • 제품의 크기 • 제품의 크기가 커짐에 따라 비용은 기하급수로 늘어남  분산, 병렬 시스템의 예 • 제품의 복잡도 • 응용 : 개발지원 : 시스템 = 1 : 3 : 9 • 프로그래머의 자질 • 코딩, 디버깅의 능력차 • 프로그래밍 언어, 응용 친숙도 • 요구되는 신뢰도 수준  MTBF(mean time between failure) • 기술 수준(개발 장비, 도구, 조직능력, 관리, 방법론 숙달) • 남은 시간 • Putnam “프로젝트의 노력은 남은 개발 기간의 4제곱에 반비례” 2달 남았으면 1/24 = 1/16, 1달 남았으면 1이 필요…

16. MTBF 제안 예제 계획 (Planning)

17. 프로젝트 비용을 예측하는 방법 계획 (Planning) • 상향식 (Bottom-up) • 소작업에 소요되는 기간을 구하고,여기에 투입되어야 할 인력과 투입 인력의 참여도를 곱하여 최종 인건 비용을 계산 • 장점: 소작업에 드는 노력을 일일이 계획할 수 있음 • 단점: 개인의 주관에 의한 추정이 될 가능성이 많음 • 하향식 (Top-down) • 프로그램의 규모를 예측하고 과거 경험을 바탕으로 예측한 규모에 대한 소요 인력과 기간을 추정 • 프로그램의 규모 • LOC (Lines of code) • 기능 점수 (Function Point)  총 몇 라인이니까, 혹은 어떤 기능이 있으니까 얼마 정도가 들 것이다라고 예측함

18. COCOMO 방법 (1/4) 계획 (Planning) • 개요 (위키) • B. Boehm이 1981년에 제안한 Constructive Cost Model이다. • 주로 2K-32K 라인 규모의 많은 프로젝트의 기록을 통계 분석하여 얻은 결과로서, 중소규모 프로젝트의 추정에 적합하다. • 완성될 규모의 LOC(lines of code)를 추정하고, 이를 준비된 식에 대입하여 소요 MM을 예측한다. • 소프트웨어 공학 기술의 발전과 더불어 초기 COCOMO 모델은 1995년에 COCOMO II로 확장되었다.

19. COCOMO 방법 (2/4) 계획 (Planning) 표준 산정 공식 • 용어 • KDSI: Kilo Delivered Source Instruction  입력 값으로 추정치에 해당함(LOC: Lines of code  1 KDSI = 1,000 LOC) • PM: Programmer-Month • TDEV: Total development time  궁극적으로 파악해야 하는 값

20. COCOMO 방법 (3/4) 계획 (Planning) • 유형 설명 • 단순형: 소규모 팀이 개발하는 잘 알려진 응용 시스템으로, 일괄 자료 처리, 과학 기술 계산, 비즈니스 자료 처리 등 5만 라인 이하 규모 • 중간형: 중규모 팀이 개발하는 소프트웨어 시스템으로, 트랜잭션 처리, 운영체제, DBMS 등 30만 라인 이하 규모 • 임베디드형: 하드웨어가 포함된 실시간 시스템, 미사일 유도, 신호기 제어 시스템 • 예제: CAD 시스템 • 예상 규모: 33,360 LOC  중간형 • PM = 3.0 x (KDSI)1.12 = 3.0 x (33.36)1.12 = 152MM • TDEV = 2.5 x (152)0.35 = 14.5 M • N = PM/TDEV = 152/14.5 ≒ 11명

21. COCOMO 방법 (4/4) 계획 (Planning) 비용 예측 그래프 • 단순히 # of lines에 비례하는 것이 아니라, • 복잡할수록(시스템이 커질수록) 비례하는 정도가 달라진다.  빨리 증가한다.

22. COCOMO 방법의 보정(Scaling) (1/2) 계획 (Planning) • 기본 방법에 제품의 성격, 목표 시스템의 특성, 개발 구성원의 특성, 프로젝트 자체의 성격 등에 따라 보정한다. • 예를 들어, 프로그램의 경험이 많다면 노력 예측 값은 더 작아져야 하며, • 실시간 처리 요구가 있다면 예측 값은 더 커져야 한다. 노력 승수: 여러 조건을 고려하여 기본 방법에 곱하는 상수 값 • 노력 승수에 영향을 미치는 요소 • 제품의 특성: 신뢰성에 대한 요구나 문제의 복잡도, 데이터베이스의 크기 등 • 컴퓨터 실행: 수행 시간의 제약, 주기억 장치의 제약, H/W 및 S/W의 안전성 등 • 개발자의 특성: 개발자의 응용 분야 경험 유무, 프로그래밍 언어에 대한 익숙도 등 • 프로젝트: 복잡한 소프트웨어 도구 사용이 필요한가?

23. COCOMO 방법의 보정(Scaling) (2/2) 계획 (Planning) 노력 승수 테이블  다음 페이지참조 노력 승수(ki, 1  i n)를 사용하여 보정한 PM 계산 노력 승수를 기본 PM 값에 곱하여 보정된 PM 값을 구한다.

24. 노력 승수 테이블 예제 계획 (Planning)

25. COCOMO 방법의 사용 예제 (1/2) 계획 (Planning) 128,000 LOC 크기인 임베디드형(Embedded)의 예측 • 기본 방법 • PM = 3.6 x (128)1.20 = 1,216 MM(man-months) • TDEV = 2.5 x (1,216)0.32 = 24 개월 • N = 1,216 / 24 = 50.66 ≒ 51명 • 생산성: 128,000/1,216 = 105 LOC/MM  한 달에 105 라인 작성

26. COCOMO 방법의 사용 예제 (2/2) 계획 (Planning) 128,000 LOC 크기인 임베디드형(Embedded)의 예측 (계속) • 보정된 방법 (1.15, 1.56, 0.82 적용 시 예제) • PMscale = 1.15 x 1.56 x 0.82 x PM = 1,789 MM(man-months) • TDEV = 2.5 x (1,789)0.32 = 28 개월 • N = 1,789 / 28 = 50.66 ≒ 63명 • 128,000/1,789 = 72 LOC/MM  한 달에 72 라인 작성

27. COCOMO 방법의 특징 계획 (Planning) COCOMO 모델을 보면, “소요 기간과 소요 인원의 관계는 서로 바꿀 수 있는 관계가 아니다”라는 말을 실증하고 있다. 기간이 먼저 계산되고, 이에 따라서 필요 인원을 파악 “기간이 많이 걸리니 인원을 늘리자”는 잘못된 생각 프로젝트의 규모만 예측될 경우, 인원, 개발 기간 등의 비용을 비교적 정확하게 예측할 수 있다. 반면에, 1) 소프트웨어 제품을 하나의 개체로 보고 전체적인 수식을 계산한다. 실제로는 제품이 훨씬 복잡한 구조를 가지고 있다.2) 계획 단계에 프로젝트의 규모를 정확히 예측하기는 거의 불가능하다.

28. COCOMO II 계획 (Planning) • 1995년에 발표 • 소프트웨어 개발 프로젝트가 진행된 정도에 따라 세 가지의 다른 모델을 제시  각 단계에 따라 다른 계산법을 적용 • 제1단계: 프로토타입을 만드는 단계 • 화면이나 출력 등 사용자 인터페이스, 3 세대 언어 컴포넌트 개수를 세어 응용 점수(application points)를 계산 • 이를 바탕으로 노력을 추정 • 제2단계: 초기 설계 단계 • 자세한 구조와 기능을 탐구 • 제3단계: 구조 설계 이후 단계 • 시스템에 대한 자세한 이해

29. 기능 점수 방법 계획 (Planning) • 기능 점수(function points) • 정확한 라인수는 예측 불가능  COCOMO 적용이 어려움 • 입력, 출력, 질의, 화일, 인터페이스의 개수로 소프트웨어의 규모를 나타냄 • 각 기능에 가중값(표 3.4(p. 120))이 기본이고, 표 3.5(p. 121)은 복잡도에 따라 세분화함) 부여 • 기능 점수 1을 구현하기 위한 LOC • 어셈블리 언어: 324 • C언어: 150 • Pascal: 91 • Ada: 71 • Smalltalk: 21 • 총 라인수= FP x 원하는 언어의 1점 당 LOC • 개발 노력 = 총 라인수/ 생산성(LOC/MM) 일단 총 라인 수를 구하고, COCOMO 등을 사용해 예측할 수도 있다. 이들 고급 언어는 어디로 갔지?

30. 가중값설명 (1/2) 계획 (Planning) 입력 개수: 사용자가 시스템에 제공하는 입력 자료의 개수예: 웹 페이지 작성에 있어서 입력 화면의 개수 출력 개수: 시스템이 사용자에게 제공하는 출력 자료의 개수예: 웹 페이지 작성에 있어서 출력 화면의 개수 질의 개수: 사용자가 제공하는 대화형 질의의 개수예: 검색 화면에서 검색 조건을 주는 방법의 수

31. 가중값설명 (2/2) 계획 (Planning) 파일 개수: 시스템이 저장 및 관리하는 파일의 개수예: 봉급 파일, 주소 파일 인터페이스 개수: 다른 시스템과의 인터페이스 개수예: 은행 봉급 서버는 주소 서버, 고과 서버와 인터페이스 함

32. 복합 가중값설명 계획 (Planning) 기본 가중값을 바탕으로 복잡도를 고려하여, 단순, 보통, 복잡의 세 가지 단계로 구분함 아래 예를 보면, “개수 x 복합 가중값”을 더하여 최종 점수 148을 구한다. 25 LOC/FP인 4세대 언어로 구현하면, 148 x 25=3775 LOC가 된다. 프로젝트 팀의 생산성이 2000 LOC/MM이며, 즉한 달에 한 사람이 2000 라인 작성한다면, 3775/2000 = 1.9MM가 된다.

33. 기능 점수 추정 사례 계획 (Planning)  내용을 Skip함 (교재 사례 예제가 너무 복잡하여 강의에서 제외함)

34. In this chapter … 계획 (Planning) 프로젝트 관리 3.1 문제의 정의 3.2 노력 추정 3.3 일정 계획 3.4 조직 계획 3.5 위험 분석 3.6 계획서 작성

35. 일정 계획 (Scheduling) 계획 (Planning) • 일정 계획:개발 프로세스를 이루는 소작업(activity)를 파악하고, 그 순서와 일정을 정하는 작업 • 개발 모형 결정 (폭포수, 프로토타이핑, …) • 소작업, 산출물, 이정표 설정 • 작업 순서 • 작업 분해: WBS(Work Breakdown Structure) 작성 • CPM(Critical Path Method) 네트워크 작성 • 최소 소요 기간(best case)을 구함 (위험 분석을 위해, worst case도 작성해 본다.) • 소요 MM, 기간 산정하여 CPM 수정 • 간트 차트로 그려, 일정을 구체화 함

36. 작업 분해(Decomposition) 계획 (Planning) • 작업 분해:프로젝트 완성에 필요한 소작업(activity)를 찾아냄 • WBS(Work Breakdown Structure) • 계층적 구조를 가짐 • Activity의 규모를 판별할 수 있음 • 각 노드에 작업 소요일, 책임자 등을표시할 수 있음 • 작업 분해는 일정 계획에앞서서 필요 작업을 찾는데주된 목적이 있음

37. 작업순서 결정 및 소요시간 예측 계획 (Planning) CPM 네트워크 작성을 위해, 우선 각 소작업에 대한 소요 기일을 예측하고, 각 소작업 간의 선후관계를 파악한다. CPM 소작업 리스트 예제

38. CPM 네트워크 (1/2) 계획 (Planning) • CPM 네트워크는 방향성 그래프(directed graph)이다. 그리는 예는, • 노드(node)는 소작업을 표시한다. • 원형 노드: 소작업의 이름과 소요 기간을 기재한다. • 박스 노드: 프로젝트 중간 점검(milestone)을 의미하며, 예상 종료일을 기재한다. • 에지(edge)는 작업 사이의 선후 관계를 표시한다. • CPM 네트워크를 사용하여, 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요기간을 예측하는데 사용된다.

39. CPM 네트워크 (2/2) 계획 (Planning) CPM 네트워크 예제

40. CPM 네트워크에 의한 임계 경로 (1/2) 계획 (Planning) • CPM 네트워크를 사용하여 파악할 수 있는 정보 • 각 작업이 가장 빠르게 시작할 수 있는 시각 (earliest start time) • 각 작업이 최대한 빠르게 끝날 수 있는 시각 (earliest finish time) • 각 작업을 최대로 늦추어 시작할 수 있는 시각 (latest start time) • 각 작업을 최대로 늦추어 끝낼 수 있는 시각 (latest finish time) 작업의 순서는 물론 엔지니어의 적기 투입에 중요한 역할을 한다. • 임계 경로 (critical path) • 프로젝트를 마치는데 있어서 가장 기간을 많이 차지하는 경로 • 임계 경로 내의 작업이 늦어지면 프로젝트 전체 일정이 늦어진다. • 관리자는 임계 경로의 작업에 많은 신경을 써야 한다.

41. CPM 네트워크에 의한 임계 경로 (2/2) 계획 (Planning) 임계 경로 예제

42. CPM 네트워크 특징 계획 (Planning) • 장점 • 관리자의 일정 계획 수립에 도움 • 프로젝트 안에 포함된 작업 사이의 관계를 파악할 수 있음 • 병행 작업 계획  Parallel Processing 가능 • 일정 시뮬레이션 • 일정 점검, 관리 • 관리에 대한 작업도 포함 가능 • 작업 시간의 정확한 예측 필요 • 소프트웨어 도구 • MS Project 등 Page 42

43. MS Project의 CPM 네트워크 예제 계획 (Planning)

44. 프로젝트 일정표 (간트 차트, Gannt Chart) 계획 (Planning) 소작업별로 작업의 시작과 끝을 나타낸 그래프 예비시간(slack time)을 보여줌예비시간: 다음 작업에 영향을 주지 않고 연장 가능한 시간 계획 대비 진척도를 표시할 수 있음  프로젝트 일정 관리에 활용 개인별 일정표 작성 가능 언제 투입하고, 언제 휴가가고… • 일반적인 간트 차트의 구성 • 세로를 일정축으로 하여 작업을 가로의 막대로서 표시함 • 막대의 흰 부분: 예상 소요 기간 • 막대의 회색 부분: 예비시간

45. 간트 차트 예제 계획 (Planning)

46. MS Project의 간트 차트 예제 계획 (Planning) 관심있는 학생은 MS Project를 배워보시기 바랍니다. (무료교육 많음) SI 업체 등에 취업할 경우 큰 도움이 될 것입니다.

47. In this chapter … 계획 (Planning) 프로젝트 관리 3.1 문제의 정의 3.2 노력 추정 3.3 일정 계획 3.4 조직 계획 3.5 위험 분석 3.6 계획서 작성

48. 조직 계획 계획 (Planning) • 조직의 구성 • 소프트웨어 개발 생산성에 큰 영향 • 작업의 특성과 팀 구성원 사이의 의사 교류 • 프로젝트의 구조 • 프로젝트별 조직: 프로젝트 시작에서 개발 완료까지 전담 팀 구성 • 기능별 조직 • 계획수립 분석팀, 설계 구현 팀, 테스트 및 유지보수 팀 • 파이프라인(pipeline)식 공정 • 매트릭스 조직 ( 인력 풀 제도) • 요원들은 고유 관리 팀과 기능 조직에 동시에 관련 • 필요에 따라 요원을 차출 팀을 구성하고 끝나면 원래의 소속으로 복귀

49. 조직 구성의 노하우? 계획 (Planning) • 경험이 많은 사람과 적은 사람을 적당히 혼합한다. • 경험 많은 사람만 모아놓으면 배가 산으로 갈 것이다. • 경험 적은 사람만 모아놓으면 아예 배를 만들지 못할 것이다. • 적당히 섞어 놓으면, 경험과 노하우가 자연스럽게 전수되는 이점이 있다. • 이직의 최소화가 대규모 프로젝트의 성패를 좌우한다. • 프로젝트 후반에 새로운 인원이 투입되면 그만큼 일정이 지연된다. • 기간 단축을 위해서 인원을 추가 투입하는 것은 의미가 없다. • 프로젝트를 너무 잘게 나누면, 팀(모듈)간 의사 교환 문제가 발생한다. 대개 3명~8명 정도가 적당하다. 8명이 넘으면 중간 관리자를 둔다.

50. 중앙 집중식 조직 (1/2) 계획 (Planning) • 의사 결정권이 리더에게 집중 • 계층적 팀 구조 • 책임 프로그래머 팀(Chief Programmer Team) • 외과 수술 팀 구성에서 따옴 • 책임 프로그래머: 제품설계, 주요부분 코딩, 중요한 기술적 결정, 작업의 지시 • 프로그램 사서: 프로그램 리스트 관리, 설계 문서 및 테스트 계획 관리 • 보조 프로그래머: 기술적 문제에 대하여 논의, 고객/출판/품질 보증 그룹과 접촉, 부분적 분석/설계/구현을 담당 • 프로그래머: (책임 프로그래머의 지시에 따라) 각 모듈을 프로그래밍