소프트웨어 공학 (Software Engineering) 계획 (Planning) 최미정 강원대학교 컴퓨터과 학 전공

1. 소프트웨어 공학 (Software Engineering) 계획 (Planning) 최미정 강원대학교 컴퓨터과학전공

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) • 프로젝트 관리 • 문제 정의 • 계획 (일정, 예산, 조직) • 노력 추정 • 위험 분석 • 계획서 작성

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

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

7. 일반 제품 관리와 소프트웨어 프로젝트 관리의 차이점 계획 (Planning) • 프로덕트를 만질 수 없고 눈이 보이지 않음 • 프로덕트가 매우 Flexible함  변경이 쉽고, 진화하며, 에러를 내재함 • 기계공학, 건축공학처럼 엔지니어링 기술이 아직 확립되어 있지 않음 수십 년을 연구했음에도 Not Yet?  과연 SE란 것이 존재하나? • 소프트웨어 엔지니어링 프로세스가 표준화되어 있지 않음 최근 표준화를 시도하고 있음 (ISO, CMM 등을 확대해석 하면) • 대부분의 소프트웨어 프로젝트는 일회성 아파트 건설 (서울에 짓나, 춘천에 짓나, 그게 그거지 뭐~) 온라인 게임 (스타크래프트 vs. 리니지 vs. 카트라이더…)

8. 프로젝트 관리 작업 계획 (Planning) • 계획서 작성(Proposal writing) • 프로젝트 예산 수립(Project costing) • 프로젝트 일정 계획(Project planning and scheduling) • 프로젝트 모니터링 및 리뷰(Project monitoring and reviews) • 조직 구성 및 평가(Personnel selection and evaluation) • 보고서 작성 및 발표(Report writing and presentations)

9. 프로젝트 관리 작업의 공통점 계획 (Planning) • 소프트웨어 프로젝트에만 있는 작업이 아님 • 다른 엔지니어링에서도 충분히 볼 수 있는 관리 작업들임 과거를 돌아보면, 건설사 사장이 전자 사장해도 (대충) 잘하고,전자 사장이 소프트웨어 사장해도 (대충) 잘한다. 소프트웨어 프로젝트 관리가 다른 특징을 많이 가지긴 해도 큰 범주 안에서 보면 결국 관리 공학이다. • 다른 엔지니어링도 복잡해진다면, 소프트웨어 프로젝트 관리에서 드러내는 문제점을 가질 수 있음 • 예산의 초과 • 자원 예측의 부정확 • 기간의 지연 • 계획의 잦은 변경

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

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

12. We are now … 계획 (Planning) • 프로젝트 관리 • 문제 정의 • 계획 (일정, 예산, 조직) • 노력 추정 • 위험 분석 • 계획서 작성

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

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

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

16. We are now … 계획 (Planning) • 프로젝트 관리 • 문제 정의 • 계획 (일정, 예산, 조직) • 노력 추정 • 위험 분석 • 계획서 작성

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

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

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

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

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

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

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

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

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

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

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

28. 간트 차트 또다른 예제 계획 (Planning) • 교재 p. 63의 표 2.2 참조

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

30. We are now … 계획 (Planning) • 프로젝트 관리 • 문제 정의 • 계획 (일정, 예산, 조직) • 노력 추정 • 위험 분석 • 계획서 작성

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

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

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

34. 프로젝트 비용을 예측하는 방법 계획 (Planning) • 하향식 (Top-down) • 소요 기간을 구하고 여기에 투입되어야 할 인력과 투입 인력의 참여도를 곱하여 최종 인건 비용을 계산 • 소작업에 대한 노력을 일일이 예측해야 함  커다란 구조를 작은 구조로 잘게 잘라 나가면서 비용을 예측함 • 상향식 (Bottom-up) • 프로그램의 규모를 예측하고 과거 경험을 바탕으로 예측한 규모에 대한 소요 인력과 기간을 추정 • 프로그램의 규모 • LOC (Lines of code) • 기능 점수 (Function Point)  총 몇 라인이니까, 얼마 정도가 들 것이다라고 예측함

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

36. 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  궁극적으로 파악해야 하는 값

37. 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명

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

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

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

41. 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 라인 작성

42. 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 라인 작성

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

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

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

46. 가중값(p. 71의 표 2.6) 설명 계획 (Planning) • 입력 개수: 사용자가 시스템에 제공하는 입력 자료의 개수예: 웹 페이지 작성에 있어서 입력 화면의 개수 • 출력 개수: 시스템이 사용자에게 제공하는 입력 자료의 개수예: 웹 페이지 작성에 있어서 출력 화면의 개수 • 질의 개수: 사용자가 제공하는 대화형 질의의 개수예: 검색 화면에서 검색 조건을 주는 방법의 수 • 파일 개수: 시스템이 저장 및 관리하는 파일의 개수예: 봉급 파일, 주소 파일 • 인터페이스 개수: 다른 시스템과의 인터페이스 개수예: 은행 봉급 서버는 주소 서버, 고과 서버와 인터페이스 함

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

48. 기능 점수 추정 사례 계획 (Planning)  내용을 Skip함 (pp. 72-76)(교과서 사례 예제가 너무 일관성이 없어 강의에서 제외함)

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

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