프로젝트 관리와 계획

(1)

소프트웨어 공학 (Software Engineer- ing)

프로젝트 관리와 계획

문양세

강원대학교 IT 대학 컴퓨터과학전공

(2)

Software Engineering by Yang-Sae Moon

Page 2

소프트웨어 공학의 계획을 논하기에 앞서서…

만사에 있어서 계획이 없으면 이룰 것이 없다 .

많은 계획들 중에 있어서도 가장 중요한 계획은 자기 자신 인생의 장중단기 계획이다 .

계획 (Planning)

In this chapter … (1/2)

사랑하는 학생 여러분 가슴에 손을 올리고 생각해 보세요 .

나는 10 년 후에 무엇이 되고 싶은가 ?  장기 계획

10 년 후를 위해서 , 올 한해 나는 무엇을 추구하고 달성할 것인가 ?  중기 계획

올 한해 목표를 달성하기 위해서 , 나는 이달에 , 오늘 무엇을 해야 하나 ?  단기 계획

 그래 고민되니까 오늘까정만 한잔 ?

(3)

계획 (Planning)

In this chapter … (2/2)

소프트웨어 공학에서의 계획이란 ,

개발하고자 하는 문제에 대한 정확한 이해 및 정의를 하고 ,

여러 가지 필요한 작업들을 도출하고 , 그 작업들의 순서를 결정하며 ,

어떻게 개발해 나갈 것인지 일정을 계획하며 , 이에 따른 비용을 추정하는 것이다 .

그리고 , 궁극적인 결과 (output) 로는 계획서를 작성하는 것이다 .

We will cover …

프로젝트 관리

프로젝트 범위

노력 추정

일정 계획

위험 관리

(4)

Page 4

In this chapter …

프로젝트 관리

3.1 프로젝트 범위 3.2 노력 추정

3.3 일정 계획 3.4 조직 계획 3.5 위험 관리

3.6 계획서 작성과 도구

계획 (Planning)

(5)

프로젝트 관리란 ?

소프트웨어 프로젝트를

1) 조직하고 (organizing)

^–어떠한 일이 있는지 파악하여 , 관련 사람들을 어떻게 끌어 모으고 ,

2) 계획하고 (planning)

^–어떠한 일정으로 얼마의 비용으로 어떻게 사람을 넣어서 진행하며 ,

3) 일정관리 (scheduling) 하는 것이다 .

^–잘 진행되는지 항시 점검하고 피드백하는 것이 다 .

프로젝트 관리 (Project Management)

계획 (Planning)

(6)

Page 6

수입과 지출에 직결되는 경제 관련 작업 (economic activity)

기술 외적인 부분 ( 경영 , 경제 ) 이 많음

기술력 최고 ?  이것보다는 적기에 , 쓸만한 것을 , …

 온라인 게임 열풍  앵그리버드 , 애니팡

관리가 잘된 프로젝트도 실패하는 경우가 있음

관리가 잘 안 되는 프로젝트는 실패로 끝날 가능성이 많음

결과적으로 , 프로젝트에 있어서 관리는 필수적 개념임

그래서 , 아무리 잘난 사람이 많아도 조직에는 과장 , 팀장 , 부장이 존재하는 것임

관리 작업에 대한 방법을 일부 이론적으로 다룸

관리를 실제 배우는 일은 현장감이 중요

관리에 , 특히 인간 관리에 정도는 없음  경험을 바탕으로 융화할 수 있어야

프로젝트 관리의 중요성

계획 (Planning)

(7)

계획 (1/2)

계획의 부재

불확실성  중간에 무엇을 하고 있는지 , 어디까지 되어가는지 파악할 길이 없음

일정의 차질 , 경비의 초과 , 저품질 , 높은 유지보수 비용

위험 (risk)

결과적으로는… 프로젝트의 실패

소프트웨어 프로젝트 계획 수립

“소프트웨어 개발 과정과 일정 , 비용 , 조직 , 생산 제품에 대하여 사전에 계획”

문제를 이해하고 정의

필요한 소작업 (activity) 을 정의하고 순서를 결정

