국립중앙도서관 출판시도서목록(cip)†Œ프트웨어프로젝트관리... · 8.4...

소프트웨어 프로젝트 관리 / 고석하 지음. -- 개정3판. -- 파주 : 생능출판사, 2014 p. ; cm

ISBN 978-89-7050-794-1 93320 : ￦27000

프로젝트 관리[--管理]프로젝트[project]

325.431-KDC5658.4038-DDC21 CIP2014002516

국립중앙도서관 출판시도서목록(CIP)

3

P R E F A C E

개정 3판 머리말

이번 개정에서는 2013년 초에 발표된 PMI의 A Guide to the Project

Management Body of Knowledge ver.5에서 추가되거나 변경된 내용을 반영하

였다. 또한, 프로그램 관리에 대한 PMI의 2008년의 The Standard for Program

Management, ver.2의 내용을 추가하였으며, 프로그램 관리의 관점에서 소프트

웨어의 개발부터 폐기까지의 전체 생애주기에 걸친 총 소유비용을 어떻게 최소화

할 것인가에 대한 간단한 논의를 추가하였다.

프로젝트project는 특정 결과물을 생성한 후에 종료되는 한시적이고 유일한 노력

이다. 프로젝트가 한시적이라는 것은 명확한 시작과 종료 시점을 가진다는 뜻이

다. 반면에 운영operation은 프로젝트의 결과물을 지속적이고 반복적으로 이용하

고 관리하는 노력이다. 일반적으로 작업은 프로젝트와 운영으로 분류할 수 있다.

특히, 지식은 일반적으로 프로젝트에 의해서 생성되며 프로젝트에 의해서 생산

활동에 적용된다. 이러한 이유로, 산업 사회에서 정보화 사회를 거쳐서 지식 사회

로 진입하고 있는 현재 프로젝트의 중요성이 나날이 증대하고 있다.

프로세스는 특정 제품, 결과 또는 서비스의 성취를 위해 수행되는 상호 연관

된 행동과 활동들의 집합이다. 프로젝트의 프로세스는 크게 2가지로 분류할 수

있다.

● 제품(종속) 프로세스product-oriented process: 프로젝트의 결과물을 정의하고 생성

한다. 그 구체적인 내용은 응용 영역에 따라서 매우 다양하다.

● 관리 프로세스management process: 프로젝트를 개시하고, 작업 계획을 개발하며

구체적인 관리 활동을 수행하고, 진행 상황을 모니터하고 통제하며 프로젝

트를 종료시킨다. 모든 프로젝트에서 공통적이다.

프로젝트에서 관리 프로세스와 제품 프로세스는 서로 겹치며, 그 수행 동안에

4

P R E F A C E 상호작용한다. 예를 들면, 프로젝트의 범위는 목표로 하는 제품을 어떻게 만들 것

인가에 대한 기본적인 이해가 없이는 정의될 수 없다.

그러나 프로젝트 관리에 관한 지식들은 제품 프로세스와는 독립적으로 발전시

킬 수 있다. 프로젝트 관리와 관련된 국제적인 기구인 PMIProject Management Institute

에서는 제품 프로세스에 의해서 직접적으로는 영향을 받지 않는, 프로젝트 관리

를 위한 지식을 주기적으로 정리하여 하나의 지식 체계Body of Knowledge로 발표한

다. PMI는 2013년에 제5판을 발표하였다. 제5판에서는 프로젝트 관리와 관련된

지식을 크게 10개 영역으로 분류하였다.

이 책은 크게 세 부분으로 구성되어 있다. 이 책의 제I부에서는 프로젝트 관리

에 대한 기초 이론을 간단히 소개하였다. 제1장에서는 프로젝트란 무엇인가와 소

프트웨어 프로젝트의 특수성에 대하여 간단히 설명하였다. 제2장에서는 PMI의

프로젝트 관리 모형과 프로그램 관리 모형의 개요를 설명하였다. 프로그램이란

상호 연관된 프로젝트들의 집합으로, 해당 프로그램의 생애주기 내에서 시작되는

프로젝트들을 개별적으로 관리해서는 얻을 수 없는 이익을 관리하고 통제하기 위

해서 연계된 방법으로 관리되는 것들을 말한다.

제II부에서는 프로젝트 관리 프로세스들을 10개의 지식 영역별로 자세히 설명

하였다. 제3장부터 12장까지는 해당 프로젝트 관리 지식 영역에 대한 일반적인

내용을 먼저 소개하고, 소프트웨어 프로젝트 관리에 특유한 내용은 나중에 소개

하였다.

제III부에서는 소프트웨어 개발 프로젝트의 제품 프로세스와, 그것을 기반으

로, 제품 프로세스와 관리 프로세스 간의 상호작용에 대해서 소개하였다. 제13장

에서는 대표적인 소프트웨어 제품 프로세스 모델들을 소개하였다. 제14장과 제15

장에서는 전형적인 소규모 웹사이트 개발 프로젝트와 대규모 비즈니스 프로세스

응용 소프트웨어 개발 프로젝트의 제품 프로세스를 각각 가장 대표적인 소프트웨

어 제품 프로세스 모델 중의 하나인 폭포수 모델과 UPUnified Process에 기반하여 설

명하였다. 제14장과 제15장에서는 또한 관리 프로세스가 구체적인 제품 프로세스

에 따라 어떻게 조정되어야 하는가를 설명하였다.

5

P R E F A C E

이 책의 가장 큰 특징은 프로젝트의 제품 프로세스와 관리 프로세스를 엄격히

분리하여 소개하였다는 것이다. 이러한 관점에서는 이 책은 소프트웨어 프로젝트

의 예를 이용한 일반적인 프로젝트 관리에 대한 책으로 간주될 수도 있다. 이러한

구성을 선택한 이유는, 구체적인 제품 프로세스를 함께 고려하지 않고는 관리 프

로세스에 대해서도 바르게 이해할 수 없기 때문이다.

이 책의 또 하나의 특징은 너무 전문적이거나 소프트웨어 프로젝트에만 특유

한 내용들은 가급적 본문의 내용으로부터 분리하여 독립된 “Box” 안에 따로 정리

하였다는 것이다. Box 안의 내용은 되도록 그림이나 표를 이용하여 설명함으로써

이해를 높이도록 하였다. 특히 전문성이 높거나 내용이 긴 것은 각 장의 부록에

수록하였다. 이러한 모듈러한 양식은 실무자들이 현업에서 필요한 내용들을 그때

그때 확인하거나, 대학에서 강의 내용을 맞춤화하는 데에 편리할 것으로 기대한

다. 일반적인 프로젝트 관리에 대한 입문을 위해서는 Box의 내용은 선택적으로

학습하면 된다.

부족한 점이 매우 많지만, 천릿길도 한 걸음부터라는 마음으로 계속 개정하고

개선하여 우리나라 소프트웨어 산업의 발전과 지식입국에 조금이라도 보탬이 될

수 있기를 바란다. 비록 졸고이나마 이 책이 나올 수 있도록 도와주신 모든 분들

께 감사드린다.

2014년 2월

고석하

6

C O N T E N T S 차례

소프트웨어 프로젝트 관리 개요PART 01

프로젝트 관리와 소프트웨어 개발의 기초CHAPTER 011.1 프로젝트 관리 개요 18

1.1.1 프로젝트 18

1.1.2 프로젝트 관리 20

1.1.3 프로젝트 생애주기 27

1.1.4 프로그램과 프로그램 관리 32

1.2 소프트웨어 개발 프로젝트 361.2.1 소프트웨어 프로젝트의 특수성 36

1.2.2 소프트웨어 프로젝트를 성공적으로 수행하기 위해서

필요한 지식 38

부록 1A 소프트웨어 프로젝트 성공 요인과 실패 요인 40

PMI의 프로젝트 및 프로그램 관리 모델CHAPTER 022.1 PMI 프로젝트 관리 모델의 개요 48

2.1.1 프로젝트 관리 프로세스의 분류 48

2.1.2 프로젝트 관리 프로세스 그룹 50

2.1.3 프로젝트 관리 프로세스 그룹과의 상호작용 53

2.1.4 다단계 프로젝트 56

2.2 PMI 프로그램 관리 모델의 개요 582.2.1 프로그램 프로세스 그룹 58

2.2.2 프로그램 생애주기와 단계관문 검토 62

2.2.3 프로그램 효익 관리와 거버넌스 관리 64

2.2.4 프로그램 단계들 70

부록 2A 계획과 통제 76

부록 2B 프로그램 관리 문서들 83

부록 2C 소프트웨어 아키텍처의 정의 및 구성요소 88

부록 2D 소프트웨어 생애주기 모델과 프로그램 관리:

부록 확장된 나선형 모델 96

7

C O N T E N T S

PMI 프로젝트 관리 프로세스PART 02

프로젝트 통합 관리CHAPTER 033.1 프로젝트 통합 관리 프로세스들 104

3.1.1 프로젝트 헌장을 개발하기 프로세스 107

3.1.2 프로젝트 관리 계획을 개발하기 프로세스 110

3.1.3 프로젝트 작업을 지시하고 관리하기 프로세스 115

3.1.4 프로젝트 작업을 모니터하고 통제하기 프로세스 118

3.1.5 통합 변경 통제를 수행하기 프로세스 119

3.1.6 프로젝트 또는 단계를 종료하기 프로세스 122

3.2 의사결정 1233.2.1 의사결정이란? 123

3.2.2 합리적 의사결정 과정 125

3.2.3 정보의 가치 127

3.3 변경관리 129

부록 3A 의사결정분석: A소프트웨어사 프로젝트 사례 133

부록 3B 소프트웨어 형상 관리 136

프로젝트 이해관계자 관리CHAPTER 044.1 프로젝트 의사소통 관리 프로세스들 142

4.1.1 이해관계자를 확인하기 프로세스 142

4.1.2 이해관계자 관리 계획을 개발하기 프로세스 146

4.1.3 이해관계자 참여를 관리하기 프로세스 147

4.1.4 이해관계자 참여를 통제하기 프로세스 149

4.2 프로젝트 이해관계자 149

4.2.1 프로젝트 이해관계자의 종류 149

4.2.2 사용자 및 과업 분석 153

프로젝트 범위 관리CHAPTER 055.1 프로젝트 범위 관리 프로세스들 158

5.1.1 범위 관리 계획을 개발하기 프로세스 160

5.1.2 요구사항을 수집하기 프로세스 161

5.1.3 범위를 정의하기 프로세스 163

5.1.4 WBS를 생성하기 프로세스 167

8

C O N T E N T S 5.1.5 범위를 입증하기 프로세스 169

5.1.6 범위를 통제하기 프로세스 169

5.2 요구사항 밝히기 기법 : 집단 창조성 기법 1705.2.1 브레인스토밍 170

5.2.2 명목 집단 기법 171

5.2.3 델파이 방법 174

5.2.4 아이디어/마인드매핑 175

5.2.5 친화도 175

5.3 요구사항을 밝히기 위한 고객과 개발자의 공동 작업 1785.3.1 요구사항 워크숍 178

5.3.2 JAD 179

5.4 WBS 작성 방법 1825.4.1 WBS 개요 182

5.4.2 100% 규칙 184

5.4.3 WBS 품질 평가 기준 184

5.4.4 WBS 개발 절차 186

5.5 소프트웨어 요구사항 프로세스 1895.5.1 요구사항 밝히기 189

5.5.2 쓰임새 모델링 195

부록 5A POS 시스템 쓰임새 모델(예) 203

프로젝트 시간 관리CHAPTER 066.1 프로젝트 시간 관리 프로세스들 214

6.1.1 일정 관리 계획을 개발하기 프로세스 219

6.1.2 활동을 정의하기 프로세스 221

6.1.3 활동을 배열하기 프로세스 221

6.1.4 활동을 자원 추정하기 프로세스 221

6.1.5 활동을 기간 추정하기 프로세스 222

6.1.6 일정을 개발하기 프로세스 223

6.1.7 일정을 통제하기 프로세스 223

6.2 프로젝트 시간 관리 기법 및 도구 2246.2.1 간트 도표 224

6.2.2 PERT/CPM 227

6.3 예측과 추정 2356.3.1 예측 235

6.3.2 추정 237

9

