5. 프로젝트 관리 및 계획 -2

프로젝트 스케쥴링

COCOMO를 통해서 비용을 추정했다면, 이제는 프로젝트를 진행할 기간과 기간별 진행 요소들을 스케쥴링 해야한다. WBS-CPM-Gantt Chart로 이어지는 방식으로 프로젝트를 스케쥴링 해보자.

WBS(Work Breakdown Structure)

Untitled

만들고자 하는 소프트웨어를 여러 계층으로 나누는 방법이다. 세분화 하면 Top-down, Bottom-up, Analogy, Brainstorming 등의 방법이 있다.

CPM(Critical Path Method)

CPM은 프로젝트를 완료하기까지 최소한 어느 정도의 기간이 필요한가 알아내는 기법이다. 또한 작업간의 종속성이나 소요기간을 시각적으로 확인할 수 있는 좋은 방법이다.

Untitled

CPM을 그리기 위해서는, WBS에서 세분화한 소작업들에 대하여 종속성 분석이 선행되어야 한다. 종속성 분석이란, 어떤 작업을 수행하기 위해서 필요한 선행 작업들을 확인하는 것을 의미한다. 또한, 각 소작업에 소요되는 소요기간을 정리한다.

Untitled

이렇게 정리한 표를 가지고 CPM 네트워크를 그린다. 네트워크의 구성 요소는 다음과 같다.

  • 원형의 노드 → 소작업
  • 화살표 → 작업의 선후 의존 관계
  • 화살표 위의 숫자 → 해당 작업을 마치는데 필요한 소요 기간.
  • S, X노드 → 시작 노드, 끝 노드
  • 사각형 노드 → 마일스톤. 프로젝트의 중요한 중간 결과를 완성하였다는 표시.

작업을 완료하기까지 필요한 여러 경로들이 보일 것이다.

네트워크를 전부 그렸다면 임계 경로(Critical Path)를 구할 수 있다. 임계경로란, CPM 네트워크에서 작업 소요 기간이 가장 긴 경로를 의미한다. 프로젝트를 완료하기 위한 최소 소요 기간이 임계경로의 작업 소요 기간과 같다는 점을 기억하자. 임계 경로의 작업 소요기간이 늘어나면 프로젝트 전체의 작업 소요 기간 또한 늘어난다.

임계 경로를 제외한 다른 경로들은 상대적으로 여유 기간이 생기는데, 이를 Slack Time이라고 한다.

간트 차트(Gantt Chart)

CPM은 좋은 방법이지만, 시각적으로 썩 훌륭하지는 않다. 그래서 보통은 간트 차트를 이용하여 프로젝트 작업 일정을 표현한다.

Untitled

간트차트는 전체적인 시간 흐름(가로축 날짜 표시) 속에서 작업들의 시작일, 종료일을 표시한다. 흰색으로 된 부분이 작업에 소요되는 일정이며, 회색 부분들은 slack time이다.

팀 구성

소프트웨어 개발을 위한 팀은 상황에 맞추어 유동적으로 구성될 수 있다. 그렇기에 ‘이런 역할들이 있다’ 정도로만 언급하고 넘어가자.

구성원

  • PM(Project Manager) - management
  • PL(Project Leader) - technology
  • Software Engineer
  • Tester(QA)
  • Build/Release
  • Technical Writer

구조

  • Chief programmer team

    Untitled

    Chief programmer 한 명에 여러 서포팅이 붙는 구조.

  • Egoless team

    Untitled

    모두가 공평하게 의견을 교환한다. 오픈소스 진영에서 자주 보인다.

  • Hierarchical team

    Untitled

    개발 규모가 커짐에 따라 계층적 구조로 변한다.

리스크 관리

앞 부분이 길어서 잊어버렸을 수 있으니 다시 기억하자. 우리는 지금 소프트웨어 프로젝트 계획단계에서 어떻게 리스크 관리를 할지 알아보고있다.

리스크 관리는 아래의 3단계로 구성된다.

  • Risk Identification - 리스크 정체 파악하기.
  • Risk analysis & Risk prioritization - 리스크 분석하고 우선순위 매기기.
  • Risk resolution & Risk monitoring - 리스크를 해결하거나 지켜보기.

1) Risk identification

아래의 분야들에서 리스크가 발생 할 수 있으니 미리미리 확인하는 것이 좋다.

  • Estimation - 짧은 일정, 저조한 오류 수정률, 잘못된 규모 측정 등
  • Organizational - 프로젝트 담당 부서변경, 예산 축소 등
  • People - 전문 인력 구인, 핵심 멤버 부재, 훈련 부재 등
  • Requirements - 중요 설계에 대한 요구사항 변경 등
  • Technology - 처리 속도 저하, 컴포넌트 오류 등
  • Tools - 도구의 기능 부족, 개발 문화와 맞지 않는 도구 등

2) Risk analysis

두 가지 측면에서 리스크를 평가한다. 이를 통해서 먼저 해결해야 하는 리스크가 무엇인지 확인한다.

  • 해당 리스크가 발생할 확률이 얼마나 되는가?
  • 발생한다면 얼마나 큰 영향을 미치는가?

3) Risk monitoring

리스크가 발생할 징조를 확인한다. 쓰나미가 오기 전에 새들이 날아가거나 물이 역류하는 등의 징조를 보이듯, 리스크가 발생하기 전에도 징조가 보일 것이다.

Untitled

참고자료