Scheduling in Project Management 일정 계획 예산 계획 조직 계획 위험 분석 계획서 작성

학습 목표 소프트웨어 프로젝트를 계획하려면 어떤 작업이 필요한가? 프로젝트 문제와 범위를 정의하는 방법 작업량을 예측하여 일정을 계획하는 방법 소프트웨어 비용을 산정하는 방법 소프트웨어 개발 팀을 구성하는 방법 소프트웨어 프로젝트의 위험 요소와 이를 관리하는 방법

Resource Estimation COCOMO

COCOMO Method 1. Basic COCOMO (COnstructive COst MOdel) B. Boehm presented, 통계적 기록에 입각 Predict Programmer-Months (or Man-Months) ☞ Organic mode: scientific model, business model < 50 KDSI or KLOC ☞ Semidetached mode: utility program < 300 KDSI or KLOC ☞ Embedded mode: > 300 KDSI where KDSI means Kilo Delivered Source Instruction 1 KDSI = 1000 program steps

COCOMO 방법 PM = 3.0*(KDSI)1.05 = 3.0*(290)1.05 = MM 표준 산정 공식 노력(MM) 기간(D) Organic 유형 PM = 2.4*(KDSI)1.05 TDEV=2.5*(PM)0.38 Semidetached 유형 PM = 3.0*(KDSI)1.12 TDEV=2.5*(PM)0.35 Embedded 유형 PM = 3.6*(KDSI)1.20 TDEV=2.5*(PM)0.32 예 CAD 시스템 예상 규모: 290 KLOC PM = 3.0*(KDSI)1.05 = 3.0*(290)1.05 = MM TDEV = 2.5*(PM)0.38 = 2.5*( )0.38 = M N = MM / TDEV = / 명 보정

Suppose Productivity = 620 LOC/MM Cost = 1500 원/LOC - Example) Suppose Productivity = 620 LOC/MM Cost = 1500 원/LOC Coding Language: C  128 LOC/FP We obtained FP considering multiple weights = 167 FP PM = TDEV = N = ?

PM = 2.4*(KDSI)1.05 TDEV=2.5*(PM)0.38 - Example ) Suppose Productivity = 620 LOC/MM Cost = 1500 원/LOC Coding Language: C  128 LOC/FP We obtained FP considering multiple weights = 167 FP Total Lines = 167 FP * 128 LOC/FP = 21,376 LOC PM = 2.4*(KDSI)1.05 TDEV=2.5*(PM)0.38

COCOMO에 의한 비용 예측

COCOMO 방법 모델 내용 기타 기본 COCOMO (Basic COCOMO) 추정된 LOC를 프로그램 크기의 함수로 표현해서 소프트웨어 개발 노력(그리고 비용)을 계산. S/W 크기와 개발모드 중간급COCOMO (Intermediate COCOMO) 프로그램 크기의 함수와 제품, 하드웨어, 인적 요소, 프로젝트 속성들의 주관적인 평가를 포함하는 “비용 유도자(cost driver)”의 집합으로 소프트웨어 개발 노력을 계산한다 15개의 비용 요소를 고려하여 곱한 가중치 계수 이용 고급 COCOMO (Advanced COCOMO = Detail COCOMO) 소프트웨어 공학 과정의 각 단계(분석, 설계 등)에 비용 유도자(cost driver)의 영향에 관한 평가를 중간급 모형의 모든 특성을 통합시킨 것. 시스템을 모듈, 서브 시스템으로 세분화한 후 Intermediate와 동일

1. Basic COCOMO (계속) - Development Effort and Time Mode Nominal Dev. Effort Dev. Time Organic MM = 2.4 (KDSI)1.05 TDEV = 2.5(MM)0.38 Semidetached MM = 3.0 (KDSI)1.12 TDEV = 2.5(MM)0.35 Embedded MM = 3.6 (KDSI)1.20 TDEV = 2.5(MM)0.32 Example 1) Suppose that we want to develop “Organic mode with expected 32,000 DSI”. FSP (full time software personnel) and total development time ?. MM = 2.4(32)1.05 = 91 MM TDEV = 2.5(91)0.38 = 14 Month FSP = = 91 / 14 = 6.5 사람

Basic COCOMO Example 2) Suppose a software development project for Embedded mode software with 428.000 DSI. FSP and TDEV ?. MM = 3.6(428)1.20 = MM TDEV = 2.5( )0.32 = Months FSP = MM / TDEV = / = Men Note: COCOMO 모델에서 프로젝트를 완성하는데 필요한 시간은 프로젝트에 종사하는 소프트웨어 개발자의 수에 관한 함수가 아니라 프로젝트를 완성하는데 필요한 전체의 노력에 관한 함수이다. 예를 들면 6,5 명이 14개월에 끝낼 수 있는 프로젝트를 3 명이 30 개월에 끝낼 수 있는지는 확실치 않다.