C O N T E N T S

6.4 소프트웨어 규모 척도와 노력 추정 2406.4.1 소프트웨어 규모 척도 240

6.4.2 소프트웨어 프로젝트 노력 추정 247

부록 6A A소프트웨어사 프로젝트 사례 251

부록 6B 활동 시간의 불확실성과 일정 위험의 PERT/CPM을

부록 6B 이용한 관리 258

프로젝트 비용 관리CHAPTER 077.1 프로젝트 비용 관리 프로세스들 270

7.1.1 비용 관리 계획을 개발하기 프로세스 272

7.1.2 비용을 추정하기 프로세스 273

7.1.3 예산을 결정하기 프로세스 275

7.1.4 비용을 통제하기 프로세스 275

7.2 프로젝트 원가 278

7.3 프로젝트 경제성 분석 2797.3.1 회수기간법 280

7.3.2 평균 회계이익률법 280

7.3.3 순현가법 280

7.3.4 수익성 지수법 281

7.3.5 내부수익률법 282

7.4 프로젝트 비용 관리 활동 2827.4.1 원가 추정 283

7.4.2 원가 예산 책정 284

7.4.3 비용 통제 284

7.5 획득 가치 분석 286

7.6 프로젝트 관리 계획의 갱신 291

프로젝트 품질 관리CHAPTER 088.1 프로젝트 품질 관리 프로세스들 296

8.1.1 품질 관리 계획을 개발하기 프로세스 300

8.1.2 품질 보증을 수행하기 프로세스 301

8.1.3 품질 통제를 수행하기 프로세스 302

8.2 품질의 정의 및 종류 3058.2.1 품질의 정의 305

8.2.2 품질의 종류 307

10

C O N T E N T S 8.2.3 품질의 측정 : 외부 메트릭과 내부 메트릭 309

8.3 품질 비용과 프로세스 개선 3108.3.1 품질 비용 310

8.3.2 프로세스 품질과 프로세스 개선 312

8.4 품질 관리 기법 및 도구 3138.4.1 품질 관리의 발전 313

8.4.2 품질분임조 315

8.4.3 자료 수집 및 통계적 분석 315

8.4.4 기본적인 품질 관리 도구 318

부록 8A 식스 시그마 및 린 식스 시그마 323

부록 8B 품질 기능 전개 326

부록 8C ISO 9126 소프트웨어 품질 분류 체계 332

프로젝트 인적자원 관리CHAPTER 099.1 프로젝트 인적자원 관리 프로세스들 338

9.1.1 인적자원 계획을 수립하기 프로세스 340

9.1.2 프로젝트 팀을 획득하기 프로세스(실행) 342

9.1.3 프로젝트 팀을 개발하기 프로세스 344

9.1.4 프로젝트 팀을 관리하기 프로세스 346

9.2 조직화 및 직무 설계 3489.2.1 조직화의 기본 원칙 348

9.2.2 조직 구조의 유형 349

9.2.3 직무 설계 354

9.3 충원 3559.3.1 채용 계획 356

9.3.2 모집 356

9.3.3 선발 357

9.4 인적 자원 개발 3599.4.1 인적 자원 개발의 의미 359

9.4.2 교육 및 훈련 방법 360

9.5 동기 부여 3619.5.1 매슬로의 욕구단계설 362

9.5.2 맥그리거의 X/Y이론 363

9.5.3 허즈버그의 동기-위생이론 364

9.5.4 브룸의 기대 이론 365

9.5.5 ERG 이론 366

11

C O N T E N T S

9.5.6 맥클러랜드의 욕구 이론 367

9.5.7 인지적 평가 이론 368

9.5.8 목표 설정 이론 368

9.5.9 공정성 이론 369

9.6 평가와 보상 371

프로젝트 의사소통 관리CHAPTER 1010.1 프로젝트 의사소통 관리 프로세스들 374

10.1.1 의사소통 관리 계획을 개발하기 프로세스 376

10.1.2 의사소통을 관리하기 프로세스 378

10.1.3 의사소통을 통제하기 프로세스 379

10.2 의사소통 관리 38110.2.1 의사소통이란 381

10.2.2 의사소통 네트워크의 형태 382

10.2.3 공식적, 비공식적 의사소통 384

10.2.4 효율적 의사소통 385

10.3 리더십 38710.3.1 리더십과 리더 387

10.3.2 리더십의 유형 388

10.3.3 상황론적 리더십 389

10.3.4 팀 임파워링 리더십 391

10.4 갈등 관리 39310.4.1 갈등이란 393

10.4.2 갈등의 관리 394

10.4.3 협상 396

프로젝트 조달 관리CHAPTER 1111.1 프로젝트 조달 관리 프로세스들 400

11.1.1 조달 관리 계획을 수립하기 프로세스 407

11.1.2 조달을 수행하기 프로세스 410

11.1.3 조달을 통제하기 프로세스 412

11.1.4 조달을 종결하기 프로세스 414

11.2 구매 관리 41511.2.1 구매란 415

11.2.2 구매 절차 418

12

C O N T E N T S 11.3 자재 관리 420

11.3.1 자재 발주 420

11.3.2 자재 보관 423

11.4 계약 관리 42411.4.1 개요 424

11.4.2 인센티브 427

11.4.3 고정 가격 계약의 형태 429

11.4.4 원가 배상 계약의 형태 431

11.4.5 비확정 납품계약 433

11.4.6 기타 계약들 433

프로젝트 위험 관리CHAPTER 1212.1 프로젝트 위험 관리 프로세스들 436

12.1.1 위험 관리 계획을 개발하기 프로세스 439

12.1.2 위험을 식별하기 프로세스 443

12.1.3 정성적 위험 분석을 수행하기 프로세스 448

12.1.4 정량적 위험 분석을 수행하기 450

12.1.5 위험 대응 계획을 개발하기 452

12.1.6 위험을 통제하기 454

12.2 위험 분석 45812.2.1 위험 노출도 458

12.2.2 위험의 우선순위 459

12.2.3 민감도 분석과 위험 감소 리버리지 461

12.3 위험 대응전략 46212.3.1 부정적 위험에 대한 전략 462

12.3.2 긍정적 위험에 대한 전략 465

12.3.3 위험과 기회에 대한 전략 466

12.3.4 상황 대응 전략 466

12.4 Win-Win 나선형 모델 46612.4.1 나선형 모델의 개요 466

12.4.2 프로토타이핑에 의한 위험의 최소화와 그 한계 468

12.4.3 위험 해소 정도에 의존적인 프로세스 전개 472

12.4.4 나선형 모델의 장단점 472

부록 12A 확인과 입증: 부정적 소프트웨어 위험에 대한 완화 전략 473

부록 12B AHP에 의한 상대적 중요도의 평가 477

13

C O N T E N T S

소프트웨어 제품 프로세스PART 03

소프트웨어 프로세스 모델CHAPTER 1313.1 소프트웨어 프로세스 모델이란 무엇인가? 484

13.1.1. 소프트웨어 프로세스 모델과 소프트웨어 방법론 484

13.1.2 소프트웨어 프로세스 모델과 소프트웨어 프로젝트 범위 관리 485

13.2 폭포수 모델 48713.2.1 폭포수 모델의 절차 487

13.2.2 폭포수 모델의 장단점 489

13.3 진화적 개발 모델 49313.3.1 진화적 개발 모델의 절차 493

13.3.2 진화적 개발 모델의 장단점 493

13.4 증분적 인도 모델 49513.4.1 증분적 인도 모델의 절차 495

13.4.2 증분적 인도 모델의 장단점 496

13.4.3 DSDM : 증분적 인도 모델의 예 497

13.5 전환 모델과 제4세대 모델 50513.5.1 전환 모델의 절차 505

13.5.2 전환 모델의 장단점 506

13.5.3 제 4세대 모델과 제 4세대 기법 506

13.6 소프트웨어 프로세스 모델들의 비교 509

웹 사이트 개발 프로젝트CHAPTER 1414.1 웹 사이트 개발 프로젝트 진행 절차 512

14.2 프로젝트 초기화 514

14.3 요구사항 분석 517

14.4 아키텍처 설계 52114.4.1 정보 아키텍처 설계 522

14.4.2 소프트웨어 아키텍처 설계 523

14.4.3 기타 기술 및 개발 전략 523

14.5 상세 설계 53014.5.1 디자인 설계 530

14.5.2 데이터베이스 상세 설계 531

15.5.3 프로그램 상세 설계 541

14

C O N T E N T S 14.6 구현 541

14.7 통합 및 테스트 545

14.8 인도 및 운영 546

대규모 비즈니스 시스템 개발 프로젝트CHAPTER 1515.1 UP: Unified Process 548

15.1.1 UP의 기본 개념 548

15.1.2 UP의 디시플린 549

15.1.3 UP의 작업 단계 549

15.1.4 UP에 의거한 프로젝트 관리 프로세스 554

15.2 인셉션 55715.2.1 비즈니스 모델과 소프트웨어 모델 간의 관계 557

15.2.2 비즈니스 모델이 소프트웨어 모델링에서 맡아야 할 역할 557

15.2.3 비즈니스 프로세스 모델링 560

15.2.4 도메인 모델 562

15.2.5 모델-뷰 분리 원칙 562

15.3 일래버레이션 56415.3.1 쓰임새 모델과 계약 564

15.3.2 아키텍처 분석 565

15.4 컨스트럭션 57015.4.1 쓰임새 실체화: 설계 모델의 작성 570

15.4.2 구현 : 설계를 코드로 전환시키기 571

15.4.3 구현 과정에서 획득된 정보의 피드백 573

부록 15A UML: Unified Modeling Language 473

■ 참고문헌 581

■ 찾아보기 584

01P A R T

소프트웨어 프로젝트 관리 개요

CHAPTER 01 프로젝트 관리와 소프트웨어 개발의 기초

CHAPTER 02 PMI의 프로젝트 및 프로그램 관리 모델

제1부에서는 프로젝트 및 프로그램 관리에 대한 기초적인 지식을 PMIProject Management

Institute가 2013년에 출판한 <A Guide to the Project Management Body of Knowledge,

Ver.5>와 2008년에 출판한 <The Standard for Program Management, Ver.2>의 개요에 대해

살펴볼 것이다.

제1장에서는 프로젝트와 프로그램이 무엇이며, 프로젝트 및 프로그램의 한 종류로서 소프트웨

어 프로젝트 및 프로그램의 특수성은 무엇인가에 대해서 설명한다. 프로젝트와 프로그램은 프

로세스에 의해서 수행된다. 프로젝트 프로세스는 크게 제품(종속) 프로세스와 프로젝트 관리

프로세스로 분류할 수 있다. 프로젝트 관리 프로세스와 제품 프로세스는 서로 겹치며, 프로젝

트가 수행되는 동안 상호작용한다. 예를 들면, 프로젝트의 범위는 목적으로 삼는 제품을 어떻

게 만들 것인가에 대한 기본적인 이해 없이는 정의될 수 없다.

이 책에서는 프로젝트 관리에 대해서 효과적으로 설명하기 위해 필요하다고 생각되는 범위에

한해서 제품 프로세스에 관해 설명하였다. 이러한 경우에도 다양한 종류의 제품 프로세스를

이용하여 관리 프로세스에 대해서 설명하는 것은 혼란을 유발할 수 있다. 따라서 이 책에서는

소프트웨어를 이용하여 일관성 있게 프로젝트 관리 프로세스 자체뿐만 아니라 프로젝트 관리

프로세스와 제품 프로세스 간의 상호작용에 대해서 설명하였다. 제1장에서는 앞으로의 일관성

있는 설명을 위해 소프트웨어 프로젝트의 특수성에 대해서 설명할 것이다.

제2장에서는 <A Guide to the Project Management Body of Knowledge, Ver.5>1)의 프로젝트

관리 모델과 <The Standard for Program Management, Ver.2>2)의 프로그램 관리의 전체적

인 구조에 대해서 설명할 것이며, 이를 위해서 관리의 기본 요소인 계획과 통제를 PCDAPlan-

Do-Check-Act 사이클의 관점에서 간단히 설명하고 거버넌스governance 개념을 소개할 것이

다. PDCA 사이클은 프로젝트 수행 기간에 얻어진 경험을 분석하고 그 결과를 다음 프로젝트

