계획(프로젝트 계획과 관리) (part 2)

일정 계획

- 소프트웨어를 개발하기 위해 어떤 작업이 필요한지 찾은 후, 진행할 순서를 결정하거나 소작업들의 개발 기간을 계획

일정 계획 - 작업 분할 구조도 (Work Breakdown Structure, WBS)

- 프로젝트 목표를 달성하기 위해 필요한 활동을 세분화함

- 프로젝트 구성요소들을 계층 구조로 분류

- 프로젝트 전체 범위 정의

- 프로젝트 작업을 세분화 -> 최하위에 있는 항목은 작업 페키지

- 맨 하위 층을 보면 구현해야되는 기능들을 알 수 있음

장점

- 사용자와 개발자의 의사소통 도구로 사용가능

- 역할과 책임과 분명함

- 업무 내역을 가시화할 수 있어 관리에 용이함

- 필요 인력, 일정 계획, 비용 선정 등에 기초로 활용할 수 있음

- 성과 측정에 기준치로 사용될 수 있음

WBS 작성 후..

- 작업 사이의 의존관계 파악 (선행 관계)

- WBS 기반 작업당 소요 시간 노력 예측

- CPM(Critical Path Model) 이용하여 여유시간 계산

- 소요 자원의 할당

일정 계획 - 네트워크 차트 

- WBS의 작업 순서, 작업 시간을 네트워크 형태의 그래프로 나타냄

- 중요한 작업(늦어지면 일정이 지연될 수 있음)과 안 중요한 작업(일정의 여유가 있음)을 찾아 중점 관리를 해야하는 작업을 명확히할 수 있음

- 지연을 사전에 예방할 수 있고 개발 기간을 단축시킬 수 있음 -> 일정을 효율적으로 관리

- PERT/CPM 기법을 이용

PERT/CPM 의 전개 단계

1. 모든 작업들을 파악함 (WBS)
2. 작업들의 선후관계를 파악하여 네트워크로 표시
3. 작업 소요 시간 추정
4. 최단 완료시간과 임계 경로 파악

네트워크 차트를 그리는 법

1. CPM(Critical Path Model)을 그린다.
2. ES(Earliest Start Time)를 구한다.
   -> 가능한 빨리 시작할 수 있는 시간 (선행 작업이 완료되어 작업을 가장 빨리 시작할 수 있는 시간)
   EF (Earliest Finish Time)를 구해도 된다.
   -> 가장 빠른 완료 시간 (ES + 작업 소요 시간)
3. LS(Latest Start Time)를 구한다. 
   -> 늦어도 시작해야하는 시간 (이 시간에 시작하지 않으면 총 일정이 지연됨)
   LF(Latest Finish Time)를 구해도 된다.
   -> 작업을 가장 늦게 끝낼 수 있는 시간 (LS + 작업 소요 시간)
4. ST(Slack Time)를 구한다.
   -> 여유 시간, LS - ES으로 구할 수 있다. (LF - EF로 구해도 됨)
5. 임계 경로(Critical Path)
   -> 여유 시간이 없는 경로 

일정 계획 - 간트 차트

- 프로젝트 일정 관리를 위한 바 형태의 도구

- WBS를 이용하여 주요 활동들을 파악한 후 일정 시작 시점과 끝나는 시점을 막대 모양으로 표시

- 전체 일정을 한 번에 볼 수 있음

위험 분석

- 소프트웨어 개발에 방해가 되는 요소들을 미리 예상하고 이에 대한 대책을 세우는 것

- 사용자의 요구사항, 개발 인력 부족, 예산 부족 등이 있음

- 위험 분석 단계

1. 위험 요소를 미리 파악하고 (위험 요소 식별)
2. 위험 요소의 발생 확률과 영향도를 판단 (위험 분석)
3. 분석한 결과에 따라 우선 순위를 정해 대책을 세움 (위험 계획 수립)

위험 요소 식별

- 프로젝트 진행에 영향을 주는 위험 요소 식별

- 브레인스토밍이나 유사 프로젝트의 위험 요소 참조

   ( 개발자의 이직, 요구사항 변경, 예상을 빗나간 투입 인력, 개발비 초과 등 )

위험 분석

- 식별한 위험 요소의 발생 가능성과 영향력을 판단

- 경험이 많은 개발자에게 의존

위험 계발 수립

- 위험 분석을 통해 위험 대응 방안 수립

- 우선순위에 따라 진행

(추가) 위험 감시

- 식별된 위험은 계속해서 감시

(추가) 팀 구성하기

- 개발 종류에 따라 팀 구성이 달라짐

- 소통, 협력이 중요함

- 개개인의 역할을 정의해야 함

고려사항

- 프로젝트 기간

   -> 기간이 긴 프로젝트 : 중간 이탈이 없게 해야하며 경험이 많은 사람과 적은 사람이 적절히 섞이도록 해야 함

   -> 기간이 짧은 프로젝트 : 각자할 수 있는 일에 집중하도록 함 (일을 배우는 것은 비효율적)

- 작업의 규모

   -> 규모가 큰 프로젝트 : 여러 계층으로 조직화함

- 소프트웨어의 특성

   -> 소프트웨어의 함수가 다른 함수와의 연관성이 높음 -> 많은 의사소통 필요

(추가) 팀 구성 모델

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

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

- 팀원들의 역할

   책임 프로그래머 : 핵심 부분 코딩, 중요 의사 결정, 작업 지시

   이외의 프로그래머 : 이외의 것들 (시키는 거)

장점

- 의사 결정권이 리더에게 있기 때문에 빠른 결정 가능 (시키는 것만 하면 됨)

- 초보 프로그래머를 키우기 좋음 (의사소통이 많이 없음)

- 소규모 프로젝트에 적합 (프로젝트가 커지면 책임 프로그래머의 역할이 너무 커짐)

단점

- 한 사람의 능력이 프로젝트 전체를 좌우할 수 있음

- 책임 프로그래머 이외의 사람들은 창의성을 발휘할 수 있는 기회가 없음 (시키는 것만 하기 때문에)

- 한 사람에게 너무 쏠려있는 구조

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

 

- 서로 협동항 수행하는 비 이기적인 팀 구성

- 동등한 책임과 권한

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

- 의사 교환경로가 다양 

장점 

- 작업 만족도가 높다 ( 팀 구성원이 모두 동등한 레벨이기 때문 )

- 의사 교류 활성화

- 장기 프로젝트에 적합 (복잡한 프로젝트를 의사소통으로 해결)

단점

- 책임이 명확하지 않음 (모두 책임을 나눈다 -> 아무도 책임을 지지 않는다)

- 대규모 프로젝트에 적합하지 않음 (대규모 프로젝트는 함수가 많음)

   -> 집단의 합의를 이끌어 내기 쉽지 않음

계층적 팀 구성

- 집중형(책임 프로그래머), 분산형(에고리스)의 단점을 보완

- 초보자와 경함자를 분리

- 프로젝트 관리자에게 지휘 권한을 부여

- 의사교환은 중간 관리층으로 분산

장점

- 시스템이 기능적으로 명확하게 나눠지는 프로젝트에 적합

- 대규모 프로젝트에 적합

단점

- 의사 전달 경로가 길어짐