일정 예측

비용 예측

위험 분석

계획 (Planning)

 계획서 작성

(8)

Page 8

계획 (2/2)

계획 수립의 결과

 소프트웨어 개발 계획서

사업관리자 , 개발자 , 사용자들에게 사업의 범위 , 필요 비용 , 필요 자원 , 개발 일정 , 위험 요소 등에 대한 정보를 제공하는 산출문서 (deliverable)

주의할 점

( 계획자는 ) 시스템에 대한 충분한 이해가 있어야 함 , 그러나 변경의 여지도 있음

현실적 , 구체적 계획  보여주기 위한 계획이 아닌 실질적인 계획

득실 관계 저울질  기간 vs. 비용

기술적인 측면 고려  제품의 난이도 , 투입 엔지니어의 능력

계획 (Planning)

(9)

프로젝트 일정 계획 작업 과정

계획 (Planning)

(10)

Page 10

In this chapter …

프로젝트 관리

3.1 프로젝트 범위 3.2 노력 추정

3.3 일정 계획 3.4 조직 계획 3.5 위험 관리

3.6 계획서 작성과 도구

계획 (Planning)

(11)

프로젝트 범위

계획 (Planning)

소프트웨어 개발 프로젝트를 위한 계획은 대상 업무나 문제의 범위 (scope) 를 결정하는 것으로부터 시작

문제의 범위를 정의하기 위하여 먼저 문제의 배경과 응용 분야를 파악

사용자와 면담

현장 관찰

실제 업무 수행

문제 정의

(12)

Page 12

문제 정의 (1/2)

문제의 이해 :

대상 업무나 문제를 사용자가 이해하는 용어로 정확히 기술한 것 ( 개발자가 아닌 고객의 관점에서 정확히 기술해야 함 )

계획 (Planning)

문제의 인식

기본 요건 분석

시스템 조사 및 정보 수립

현 시스템의 이해

신규 시스템의 정의



문제 범위와 원인 파악



문제를 둘러싼 조직 , 제도 , 시설 , 인원 , 기술에 관한 현황 파악



현재의 시스템 조사 , 업무 흐름 정책 등을 파악



면담과 서류로 심층 분석

( 고객 상담 , 현업의 분석 , 작업의 체험 )



목표 시스템의 정의

(13)

문제 정의 (2/2)

계획 (Planning)

문제를 정의한 후에는 해결 방법에 대한 대책을 수립함

신규 시스템의 목표 설정  기능과 우선순위 ( 투자 효과를 분석 )

해결 방안 모색 ( 사용자 요구 , 개발 여건 , 기술적 능력 고려 )

문제 ( 개발 시스템 ) 의 정의 요소

문제의 기술 ( 교수용 온라인 게임을 만든다 .)

시스템의 필요성 ( 교수들도 가끔 즐길 권리가 있다 .)

시스템의 목표 ( 전국 교수들을 모두 매혹시킨다 .)

제약 사항 ( 근데 , 컴퓨터를 다룰 줄 모르는 분은 불행히 제외한다 .)

시스템의 제공 기능 (3D 와 FullHD 는 기본이고 , 사운드는 5.1 채널 지원이다 .)

사용자의 특징 ( 애덜이 아니라 대부분 중년이다 .)

개발 , 운용 , 유지보수 환경 ( 전화 Claim 이 비교적 많을 것이니 , ARS 응대가 필요하 다 .)

(14)

Page 14

문제 범위 정하기

계획 (Planning)

수강 신청 시스템 사례

 넓은 범위

 작은 범위

(15)

In this chapter …

프로젝트 관리

3.1 프로젝트 범위 3.2 노력 추정

3.3 일정 계획 3.4 조직 계획 3.5 위험 관리

3.6 계획서 작성과 도구

계획 (Planning)

(16)

Page 16

노력 추정이란 ?

계획 (Planning)

얼마나 노력이 들어가느냐 , 결국 개발 비용을 추정하는 것이다 . 소프트웨어 개발 비용 예측