2. Intermediate(중간) COCOMO A multivariable static model 15 variables - It considers the attributes of the software product, the computer that runs the software, and the personnel involved in the product development and the project.

중간 COCOMO 방법 비용 드라이버 비율 낮음 보통 높음 제품특성 RELY 0.75 0.88 1 1.15 1.4 DATA   비용 드라이버 비율 매우낮음 낮음 보통 높음 매우높음 극히매우높음 제품특성 RELY 0.75 0.88 1 1.15 1.4 DATA 0.94 1.08 1.16 CPLX 0.7 0.85 1.3 1.65 H/W TIME 1.11 1.66 STOR 1.06 1.21 1.56 VIRT 0.87 TURN 1.07 개인특성 ACAP 1.46 1.19 0.86 0.71 AEXP 1.29 1.13 0.91 0.82 PCAP 1.42 1.17 VEXP 1.1 0.9 LEXP 1.14 0.95 PROJECT 특성 MODP 1.24 TOOL 0.83 SCED 1.23 1.04

2. Intermediate COCOMO Basic COCOMO 모델에서 제품에 요구되는 신뢰도, 데이타 베이스 크기, 수행시간과 기억장치의 제한, 개인적 특성, 소프트웨어에 사용되는 도구 등의 요인을 적용시킨 모델. - 제품 특성 ◇ 요구되는 소프트웨어 신뢰도 (RELY): 낮은 등급 - 고장으로 고장 불편을 초래, 중간 등급 - 고장이 회복 가능, 높은 등급 - 치명적 위험 ◇ 데이타 베이스 크기 (DATA): 낮은 등급 - 프로그램의 10 배 미만, 중간등급 - 시스템 크기의 10 - 100 배, 높은 등급 - 프로그램보다 1000 배 정도 크기

2. Intermediate COCOMO - 컴퓨터의 특성 ◇ 수행시간제한 (TIME): 중간등급 - 가용한 수행시간의 50 %미만 정도 사용상태, 극히 높은 등급 - 가용한 수행시간 90~95 % 사용상태 ◇ 기억장소 제한 (STOR): 중간등급 - 가용한 기억장소의 50 % 미만 사용, 극히 높은 등급 - 가용한 기억 장소의 90~95 % 사용 ◇ 가상기계(software 와 hardware 의 조합) 의 안전성 (VIRT): 매우 낮은 등급 - 1 년에 한번 정도 변화, 중간 등급 - 6 개월에 한번 변화, 매우 높은 등급 - 2 주일에 한번 변화

2. Intermediate COCOMO - 개인의 특성 ◇ 분석가의 능력 (ACAP) ◇ 개발분야의 경험 (AEXP) ◇ 가상기계의 경험 (VEXP) ◇ 프로그래머의 능력 (PCAP) ◇ 프로그밍언어 의 경험 (LEXP) 매우 낮은 등급 - 경험 전혀 없음, 중간등급 - 최소한 1 년, 매우 높은 등급 - 3 년이상

2. Intermediate COCOMO - 프로젝트의 특성 ◇ 최신 프로그래밍 기법이용(MODP): 소프트웨어 공학 2. Intermediate COCOMO - 프로젝트의 특성 ◇ 최신 프로그래밍 기법이용(MODP): 매우 낮은 등급 - 경험 전혀 없음, 중간등급 - 매우 어느정도 사용, 매우 높은 등급 - 일상으로 사용 ◇ 소프트웨어 도구 (TOOL): 매우 낮은 등급 - 어셈블어와 같은 기본적 도구만 사용 가능, 중간등급 - 구현 도구, 디버깅 도구, 테스팅 도구 같은 완전한 도구들을 이용, 매우 높은 등급 - 도구들을 life cycle 전 단계에서 이용될 수 있다. ◇ 요구되는 개발 일정 (SCED): 낮은 등급 - Basic COCOMO 에서 예측한 일정보다 단축 시 , 높은 등급 - Basic COCOMO 에서 예측한 일정보다 연장 될 때.

중간 COCOMO 방법 모든 노력 승수를 곱한다. 단점 소프트웨어 제품을 하나의 개체로 보고 승수들을 전체적으로 적용시킴 예: E=EAF * 2.4(32)1.05 = EAF * 91 man-months 단점 소프트웨어 제품을 하나의 개체로 보고 승수들을 전체적으로 적용시킴 실제 대부분의 대형 시스템은 서로 상이한 서브 시스템으로 구성될 수도 있다. - 예) 대형시스템 중 일부분은 Organic Mode이고 다른 부분은 Embedded Mode인 경우도 있다.

