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

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

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

In this chapter … 프로젝트 관리 문제 정의 계획 (일정, 예산, 조직) 노력 추정 위험 분석 계획서 작성 계획 (Planning) 프로젝트 관리 문제 정의 계획 (일정, 예산, 조직) 노력 추정 위험 분석 계획서 작성

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

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

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

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

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

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

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

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

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

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

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

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

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

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

작업순서 결정 및 소요시간 예측 계획 (Planning) CPM 네트워크 작성을 위해, 우선 각 소작업에 대한 소요 기일을 예측하고, 각 소작업 간의 선후관계를 파악한다. CPM 소작업 리스트 예제 소작업 선행작업 소요기간(일) A B C D E F G H I J K L - B, D A, B C, F G, E 8 15 10 5 20 25 7

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

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

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

CPM 네트워크에 의한 임계 경로 (2/2) 임계 경로 예제 가능 경로 소요 기간(일) 계획 (Planning) 임계 경로 예제 가능 경로 소요 기간(일) S-A-M1-C-M4-I-M6-K-M8-L-X  S-A-M3-F-M4-I-M6-K-M8-L-X  S-A-M1-G-M7-J-X  S-B-M3-F-M4-I-M6-K-M8-L-X  S-B-M2-E-M7-J-X  S-D-M2-E-M7-J-X  S-D-M5-H-X 55* 45 43 52 40 35

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

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

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

간트 차트 예제 계획 (Planning)

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

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

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

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

MTBF 제안 예제 계획 (Planning)

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

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

COCOMO 방법 (2/4) 표준 산정 공식 용어 프로젝트 유형 노력(MM) 개발 기간(Day) 단순형 (Organic) 계획 (Planning) 표준 산정 공식 프로젝트 유형 노력(MM) 개발 기간(Day) 단순형 (Organic) PM = 2.4 x (KDSI)1.05 TDEV = 2.5 x (PM)0.38 중간형 (Semi-detached) PM = 3.0 x (KDSI)1.12 TDEV = 2.5 x (PM)0.35 임베디드형 (Embedded) PM = 3.6 x (KDSI)1.20 TDEV = 2.5 x (PM)0.32 용어 KDSI: Kilo Delivered Source Instruction  입력 값으로 추정치에 해당함 (LOC: Lines of code  1 KDSI = 1,000 LOC) PM: Programmer-Month TDEV: Total development time  궁극적으로 파악해야 하는 값