정확한 비용 예측은 매우 어려움

 알려지지 않은 요소가 산재  에러 발생 , 성능 저하 , 엔지니어의 이직 , …

 원가의 계산이 어려움 ( 결국 , 인건비인데 , 이것 자체의 추정이 어려움 )

과거의 ( 경험적 ) 데이타가 필요

단계적 비용 산정 방법도 사용 ( 초기 10 억원 , 프로토타입 이후 11.5 억원 등 )

예산

인건비 : MM( 인원 / 월 ) 를 기초  관리자를 포함한 엔지니어의 인건비를 의미함

경비 : 여비 , 인쇄비 , 재료비 , 회의비 , 공공요금

간접 경비 : 오버헤드 (overhead)  회사에는 회계 , 기획 , 경영 등 많은 파트가 있음

(17)

비용에 영향을 주는 요소

계획 (Planning)

제품의 크기

제품의 크기가 커짐에 따라 비용은 기하급수로 늘어남  분산 , 병렬 시스템의 예

제품의 복잡도

응용 : 개발지원 : 시스템 = 1 : 3 : 9

프로그래머의 자질

코딩 , 디버깅의 능력차

프로그래밍 언어 , 응용 친숙도

요구되는 신뢰도 수준  MTBF(mean time between failure) 기술 수준 ( 개발 장비 , 도구 , 조직능력 , 관리 , 방법론 숙달 ) 남은 시간

Putnam “ 프로젝트의 노력은 남은 개발 기간의 4 제곱에 반비례”

 2 달 남았으면 1/2⁴ = 1/16, 1 달 남았으면 1 이 필요…

(18)

Page 18

프로젝트 비용을 예측하는 방법

계획 (Planning)

상향식 (Bottom-up)

소작업에 소요되는 기간을 구하고 , 여기에 투입되어야 할 인력과 투입 인력의 참여도를 곱하여 최종 인건 비용을 계산

장점 : 소작업에 드는 노력을 일일이 계획할 수 있음

단점 : 개인의 주관에 의한 추정이 될 가능성이 많음

하향식 (Top-down)

프로그램의 규모를 예측하고 과거 경험을 바탕으로 예측한 규모에 대한 소요 인력과 기간을 추정

프로그램의 규모



LOC (Lines of code)



기능 점수 (Function Point)

 총 몇 라인이니까 , 혹은 어떤 기능이 있으니까 얼마 정도가 들 것이다라고 예측함

(19)

COCOMO 방법 (1/4)

계획 (Planning)

개요 ( 위키 )

B. Boehm 이 1981 년에 제안한 Constructive Cost Model 이다 .

주로 2K-32K 라인 규모의 많은 프로젝트의 기록을 통계 분석하여 얻은 결과로서 , 중소규모 프로젝트의 추정에 적합하다 .

완성될 규모의 LOC(lines of code) 를 추정하고 , 이를 준비된 식에 대입하여 소요 MM 을 예측한다 .

소프트웨어 공학 기술의 발전과 더불어 초기 COCOMO 모델 (COCOMO-81 이라 일컬 음 ) 은 1995 년에 COCOMO II 로 확장되었다 .

(20)

Page 20

COCOMO 방법 (2/4)

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

(21)

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 명

(22)

Page 22

COCOMO 방법 (4/4)

계획 (Planning)

비용 예측 그래프

단순히 # of lines 에 비례하는 것이 아니라 ,

복잡할수록 ( 시스템이 커질수록 ) 비례하는 정도가 달라진다 .  빨리 증가한다 .

(23)

COCOMO 방법의 보정 (Scaling) (1/2)

계획 (Planning)

기본 방법에 제품의 성격 , 목표 시스템의 특성 , 개발 구성원의 특성 , 프로젝트 자체의 성격 등에 따라 보정한다 .

예를 들어 , 프로그램의 경험이 많다면 노력 예측 값은 더 작아져야 하며 ,

실시간 처리 요구가 있다면 예측 값은 더 커져야 한다 .

 노력 승수 : 여러 조건을 고려하여 기본 방법에 곱하는 상수 값 노력 승수에 영향을 미치는 요소