에 피드백함으로써 생산성을 향상시키는 기제를 말한다. 또한 프로그램 관리의 관점에서 아키

텍처 침식architecture erosion을 방지함으로써 소프트웨어의 전체 생애 주기에 걸친 총비용을

어떻게 최소화할 것인가에 대해서 간단히 설명할 것이다.

1) 앞으로는 ‘PMBoK2013’으로 표시하겠다.

2) 앞으로는 ‘StdPgM2008’로 표시하겠다.

프로젝트 관리와 소프트웨어 개발의 기초

01C H A P T E R

1.1 프로젝트 관리 개요

1.2 소프트웨어 개발 프로젝트

부록 1A 소프트웨어 프로젝트 성공 요인과 실패 요인

18

이 장에서는 다음의 사항을 중심으로 프로젝트 관리와 소프트웨어 개발에 관한 기본적 개념들에 대

해서 알아본다.

● 프로젝트, 프로그램, 포트폴리오의 차이

● 제품 프로세스와 관리 프로세스의 차이

● 소프트웨어 개발 프로젝트의 특수성

CH

AP

TE

R

01 프로젝트 관리와 소프트웨어 개발의 기초

프로젝트 관리 개요1.1

1.1.1 프로젝트1)

PMIProject Management Institute의 정의에 의하면, 프로젝트project는 유일한 제품, 서

비스 혹은 결과를 만들어 내기 위해 수행되는 한시적으로 수행되는 점진적인 노

력이다. 여기에서 ‘한시적’, ‘유일한’, ‘점진적’의 의미는 다음과 같다.

● 한시성 : 한시적이라는 의미는 모든 프로젝트가 명확한 시작과 명확한 종료를

가진다는 의미이다. 프로젝트는 그 수행 목표들이 달성되었거나, 목표를 달성하

는 것이 불가능하다는 것이 명확해지거나, 또는 더 이상의 프로젝트 수행에 대

한 필요성이 없어졌을 경우에 프로젝트가 종료된다. 일시적이라는 의미가 반드

시 기간의 짧음을 의미하진 않으며, 실제 다수의 프로젝트가 몇 년씩 지속되는

경우도 있다. 하지만 어떠한 경우에도 프로젝트의 수행 기간은 한정되어 있다.

● 유일성 : 프로젝트는 제품, 서비스, 또는 지식이나 정보와 같은 인도물을 생성하

며, 이러한 인도물은 유일하다. 예를 들면, 수많은 사무실 건물이 건설되어 왔

지만 위치나 형태 등이 완전히 같은 건물들은 한 쌍도 없다.

● 점진성 : 프로젝트 또는 프로젝트의 인도물은 점진적으로 구체화된다. 예를 들

1) PMBoK2008. pp.5-7, 12, 22-23, 37-38. “PMBoK2008”과 PMBoK2013은 각각 PMI가 2008년에

발표한 프로젝트 관리 표준 모델인 A Guide to the Project Management Body of Knowledge의 제4

판과 제5판을 의미한다. 이 책에 각주로 붙은 부분은 해당 부분을 정리하였다는 것을 의미한다.

CHAPTER

19

01프로젝트 관리와 소프트웨어 개발의 기초

면, 일반적으로 초기에는 프로젝트 범위(해야 할 일)가 대략적으로 기술되지만,

목표와 인도물에 대한 이해가 증진됨에 따라 프로젝트 범위는 좀 더 명확하고

구체적으로 기술된다. 프로젝트 명세서에 대한 점진적 구체화는2) 프로젝트가

계약에 의해 수행되는 경우에는 프로젝트 범위 정의와 함께 주의 깊게 조정되

어야 한다.

프로젝트 자체가 한시적이기 때문에 프로젝트를 수행하는 프로젝트 팀도 또한

한시적이다. 단일 프로젝트 수행을 위해 생성된 팀은, 그 프로젝트가 종료되면,

해체되고 팀원들은 재배치된다.

일반적으로 작업은 프로젝트와 운영operation으로 분류된다. 작업은 한 집합의

목적들을 달성하기 위해 수행하는 일이다. 프로젝트와 운영은 아래와 같은 공통

적인 특징들을 가지고 있다.

●사람에 의해 수행된다.

●한정된 자원으로 인해 제한받는다.

●계획되고, 수행되고, 통제된다.

그러나 프로젝트와 운영은 목표에 있어 근본적으로 차이가 있다. 프로젝트는

특정 인도물을 생성한 후에는 종료되는 한시적이고 유일한 노력인 반면에, 운영

은 인도물을 지속적이고 반복적으로 이용하고 관리하는 노력이다. 이러한 모든

노력들은 프로세스를 통해서 수행된다.

프로세스process는 특정 제품, 결과 또는 서비스의 성취를 위해 수행되는 상호

연관된 행동과 활동들의 집합이다. 프로젝트 프로세스는 프로젝트 팀에 의해 수

행되며, 프로세스의 종류는 두 가지로 분류할 수 있다.

● 제품 종속 프로세스product-oriented process : 프로젝트가 제품생성과 관련된 프로세

스로서, 응용 영역에 따라 매우 다양하다.

● 프로젝트 관리 프로세스project management process : 프로젝트의 관리, 즉 초기화, 계

2) 점진적 구체화와 혼동하면 안 될 개념으로 범위 확산이 있다. 범위 확산scope creep은 시간이 지남에 따

라서 범위 자체가 점점 확대되는 것을 말한다.

20

01 소프트웨어 프로젝트 관리 개요

P A R T

획, 수행, 모니터링 및 통제, 종료를 위한 프로세스인데, 모든 프로젝트에 공통

적이며 프로젝트 제품에 독립적이다.

프로젝트 관리 프로세스들은 응용 영역 또는 산업 분야와는 독립적이다. 그러

나 프로젝트 관리 프로세스와 제품 종속 프로세스는 서로 중복되는 부분이 있으

며, 프로젝트가 수행되는 동안 상호작용한다. 예를 들면, 프로젝트의 범위는 제품

을 어떻게 만들 것인가에 대한 기본적인 이해 없이는 정의될 수 없다.

산출물은 명세서, 타당성 조사 보고서, 상세 설계 문서 또는 작업 프로토타입과

같은 측정가능하고 검증가능한 작업결과이다. 프로젝트의 산출물 또한 그 프로세

스에 따라서 다음과 같이 크게 2가지로 분류할 수 있다.

● 프로젝트 관리 프로세스에 따른 결과

● 최종 제품 또는 계획된 최종 제품의 구성 요소

1.1.2 프로젝트 관리3)

관리management는 조직 목표를 달성하는 과정으로, 모든 종류의 조직과 모든 계

층에 적용된다. 기업의 경우에는, 유효성effectiveness과 효율성efficiency을 높임으로써

잉여를 창출하는 것이 목표이다. 관리 과정은 다음과 같이 크게 다섯 단계로 분류

할 수 있다.

① 계획planning : 사명missions과 목표objectives, 그리고 이들을 달성하기 위한 행동 방

안을 선택하는 것, 미래에 대해서 예측하고, 미래의 행동과정에 대한 여러 가

지 대안을 작성하고, 이러한 대안 중에서 최적의 것을 선택하는 의사결정을 포

함한다.

② 조직화organizing : 조직 구성원들이 담당할 역할 구조를 설정하는 것이다. 목표

를 달성하기 위해서 필요한 모든 일을 확인하여 배분하고, 그 일을 수행할 최

적의 사람을 선택하여 할당한다.

③ 충원staffing : 조직화에 의해서 설정된 업무에 인원을 배치하고 그 상태를 유지

3) PMBoK2008. pp.6-7, 41-65.

CHAPTER

21


하기 위해서 인적 자원을 관리한다.4)

④ 지휘leading : 구성원들이 조직과 집단의 목표를 달성하는 데 공헌하도록 그들

에게 영향을 미침. 동기부여motivating, 리더십, 의사소통communication 등을 포함

한다.

4) 학자에 따라서는 충원은 조직화에 포함시키기도 한다. 또한 학자들에 따라서는 지시commanding, 조정

coordinating, 의사결정decision making을 관리의 주요 요소로 분류하기도 한다.

Box 1-1 성공적인 프로젝트 관리 전략

● 프로젝트 성공 기준을 정의한다. 프로젝트 초기에 반드시 이해관계자들이 프로젝트 성공을 결정

할 방법에 대해서 공동 인식을 공유하도록 한다.

● 견고한 프로젝트 계획을 개발한다. 계획을 개발하는 데 가장 어려운 것은 생각하고, 정보를 교환

하고, 협상하며, 균형을 맞추는 것이다. 견고한 프로젝트 계획을 작성하기 위해서 사용한 시간은 그

이후의 변경을 감소시킨다.

● 분할해서 정복한다. 모든 대규모 과업을 작은 과업들로 분할하여, 좀 더 정확한 예측을 제공하고,

잠재된 작업 활동들을 밝혀내고, 더욱 정확하고 세밀한 상태 추적을 할 수 있도록 한다.

● 변경 계획을 수립한다. 프로젝트에서는 모든 것이 정확히 계획한 대로만 진행되지는 않는다. 따라

서 예산과 일정은 변화를 수용하기 위해서 주요 단계의 후반에는 약간의 여유분을 포함해야 한다.

● 프로젝트 위험을 관리한다. 위험의 탐지와 통제의 실패는 위험이 프로젝트를 통제하도록 만든다.

프로젝트 계획 동안에 반드시 가능한 위험 요인을 브레인스토밍을 통하여 탐지하고, 그 잠재적인

위협을 평가하고, 완화하거나 방지할 최선의 방법을 결정하기 위해서 충분한 시간을 사용하여야

한다.

위의 항목들은 잡지 CIO에 게재된 상위 5개의 성공적 프로젝트 관리 전략을 보여준다([고 외, 2008]).

프로젝트 성공 기준을 잘 정의하고 공유하는 것은 프로젝트의 성공을 위해서 가장 중요하다. 소프트

웨어 개발 프로젝트의 경우에는 종종, 미리 결정된 일정을 맞추는 것만이 성공에 대한 유일한 척도인

경우가 많다. 그러나 분명히 다른 중요한 기준들이 많다. 시장 점유율 올리기, 특정 판매량이나 수입

달성하기, 특정 고객 만족 척도 충족하기, 유지보수 비용이 많이 드는 레거시 시스템legacy system

퇴역시키기, 특정 트랜잭션 처리량과 정확도 달성하기 등이 그 예이다.

변경은 대규모 소프트웨어 시스템에서는 피할 수 없는 현상이다. 조직의 필요와 요구사항을 시스템의

전체 생에뿐만이 아니라, 개별 프로젝트 기간 동안에도 변화한다. 이것은 상응하는 변경이 시스템 또

는 프로젝트에 행해져야 함을 의미한다.

변경 계획을 수립하고 프로젝트 위험을 관리하는 것은 프로젝트의 성공을 위한 가장 중요한 요소 중

의 하나이다. 변경 관리와 위험 관리는 밀접하게 연관되어 있다. 위험 관리의 가장 중요한 요소 중의

하나는 프로젝트 후반에 대규모의 변경이 불가피해지는 것을 방지하는 것이다.

22


P A R T

Box 1-2 PDCA 주기와 지속적 개선

프로젝트 1 프로젝트 2 프로젝트 3시간

생산성

P1

P2

P3

A1 D1

D2

D3

C1

C2

C3A2

A3

▶ PDCA 사이클과 생산성 향상

PDCA 주기에서 P는 계획plan, D는 실행do, C는 점검check, A는 조치action를 의미한다. 실행은 통

상적인 의미의 모니터링 및 통제 활동을 포함하며, 계획과 함께 프로젝트 관리의 대부분을 차지한다.

각 부분의 자세한 내용은 다음과 같다.

● 계획plan : 목적과 목표을 정하고, 그것을 달성하기 위한 구체적인 행동 경로를 결정한다.

● 실행do : 계획을 실행하고, 실행을 모니터하며, 실행이 계획대로 진행되고 있지 않을 경우에는 적절

한 조정 조치를 취한다.

● 점검check : 실행 단계에서 심각한 이상이 감지되었을 경우에 그 해결책을 강구한다. 정보를 수집

