1. 프로젝트 식별 및 관리

프로젝트를 어떻게 시작하느냐에 대한 관점

프로젝트를 시작하기 전, 어떻게 평가할 지, 그리고 어떻게 계획을 세울지를 설명한다.

프로젝트 식별

1. System Request 작성

Project Sponsor

프로젝트의 아이디어 제공자

프로젝트의 금전적 지원자 아님.
Business Need
Business requirements
Business Value : CEO의 입장에서 가장 먼저 보게된다.
- 프로젝트의 Business Value가 명확해야 한다.
- Economic feasibility부분을 미리 고민해봐야 한다.
Special issues or constraints

프로젝트 마감 기간 등

ex) 크리스마스 시즌 전에 완성해야 한다.

2. Feasibility Analysis(타당성 분석)

프로젝트를 진행하기 전에 분석해야 한다.

Technical feasibility

기술적으로 개발이 가능한지에 대한 분석
1. 도메인과의 친숙도
  
  우리가 평소 개발하던 분야가 얼마나 해당 분야와 가까운가에 대한 것
2. 기술적 친숙도
3. 프로젝트 크기
4. 기존 시스템과의 경쟁성
5. 기존 시스템과의 호환성
  
  기존 프로젝트와의 비교
  
  외부 전문가의 평가
Economic feasibility

해당 프로젝트가 돈이 되는지에 대한 분석
1. Net present value(NPV)
2. Return on investment(ROI)
  
  클수록 좋다.
3. Break even point(BEP) : 손익분기점
  
  빠를수록 좋다.
Step
1. Identify costs and benefits
  - Data Conversion Costs
    
    시스템 변경시 기존의 데이터를 새로운 시스템으로 옮기는 데 소모되는 비용
  - Tangible Benefits
    
    돈으로 쉽게 환산 가능한 이익
  - Intangible Benefits
    
    돈으로 쉽게 환산하기 어려운 이익
    - 가능하면 Intangible Benefit을 돈으로 환산하여 수치화하는 것이 좋다.
    - 가장 어렵다.
2. Assign Cost and Benefit Values
  
  돈으로 환산하기
3. Determine Cash Flow
  
  재무재표 분석
4. Assess Financial Viability
  
  현재가치로의 환산 : 복리를 활용
  
  NPV > 0 ⇒ 프로젝트가 괜찮다.
Organizational feasibility

유저가 사용할 것인가에 대한 분석

Strategic alignment

이해관계자 분석(Stakeholder analysis)
- Project champion(s)
- Organizational management
  
  예산에 대한 분석
- System users

3. Project Selection Issues

Portfolio Management

회사 전체의 포트폴리오 관점에서 진행할지 여부를 결정

회사에서 진행하는 다른 프로젝트와의 밸런스 등을 고려, 최종적으로 진행여부를 결정.

해당 방식이 반드시 회사 내에서 이뤄지지 않을 수도 있다.

프로젝트의 요구사항(RFP)만 작성하면, 여러 외부업체들에서 프로젝트 제안서(proposal)을 받아서 업체를 선택하고, 완성된 프로젝트를 넘겨받는 방식도 존재한다.

RFP를 작성하기 위해 프로젝트 관리에 대한 내용을 알아둬야 한다.

원하는 프로젝트에 소요되는 시간, 비용, 노동력을 분석할 수 있어야 프로젝트를 합리적으로 요청할 수 있다.

프로젝트 관리

프로젝트의 기간이 어떻게 되는지, 노동력은 얼마나 들어가는지에 대한 관점

1. Identifying project size

비용을 결정하는 중요한 요소

Project Estimation

Mathodology in use
Actual previous projects
Experienced developers

SWE

프로젝트의 비용과 시간과 크기는 서로 연관되기 때문에 시간의 흐름에 따라 계속 분석해야 한다.

SWE

function points

SWE

여기서 function은 프로그래밍 코드 상의 function이 아닌 진짜 기능을 의미한다.

기능 유형

Inputs
- 시스템에서 입력이 몇개나 필요한지에 대한 것.
  
  마찬가지로 단순한 파라미터를 의미하는 것이 아닌 입력 데이터의 종류를 의미한다.
Outputs
Queries

참조하는 데이터의 개수? 좀 더 알아볼 것.
Files
Program Interfaces

외부 Interface을 의미한다.

SWE

function point 예시

SWE

학점을 조회하는 것이 단순하게 출력만 한다면 EO라고 볼 수 있지만,

학점을 가공하여 출력하는 경우 EQ가 된다.

위의 학생 학점 조회는 EQ에 해당한다.(오타라고 짐작됨)

Lines of codes

Project의 code line 수를 측정하면 대략적으로 알아낼 수 있다.

function point를 계산하면 기능별 필요한 코드수가 나온다.
Person Months

한 사람이 한달에 해내는 업무량

만약 14 Person Months라면 한 사람이 14달동안 해야하는 작업량이라는 것.

14명이 작업한다고 해서 작업기간이 1달로 줄지는 않는다.

⇒ 업무에는 선후관계가 존재하기 때문이다.

2. Creating and managing the workplan

프로젝트의 크기가 결정되고 난 후, PM은 계획을 짜야한다.

계획을 짜기 위해서

해야하는 업무를 나열해야 하고
사람에게 업무를 할당해야 한다.

업무가 너무 크다면 업무를 세분화시켜야 한다.

Work Breakdown Structure

workplan

Task name
Duration of Dask
Current task status
Task dependencies
Milestone (dates)
workplan 예시

하지만 workplan으로는 파악하기가 불편하다. 시각화가 필요하다.

Gantt Chart
- 간단한 모델
  
  업무의 기간만을 표시해놓은 바형 그래프
  - 정보가 너무 적다.
  - 누가 해당 업무를 하는지, dependency에 대한 정보 등등이 없다.
- 정식 모델
Critical Path
- 어떤 업무가 조금이라도 밀린다면 전체 업무가 밀리는 경우
- 업무간의 간격이 전혀 없는 경우
  
  위의 표에서 Alan의 path가 Critical path에 해당한다.
- 보통 Critical Path는 가장 유능한 사람이 맡게 된다.
  
  Alan이 가장 유능하다고 짐작할 수 있다.
PERT Chart
- X : 진행완료
- \ : 진행중