Lecture 05: 계획 (프로젝트 관리와 계획) - 2

경희대학교 김정욱 교수님의 소프트웨어 공학 수업을 기반으로 정리한 글입니다.

일정 계획

5. 일정 계획

소프트웨어를 개발하기 위해 어떤 작업이 필요한지 찾은 후, 진행할 순서를 결정하거나, 주어진 개발 기간에 소작업의 개발 개간 및 그들 간의 순서, 필요한 자원 등과 같은 일정을 계획하는 것이다.

▶ 일정 계획

 

※ 계획은 소프트웨어를 개발하기 위한 것이기에 개발한 이후의 과정인 유지보수 단계는 계획할 필요가 없다.

▶ 일정 계획 예시

 

작업 순서 결정, 소작업의 개발 기간, 순서, 필요한 자원 등의 일정을 계획한다.

 

※ 소작업을 기능이라고 보면 된다.

일정 계획 - 작업 분할 구조도 (WBS)

1) 작업 분할 구조도 (Work Breakdown Structure, WBS)

Top - down 형식으로, 본격적인 일정 계획 전, 각각의 사람이 무슨 작업을 할지 찾는 것을 의미한다. (사람별 소작업 할당)

• 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업
• 프로젝트 구성 요소들을 계층 구조로 분류 (프로젝트의 작업 파악 가능)
• 프로젝트의 전체 범위 정의
• 프로젝트의 작업을 세분화 (최하위에 있는 항목: 작업 패키지)

▶ 작업 분할 구조도 실생활 예시

 

장점

• 사용자와 개발자 간의 의사소통 도구로 사용할 수 있다.
• 프로젝트 업무 내역을 가시화할 수 있어 관리가 용이하다.
• 프로젝트 팀원의 책임과 역할이 분명하다.
• 필요 인력, 일정 계획, 개발비 산정시 기초로 활용할 수 있다.
• 성과 측정 및 조정시 기준선으로 활용할 수 있다.

이러한 WBS를 만드는 가장 근복적인 이유는 '작업별 소요 시간 노력 예측', 그리고 그 후, CPM(Criticla Path Model)을 통해 프로젝트를 완료하는데 필요한 작업을 식별하기 위해서이다.

 

WBS 작성 후

• WBS 기반 작업별 소요 시간 노력 예측
• 작업 사이의 의존 관계 파악
• CPM (Critical Path Model)을 이용한 여유 시간 계산
• 소요 자원의 할당

▶ WBS -> WBS 기반 작업별 소요 시간 노력 예측

일정 계획 - 네트워크 차트 (PERT/CPM) 

2) 네트워크 차트 (PERT/CPM)

WBS의 작업 순서, 소요 기간 등을 네트워크 형태의 그래프로 표현한 것이다.

 

이를 통해 어떤 작업이 중요한지, 또 일정에 여유가 있는 작업은 어떤 것인지 찾아내 중점 관리를 해야 하는 작업을 명확히하는 데 사용할 수 있다.

 

또한, 전체 작업 일정을 세분화하여 지연을 사전에 예방, 개발 기간 단축에 활용하여 일정을 효율적으로 관리할 수 있다.

ex) B는 10달, C는 1달이 걸리면 B부터 시작하여 지연을 방지한다.

 

※ PERT: Program Evaluation and Review Technique)

 

※ 어떤 작업이 중요하다는 것은, 이 작업을 안 하면 일정이 길어진다는 의미이다. 그리고 중요하지 않다는 것은, 이 작업은 시간의 여유를 가지고 해도 된다는 의미이다.

▶ WBS -> PERT/CPM

 

PERT/CPM의 전개 단계

• 1단계: 프로젝트에서 수행되어야 할 모든 활동 파악 (WBS를 통해 파악)
• 2단계: 활동 간의 선행 관계를 결정하고 관계를 네트워크로 표시
• 3단계: 각 활동에 소요되는 시간 추정 
• 4단계: 프로젝트의 최단 완료 시간과 임계 경로(가장 시간이 많이 걸리는 경로)를 파악

▶ PERT/CPM 예시

 

※ 그리고 이를 가지고, 나중에 소작업별 얼마나 시간이 소요되는지 나타내는 간트 차트를 그린다.

네트워크 차트 (예시) - 학사 관리 어플리케이션

▶ 네트워크 차트를 그리기 위한 목록

 

(1) CPM(Critical Path Model)을 그린다.

노드(Node)는 작업, 간선은 노드 간의 선후 의존 관계를 나타낸다.

