[소공] 3장 프로젝트 관리와 계획

0. 프로젝트 관리의 목적

: 작업 수행에 필요한 자원 등을 효과적으로 사용해 프로젝트 목표를 달성하는 것.

1. 프로젝트 관리 목표(7)

  - 최종 결과가 고객의 요구를 만족.

  - 결과물의 속성(품질, 비용 등)이 요구 수준에 부합.

  - 일정 준수

  - 팀, 팀원 역량 발휘

  - 실행을 모니터링하고, 조정

  - 리스크를 예측하고, 대비

  - 자원의 효과적 사용

2. SW 프로젝트 관리의 어려움(3)

  - 개발 대상이 눈에 안보임.

  - SW 분야의 기술 발전은 매우 빠름.

  - SW 분야는 조직마다 프로세스가 다름.

3. 프로젝트 관리 활동의 요소(4)

  - 계획/ 조직/ 모니터링/ 조정

4. 프로젝트 관리 프로세스

  : 프로젝트 시작→ 프로젝트 계획→ 실행과 모니터링→ 종료

3-1 프로젝트 시작

1. 프로젝트의 첫 작업(2)

: 목표 세우기, 가치와 리스크를 이해하기

2. 프로젝트 시작할 지, 말 지 결정 요인(2)

  - 프로젝트가 제공할 가치 (직/간접 가치, 결과물의 지속 가능성)

  - 프로젝트와 관련된 리스크 (자원가용성, 타이밍, 기술적 어려움, 불확정성 등)

3. 가치를 평가하는 방법(4)

  - 투자 회수 기간: 투자금과 같은 금액을 버는데 걸리는 시간

  - ROI(Return of Investment): 연간 평균 이익률

  - 순수 현재 가치: 현재 투자금과 미래 수익금을 현재 가치로 비교

  - 평가표: 금전 요소외 기술, 인력 등을 고려해 점수화

  - SWOT: 플젝의 강점/약점/기회요인/위험요인을 파요인악

4. 프로젝트 위험 요인(6)

  - 자원

  -  현재 사용량과 가용성

  -  예상 사용량과 가용성  

  -  프로젝트 우선순위 및 중요도

  - 시간 

  - 기술적 어려움 및 불확정성

5. 타당성 분석(7)

: 프로젝트를 기관의 목표와 연결시키는 문서. 관리자 입장에서는 프로젝트 선택에 기초가 되는 문서이다.

(SOW: Statement of work)

 

3-2 프로젝트 계획과 스케줄링

1. 프로젝트 초기 계획(3)

: 목표 설정/ 일정 정의/ 비용 추정

2. 프로젝트 범위 정하기

: 프로젝트 계획의 시작. 시스템이 해결할 문제들을 리스트로 작성 후 범위 선정.

3. WBS(Work Breakdown Structure) 분석

: 개발 팀이 프로젝트 결과를 산출하기 위해 수행해야할 작업들을 계층적으로 분할한 것

4. 스케줄링(3)

: WBS를 기초로 일정을 정의하는 것.

  step1) 작업 의존 관계 파악

  step2) CPM 네트워크(Critical Path Method)

       - 임계경로: 소요 기간이 가장 긴 경로. 이 경로 상에 있는 어떤 작업이라도 늦춰지면 프로젝트 지연됨.

       -  여유시간: TS = TL(최대 늦는 착수) - TE(최대 빠른 착수일)

  step3) 소요 자원 할당

5. 에자일 프로세스의 스케줄링

: 전통적인 프로세스에서는 위처럼 CPM을 사용해 스케줄링함. 에자일 프로세스는 스토리 카드를 사용해 스케줄링함.

여기서 스토리 점수는 개발 노력임. 위의 팀은 스토리 점수 3점을 개발하려면 1주 소요.

 

3-3 비용 예측 기법

1. 노력과 자원

  - 노력: 프로젝트를 완성시키기 위해 필요한 작업의 양. 작업을 완료시키기 위한 노동의 양.

    (ex. 3명이 1개월 동안 작업한 노력: 3MM(Man-Month))

  - 자원: 작업에 동원될 수 있는 인력의 양.

  - 기간: 수행될 기간

: 노력(E)과 자원(M), 기간(D)의 관계

'

2. 비용 예측 방법(3)

  - 전문가 판단

  - PERT(Program Evaluation and REview Technique)

  - 알고리즘식 방법: COCOMO(Constructive Cost Model), 기능점수, 객체점수 모델

3. COCOMO-81

: 시스템 규모를 추정하고 이를 준비된 식에 대입해 소요 MM을 예측.

: 노력 = A * (Size)^B * M

(A: 개발 특징 등에 좌우됨, Size: 원시코드 라인 수 등, B: 1~1.5사이로 비선형적 비례를 의미, M: 노력승수를 모두 곱한 값)

- 단점(3)

• 프로젝트 초기 단계에서 Size값을 예측하는 것은 어려움.
• 기본 예측모델에서 B와 M의 값에 영향을 주는 요소들이 주관적임.
• 보정(calibration): 모델의 노력 승수 값이 프로젝트 팀 고유 환경에 일치하나 알기 어려움. 계속 보정해야 함.

4. COCOMO II

: 소프트웨어 개발 프로젝트의 진행 정도에 따라 세가지 다른 모델을 제시

         1단계: 프로토타입 만드는 단계 → 2단계: 초기 설계 단계 → 3단계 구조설계 이후 단계