하고, 이상의 근본 원인이 무엇인지 확인한다.

• 실행 성과가 계획을 초과하였다면, 그 원인이 항상 발생하도록 시스템을 개선할 수 있는 대안을

작성한다.

● 조치action : 선택된 대안을 실행하여 시스템과 프로세스를 개선하고, 개선된 시스템과 프로세스를

안정시켜서 개선 효과가 일시적이 아니라, 지속적이고 누적적으로 발휘되도록 한다.

프로젝트 관리의 관점에서는, 문제점이나 개선점이 발견되더라도 프로젝트의 수행 중에 관련 프로세

스를 변경하는 것은 너무나 큰 위험을 수반할 수 있다. 따라서 프로젝트 관리자는 프로젝트 수행 중

에 얻은 교훈을 잘 정리하여 조직의 학습된 교훈 데이터베이스lessons learned database와 최선의 관

행 라이브러리best practice library를 갱신하여야 한다. 프로젝트 수행 조직은 이러한 학습된 교훈

을 정리하고 프로세스를 개선하여 그 결과를 다음 프로젝트에 피드백함으로써 생산성을 향상시켜야

한다.

CHAPTER

23


⑤ 통제controlling : 수행되는 일들이 계획과 일치하도록 하기 위해서 조직과 개인의

성과를 측정하고 수정함. 즉, 모든 활동들이 계획과 같이 잘 수행되고 있는가

를 탐지하고 확인하는 과정으로, 목표 달성 여부의 측정과 관련된 활동과 그에

대한 통제를 포함한다.

이 중에서도 가장 핵심적인 요소는 계획, 조직화, 통제이다. 관리 과정을 이 세

요소를 중심으로 한 POCplanning, organizing, controlling의 반복적인 순환체계로 표현되

기도 한다. 즉, 이들 각 요소는 단독적으로 성립되고 실행되는 것이 아니라, 계획

하고plan, 계획된 내용을 조직을 이용하여 수행하고do, 그 결과를 확인하고 보장하

는see 일련의 연관되고 반복되는 과정5)을 통해서 수행된다. 프로젝트 관리와 관련

해서는 PDCAplan, do, check, action 주기가 주로 거론된다.

프로젝트 관리project management의 근본적인 목적은 프로젝트의 목적을 달성하는

것, 즉 프로젝트의 범위를 충족시키는 것이며, 그러기 위해서 프로젝트 요구사항

충족을 위한 활동들에 지식, 기술, 도구 및 기법을 적용하는 것이다.

프로젝트 관리는 여러 가지 프로세스들을 통합하는 일이다. 프로젝트 관리의

통합은 개별 프로젝트 프로세스 및 제품 프로세스들을 적절하게 정렬시키고, 그

것들의 조화로운 작동을 위해 서로 다른 프로세스들과 연결시킨다. 프로젝트 관

리 프로세스들은 잘 정의된 인터페이스를 가진 분리된 요소들로 표현된다. 하지

만, 실제 그것들은 겹치는 부분이 있으며 복잡하고 다양한 방법으로 상호작용한

다. 특히, 한 프로세스 내에서의 활동은 해당 프로세스 및 관련된 타 프로세스들

의 활동에도 영향을 끼친다. 예를 들면, 범위 변경은 거의 대부분 프로젝트 비용

이나 팀 윤리, 그리고 제품 품질 등에 영향을 미칠 수 있다. 특정 사항에 대한 상

충관계tradeoff는 프로젝트 및 조직 간에 다양하다. 성공적인 프로젝트 관리는 후원

자sponsor, 고객, 기타 이해관계자의 요구사항을 성공적으로 충족시키기 위해, 상

충관계를 해결하기 위한 상호작용들을 촉진하고 관리하는 것을 포함한다.

프로세스 상호작용은 종종 프로젝트 요구사항과 목표 간의 상충관계를 조정할

것을 요구하기도 한다. 크고 복잡한 프로젝트의 경우에는 이해당사자 들의 요구

사항을 정의하고 충족시키고, 프로세스 결과에 대한 동의를 얻기 위해 특정 프로

5) 이러한 전체의 과정을 ‘plan-do-see’, 약자로 ‘PDS cycle’이라고 부르기도 함

24


P A R T

세스가 여러 번 반복될 수 있다.

PMI의 PMBoK2013은 단일 프로젝트의 초기화, 계획, 수행, 모니터링 및 통

제 그리고 종료에 필요한 정보를 문서화하고 표준화하는 방법을 제시하고 있다.

PMBoK2013의 프로젝트 관리 표준은 대부분의 프로젝트, 대부분의 수행 기간에

서 최적 사례로 인식되어 온 프로젝트 관리 프로세스들을 식별한 것으로, 산업계

에서 광범위하게 적용되고 있다. ‘최적 사례’는 이러한 프로젝트 관리 프로세스들

의 적용이 다양한 프로젝트의 성공 기회를 높여 주었다는 것에 대한 일반적인 합

의가 있다는 것을 의미한다.

‘표준’이라는 것은 묘사된 지식, 기술 그리고 프로세스들이 모든 프로젝트에 동

일하게 적용되어야 한다는 것을 의미하는 것은 아니다. 어떤 프로젝트든지 프로

젝트 관리자는, 프로젝트 팀원과 협력하여, 어떤 프로세스가 적절한지 그리고 각

프로세스를 어느 정도로 적용해야 할지에 대해서 결정해야 한다. 프로젝트 관리

자와 팀원들은 각 프로세스와 그 프로세스를 구성하는 입/출력 요소를 신중하게

선정하고 재단tailoring해야 한다.6)

6) StdPgM2008 p.81. “StdPgM2008”은 PMI가 2008년에 발표한 프로그램 관리 표준의 2번째 모델인

The Standard for Program Management를 의미한다. 이 책이 각주로 붙은 부분은 해당 부분을 정

리하였다는 것을 의미한다.

Box 1-3 최선의 관행 라이브러리6)

조직들은 규모의 경제와 효율성을 달성하기 위해서 최선의 관행을 채택하고 개발하며 적용한다. 이

러한 것은 인프라스트럭처를 평가, 계획, 및 관리하는 데 적용된다. 최선의 관행 라이브러리best

practice library 그 자체는 최선의 관행이 아니다. 그것은 최선의 관행을 검색하고 관리하기 위한 자

료저장소이다. 최선의 관행을 정의하고 지정하는 것은 이 표준의 목적 밖이다. 이 라이브러리는 품질

보증, 비용 추정, 및 프로그램 관리와 같은 적용가능한 방법론들을 포함한다.

프로그램 관리 방법론은 조직 또는 산업 내에서 프로그램을 관리하기 위해서 사용되는 관행, 기법, 절

차, 및 규칙들이다. 이것은 프로그램 위험을 감소시키고, 프로그램 효익을 달성하며, 프로그램을 계획

대로 완성시키고, 이해관계자와 고객의 만족을 높이고, 갈등과 계획되지 않은 변경을 줄인다. 이것은

조직 수준에서 채택되고 승인되며, 프로젝트 관리 방법론을 보완(상충하는 것이 아니라)해야 한다.

최선의 관행은, 학습된 교훈처럼, 효과적이고 적절하게 (종종 선정된 이해관계자들에게 제한되고 통

제된 방법으로) 유통되어야 한다. 최선의 관행은 적절하게 평가되고 선택되고, 검색에 적절하도록 저

장되고, 그 유용성이 다함(또는 더 우수한 관행이 채택됨)에 따라서 제거되어야 한다.

CHAPTER

25


PMBoK2013년 표준은 47개의 프로젝트 관리 프로세스들을 정의하고, 다음과

같이 5가지의 프로젝트 관리 프로세스 그룹으로 분류하고 있다.7)

● 개시하기 프로세스 그룹initiating process group : 프로젝트 또는 프로젝트 단계를 정의

하고 공인하는 과정으로 2개의 프로세스로 구성되어 있다.

● 계획하기 프로세스 그룹planning process group : 목표들의 정의 및 정제, 목표 달성을

위해 필요한 활동의 과정, 프로젝트 수행 시에 따라야 할 범위에 대한 계획을

수립과정으로 24개의 프로세스로 구성되어 있다.

● 수행하기 프로세스 그룹executing process group : 프로젝트에 대한 관리 프로세스를

수행할 인적 및 기타 자원을 통합하는 과정으로 8개의 프로세스를 포함한다.

● 모니터링 및 통제하기 프로세스 그룹monitoring and controlling process group : 프로젝트

수행 실적과 프로젝트 관리 계획과의 차이를 식별하기 위해 프로세스를 정기적

으로 측정하고 모니터링하며, 프로젝트 목표 달성을 위해 시정 조치 활동을 수

행과정으로 11개의 프로세스로 구성되어 있다.

● 종료하기 프로세스 그룹closing process group : 제품, 서비스 또는 결과물의 수용을 공

7) StdPgM2008 p.81. “StdPgM2008”은 PMI가 2008년에 발표한 프로그램 관리 표준의 2번째 모델인

The Standard for Program Management를 의미한다. 이 책이 각주로 붙은 부분은 해당 부분을 정

리하였다는 것을 의미한다.

Box 1-4 최선의 관행 라이브러리7)

조직들은 규모의 경제와 효율성을 달성하기 위해서 최선의 관행을 채택하고 개발하며 적용한다. 이

러한 것은 인프라스트럭처를 평가, 계획, 및 관리하는 데 적용된다. 최선의 관행 라이브러리best

practice library 그 자체는 최선의 관행이 아니다. 그것은 최선의 관행을 검색하고 관리하기 위한 자

료저장소이다. 최선의 관행을 정의하고 지정하는 것은 이 표준의 목적 밖이다. 이 라이브러리는 품질

보증, 비용 추정, 및 프로그램 관리와 같은 적용가능한 방법론들을 포함한다.

프로그램 관리 방법론은 조직 또는 산업 내에서 프로그램을 관리하기 위해서 사용되는 관행, 기법, 절

차, 및 규칙들이다. 이것은 프로그램 위험을 감소시키고, 프로그램 효익을 달성하며, 프로그램을 계획

대로 완성시키고, 이해관계자와 고객의 만족을 높이고, 갈등과 계획되지 않은 변경을 줄인다. 이것은

조직 수준에서 채택되고 승인되며, 프로젝트 관리 방법론을 보완(상충하는 것이 아니라)해야 한다.

최선의 관행은, 학습된 교훈처럼, 효과적이고 적절하게 (종종 선정된 이해관계자들에게 제한되고 통

제된 방법으로) 유통되어야 한다. 최선의 관행은 적절하게 평가되고 선택되고, 검색에 적절하도록 저

장되고, 그 유용성이 다함(또는 더 우수한 관행이 채택됨)에 따라서 제거되어야 한다.

26


P A R T

식화하고, 프로젝트 또는 프로젝트 단계를 차례로 끝내는 과정으로 2개의 프로

세스로 구성되어 있다.

Box 1-5 프로젝트 관리자가 갖추어야 할 지식

프로젝트 관리를 위한 많은 지식과 도구, 기법들은 작업분할체계WBS: work-break structure, 주요

공정 분석, 획득가치 관리 등과 같이 특화될 수 있다. 하지만 지식, 기술, 도구, 기법들에 대한 이해와

적용만으로는 효과적인 프로젝트 관리가 부족하다. 효과적인 프로젝트 관리를 위해서는 프로젝트 관

리 팀원들은 적어도 다음의 5가지 영역의 전문적 지식을 갖추어야 한다.

● 프로젝트 관리 기법 : 프로젝트의 관리를 위해 특별히 개발된 기법이나 지식.

● 응용 영역에 대한 지식, 표준, 규정 : 예를 들어, 회계 관리 소프트웨어 개발 프로젝트에서는 회계

규정, 세법, 그리고 소프트웨어 공학 등과 같은 해당 응용 영역에 관한 구체적인 특수한 지식들이

필요하다.

● 프로젝트 환경에 대한 이해 : 실질적으로 모든 프로젝트는 사회적, 경제적 환경 내에서 계획되고 이

행되며 환경적 요소들은 의도되었건 의도되지 않았건 프로젝트에 긍정적인 (또는) 부정적인 영향을

