소프트웨어 공학 - 프로젝트 관리

소프트웨어 공학에서 굉장히 중요한 부분중 하나인 프로젝트 관리(Project Management)에 대해 알아보자.

관리 활동 / 계획 수립 / 일정 수립 / 위험 관리 등의 과정으로 나뉜다.

 

소프트웨어 개발 프로젝트의 최종 결과물은 기본적으로 아래와 같은 것들에 영향을 받는다.

 

위 내용 다 중요하지만 굳이 경중을 두자면 

마감일(delivery deadline), 활용 분야(application domain), 기술(technology to be implemented), 시스템 제약 조건(system constraints) 등이 되겠다.

 

위 요소들에 영향을 받는 최종 결과물을 지칭하는 말이 있는데 

The 4P's 라는 것이다.

1. People : 사람이다. 프로젝트에서 가장 중요한 요소이다.

2. Product : 말그대로 결과물이다. 제품을 말한다.

3. Process : 소프트웨어 개발 과정이다. 제작 공정도 중요한 요소이다.

4. Project : 프로젝트다.

 

1. 프로젝트 관리 활동

자, 그럼 본격적인 프로젝트 관리에 대해 알아보자.

일단 프로젝트 관리를 하기 위해서는 프로젝트를 따와야 하지 않겠는가.

이 때 나오는 ROI(Return on Investment) 라는 말이 있는데,

투자 대비해 나오는 결과물 정도로 보면 되겠다. 이게 좋아야 지원을 해준다.

 

자 그럼 ROI가 정말 발군이라, 지원을 받아 프로젝트를 시작하게 되었다.

프로젝트 관리를 해야 하는데, 이것 저것 생각해볼 여지가 많다.

그런 프로젝트 관리에 관여되는 요소들이 어떤 것들이 있는지 보겠다.

 

 

제품의 질, 위험 평가, 측정(개발 진행도를 어떤식으로 측정할 것인지), 비용산정, 

일정, 고객과의 의사소통, 팀원, 프로젝트 진행상황 체크 등으로 볼 수 있다.

 

위 요소들을 가지고 W5HH 원칙에 따라 프로젝트 관리를 해야한다.

1. 이 시스템이 왜(Why) 개발되고 있는가?

2. 무엇을(what), 언제(when)까지 해야하는가?

3. 이 기능은 누가(who) 책임지는가?

4. 그들이 조직 편제상 어디에(where) 있는가?

5. 그 일이 어떻게(how) 실무 차원 및 관리차원에서 완수되는가?

6. 각 자원은 얼마나(how) 많이 필요한가?

 

프로젝트 관리는 일정대로 결과물이 인도되고, 그 결과물이 고객과 개발자 모두의 요구를 충족시키는 지에 대해 관심이 많다. 이 요구 조건들이 항상 개발에 영향을 주기 때문에 프로젝트 관리는 반드시 해야 한다.

 

특히나 소프트웨어 개발 프로젝트는 다른 것들과 차이가 많다.

결과물을 만질 수 없고, 본래 유연하여 계속해서 변화, 진화될 여지가 있다. 그리고 표준화가 되어 있지 않으며, 보통 1회성인 프로젝트들이 많다.

이런 여러가지 이유들로 인해 소프트웨어 공학에서 프로젝트 관리는 매우 중요하다.

 

 

2. 프로젝트 계획 수립

기술적으로 복잡한 프로젝트 구성은 s/w 개발에 문제점을 야기할 수도 있다. 그리고 먼저 관리 활동을 하기 전에 프로젝트에 적합한 인원을 선별하는 과정이 필요하다.

예산 제한으로 굉장히 비싼 인력을 구할 수도 없고, 원하는 인원이 없을 수도 있다.

이런 제한 조건을 가지고 인원을 선정해야 하는데 전세계적으로 숙련된 IT인력이 부족한 상황이라고 한다.

 

인원 선정에 대한 문제가 해결되었다면 관리 활동을 해야한다.

관리 활동들은 여러가지 단계를 가지는데, 먼저 프로젝트 계획 수립에 대해 알아보자.

 

프로젝트 계획 수립

아마도 관리 활동에서 가장 많은 시간이 드는 과정이다.

초기 개념 단계 부터 결과물이 인도 될 때 까지 계속되는 활동이다. 

새로운 정보들이 나올때 마다 계속 정규적으로 갱신해 주어야 하는 활동임.

 

프로젝트 계획의 유형에는 5가지 정도가 있다.

위 내용들이 총괄되어 프로젝트 계획이 수립되어야 한다.

계획 수립 과정은 아래와 같은 프로세스로 진행하면 된다.

 

위에서 이정표(Milestone) 과 인도물(Deliverables) 라는 개념이 나오는데,

이정표(Milestone)는 어떤 프로세스 활동이 끝난 시점을 나타내는 말이고,

인도물(Deliverables)은 고객에게 전달되는 프로젝트 결과물을 지칭하는 말이다.

 

프로젝트 계획을 위 프로세스 대로 진행하고,

최종적으로는 개요, 프로젝트 구성, 위험 분석, H/W, S/W 자원 요구사항, 작업 분해도,

프로젝트 일정, 감시와 보고체계 등의 구성이 들어가야 한다.

 

작업분해도를 WBS(Work Breakdown Structure)라고 하는데 SE의 철학중 하나가 Divide & Conquer이다.

작업을 분해하여 적제 적소에 배치해야 한다.