COCOMO 방법 (3/4) 유형 설명 예제: CAD 시스템 계획 (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명

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

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

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

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

COCOMO 방법의 사용 예제 (1/2) 128,000 LOC 크기인 임베디드형(Embedded)의 예측 기본 방법 계획 (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 라인 작성

COCOMO 방법의 사용 예제 (2/2) 128,000 LOC 크기인 임베디드형(Embedded)의 예측 (계속) 계획 (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 라인 작성

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

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

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

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

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

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

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

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

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

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

중앙 집중식 조직 (2/2) 특징 단점 책임프로그래머 프로그램 사서 프로그래머 보조 프로그래머 백업 의사 결정이 빠름 계획 (Planning) 책임프로그래머 프로그램 사서 프로그래머 보조 프로그래머 백업 특징 의사 결정이 빠름 소규모 프로젝트에 적합 초보 프로그래머를 훈련시키는 기회로 적합 단점 한 사람의 능력과 경험이 프로젝트의 성패 좌우  책임 프로그래머의 선정 문제 책임 프로그래머에게 오버로드가 걸릴 수 있음 보조 프로그래머의 역할이 모호

분산형 팀 조직 민주주의식 의사 결정 다각도의 의사 교환 경로 제공 특징 단점 서로 협동하여 수행하는 비이기적인 팀 계획 (Planning) 민주주의식 의사 결정 서로 협동하여 수행하는 비이기적인 팀 자신이 있는 일을 알아서 수행 구성원이 동등한 책임과 권한 다각도의 의사 교환 경로 제공 특징 작업 만족도 높음 ( 이직률이 낮음) 의사 교류 활성화 장기 프로젝트에 적합 단점 책임이 명확하지 않은 일이 발생 대규모에 적합하지 않음(의사 결정 지연 가능)

혼합형 팀 조직 집중형, 분산형의 단점을 보완 특징 소프트웨어 에 따라 계층적으로 분산됨 단점 초보자와 경험자를 분리 계획 (Planning) 집중형, 분산형의 단점을 보완 특징 초보자와 경험자를 분리 프로젝트 관리자와 고급 프로그래머에게 지휘권한이 주어짐 의사교환은 초보 엔지니어나 중간 관리층으로 분산 소프트웨어 에 따라 계층적으로 분산됨 단점 기술인력이 관리를 담당 의사 전달 경로가 김

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

위험 분석 (Risk Analysis) (내재된) 위험 요소를 인식하고 그 영향을 분석하여 관리 계획 (Planning) (내재된) 위험 요소를 인식하고 그 영향을 분석하여 관리 실패에 영향을 미칠 위험 요소 인식하고 그 대책 수립 인력의 부족  인력의 적극적 유치, 팀 구성 시 고려, 교차교육 등 일관성 있는 해결 방안 (누가 못하면, 조금 여유 있는 옆 사람이 한다?)  체계적이고 조직적인 해결 방안(조수/사수 개념, 중복 배치 등) 비용에 많은 영향을 미치는 요소  리스크 요구분석의 변경 위험 감소 방안  프로토타이핑, 설문지, 리뷰 일정 지연의 위험 작업 의존도를 낮춤 (한 가지 작업에 병목이 발생하는 것을 최소화한다.) CPM 네트워크에서 outgoing edge가 많은 노드

일반적인 위험 요소 (1/2) 위험 요소 위험 관리 기법 1. 인력 부족 유능한 인력모집, 팀 구성, 요원 배치 계획 (Planning) 위험 요소 위험 관리 기법 1. 인력 부족 유능한 인력모집, 팀 구성, 요원 배치 교차-교육, 유능 인력 사전 확보 2. 비현실적 일정 및 예산 더 자세한 비용, 일정 예측, 원가 분석 점증적 개발, 소프트웨어 재사용 요구를 줄임 3. 잘못된 기능의 소프트웨어 개발 사용자 회람, 프로토타이핑 사용자 지침서 조기 작성, 조직 분석, 직능 분석 4. 잘못된 인터페이스의 개발 프로토타이핑, 시나리오, 태스크 분석 사용자 분류(기능, 스타일, 업무) 5. 과포장 요구 삭감, 프로토타이핑 비용-수익 분석, 원가 분석

일반적인 위험 요소 (2/2) 위험 요소 위험 관리 기법 6. 계속적인 요구 변경 최대 변경 상한선, 정보 은닉 계획 (Planning) 위험 요소 위험 관리 기법 6. 계속적인 요구 변경 최대 변경 상한선, 정보 은닉 점증적 개발(다음 버젼까지 변경을 연기) 7. 외부 모양의 빈약 벤치마킹, 검사, 대조 확인, 성숙도 분석 8. 외부 기능의 빈약 대조 확인, 사전 검증, 설계 경연, 팀 작업 9. 실시간 성능의 빈약 시뮬레이션, 벤치마킹, 모델링, 프로토타이핑, 튜닝 10. 기술적 취약 기술 분석, 비용-수익 분석, 프로토타이핑, 점검

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

계획서 작성 (1/3) 1. 개 요 1.1 프로젝트 개요 1.2 프로젝트의 산출물 1.3 정의, 약어 2. 자원 및 일정 예측 계획 (Planning) 1. 개 요 1.1 프로젝트 개요 1.2 프로젝트의 산출물 1.3 정의, 약어 2. 자원 및 일정 예측 2.1 자원 가. 인력 나. 비용 2.2 일정 3. 조직 구성 및 인력 배치 3.1 조직 구성 3.2 직무 기술

계획서 작성 (2/3) 4. WBS 5. 기술관리 방법 5.1 변경 관리 5.2 위험 관리 5.3 비용 및 진도 관리 계획 (Planning) 4. WBS 5. 기술관리 방법 5.1 변경 관리 5.2 위험 관리 5.3 비용 및 진도 관리 5.4 문제점 해결 방안 6. 표준 및 개발 절차 6.1 개발 방법론 7. 검토 회의 7.1 검토회 일정 7.2 검토회 진행 방법 7.3 검토회 후속 조치

계획서 작성 (3/3) 8. 개발 환경 9. 성능 시험 방법 10. 문서화 11. 유지보수 12. 설치, 인수 계획 (Planning) 8. 개발 환경 9. 성능 시험 방법 10. 문서화 11. 유지보수 12. 설치, 인수 13. 참고문헌 및 부록

개발 계획서 예제 (1/2) 계획 (Planning)

개발 계획서 예제 (2/2) 계획 (Planning)

Homework #2 계획 (Planning)