ex) D는 B, C가 끝나야 시작

▶ CPM

 

(2) ES(Earliest Start Time), EF(Earliest Finish Time)를 구한다.

ES는 가능한 빨리 시작할 수 있는 시간으로, 선행 작업이 완료되었을 때 해당 작업을 시작할 수 있는 가장 빠른 시점을 의미한다.

▶ D의 ES

 

D는 B도 끝나야 되고, C도 끝나야 하기에 min이 아니라 max로 계산한다.

▶ ES

 

EF는 가장 빠른 시작 시간(ES)으로 시작했을 때의 가장 빠른 완료 시간을 의미한다.

때문에 가능한 가장 빨리 끝낼 수 있는 시간으로, 'ES + 작업 소요 시간'으로 구할 수 있다.

▶ D의 EF

 

(3) LS(Latest Start Time)를 구한다.

LS는 늦어도 시작해야 하는 시간으로, 이 시간에 시작하지 않으면(늦으면) 총 일정이 지연된다. (뒤에서 앞 방향으로 계산)

▶ F의 LS

 

ES로 계산했을 때 M이 22라고 할 때,

F가 J에 맞춰 18로 하면 J의 입장에서는 문제가 없지만,

3주 소요로 인해 21에 다음이 시작하게 되어 20에 시작해야 하는 I가 늦어져 연달아 L, M이 늦어지게 된다.

 

때문에 LS는 max가 아닌 min으로 계산해야 한다.

▶ LS

 

(4) LF(Latest Finish Time)를 구한다

LF는 작업을 가장 늦게 끝낼 수 있는 시간, 즉 아무리 늦어도 이때는 끝나야 한다는 의미이다.

때문에 'LS + 작업 소요 시간'으로 계산할 수 있다.

▶ LF

 

(5) ST(Slack Time)를 구한다.

ST는 여유 있는 시간을 의미한다.

때문에 '가장 늦게 시작하는 시간 (LS) - 가장 빨리 시작하는 시간 (ES)'로 구할 수 있다.

혹은 'LF(LS + 작업 소요 시간) - EF(ES - 작업 소요 시간)'로 구해도 동일한 결과가 나온다.

 

즉, LS와 ES의 차이를 구하면 값이 0이 아닌 구간이 나오는데, (양수)

이러한 구간을 slack time이라고 해서, 여유 시간, 즉 시간을 안 지켜도 된다고 판단할 수 있다.

이때 차이가 0이면 여유 없이, 지금 이 순간에  바로 해야 된다는 의미이다. (right now)

▶ ST

 

(5) 임계 경로(Critical Path)를 구한다.

임계 경로는 말 그대로 중요한 경로로, 그래프에 여유 시간이 없는 경로를 의미한다. (ST = 0)

이 경로에서는 미룰 수 없고, 무조건 쉬지 않고 해야 한다. (일정을 꼭 지켜야 함)

 

모든 일정 계획은 임계 경로에 의해 좌우되며, (임계 경로가 무너지면 전체 일정이 무너짐)

임계 경로를 벗어난 작업은 시간 한도 내에서는 여유가 있다고 볼 수 있다.

 

이렇게 Critical Path를 구하여 우선 순위를 구하면 된다.

▶ 임계 경로

 

작업 I가 2주 지연되더라도 5주의 여유 시간이 있어, 프로젝트 최종 완료일에 영향을 미치지 않는다.

일정 계획 - 간트 차트

3) 간트 차트

프로젝트 일정 관리를 위한 바(bar) 형태의 도구이다.

 

WBS를 통해 프로젝트의 주요 활동을 파악한 후, (소작업 분류)

각 활동의 일정을 시작하는 시점과 끝나는 시점을 연결한 막대 모양으로 표시한다.

 

때문에, 전체 일정을 한 눈에 볼 수 있다는 장점이 있다. (가시적)

▶ 간트 차트

 

※ 계획 단계는, 말 그대로 계획이기에 구체적이지 않고 러프하게 짜야 한다.

위험 분석

6. 위험 분석

소프트웨어 개발에 방해가 되는 요소를 미리 예상하고, 이에 관해 적절한 대책을 수립하는 활동이다.

 

위험 요소: 사용자 요구사항 (가장 큰 위험 요소), 인력 부족, 예산 부족 등

위험 분석 단계

1) 위험 요소를 미리 파악하고 (위험 요소 식별),

2) 위험 요소의 발생 확률과 영향도를 평가한 뒤 (위험 분석),