그리고 자원 요구사항은 두가지를 고려해야 한다. 개발 환경(개발 당시), 운영 환경(개발 완료)

 

 

3. 프로젝트 일정 수립

프로젝트의 작업을 분해하고 각각의 작업을 완성하는데 필요한 시간, 자원등을 추정하는 작업이 일정 수립이다. 이때 고려할 부분이 있다.

 

1. 작업력이 극대화 되도록 각 작업들이 동시에 수행할 수 있도록 구성한다.

2. 작업들 간에 종속성을 최소화 시킨다. ( A를 해야 B를 할 수 있는 이런 것을 줄여라)

3. 프로젝트 관리자의 경험과 직관에 의존한다.

 

위 세가지를 고려해야 한다.

물론 저런것들을 고려한다고 일정수립이 완벽하게 되지는 않는다.

문제점들의 난이도 측정이 어려워 비용 산출이 어렵고, 얘기치 못한 상황이 발생하여 프로젝트가

지연되는 문제, 그리고 지연되었다고 인원을 투입시키는데 많이 투입시킨다고 또 프로젝트가

제대로 돌아가는 것이 아니라는 점 등등... 여러가지 문제점에 봉착한다.

이런 상황들을 항상 고려해야 하는 문제가 있지만 문제점이 있다고 계획 안 세울건가.

 

자 그럼 이제 일정을 수립해보자, 일정 수립하는데 정해진 프로세스가 있다.

먼저 S/W 요구사항을 참조하여 작업을 구별한다.

그리고 작업들 간에 상호 의존성을 테스트한다. 

그 후 시간 할당, 노력 확인, 책임의 정의(누가 할지), 결과물의 정의(결과물이 뭔지), 이정표 정의(언제까지 할건지) 등의 프로세스를 거친다.

 

그리고 난후 프로젝트를 그래픽 표기법을 이용하여 설명하기 용이하게 구성한다.

이 때 나오는게 Activity Network (퍼트 차트), Bar chart (간트 차트)이다.

 

먼저 작업을 분해한다. 그리고 분해한 작업들의 소요 시간을 예상하고

작업들간의 종속성을 체크하여 표에다가 정리를 한다. 아래 예를 보여주겠음

 

종속성을 보고 저번에 설명한 이정표(milestone)을 표시한다.

이걸 표시하면 다음 작업이 쉬워진다. 위 표를 보고 먼저 퍼트 차트부터 그려본다.

 

작업들의 종속성과 마일스톤으로 위 차트를 그리면된다.

 

빨간색으로 표시된 것이 임계 경로(Critical Path) 이다.

시작부터 완성하는데 가장 시간이 오래 걸리는 것을 말한다.

여기서 하나라도 지연되면 프로젝트 전체가 지연되므로 작업 관리자가 주의깊게 보아야 한다.

퍼트 차트는 작업간의 종속성을 확인하기 용이하다.

 

다음은 간트 차트를 그려보겠다.

 

간트 차트는 날짜별 작업 일정을 잘 볼수있는 차트이다.

연두색 색칠된 부분이 작업에 대한 여유기간을 나타낸 것이다. 색칠 안되어 있는 부분은 작업 수행 기간이다.

아예 색칠이 안되어 있는 작업들(T1, T3, T9, T11, T12)은 임계 경로내에 속한 작업들이다.

 

이렇게 차트를 그리고 나면 프로젝트 계획에 대한 것들이 눈에 잘 보인다.

다 그리고 나서 이제 인원 별로 작업을 할당해야 할 것이다.

 

 

4. 프로젝트 위험 관리

프로젝트를 수행하는데 있어서 많은 위험요소들이 존재한다. 프로젝트 위험, 프로덕트 위험, 비지니스 위험 총 3가지 위험 분류가 있다.

 

프로젝트 위험은 일정 또는 자원에 영향을 미치는 위험

프로덕트 위험은 개발중인 s/w 품질 또는 성능에 영향을 미치는 위험

비지니스 위험은 s/w를 개발하거나 획득하는 조직에 영향을 미치는 위험

 

각종 위험들을 위 3가지 유형으로 분류하여 관리할 수 있다.

 

이런 위험들을 관리하는 위험 관리 프로세스가 따로 정의 되어 있다.

 

A. 위험 식별 (Risk Identification)

프로젝트, 프로덕트 그리고 비지니스 위험을 식별한다.

기술, 인력, 조직, 도구, 요구사항, 추정에 대한 위험들을 식별하고 분류하는 단계이다. 각종 위험들을 종류별로 분류하면 아래와 같다.

 

B. 위험 분석 (Risk Analysis)

이런 위험들의 발생 가능성과 미치는 영향을 측정한다. 가능성은 매우적음, 적음, 보통, 많음, 매우많음 으로 구분하고

영향은 재난(catastrophic), 심각함(serious), 견딜만함(tolerable), 중요하지 않음(insignificant) 으로 구분한다.

예를 들면 아래와 같음.

 

C. 위험 계획 수립 (Risk Planning)

위험의 영향을 피하거나 최소화하기 위한 계획, 전략을 수립한다.

회피 전략(Avoidance strategies), 최소화 전략(Minimisation strategies), 비상 계획(Contingency plans)

등의 전략을 개발하는 것이 중요하다.  

 

D. 위험 감시 (Risk Monitoring)

프로젝트 내내 위험들을 감시한다. 또한 위험의 영향도의 변화도 측정한다.

각각의 주요한 위험들을 회의를 열어 논의한다.

감시할 때 위험 요인들을 목록화 하여 관리한다.