: 노력 = A * (Size)^B * M

 - 과정

  ① 애플리케이션을 구성하는 화면, 보고서, 3세대 언어 컴포넌트의 숫자 세기.

  ② 아래의 표를 이용해 화면과 보고서의 복잡도 수준 결정.

  ③ 아래의 표를 이용해 화면, 보고서, 3세대 언어 컴포넌트를 위한 복잡도 가중치 찾기

  ④ 화면 보고서, 3세대 언어 컴포넌트 개수에 가중치를 곱해 객체 점수 계산(OP)

  ⑤ 재사용률을 예측해 아래으 공식에 대입해 NOP를 구함

  ⑥ 객체 점수 생산성(PROD)을 결정

  ⑦ 객체 점수 생산성을 식 PM = NOP/PROD에 대입해 최종 PM(Person Month)을 구함

(실제 예시는 pdf 참고하기!!!!)

5. 기능 점수

: 소프트웨어 시스템이 갖는 기능(입력, 출력, 질의, 화일, 인터페이스의 개수)을 정량화한 것.

 - 과정

  ① 다섯 가지 기능 분야에 해당되는 개수를 표에 채움.

  ② 복잡도를 결정해 표시.

  ③ GFP(총 기능 점수)를 구한다. 개수와 복잡도 가중치를 곱하고 총합을 구함.

  ④ 14개의 질문으로 처리복잡도의 정도에 따라 0에서 5까지 할당.

  ⑤ PCA(처리 복잡도 보정계수)를 구함. PCA는 0.65에서 1.35를 넘지 않는다.

0.65는 경험에 의한 상수값임.

  ⑥ 아래의 식에 넣어 기능 점수를 구함.

(국내 기능 점수산정 가이드는 pdf 참조할 것)

 

3-4 프로젝트 팀 조직

1. 프로젝트 팀 조직 정의(3)

  - 역할과 책임이어디에 있는가?

  - 어떤 통로로 정보가 전달되고 결정되는가?

  - 어떻게 갈등을 해소할 것인가?

2. 팀 역할 종류(10)

: 프로젝트 관리자, 시스템 운영자, 시스템 분석가, 시스템 개발자, 데이터베이스 엔지니어, QA 관리자, 기술지원, 하드웨어 엔지니어, 웹 개발자, 디자이너

3. 조직의 종류(4)

  (1) 직능별 조직

       : 팀원은 한 부서에 소속. 프로젝트의 협력은 부서별로.서로 다른 부서가 한 프로젝트의 다른 단계에 들어와 작업 수행.

  (2) 프로젝트별 조직

       : 의사 전달 경로가 짧음. 프로젝트 관리가 수월. 자원 효율성 측면에서도 가장 좋음.

  (3) 매트릭스 조직

       : 직능별 조직 + 프로젝트별 조직. 직능별 조직에 속해 있되, 간헐적으로 일함. 각 프로젝트마다 관리자 존재.

       - 강한 메트릭스: 프로젝트 관리자가 프로젝트에 책임을 지고 팀원들은 직능별 조직보다 프로젝트에 더 개입.

       - 약한 매트릭스:  프로젝트의 책임을 직능별 관리자에게 맡기고, 직능별 조직에 소속된 팀원도 적극적 담당.

  (4) 애자일 조직

       : 5~9명의 팀. 결과와 이슈에 대한 오너쉽을 공유.

       - 스크럼 마스터: 프로젝트 진도 측정하고, 문제 해결. 외부로부터 팀 보호

       - 프로젝트 오너(고객): 요구 분석 결과물 오너

       - 개발팀: 하나의 스프린트에서 생산된 결과물을 오너에게 시연. 매일 스크럼 회의에 참여해 진척 상황 점검.

 

3-5 실행과 모니터링

1. 프로젝트 실행(2)

  - 작업 시작 미팅: 작업을 공포하고 팀을 확인하기위해 회의 진행.

  - 작업 결과 수집: 결과물을 체계적으로 수집

2. 프로젝트 모니터링

: 프로젝트 현황을 파악하고 차이 분석하여 조치함.

3. 모니터링 종류(2)

  - 일정 모니터링: 계획된 일정과 실제 일정을 비교. 투입된 노력을 시간단위로 환산해 수집.

  - 어닝 밸류 분석: 비용과 일정을 통합된 방법으로 모니터링. 미래 비용과 일정 예측 가능.

4. 번다운 차트

  - 번다운 차트의 목표: 기능이 출시되는 속도 측정.(에자일 프로세스 중 스크럼에서 사용)(남아있는 작업에 초점)

  - 번다운 차트의 전제: 스프린트 사이의 속도는 일정.

x축: 스프린트 log 개수, y축: 기능 점수

(각 가능은 스프린트에 배정되어 기능이 완성되면서 소멸되는 스프린트 점수로 기록)

 

3-6 리스크 관리

1. 리스크 관리의 목적

: 위험이 발생되었을 때의 영향을 줄이는 것

2. 리스크 파악 방법(4)

  - 회의/문서 분석/리스크 분할 구조, 체크리스트/유추

(리스크 분할 구조, 체크리스트: 리스크 항목을 분할하여 계층 구조로 그리거나 체크리스트로 파악.)

(유추: 유사 프로젝트 유형과 비교하여 유추)

3. 리스크 평가

  - E: 발생 가능성이 높고, 영향이 큰 것. -> 관리 못하면 프로젝트 실패 가능

  - H: ausalfgl ahslxjfld vlfdy

  - 그외: 해가 되는 요소

(E가 최우선, 다음 H)

4.리스크 관리(4)

: 위험 요소를 해소하기 위한 방법을 강구하고,  플젝 실행 동안 이를 적용.

  - 리스크를 피하기 위해 계획을 변경하거나 책임을 다른 기관에 맡김

  - 프로토타이핑

  - 유능한 인재를 등용

  - 3자와 협업