끼친다. 프로젝트 팀원들은 프로젝트가 수행되는 문화, 사회, 정치, 자연적 환경을 고려해야 한다.

● 일반적인 관리 지식 및 기술 : 일반 관리는 지속되는 사업의 운영에 대한 계획, 조직, 인력, 수행, 통

제 등이 있다.

● 대인 기술 : 효과적인 의사소통, 조직에 대한 영향력, 리더십 및 동기 부여, 협상 및 갈등 관리, 문제

해결에 관한 지식 등이 있다.

일반 관리는 프로젝트 관리 기술 습득을 위한 기반을 제공하며, 종종 프로젝트 관리자의 필수 요건이

된다. 이러한 기술들과 응용을 설명하는 일반 관리 문서는 기본적으로 대부분의 프로젝트에서 공통

적으로 필요하다. 이것은 다음과 같은 지식 분야들로 이루어져 있다. 재정관리 및 회계, 구매 및 조달,

판매 및 거래, 계약 및 상법, 제조 및 분배, 물류 및 공급망(전략적 계획, 전술적 계획) 운영적 계획(조

직 구조, 조직 습성, 인력에 대한 관리, 보상, 이익, 경력), 안전 보건 업무, 정보 기술 등이다.

이상의 5가지 전문 지식 영역은 서로 중첩되며 어느 것 하나도 독립적으로 유지될 수 없다. 5 개의 모

든 영역에 대해 프로젝트 팀원 모두가 전문가가 될 필요는 없으며, 또한 그럴 수도 없다. 하지만, 효과

적으로 프로젝트를 관리하기 위해서는 프로젝트 팀이 5가지 지식 영역에 충분히 정통해야 한다.

프로젝트들 팀은 일반적으로 상위 조직의 일부이다. 조직의 예로는 회사, 정부 기관, 복지 기관, 국제

단체, 전문가 협회 등이 있다. 심지어 프로젝트 팀이 별도의 독립된 조직으로 운영되더라도, 그 팀은

일반적으로 해당 팀을 만든 조직에 의해 영향을 받는다. 프로젝트 관리 시스템, 문화, 유형, 조직 구

조, 프로젝트 관리 사무소PMO: project management office에 대한 조직의 성숙도 또한 프로젝트 팀

에 영향을 미친다. 프로젝트를 성공적으로 수행하기 위해서는 프로젝트에 영향을 미치는 이러한 상위

조직에 대한 지식도 또한 갖추고 있어야 한다.

CHAPTER

27


이 5개의 프로세스 그룹들은 서로 의존하며, 동일한 순서로 각 프로젝트에서

수행되며, 응용 영역 또는 산업 분야에 따라 다르게 수행되지 않는다. 프로세스

들 역시 프로세스 그룹 내 또는 프로세스 그룹 간에 서로 상호작용한다. 프로세

스 그룹과 프로세스들은 하나의 프로젝트 내에서 종종 반복되고 교정된다. 특히,

계획 프로세스들은 일반적으로 수행 기간 동안에 재수행되거나 갱신되는 경우가

많다.

프로세스들은 저마다의 입·출력물로 연결되어 있다. 즉, 한 프로세스의 출력

또는 결과가 다른 프로세스의 입력이 된다. 예를 들면, 모니터링 및 통제 프로세

스 그룹은 프로세스 그룹이 실행되는 동안 수행된 작업에 대해 모니터링과 통제

를 할 뿐만 아니라, 전체 프로젝트 노력을 모니터링하고 통제한다. 모니터링 및

통제 프로세스 그룹은 프로젝트 관리 계획에 대한 준수 또는 적절한 수정을 위한

시정 활동과 사전 예방 활동 이행을 위한 피드백을 제공한다. 프로세스 그룹 간

많은 추가적인 상호작용들도 이와 비슷하다.

프로젝트가 여러 단계들로 나누어진 경우 프로세스 그룹들은 일반적으로 프로

젝트가 효과적으로 완료될 수 있도록 전체 프로젝트 생애주기 동안 각 단계 내에

서 반복된다. 대형 또는 복잡한 프로젝트에서 타당성 검토, 개념 개발, 설계, 프

로토타입, 구축, 테스트 등 구분된 단계 또는 하부 프로젝트로 나누어진 경우에도

모든 프로세스 그룹의 프로세스들은 일반적으로 각 단계 또는 하부 프로젝트에서

반복된다. 프로젝트 관리자와 팀원은 원하는 프로젝트 목표들의 달성을 위해 프

로세스 그룹에서 언제 어떤 프로세스를 적용할 것인지, 누가 수행할 것인지, 어느

정도로 엄격히 적용할 것인지를 결정할 책임을 진다.

1.1.3 프로젝트 생애주기8)

프로젝트 혹은 조직의 관리자는 조직 내에서 수행중인 운영과의 적절한 연계를

통해 효율적으로 관리하기 위해 프로젝트를 여러 단계로 나눌 수 있다. 프로젝트

생애주기project life-cycle는 프로젝트의 시작부터 종료까지를 연결하는 단계들을 정

의한다. 예를 들면, 조직은 대응할 필요가 있는 어떤 일을 식별했을 때 종종 그것

을 프로젝트로 수행할 것인가를 결정하기 위해 타당성 조사를 공식적으로 수행할

8) PMBoK2008. pp.15-21.

28


P A R T

수 있다. 프로젝트 생애주기에 대한 정의는 프로젝트 관리자가 타당성 조사를 프

로젝트의 첫 번째 단계 또는 별도의 독립 프로젝트로서 다루어야 하는지에 대해

명확히 할 수 있도록 한다. 초기 투입의 성과를 명확히 식별할 수 없다면 이 노력

들은 별개의 프로젝트로 취급하는 것이 적합하다.

프로젝트 생애주기는 일반적으로 아래 사항으로 정의된다.

● 각 단계 내에서 어떤 기술적 작업들이 수행되는가(예, 아키텍터의 작업은 어떤

단계에 포함되는가)?

● 각 단계의 인도물들은 언제 생성되며 어떻게 검토되고 검증되며, 유효해지

는가?

● 각 단계에 누가 참여하는가(예, 동시공학concurrent engineering에서 이행 단계의 주

요 참여자는 요구사항 및 설계에도 참여한다)?

● 각 단계의 통제와 승인은 어떻게 하는가?

대부분의 프로젝트 생애주기는 다음의 몇 가지 공통적인 특성을 가진다.

● 단계들은 일반적으로 순차적이고, 기술적 정보의 전달 또는 기술적 구성 요소

의 이양과 같은 형태로 정의된다.

● 비용과 인력의 투입은 초기에는 낮은 수준이고, 중간 단계에서 최고에 도달하

며, 프로젝트가 종료될 때 급속히 떨어진다.

● 프로젝트가 시작되었을 때 불확실성이 가장 높고, 따라서 목표 달성에 대한 실

패의 위험이 가장 크다. 완수에 대한 확실성은 일반적으로 프로젝트가 진행됨

에 따라 점점 개선된다.

프로젝트 단계는 하나 또는 그 이상의 산출물에 의해서 정의되며, 한 단계의 산

출물들은 대체로 다음 단계의 작업 시작 전에 완결성과 정확성에 대해 검토되고

승인된다. 일반적으로 성취한 작업 및 산출물들이 승인되면 해당 단계가 종료되

고 다음 단계가 시작된다. 한 단계의 결과물, 즉 산출물은 일반적으로 프로젝트의

적절한 통제 및 원하는 제품 또는 서비스의 획득을 보장하기 위한 다음 단계의 일

부가 된다.

한 단계는 하부 단계들로 세분될 수 있다. 각각의 하부 단계도 모니터링 및 통

CHAPTER

29


Box 1-6 제품 생애주기와 혁신

제품 개발

매출액 / 수

익

도입 성장 성숙 쇠퇴

제품 생애주기PLC: product life cycle 이론에 의하면, 신제품이 시장에 도입되면 일반적으로 그 판매

량과 이익이 일정한 패턴을 따라서 증가하였다가 안정된 후, 감소하기 시작해서 결국에는 사라진다.

여기에서 제품이란, 특정 브랜드의 제품보다는 하나의 산업에 해당하는, 예를 들면, 흑백텔레비전, 냉

장고, CD 플레이어, 전기 자동차와 같은 것을 말한다(순서대로, 각각 쇠퇴기, 성숙기, 성장기, 도입기

에 있는 것으로 평가되고 있다).

신제품을 도입하기 위해서는 우선 해당 제품을 발명해야 한다. 발명invention은 새로운 지식의 창출

또는 기존 지식의 새로운 조합을 통해서 새로운 제품과 생산 공정을 만들어 내는 것을 말한다. 혁신

innovation은 발명을 최초로 시장에 도입하는 것을 말한다. 혁신은 크게 제품 혁신과 프로세스 혁신

으로 분류할 수 있다.

● 제품 혁신product innovation: 새로 개발된 제품이 기존의 제품과 얼마나 다른가에 따라서 다음과

같이 두 가지로 나눌 수 있다.9)

• 급진적 제품 혁신major product innovation: 주요 기능이나 특성이 완전히 다른, 예를 들면 흑백

텔레비전과 컬러텔레비전과 같이, 새로운 제품을 개발한다. 이를 위해서는 한편으로는 아이디어

창출에서 제품 설계 그리고 세부 엔지니어링으로 이루어지는 발명과, 또 다른 한편으로 시장 조

사 및 분석의 비즈니스 활동이 필요하다.

• 점진적 제품 혁신incremental product innovation: 기존 제품의 기능을 개선하거나 디자인을 변

경한다.

● 프로세스 혁신process innovation : 새로운 재료나 부품10)을 사용하거나, 절차를 개선함으로써 프

로세스의 효율성을 높인다. 제조품의 생산 프로세스의 혁신은 특히 공정 혁신이라고 하기도 한다.

새로운 기술의 개발과 시장에서의 반응이 서로 역동적으로 작용하면서 제품 생애주기가 발전해 간다. 이러

한 제품의 생애주기는 전형적으로, 도입 전까지 포함시키면, 다음과 같은 5단계로 구분할 수 있다.11)

● 개발기product development : 기업이 고객의 필요를 충족시킬 수 있는 새로운 제품을 구상하기 위

30


P A R T

제를 위해 하나 또는 그 이상의 특정 산출물들을 기준으로 조정된다. 이러한 하부

단계들의 산출물들은 일반적으로 상위 단계 산출물들과 연계하여 정의된다.9)10)11)

한 단계를 종료하고 산출물을 승인하기 위해서 공식적인 검토 회의를 열 수 있다.

공식적인 단계의 종료는 다음 단계의 공식적 승인은 아니다. 그러나 효과적인 통제

9) OECD는 지향하는 혁신의 종류에 따라서 기업의 연구개발 활동을 제품 관련 연구개발과 공정 관련 연

구개발로 구분할 것을 제안하고 있다. 제품 관련 연구개발은 다시 혁신적 연구개발과 점진적 연구개발

로 분류할 수도 있다.[권1994]

10) 새로운 물질 또는 재료 그 자체가 상품이 될 경우에는, 제품 혁신에 해당한다. 바이오나 의학 분야 등

에서는 새로운 물질의 발견 또는 발명하는 것이 매우 중요하다. 기존의 물질을 기존의 용도와 전혀 다

른 용도로 사용하기 위한 연구개발도 있을 수 있으며, 용도 특허는 그 결과에 대한 권리를 인정한다.

그러나 새로운 재료나 부품의 재품의 개선과 상관이 없이 비용 절감의 목적으로 사용되었을 때에는 공

정 혁신으로 분류.

11) PLC 모델은 본질적으로 신제품에 대한 마케팅과 시장 반응에 대한 이론이다. 그러나 여기에서는 연구

개발과 관련된 부분을 추가하여 강조하였다.

한 시장 조사를 하고, 필요한 기술 개발을 위한 연구개발을 수행한다.

● 도입기introduction : 혁신가 및 빠른 수용자들을 대상으로 신제품이 대한 브랜드 인지도를 높이기

위한 광고 및 마케팅 활동에 많은 자금이 투자된다. 새로운 기능과 높은 품질이 중요시되어 제품

혁신이 활발하게 이루어지며, 특허나 상표권 같은 지적 재산권이 획득된다. 제품의 다양성은 아직