2. Intermediate COCOMO Mode Nominal Dev. Effort Dev. Time Organic MM = 3.2(KDSI)1.05 TDEV = 2.5(MM)0.38 Semidetached MM = 3.0(KDSI)1.12 TDEV = 2.5(MM)0.35 Embedded MM = 3.6(KDSI)1.20 TDEV = 2.5(MM)0.32 - Pprocedure of Cost Estimation with Intermediate COCOMO 1. Estimate Nominal Development Effort 2. Define 15 variable values 3. Estimate MM, Nominal Dev. Effort Effort = (MM)(C; cost driver) FSP = MM / TDEV 4. Cost = (FSP)(TDEV)(salary / Month)

3. Intermediate COCOMO Example 3) Suppose we develop embedded software. - Obtained Nominal Development Effort is 45MM. - Cost drivers of each variable in Intermediate COCOMO Model are as next. The remaining variable are Medium. RELY 1.15, STOR 1.21, TIME 1.10, TOOL 1.10 1. Estimate Nominal Development Effort = 45MM. 2. Define 15 variable values 3. Estimated MM is 45 4. Effort = (45MM)(1.15*1.21*1.10*1.10) = 76 MM TDEV = 2.5*(76 MM)0.32 FSP = 76 MM / TDEV 5. Cost = (MM)(Salary / Month) = (76)(7.000) = 532.000 $ if Salary / Month is 7.000 $

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

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

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

중앙 집중식 조직 특징 단점 의사 결정이 빠름 소규모 프로젝트에 적합 초보 프로그래머를 훈련시키는 기회로 적합 책임프로그래머 프로그램 사서 프로그래머 보조 프로그래머 백업 특징 의사 결정이 빠름 소규모 프로젝트에 적합 초보 프로그래머를 훈련시키는 기회로 적합 단점 한 사람의 능력과 경험이 프로젝트의 성패 좌우 보조 프로그래머의 역할이 모호

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

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

2.6 위험 분석 위험 요소를 인식하고 그 영향을 분석하여 관리 실패에 영향을 미칠 위험 요소 인식하고 그 대책 수립 인력의 부족 -> 인력의 적극적 유치; 팀 구성; 교차교육 등 일관성 있는 해결 방안 비용에 많은 영향을 미치는 요소 -> 리스크 요구분석의 변경 프로토타이핑, 설문지, 리뷰 일정 지연의 위험 작업 의존도를 낮춤 CPM 네트워크에서 outgoing arcs가 많은 노드

Software risks R i sk A f ec ts D e s cr p t on S ta ff u r n o v P j x pe ie ce d a f w l ea e t h b is f d. M na g m t c ge T er w a c f o an is at al fe pr io s. H ar dw ai ab li y sse nt o r t h e p jec t w il l n be d eli v n s c ed u le . R q i m en ts an g P j ct a n T er w l b ge r n mb f s eq s t ha ci ate S ic ti de ay ss al ai ab S iz e u n d re st i m a t P r o j ct p T h s z f t he y as be im ate . C AS E t l u er - fo ce c ls w ch su je t p m as ti Tec l g an B us ss e u te w ic sys m is b ui rs ed b y ne w t ec h n o lo g y . P r o d u c t co mp et i t i o n B us i n e ss A c o m p e t it i ve p r o d u c t i s m ar k e t ed be f o r e t h e s y st e m i s c om pl e te d .

The risk management process Risk identification Identify project, product and business risks; Risk analysis Assess the likelihood and consequences of these risks; Risk planning Draw up plans to avoid or minimise the effects of the risk; Risk monitoring Monitor the risks throughout the project;

The risk management process

Risk identification Technology risks. People risks. Organisational risks. Requirements risks. Estimation risks.

Risks and risk types

Risk analysis Assess probability and seriousness of each risk. Probability may be very low, low, moderate, high or very high. Risk effects might be catastrophic, serious, tolerable or insignificant.

Risk analysis (i)

Risk analysis (ii) R i s k P ro b ab ilit y E ff ec t T he da ta base us e d n he sy st m c anno p r oce s as any an ac ti ons pe econd as expec ed . Mod ra te S ri ous tim requ ir o deve l op o f w ar unde es a H gh CA SE oo ls canno be in eg ol rab le Cu er il to and im pa t o equ change qui ng fo no av la bl of de epa und re stim ed. si ze o f t he cod gen by C A is i ne ffi en I ns gn if

The risk management process

Risk planning The probability that the risk will arise is reduced; Consider each risk and develop a strategy to manage that risk. Avoidance strategies The probability that the risk will arise is reduced; Minimisation strategies The impact of the risk on the project or product will be reduced; Contingency plans If the risk arises, contingency plans are plans to deal with that risk;

Risk management strategies (i)

Risk management strategies (ii)

The risk management process

Risk indicators

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

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

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