3) 분석한 결과에 따라 위험 우선 순위를 정해 그에 맞게 대책을 세워야 함 (위험 계획 수립)

4) 위험 감시

▶ 위험 분석 단계

 

1) 위험 요소 식별

• 프로젝트 수행에 영향을 주는 위험 요소 파악
• 브레인토밍 또는 유사 프로젝트 때의 위험 요소 참조

▶ 위험 요소 식

 

2) 위험 분석

• 위험 요소 식별 후, 위험 요소가 발생할 가능성과 영향력을 판단
• 과거 프로젝트에서 위험을 분석한 경험이 많은 개발자에 의존
• 위험 발생 가능성, 위험 발생 확률 등 분석

3) 위험 계획 수립

• 위험 분석을 통해 이를 처리하는 위험 대응 방안 수립
• 우선 순위에 따라 진행

4) 위험 감시

• 식별된 위험은 계속 감시
• 유사한 프로젝트를 진행할 때 참고할 수 있도록 데이터베이스 내에 기록

(추가) 팀 구성하기

소프트웨어 팀 구성

• 소프트웨어는 개발 종류에 따라 팀(조직) 구성이 다름
• 개개인의 역할을 정의하고 프로젝트에 적절히 할당해서 목표를 이뤄야 함
• 팀 구성의 목적: 협력, 상호작용

소프트웨어 팀 구성을 위한 고려사항

1) 프로젝트의 기간

• 기간이 긴 프로젝트: (1) 개인의 만족도를 높여 중간 이탈이 없도록, (2) 경험이 많은 사람과 적은 사람이 적절히 혼합되도록
• 기간이 짧은 프로젝트: 각자 할 수 있는 일에 집중할 수 있도록 (해당 기간에 일을 배우는 것은 비효율적)

2) 작업의 규모

• 규모가 큰 작업: 여러 계층으로 조직화

3) 소프트웨어의 특성

• 소프트웨어 내 함수가 다른 함수들고 연관성이 높으면 구성원 간 많은 의사소통 필요

(추가) 팀 구성 모델

1) 책임 프로그래머(Chief Programmer) 팀 구성

팀 구성원이 관리자(책임 프로그래머)의 명령을 따라 일하고 결과를 보고하는 방식이다. (Top-down 방식)

 

팀원들의 역할

• 책임 프로그래머: 향후 요구사항 분석, 설계, 핵심부분 코딩, 중요 의사 결정, 작업지시 담당
• 이외의 프로그래머: 이외의 것들 담당 (각 모듈 프로그래밍, 설계 문서 및 테스트 관리)

▶ 책임 프로그래머 팀 구성

 

장점

• 의사 결정권이 리더에게 있어 의사 결정이 빠르다.
• 소규모 프로젝트에 적합하다.
• 초보 프로그래머 훈련시키는 기회로 적합하다.

단점

• 한 사람의 능력과 경험이 프로젝트를 좌우한다.
• 팀 구성원은 개인적인 창의성을 발휘할 기회가 없다.
• 책임 프로그래머에게 오버로드(과부하) 가능성이 있다.
• 이외의 구성원의 역할이 애매하다.

2) 에고리스(Ego-less) 팀 구성

서로 협동하여 수행하는 비이기적인(Ego-less) 팀 구성으로, (자아가 없는)

자신있는 일을 알아서 수행하며 구성원이 동등한 책임과 권한이 있어 의사 교환 경로가 다양하다.

▶ 에고리스 팀 구성

 

장점

• 작업 만족도가 높다. (팀 구성원 모두가 동등한 레벨)
• 의사 교류가 활성화된다. (적극성을 띔)
• 장기 프로젝트에 적합하다. (복잡한 프로젝트를 원활한 의사소통으로 해결)

단점

• 책임이 명확하지 않은 일이 발생한다. (모두가 책임을 나눈다 = 아무도 책임을 지지 않는다)
• 대규모 소프트웨어에 적합하지 않다. (대규모 = 함수가 많이 얽힘)

3) 계층적 팀 구성

집중형(책임 프로그래머), 분산형(에고리스)의 단점을 보완한 팀 구성으로, 초보자와 경험자를 분리한다.

 

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

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

▶ 계층적 팀 구성

 

장점

• 개발 시스템이 기능적으로 명확하게 나눠지는 프로젝트에 적합하다.
• 대규모 프로젝트에 적합하다.

단점

• 의사 전달 경로가 길어진다.