비교적 제한되어 있다. 개발비를 빨리 회수하기 위해서, 일반적으로 가격이 매우 높게 책정된다.

● 성장기growth : 마케팅의 주요 대상이 일반 대중으로 변함에 따라서 제품의 성능이나 품질에 비

해서 가격경쟁력의 중요성이 증가한다. 제품 혁신은 빈도와 그 폭이 점차 감소하고, 생산 프로세스

혁신의 중요성이 증가한다.

● 성숙기maturity : 기능을 개선함으로써 차별화를 하려는 시도에도 불구하고, 제품과 기술이 표준화

가 더욱 진전된다. 가격 경쟁의 격화되어 가격이 더욱 하락한다.

● 쇠퇴기decline : 수요가 감소하며(새로운 대체재의 등장 등으로 인하여) 제조와 물류의 효율성이 경

쟁의 핵심이 되고, 수익성이 떨어지는 유통 경로들이 폐쇄된다. 재고 처리 등의 이유로 인한 가격

● 전쟁이 발생하기도 한다. 새로운 기능과 고객을 발견함으로써 (틈새시장에서) 제품의 수명을 연장

하려는 시도가 있을 수 있다.

모든 상업적 연구개발은 궁극적으로는 혁신을 지향한다. 그러나 새로운 제품에 대한 가능성에 대한

인식은 종종 기초연구 또는 그 결과로부터 촉발된다. 이러한 의미에서 기초연구는 그야말로 발명과

혁신의 기초라고 할 수 있다. 그러나 순수 기초연구는 개별 기업이 수행하기에는 위험이 크며, 주로

국가 주도로 수행되고 있다. 목적 기초연구는 기업에 의해서도 종종 수행되어 제품 개발로 연결된다.

제품 생애주기가 진전됨에 따라서 응용연구의 비중이 커지다가, 최종적으로는 개발 활동이 주로 수행

된다.

CHAPTER

31


를 위해 단계 말 검토에서 종종 다음 단계 초기화가 동시에 수행된다. 일반적으로

한 단계의 종료와 다음 단계의 시작에 대한 공인은 하나의 검토로 이루어질 수 있

다. 프로젝트가 완료되었거나 프로젝트를 계속하기에는 위험이 너무 크다고 확인된

경우에는 다음 단계의 초기화에 대한 결정 없이 한 단계가 종료될 수도 있다.

위험요소가 받아들일 정도라면 이전 단계 인도물들에 대한 승인 이전에 다음

단계를 시작할 수 있다. 이러한 단계간 중복현상의 예로는 일정 압축 기법인 패스

트트래킹fast tracking을 들 수 있다. 패스트트래킹에서는 단계간 중복이 대체로 순

차적으로 이루어진다. 현재 단계에 대한 종료 없이 다음 단계 활동 시작에 대한

결정을 위한 관리자 회의가 종종 개최되기도 한다. 예를 들면 프로젝트 관리자가

조치의 과정으로 패스트트래킹을 선택한 경우이다. 또 다른 예는 정보기술 회사

가 하나 이상의 단계가 동시에 진행될 수 있는 반복 생명주기를 선택한 경우이다.

모듈에 대한 요구사항은 모듈이 설계되고 구축되기 전에 수집되고 분석될 수 있

다. 모듈에 대한 분석이 진행되는 동안 또 다른 모듈에 대한 요구사항들의 수집을

병행하여 진행할 수 있다.

이상적인 프로젝트 생애주기 모델을 정의하기 위한 유일한 최선의 방법은 없

다. 어떤 조직은 모든 프로젝트에 한 가지 프로젝트 생애주기 모델을 적용하는 정

책 및 표준을 수립한 조직이 있는 반면, 어떤 조직들은 프로젝트 관리 팀이 프로

젝트에 가장 적합한 프로젝트 생애주기 모델을 선택하도록 하는 조직도 있다. 산

업에 따라서는 해당 산업을 위해서 특화된, 많은 조직에 의해서 선호되는 생애주

기 모델이 있을 수도 있다.

프로젝트 생애주기와 제품 생애주기product life-cycle는 구분되어야 한다. 예를 들

어, 비즈니스 계획에서 새로운 데스크톱 컴퓨터에 대한 개략적인 아이디어가 구

상되고, 제품을 설계하고, 생산 설비와 조직을 구축하고, 지속적으로 설비와 조직

을 운영함으로서 제품을 생산하고, 제품 및 설비를 개선하거나 확충하고, 최종적

으로 제품을 철회하고 조직을 해체하기까지로 이루어질 수 있다. 이러한 제품 생

애주기의 각 단계마다 한 개 또는 그 이상의 프로젝트들이 수행될 수 있다. 반대

로 하나의 프로젝트에 여러 개의 제품 생애주기가 포함될 수도 있다.

경우에 따라서는 프로젝트는 2단계로 수행될 수도 있다. 많은 프로젝트 수행

조직에서 타당성 조사를 통해서 수익성이 인정된 경우에만 본 프로젝트를 공식적

으로 승인한다. 이러한 경우에 타당성 분석 또는 초등 분석은 별개의 프로젝트 형

32


P A R T

태를 취할 수 있다. 예를 들면, 최종 제품의 개발을 위한 프로젝트를 공식적이고

본격적으로 시작하기 이전에, 프로토타입의 개발과 테스트를 위한 추가적인 프로

젝트가 수행될 수 있다.

1.1.4 프로그램과 프로그램 관리12)

프로그램program은 상호 관련된 프로젝트들의 집합으로, 해당 프로그램의 생애

주기 내에서 시작되는 프로젝트들을 개별적으로 관리해서는 얻을 수 없는 이익과

통제를 얻기 위해서 연계된 방법으로 관리되는 것들이다. 프로그램은 프로그램

내의 개별적인 프로젝트 범위 밖에 있는 — 프로젝트 자체의 관리를 위한 노력과

인프라스트럭처와 같은 — 연관된 작업 요소들을 포함할 수 있다. 프로그램의 예

로서는 다음과 같은 것들을 들 수 있다.

● 단일 제품을 갖는 대형 프로그램: 대규모 빌딩 단지의 개발

● 단일 제품의 다수의 버전: 777-200, 777-200ER, 777-200LR, 777-3000,

777-3000LR, 777-F 등의 여려 제품을 포함하는 보잉 777 프로그램

프로그램 관리program management는 해당 프로그램의 전략적인 목표와 효익을 달

성하기 위한 해당 프로그램에 대한 증앙 집중적으로 조정된 관리이다. 그것은 프

로그램 목적을 달성하기 위해서 다수의 프로젝트들을 조정하고 최적화되거나 통

합된 비용, 일정, 그리고 노력을 정하는 것이다. 즉, 프로그램 관리는 전략적 효

익, 통합된 계획, 복잡한 상호의존성, 인도물 통합, 그리고 최적화된 진행 등의 핵

심 요인들을 고려함으로써 연관된 프로젝트들을 관리할 틀을 제공한다.

프로그램 내의 프로젝트들은 인도되는 공통의 결과나 집단적인 노력을 통하여

연결된다. 프로젝트들 간의 연결이 공유되는 고객, 판매자, 기술, 또는 자원이라

면, 노력은 하나의 프로그램보다는 프로젝트들의 포트폴리오로 관리되어야 한다.

포트폴리오portfolio는 해당 작업의 효과적인 관리를 촉진하고 전략적 비즈니스 목

표들을 달성하기 위해서 함께 묶은 컴포넌트들(예, 프로젝트들, 프로그램들, 포

트폴리오들, 그리고 보수유지 및 연결된 지속적 운영활동들)의 모음이다. 포트폴

12) StdPgM2008 pp.5-12, 19. StdPgM200P은 PMI가 2008년도에 발표한 The Standar for Program

Management, 2nd edition을 의미한다.

CHAPTER

33


리오의 프로젝트나 프로그램들은 반드시 상호의존적이거나 직접적으로 연관되어

있을 필요는 없다.

프로그램에 기대되는 목적, 효익, 그리고 관리 방식은 프로젝트 관리 프로세스

에서 주로 초기화 및 계획 프로세스 그룹을 통해서 투입된다. 한편, 프로젝트 위

Box 1-7 소프트웨어 실패 곡선과 개선 프로젝트

소프트웨어의 실제 사용 환경은 동태적이며, 요구사항이 끊임없이 변한다. 이러한 요구사항의 변경은

소프트웨어의 실제 사용 환경은 동태적이며, 요구사항이 끊임없이 변한다. 이러한 요구사항의 변경은

국부적인 수정 작업으로는 해결하기 어려운 것들이 많다. 이러한 완전히 해결이 되지 않은 요구사항

이 어느 한계 이상으로 누적되면, 국부적인 수정과 개선 작업에도 불구하고 시스템의 실패가 증가하

는 시점이 발생한다. 그 후 시스템의 실패 발생률이 감당할 수 있는 한계를 벗어나면(비용/효익 분석

후에) 시스템 전체의 구조적인 차원에서의 개선 작업(경우에 따라서 독립적인 개선 프로젝트로 수행

되는)이 이루어진다. 구조적 개선 작업 이후에는 또한 국부적인 개선 작업들이 수행이 되어야 한다.

이러한 사이클은 여러 번 반복될 수 있다. 그러나 기존 코드의 많은 부분을 재활용하는 구조 변경이

나 개선에는 한계가 있으며, 이러한 개선 사이클이 어느 횟수 이상 진행된 후에는 기존의 소프트웨어

는 폐기하고, 전혀 새로운 소프트웨어를 만드는 것이 경제적으로 되는 시점이 발생한다.

하드웨어의 경우에는 제품 모델의 설계 개선이(또는 개선 프로젝트가) 완료되면, 제조 설비와 조직,

그리고 절차들도 또한 변경되어야 한다. 그러나 소프트웨어의 경우에는, 초기 개발과 마찬가지로, 이

러한 후속 단계(또는 프로젝트)가 생략된다.

34


P A R T

험, 변경 요구, 기준 들(시간, 비용, 및 품질)의 변경, 이슈들을 주로 실행, 모니터

링 및 통제, 종료 프로세스 그룹을 통해서 이루어지며, 프로젝트 관리 프로세스에

서 프로그램 관리 프로세스로 피드백된다.

프로그램에서는 컴포넌트들 간의 상호의존성을 통합하고, 모니터하고, 그리고

통제하는 것이 중요하다. 프로그램 관리는 프로젝트 상효의존성에 초점을 맞추고

그것을 관리하기 위한 최적의 접근방법을 결정하는 데 도움을 준다. 이러한 상호

의존성과 관련된 행동으로는 다음과 같은 것들이 있다.

● 컴포넌트, 작업, 또는 단계들을 조정하기.

● 내부 프로그램을 위해서는, 해당 프로그램 내 복수의 프로젝트들에 영향을 미

치는 자원 제약 및/또는 갈등을 해소하기.

● 상황 대처 계획과 같은 컴포넌트들의 위험활동을 완화시키기.

● 프로젝트 및 프로그램 목적과 목표들에 영향을 미치는 조직/전략적 방침들을

정렬하기.

● 공유된 거버넌스 구조 안에서 이슈들과 범위/비용/일정/품질 변경들을 해결하기.

● 문화, 언어, 시간, 그리고 거리 차이 등을 다루기 위해서 프로그램 전체를 포괄

하는 프로그램 관리 프로세스와 인터페이스를 재단한다.

프로그램 관리자program manager는 프로젝트들 간에 투입노력을 조정하지만, 프

로젝트들을 직접 관리하지는 않는다. 프로그램 관리자는 개별 프로젝트들을 지원

하고 지도함과 동시에 각 프로젝트를 — 좀 더 큰 프로그램과 조직 성과 목표들을

포함하는 — 보다 큰 그림과의 연관성을 전달하기 위해서 각 프로젝트 관리자들

과 상호작용한다. 프로그램 관리자는 전체 프로그램 구조와 프로그램 관리 프로

세스에서 일을 성공적으로 수행하고 인도물들이 프로그램의 최종 산출물로 통합

된 수 있도록 보장할 책임이 있다. 프로그램 관리자는 또한 프로젝트들이 일관된

방법으로 조직되고 수행되며 확립된 표준에 맞춰서 완수되도록 보장해야한다. 그