제품의 특성 : 신뢰성에 대한 요구나 문제의 복잡도 , 데이터베이스의 크기 등

컴퓨터 실행 : 수행 시간의 제약 , 주기억 장치의 제약 , H/W 및 S/W 의 안전성 등

개발자의 특성 : 개발자의 응용 분야 경험 유무 , 프로그래밍 언어에 대한 익숙도 등

프로젝트 : 복잡한 소프트웨어 도구 사용이 필요한가 ?

(24)

Page 24

COCOMO 방법의 보정 (Scaling) (2/2)

계획 (Planning)

노력 승수 테이블  다음 페이지 참조

노력 승수 (k

_i

, 1  i

 n

) 를 사용하여 보정한 PM 계산

 노력 승수를 기본 PM 값에 곱하여 보정된 PM 값을 구한다 .

 ^ ¹   ^ ¹  ^ ^

  ⁿ    ⁿ   ^k

scale i i i i

PM k PM k c KDSI

(25)

노력 승수 테이블 예제

계획 (Planning)

(26)

Page 26

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

(27)

COCOMO 방법의 사용 예제 (2/2)

계획 (Planning)

128,000 LOC 크기인 임베디드형 (Embedded) 의 예측 ( 계속 ) 보정된 방법 (1.15, 1.56, 0.82 적용 시 예제 )

PM_scale = 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 라인 작성

(28)

Page 28

COCOMO 방법의 특징

계획 (Planning)

COCOMO 모델을 보면 , “ 소요 기간과 소요 인원의 관계는 서로 바꿀 수 있는 관계가 아니다”라는 말을 실증하고 있다 .

 기간이 먼저 계산되고 , 이에 따라서 필요 인원을 파악

 “기간이 많이 걸리니 인원을 늘리자”는 잘못된 생각

프로젝트의 규모만 예측될 경우 , 인원 , 개발 기간 등의 비용을 비교적 정확하게 예측할 수 있다 .

반면에 ,

1) 소프트웨어 제품을 하나의 개체로 보고 전체적인 수식을 계산한다 .  실제로는 제품이 훨씬 복잡한 구조를 가지고 있다 .

2) 계획 단계에 프로젝트의 규모를 정확히 예측하기는 거의 불가능하다 .

(29)

COCOMO II

계획 (Planning)

1995 년에 발표

소프트웨어 개발 프로젝트가 진행된 정도에 따라 세 가지의 다른 모델을 제시  각 단계에 따라 다른 계산법을 적용

제 1 단계 : 프로토타입을 만드는 단계

화면이나 출력 등 사용자 인터페이스 , 3 세대 언어 컴포넌트 개수를 세어 응용 점수 (application points) 를 계산

이를 바탕으로 노력을 추정

제 2 단계 : 초기 설계 단계

자세한 구조와 기능을 탐구

제 3 단계 : 구조 설계 이후 단계

시스템에 대한 자세한 이해

(30)

Page 30

기능 점수 방법