리고 프로그램 관리자는 프로그램의 성과에 영향을 주는 외부 요인들을 파악하고

감안할 책임도 있다.

프로그램 관리 오피스PMO: program management office는 프로그램 인프라스트럭처의

핵심이다. PMO는 프로그램 관리자가 연관된 프로젝트들을 관리하는 것을 지원

CHAPTER

35


한다. 다양한 형태의 PMO가 있을 수 있지만, 표준적인 PMO의 목표는 다음과 같

이 프로그램 관리자를 지원하는 것이다.

● 준수해야 할 프로그램 관리 프로세스를 정의하기.

● 프로그램 수준에서 일정을 관리하기.

● 프로그램과 프로그램 컴포넌트들을 위한 품질 표준을 정의하기.

● 문서 형상 관리를 제공하기.

<표 1-1> 프로젝트, 프로그램 그리고 포트폴리오 관리의 비교

구분 프로젝트 프로그램 포트폴리오

범위

정의된 목표를 갖는다. 범

위는 프로젝트 생애주기를

통해서 점진적으로 다듬어

진다.

좀 더 큰 범위를 가지며 보

다 중요한 효익을 제공한다.

조직의 전략적 목적에 맞춰

변하는 비즈니스 범위를 갖

는다.

변화/변경

프로젝트 관리자는 변경을

예상하며 변경이 관리되고

통제되게 하기 위한 프로

세스를 실행한다.

프로그램 관리자는 프로그

램 내외부로부터의 변화를

예측해야 하며 그것을 관리

하기 위해서 준비해야 한다.

포트폴리오 관리자는 좀 더

넓은 환경에서의 변화를 지

속적으로 모니터해야 한다.

계획

프로젝트 관리자는 프로젝

트 생애주기를 통해서 점

진적으로 고수준의 정보를

상세한 계획으로 발전시켜

야 한다.

프로그램 관리자는 전체 프

로그램 계획을 개발하고 컴

포넌트 수준의 상세한 계획

을 위한 지침을 제공할 고수

준의 계획을 작성해야 한다.

포트폴리오 관리자는 통합된

포트폴리오에 필요한 프로세

스와 정보소통을 창조하고

유지해야 한다.

관리


트 목표들을 충족시키기

위해서 프로젝트 팀을 관

리한다.


램 스태프들과 프로젝트 관

리자들을 관리한다. 그들은

비전과 전반적인 리더십을

제공한다.

포트폴리오 관리자는 포트폴

리오 관리 스태프들을 관리

하거나 또는 통합할 수 있다.

성공

성공은 제품, 프로젝트 품

질, 적시성, 예산 준수성,

및 고객 만족도의 정도에

의해 측정된다.

성공은 프로그램의 필요와

효익을 충족한 정도에 의해

측정된다.

성공은 포트폴리오 컴포넌트

들의 종합적 성과를 기준으

로 측정된다.

모니터링


트가 생산하기로 한 제품

의 생산 작업을 모니터하

고 통제한다.


램이 충족시켜야 하는 전체

목적, 일정, 예산, 및 효익

을 보장하기 위해서 프로그

램 컴포넌트들의 진행을 모

니터한다.

포트폴리오 관리자는 통합된

성과와 가치 지표들을 모니

터한다.

출처: StdPgM2008 p.11, T1-1.

36


P A R T

● 변화를 관리하고 위험과 이슈들을 추적하기 위한 중앙 집중된 지원을 제공하기.

뿐만 아니라, 길고 위험하거나 복잡한 프로그램을 위해서는, PMO는 인적자원

관리, 계약 및 조달(특히 국제적) 관리, 법률 지원, 그리고 필요한 기타 지원 등과

같은 영역에서 추자적인 지원을 제공할 수 있다. 일부 프로그램들은 수년간 지속

하며 대규모 조직의 운영 관리와 중첩하는, 일반적 운영의 다양한 측면을 포함하

고 있다.

소프트웨어 개발 프로젝트1.2

1.2.1 소프트웨어 프로젝트의 특수성

일반적 프로젝트 관리 기법의 대부분을 소프트웨어 프로젝트 관리에 적용할 수

있다. 그러나 소프트웨어 프로젝트의13) 결과물인 소프트웨어는 하드웨어와는 다

른 특성을 갖고 있으며, 이러한 특이성은 소프트웨어 프로젝트 관리를 위해 전문

화된 기법을 사용할 것을 요구한다.

소프트웨어 프로젝트 관리의 핵심은 보이지 않는 것을 보이게 하는 것에 있다.

● 비가시성 : 교량이나 도로와 같은 물리적 인조물을 구축할 때에는 작업 진척 상

황이 실제로 눈으로 보여질 수 있다. 그러나 소프트웨어의 경우에는 진도를 즉

시로 눈으로 확인할 수 없다.

● 복잡성 : 지출된 화폐 단위 당 복잡성이 소프트웨어 제품은 하드웨어 제품보다

더 복잡하다.

● 유연성 : 소프트웨어의 변경 용이성은 일반적으로 소프트웨어의 장점으로 간주

된다. 그러나 이러한 것은 소프트웨어가 물리적 또는 조직적 시스템과 상호작

용할 때에는, 만약 필요하다면, 소프트웨어가 다른 요소에 적응하기 위해서 변

경되기를 요구받는다는 것을 의미한다. 즉 소프트웨어 프로젝트는 제품에 대한

보다 잦은 변경 요구를 수용할 수 있어야 한다. 비록 소프트웨어라는 단어 자체

13) 여기에서 소프트웨어 프로젝트는 일반적으로 소프트웨어 ‘개발’ 프로젝트를 의미한다.

CHAPTER

37


가 고치기 쉽다는 뜻을 내포하고 있고 그러한 의미에서 ‘소프트웨어’라는 명칭

이 사용되었지만, 실제로는 소프트웨어를 고치는 것은 ‘그렇게 쉽지’ 않다.

Box 1-8 소프트웨어 개발 프로젝트에서의 변경 비용

소프트웨어 개발 프로젝트에서 변경은 추가적인 비용을 발생시킨다. 변경을 초래하는 주된 이유 중의

하나는 오류error이다. 오류 수정 비용은 그 오류가 발생했을 즉시에 수정한다면 그리 크지 않지만,

발생 후에 수정한다면 그 경과 시간에 따라 기하급수적으로 증가한다. 예를 들어, 요구사항 단계에서

발생한 오류를 그 단계에서 수정할 때의 비용을 1이라 하면, 동일한 오류를 운영 단계에서 수정하기

위해서는 최대 1000까지의 비용이 든다. 따라서 요구사항 단계에서의 오류 발생을 최소화하고, 만약

발생하더라도 빨리 감지되어 수정되도록 하는 것이 무엇보다 중요하다.

코딩 단계에서 발생한 오류의 경우에도 마찬가지이다. 코딩 단계에서 발생한 오류를 I단계에서 수정

한다면 비용이 얼마 들지 않지만, 그 후속 단계에서 고친다면 비용이 기하급수적으로 증가한다.

요구 사항의 변경 또는 추가로 인한 소프트웨어의 변경도 위의 그림에서 표현된 오류에 의한 변경과

동일한 패턴을 따른다. 운영 중에 요구사항이 변하여 기존의 소프트웨어를 그대로 쓸 수가 없게 되었

다면, 경우에 따라서는 기존의 소프트웨어를 수경하는 것보다는 새로 개발하는 것이 경제적으로 더

유리할 수가 있다. 이런 의미에서 소프트웨어는 기술적인 관점에서는 변경이 가능하지만, 즉 말랑말

랑soft하지만, 경제적인 관점에서는 변경이 불가능, 즉 딱딱hard할 수 있다.

38


P A R T

1.2.2 소프트웨어 프로젝트를 성공적으로 수행하기 위해서 필요한 지식

CMU/SEI SEBoK Ver, 1.0은14) 소프트웨어 프로젝트를 성공적으로 수행하기

위해서 필요한 지식, 즉 소프트웨어 공학의 지식 체계를 다음과 같이 크게 네 영

역으로 분류한다.

● 계산 기초 사항computing fundamental : 소프트웨어 개발과 소프트웨어 공학 학문

분야의 기초를 이루는 계산에 관한 지식과 개념, 이론, 방법, 기술, 그리고 응

용에 대해 다룬다. 이 범주는 다음과 같은 5개의 지식 영역으로 구성된다. 해

법과 자료구조algorithms and data structures, 계산기 구조computer architecture, 수학

적 기초mathematical foundations, 운영체계operating systems, 그리고 프로그래밍 언어

programming languages.

● 소프트웨어 제품 공학software product engineering : 정확하고 일관성 있는 소프트웨어

를 효과적이고 효율적으로 생산하기 위한 잘 정의되고 통합된 활동들의 집합에

대해서 다룬다. 소프트웨어 제품 공학은 요구사항 공학, 설계, 코딩, 그리고 테

스팅과 같은 소프트웨어 제품의 생산, 그 운영과 유지에 관련된 기술적인 활동

들을 포함한다.

● 소프트웨어 도메인software domain : 계산이나 소프트웨어 공학 응용 또는 활용을

포함하는 특수한 도메인에 관한 지식을 다룬다. 이 범주는 다음과 같은 소프트

웨어 도메인을 포함한다. 인공지능, 데이터베이스 시스템, 인간-컴퓨터 상호작

용human-computer interaction, 컴퓨터 시뮬레이션, 그리고 소프트웨어 획득software

acquisition.

● 소프트웨어 관리software management : 소프트웨어 프로젝트 관리, 소프트웨어 위험

관리, 소프트웨어 품질 관리, 그리고 소프트웨어 형상 관리, 소프트웨어 프로세

스 관리, 그리고 소프트웨어 취득 관리에 관련된 활동들을 포함한다.

소프트웨어 프로젝트를 성공적으로 수행하기 위해서는 위의 네 가지 영역의 지

식을 모두 갖추어야 한다. 그러나 위의 네 가지 지식 영역 중에서 소프트웨어 프로

젝트 관리와 직접적으로 연관이 있는 것은 소프트웨어 관리 영역이다. SEBoK Ver.

14) Carnegy Mellon University/Software Engineering Institute, Software Engineering Body of

Knowledge Version 1.0.

CHAPTER

39


1.0는 소프트웨어 관리지식 영역을 다음과 같은 6개의 활동 영역으로 세분한다.15)

● 소프트웨어 프로젝트 관리software project management : 프로젝트 목적을 정의하고, 프

로젝트의 요구와 자원을 평가하고, 수행되어야 할 작업들에 대한 추정 값들을

작성하고, 수행하기 위한 계획을 정의하는 것을 다룬다.

● 소프트웨어 위험 관리software risk management : 소프트웨어 제품 개발 계획을 위협

하는 제 위험을 관리하기에 관한 개념, 방법, 그리고 기술 등을 다룬다. 위험 관

리는 위험의 정의, 위험의 분석, 위험의 모니터링, 위험의 완화, 그리고 위험 계

획과 같은 활동들을 포함한다.

● 소프트웨어 품질 관리software quality management : 효과적이고 경제적인 방법으로 고

품질의 소프트웨어 산출물 제작을 위한 개념, 기준, 방법, 기술, 그리고 기준과

관련이 있다. 이 영역은 품질 계획과 통제, 검증과 확인 활동, 산출물의 프로세

스 특성의 측정, 그리고 소프트웨어 확실성dependability과 신뢰성에 대한 지식을

포함한다.

● 소프트웨어 형상 관리software configuration management : 각 시점에서의 시스템 형상

들, 각 형상에 가해지는 변경을 체계적으로 통제하고 소프트웨어 시스템의 수

명 전체를 통해서 각 형상의 일정과 추적 가능성을 유지하기 위해서, 확인하기

위한 방법들에 대하여 다룬다.

● 소프트웨어 프로세스 관리software process management : 소프트웨어 개발 과정의 기술

적 측면의 관리에 대해 다룬다. 이 영역은 다음과 같은 관리 구성 요소를 포함한

다. 사람들이 소프트웨어와 관련된 산출물을 개발하고 유지하기 위하여 사용하는

활동, 방법, 관행, 그리고 변환. 이 분야는 또한 조직 내의 제 프로세스들이 기대