계획 (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 등을 사용해 예측할 수도 있 다 .

이들 고급 언어는 어디로 갔지 ?

(31)

가중값 설명 (1/2)

계획 (Planning)

입력 개수 : 사용자가 시스템에 제공하는 입력 자료의 개수 예 : 웹 페이지 작성에 있어서 입력 화면의 개수

출력 개수 : 시스템이 사용자에게 제공하는 출력 자료의 개수 예 : 웹 페이지 작성에 있어서 출력 화면의 개수

질의 개수 : 사용자가 제공하는 대화형 질의의 개수

예 : 검색 화면에서 검색 조건을 주는 방법의 수

(32)

Page 32

가중값 설명 (2/2)

계획 (Planning)

파일 개수 : 시스템이 저장 및 관리하는 파일의 개수 예 : 봉급 파일 , 주소 파일

인터페이스 개수 : 다른 시스템과의 인터페이스 개수

예 : 은행 봉급 서버는 주소 서버 , 고과 서버와 인터페이스 함

(33)

복합 가중값 설명

계획 (Planning)

기본 가중값을 바탕으로 복잡도를 고려하여 , 단순 , 보통 , 복잡의 세 가 지 단계로 구분함

아래 예를 보면 , “ 개수 x 복합 가중값”을 더하여 최종 점수 148 을 구 한다 .

 25 LOC/FP 인 4 세대 언어로 구현하면 , 148 x 25 = 3775 LOC 가 된다 .

 프로젝트 팀의 생산성이 2000 LOC/MM 이며 ,

즉 한 달에 한 사람이 2000 라인 작성한다면 , 3775/2000 = 1.9MM 가 된다 .

(34)

Page 34

기능 점수 추정 사례

계획 (Planning)

 내용을 Skip 함

( 교재 사례 예제가 너무 복잡하여 강의에서 제외함 )

(35)

In this chapter …

프로젝트 관리

3.1 프로젝트 범위 3.2 노력 추정

3.3 일정 계획 3.4 조직 계획 3.5 위험 관리

3.6 계획서 작성과 도구

계획 (Planning)

(36)

Page 36

일정 계획 (Scheduling)

계획 (Planning)

일정 계획 :

개발 프로세스를 이루는 소작업 (activity) 를 파악하고 , 그 순서와 일정 을 정하는 작업

개발 모형 결정 ( 폭포수 , 프로토타이핑 , …)

소작업 , 산출물 , 이정표 설정

작업 순서

작업 분해 : WBS(Work Breakdown Structure) 작성

CPM(Critical Path Method) 네트워크 작성

최소 소요 기간 (best case) 을 구함 ( 위험 분석을 위해 , worst case 도 작성해 본다 .)

소요 MM, 기간 산정하여 CPM 수정

간트 차트로 그려 , 일정을 구체화 함

(37)

작업 분해 (Decomposition)

계획 (Planning)

작업 분해 :

프로젝트 완성에 필요한 소작업 (activity) 를 찾아냄 WBS(Work Breakdown Structure)

계층적 구조를 가짐

Activity 의 규모를 판별할 수 있음

각 노드에 작업 소요일 , 책임자 등을 표시할 수 있음

작업 분해는 일정 계획에

앞서서 필요 작업을 찾는데

주된 목적이 있음

(38)

Page 38

작업순서 결정 및 소요시간 예측

계획 (Planning)

CPM 네트워크 작성을 위해 , 우선 각 소작업에 대한 소요 기일을 예측하 고 , 각 소작업 간의 선후관계를 파악한다 .

CPM 소작업 리스트 예제

소작업 선행작업 소요기간 ( 일 )

A B C D E F G H I J K

L

- - A

- B, D A, B

A D C, F G, E

I K

8

15

10

5

20

25

15

7

10

(39)

CPM 네트워크 (1/2)

계획 (Planning)

CPM 네트워크는 방향성 그래프 (directed graph) 이다 . 그리는 예는 ,

노드 (node) 는 소작업을 표시한다 .

 원형 노드 : 소작업의 이름과 소요 기간을 기재한다 .

 박스 노드 : 프로젝트 중간 점검 (milestone) 을 의미하며 , 예상 종료일을 기재한 다 .

에지 (edge) 는 작업 사이의 선후 관계를 표시한다 .

CPM 네트워크를 사용하여 , 프로젝트 완성에 필요한 작업을 나열하고

작업에 필요한 소요기간을 예측하는데 사용된다 .

(40)

Page 40

CPM 네트워크 (2/2)

계획 (Planning)

CPM 네트워크 예제

(41)

CPM 네트워크에 의한 임계 경로 (1/2)

계획 (Planning)

CPM 네트워크를 사용하여 파악할 수 있는 정보

각 작업이 가장 빠르게 시작할 수 있는 시각 (earliest start time)

각 작업이 최대한 빠르게 끝날 수 있는 시각 (earliest finish time)

각 작업을 최대로 늦추어 시작할 수 있는 시각 (latest start time)

각 작업을 최대로 늦추어 끝낼 수 있는 시각 (latest finish time)

 작업의 순서는 물론 엔지니어의 적기 투입에 중요한 역할을 한다 . 임계 경로 (critical path)

프로젝트를 마치는데 있어서 가장 기간을 많이 차지하는 경로

임계 경로 내의 작업이 늦어지면 프로젝트 전체 일정이 늦어진다 .

관리자는 임계 경로의 작업에 많은 신경을 써야 한다 .

(42)

Page 42

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

(43)

CPM 네트워크 특징

계획 (Planning)

장점

관리자의 일정 계획 수립에 도움

프로젝트 안에 포함된 작업 사이의 관계를 파악할 수 있음

병행 작업 계획  Parallel Processing 가능

일정 시뮬레이션

일정 점검 , 관리

관리에 대한 작업도 포함 가능

작업 시간의 정확한 예측 필요

소프트웨어 도구

MS Project, MS Works 등

Page 43

(44)

Page 44

MS Project 의 CPM 네트워크 예제

계획 (Planning)

(45)

프로젝트 일정표 ( 간트 차트 , Gannt Chart)

계획 (Planning)

소작업별로 작업의 시작과 끝을 나타낸 그래프 예비시간 (slack time) 을 보여줌

예비시간 : 다음 작업에 영향을 주지 않고 연장 가능한 시간

계획 대비 진척도를 표시할 수 있음  프로젝트 일정 관리에 활용 개인별 일정표 작성 가능  언제 투입하고 , 언제 휴가가고…

일반적인 간트 차트의 구성

세로를 일정축으로 하여 작업을 가로의 막대로서 표시함

막대의 흰 부분 : 예상 소요 기간

막대의 회색 부분 : 예비시간

(46)

Page 46

간트 차트 예제

계획 (Planning)

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4 T1

T2

M1 T7T3

M5 T8

M3 M2 T6 T5

M4 T9

M7 T10

M6 T11

M8 T12

Start

Finish

(47)

MS Project 의 간트 차트 예제

계획 (Planning)

(48)

Page 48

애자일 계획

계획 (Planning)

스토리 카드 ( 포스트잇 ) 같은 도구로 , 업무의 순서는 물론 우선 순위 , 연관성 등을 정렬하여 표현

애자일 프로세스의 일정 계획 사례

장점

높은 우선순위를 가진 사용 사례가 조기에 개발되어 설치된다는 확신이 가질 수 있다 .

사용 사례 사이에 선행관계를 지킬 수 있다 .

각 열의 점수의 합은 개발 팀의 작업속도를 초과 하지 않아야 한다 .

(49)

In this chapter …

프로젝트 관리

3.1 프로젝트 범위 3.2 노력 추정

3.3 일정 계획 3.4 조직 계획 3.5 위험 관리

3.6 계획서 작성과 도구

계획 (Planning)

(50)

Page 50

조직 계획

계획 (Planning)

조직의 구성

소프트웨어 개발 생산성에 큰 영향

작업의 특성과 팀 구성원 사이의 의사 교류

프로젝트의 구조

프로젝트별 조직 : 프로젝트 시작에서 개발 완료까지 전담 팀 구성

기능별 조직

 계획수립 분석팀 , 설계 구현 팀 , 테스트 및 유지보수 팀

 파이프라인 (pipeline) 식 공정

매트릭스 조직 ( 인력 풀 제도 )

 요원들은 고유 관리 팀과 기능 조직에 동시에 관련

 필요에 따라 요원을 차출 팀을 구성하고 끝나면 원래의 소속으로 복귀

(51)

조직 구성의 노하우 ?

계획 (Planning)

경험이 많은 사람과 적은 사람을 적당히 혼합한다 .

경험 많은 사람만 모아놓으면 배가 산으로 갈 것이다 .

경험 적은 사람만 모아놓으면 아예 배를 만들지 못할 것이다 .

적당히 섞어 놓으면 , 경험과 노하우가 자연스럽게 전수되는 이점이 있다 .

이직의 최소화가 대규모 프로젝트의 성패를 좌우한다 .

프로젝트 후반에 새로운 인원이 투입되면 그만큼 일정이 지연된다 .

기간 단축을 위해서 인원을 추가 투입하는 것은 의미가 없다 .

프로젝트를 너무 잘게 나누면 , 팀 ( 모듈 ) 간 의사 교환 문제가 발생한

(52)

Page 52

책임 프로그래머 팀 조직 (1/2)

계획 (Planning)

의사 결정권이 리더에게 집중 계층적 팀 구조

책임 프로그래머 팀 (Chief Programmer Team)

외과 수술 팀 구성에서 따옴

책임 프로그래머 : 제품설계 , 주요부분 코딩 , 중요한 기술적 결정 , 작업의 지시

프로그램 사서 : 프로그램 리스트 관리 , 설계 문서 및 테스트 계획 관리

보조 프로그래머 : 기술적 문제에 대하여 논의 , 고객 / 출판 / 품질 보증 그룹과 접촉 , 부 분적 분석 / 설계 / 구현을 담당

프로그래머 : ( 책임 프로그래머의 지시에 따라 ) 각 모듈을 프로그래밍

(53)

책임 프로그래머 팀 조직 (2/2)

계획 (Planning)

특징

의사 결정이 빠름

소규모 프로젝트에 적합

초보 프로그래머를 훈련시키는 기회로 적합

단점

한 사람의 능력과 경험이 프로젝트의 성패 좌우  책임 프로그래머의 선정 문제 책임프로그래머

프로그램 사서 프로그래머 보조 프로그래머

백업

(54)

Page 54

에고레스 (Egoless) 팀 조직

계획 (Planning)

민주주의식 의사 결정

서로 협동하여 수행하는 비이기적인 팀

자신이 있는 일을 알아서 수행

구성원이 동등한 책임과 권한

다각도의 의사 교환 경로 제공 특징

작업 만족도 높음 ( 이직률이 낮음 )

의사 교류 활성화

장기 프로젝트에 적합

단점

책임이 명확하지 않은 일이 발생

대규모에 적합하지 않음 ( 의사 결정 지연 가능 )

(55)

계층적 팀 조직

계획 (Planning)

집중형 , 분산형의 단점을 보완

특징

초보자와 경험자를 분리

프로젝트 관리자와 고급 프로그래머에게 지휘권한이 주어짐

의사교환은 초보 엔지니어나 중간 관리층으로 분산

소프트웨어에 따라 계층적으로 분산됨

단점

(56)

Page 56

In this chapter …

프로젝트 관리

3.1 프로젝트 범위 3.2 노력 추정

3.3 일정 계획 3.4 조직 계획 3.5 위험 관리

3.6 계획서 작성과 도구

계획 (Planning)

(57)

위험 분석과 관리란 ?

계획 (Planning)

( 내재된 ) 위험 요소를 인식하고 그 영향을 분석하여 관리

실패에 영향을 미칠 위험 요소 인식하고 그 대책 수립

인력의 부족  인력의 적극적 유치 , 팀 구성 시 고려 , 교차교육 등

일관성 있는 해결 방안 ( 누가 못하면 , 조금 여유 있는 옆 사람이 한다 ?)

 체계적이고 조직적인 해결 방안( 조수 / 사수 개념 , 중복 배치 등 )

비용에 많은 영향을 미치는 요소  리스크

요구분석의 변경

 위험 감소 방안  프로토타이핑 , 설문지 , 리뷰

일정 지연의 위험

(58)

Page 58

위험 관리 (Risk Management)

계획 (Planning)

위험 관리의 목적 : 위험이 발생되었을 때의 영향을 최소화 Boehm 이 제안한 위험 관리 [Boehm, 1991]

위험 파악

위험 분석

위험 우선순위 정하기

위험 해결

위험 모니터링

(59)

위험 요소 위험 관리 기법

1. 인력 부족  유능한 인력모집 , 팀 구성 , 요원 배치

 교차 - 교육 , 유능 인력 사전 확보

2. 비현실적 일정 및 예산  더 자세한 비용 , 일정 예측 , 원가 분석

 점증적 개발 , 소프트웨어 재사용 요구를 줄임

3. 잘못된 기능의 소프트웨어 개발

 사용자 회람 , 프로토타이핑

 사용자 지침서 조기 작성 , 조직 분석 , 직능 분 석

4. 잘못된 인터페이스의 개발  프로토타이핑 , 시나리오 , 태스크 분석

 사용자 분류 ( 기능 , 스타일 , 업무 )

 요구 삭감 , 프로토타이핑

(1) 위험 파악 (1/2)

계획 (Planning)

(60)

Page 60

위험 요소 위험 관리 기법

6. 계속적인 요구 변경  최대 변경 상한선 , 정보 은닉

 점증적 개발 ( 다음 버젼까지 변경을 연기 ) 7. 외부 모양의 빈약  벤치마킹 , 검사 , 대조 확인 , 성숙도 분석 8. 외부 기능의 빈약  대조 확인 , 사전 검증 , 설계 경연 , 팀 작업

9. 실시간 성능의 빈약  시뮬레이션 , 벤치마킹 , 모델링 , 프로토타이핑 , 튜닝 10. 기술적 취약  기술 분석 , 비용 - 수익 분석 , 프로토타이핑 , 점검

(1) 위험 파악 (2/2)

계획 (Planning)

(61)

(2) 위험 분석 , (3) 위험 우선순위 정하기

계획 (Planning)

위험 분석 : 각 위험에 대한 피해 정도 , 위험 해결 방법 , 이에 대한 비용 등을 결정하는 것이다 .

손실 발생 확률

손실 발생 규모

위험 노출 (exposure)

우선 순위 정하기 : 위험 중에서 대처할 항목들의 우선 순위를 정한다 .

고위험 , 고비용 위험을 우선 ?

저위험 , 저비용 위험을 우선 ?

(62)

Page 62

(4) 위험 해결 , (5) 위험 모니터링

계획 (Planning)

위험 해결 : 위험 관리 계획에 명시된 위험을 줄이는 기법을 구현하고 실 행하는 것이다 .

위험 모니터링 : 위험 경감을 위한 정책이 일정대로 잘 구현되고 실행되 는지 감시하는 것이다 .

위험 관리 프로세스 도식화

(63)

In this chapter …

프로젝트 관리

3.1 프로젝트 범위 3.2 노력 추정

3.3 일정 계획 3.4 조직 계획 3.5 위험 관리

3.6 계획서 작성과 도구

계획 (Planning)

(64)

Page 64

계획서 작성 (1/3)

계획 (Planning)

1. 개 요

1.1 프로젝트 개요

1.2 프로젝트의 산출물 1.3 정의 , 약어

2. 자원 및 일정 예측 2.1 자원

가 . 인력 나 . 비용 2.2 일정

3. 조직 구성 및 인력 배치 3.1 조직 구성

3.2 직무 기술

(65)

계획서 작성 (2/3)

계획 (Planning)

4. WBS

5. 기술관리 방법 5.1 변경 관리 5.2 위험 관리

5.3 비용 및 진도 관리 5.4 문제점 해결 방안 6. 표준 및 개발 절차

6.1 개발 방법론 7. 검토 회의

7.1 검토회 일정

(66)

Page 66

계획서 작성 (3/3)

계획 (Planning)

8. 개발 환경

9. 성능 시험 방법 10. 문서화

11. 유지보수 12. 설치 , 인수

13. 참고문헌 및 부록

(67)

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

계획 (Planning)

(68)

Page 68

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

계획 (Planning)

(69)

도구

계획 (Planning)

프로젝트 계획과 관리 도구

노력 추정을 위한 도구 – COCOMO

일정 계획 및 진도 관리 도구 – MS Project

문서 및 버전 관리 도구 – Github

(70)

Page 70

도구 사례 – COCOMO II

계획 (Planning)

(71)

도구 사례 – MS Project

계획 (Planning)

(72)

Page 72

도구 사례 – Github

계획 (Planning)

(73)

In this chapter …

프로젝트 관리

3.1 프로젝트 범위 3.2 노력 추정

3.3 일정 계획 3.4 조직 계획 3.5 위험 관리

3.6 계획서 작성과 도구

계획 (Planning)

(74)

Page 74

Homework #2

계획 (Planning)