된 대로 수행되는 것을, 즉 정의된 프로세스들이 바르게 수행되고 그 프로세스들

이 조직의 목표를 달성하기 위해서 개선되는 것을 보장하는 것을 포함한다.

● 소프트웨어 취득 관리software acquisition management : 대리인을 통하여 그 대리인과

관계없는 소프트웨어 개발자로부터 맞춤 소프트웨어 시스템을 획득하는 것에

대해 다룬다. 이 영역은 조달, 계약, 성과 평가, 소프트웨어 시스템에 대한 미래

의 지원을 확보하는 것과 같은 취득 활동에 관한 지식을 다룬다.

15) CMU/SEI SE-BoK Ver 1.0. [HILBURN 1999] pp.29-34.

40


P A R T

부 록 1A소프트웨어 프로젝트 성공 요인과 실패 요인

소프트웨어 프로젝트의 특징은 너무 많은 소프트웨어 프로젝트가 너무나 많은

방법으로 실패한다는 것이다. 즉, 소프트웨어 프로젝트는 성공하기는 어려우나

실패하기는 쉽다. 실패한 소프트웨어 프로젝트의 대표적인 공통된 증상은 다음과

같다.

● 최종 사용자의 필요에 대한 부정확한 이해

● 변하는 요구사항에 대처하는 능력의 부족

● 서로 잘 맞지 않는 모듈들

● 보수하거나 확장하기 힘든 소프트웨어

● 심각한 프로젝트 결함의 늦은 발견

● 낮은 소프트웨어 품질

● 받아들일 수 없는 소프트웨어 성능

● 제 각각의 방법으로 일하는 팀 멤버들 - 결과적으로 누가 무엇을 언제, 어디를,

왜 바꾸었는지를 확인할 수 없게 함

● 신뢰하기 힘든 구축과 인도 과정

[그림 1A] 높은 소프트웨어 프로젝트 실패 비율

CHAPTER

41


<표 1A-1> MIS 소프트웨어 프로젝트의 성공과 실패 요인

항목 성공 요인 실패 요인

비즈니스 능력 새로운 능력을 제공 현재의 능력을 저해

가치value 명백하고 긍정적인 가치 부정적인 가치

운영 속도 개선 저해

운영 비용 감소 증가

경쟁력 향상 저해

근로자의 의욕 개선 저해

요구사항 충족 정도 모든 사용자 요구사항을 충족충분한 사용자 요구사항 충족에

실패

사용자 만족 수준 높은 수준에 달성 낮은 수준에 이름

스케줄 5% 이내로 예상 가능 통제 불가능함

비용 5% 이내로 예상 가능 통제 불가능함

요구사항 범위5% 이내로 안정된 사용자 요구

사항통제를 벗어난 요구사항

참조: JONES00, p.193.

그러나 이러한 증상들을 치료하는 것은 그 병을 치료하는 것은 아니다. 예를 들

어, 심각한 프로젝트 결함의 뒤늦은 발견은 단지 더 큰 문제들(즉, 프로젝트 상

태의 주관적인 평가와, 요구사항과 설계 그리고 구현에서의 탐지되지 않은 불일

치 등)의 증상에 불과하다. 다음은 실패한 소프트웨어 프로젝트의 근본 원인들

이다.

● 즉흥적인 요구사항 관리

● 모호하고 정확치 않은 의사소통

● 취약한 아키텍처

● 지나친 복잡성

● 요구사항과 설계 그리고 구현에서의 탐지되지 않은 불일치

● 불충분한 테스팅

● 프로젝트 상태의 주관적인 평가

● 위험에 대한 대처의 실패

● 변경의 통제되지 않는 확산

42


P A R T

● 충분치 못한 자동화

소프트웨어 개발 프로젝트는 다음과 같이 개발하는 소프트웨어의 종류에 따라

서 6개 범주로 구분할 수 있다.

● MISmanagement information system

● 외주outsource

● 시스템과 내장embedded 소프트웨어

● 군용 소프트웨어

● 상업적COTS: commercial off the shelf 소프트웨어

● 개인적 소프트웨어

MIS는 기업이 자신의 영업과 행정 업무를 지원하기 위해서 생산한 응용 프로

그램 유형을 말한다. 급여 시스템, 회계 시스템, 전후방 사무실 은행 업무 시스템,

항공기 예약 시스템, 그리고 e-비즈니스 등. 이 단어는 영업 도구로 컴퓨터가 사

용되기 시작한 1963년부터 사용되기 시작했다.

일반적으로, 정보 시스템은 기업의 임원, 경영자, 그리고 지식 노동자의 업무상

필요에 의해서 개발된다. 정보 시스템은 이들에게 새로운 능력을 부여하거나, 실

수할 확률을 줄이거나, 업무 수행을 촉진시키거나, 또는 다른 어떤 유리한 상황을

조성하기 위해서 개발된다. 정보 시스템의 평가 기준은 그것이 그 구축과 운영 비

용을 상쇄하는 긍정적인 가치를 기업에 되돌려 줄 수 있는냐 하는 것이다.

인기 있는 MIS 개발 방법 중의 하나는 정보 공학information engineering이다. Texas

Instrument나 James Martin Associates의 제품과 같은 몇몇의 정보 공학을 위

한 상업적 도구 제품들이 존재한다. 그러나 이것들은 주로 데이터베이스 응용을

디자인하는 데 주안점을 둔다. 이외에도 주로 MIS 응용applications을 위한 소프트웨

어 설계 방법들이 있다. Wariner-Orr, Michel Jackson, James Martin 등의 방

법들이 그 중의 하나이다.

MIS 응용개발의 프로젝트 관리 측면은 몇몇 소프트웨어 비용 예측 도구에 의

해서 지원된다. 이러한 독립적인 예측 도구 외에도, 좀 더 큰 MIS 개발 슈트의 일

부로 내정되어 있는 예측 도구들이 있다. 예를 들어 TI Information Engineering

CHAPTER

43


Facility는 기능 점수치function point를 생산하고, 다시 소프트웨어 비용과 일정 추

정치를 생산하는 내장 도구를 지니고 있다. 기능 점수 척도가 MIS분야에서 가장

널리 사용되는 척도이기 때문에, 많은 기능 점수(를 명세나 설계로부터 계산하는)

도구들이 시판되고 있다.

MIS 응용들은 종종 특정한 고객 조직에 의해서 특정 문제를 해결하기 위해서

발주되기 때문에, MIS 응용의 요구사항은 종종 소수의 사용자로부터 도출된다,

이러한 것은 수백만의 고객을 지원하기 위한 Window98과 같은 많은 시스템 소

프트웨어 응용과 대비된다.

많은 MIS 요구사항이 특정한 목적을 위해서 개발되기 때문에 MIS 응용을 위

한 요구사항 수집과 분석 방법들이 매우 중요하다. 요구사항을 확인하는 가장 인

기 있고 성공적인 방법은 JADjoint application design이다. 이 방법은 IBM의 캐나다 토

론토 소재 소프트개발 연구실에서 1970년대에 개발되었으며, 가장 정형적이고 대

규모의 사용자와 자료 처리 전문가 공동의 작업 형태이다. JAD는 프로젝트 정의,

조사, 준비, 회의 그리고 최종 문서 작성의 5단계로 이루어지며, JAD 세션이라고

불리는 구조적인 워크숍을 중심으로 진행된다. JAD 세션은 일반적으로 작업이

<표 1A-2> 소프트웨어 아웃소싱 프로젝트의 성공과 실패 요인

항목 성공 요인 실패 요인

계약의 법적 소송 없음 있음

인도된 소프트웨어의

운영 가능성가능 가능하지 않음

요구사항의 변경 5% 이내로 통제를 벗어나 확산

프로젝트가 요구사항을

만족시키는 정도100% 만족시킴 20% 이상을 빠뜨림

계약 비용 표준보다 적다. 표준보다 많다.

비용 예상 5% 이내로 예상 가능 20% 이상 초과됨

일정: 내부 개발 표준

일정에 대비하여짧다 길다

일정 예측 1% 이내로 예측 가능 20% 이상 틀림

인도된 소프트웨어의

유지보수가능함 본질적으로 불가능

계약당사자의 이익 모두에게 이익 한쪽이나 양쪽에게 손해


44


P A R T

중단 없이 계속되게 하기 위해서 현장에서 떨어진 곳에서 3~5일 동안 진행되며,

이해관계자들이 모여 요구사항을 정의하거나, 프로젝트를 계획하거나, 컴퓨터 시

스템을 설계하거나, 또는 기타 업무적인 의사결정을 내린다.

JAD의 특징은 사용자와 개발 조직을 모두 대표하는 팀에 의해서 합동으로 요

<표 1A-3> 프로젝트와 계약 위반 소송에 연루된 프로젝트의 차이점

항목 성공적인 프로젝트 소송에 연류된 프로젝트

단점 예방

JAD 사용 미사용

프로토타입 사용 미사용

결함 추적 사용 뒤늦게 사용

변화 관리 공식적 비공식적

복잡성 분석 사용 뒤늦게 사용

단점 평가 사용 미사용

결함 제거 척도 사용 미사용

테스트 전 결함 제거

설계 조사 사용 급하게 사용되거나 생략됨

코드 조사 사용 급하게 사용되거나 생략됨

테스팅

서브루틴 테스트 사용 사용

유닛 테스트 사용 사용

새로운 기능의 테스트 사용 급하게 사용되거나 생략됨

회귀 테스트 사용 급하게 사용되거나 생략됨

통합 테스트 사용 사용

시스템 테스트 사용 급하게 사용되거나 생략됨

성과 테스트 사용 급하게 사용되거나 생략됨

능력capacity 테스트 사용 급하게 사용되거나 생략됨

승인acceptance 테스트 사용 실패한 시스템

전문화

소프트웨어 품질 보증 사용 비공식적

소프트웨어 테스팅 전문가 사용 미사용


CHAPTER

45


구사항이 개발된다는 것이다. JAD에 참여하는 사람들의 종류에는 임원 후원자,

촉진자, 서기, 풀타임 참여자들이 있으며, 경우에 따라서는 호출 참여자와 관찰자

가 추가적으로 참가하기도 한다. 훈련된 JAD 촉진자가, 요구사항에 관련 있는 모

든 요소들을 포함하기 위해서, JAD 세션을 중재한다. JAD 방법의 장점중의 하나

는 요구사항의 확산을 효과적으로 제어한다는 것이다. JAD에 의해서 요구사항이

수집되고 확정된 후에는, 일반적으로 설계와 코딩 단계에서의 요구사항의 월간

변화율이 전통적인 방법에 의한 2%에서 0.5% 이하로 감소한다.

외주 소프트웨어outsourced software는 고객 조직을 위해서 계약 하에 외부 기업에

의해서 개발된 소프트웨어 프로젝트를 의미한다. 1990년경 이후로 외주 산업이

급격히 팽창하고 있다. 가장 중요한 외주 프로젝트 성공 요인 중의 하나는 계약상

의 모호성을 제거하여 외주 계약자와 고객 간 분쟁의 위험을 최소화하는 것이다.

많은 대형 외주 벤더들이 전문화의 관점에서 시스템 소프트웨어 영역에 전문화

되어 있다. 특정한 산업 내에서의 수직적 전문화는 외주 업계의 독특한 특징이다.

대형 외주 벤더들은 뱅킹, 보험, 정부 및 공공기관, 그리고 제조업 등의 몇몇의 다

수의 고객을 지원할 수 있는 재사용가능한 응용을 개발하는 데 많은 결실을 맺게

한다.

주요 벤더들은 비용과 일정 예측, 소프트웨어 품질 보증, 테스팅, 기술적 저술,

데이터베이스 관리, 그리고 기능 점수 분석 등의 분야의 다수의 전문가들을 고용

한다. 대형 외주 벤더 내의 다른 종류의 전문가들은 ‘시스템 분석가’와 같은 일반

적인 직함을 갖고 있으나. JAD 세션을 촉진시키거나, 설계와 코드 인스펙션을 중

재하는 등의 일정한 기술적 활동에 대하여 잘 훈련받기도 한다.

국립중앙도서관 출판시도서목록(cip)†Œ프트웨어프로젝트관리... · 8.4...

Documents