과 정 명 : 개발자가 알아야 할 PM & QA 교육기간 : – 강 사 명 : 김동희

과 정 명 : 개발자가 알아야 할 PM & QA 교육기간 : 2010. 03. 02 – 03. 06 강 사 명 : 김동희

1 일차 2 일차 3 일차 4 일차 5 일차 3월 2일(화) 3월 3일(수) 3월 4일(목) 3월 5일(금) 3월 6일(토)
프로젝트관리의 개요 • 프로젝트관리이론 및 필요성 • 프로세스관리영역과 프로젝트관리프로세스 프로젝트통합관리 • 프로젝트헌장개발 • 프로젝트관리계획개발 • 프로젝트실행지시 및 관리 • 프로젝트작업감시 및 통제 • 프로젝트 또는 단계종료 프로젝트범위관리 • 요구사항수집 • 범위정의 • 작업분류체계(WBS)작성 • 범위검증 • 범위통제 프로젝트일정관리 • 활동정의 • 활동순서배열 • 활동자원산정 • 활동기간산정 • 일정개발 • 일정통제 프로젝트원가관리 • 원가산정 • 예산결정 • 원가통제 - 프로젝트품질관리 • 품질계획수립 • 품질보증수행 • 품질통제수행 - 프로젝트인적자원관리 • 인적자원계획서개발 • 프로젝트 팀 확보 • 프로젝트 팀 개발 • 프로젝트 팀 관리 - 프로젝트의사소통관리 • 이해관계자식별 • 의사소통계획수립 • 정보배포 • 이해관계자기대사항관리 • 성과보고 - 프로젝트리스크관리 • 리스크관리계획수립 • 리스크식별 • 정성적리스크분석수행 • 정량적리스크분석수행 • 리스크대응계획수립 • 리스크감시 및 통제 - 프로젝트조달관리 • 조달계획수립 • 조달수행 • 조달관리 • 조달종료 - 프로젝트형상관리 • 형상식별 • 형상통제 • 형상관리 - 품질보증 • 품질 과 품질보증 개요 • 품질평가 및 점검 • S/W품질 측정 및 매트릭스 - 품질보증 활동 • 품질보증 프로세스 • S/W품질 성숙도 평가모델 • 인스펙션 워크샵 Page  2

과정개요 과정개요 프로젝트 PM 뿐만 아니라 프로젝트에 투입되는 개발자, 설계자 및 관리자 등 프로젝트에 참여하는 모든 이해관계자들이 프로젝트관리와 이를 지원하는 품질활동에 대해 이해하고 활용할 수 있는 방안을 제시 과정목표 프로젝트 관리의 기본 원칙 이해 및 중요성 인식 프로젝트 수행단계별 필요한 관리영역 이해 프로젝트 관리 영역별 활용하는 지원 도구와 기법 습득 품질 보증 활동의 필요성 및 프로세스 이해 Page  3

목차 2. 프로젝트 통합관리 3. 프로젝트 범위관리 4. 프로젝트 일정관리 5. 프로젝트 원가관리 6. 프로젝트 품질관리
1. 프로젝트 관리 개요 2. 프로젝트 통합관리 3. 프로젝트 범위관리 4. 프로젝트 일정관리 5. 프로젝트 원가관리 6. 프로젝트 품질관리 7. 프로젝트 인적자원관리 8. 프로젝트 의사소통관리 9. 프로젝트 리스크관리 10. 프로젝트 조달관리 11. 프로젝트 형상관리 12. 품질보증 개요 13. 품질보증 활동 및 기법 Page  4

프로젝트 관리 개요 프로젝트 관리 이론 프로젝트 관리 프로세스 그룹 프로젝트 관리 영역 Page  5

프로젝트 관리 이론 프로젝트란 무엇인가? 프로젝트의 특성
고유한 제품, 서비스 또는 결과물을 창출하기 위해 수행하는 한시적인 활동 프로젝트의 특성 한시성(Temporary) 시작과 끝이 정해져 있음을 의미 프로젝트목표가 달성되었을 때 프로젝트 목표를 충족할 가능성이 없어서 프로젝트를 종료했을 때 프로젝트가 더 이상 필요하지 않을 때 고유성(Unique) 모든 프로젝트는 항상 새롭고 처음 하는 업무라는 의미 유사한 프로젝트를 반복하여 수행하는 경우도 있지만 엄밀히 따지면 다른 설계, 다른 환경 등 고유한 특성을 지님 점진적 구체화(Progressive Elaboration) 모든 프로젝트는 초기의 개략적인 범위정의에서 시작하여 점차 구체화하여 구현한다는 의미 단계적 발전과 일정한 증가를 유지하면서 지속되는 것을 의미 Page  6

프로젝트 관리 이론 프로젝트와 운영의 차이 프로젝트 운영(Operation) 목표 기간 목표의 달성(종료)
( 예 : 정보 시스템 개발 ) 목표의 유지(~ing) ( 예 : 정보 시스템 활용 ) 목표 기간 -독특(unique)하고 -한시성(temporary) 개발 -반복적(repetitive) -지속적(ongoing) 활동 프로젝트 종료 Page  7

프로젝트 관리 이론 프로젝트 관리란 무엇인가? 프로젝트 관리 업무
프로젝트 요구사항을 충족시키기 위해 지식, 기술, 도구, 기법 등을 프로젝트 활동에 적용하는 것 프로젝트 관리 업무 요구사항 식별 프로젝트가 계획되고 실행됨에 따라 발생하는 이해관계자의 다양한 요구사항, 관심사항, 기대사항의 처리 및 해결 범위, 품질, 일정, 예산, 자원, RISK를 포함하여 서로 경합하는 다양한 프로젝트의 제약사항들 사이에서의 균형유지 Page  8

프로젝트 관리 이론 프로젝트 관리의 3가지 제약사항(Triple Constraint) Page  9 범위(Scope)
일정(Time) 품질(Quality) 원가(Cost) Page  9

프로젝트 관리 이론 포트폴리오, 프로그램, 프로젝트관리 상호작용 Page  10

프로젝트 관리 이론 포트폴리오 포트폴리오 관리
전략적 사업 목표를 달성하기 위해 작업을 효율적으로 관리해야 하는 프로젝트 또는 프로그램, 기타 관련 작업의 모음 포트폴리오 관리 특정한 전략적 사업 목표를 달성하기 위해 하나 이상의 포트폴리오를 중앙에서 관리하는 것을 의미 프로젝트, 프로그램, 기타 관련 작업의 식별, 우선순위 지정, 승인, 관리 및 통제 프로젝트와 프로그램을 검토하여 자원할당의 우선순위를 결정하고 포트폴리오의 관리가 조직의 전략과 일치하며 일관성을 유지하도록 주력 조직 전체 차원에서 프로젝트와 프로그램을 최적으로 통합관리 하는 것 Page  11

프로젝트 관리 이론 프로그램 개별적으로 관리할 경우 확보할 수 없는 혜택과 통제를 얻기 위해 통합적인 방법으로 관리되는 관련 프로젝트들의 그룹으로 정의 프로그램은 항상 다수의 프로젝트를 포함하고 있다 프로그램 관리 프로그램의 전략적 목표와 혜택을 달성하기 위해 중앙에서 조정된 방식으로 프로그램을 관리하는 것 여러 개의 프로젝트를 통합하여 관리하는 것 프로그램 관리는 프로젝트 상호 의존성에 중점을 둠 시스템 내에서 여러 프로젝트에 영향을 미치는 자원 제약사항 및/또는 충돌사항 해결 프로젝트 및 프로그램 목표와 목적에 영향을 미치는 조직적/전략적 방향 조율 공유된 거버넌스 구조 내에서 이슈 해결 및 변경관리 Page  12

프로젝트 관리 이론 포트폴리오, 프로그램, 프로젝트 계층구조 포트폴리오 프로그램 프로젝트 서브프로젝트 Page  13

프로젝트 관리 이론 프로젝트관리오피스(PMO : Project Management Office)
해당 영역의 프로젝트를 조정된 중앙 통제 방식으로 관리하기 위하여 필요한 다양한 책임을 배정받은 조직 부서나 주체 PMO가 관리하는 모든 프로젝트 전반에 걸친 공유자원 관리 프로젝트 관리 방법론, 모범적 실무관행, 표준 식별 및 개발 지도, 편달, 교육 및 감독 프로젝트 감사를 통해 프로젝트 관리 표준정책, 절차 및 템플릿 준수 여부 감시 프로젝트 정책, 절차, 템플릿 및 기타 공유 문서(조직 프로세스 자산)의 개발 및 관리 프로젝트간 정보 교환 조정 Page  14

PM (Project Management)
프로젝트 관리 이론 PMO 와 PM 차이점 구분 PMO PM (Project Management) 관리대상 프로그램, 포트폴리오 프로젝트 목 표 전체 조직의 목표달성 개별 프로젝트의 성공 자원관리 프로젝트 간 자원 운영의 최적화 주어진 자원을 최대한 활용 관리관점 전사관점에서의 위험관리 프로젝트 관리(범위,일정,원가,품질 등) Page  15

프로젝트 관리 이론 기업 환경 요인(EEF: Enterprise Environmental Factors)
조직의 문화, 구조 및 프로세스 정부 또는 산업 표준(예:규제 당국 규정, 행동 강령, 제품 표준, 품질 표준) 인프라(예:기존 시설, 자본 장비) 기존 인적자원(예:설계, 개발, 법률, 계약, 구매 등의 기량, 숙련도, 지식) 인사 행정(예:인력투입 및 존속 지침, 사원성과 검토 및 교육 기록, 시간외 근무정책) 회사의 작업 승인 시스템 시장 여건 이해관계자 리스크 허용한도 정치 풍토 조직에 구축된 의사소통 채널 상용데이터베이스(예:표준화된 원가 산정 자료, 산업 리스크 연구 정보) 프로젝트 관리 정보 시스템(PMIS) (예:일정관리 SW도구, 형상관리시스템) Page  16

프로젝트 관리 이론 조직 프로세스 자산(OPA: Organizational Process Asset) 프로세스 및 절차
표준, 정책(예: 윤리정책, 프로젝트 관리 정책, 안전 및 보건 정책) 표준화된 지침서, 작업지시, 제안서 평가 기준, 성과 측정 기준 템플릿 조직 의사소통 요구사항(의사소통 매체, 기록 보존 정책, 보안요구사항) 프로젝트 종료 지침 또는 요구사항(최종 프로젝트 감사, 프로젝트 평가, 제품확인 및 인수기준) 재무 통제절차(필요한 지출 및 지급검토, 회계코드, 표준계약조항) 공식적인 회사표준, 정책, 계획 및 절차, 변경통제 절차) 이슈 및 결함통제, 결함관리절차 공동 지식 기반 프로세스 및 제품 관련 측정 자료를 수집하고 지원하는데 사용되는 프로세스 측정 데이터베이스 프로젝트 파일(예: 범위, 일정, 원가, 품질 기준선, 성과 측정 기준선 등) 지식 기반에서 습득한 교훈과 선례 정보(예: 프로젝트 기록 및 문서, 모든 프로젝트 종료 정보) 이슈 및 결함관리 데이터베이스 모든 공식적인 회사의 표준, 정책, 절차, 프로젝트 문서 버전 및 기준선을 포함하는 형상관리 지식 기반 근로시간, 발생비용, 예산, 프로젝트 원가 초과액 등의 정보를 포함하는 회계 데이터베이스 Page  17

프로젝트 관리 이론 EEF와 OPA 비교 EEF 유형적 요소 무형적 요소 -시스템, 소프트웨어, 툴 -회사의 인프라
-보유 인력, 자원 -정부나 산업계 표준 -문화 -조직구조 -시장의 환경 -이해관계자들의 위험허용 수준 OPA 프로세스 수행실적 -표준 프로세스, 표준제품 -표준 프로젝트 라이프사이클 -템플릿, 가이드라인 -테일러링 가이드 및 기준 -프로세스 측정 데이터 -프로젝트 파일 -과거 프로젝트의 기록과 Lessons Learned -프로젝트관리, 형상관리, 이슈관리 시스템 Page  18

(Organizational Process Asset)
프로젝트 관리 이론 단위 프로젝트 관리와 OPA 관계 OPA (Organizational Process Asset) 프로젝트 종료 프로젝트 수행 실적 (원가, 일정, 자원 등) 조직 프로세스 개선 사항 (품질, 위험, 의사소통 등) 프로젝트 착수 Estimates procedure 프로젝트 관리 계획서 조직의 표준 프로세스 과거 프로젝트 수행 실적 (Historical Information) Update Guide Page  19

프로젝트 관리 이론 프로젝트 생애 주기 Page  20

프로젝트 관리 이론 이해관계자 영향력, 리스크, 불확실성 관계 Page  21

프로젝트 관리 이론 프로젝트 단계(단일) Page  22

프로젝트 관리 이론 프로젝트 단계(중첩) Page  23

프로젝트 관리 이론 프로세스 그룹의 상호관계 계획수립 착수 프로세스 프로세스 감시 및 통제 실행 프로세스 종료 프로세스
Organizational Process Asset -조직의 표준 프로세스 -Lessons Learned -유사 프로젝트 수행 실적 -조직의 표준 프로세스에 대한 변경 요청 사항 -프로젝트 수행 실적 프로젝트 차터 프로젝트 관리 계획서 승인된 작업 지시 작업 수행 결과 승인된 산출물 변경된 프로젝트 관리 계획서 Page  24

프로젝트 관리 이론 프로젝트 / 운영(Operation) 비교 구분 프로젝트 운영 기간 한시적(temporary)
지속적(ongoing) 특징 고유성(unique) 반복적(repetitive) 목표 목표달성(종료) 목표의 유지 공통점 -개별 사람(담당자)에 의해 수행된다 -자원제약을 포함한 여러 가지 제약을 받는다 -기획, 실행, 감시 및 통제 된다 -조직의 목표 또는 전략적 기획을 달성하기 위해 수행된다 Page  25

프로젝트 관리 이론 이해관계자(Stakeholder) Page  26

프로젝트 관리 이론 조직영향(Organizational Influences)
기능조직(Functional Organization) 프로젝트 전담조직(Projected Organization) 매트릭스조직(Matrix Organization) Weak Matrix Balanced Matrix Strong Matrix Page  27

프로젝트 관리 프로세스 그룹 Page  28

프로젝트 관리 프로세스 그룹 기획단계 착수단계 감시·통제단계 실행단계 종료단계 4.2 프로젝트관리계획개발 5.1 요구사항수집
5.2 범위정의 5.3 작업분류체계(WBS) 작성 6.1 활동정의 6.2 활동순서배열 6.3 활동자원산정 6.4 활동기간산정 6.5 일정개발 7.1 원가산정 7.2 예산결정 8.1 품질계획수립 9.1 인적자원계획서개발 10.2 의사소통계획수립 11.1 리스크관리계획수립 11.2 리스크식별 11.3 정성적리스크분석수행 11.4 정량적리스크분석수행 11.5 리스크대응계획수립 12.1 조달계획수립 착수단계 4.1 프로젝트 헌장개발 10.1 이해관계자 식별 감시·통제단계 4.4 프로젝트작업 감시 및 통제 4.5 통합변경통제수행 5.4 범위검증 5.5 범위통제 6.6 일정통제 7.3 원가통제 8.3 품질통제수행 10.5 성과보고 11.6 리스크감시및통제 12.3 조달관리 실행단계 4.3 프로젝트 실행 지시 및 관리 8.2 품질보증수행 9.2 프로젝트 팀 확보 9.3 프로젝트 팀 개발 9.4 프로젝트 팀 관리 10.3 정보배포 10.4 이해관계자 기대사항 관리 12.2 조달 수행 종료단계 4.6 프로젝트 또는 단계종료 12.4 조달종료 Page  29

프로젝트 관리 프로세스 그룹 착수 프로세스 그룹 기획 프로세스 그룹 실행 프로세스 그룹 감시 및 통제 프로세스 그룹
기존 프로젝트의 새 단계 또는 새 프로젝트를 정의하고, 승인을 받아 시작하는 프로세스 기획 프로세스 그룹 프로젝트의 범위를 설정하고, 목표를 구체화하고, 프로젝트의 목표를 달성하기 위한 일련의 활동을 계획하는 프로세스 실행 프로세스 그룹 프로젝트의 사양에 맞게 프로젝트 관리 계획서에 정의된 작업을 완료하는 과정에서 수행하는 프로세스 감시 및 통제 프로세스 그룹 프로젝트의 진행과 성과를 추적, 검토 및 조절하거나, 계획변경이 필요한 영역을 식별하거나, 해당 변경을 착수하는데 필요한 프로세스 종료 프로세스 그룹 전체 프로세스 그룹의 모든 활동을 종결하는 과정에서 수행되어 프로젝트나 단계를 공식적으로 종료하는 프로세스 Page  30

프로젝트 관리 프로세스 그룹 프로젝트 관리 프로세스 그룹 Page  31

프로젝트 관리 프로세스 그룹 프로젝트 상호작용(1) 프로젝트 관리 프로세스 그룹은 각각에서 생성된 산출물로 연결
Page  32

프로젝트 관리 프로세스 그룹 프로젝트 상호작용(2) Page  33

프로젝트 관리 프로세스 그룹 프로젝트 관리 프로세스 그룹과 지식영역간 관계 구분 통합 범위 시간 원가 품질 인적자원 의사소통
리스크 조달 착수 프로세스 그룹 4.1 프로젝트 헌장개발 10.1 이해관계자 식별 기획 4.2 프로젝트 관리계획 개발 5.1 요구사항 수집 5.2 범위정의 5.3 WBS작성 6.1 활동정의 6.2 활동순서 배열 6.3 활동자원 산정 6.4 활동기간 6.5 일정개발 7.1 원가산정 7.2 예산결정 8.1 품질계획 수립 9.1 인적자원 계획서 10.2 의사소통 계획수립 11.1 리스크관리 11.2 리스크식별 11.3 정성적리스크 분석수행 11.4 정량적리스크 11.5 리스크대응 12.1 조달계획 실행 4.3 프로젝트 실행 지시 및 관리 8.2 품질보증 수행 9.2 프로젝트 팀 확보 9.3 프로젝트 팀 개발 9.4 프로젝트 팀 관리 10.3 정보배포 10.4 이해관계자 기대사항관리 12.2 조달수행 감시·통제프로세스 4.4 프로젝트작업 감시 및 통제 4.5 통합변경통제 5.4 범위검증 5.5 범위통제 6.6 일정통제 7.3 원가통제 8.3 품질통제 10.5 성과보고 11.6 리스크 12.3 조달관리 종료 4.6 프로젝트 또는 단계종료 12.4 조달종료 Page  34

프로젝트 관리 프로세스 그룹 착수 프로세스 그룹 4.1 프로젝트헌장 개발
프로젝트 또는 단계를 공식적으로 승인하는 문서를 작성하고, 이해관계자의 요구와 기대치를 충족하기 위한 초기 요구사항을 문서화하는 프로세스 Page  35

프로젝트 관리 프로세스 그룹 착수 프로세스 그룹 10.1 이해관계자 식별
프로젝트의 영향을 받는 모든 사람과 혹은 조직을 식별하여 각각의 이해사항, 관여도, 프로젝트의 성공에 미치는 영향력에 관한 정보를 문서화하는 프로세스 Page  36

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 4.2 프로젝트 관리계획서 개발
모든 보조 계획을 정의, 준비 및 통합하는데 필요한 조치를 문서화하는 프로세스 프로젝트의 기획, 실행, 감시 및 통제, 종료하는 방법에 관한 기본적인 정보를 제공 Page  37

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 5.1 요구사항 수집
프로젝트 목표를 충족하기 위해 이해관계자의 요구사항을 정의하고 문서화하는 프로세스 Page  38

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 5.2 범위정의 프로젝트와 제품에 대한 상세한 설명을 개발하는 프로세스
Page  39

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 5.3 작업분류체계(WBS)작성
프로젝트 인도물과 프로젝트 작업을 관리하기 편리한 작은 요소들로 세분화하는 프로세스 Page  40

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 6.1 활동정의
프로젝트 인도물을 생성하기 위해 수행하는 특정 활동들을 식별하는 프로세스 Page  41

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 6.2 활동순서배열 프로젝트 활동 사이의 관계를 식별하여 문서화하는 프로세스
Page  42

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 6.3 활동자원산정
각 활동을 수행하는데 필요한 재료, 사람, 장비, 또는 공급품의 종류와 수량을 산정하는 프로세스 Page  43

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 6.4 활동기간산정
산정된 자원으로 개별 활동을 완료하는데 필요한 총 작업 기간 수를 대략적으로 추정하는 프로세스 Page  44

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 6.5 일정개발
활동순서, 기간, 자원 요구사항 및 일정 제약사항을 분석하여 프로젝트 일정을 수립하는 프로세스 Page  45

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 7.1 원가산정
프로젝트 활동을 완료하는데 필요한 금전적 자원의 근사치를 추정하는 프로세스 Page  46

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 7.2 예산결정
개별활동 또는 작업 패키지 별로 산정된 원가를 합산하여 승인된 원가 기준선을 설정하는 프로세스 Page  47

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 8.1 품질계획 수립
프로젝트 및 제품에 대한 품질 요구사항 또는 표준을 확인하고, 프로젝트가 실제로 어떻게 준수할지 문서화하는 프로세스 Page  48

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 9.1 인적자원계획서 개발
프로젝트 역할, 책임사항, 필요한 기량, 보고관계를 식별하여 문서화하고, 직원관리계획서를 작성하는 프로세스 Page  49

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 10.2 의사소통계획 수립
프로젝트 이해관계자의 정보 요구사항을 결정하고 의사소통방식을 정의하는 프로세스 Page  50

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 11.1 리스크관리 계획 수립
프로젝트에 대한 리스크 관리 활동을 수행하는 방법을 정의하는 프로세스 Page  51

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 11.2 리스크 식별
프로젝트에 영향을 미칠 수 있는 리스크를 식별하고 리스크 별 특성을 문서화하는 프로세스 Page  52

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 11.3 정성적 리스크 분석수행
리스크의 발생확률과 영향력을 평가하고 결합함으로써, 추가적인 분석이나 조치를 위하여 리스크의 우선순위를 지정하는 프로세스 Page  53

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 11.4 정량적 리스크 분석수행
확인된 리스크가 전체 프로젝트 목표에 미치는 영향을 수치로 분석하는 프로세스 Page  54

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 11.5 리스크 대응계획 수립
프로젝트 목표에 대한 기회를 증대시키고 부정적인 요인을 경감시킬 수 있도록 선택 가능한 대안과 조치를 개발 하는 프로세스 Page  55

프로젝트 관리 프로세스 그룹 기획 프로세스 그룹 12.1 조달계획 수립
프로젝트 구매 결정 사항을 문서화하고, 구매 방식을 구체화하고, 잠재적인 판매자를 식별하는 프로세스 Page  56

프로젝트 관리 프로세스 그룹 실행 프로세스 그룹 4.3 프로젝트 실행지시 및 관리
프로젝트의 목표를 달성하기 위해 프로젝트 관리 계획서에 정의된 작업을 수행하는 프로세스 Page  57

프로젝트 관리 프로세스 그룹 실행 프로세스 그룹 8.2 품질보증 수행
품질의 요구사항과 품질통제의 측정결과를 감시하면서, 해당하는 품질표준과 운영상 정의를 사용하고 있는지 확인하는 프로세스 Page  58

프로젝트 관리 프로세스 그룹 실행 프로세스 그룹 9.2 프로젝트 팀 확보
가용 인적자원을 확인하여 프로젝트 배정을 완료하는데 필요한 팀을 구성하는 프로세스 Page  59

프로젝트 관리 프로세스 그룹 실행 프로세스 그룹 9.3 프로젝트 팀 개발
프로젝트 성과를 향상시키기 위해 팀원들의 역량과 팀원간 협력, 전반적인 팀 분위기를 개선하는 프로세스 Page  60

프로젝트 관리 프로세스 그룹 실행 프로세스 그룹 9.4 프로젝트 팀 관리
프로젝트 성과를 최적화하기 위하여 팀원의 성과를 추적하고, 피드백을 제공하여, 이슈를 해결하고, 변경을 관리하는 프로세스 Page  61

프로젝트 관리 프로세스 그룹 실행 프로세스 그룹 10.3 정보배포 프로젝트 이해관계자에게 계획된 관련정보를 제공하는 프로세스
Page  62

프로젝트 관리 프로세스 그룹 실행 프로세스 그룹 10.4 이해관계자 기대사항 관리
이해관계자들의 의사소통 및 협력을 통해 이해관계자의 요구사항을 충족시키고 발생하는 이슈를 처리하는 프로세스 Page  63

프로젝트 관리 프로세스 그룹 실행 프로세스 그룹 12.2 조달수행
대상 판매자를 모집하고, 판매자를 선정하고, 계약을 체결하는 프로세스 Page  64

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 4.4 프로젝트 작업 감시 및 통제
프로젝트 관리 계획서에 정의된 성과 목표를 달성하기 위해 프로젝트 진행을 추적하고, 검토하고, 조정하는 프로세스 Page  65

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 4.5 통합 변경 통제 수행
모든 변경 요청을 검토하고, 변경사항을 승인하고, 인도물, 조직 프로세스 자산, 프로젝트 문서, 프로젝트 관리 계획서에 대한 변경을 관리하는 프로세스 Page  66

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 5.4 범위검증 완료된 프로젝트 인도물의 인수를 공식화하는 프로세스
Page  67

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 5.5 범위통제
프로젝트 및 제품의 범위를 감시하고 범위 기준선에 대한 변경을 관리하는 프로세스 Page  68

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 6.6 일정통제
프로젝트의 상태를 감시하여 프로젝트의 진행을 업데이트하고 일정 기준선에 대한 변경을 관리하는 프로세스 일정 Page  69

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 7.3 원가통제
프로젝트의 상태를 감시하여 프로젝트 예산을 업데이트하고 원가 기준선에 대한 변경을 관리하는 프로세스 Page  70

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 8.3 품질통제 수행
품질보증 활동의 실행 결과를 감시하고 기록하면서 성과를 평가하고 필요한 변경 권고안을 제시하는 프로세스 Page  71

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 10.5 성과보고
상태보고, 진행측정, 예측치 등의 성과 정보를 수집하고 배포하는 프로세스 Page  72

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 11.6 리스크 감시 및 통제
프로젝트 전반의 리스크 대응 계획을 구현하고, 식별된 리스크를 추적하고, 잔존 리스크를 감시하고, 새로운 리스크를 식별하고, 리스크 처리를 평가하는 프로세스 Page  73

프로젝트 관리 프로세스 그룹 감시 및 통제 프로세스 그룹 12.3 조달관리
조달관계를 관리하고, 계약의 이행을 감시하고, 필요한 사항을 변경 및 수정하는 프로세스 Page  74

프로젝트 관리 프로세스 그룹 종료 프로세스 그룹 4.6 프로젝트 또는 단계종료
프로젝트나 단계를 공식적으로 완료하기 위해 전체 프로젝트 관리 프로세스 그룹에 속한 모든 활동을 종결하는 프로세스 Page  75

프로젝트 관리 프로세스 그룹 종료 프로세스 그룹 12.4 조달종료 각 프로젝트 조달을 완료하는 프로세스 Page  76

프로젝트 관리 지식 영역 Page  77

프로젝트 관리 지식 영역 4. 프로젝트 통합관리 개념 세부 활동
프로젝트 관리 프로세스 그룹에 속하는 다양한 프로세스와 프로젝트관리 활동들을 식별, 정의, 결합 및 조정하는데 필요한 프로세스 세부 활동 4.1 프로젝트 헌장 개발 4.2 프로젝트 관리 계획서 개발 4.3 프로젝트 실행 지시 및 개발 4.4 프로젝트 작업 감시 및 통제 4.5 통합 변경 통제 수행 4.6 프로젝트 또는 단계 종료 4.1 프로젝트헌장개발 착수 프로세스 4.2 프로젝트관리계획서 개발 계획수립 프로세스 4.3 프로젝트실행지시 및 관리 실행 프로세스 4.4 프로젝트작업감시 및 통제 감시 및 통제 프로세스 4.5 통합변경통제수행 4.6 프로젝트 또는 단계종료 종료 프로세스 프로젝트 관리 계획서 승인된 산출물 시정조치 승인 작업 결과 프로젝트 헌장 계획 변경 Page  78

프로젝트 관리 지식 영역 5. 프로젝트 범위관리 개념 세부 활동
프로젝트를 성공적으로 완료하는데 반드시 필요한 작업만을 빠짐없이 프로젝트에 포함시키기 위해 필요한 프로세스 프로젝트 업무 범위 설정 및 승인을 받아 프로젝트 목표에 맞도록 관리하는 기능 세부 활동 5.1 요구사항 수집 5.2 범위 정의 5.3 작업분류체계 (WBS) 작성 5.4 범위 검증 5.5 범위 통제 ※ WBS : Work Breakdown Structure Page  79

프로젝트 관리 지식 영역 6. 프로젝트 시간관리 개념 세부 활동 프로젝트를 적시에 완료하도록 관리하는데 필요한 프로세스
프로젝트를 단위작업으로 분할한 후 각 단위 작업별 일정을 수립하고 관리하는 기능 세부 활동 6.1 활동 정의 6.2 활동 순서 배열 6.3 활동 자원 산정 6.4 활동 기간 산정 6.5 일정 개발 6.6 일정 통제 Page  80

프로젝트 관리 지식 영역 7. 프로젝트 원가관리 개념 세부 활동
승인된 예산 범위 내에서 프로젝트를 완료할 수 있도록 원가를 산정하고, 예산을 책정하고, 원가를 통제하는 프로세스 세부 활동 7.1 원가 산정 7.2 예산 결정 7.3 원가 통제 Page  81

프로젝트 관리 지식 영역 8. 프로젝트 품질관리 개념 세부 활동
프로젝트가 요구사항을 충족할 수 있도록 품질정책, 품질목표, 품질 책임사항을 결정하는 프로세스 세부 활동 8.1 품질 계획 수립 8.2 품질 보증 수행 8.3 품질 통제 수행 Page  82

프로젝트 관리 지식 영역 9. 프로젝트 인적자원관리 개념 세부 활동
프로젝트 팀을 구성하고, 관리하고, 프로젝트 팀을 이끄는 프로세스 프로젝트 수행요원들의 활동을 조직하고 조정하는 기능 세부 활동 9.1 인적 자원 계획서 개발 9.2 프로젝트 팀 확보 9.3 프로젝트 팀 개발 9.4 프로젝트 팀 관리 Page  83

프로젝트 관리 지식 영역 10. 프로젝트 의사소통관리 개념 세부 활동
프로젝트 정보의 생성, 수집, 배포, 저장, 검색 그리고 최종처리가 적시에 적절히 수행되도록 하기 위해 필요한 프로세스 프로젝트의 이해관게자간에 효율적인 정보전달체계를 계획, 조직, 관리하는 기능 세부 활동 10.1 이해관계자 식별 10.2 의사소통계획 수립 10.3 정보배포 10.4 이해관계자 기대사항 관리 10.5 성과보고 Page  84

프로젝트 관리 지식 영역 11. 프로젝트 리스크관리 개념 세부 활동
프로젝트에 대한 리스크의 관리 기획, 식별, 분석, 대응 기획, 감시 및 통제를 수행하는 프로세스 프로젝트 수행과정에서 일어날 수 있는 리스크요인을 발견하고 분석하여 대책을 수립하는 기능 세부 활동 11.1 리스크관리 계획 수립 11.2 리스크 식별 11.3 정성적 리스크 분석 수행 11.4 정량적 리스트 분석 수행 11.5 리스크 대응 계획 수립 11.6 리스크 감시 및 통제 ※ 리스크관리의 목표 : 프로젝트에서 긍정적인 사건의 확률 및 영향은 증가시키고 부정적인 사건의 확률 및 영향은 감소시키는 것 Page  85

프로젝트 관리 지식 영역 12. 프로젝트 조달관리 개념 세부 활동
작업 수행에 필요한 제품, 서비스 또는 결과물을 프로젝트 팀 외부로부터 구매하거나 획득하기 위해 필요한 프로세스 프로젝트 수행에 필요한 각종 자원(인력, 장비, 자재 등)을 확보하고 관리 세부 활동 12.1 조달 계획수립 12.2 조달 수행 12.3 조달 관리 12.4 조달 종료 Page  86

실습 #1 관리 프로세스 그룹과 지식영역 관계 5개 프로젝트 관리 프로세스 그룹과 9개 지식영역간 관계(30분)
Hand-out Page  87

4. 프로젝트 통합관리 4.1 프로젝트 헌장 개발 4.2 프로젝트 관리 계획서 개발 4.3 프로젝트 실행 지시 및 관리 4.4 프로젝트 작업 감시 및 통제 4.5 통합 변경 통제 수행 4.6 프로젝트 또는 단계 종료 Page  88

4.1 프로젝트 헌장 개발 프로젝트 또는 단계를 공식적으로 승인하는 문서를 작성하고, 이해관계자의 요구와 기대치를 충족하기 위한 초기 요구사항을 문서화하는 프로세스 프로젝트 외부의 경영층이 승인해야 한다 프로젝트 스폰서 혹은 프로젝트 착수자 프로젝트에 대한 개략적인 개요, 목적, 일정, 예산, 조직, 제약조건, 이해당사자 분석 등을 포함하여야 한다 범위기술서(Project Scope Statement)와 프로젝트 관리 계획서에서 내용이 상세화된다 프로젝트 관리자에게 조직의 인력과 자원을 사용할 권한을 부여한다 ※ 프로젝트 차터( Project Charter) : 프로젝트 착수를 공식화 하는 문서 Page  89

4.1 프로젝트 헌장 개발 비즈니스 케이스 (프로젝트 승인 요인) 시장 수요 조직의 요구 고객 요청 기술 진보 법률 규제
예: 자동차 회사에서 휘발유 부족 사태에 대응하여 연료 절약형 자동차를 생산하는 프로젝트 승인 조직의 요구 예: 교육 관련 회사에서 수익 증대를 목적으로 교육 과정을 신설하는 프로젝트 승인 고객 요청 예: 전기 회사에서 새 산업 단지를 지원할 발전소를 신축하는 프로젝트 승인 기술 진보 예: 전자 제품 회사에서 컴퓨터 메모리 및 전자 기술 발전 이후 더 작고 빠르고 값싼 랩탑 컴퓨터를 개발하는 새 프로젝트 승인 법률 규제 예: 페인트 제조업체에서 독성 물질을 취급하기 위한 지침을 마련하는 프로젝트 승인 생태학적 영향 예: 회사에서 환경에 유해한 영향을 줄이는 프로젝트 수행 Page  90

4.1 프로젝트 헌장 개발 프로젝트 헌장에 포함될 내용 프로젝트의 목적과 정당성 고객, 스폰서 등 이해관계자들의 요구사항
측정 가능한 프로젝트 목표 및 관련된 성공 기준 상위 수준 프로젝트 설명 및 요구사항 상위 수준 리스크 마일스톤 요약 일정 개략적 예산 요약 프로젝트 승인 요구사항 (프로젝트 성공의 구성 요건, 프로젝트 성공에 대한 결정권자, 프로젝트 서명자) 선임된 프로젝트관리자, 책임사항 및 권한 수준 프로젝트 헌장을 승인하는 스폰서 또는 기타 주체의 이름과 권한 조직과 참여 역할 Page  91

4.2 프로젝트 관리 계획서 개발 모든 보조 계획을 정의, 준비, 통합 및 조정하는데 필요한 조치를 문서화하는 프로세스(프로젝트의 실행, 감시 및 통제, 종료 방법 정의) 프로젝트 관리 계획서에 포함되어야 할 내용 각 영역별 계획(범위, 일정, 원가, 품질목표, 인력계획, 의사소통방법, 위험관리계획, 조달관리) 각 영역별 프로세스의 실행수준, 기법 프로젝트 수행방법론 프로젝트 수행을 위한 각종 도구 변경통제 및 형상관리 방안 성과측정 방법 및 성과 측정 기준관리 Page  92

4.2 프로젝트 관리 계획서 개발 프로젝트관리정보시스템(PMIS) 형상관리 시스템 변경통제 시스템
변경 제안서 제출, 제출된 변경안 검토 및 승인, 변경 승인 레벨정의, 승인된 변경 확인 방법 제공 등의 프로세스들로 구성 대부분의 응용 분야에서 형상관리 시스템에 변경통제 시스템이 포함됨 제품 구성요소의 기능적, 물리적 특성을 식별하여 문서화 그와 같은 특성에 대한 모든 변경을 통제 각 변경과 구현 상태를 기록 및 보고 제품이나 구성요소의 감사를 지원하여 요구사항 준수 여부 검증 변경통제 시스템 프로젝트 인도물 및 문서의 통제, 변경 및 승인 방법을 정의하는 공식 문서화된 절차의 모음 형상관리 시스템에 속한 하부시스템 Page  93

4.3 프로젝트실행 지시 및 관리 프로젝트의 목표를 달성하기 위해 프로젝트 관리 계획서에 정의된 작업을 수행하는 프로세스
프로젝트의 목표를 달성하기 위해 프로젝트 관리 계획서에 정의된 작업을 수행하는 프로세스 주요 수행 활동 프로젝트 요구사항을 완수하는데 필요한 활동 수행 프로젝트 인도물 생성 / 계획된 방법과 표준 구현 프로젝트에 배정된 팀원 배치, 교육 및 관리 자재, 도구, 장비, 설비 등의 자원을 확보, 관리 및 활용 프로젝트 팀의 내부 및 외부적 프로젝트 의사소통 채널 구축 및 관리 원가, 일정, 기술, 품질 측면에서 진행률 및 상태와 같은 프로젝트 자료를 생성하여 예측이 가능하도록 지원 변경요청 발생, 승인된 변경 내용을 프로젝트의 범위, 계획 및 환경에 맞춰 조정 리스크 관리 및 리스크 대응 활동 구현 / 판매자 와 공급업체 관리 습득한 교훈 수집, 문서화 및 승인된 프로세스 개선 활동 구현 Page  94

4.4 프로젝트작업 감시 및 통제 프로젝트 관리 계획서에 정의된 성과 목표를 달성하기 위해 프로젝트 진행을 추적하고, 검토하고, 조정하는 프로세스 주요 수행 활동 프로젝트 관리 계획서와 대비한 실제 프로젝트 성과 비교 시정 또는 예방 초지의 필요성을 결정하기 위해 성과를 평가하고, 필요에 따라 시정 또는 예방 조치 권고 추가 리스크의 정확한 식별, 리스크의 상태보고, 적절한 리스크 대응 계획이 지속적으로 실행되도록 추가 리스크 식별, 기존 프로젝트 리스크 분석, 추적 및 감시 프로젝트 전반에 걸쳐 프로젝트 제품 및 관련 문서에 대한 정확하고 시기 적절한 정보 기반 유지 상태 보고, 진행률 측정 및 예측 활동을 지원하는 정보 제공 현재 원가 및 일정 정보를 갱신할 예측자료 제공 승인된 변경이 발생할 때 변경사항의 구현 감시 Page  95

4.5 통합 변경 통제 수행 인도물, 조직프로세스 자산, 프로젝트 문서, 프로젝트 관리 계획서에 대한 모든 변경 요청을 검토하고, 변경사항을 승인 하며, 변경을 관리하는 프로세스 주요 수행 활동 통합변경통제에서 제외되는 요인에 영향을 주어 오직 승인된 변경만이 구현되도록 조치 결정 지연이 시간 또는 변경 타당성에 부정적인 영향을 미칠 수 있으므로 중요한 변경 요청을 즉시 검토 및 분석하여 승인 승인된 변경관리 프로젝트 관리 계획서와 프로젝트 문서의 통합을 위해 오직 승인된 변경만을 인정함으로써 기준선의 완전성 유지관리 권고 받은 모든 시정 및 예방 조치를 검토한 후 승인 또는 거부 전체 프로젝트에 걸쳐 변경사항 조정 (예 : 제안된 일정 변경은 대개 원가, 리스크, 품질, 팀원배정에 영향을 미침) 완료된 변경 요청의 영향을 문서화하는 활동 Page  96

변경통제 위원회(CCB : Change Control Board)
각 관리 영역에서 발생하는 변경 요청사항은 프로젝트 전체 관점에서 사전에 정의된 변경통제 절차에 따라 “승인” 또는 “기각”해야 한다 변경사항을 식별하고 프로젝트 전체 관점에서 변경의 영향력이나 효과를 평가하고 검증하는 프로세스 변경사항의 유형별 의사결정 책임자 또는 변경통제 위원회 형상의 식별, 기록, 감사를 위한 프로세스 승인된 변경사항에 대하여 주요 이해관계자들의 의사소통 하는 프로세스 Page  97

통합관리 영역의 계획, 수행, 통제 프로세스 체계 Planning Process Group 프로젝트 관리 계획 개발
프로젝트 실행 지시 및 관리 프로젝트 작업 감시 및 통제 통합 변경 통제 Planning Process Group Executing Process Group Monitor and Controlling Process Group 프로젝트 관리 계획서 승인된 변경요청 (Approved *) 변경요청 (Recommended *) (계획변경) 업무수행실적 (Work Performance Information) Page  98

4.6 프로젝트 또는 단계종료 프로젝트나 단계를 공식적으로 완료하기 위해 전체 프로젝트 관리 프로세스 그룹에 속한 모든 활동을 종결하는 프로세스 주요 수행 활동 프로젝트 또는 단계종료의 종료 기준을 충족하는데 필요한 조치 및 활동 프로젝트의 제품, 서비스, 결과물을 다음단계 또는 생산 및 운영으로 인계하는데 필요한 조치 및 활동 프로젝트 또는 단계 기록을 수집하고 프로젝트 성공 또는 실패를 평가하고, 습득한 교훈을 수집하며, 향후 조직에서 활용하기 위해 프로젝트 정보를 보존하는데 필요한 활동 Page  99

4.6 프로젝트 또는 단계종료 행정종료 계약종료 프로젝트 결과 및 기록의 수집 프로젝트의 성공과 실패에 대한 분석
Lessons Learned 정리 향후 프로젝트를 위한 기록 및 정리 계약종료 프로젝트와 연관된 계약의 종료 Product Verification 계약과 관련한 기록에 대한 분류화 및 정리 Page  100

4.6 프로젝트 또는 단계종료 종료 프로세스 단계 1 단계 2 단계 N 운영 (Operation) 검증된 산출물 최종 산출물
결과 프로젝트 종료 Page  101

4.6 프로젝트 또는 단계종료 일반적 프로젝트의 종료순서 프로젝트 종료에 대한 공식 승인 획득
프로젝트 종료에 대한 고객의 공식 승인은 종료 프로세스에서 가장 중요하면서도 가장 먼저 수행되어야 하는 활동이다 Lessons Learned 정리 프로젝트를 종료하기 전에 프로젝트를 수행하면서 경험하였던 각종 교훈을 전체 팀원들과 함께 검토하고 정리하여야 한다 프로젝트 Archives의 정리 프로젝트 각종 산출물을 분류, 정리하여 향후 유사 프로젝트를 수행할 때 내용을 참고할 수 있어야 한다 프로젝트 팀원의 발령 해제 이상의 모든 작업은 프로젝트 팀원과 함께 수행하여야 한다. 프로젝트 팀원의 발령 해제는 프로젝트 종료 시 가장 나중에 실시해야 하는 프로세스이다 Page  102

실습 #2 프로젝트 활동과 통합관리 프로세스의 매핑
통합관리 영역의 수행 활동 해당 프로세스 찾기(30분) Hand-out Page  103

5. 프로젝트 범위관리 5.1 요구사항 수집 5.2 범위 정의 5.3 작업분류체계(WBS) 작성 5.4 범위 검증 5.5 범위 통제 Page  104

5.1 요구사항 수집 프로젝트 목표를 충족하기 위해 이해관계자의 요구사항을 정의하고 문서화하는 프로세스
프로젝트 목표를 충족하기 위해 이해관계자의 요구사항을 정의하고 문서화하는 프로세스 프로젝트 단계에 따른 요구 공학 개념 분석 설계 개발 시험 구축 요구사항 변경관리 요구사항 개발 요구사항 추적성 관리 SDLC 요구공학 도출 명세 검증 Page  105

5.1 요구사항 수집 도구 및 기법 인터뷰 워크샵 브레인스토밍 관찰 설문지 및 설문조사 프로토타입
이해관계자와 직접 대화를 통해 정보를 구하는 공식적 또는 비공식적 정보 수집 방법 워크샵 복합 기능 이해관계자가 모여서 제품의 요구사항을 정의하는 집중 세션 브레인스토밍 관련 인원이 대부분 참여하여 관심 있는 영역에 대해 창조적인 아이디어를 도출하는 기법 관찰 개개인이 각자의 환경에서 담당업무, 태스크 또는 프로세스를 수행하는 방법을 직접적으로 관찰하는 방법 설문지 및 설문조사 수많은 응답자로부터 신속하게 정보를 수집하도록 고안된 문항들로 구성된 양식 프로토타입 제품의 실제 제작에 앞서 예상 제품의 작동 모형을 제공하여 요구사항에 대한 조기 피드백을 확보하는 방법 Page  106

5.1 요구사항 수집 도구 및 기법 자료분석 역공학 델파이 기법
업무와 관련 있는 각종 자료와 문서를 분석하여 정보를 추출하는 방법 역공학 소스로부터 역으로 분석/설계 단계의 요구사항을 추출하는 방법 델파이 기법 선정된 전문가 그룹이 설문지에 응답하고 각 요구사항 수집 세션에서 나온 응답에 대한 피드백을 제공하는 방법(응답은 사회자만 볼 수 있도록 하여 익명성 보장) Page  107

5.1 요구사항 수집 요구사항의 종류 기능적 요구사항 비기능적 요구사항 기능 -시스템이 무엇을 하는가?
-시스템이 언제 그 일을 하는가? 자료 -입/출력이 무엇이며 어떤 형태를 갖는가? 얼마나 자주 자료를 주고 받는가? -자료가 얼마나 정확하여야 하는가? 시스템에 유입되는 자료의 양은? 인터페이스 -다른 시스템에서 유입, 유출되는 입력은 무엇인가? -자료 전달에 사용되는 특정한 미디어가 있는가? 사용자 -누가 시스템을 사용할 것인가? 사용자가 여러 그룹인가? 자원 -유지보수에 필요한 자원, 인력은 무엇인가? -개발자가 갖추어야 할 기술은 무엇인가? 어떤 하드웨어를 사용할 것인가? -시스템이 차지하는 공간은? 성능 -시스템의 속도, 반응 시간, 처리율 보안 -자료와 시스템에 대한 접근이 통제되어야 하는가? 시스템의 백업 기간 및 책임자, 재난을 대비한 방지책 품질 -품질 특성에 대한 요구, 시스템 가동 평균 시간, 유지보수 용이성 Page  108

5.1 요구사항 수집 요구사항 문서 구성요소 현재 상황에서 제한사항과 프로젝트의 수행 사유를 설명하는 비즈니스 요구 또는 포착할 기회 추적 지표로 활용할 비즈니스 및 프로젝트 목표 요구사항 목록, 모델 또는 두 가지 모두에 적절히 문서화할 수 있는 비즈니스 프로세스, 정보, 제품과의 상호작용으로 기술되는 기능적 요구사항 서비스 수준, 성과, 안전성, 보안, 지원 가능성, 보유/제거 등과 같은 비기능적 요구사항 품질 요구사항 인수 기준 조직의 운영 원칙을 밝히는 비즈니스 규칙 콜센터, 영업부서, 기술 그룹 등의 다른 조직 영역에 미치는 영향력 수행 조직 내부 또는 외부의 다른 주체에 미치는 영향력 지원 및 교육 요구사항 요구사항의 가정과 제약 Page  109

5.1 요구사항 수집 요구사항 관리 계획서에 포함될 사항 요구사항 활동을 계획, 추적 및 보고하는 방법
제품, 서비스 또는 결과 요구사항에 대한 변경을 착수하는 방법, 영향력을 분석하는 방법, 변경과 영향력을 추적하고 탐지하고 보고하는 방법 해당 변경을 승인하는데 필요한 권한 수준 등과 같은 형상관리 수준들 요구사항 우선순위 지정 프로세스 사용할 제품 지표와 해당 지표를 사용하는 이유 추적 구조, 추적 매트릭스에 포착할 요구사항 속성과 추적할 기타 프로젝트 문서 요구사항 Page  110

5.1 요구사항 수집 요구사항 추적 매트릭스 비즈니스 요구, 기회, 목표 및 목적에 대한 요구사항
프로젝트 목표에 대한 요구사항 프로젝트 범위, WBS 산출물에 대한 요구사항 제품 설계에 대한 요구사항 제품 개발에 대한 요구사항 테스트 전략 및 테스트 시나리오에 대한 요구사항 상위 수준부터 상세한 수준까지의 모든 요구사항 Page  111

실습 #3. 기능 요구사항과 비기능 요구사항 식별 요구사항
여러지방에 브랜드를 보유하고 있는 콘도회사의 객실 예약 시스템을 구축하고자 한다. 객실 예약 시스템은 담당 직원에 의해 운용되고, 객실을 검색하고 예약할 수 있으며 예약을 취소할 수 있어야 한다. 객실 예약 시스템은 사용이 용이하고, 기존의 시스템을 이용하여 구축할 수 있어야 한다. 위의 요구사항에서 기능 요구사항과 비기능 요구사항을 식별하세요. (15분) Page  112

5.2 범위정의 프로젝트와 제품에 대한 상세한 범위를 개발하는 프로세스 프로젝트 범위 기술서 구성요소 제품 범위 명세서
프로젝트헌장과 요구사항 문서에 설명된 제품, 서비스 또는 결과의 특성을 점진적 구체화 제품 인수 기준 완료된 제품, 서비스 또는 결과의 인수 프로세스와 기준을 정의 프로젝트 제외사항 프로젝트에서 제외되는 대상 식별 프로젝트 제약사항 프로젝트 범위와 연관되어 팀의 옵션을 제한하는 특정 프로젝트 제약사항을 열거하여 설명 프로젝트 가정사항 프로젝트 범위와 연관된 특정 프로젝트 가정을 열거하여 설명하고 그러한 가정이 오류로 판명되는 경우 잠재적 영향력에 대한 설명을 추가 제품 인수기준 완성된 제품의 인수 프로세스와 인수 기준을 정의 Page  113

5.3 작업분류체계(WBS) 작성 작업분류체계(WBS) 정의 구성항목
관리와 통제를 목적으로 프로젝트를 근원적인 요소로 나누는 계층적 분류 구조 프로젝트 생명주기에 걸쳐 모든 산출물들을 위한 기준을 제공 목표를 단계, 활동, 작업 등 계층적으로 분류하는 것 구성항목 구성항목 구성항목별 개념 및 상세 내용 Work Package - WBS의 최하위 단위 통상 Work Package는 80시간(2주) 내외의 기간을 가지도록 분할 . 작업기간을 너무 길게 할당하면 작업 진척도를 평가하기 어려움 . 계획수립 시점에서 더 이상 상세화할 수 없으면 추후 분할 : planning package Code of Account - WBS의 고유한 ID(넘버링 체계) WBS Dictionary - Work Package의 상세한 내용 기술한 것 - 업무내용, 세부 액티비티, 소요자원, 일정, 책임자, 예산 등을 기술 Control Account - 조직의 각 단위에 부여된 WBS의 단위(통제단위) WBS 분할 적정성 판단기준 - 각 work Package별로 원가와 일정을 추정할 수 있는 수준까지 분할 Page  114

5.3 작업분류체계(WBS) 작성 WBS 작성시 주의사항
고객이 요구하는 기능(최종 산출물)을 제공하기 위하여 필요한 중간 산출물을 계층적으로 정의한 문서 WBS는 일정관리 도구(Scheduling toll)가 아니다 WBS는 프로젝트 내부 및 고객과의 의사소통 수단으로 사용된다 WBS는 프로젝트 팀이 만든다 OBS에 WBS를 매핑 시켰을 때(어떤 조직이 어떤 Work Package를 수행할 것인가를 매핑) OBS와 WBS가 상호 교차하는 부문을 Control Account라고 한다 ※ OBS(Organizational Breakdown Structure) : 조직도 BOM(Bill Of Material) : 제품을 생산하기 위한 부품 체계 RBS(Risk Breakdown Structure) : 프로젝트에서 식별한 위험분류 체계 RBS(Resource Breakdown Structure) : 자원의 종류를 계층적으로 분류한 체계 Page  115

5.3 작업분류체계(WBS) 작성 WBS 와 다른 프로세스의 관계 WBS ① ② ③ ④ ⑤ ⑥ ⑦ 아웃소싱 결정 진척보고 방법
리스크식별 조직구성 원가추정 액티비티 정의 자원결정 ① ② ③ ④ ⑤ ⑥ ⑦ ① WBS는 ‘what’을 정의하는 것이라면 액티비티 정의는 ‘how’를 정의하는 것 (Time) ② WBS가 결정되어야 어떤 자원이 얼마만큼 필요한지를 결정 (Time) ③ WBS가 결정되면 업무수행에 필요한 원가를 추정 (Cost) ④ WBS가 결정되면 누가 무엇을 할 것인가를 결정 (Human Resource) ⑤ WBS가 세부적으로 결정되면 체계적인 리스크 식별을 위한 체크리스트로 활용 가능 (Risk) ⑥ WBS를 결정하고 나면 아웃소싱을 할 부분이 있는지 결정 (Procurement) ⑦ WBS 체계에 따라 정기적인 성과보고서의 형태를 정의할 수 있다 (Communication) ※ Page  116

5.3 작업분류체계(WBS) 작성 WBS (Work Package : 예) Rolling Wave Planning :
프로젝트 착수 시점에서 정보가 부족하여 더 이상 분할하기 힘들 경우 프로젝트를 진행하면서 상세한 분할 진행 Page  117

5.4 범위 검증 완료된 프로젝트 인도물의 인수를 공식화하는 프로세스 도구 및 기법 검사(Inspection)
작업과 인도물이 요구사항과 제품인수 기준을 충족하는지 판별하기 위하여 수행하는 측정, 검수, 확인 등의 활동(Walkthroughs) 다소 부정확하더라도 검수를 받는 경우 -납기가 중요한 경우 -중요하지 않는 부분이 부정확한 경우 중요한 부분의 결함이 있는 경우 업무범위의 제품, 서비스를 검수하는 경우 추가적인 변경 요청사항이 있는 경우 Incorrect Correct Accept Reject Page  118

5.5 범위 통제 프로젝트 및 제품 범위의 상태를 감시하고 범위 기준선에 대한 변경을 관리하는 프로세스(통합변경통제)
프로젝트 및 제품 범위의 상태를 감시하고 범위 기준선에 대한 변경을 관리하는 프로세스(통합변경통제) 도구 및 기법 차이분석 프로젝트 성과 측정치를 사용하여 초기 범위 기준선으로부터 차이를 평가 ※ 기준선(Baseline) : CCB의 승인 필수 ※ 변경위원회(CCB : Change Control Board) ※ Scope Creep : 통제되지 않는 변경, 업무 범위의 잦은 변경 Page  119

실습 #4. WBS 작성 일정 2개월(5.1~6.30), 12MM 투입 예정인 응용시스템 개발 프로젝트의
Page  120

6. 프로젝트 시간관리 6.1 활동 정의 6.2 활동 순서 배열 6.3 활동 자원 산정 6.4 활동 기간 산정 6.5 일정 개발 6.6 일정 통제 Page  121

일반적 일정계획수립 개발 일정 프로젝트 상황 -규모, 복잡도, 기술 등 수행 공정 -개발 방법론(라이프사이클) 라이프사이클
-단계별 기간 비율 결정 Top Down 기간 배분 -단계  액티비티 개발 일정 제약조건 -계약기간(종료일) -프로젝트 관리자에 따라 달라질 수 있음 (3:7, 4:6, 5:5, 6:4 기간 비율 결정) -하위 공정별 결정 -기간이 촉박할수록 분석/설계단계의 기간을 짧게 조정 Page  122

6.1 활동정의 프로젝트 인도물을 생성하기 위해 수행하는 구체적인 활동들을 식별하는 프로세스 도구 및 기법
프로젝트 인도물을 생성하기 위해 수행하는 구체적인 활동들을 식별하는 프로세스 도구 및 기법 분할(Decomposition) 프로젝트 작업 패키지를 활동이라고 하는 관리하기 간편한 작은 요소로 세분화하는 작업 연동기획(Rolling Wave Planning) 가까운 시기에 완료할 작업은 상세히 계획하고 장기적인 작업은 작업분류체계(WBS)의 상위수준에서 계획하는 방식(프로젝트를 수행하면서 상세화) 템플릿(Templates) 표준활동목록 또는 과거 프로젝트에 사용한 활동목록의 일부를 흔히 새 프로젝트의 템플릿으로 활용 전문가 판단(Expert Judgment) 프로젝트 팀원 또는 상세한 프로젝트 범위기술서, 작업분류체계(WBS), 프로젝트 일정을 개발하는데 경험과 지식이 풍부한 전문가 활동 Page  123

WBS vs. Activity 구분 WBS Activity 공통점 정의의 관점 산출물 관점에서 정의 액티비티 관점에서 정의
분할방법과 로직은 동일 WBS, Activity 모두 추정, 감시, 통제의 목적으로 활용 분할대상 (Input) Project Scope Statement WBS(Work Package) 분할결과 (Output) Work Package Schedule Activity 세부내용 WBS Dictionary Activity Attribute 실제 현실 “WBS 작성”과 “Activity 정의”를 별개의 프로세스로 진행하지 않고 프로젝트를 수행하면서 세부 Activity를 추가하고 보완하는 하나의 프로세스로 수행 Page  124

6.2 활동순서배열 프로젝트 활동 사이의 관계를 식별하여 문서화하는 프로세스로 논리관계를 사용하여 활동을 순서대로 배열
프로젝트 활동 사이의 관계를 식별하여 문서화하는 프로세스로 논리관계를 사용하여 활동을 순서대로 배열 도구 및 기법 선후행도형법(PDM: Precedence Diagramming Method) ‘노드’라고 하는 네모상자나 직사각형을 사용하여 여러 가지 활동을 표시하고 노드 사이를 화살표로 활동간 의존성을 표시는 프로젝트 일정네트워크 다이어그램 Page  125

6.2 활동순서배열 PDM에서 사용하는 네가지 유형의 의존관계 FS(Finish to Start) Dependency
가장 일반적으로 많이 사용하며, 선행작업을 완료하여야 후행작업을 착수할 수 있는 관계 FF(Finish to Finish) Dependency 선행작업을 완료하여야 후행작업을 종료할 수 있는 관계 SS(Start to Start) Dependency 선행작업을 착수하여야 후행작업을 착수할 수 있는 관계 SF(Start to Finish) Dependency 선행작업을 착수하여야 후행작업을 종료할 수 있는 관계 선행작업 후행작업 선행작업 후행작업 선행작업 후행작업 선행작업 후행작업 Page  126

6.2 활동순서배열 의존관계 결정 세가지 유형 의무적 의존관계(Mandatory dependency)
작업의 본질상 임의로 정할 수 없고 미리 정해진 선후관계를 의미(Hard logic) (예 : 기초공사가 완료되기 전까지 구조물을 올릴 수 없다) 임의적 의존관계(Discretionary dependency) 프로젝트 팀에서 임의로 정할 수 있는 작업관계(Soft logic, Preferred logic) (Fast tracking, 프로젝트 상황, 유사 프로젝트 사례, 우수 사례를 고려하여 신중한 결정 필요) 외부적 의존관계(External dependency) 프로젝트 업무범위 외의 액티비티와 프로젝트 액티비티 사이의 관계 (예 : 정부의 사업 승인이 있어야 시스템을 Open할 수 있다) Page  127

6.2 활동순서배열 도구 및 기법 화살도형법(ADM: Arrow Diagramming Method)
화살표를 사용하여 활동을 나타내고 노드에서 활동들을 연결하여 상호의존 관계를 표시하는 프로젝트 일정네트워크 다이어그램 Page  128

(Precedence Diagramming Method) (Arrow Diagramming Method)
6.2 활동순서배열 PDM / ADM 비교 구분 PDM (Precedence Diagramming Method) ADM (Arrow Diagramming Method) 특징 -액티비티를 노드 위에 표현함 -AON(Activity On Node)라고도 함 -액티비티를 화살표 위에 표현함 -AOA(Activity On Arrow)라고도 함 Dummy 발생하지 않음 필요에 따라 발생할 수 있음 연관관계 표현 네 가지 유형 의존관계 모두 표현 -FS -FF -SS -SF -FS 의존관계만 표현 가능 ※ Dummy란 자원을 소모하지 않는 공정으로 Milestone이 대표적인 예 Page  129

6.2 활동순서배열 리드(Lead) / 래그(Lag) 리드(Lead) 후행 액티비티의 착수를 당길 수 있는 관계
선행 액티비티의 종료 이전에 후행 액티비티를 착수할 수 있는 개념 (예:매뉴얼 작성 시 1차 드래프트 버전 완료 15일 존에 2차 드래프트 버전에 착수할 수 있다) 래그(Lag) 후행 액티비티의 착수를 지연시키는 관계 선행 액티비티가 종료되고 일정 기간이 지나서 후행 액티비티를 착수할 수 있는 개념 (예:콘크리트 타설 후 바로 도색작업에 착수하지 못하고 양생을 위해 3일을 기다려야 한다) 1차 드래프트 작성 2차 드래프트 작성 FS – 15D 콘크리트 타설 도색작업 FS + 3D Page  130

Project team Knowledge
6.3 활동자원산정 각 활동을 수행하는데 필요한 자재, 사람, 장비 또는 공급품의 종류와 수량을 산정하는 프로세스 도구 및 기법 Input Tool & Technique Output 조직 및 외부상황 (EEF) Historical Data (OPA) Project files Commercial DB Project team Knowledge Project Context (규모, 환경, 스킬) 전문가 판단 대안분석 . 조직 내 자원의 제약조건 고려 . 프로젝트 일차적인 제약조건 고려 ( 일정, 예산) Bottom-up estimating 프로젝트 관리 소프트웨어 추정 -활동자원 요구사항 -RBS -프로젝트 문서 Updates Page  131

(Program Evaluation and Review Technique) (Critical Path Method)
6.4 활동기간산정 산정된 자원으로 개별 활동을 완료하는데 필요한 총 작업 기간을 개략적으로 산정하는 프로세스 PERT / CPM 차이 PERT (Program Evaluation and Review Technique) CPM (Critical Path Method) -미국 해군의 미사일 개발 프로젝트를 통해서 개발 -3점 추정 -액티비티 기간에 대하여 세가지 추정치 사용 (probabilistic) -평균 = (p +4m + o) / 6 ( p : 비관치, m : 보통치, o : 낙관치) 표준편차 = ( p – o ) / 6 -액티비티 기간에 대한 불확실성이 높아서 정확한 일정을 산출하고자 할 때 적합 -위험을 고려한 일정 추정 기법 -개발일정 추정에 관심을 두며 듀퐁의 화학공장건설 프로젝트를 통해 개발됨 -1점 추정 -이전 프로젝트의 경험을 통하여 불확실성이 적을 경우 사용하며 액티비티마다 추정치가 한가지다(deterministic) Page  132

6.5 일정개발 활동순서, 기간, 자원 요구사항 및 일정 제약사항을 분석하여 프로젝트 일정을 수립하는 프로세스 PERT/CPM
활동순서, 기간, 자원 요구사항 및 일정 제약사항을 분석하여 프로젝트 일정을 수립하는 프로세스 PERT/CPM PERT 각 작업(Activity)의 소요기간을 3점 추정에 의한 기대값을 산출하여 적용하는 확률적 방식으로 결과 값은 정규분포를 따른다는 가정에 따라 50%의 확률을 갖게 됨 과거의 경험이 별로 없는 새로운 프로젝트를 성공적으로 완료하기 위해 최적의 시간 (공기단축 포함)을 찾아내기 위한 방식 CPM 과거 경험에 맞춰 작업기간과 작업 순서에 근거하여 작성된 N/W 다이어그램을 이용하여 각 작업의 시작, 종료, 여유시간을 계산하는 방법으로 여러 경로 중 가장 긴 Path를 Critical Path라 함 임계경로의 의미 프로젝트의 게시에서 종료까지 가장 긴 시간이 걸리는 경로를 나타내며 동시에 임계경로선상의 작업이 늦어지면 그 만큼 프로젝트 전체가 늦어지는 것임 Critical Path상의 액티비티는 여유시간(Float) = LF(Last Finish) – EF(Early Finish) = 0 인 공정 Page  133

여유시간(Float) ( LS-ES = LF-EF)
6.5 일정개발 PERT/CPM PERT 12 4 6 8 마 라 다 나 가 22 18 ES : Early Start EF : Early Finish LS : Late Start LF : Late Finish Forward Scheduling Backward Scheduling 10 작업 소요시간 ES EF LS LF 여유시간(Float) ( LS-ES = LF-EF) 가,나 12 가,다 4 6 10 나,라 18 다,라 8 라,마 22 Page  134

6.5 일정개발 PERT/CPM PERT 자 아 다 나 가 마 라 사 차 바 Backward Scheduling
Forward Scheduling 3 7 5 2 4 1 6 8 10 11 15 16 22 23 26 27 29 20 13 Critical Path : Float이 0인 Activity의 연결 Early Start Early Finish Last Start Last Finish 납기를 지연시키지 않고 가질 수 있는 여유시간(Float) Page  135

실습 #5. PERT/CPM 계산 다음의 CPM 네트워크에서 임계경로(Critical Path)를 찾으시오. (30분) 작업
선행작업 소요시간 가 없음 8 나 10 다 5 라 3 마 7 바 2 사 다, 라 1 아 6 자 바, 사, 아 4 Page  136

6.5 일정개발 도구 및 기법 일정단축(Schedule Compression) 구분 공정압축법 (Crashing)
공정중첩단축법 (Fast Tracking) 방법 자원(비용)을 더 투입하여 일정을 단축 시키는 방법 순차적으로 수행해야 하는 단계나 Activity를 병행하여 수행하는 방법 대상 Critical Path상에 있는 Activity 가운데 최소의 비용으로 최대의 단축을 얻을 수 있는 Activity 연관관계 중 Mandatory Dependency를 제외한 병행 가능하다고 판단한 작업 상황 -예산이 충분하거나 여분의 자원이 있을 때 -재작업 가능성이나 위험요소가 증가하는 것을 원하지 않을 때 -예산을 더 투입할 수 없을 때 Page  137

일정개발 주공정연쇄법(Critical Chain Method)
제한된 자원을 고려하여 프로젝트 일정을 수정하는 일정네트워크 분석 기법 여러 가지 방식을 결합 작업 일정 활동과 무관한 기간 완충을 추가하여 계획된 활동 기간을 유지 계획된 일정 활동에 적용된 자원과 완충 활동 기간을 관리하는 데 중점 50 : 50 추정 버퍼 Activity A Activity B Activity C 버퍼 C 버퍼 A 버퍼 B 줄인 버퍼 행동영역 안전영역 감시영역 ※ 안전영역 : 사용하여도 안전한 버퍼 ※ 감시영역 : 버퍼사용추이 및 원인을 모니터링하는 영역 ※ 행동영역 : 버퍼 통제를 위한 조치를 취하는 영역 각 액티비티가 지연되는 경우 전체 버퍼를 활용. Page  138

일정개발 Critical Path / Critical Chain 비교 구분 Critical Path Critical Chain
착수일 Earliest Start Date Latest Start Date 관리관점 진척률, EVM 전체 버퍼의 소진율 버퍼 각 액티비티에 버퍼 반영 버퍼를 모아서 관리 자원제약 액티비티 사이의 연관관계 Dependency를 고려하여 일정계획 수립 후 자원 평준화(Resource Leveling)로 해결 자원 제약 자체를 계획에 반영 Page  139

6.5 일정개발 도구 및 기법 자원평준화(Resource Leveling)
특정 기간에 과부하된 자원(Over-loaded Resource)을 활용 범위 안에 분포하도록 자원을 분산(Load Balancing)하는 작업 15 10 5 (기간) (인원) ※ 특정기간에 과부하된 자원의 작업량을 줄이는 방법은 과부하된 기간 동안 수행하는 여러 액티비티의 일부를 다른 기간에 수행하는 것으로 조정하는 것 ※ 자원 평준화는 종종 프로젝트 기간의 연장을 초래한다 Page  140

6.6 일정통제 프로젝트의 상태를 감시하여 프로젝트의 진행을 갱신하고 일정 기준선에 대한 변경을 관리하는 프로세스
프로젝트의 상태를 감시하여 프로젝트의 진행을 갱신하고 일정 기준선에 대한 변경을 관리하는 프로세스 일정통제의 중점활동 사항 프로젝트 일정의 현황 판별 일정 변경의 원인이 되는 요인 조정 프로젝트 일정의 변경 여부 판별 실제로 발생하는 변경관리 Page  141

7. 프로젝트 원가관리 7.1 원가산정 7.2 예산결정 7.3 원가통제 Page  142

7.1 원가산정 프로젝트 활동을 완료하는데 필요한 금전적 자원의 근사치를 추정하는 프로세스 도구 및 기법
프로젝트 활동을 완료하는데 필요한 금전적 자원의 근사치를 추정하는 프로세스 도구 및 기법 유사산정(analogous Estimating) 과거 유사한 프로젝트의 범위, 예산, 기간 복잡성 등 측정치를 기준으로 활용하는 것 모수산정(Parametric Estimating) 과거 실적 자료와 기타 변수 (근로 시간, 소프트웨어 코드 행 수)사이의 통계적 관계를 활용하여 일정 활동 자원의 원가 산정치를 계산하는 기법 상향식 산정(Bottom-up Estimating) 개별 작업 packages나 최하위 수준의 개별 일정 활동의 원가를 산정한 후 산출된 원가를 상위 수준으로 roll up하는 방식 프로젝트관리 소프트웨어 원가 산정 소프트웨어 프로그램, 스프레드시트, 시뮬레이션 통계 도구 활용 Page  143

원가추정 프로세스 기법 No. 기법 설명 1 Analogous Estimating
이전에 수행한 비슷한 프로젝트를 참고로 원가를 추정 2 Determine Resource Cost Rates 시간간당 인건비 등 자원의 단가를 결정 3 Bottom up Estimating Work Package나 Activity의 원가를 추정해서 상위 수준으로 ‘Roll Up’ 4 Parametric Estimating Historical Data와 변수들 사이의 통계적인 관계를 사용하여 추정 5 Project Management Software 스프레드시트, 시뮬레이션, 확률분석 도구 등 원가 추정 툴 6 Vendor Bid Analysis 입찰에 의한 방법으로 프로젝트가 진행될 때 견적가와 예상원가를 분석 7 Reserve Analysis 위험이나 문제 해결을 위해 예비비를 확보 8 Cost of Quality 프로젝트 품질비용의 금액이나 비율을 고려 Page  144

7.1 원가산정 FP 산정 방법 FP 정의 FP 를 이용한 개발원가산정 절차 FP 규모 산정 절차
소프트웨어 모듈의 기능에 가중치를 부과한 기능점수라는 계수를 도입하여 계산 FP 를 이용한 개발원가산정 절차 측정유형 결정 미조정 기능점수 계산 데이터 기능 측정 측정범위와 어플리케이션 경계 식별 조정인자 결정 (VAF) 조정 기능 점수 계산 트랜잭션 기능 측정 FP 규모 산정 절차 ※ 조정인자( VAF : Value Adjustment Factor ) -어플리케이션 사용자에게 제공되는 일반적인 기능을 나타내는 인자 -어플리케이션에 대한 14가지의 일반적인 시스템 특성을 평가 Page  145

7.1 원가산정 FP 산정 절차 측정 유형 결정 측정범위와 어플리케이션 경계 식별 데이터 기능 유형
시스템 개발 유형에 따른 기능점수 측정방식 결정 개발 프로젝트 기능점수, 개선프로젝트 기능점수, 어플리케이션 기능점수로 분류 측정범위와 어플리케이션 경계 식별 측정범위 : 규모를 측정 하고자 하는 어플리케이션 기능 범위 어플리케이션 경계 식별 : 측정대상 소프트웨어와 사용자간의 경계를 의미함 데이터 기능 유형 내부논리파일(ILF : Internal Logical Files) : 사용자 어플리케이션 영역 내에 존재하는 사용자가 식별 가능한 제어정보(Control Information) 또는 논리적으로 연관된 DATA들의 집합을 의미하며 해당 어플리케이션 내의 단위 프로세스에 의해서 반드시 Maintained된다(Maintained란 외부 입력 같은 단위 프로세스에 의하여 데이터가 변경되는 것을 말한다(추가, 수정, 삭제 등) 외부연계파일(External Interface Files) : 다른 어플리케이션 경계 내에서 수정되어지는 사용자가 인식 가능한 논리적으로 연관된 데이터 그룹이나 어플리케이션에 의해서 참조되는 제어정보를 말한다(한 어플리케이션에서 EIF로 측정되는 파일은 다른 어플리케이션에서 ILF로 측정된다) Page  146

7.1 원가산정 FP 산정 절차 조정인자(VAF: Value Adjustment Factor) 보정계수(4가지) 규모 보정계수
14개의 시스템 일반특성(GSC: General System Characteristics)으로 구성 Data 기능과 Transaction기능만 가지고 규모를 측정하는 경우 시스템의 특성에 따른 난이도가 고려되지 않는 단점 보완 ISO는 시스템 특성을 배제하는 분위기 임 국내 사업대가 고시에는 14개 GSC 중 일부의 내용을 포함하는 네 가지 ‘보정계수’를 적용하고 있음 보정계수(4가지) 규모 보정계수 어플리케이션유형 보정계수 언어 보정계수 품질특성 보정계수 Page  147

7.1 원가산정 FP 산정 절차 기능점수 계산과정 기능수(∑기능유형 * 가중치)
기술적 복잡도(TCF) = * 총영향도(항목 14개, 0 ~ 5) 기능점수(기능수 * 기술적복잡도) Page  148

7.1 원가산정 개발 원가 산정 절차 보정 계수 적용 총 보정계수는 규모, 어플리케이션유형, 개발언어, 품질 및 특성 보정계수를 곱하여 산정 개발원가 = 보정전 개발원가 * 총 보정계수 보정계수 보정계수별 적용 방법 규모 - 개발규모가 증가하면 투입인원이 증가하고 프로젝트 관리 및 투입 인력간 의사소통의 증가로 생산성이 감소하는 부분을 반영한 보정계수임(0.108 * log e (기능점수) ) 어플리케이션 유형 - 로직의 복잡성과 시스템의 영향정도에 따라 생산성이 증감되는 것을 반영한 보정계수 - 업무처리용, 과학기술용, 멀티미디어용 등 어플리케이션의 유형에 따라 보정계수를 적용함 언어 - 프로젝트 개발언어별로 적용비율 도출하며 구현 및 시험단계에만 적용 - 개발언어별 보정계수와 적용비율을 곱하여 언어별 보정치를 구하고, 각 언어별 보정계수 합을 구함 예) C, C++, Java 의 보정계수는 모두 1.2 이고, 적용언어가 C와 Java이고 각각 프로젝트에 10%와 90%를 적용했다면, 언어별보정치는 (1.2*0.1) + (1.2*0.9)로 계산, 구현 및 시험단계에만 적용 품질특성 - 분산처리, 성능, 신뢰성, 다중사이트 여부 Page  149

7.2 예산결정 개별 활동 또는 작업 패키지별로 산정된 원가를 합산하여 승인된 원가 기준선을 설정하는 프로세스 도구 및 기법
개별 활동 또는 작업 패키지별로 산정된 원가를 합산하여 승인된 원가 기준선을 설정하는 프로세스 도구 및 기법 원가합산 작업분류체계(WBS)에 따라 작업 패키지별로 원가 산정치를 합산 전문가 판단 수행 중인 활동에 해당되는 응용분야, 지식영역, 전문분야, 산업분야 등의 전문지식에 근거하여 제시되는 판단을 예산 결정에 활용 선례관계 유사 프로젝트 또는 경험한 프로젝트 특성을 사용하여 전체 프로젝트 원가를 예측 자금한도 조정 프로젝트 자금을 집행할 때 자금 한도에 맞춰 지출 조정 Page  150

7.3 원가통제 프로젝트 상태를 감시하면서 프로젝트 예산을 갱신하고 원가 기준선에 대한 변경을 관리하는 프로세스
프로젝트 상태를 감시하면서 프로젝트 예산을 갱신하고 원가 기준선에 대한 변경을 관리하는 프로세스 원가통제 활동은 다음을 포함한다 승인된 원가 기준선에서 변경을 초래하는 요인 조정 모든 변경 요청이 적시에 실행되도록 감시 실제로 발생하는 변경관리 원가 지출이 기간별로 승인된 자금과 프로젝트 총액을 초과하지 않도록 관리 원가 성과를 감시하여 승인된 원가 기준선을 벗어난 차이 확인 및 파악 지출된 자금에 대한 작업 성과 감시 승인되지 않은 변경이 보고된 원가 또는 자원 사용량 자료에 포함되지 않도록 차단 승인된 모든 변경 및 연관된 원가를 이해관계자에게 통지 예상원가 초과를 허용한계 내로 통제하는 조치 수행 Page  151

7.3 원가통제 획득가치관리(EVM : Earned Value Management) 계획가치(Planned Value, PV)
지정 시점까지 완료해야 할(계획된) 작업의 예산 원가 획득가치(Earned Value, EV) 완료된 작업 예산 원가 실제 원가(Actual Cost, AC) 실제 발생한(완료된) 총 원가 원가 차이(Cost Variance, CV) 획득가치(EV) – 실제원가(AC), 음수는 예산초과 일정 차이(Schedule Variance, SV) 획득가치(EV) – 계획가치(PV), 음수는 공정 지연 일정성과지수(Schedule Performance Index, SPI) 획득가치(EV)/계획가치(PV), 1미만은 공정 지연 원가성과지수(Cost Performance Index, CPI) 획득가치(EV)/실제원가(AC), 1 미만은 예산초과 Page  152

7.3 원가통제 획득가치관리(EVM : Earned Value Management)
BAC(Budget At Completion) 총 예산 EAC(Estimate At Completion) : 현 시점에서 예측한 종료시의 발생원가 총예산(BAC) / 원가성과지수(CPI) ETC(Estimate At Completion) : 현 시점에서 향후 추가로 발생할 것으로 추정한 원가 EAC - AC VAC(Variance At Completion) : 현 시점에서 추정한 종료시의 추가 발생 원가 BAC - EAC Page  153

기성고 기법의 지표 구분 지표 공식 의미 일정 SV(Schedule Variance) EV-PV
SPI(Schedule Performance Index) EV/PV SPI > 1 : 일정이 계획을 초과 SPI = 1 : 일정이 계획과 같음 SPI < 1 : 일정이 계획에 미달 원가 CV(Cost Variance) EV-AC CV > 0 : 원가가 계획을 초과 CV = 0 : 원가가 계획과 같음 CV < 0 : 원가가 계획에 미달 CPI(Cost Performance Index) EV/AC CPI > 1 : 원가가 계획을 초과 CPI = 1 : 원가가 계획과 같음 CPI < 1 : 원가가 계획에 미달 Page  154

직접비와 간접비 구분 정의 종류 직접비(Direct Cost) 프로젝트 수행에 직접적으로 투입되는 비용 재료비, 인건비 등
간접비(Indirect Cost) 프로젝트 수행에 간접적으로 투입되는 비용 사무실 임대료, 전기료, 복리 후생비, 세금 등 Page  155

8. 프로젝트 품질관리 8.1 품질 계획 수립 8.2 품질 보증 수행 8.3 품질 통제 수행 Page  156

8.1 품질 계획 수립 프로젝트 및 제품에 대한 품질 요구사항 및 표준을 식별하고, 어떻게 프로젝트가 준수할지 입증하는 방법을 문서화하는 프로세스 품질(Quality) 단순한 기능의 고품질 (예: 메모장, 포스트잇) 복잡한 기능의 고품질 ( 예: 휴대전화) 단순한 기능의 저품질 복잡한 기능은 많지만 에러가 많음 High 고객에게 저품질의 제품을 제공해서는 안 된다 Low Low High 고객이 요구하는 기능 이상을 제공하여서는 안 된다 ( Gold Plating ) Low Grade는 문제가 되지 않는다 등급(Grade) Page  157

정확도(Accuracy)와 정밀도(Precision)
정확도 : 측정한 값이 얼마나 참값(true value)에 근접해 있느냐 의미 정밀도 : 측정한 값이 얼마나 한 값에 모여 있느냐, 즉, 흩어짐의 정도가 얼마나 작으냐 의미 항목 이슈 대책 정확도 프로젝트 완료 기준은 무엇인가? 인력철수, 대금청구, 대금회수, 검수 등 조직 내 여러 부서가 합의하는 기준을 정의 정밀도 경우에 따라 기간을 월, 주, 일 가운 데 하나를 임의로 사용 지표를 명확히 정의(휴일포함 여부) 지표의 측정 단위를 월이나 주단위로 하지 않고 일단위로 함 Page  158

현대 품질관리 활동의 중요성 다음과 같은 활동의 중요성을 인식하고 있다 고객 만족 검사보다 예방우선 지속적인 개선 관리 책임
고객의 기대치를 파악, 평가, 정의 및 관리하여 고객의 요구사항을 충족시키는 것 프로젝트가 반드시 목표한 것을 산출한다는 “요구사항에 일치성”과 제품이나 서비스가 실질적인 필요를 충족한다는 “용도에 적합성”을 모두 갖춰야 한다 검사보다 예방우선 품질이란 검사 대상이 아니라 계획, 설계 및 구축의 대상이라는 것이 현대의 품질관리 기본 원칙이다(오류의 발생을 예방하는 비용이 검사 결과 확인된 오류를 시정하는 비용보다 훨씬 적다) 지속적인 개선 슈와트(Shewhart)가 정의하고 데밍(Deming)이 보완한 계힉-시행-검토-조치(PDCA: Plan-Do-Check-Act) 주기가 품질 개선의 기본이다(TQM, 6시그마, CMMI 등) 관리 책임 프로젝트를 성공하기 위해서는 프로젝트 팀 전원의 참여가 요구되지만 성공에 필요한 자원을 제공하는 것은 관리자의 책임이다 Page  159

품질관리계획서 프로젝트에 적합한 품질표준과 이를 달성하기 위한 품질활동 정의 품질관리계획서 목차 품질표준 내용 품질활동의 유형
프로젝트 상황에 적합한 제품 및 프로세스의 품질 표준 정의 품질활동의 유형 프로젝트에서 수행할 품질활동과 간략한 내용 설명 품질활동 수행 책임자 품질활동 수행 시기 품질활동 대상 품질활동의 핵심은 무엇을 검토하는 활동이다(검토의 대상 정의) 품질활동 수행절차 품질활동 체크리스트 지적 사항 시정조치 절차 Page  160

품질활동 계획수립 도구 및 기법 수익비용 분석(benefit-cost analysis)
품질활동에 소요되는 비용과 그에 따르는 효과를 분석하여 최적의 품질수준 계획 (재작업 감소, 생산성 증가, 프로젝트 비용감소, 이해관계자들의 만족도 증대) 품질비용(COQ: Cost Of Quality) 프로젝트의 품질활동에 소요되는 모든 비용 벤치마킹(Benchmarking) 실제 또는 계획한 프로젝트의 실무관행을 유사한 프로젝트의 실무관행과 비교 실험 설계법(DOE: Design Of Experiment) 결과에 영향을 미치는 여러 변수들을 조합하여 실험을 해보고 그 결과를 통해 변수들의 영향력 분석(예: 정보시스템의 응답속도 저하, H/W용량, N/W성능, DB구조, APP.구조, TXN수) 친화도 여러 가지 아이디어나 생각들이 정돈되지 않은 상태로 있어 전체적인 파악이 어려울 때, 이를 이해하기 쉽도록 유사성이나 연관성에 따라 묶는 방법 Page  161

품질비용 제품 생애 주기 전반에 품질과 관련된 모든 업무에 대한 총 비용 품질비용 정의 예 예방비용
( Prevention Cost) 불량의 예방을 위하여 설계나 제조, 수행단계에서 사용하는 비용 . 품질계획비용 . 설계검토비용 . 공정관리비용 . 교육훈련비용 평가비용 (Appraisal Cost) 품질을 만족하는지 확인하기 위하여 재료, 반제품, 완제품 등을 측정/평가하는데 사용하는 비용 . 검사비용 . 프로젝트 감리비용 . ISO 획득 비용 실패비용 (Failure Cost) 내부(Internal) 부적합이나 불량이 고객에게 넘겨지기 전에 발견되어 이를 조치 하는데 드는 비용 . 폐기처분 비용 . 재작업 비용 . 재검사비용 . 작업중단비용 외부(External) 고객에게 넘겨진 다음 부적합이 발견되어 이를 조치하는데 드는 비용 . 클레임처리비용 . 반품비용 . 보증수수료 . 제품책임비용 Page  162

8.2 품질 보증 수행 품질 요구사항과 품질 통제 측정치를 감시하면서 해당하는 품질 표준과 운영상 정의를 사용하고 있는지 확인하는 프로세스 도구 및 기법 품질 감사 프로젝트 활동이 조직의 프로젝트 정책, 프로세스 및 절차를 따르는지 판별하기 위하여 수행하는 체계적이며 독립적인 검토 활동 감사의 목적 수행 중인 우수한/모범적인 실무관행 식별 모든 격차/결점 식별 조직 및/또는 산업 내 유사 프로젝트에서 도입 또는 구현한 모범적 실무관행 공유 팀의 생산성 향상에 도움이 되도록 프로세스 구현을 개선하는 방식 지원 제공 프로세스 분석 프로세스 개선 계획서에 기술된 단계에 따라 필요한 개선사항 식별 및 분석 Page  163

8.3 품질 통제 수행 품질 활동의 실행 결과를 감시하고 기록하면서 성과를 평가하고 필요한 권고안을 제시하는 프로세스
품질 활동의 실행 결과를 감시하고 기록하면서 성과를 평가하고 필요한 권고안을 제시하는 프로세스 도구 및 기법 인과관계도(Cause-and-Effect Diagram, Ishikawa Diagram, Fishbone Diagram) 다양한 요인과 잠재적 문제 또는 영향의 관계를 도식화 원인과 결과 관계 분석 및 문제해결의 촉진 Page  164

인과관계도(예) 절차상의 어려움 매뉴얼의 유용성 환경 매뉴얼에 대한 불만이 많다 유용성 매뉴얼상의 문제 종이 배포 문제
시스템이 오래되어 매뉴얼이 분실됐다. 표준이 없다 배포 절차가 어렵다 현재 매뉴얼이 없거나 미흡하다 매뉴얼의 “기술방법” 절차가 부족하다 활용되지 않는 매뉴얼이 있다 현재 시스템과 매뉴얼이 일치하지 않는다 매뉴얼에 대한 불만이 많다 업무에 Orient되어 매뉴얼이 활용되지 않음 현 시스템과 불일치 User가 한정되어 있다 기술방법이 일정치 않다 난해하다 매뉴얼이 필요 없는 시스템이 있다 매뉴얼이 없거나 미흡 이해하기 힘들다 유용성 매뉴얼상의 문제 Page  165

품질통제 툴 구분 Technique / Tool 설명 부적합 식별 및 수정 Control Chart Inspection
프로세스를 예측할 수 있고 안정적인지를 판단 Inspection 산출물이 표준에 부합하는지 여부를 평가 Run Chart 시간의 흐름에 따른 프로세스 및 성과 추이 분석 Defect Repair Review 프로세스와 독립적인 제3의 부서에서 식별된 결함을 정확하게 수정하는지 평가 부적합 유형 분류 및 우선순위결정 Histogram 특정 변수의 빈도수를 그래프로 표현 Pareto Chart 결함 원인을 빈도수 순서대로 Histogram의 형태로 표현하여 효과가 큰것부터 수정 Case Effect Diagram 주요 원인에 대한 다양한 변수들의 관계를 생선뼈 모양으로 체계적으로 표현 원인분석 Flowchart 문제의 발생 경과를 프로세스 흐름으로 표현 Scatter Diagram 두 변수의 상관관계를 X, Y축으로 표현하여 독립변수 및 종속변수를 추정 기타 Statistical Sampling 품질통제활동 비용을 최소화할 수 있는 모집단에서의 샘플 추출 방법 Page  166

통제도(Control Chart) 정의–프로세스가 안정적인지를(stable) 시간대별로 표현
용도–프로세스의 안정 여부 혹은 제품의 합격·불합격 여부를 판단 Out of control의 유형 결과가 상한선(UCL)이나 하한선(LCL)을 벗어나는 경우 7 rule : 7개 이상의 연속되는 포인트가 특정 패턴을 보이는 경우 ( 특정패턴이란 ①계속 증가 ②계속 감소 ③평균을 중심으로 어느 한 부분에만 위치하는 세가지를 의미한다) Hugging : 평균을 중심으로 어느 한 부분에 2/3 이상이 몰려 있는 경우 Upper Spec. Limit Lower Spec. Limit Upper Control Limit Lower Control Limit In Control Out of Control Page  167

파레토 다이어그램(Pareto Diagram)
정의–알려진 원인의 유형을 빈도수에 따라 히스토그램의 형태로 정리한 표 용도–파레토 다이어그램은 흔히 80:20의 법칙으로 알려져 있는데, 20%의 프로그램에서 80%의 결함이 발생한다거나, 20%의 프로그램이 80%의 기능을 커버한다는 원리이다. 즉, 제한된 자원으로 최대의 효과를 얻고자 할 때 자주 활용하는 기법 < 공정별 버그 건수를 파악한 파레토 다이어그램 > Page  168

품질관리(Summary) 품질계획 품질보증 품질통제
프로젝트에 적합한 품질표준을 선정하고 이를 프로젝트에 어떻게 달성할 것인지 계획하는 것 품질보증 프로젝트가 요구사항을 충족시키기 위해 필요한 모든 프로세스를 적용할 것이라고 보장하는 계획적이고 체계적인 품질활동 품질통제 프로젝트 결과물에 대한 모니터링을 통해 관련 품질 표준을 만족하였는지 결정하고 부적합이 발생할 경우 원인을 찾아 해결하는 것 Page  169

품질관리(Summary) 생명주기에 대한 품질종류 요구품질(requirement of quality)
제품을 사용하거나 서비스를 적용 받을 사람의 관점에서 요구되는 품질 설계품질(quality of design) 명세(specification)와 설계(design)에 의해서 정의된 품질 제품품질(quality of manufacture) 제조 공정에 의해서 실현된 제품의 품질 적합품질(quality of conformance)이라고도 함 사용품질(quality of use) 제품이 시장에서 소비자들이 사용한 후 주관적으로 평가한 품질 시장품질이라고도 함 Page  170

품질관리(Summary) 품질활동체계 품질 계획수립(Quality Planning)
프로젝트 요구사항이 무엇이고 무엇을 어떻게 달성할 것인가? - 품질 요구사항 정의(기능, 성능) - 품질활동 프로세스 정의(테스트, 리뷰 등) 품질 보증 수행(Quality Assurance) 요구사항 충족을 위해 필요한 프로세스를 수행한다는 것을 계획적/체계적으로 보증 - 프로세스 심사 - 프로세스 개선활동 품질 통제 수행(Quality Control) 요구사항을 달성하였는지 확인하고 미흡한 경우 필요한 시행조치 활동 수행 - 테스트 활동 수행 및 결함수정 - 부적합 원인 분석 제품/프로젝트 요구사항(Needs) Process Needs (품질정책) 요구사항 정의 동시 사용자 1,000명을 커버하고 응답속도 2초 이내 온라인주식거래시스템 전사품질정책 품질 매뉴얼 프로젝트 수행방법론 ※ QA는 QP에서 정의한 QC를 제대로 하고 있는지 확인하는 활동 Page  171

품질관리(Summary) 체크리스트(예) 단계 항목 Y N NA 요구 사항 1. 요구사항이 일관되게 기술되었는가?
2. 요구사항이 명백하게 기술되었는가? 3. 정의된 모든 요구사항은 소프트웨어로 구현 가능한가? 4. 하나의 요구사항은 여러 요구사항에 중복됨이 없이 유일하게 존재하는가? 5. 기능적 요구사항이 작성되었나? 6. 기능적 요구상에 대하여 기능개요, 입력, 처리방법, 출력 등을 기술 하였는가? 7. 고객의 성능 요구사항이 테스트 가능하도록 정량화 되어 있는가? 8. 개발해야 할 S/W와 타 시스템간 인터페이스가 요구명세에 적절하게 기술되었나? 9. 보안관련 요구사항이 기술되었나? 10. 하드웨어 환경(제약사항 포함)이 완전하게 정의되었는가? 11. 설치 및 Migration 요구사항이 완전하게 정의되었는가? 12. 주요 기능적 요구사항에 대해 계층적으로 세분화 되어 기술되었는가? 13. 도출된 요구사항은 프로젝트에서 구축해야 할 모든 영역을 충분히 커버하고 있나? 14. 요구사항에 대한 변경관리가 이루어지는가? 15. 소프트웨어 요구분석 결과는 관련자와 합동 검토를 하고 그 결과는 문서화되었는가? Page  172

품질관리(Summary) 체크리스트(예) 단계 항목 Y N NA 16. 요구사항이 현재 시스템으로 수용 가능한가?
17. 모든 요구사항이 최소한 하나 이상의 테스트 활동을 통해서 검증될 수 있는가? 설계 1. 설계가 요구사항 문서에 추적 가능한가? 2. 설계가 일관되게 기술되었나? 3. 설계가 명백하게 기술되었나? 4. 인터페이스가 명백하게 정의되었나? 5. 요구사항의 제약사항이 설계로 통합되었는가? 6. 모든 에러 메시지가 정의되었는가? 7. 모든 의존성(dependencies)이 명백하게 식별되었는가? 8. 설치 및 Migration 요구사항이 설계로 통합되었는가? 9. 요구사항에 명시된 성능 요구사항이 설계로 통합되었는가? 10. 모든 설계가 최소한 하나 이상의 테스트 활동을 통해서 검증될 수 있는가? 11. 컴포넌트와 모듈의 구조가 명백하게 정의되었는가? 12. 컴포넌트와 모듈의 명명법(naming convention) 표준이 준수되었는가? 13. 설계에 명시된 모든 알고리즘이 명백하게 기술되었나? Page  173

품질관리(Summary) 품질통제 기법-QC의 7가지 도구 도표(예) 기법 설명 체크시트
공정으로부터 필요한 자료를 수집하는데 가장 흔하게 사용하는 도구 불량 수, 결점 수 등 셀 수 있는 데이터를 기입할 수 있게 작성된 용지 파레토 다이어그램 문제가 되고 있는 불량품, 결점, 클레임, 사고 등과 같은 현상이나 원인 별로 데이터를 분류하여 불량 수 및 손실금액 등이 많은 순서로 정리하고 그 크기를 막대 그래프로 나타낸 것 발생사례를 중요도에 따라 분류해서 가장 중요한 것을 먼저 해결하는데 중점을 두고 있음 흐름도 (Flow Chart) -문제가 어떻게 발생하는지 분석하기 위해 프로세스의 흐름을 표현한 것 특성요인도 -문제점(특성)과 문제점에 영향을 주는 원인(요인)의 관계를 도식화하여 분석하는 기법 히스토그램 -데이터가 존재하는 범위를 몇 개의 구간으로 나누어 각 구간에 포함되는 데이터의 발생도수를 세어서 도수표를 작성한 다음 이를 도형화한 것 산점도 -사람의 키와 몸무게처럼 서로 관련 있는 쌍으로 된 변수의 관측값을 직교 좌표상에 표시하여 두 변수 사이의 대략적인 관계를 시각적으로 판단하도록 한 그림 통제도 -공정상의 이상 여부를 알기 위해, 또는 공정의 안정 유지를 위해 사용하는 그래프 Page  174

실습 #6. 품질비용 예방비용, 평가비용, 내부실패비용, 외부실패비용 구분하기 (30분) Hand-out Page  175

9. 프로젝트 인적자원관리 9.1 인적자원계획서 개발 9.2 프로젝트 팀 확보 9.3 프로젝트 팀 개발 9.4 프로젝트 팀 관리 Page  176

9.1 인적자원계획서 개발 프로젝트의 역할, 책임사항, 필요한 기량, 보고관계를 식별하여 문서화하고, 직원 관리 계획서를 작성하는 프로세스 도구 및 기법 조직도 및 직무 기술서 프로젝트 조직의 역할과 책임을 정의 Page  177

계층구조의 조직도 전통적인 조직도 구조로 직위와 관계를 상하 도식으로 보여주며 가장 많이 활용하는 조직도 형태 특징
전통적인 조직도 구조로 직위와 관계를 상하 도식으로 보여주며 가장 많이 활용하는 조직도 형태 특징 보고체계를 함께 볼 수 있으며 시각적으로 이해하기 쉽다 조직분류체계(OBS : Organization Breakdown Structure)라고도 함 Page  178

매트릭스형 역할표 각 액티비티 별로 구체적인 책임을 정의 특징
RAM(Responsibility Assignment Matrix) RACI(Responsible, Accountable, Consult, Inform) Chart 라고도 함 구분 박 PM 석 PL 김 개발 이 개발 분석 S R P 설계 개발 구현 S(Sign-off) : 승인자, R(Review) : 검토자, I(Input) : 입력물 책임자, P(Participant) : 업무수행 주1) 사람은 역할(PM, QAO, TA, PL 등)로 대신할 수 있다 주2) 업무는 단계, 액티비티, 태스크 혹은 주요 이벤트를 기술할 수 있다 주3) 고객도 포함하여 작성하는 것이 바람직하다 Page  179

텍스트형식 역할표 자세한 설명을 필요로 하는 팀원 책임사항을 텍스트 형식으로 팀원의 역할 기술 특징
자세한 설명을 필요로 하는 팀원 책임사항을 텍스트 형식으로 팀원의 역할 기술 특징 각 역할별로 상세한 책임을 정의하기에 적합함 Page  180

인적자원계획서 프로젝트의 인적 자원을 정의, 배정, 관리 및 통제하고, 마지막에 해제하는 방법에 대한 지침 제공
프로젝트의 인적 자원을 정의, 배정, 관리 및 통제하고, 마지막에 해제하는 방법에 대한 지침 제공 인적자원계획서에 포함될 내용 역할 및 책임사항 역할 / 권한 / 책임 / 역량 프로젝트 조직도 프로젝트 팀원과 보고관계 직원 관리 계획서 직원확보 : 프로젝트 팀원 확보 기획 자원 역일표 : 프로젝트 팀 개개인/전체 그룹에 필요한 일정표, 채용계획, 인적자원 확보시기 명시 직원해제계획 : 팀원의 해제 방법과 시기 결정 교육계획 평가 및 보상 규정준수 / 안전 Page  181

기능조직구조 기능부서 중심의 전통적인 조직구조(예:인사, 총무, 재무, 회계, 등) 장/단점 장점 단점
- 전문성이 높고 업무 범위가 명확 - 부서간 책임 분산 - 부서 내 의사소통체계가 간단하고 잘 정립 - 부서간 경쟁과 갈등 유발 - 안정적인 작업환경을 선호하는 직원에게 좋음 - 부서 관점의 편협된 의사결정 - 부서 내 명확하게 정의된 책임과 역할 - 전체 프로젝트를 책임지는 부서가 없음 - 기능부서가 기술지원 및 인력개발 지속 - 프로젝트 참여자에 대한 동기부여가 약함 ※ 기능 부서장의 권한이 프로젝트 관리자의 권한보다 강하다 Page  182

프로젝트 조직구조 주어진 목표를 단기간에 달성하기에 가장 적합한 조직구조(예:전담 TF) 장/단점 장점 단점
- PM이 프로젝트 팀원에 대한 작업 지시 권한 - 여러 개의 프로젝트 조직을 동시에 운영하면 자원의 낭비가 발생 - 팀원과 PM 사이의 의사소통이 쉽다 - 노하우나 기술이 개인에 의존되어 필요 이상의 자원이나 인력이 프로젝트에 있어야 함 - 의사소통과 보고체계가 단순하다 - 인력 충원을 하지 못하면 아웃소싱에 의존하는데, 이를 경우 노하우의 축적이 어렵다 - 과업 지향적이고 동질적인 팀 분위기 형성 - 프로젝트 완료 후 돌아갈 조직이 없다 - 신속한 의사 결정과 집행 가능 ※ 프로젝트 관리자의 권한이 기능 부서장의 권한보다 강하다 Page  183

매트릭스 조직구조 기능조직과 프로젝트 조직구조의 장점을 살린 혼합(hybrid) 조직형태 종류 장/단점
Strong Matrix, Balanced Matrix, Weak Matrix 장/단점 장점 단점 - 회사 전체 자원 활용의 극대화 - 조직의 구성체계가 복잡하여 구성원이 이해하기 어렵다 - 수직/수평의 정보공유 기여 - 이중 책임과 권한에 대한 갈등을 유발시킨다 - 기능부서/프로젝트 관점의 조화 - 관련부서와 협의과정에서 의사결정 기간이 길어진다 - 기능조직/프로젝트 조직의 장점을 발휘할 수 있다 - 희소자원일 경우 부서간의 갈등이 발생할 수 있다 - 신속한 의사 결정과 집행 가능 - 기능조직에서 능력 있는 사람을 프로젝트에 투입하지 않는다 ※ PM의 권한 : Strong Matrix > Balanced Matrix > Weak Matrix Page  184

조직구조와 프로젝트 관리자의 권한 100% 50% 0% Functional Matrix Projectized Weak
Strong Low PM의 권한 High 팀원이 프로젝트 팀에 있는 비율 팀원이 기능부서에 있는 비율 Project Expediter Part Time Coordinator Full Time Project Manger Project Office Separate Time Page  185

9.2 프로젝트 팀 확보 가용 인적 자원을 확인하여 프로젝트 배정을 완료하는데 필요한 팀을 구성하는 프로세스
가용 인적 자원을 확인하여 프로젝트 배정을 완료하는데 필요한 팀을 구성하는 프로세스 프로젝트 팀 확보를 위한 고려사항 프로젝트 관리자 또는 프로젝트 관리팀은 프로젝트에 필요한 인적자원을 공급할 위치에 있는 다른 사람과 효과적으로 협상하고 영향력을 행사해야 한다 프로젝트에 필요한 인적자원을 확보하는데 실패하면 프로젝트 일정, 예산, 고객 만족도, 품질, 리스크로 파급될 수 있다 프로젝트 성공률을 떨어뜨리고 프로젝트 취소라는 결과를 낳기도 한다 제약사항, 경제적인 요인 또는 다른 프로젝트에 사전 배정 등으로 인해 적임자를 투입할 수 없는 경우, 프로젝트 관리자 또는 프로젝트 관리팀은 법률, 규제, 의무 또는 기타 특정 기준을 위반하지 않는 한도에서 역량이 낮은 대체 인적자원을 배정하는 것이 필요할 수 있다 Page  186

도구 및 기법 사전배정 협상 프로젝트가 경쟁 입찰의 일환으로 특정인의 배정이 약속된 경우
프로젝트가 특정 전문가의 기술력에 의존하는 경우 일부 직원 배정이 프로젝트 헌장에 정의되어 있는 경우 프로젝트 팀원이 미리 선정되는 경우 사전배정으로 간주된다(선 확보) 협상 필요한 시기에 적합한 역량을 갖춘 직원 투입, 프로젝트에서 각자의 책임을 완수할 때 까지 프로젝트 팀원들의 참여 가능성, 의지, 권한이 유지되도록 확인하기 위해 기능관리자와 협상한다 희소성 또는 전문성 높은 인적 자원을 적절하게 배정하기 위해 수행 조직 내의 다른 프로젝트 관리팀과 협상한다 적임성, 희소성, 전문성 및 합당한 자격을 갖추고 있고, 인증되거나 기타방식으로 지정된 인적 자원을 확보하기 위해 외부조직, 공급업체, 계약업체 등과 협상한다 외부정책협상, 실무 프로세스, 지침, 법률 및 기타 관련 기준에 대해 특별히 주의를 기울여야 한다 Page  187

도구 및 기법 확보 가상팀(Virtual Team)
조직 내부에 프로젝트를 완수하는데 필요한 인력이 부족한 경우, 필요한 서비스를 외부공급처로부터 적합한 인력을 공급한다 컨설턴트를 고용하거나 작업을 외주처리 하는 방법 가상팀(Virtual Team) 직접 대면하는 일은 극히 적거나 한 장소에 모여서 프로젝트를 수행하는 것이 아니라 원격으로 떨어져 전자메일이나 화상회의와 같은 전자방식을 통해 프로젝트를 수행하는 팀 지리적으로 넓게 분포된 지역에 거주하는 같은 회사 직원들로 팀 구성 특수분야 전문가의 거주지역에 제한을 받지 않고 프로젝트를 수행할 때 재택근무자(home office)를 프로젝트에 참여할 때 다른 교대 근무조 또는 시간대에 일하는 사람들로 팀을 구성할 때 이동에 제약이 있거나 장애를 가진 사람을 팀에 편입 출장 경비 때문에 외면했던 프로젝트를 추진할 때 Page  188

가상팀의 장/단점 장점 단점 - 출장비, 해외 아웃소싱을 통한 인건비 절약
- 원격적으로 진행되는 만큼 많은 문제점이 발생할 수 있다(예. 의사소통) - 전문가의 참여로 기술적 전문성을 높일 수 있다 - 떨어져 프로젝트를 수행함으로 팀원 사이의 분쟁이 발생할 가능성이 다른 조직에 비해 높다 - 물리적 장소에 제약을 받지 안는다 - PM이 프로젝트팀을 통제하기 어렵다 Page  189

9.3 프로젝트 팀 개발 프로젝트 성과를 향상시키기 위해 팀원들의 역량과 팀원간 협력, 전반적인 분위기를 개선하는 프로세스
프로젝트 성과를 향상시키기 위해 팀원들의 역량과 팀원간 협력, 전반적인 분위기를 개선하는 프로세스 팀 빌딩 고려사항 팀 내에 과다한 작업이 있는 때 팀 성과가 낮아지거나 그 원인을 모를 때 의사 결정된 내용이 실행되지 않을 때 목표가 불명확하거나 팀원 사이에서 수용되지 않을 때 팀 리더가 갑작스런 문제에 부딪힐 때 팀원의 미팅에 비생산적이며 갈등이 많이 발생하고 사기를 저하시킬 때 팀원들이 책임을 회피하고 필요한 협조를 하지 않을 때 해결해야 할 갈등을 외면하고 있을 때 Page  190

팀 빌딩 응집력 있는 팀워크를 형성하고 유지하기 위해 다양한 환경, 배경, 동기 등을 가진 프로젝트 구성원을 이끌어 프로젝트를 성공적으로 완수해 나가는 일련의 과정 팀 빌딩 원칙 일찍 시작하라 중단하지 말고 프로젝트의 전 과정을 통하여 팀 빌딩을 구현하라 채용부터 좋은 사람을 선발하라 프로젝트 팀원 모두에게 서로 필요로 하고 있다는 확신을 심어주어라 프로젝트에 방해가 된다고 생각된다는 사람이 있으면 빨리 제거하라 주요한 모든 액티비티에 대하여 팀원의 자발적 합의를 얻어라 PM은 역할모델이다. 말하는 것을 직접 실천하라 무슨 일이 벌어지는지 항상 유의하라 팀 빌딩 프로세스를 계획하고 수행하라 Page  191

도구 및 기법 대인기술 교육 팀 구축 활동 기본규칙(Ground Rule) Co-location 평가 및 보상
소프트 기술(Soft Skill)이라고 한다 프로젝트 팀원의 정서를 이해하고, 팀원의 행동을 예견하고, 관심사를 살피고, 문제에 대한 후속처리를 지원한다 공감대, 영향력, 창의력, 결속력 조성 등.. 교육 프로젝트 팀원의 역량을 높이기 위해 고안된 모든 활동 팀 구축 활동 기본규칙(Ground Rule) 프로젝트 내의 약속 : 팀원의 공감대 형성에 매우 효과적이다 Co-location 프로젝트 팀원들의 대부분 또는 전원을 한 공간에 배치함으로써 수행 능력을 높이는 방식 (동일장소배치) 평가 및 보상 공정한 평가 및 성과 보상 Page  192

팀 개발 5단계 개발이론 형성(Forming) 스토밍(Storming) 표준화(Norming) 수행(Performing)
팀이 모여서 프로젝트 자체, 각자의 공식적인 역할, 책임사항에 대해 파악하는 단계 팀원들이 독자적이며 개방적이지 않은 경향이 있다 스토밍(Storming) 팀이 프로젝트 작업, 기술적 의사결정, 프로젝트 관리 방식을 다루는 단계 팀원들이 다른 사고와 관점에 협조적, 개방적이지 않다 표준화(Norming) 팀원들이 협력하고 팀원 지원하는 행동과 작업 습관을 조율하는 단계 팀원들이 서로 신뢰하기 시작한다 수행(Performing) 팀원들이 상호 의존적이며, 원활하고 효과적으로 문제를 해결하는 단계 해산(Adjourning) 팀이 작업을 완료하고 프로젝트에서 이동하는 단계 Page  193

9.4 프로젝트 팀 관리 프로젝트 성과를 최적화하기 위하여 팀원의 성과를 추적하고, 피드백을 제공하며, 이슈를 해결하고, 변경을 관리하는 프로세스 팀원 교체 전체 팀워크를 해치는 팀원은 교체 검토 팀원 교육 주어진 역할을 수행하기 위한 기술이 부족하면 필요한 교육 실시 갈등 해결 개인적인 갈등 및 동기부여가 되지 않은 팀원 마음관리 계획 변경 일정이나 예산과 관련된 계획 변경 Page  194

도구 및 기법 관찰 및 대화 프로젝트 성과 평가 갈등 관리 이슈 로그 프로젝트 팀원의 작업과 태도를 지속적으로 살핌
역할 및 책임사항 규명, 피드백 제공, 이슈발견, 개개인의 교육계획 개발, 미래준비 등 갈등 관리 이슈 로그 팀의 목표 달성에 방해가 될 수 있는 장애물 제거 대인 기술 Page  195

갈등의 원인 구분 Conceptual Planning Implementation Close 주요업무 목표설정 범위확정
공식적인 권한체계 Teaming - WBS Make/Buy 결정 정보통제시스템 계약관리 문제식별 재계획 목표수정 상황의 유지 운영문제 평가 및 보상 인원 재조정 주요 갈등 순위 - priority 관리 절차 일정 인력 기술적 옵션 대인관계 priority 원가 관리절차 Page  196

갈등 해결 기법 기법 내용 Forcing Problem Solving Compromising Withdrawing
긴급하게 결정하여야 할 경우 인기가 없는 주요 정책을 집행할 때 옳다고 믿는 주요 안건을 집행할 때 Problem Solving -매우 중요한 통합된 의견을 도출할 때 남들의 의견을 들을 필요가 있을 때 공감대를 형성하여 지속적인 관계유지가 필요할 때 Compromising -모든 관련당사자가 일정 수준 만족하는 해결책을 모색할 때 상호배타적인 목표를 가진 지단들이 비슷한 파워를 가지고 있을 때 더 이상 설득이 힘들다고 느낄 때 Withdrawing -이슈가 사소할 때 추가 정보 수집이 필요할 때 자기 의견을 관철시킬 가능성이 낮다고 판단될 때 Smoothing -자기의 의견이 틀렸다고 느끼고 합리성이 있다는 것을 보여줄 때 조화와 안정성이 매우 중요할 때 이슈가 다른 그룹에게 보다 중요한 사안일 때 Smoothing Problem Solving 의견 수용 Compromising Withdrawing Forcing 의견 관철 Page  197

프로젝트 관리자의 파워 프로젝트를 올바른 방향으로 팀원을 움직일 수 있는 프로젝트 관리자의 능력 Position Power
프로젝트를 올바른 방향으로 팀원을 움직일 수 있는 프로젝트 관리자의 능력 Position Power Formal Power 공식적인 지위로부터 나오는 파워 Penalty Power 팀원에게 불이익을 줄 수 있는 권한을 통해 팀을 통제하는 방법 Reward Power 승진·급여인상 등 팀원에게 보상을 기대하게 하여 통솔하는 방법 Personal Power Referent Power PM이 가진 성품이나 인격을 팀원들이 따르고 존경하는 데에서 발생하는 파워 Expert Power PM의 전문성에서 발생하는 파워 Page  198

인적자원관리(Summary) 프로젝트 팀 개발과 팀 관리 프로세스 비교 항목 프로젝트 팀 개발 프로젝트 팀 관리 프로세스 그룹
실행(Executing) 내용 프로젝트 생산성 향상을 위해 팀원들의 역량과 협업, 효율성을 증대시키는 것 프로젝트 생산성을 향상하기 위해 팀원들의 생산성을 측정하고, 피드백을 제공하며, 이슈를 해결하고 변경을 관리하는 프로세스 기법 -대인관계 기술 -교육 -팀 빌딩 액티비티 -Ground Rules Co-location 성과보상 -관찰과대화 -프로젝트 성과평가 -갈등관리 -이슈로그 산출물 -팀 생산성 평가 -요청된 변경 -요청된 시정조치 -요청된 예방활동 -프로젝트 관리 계획서 업데이트 키워드 -역량강화 -생산성 평가 Page  199

인적자원관리(Summary) 동기부여 이론 매슬로 이론(Maslow’s theory) 자아충실, 성장, 학습
성취, 존경, 감사 사랑, 친구, 사교 안전, 안정 의식주 자아실현 (Self Actualization) 자아(Esteem) 생리(Physiological) 사회(Social) 안전(Safety) Page  200

인적자원관리(Summary) 동기부여 이론 허즈버그 이론(Herzberg’s theory) 위생요인 동기요인
불만을 발생시키는 요인으로 만족을 유발시키지는 못함 만족을 유발시키는 요인, 불만을 유발시키지는 않음 -급여 -기술적 감독 -회사의 정책과 행정 -인간관계 -작업조건 -개인 생활 요소 -직위 -직장의 안정성 -성취감 -칭찬이나 인정을 받을 수 있는 기회 -직무 자체가 주는 흥미 -성장 가능성 -책임감 -직무의 도전성 -발전성 Page  201

인적자원관리(Summary) 동기부여 이론 맥그리거(McGregor)의 X이론,Y이론 X이론 Y이론
보편적으로 사람들은 일을 싫어하고 할 수 있으면 피하려고 한다 조직의 목적을 달성하기 위해서는 사람들을 벌주거나 위협해야 한다 사람은 책임을 회피하고 공식적인 지시에만 따르려 한다 사람들은 작업과 연관된 요인들 중 안정성을 가장 중요하게 생각하고 욕심이 없다 -보편적으로 사람들은 일을 즐긴다 -사람들은 조직의 목적을 위해 외부의 통제나 위협이 없어도 자기 통제와 자기 방향성을 수립한다 -사람들은 대개 책임감을 추구하고 받아 들인다 -합리적인 의사결정을 위한 능력은 보통의 사람에게 널리 퍼져있는 능력으로 관리자만 보유하고 있는 능력이 아니다 -X이론은 감시와 위협을 통해 직원들을 관리한다 -생산성 저하, 신바람 나는 업무문화 형성과 거리가 멀다 -Y이론은 생산성 향상, 만족도 증가, 신뢰하는 업무문화가 형성된다 Page  202

인적자원관리(Summary) 계층구조도 항목 설명 예 WBS OBS RBS 제품이나 프로젝트 범위를 분할한 계층구조
(Work Breakdown Structure) 제품이나 프로젝트 범위를 분할한 계층구조 OBS (Organizational Breakdown Structure) 팀, 부서 등 프로젝트 수행조직으로 분할한 계층구조 RBS (Resource Breakdown Structure) 자원의 종류나 기술로 분할한 계층구조 학사관리 수강관리 입학관리 졸업관리 프로젝트조직 인사부 총무부 영업부 팀원의 역할 PL 분석/설계 아키텍트 Page  203

10. 프로젝트 의사소통관리 10.1 이해관계자 식별 10.2 의사소통 계획수립 10.3 정보 배포 10.4 이해관계자 기대사항 관리 10.5 성과 보고 Page  204

10.1 이해관계자 식별 프로젝트에 영향을 받는 모든 사람 또는 조직을 식별하여 각각의 이해사항, 관여도, 프로젝트의 성공에 미치는 영향력에 관한 정보를 문서화하는 프로세스 의사소통 활동에는 다음을 포함한다 내부적(프로젝트 내부) 및 외부적(고객, 기타 프로젝트, 매체, 일반 대중) 공식(보고서, 메모, 요약서) 및 비공식(이메일, 특별 논의록) 수직적(조직의 상하관계) 및 수평적(동료관계) 공식적(뉴스레터, 연례보고서) 및 비공식적(비공개 대화 내용) 서면 및 구두 언어적 및 비언어적(음성의 억양, 몸짓) Page  205

의사소통 기량 적극적이고 효과적인 청취 정확한 이해를 위해 아이디어 및 상황에 대한 질문과 탐색
팀의 지식 수준을 높여 효율을 개선할 수 있도록 교육 정보의 식별 또는 확증을 위한 사실 확인 이해관계자 기대사항 설정 및 관리 조치를 수행하기 위해 개인 또는 조직 설득 관련 당사자들간에 수용 가능한 합의에 도달하기 위한 협상 파괴적 영향을 방지하기 위한 갈등 해결 다음단계 식별/요약 및 정리 Page  206

도구 및 기법 이해관계자 분석 프로젝트 전반에 대하여 이해사항을 고려해야 하는 관련자들을 결정하기 위해 정성적 및 정량적 정보를 체계적으로 수집하고 분석하는 프로세스 1단계 : 모든 잠재적 프로젝트 이해관계자 및 관련정보 식별(면담) . 이해관계자들의 역할, 부서, 관심사항, 지식수준, 기대사항 및 영향 2단계 : 접근 전략을 정의할 수 있도록 각 이해관계자의 점재적 영향력 또는 지원 범위를 식별하여 분류 . 각자의 권한(권력) 수준 및 프로젝트 결과물에 관한 관심사항(관심도) 정도에 따라 이해관계자들을 그룹으로 분류하는 권력/관심도 도표 . 프로젝트에서 권한 수준 및 적극적 참여도에 따라 이해관계자들을 그룹으로 분류하는 권력/참여도 도표 . 프로젝트에 적극적 참여도 및 프로젝트의 기획 또는 실행 관련 변경에 영향을 미칠 수 있는 능력에 따라 이해관계자들을 그룹으로 분류하는 참여도/영향력 도표 . 권력(의도한 바를 강행하는 능력), 긴급도(즉각적인 주의 필요성) 및 적합성(적절한 참여 여부)에 기초하여 이해관계자 그룹을 설명하는 현저성 모델 3단계 : 이해관계자의 지원을 증대하고 잠재된 부정적 영향을 줄일 수 있도록 주요 이해관계자들이 다양한 상황에 반응하거나 응답하는 방법을 평가 Page  207

도구 및 기법 전문가의 판단 해당 분야 관련 전문 교육을 이수 했거나 지식을 갖춘 그룹 또는 개인으로부터 판단력과 전문성을 구함 최고 경영진 조직내부의 다른 단위 식별된 주요 이해관계자 동일한 분야에서 프로젝트를 수행한 경험이 있는 프로젝트 관리자 비즈니스 또는 프로젝트 영역에서 해당 주제 전문가(SME : Subject Matter Expert) 산업단체 및 컨설턴트 전문가 및 기술협회 Page  208

10.2 의사소통 계획수립 프로젝트 이해관계자의 정보 요구사항을 식별하고 의사소통방식을 정의하는 프로세스
프로젝트 이해관계자의 정보 요구사항을 식별하고 의사소통방식을 정의하는 프로세스 의사소통 계획수립 시 고려할 사항 어떤 정보를 언제 수집할 것인가? 누가 이 정보를 받을 것인가? 수집된 정보를 어떻게 취합하고 저장할 것인가? 누가 정보를 취합하고 분석할 것인가? 보고체계는 어떻게 정의할 것인가? 정보의 배포시점(배포주기)은 어떻게 할 것인가? Page  209

도구 및 기법 의사소통 요구사항 분석 프로젝트 이해관계자의 정보 요구사항 판별 의사소통 요구사항을 결정하는 일반적인 정보
조직도 프로젝트 조직 및 이해관계자 책임관계 프로젝트 관련 전문분야, 부서 및 특수분야 프로젝트 관련 인원수 및 장소에 대한 세부계획 내부 정보 요구 사항(예 : 조직간 상호 의사소통) 외부 정보 요구 사항(예 : 매체, 대중 또는 계약자와의 의사소통) 이해관계자 등록부의 이해관계자 정보 및 이해관계자 관리 전략 의사 소통 채널 수 -프로젝트 관리자 또는 프로젝트 의사소통의 복잡성을 나타내는 척도 -N(N-1)/2, N : 전체 이해관계자 수 이해관계자가 10명인 프로젝트의 잠재적 의사소통 채널은 45개(10(10-1)/2=45)이다 Page  210

도구 및 기법 의사소통 기술 프로젝트 이해관계자들간 정보 전달에 사용하는 방법(예:문서, 회의, 온라인 매체 등)
프로젝트에 영향을 미칠 수 있는 요소 정보 요구의 긴급성 프로젝트의 성공이 즉각적인 통보에 활용할 수 있도록 자주 갱신되는 정보에 좌우되는지 혹은 정기적으로 발행하는 서면 보고서 만으로도 충분한지 여부 기술의 가용성 이미 적용된 시스템이 적절한지 또는 프로젝트 요구사항으로 인해 시스템의 변경이 타당한지 여부 예상 프로젝트 팀원 제안된 의사소통 시스템이 프로젝트 참여자들의 경력 및 전문성에 적합한지 또는 집중적인 교육 및 학습을 요구하는지 여부 프로젝트 기간 사용할 수 있는 기술이 프로젝트가 끝나기 전에 변경될 가능성이 있는지 여부 프로젝트 환경 프로젝트 팀원이 한곳에 모여 진행하는지 또는 가상환경에서 작업하는지 여부 Page  211

도구 및 기법 의사소통 모델 발신자와 수신자로 정의되는 두 대화자 사이에 정보를 주고 받는 방법
Encode(암호화) : 생각이나 아이디어를 다른 사람들이 이해할 수 있는 언어로 변환하는 것 Message 및 Feedback: Encoding의 결과 Medium : Message를 전달하는 방법(매체) Noise : Message의 전송 및 해석과 이해를 방해하는 모든 것 Decode(복호화) : Message를 의미 있는 생각이나 아이디어로 변환하는 것 Page  212

도구 및 기법 의사소통 방법 대화식 의사소통(Interactive communication)
-둘 이상의 대화 당사자가 여러 방향으로 정보 교환을 수행하는 방식 -특정 주제에 대해 모든 참여자의 일반적인 이해를 이끌어내는 가장 효율적인 방법(미팅, 전화통화, 화상회의 등) 전달식 의사소통(Push communication) -정보를 알 필요가 있는 특정 수신자들에게 전송하는 방식 -정보가 배포되지만 의도한 수신자에게 실제 도달했는지 또는 수신자들이 이해했는지는 분명하지 않은 방법 (편지, 메모, 보고서, 이메일, 팩스, 음성메일, 보도자료 등) 유인식 의사소통(Pull communication) -대용량 정보 또는 대규모 수신자 그룹에 사용하는 방식 -수신자들이 의사소통 내용에 대해 자기자신의 재량으로 접근해야 한다(인트라넷 사이트, 온라인 학습 및 지식 저장소 등) Page  213

의사소통계획서 이해관계자 의사소통 요구사항 언어, 형식, 내용, 상세, 수준을 포함하여 전달할 정보 정보의 배포사유
필요한 정보의 배포 시간대 및 주기 정보 전달을 책임지는 담당자 기밀 정보 공개의 승인을 담당하는 책임자 정보를 수신할 개인 또는 그룹 메모, 이메일, 보도자료 등과 같이 정보를 전달하는데 사용되는 방법 또는 기술 시간 및 예산을 포함하여 의사소통 활동에 할당된 자원 하부 직급에서 해결할 수 없는 이슈의 상부 보고에 관한 시간대 및 관리자를 식별하는 상부 보고 프로세스 프로젝트가 진행되고 전개됨에 따라 의사소통 관리 계획서를 갱신 및 개정하는 방법 일반적인 용어 정리집 일반적으로 특정 법규 또는 규제, 기술 및 조직 정책 등에서 파생되는 의사소통 제약사항 Page  214

10.3 정보배포 프로젝트 이해관계자가 계획된 대로 관련 정보를 사용할 수 있도록 하는 프로세스 효과적인 정보배포 기법들
프로젝트 이해관계자가 계획된 대로 관련 정보를 사용할 수 있도록 하는 프로세스 효과적인 정보배포 기법들 발신자-수신자 모델 : 피드백 고리 및 의사소통 장애물 매체의 선택 : 기술방식(서면 또는 구두), 작성할 양식(비공식적 메모 또는 공식적 보고서) , 의사소통 수단(대면방식 또는 이메일 방식) 등 상황에 따라 결정 문체 : 능동태 또는 수동태 기술방식, 문장 구조 및 어휘 선택 회의관리 기법 : 회의록 준비 및 갈등처리 발표기법 : 몸짓 및 표정, 시각 자재 설계 촉진기법 : 합의도출 및 장애극복 Page  215

매체선택 구분 문서(Written) 구두(Verbal) 공식(Formal) 주요 계약 관련 프로젝트 계획 프로젝트 차터
실적 보고서 복잡한 문제해결 착수회의· 종료회의 PT 발표 비공식(Informal) - 메모 전자우편 면담 회의 사적인 대화 Page  216

도구 및 기법 의사소통 방법 정보 배포 도구 개인 및 그룹 미팅, 화상 및 음성 회의, 컴퓨터 채팅 및 원격 의사 소통 방법
출력한 문서 배포, 수작업 서류철 시스템, 언론보도 및 공용 전자 데이터베이스 이메일, 팩스, 전화, 화상회의 등 전자방식 의사소통 및 회의 도구 프로젝트관리시스템(PMS), 프로젝트관리 도구 Page  217

효과적인 미팅 미팅의 절차를 사전에 결정하라 정말로 필요할 때에만 미팅을 소집하라(의사결정, 토론)
미팅의 목적을 명확하게 해라 회의의 주제를 사전에 준비해라 회의 주제에 따라 진행하라 팀원의 참여를 적극 권장해라 모든 미팅을 팀 빌딩의 일환으로 생각하라 회의 결과를 정리하고 참석자에게 배포하라 Page  218

10.4 이해관계자 기대사항 관리 이해관계자들과 의사소통 및 협력을 통해 이해관계자의 요구사항을 충족시키고 발생하는 이슈를 처리하는 프로세스 다음과 같은 의사소통 활동이 포함된다 프로젝트 목표를 달성 및 유지할 수 있도록 이해관계자의 요구사항을 협상 및 조율함으로써 프로젝트 수락 확률을 높이는 방향으로 이해관계자의 기대사항을 적극적으로 관리한다 아직 이슈가 되지 않았지만 대개 앞으로 문제가 될 것으로 예상되는 우려사항을 처리한다. 이러한 우려사항은 공개하여 토론해야 하며 리스크도 평가해야 한다 식별된 이슈를 명확히 규명하고 해결한다. 해결책에 따라 변경요청이 발생하거나 프로젝트 외부에서 처리해야 할 문제도 있다. (다른 프로젝트 또는 단계를 위해 지연되거나 다른 조직으로 위임된 경우) Page  219

10.5 성과보고 현황보고서, 진행측정치, 예측치 등을 포함한 성과 정보를 수집하고 보고하는 프로세스 성과보고서의 유형
현황보고서, 진행측정치, 예측치 등을 포함한 성과 정보를 수집하고 보고하는 프로세스 성과보고서의 유형 Status Report : 프로젝트의 현재 상태에 대한 정보 Progress Report : 프로젝트의 과거부터 현재까지의 성과추이 정보 Forecasting Report : 미래의 프로젝트 상황과 성과에 대한 예측보고서 Variance Report : 계획대비 실적에 대한 차이 보고서 성과보고서 작성시 유의사항 “지난달에 무엇을 하였고, 이번 달에 무엇을 할 것인가” 보다 “지금 프로젝트의 상태가 어떠하다”는 식으로 정보를 표현 한다 보고 대상에 따라 내용을 차별화하는 것이 바람직하다(비용 대비 효과 고려) 텍스트보다 그래프나 숫자로 표현 한다 지금까지의 방향과 향후 예측이 가능해야 한다 Page  220

성과보고서에 포함되어야 할 내용 과거 성과 분석 리스크 및 이슈의 현재 상태 해당 기간에 완료된 작업 완료할 다음 작업
해당 기간에 승인된 변경 요약 검토 및 논의해야 할 기타 관련 정보 Page  221

도구 및 기법 차이분석 예측방법 기준선과 실제 성과 사이의 차이를 유발한 원인을 밝히기 위한 추후 검토활동
시계열 기법(Time series method) 향후 산출물을 예측하는 기준으로 선례자료를 활용한다(예:획득가치, 이동평균, 선형예측) 인과/계량경제 기법(Causal/Econometric method) - 가능한 가정을 토대로 예측하는 변수에 영향을 미칠 수 있는 기본적인 요인 식별 판단기법 - 직관적인 판단력, 견해, 확률 예상치를 통합(복합예측, 설문조사, 델파이 기법, 시나리오 구축) 기타기법 - 시뮬레이션, 확률적 예측 등 Page  222

성과 보고서(예:dashboard 형식)
Page  223

성과 보고서(예:정성적 형식) 항목 Status 현황 및 대응방안 요구사항 안정성 Read -요구사항 변경 및 추가요구
-변경 시 현업에서 전체 일정 및 품질에 대한 보장이 어렵다는 점을 충분히 인지함 고객 만족 Yellow -개발 일정에 다소 우려감을 갖고 있음 -특히 짧은 테스트 기간에 따른 테스트 품질저하를 우려하고 있음 고객 참여 -고객의 적극적인 참여, 개발자에 대한 지원은 보통 수준임 -인수인계에 대한 부분은 해당 단계에서 협의 예정 외부 사항 Red -고객 담당자의 변경이 잦은 설계 변경의 원인이 되고 있음 -외부 기관으로부터의 업무 요건 변경이 지속적으로 발생하고 있음 인원 변경 -투입된 인력의 업무 적응 기간을 고려할 때 인원 변경은 일정에 심각한 영향을 미침 -투입 인력에 대한 프로젝트 관리층의 지속적인 관심 필요 Page  224

성과 보고서(예:표 형식) Page  225

의사소통관리(Summary) SI 프로젝트의 다양한 이해관계자들 요구사항 프로젝트 팀 착수 종료 부서 공급자측 이해관계자
프로젝트가 성공적으로 종료할 수 있도록 다양하고 때로는 상충되는 이해관계자들의 정보 요구사항을 파악하여 필요한 정보를, 필요한 시점에 필요한 형태로 제공 부서 공급자측 이해관계자 경영층 품질, 원가, 납기 준수 영업부서 고객만족, 후속 작업 창출 기술부서 품질 목표 달성 구매부서 싼 가격, 좋은 제품 구매 계약부서 불리한 계약 배제 품질부서 품질목표달성, 프로세스 준수 재무부서 수익성 확보 프로젝트 팀 품질목표, 납기 준수 프로젝트 팀 착수 종료 다양한 이해관계자의 요구사항 부서 수요자측 이해관계자 경영층 시스템의 투자효과 달성 최종 사용자 -편리한 사용성 -유지보수의 용이성 확장성 프로젝트 결과에 영향을 많이 받는 이해관계자 일수록 프로젝트 진행에 많은 영향력을 끼치려고 한다 Page  226

의사소통관리(Summary) 프로젝트 이해관계자 역할 중요성 전문 기술자 고객 인수 책임자 고객 최종 사용자 고객 최고 경영층
역할 중요성 고객 최종 사용자 고객 최고 경영층 사내 최고 경영층 의사결정에 미치는 영향력 Page  227

의사소통관리(Summary) 정보배포 / 성과보고 구분 구분 정보배포 성과보고 정의
프로젝트의 다양한 정보를 적절한 방법으로 이해관계자들에게 전달 모든 베이스라인 데이터 수집과 생산성 정보를 이해관계자들에게 전달 프로세스 그룹 실행(Executing) 통제(Monitoring & Controlling) 성격 공식/비공식 정보 전달 모두 포함 주기적/공식적인 정보의 전달 내용 프로젝트의 다양한 정보 프로젝트 성과정보 예 -보고서, 브리핑 등 공식적인 정보 -메모, 일상적 대화 등 비공식적인 정보 -요청에 대한 답변 -주간 성과보고 -월간 성과보고 -프로젝트 위험 현황 보고 Page  228

의사소통관리(Summary) 의사소통 채널 수 팀원이 5명에서 10명이 추가 된 경우
15(15-1)/2 – 5(5-1)/2 = 95채널 팀원이 5명에서 10명으로 증가 한 경우 10(10-1)/2 – 5(5-1)/2 = 35채널 Page  229

실습 #7. 의사소통 기법 상황에 적합한 의사소통 기법 고르기(10분) Hand-out Page  230

11. 프로젝트 리스크관리 11.1 리스크관리 계획수립 11.2 리스크 식별 11.3 정성적 리스크 분석 11.4 정량적 리스크 분석 11.5 리스크 대응계획 수립 11.6 리스크 감시 및 통제 Page  231

11 프로젝트 리스크관리 프로젝트에 대한 리스크의 관리 기획, 식별, 분석, 대응 기획, 감시 및 통제를 수행하는 프로세스
프로젝트에 대한 리스크의 관리 기획, 식별, 분석, 대응 기획, 감시 및 통제를 수행하는 프로세스 Known Risk vs Unknown Risk 구분 Known Risk Unknown Risk 위험 사전에 식별되고 분석된 위험 사전에 식별되지 않은 위험 식별 가능 불가능 분석 예방계획 예비비 편성 Contingency Reserve Management Reserve 예비비 집행 Cost Baseline에 포함되며 PM재량으로 집행 Cost Baseline에 포함되지 않으며 PM재량으로 집행할 수 없음 예비비 산정 발생 가능성과 영향력의 기대값으로 계산 전체 예산의 일정 비율로 산정 Page  232

위험관리 용어 위험원인(Risk Source) 위험(Risk) 영향력(Impact) 검증되지 않은 아키텍처 채택 설계 방식
-시스템 성능 -납기 -원가 등 프로젝트 수행을 위한 사전 승인 필요 승인 여부 및 승인일자 -원가 Page  233

11.1 리스크관리 계획수립 프로젝트에 대한 리스크관리 활동의 수행 방법을 정의하는 프로세스 리스크관리 프로세스 리스크관리
건강관리 건강관리 계획수립 이상징후 식별 상세 건강진단 처방 조치 진단 및 마감 리스크관리 리스크관리 계획수립 리스크 식별 리스크 분석(정성적/정량적) 대응계획 수립 대응계획 이행 모니터링 및 통제 Page  234

리스크관리 계획서(산출물) 방법론:리스크 관리를 수행하는데 사용할 수 있는 접근방식, 도구 및 자료의 출처 정의
역할 및 책임사항:리스크관리 계획서에 각 활동 유형별 리더, 지원 및 리스크 관리 팀원을 정의하고 책임 사항 명시 예산 책정:리스크관리에 필요한 원가 성과 기준선에 포함시킬 자원, 산정치 자금을 할당하고 우발 사태 적용 규약 제정 시기:프로젝트 생애주기에 걸쳐 리스크관리 프로세스의 수행시기 및 빈도 정의 리스크 범주:위험을 식별할 때 활용할 위험요소(체크리스트)를 유형별로 정리한 것 (RBS: Risk Breakdown Structure) 리스크 확률 및 영향:정성적 리스크 분석 수행 프로세스의 정확성과 신뢰도를 확보하기 위해서 리스크의 발생 확률과 영향의 다양한 수준 정의 확률-영향 매트릭스:프로젝트 목표에 미칠 영향과 잠재적인 연관성에 따라 우선순위 부여 보고형식:리스크 관리 프로세스의 결과물을 문서화, 분석 및 전달하는 방법을 정의하고, 필요한 기타 리스트 보고서 및 리스크 등록부의 내용 및 형식 기술 추적:현재 프로젝트의 이점, 향후 요구사항 및 습득한 교훈에 대해 리스크 활동을 기록하는 방법 과 리스크관리 프로세스의 감사 방법 문서화 Page  235

리스크 분류 체계(RBS)(예) Page  236

프로젝트 목표에 대한 영향력 척도 정의(예) Page  237

11.2 리스크 식별 프로젝트에 영향을 미칠 수 있는 리스크를 결정하고, 리스크별 특성을 문서화하는 프로세스
프로젝트에 영향을 미칠 수 있는 리스크를 결정하고, 리스크별 특성을 문서화하는 프로세스 리스크 발생 가능성과 처리비용 관계 프로젝트 라이프 사이클 발생비용 리스크 수준 높음 낮음 리스크 발생시 처리비용 리스크 수준 Page  238

리스크 식별 시 고려사항 누가 식별할 것인가? 언제 식별할 것인가? 몇 차례에 걸쳐서 식별할 것인가? 어떻게 식별할 것인가?
프로젝트와 관련된 이해관계자 모두 언제 식별할 것인가? 프로젝트 시작할 때부터 끝날 때까지 식별, 착수 및 계획수립 단계에서 리스크 식별 가장 중요 몇 차례에 걸쳐서 식별할 것인가? 한번에 끝날 수도 있고 여러 차례에 걸쳐 수행할 수 있다 어떻게 식별할 것인가? 문서검토(Documentation Review) 델파이 기법(Delphi Technique) 체크리스트 분석(Checklist Analysis) 가정분석(Assumptions Analysis) 식별된 리스크를 어떻게 기록할 것인가? 원인(사실)과 위험(예상)을 구분하여 기록한다 복합적인 리스크는 나누어 기록한다 각각의 리스크는 고유한 ID를 부여한다 Page  239

도구 및 기법 문서검토(Documentation Review) 브레인스토밍(Brainstorming)
프로젝트 관리계획서, 가정사항, 이전 프로젝트 파일, 계약서 및 기타 정보를 포함한 프로젝트 문서에 대해 조직적인 검토 브레인스토밍(Brainstorming) 다양한 분야의 전문가들과 함께 진행자의 안내에 따라 참여자가 제안한 아이디어 또는 명목그룹 기법과 같은 집단 인터뷰 기법을 사용하여 구성된 아이디어를 놓고 자유 토론하는 전통적인 방식 델파이 기법(Delphi Technique) 전문가의 합의에 도달하는 방식(전문가 참여, 익명 인터뷰(우편,전자우편), 반복적인 토의, 근본 원인 분석, 합의 도출) 체크리스트 분석(Checklist Analysis) 각 조직에 축적된 리스크 식별 체크리스트나 각종 책자에 발표된 체크리스트를 활용하여 위험을 식별하는 방법 가정분석(Assumptions Analysis) 프로젝트 계획을 수립할 때 세운 여러 가지 가설, 시나리오 또는 가정사항을 근거로 식별하는 방법 SWOT 분석 SWOT(강점(strength)과 약점(weakness), 기회(opportunity)와 위협(threat) ) 기법을 통한 분석 Page  240

11.3 정성적 리스크 분석 리스크의 발생 확률과 영향을 평가하여 통합함으로써, 추가적인 분석이나 조치에 유용하도록 리스크 우선순위를 지정하는 프로세스 리스크 우선순위 결정요소 발생 가능성 해당 리스크 요소가 실제로 발생할 가능성 영향력 해당 리스크가 발생했을 때 프로젝트 성공에 미치는 영향 리스크 노출도 발생 가능성 x 영향력 Page  241

확률-영향력 매트릭스(예) 0.90 0.05 0.09 0.18 0.36 0.72 0.70 0.04 0.07 0.14 0.28 0.56 0.50 0.03 0.10 0.20 0.40 0.30 0.02 0.06 0.12 0.24 0.01 0.08 0.80 Page  242

프로젝트 목표에 미치는 리스크 영향력 정의(예)
Very Low .05 Low .1 Moderate .2 High .4 Very High .8 범위 영향 없음 일부 범위 영향 많은 범위 영향 고객에게 수용되지 않는 범위 축소 최종 납픔물의 가치가 없음 일정 지연 없음 지연 5% 이하 지연 5~10% 지연 10~20% 지연 20% 이상 원가 초과 없음 초과 10% 이하 초과 10~20% 초과 20~40% 초과 40% 이상 품질 일부 품질에 영향 품질목표 변경 시 고객승인 필요 고객이 수용할 수 없는 품질저하 예상 최종 결과물이 사용 불가할 정도로 품질이 낮음 Page  243

위험 노출도 등급분류(예) 영향력 L M H VL 발생 가능성 매우 높음 높음 보통 낮음 매우 낮음
매우 낮음 낮음 보통 높음 매우 높음 발생 가능성 Page  244

11.4 정량적 리스크 분석 식별된 리스크가 전체 프로젝트 목표에 미치는 영향을 수치로 분석 하는 프로세스 도구 및 기법
식별된 리스크가 전체 프로젝트 목표에 미치는 영향을 수치로 분석 하는 프로세스 도구 및 기법 민감도 분석(Sensitivity analysis) 여러 가지의 원인변수 X1, X2, X3,…….Xn 중에서 임의의 한 변수를 제외한 다른 변수값은 고정시킨 상태에서 그 한 변수의 값을 한 단위씩 변경할 때 결과 변수 Y가 어떻게 변하는지를 분석하는 기법 -어떤 리스크가 프로젝트에 가장 큰 영향을 미치는가를 분석하고자 할 때 활용할 수 있다 의사결정나무분석(Decision tree analysis) 불확실한 프로젝트 상황에서 의사결정의 내용에 따라 프로젝트 성과가 어떤 영향을 받는가를 분석하는 것 모델링 및 시뮬레이션 몬테카를로(Monte Carlo) 기법 -일정, 원가의 불확실성을 분석할 때 활용 -난수표를 여러 번 생성하여 프로젝트 결과를 시뮬레이션 하는 도구 Page  245

의사결정 나무 분석(예) Decision Node Change Node 확률 Net Path Value EMV
재활용 컴포넌트를 고려한 개발 ( A) (수주 6억, 개발원가 5억) 유사사업 경기활성 30% 매출이익 10억 ? 유사사업 경기불황 70% 매출이익 0.5억 재활용 컴포넌트를 고려하지 않은 개발 ( B) (수주 6억, 개발원가 3억) 매출이익 2억 매출이익 0.2억 EMV ( Expected Monetary Value) : 예상 기대값, 즉 발생가능한 경우의 수에 대한 기대값 (수주금액 - 개발원가) + ( 확률 * 매출이익 ) = EMV A : (6억 – 5억) + (( 0.3 * 10억) + ( 0.7 * 0.5억)) = 4,35억 B : (6억 – 3억) + ((0.3 * 2억) + ( 0.7 * 0.2억)) = 3.74억 ※ 효용이론(utility theory) : 의사결정자의 위험에 대한 선호도에 따라 의사결정이 달라지는 것 Page  246

EMV 계산하기 동전을 두 번 던져 앞면이 계속 나오면 $2,000를 받고 그렇지 않으면 $1,000를 잃게 된다. EMV는 얼마인가? 앞 뒤 0.5 $2,000 -$1,000 Ⓐ Ⓑ Ⓑ EMV = (0.5 * $2,000) + (0.5 * -$1,000) = $1, $500 = $500 Ⓐ EMV = (0.5 * $500) + (0.5 * -$1,000) = $ $500 = -$250 Page  247

11.5 리스크 대응계획 수립 프로젝트에 대한 기회는 증대시키고 위협은 줄이기 위한 대안과 조치를 개발하는 프로세스
프로젝트에 대한 기회는 증대시키고 위협은 줄이기 위한 대안과 조치를 개발하는 프로세스 대응계획 수립 시 유의사항 리스크는 제거하는 것이 아니다 모든 리스크에 대하여 대응하는 것이 아니다 리스크는 상호 연계되어 있다 리스크는 변한다 비용대비 효율적이어야 한다 대응계획 수립시기를 놓쳐서는 안 된다 프로젝트 상황에서 실현할 수 있는 현실적인 계획이어야 한다 대응계획에 대하여 이해관계자들의 합의를 얻어야 한다 Page  248

위협 및 기회에 대한 대응전략 구분 전략 정의 예 위협 기회 공통 (Threat) 회피 (Avoid)
-위협을 완전히 제거하기 위해 프로젝트 관리 계획서를 변경하는 조치 -위험이 발생하지 않게 하는 것 -프로젝트 관리계획서 변경 -일정의 연장 -범위의 축소 전가 (Transfer) -위협으로 인한 부정적인 영향의 일부 또는 전부를 제3자에게 이전 -Insurance, Warranties -Fixed-price Contract(공급자에게 위험) -Cost-type Contract(수요자에게 위험) 완화 (Mitigate) -불리한 리스크 사건의 확률 또는 영향을 수용 가능한 한계로 낮추는 것 -프로토타입 개발 -추가적인 테스트 실시 -안정적인 공급자 선정 기회 (Opportunity) 활용 (Exploit) -불확실성을 줄여 기회가 확실히 실현되도록 하는 전략 -납기단축을 위해 뛰어난 인력을 프로젝트에 투입 -기존 계획 이상의 품질 제공 공유 (Share) -프로젝트에 유익할 기회를 가장 잘 포착할 수 있는 제3자에게 기회 소유권 일부 또는 전부를 할당하는 것 -인센티브 공유 -Joint Venture 증대 (Enhance) -기회의 확률 또는 긍정적인 영향을 증대시키기 위해 사용되는 전략 -기회의 발생 원인을 지원 -기회의 트리거를 식별하여 발생 가능성을 높이는 것 공통 수용 (Accept) 프로젝트에서 모든 위협을 제거하는 것이 절대 불가능할 때 기회 수용이 수반된다면 활용하지만 적극적으로 추진하지는 않는 것 -위협, 기회가 발생할 때까지 그대로 둠 Page  249

11.6 리스크 감시 및 통제 프로젝트 전반에서 리스크 대응 계획을 구현하고, 식별된 리스크를 추적하고, 잔존 리스크를 감시하고, 새로운 리스크를 식별하고, 프로세스 효과를 평가하는 프로세스 리스크 감시 및 통제 프로세스의 목적 프로젝트 가정사항의 유효성이 지속되는지 여부 평가된 리스크의 변경여부 또는 철회 가능성 여부 리스크 관리정책 및 절차가 준수되고 있는지 여부 현재의 리스크 평가 결과에 따라 원가 또는 일정에 대한 우발사태 예비를 수정해야 하는지 여부 신규 리스크의 발생여부 ※ Workarounds : 사전에 계획하지 않은 위험에 대한 계획 외 반응(Unplanned response) Page  250

리스크 모니터링(예) Risk ID 발생일자 진행단계 진척현황 완료일자 책임자 H M L M H L L M H RI001
테스트 환경 구축 완료 홍길동 RI002 개발서버 도입 지연 RI003 데이터 추출 툴 결정 홍길순 H M L M H L L M H Page  251

리스크관리(Summary) 리스크관리 프로세스 프로세스 명 내용 Output Input 리스크 관리계획 수립
프로젝트의 리스크관리 활동의 접근방식과 리스크관리 활동의 계획 및 실행 방법을 결정한다 -리스크 관리 계획 -기업환경요인 -조직프로세스자산 -프로젝트범위기술서 -프로젝트관리계획서 식별 프로젝트에 영향을 미칠 수 있는 리스크를 파악하며 리스크의 특성을 문서화한다 -리스크 기록부 -리스크관리계획 정성적 리스크 분석 리스크 발생확률과 그 영향을 평가하고 종합하여 세밀한 추가 분석이나 조치의 필요성 정도에 따리 리스크의 우선순위를 결정한다 -리스크 기록부(수정된) -리스크기록부 Page  252

리스크관리(Summary) 리스크관리 프로세스 프로세스 명 내용 Output Input 정량적 리스크 분석
식별된 리스크가 프로젝트의 목표 전반에 미치는 영향을 분석하여 그 결과를 수량으로 산출한다 -리스크 기록부(수정된) -조직프로세스자산 -프로젝트범위기술서 -프로젝트관리계획 -리스크기록부 -프로젝트관리계획서 리스크 대응 계획 긍정적 기회를 증대하고 프로젝트 목표를 위협하는 요소를 줄일 수 있는 옵션과 조치를 개발한다 -프로젝트관리계획서(수정된) -리스크관리계획 감시 및 통제 식별된 리스크를 추적하고, 잔존 리스크를 감시하고, 새로운 리스크를 식별하고, 리스크대응계획을 실행하고, 프로젝트 생애주기 전반에 걸쳐 리스크 대응 계획의 효율성을 평가한다 -리스크 등록(수정된) -변경요구서 -시정조치(권고된) -예방조치(권고된) -조직프로세스자산(수정된) -리스크등록 -변경요구(승인된) -작업성과정보 -성과보고서 Page  253

리스크관리(Summary) 리스크 우선순위 결정 : 발견적 방법 우선 순위 위험 속성 조치 영향 발생시점 발생확률 1 크다
리스크 우선순위 결정 : 발견적 방법 우선 순위 위험 속성 조치 영향 발생시점 발생확률 1 크다 가깝다 높다, 보통, 낮다 즉각적인 조치를 취한다 2 보통 추가적인 정보를 수집하고,세부 대응 계획을 작성하고, 필요한 경우 조치를 취하고, 지속적으로 감시한다 3 멀다 추가적인 정보를 수집하고, 대응 계획을 작성하고, 지속적으로 감시한다 4 필요한 경우 조치를 취한다 5 높다, 보통 대응 계획을 (재)작성하고, 지속적으로 감시한다 6 대응 계획을 작성하고, 정기적으로 감시한다 7 보통,멀다 낮다 정기적으로 감시하고, 다음 회의에서 재평가 한다 8 작다 9 정기적으로 감시한다 10 가깝다, 보통, 멀다 발생 후에 처리한다 Page  254

실습 #8. 위험관리 프로세스별 리스크 항목 도출(15분) Hand-out Page  255

12. 프로젝트 조달관리 12.1 조달 계획수립 12.2 조달 수행 12.3 조달 관리 12.4 조달 종료 Page  256

12.1 조달계획수립 프로젝트 구매 결정사항을 문서화하고 조달방식을 규정하며 잠재적인 판매자를 식별하는 프로세스
프로젝트 구매 결정사항을 문서화하고 조달방식을 규정하며 잠재적인 판매자를 식별하는 프로세스 외부에서 조달할 것인지의 여부 어떤 절차로 조달할 것인지 어떤 서비스나 제품을 조달할 것인지 어떤 가격으로 조달할 것이지 어떤 일정으로 조달할 것인지 등을 결정한다 Page  257

도구 및 기법 제작-구매 분석 전문가의 판단 계약 유형
특정 작업을 프로젝트 팀이 수행하는 것이 최상인지 또는 외부 공급자로부터 구매해야 할지 여부를 결정하기 위해 사용되는 일반적인 관리 기법 전문가의 판단 투입물과 산출물을 평가하기 위해 전문가의 기술적인 판단 필요 판매자를 평가하기 위한 기준 수립 제품 서비스 또는 결과물의 기술적 세부사항 수립 계약 유형 확정가 계약(Fixed Price Contracts) : 확정금액을 정의하는 계약형태, 업무가 명확히 정의되어 있을 때 적합 원가정산 계약(Cost Reimbursable Contracts) : 프로젝트 수행을 위해 사용한 원가 외에 적정한 이익을 보장하는 계약 형태 혼합형 계약(Time & Material Contracts) : 계약 시점에 전체 계약금액은 확정되지 않고 단위당 원가(예:인력단가)는 확정되어 있는 형태, 긴급하게 계약을 체결하여야 하는 경우 적합한 계약형태 Page  258

조달관리 계획서 계약의 유형 조달 관련 표준화 문서 공급업체 관리 계획된 조달에 영향을 미칠 수 있는 모든 제약 및 가정사항
활동 자원 산정 및 일정 개발 프로세스 프로젝트 리스크 완화를 위한 이행보증 또는 보험계약에 대한 요구사항 식별 WBS개발 및 유지관리에 관련하여 판매자에게 제시할 지시사항 설정 작업 조달/계약기술서에 사용할 양식 및 형식 설정 선별된 적격 판매자가 있을 경우 해당 판매자 식별 계약관리 및 판매자 평가에 사용할 조달지표 Page  259

계약 유형 원가정산 계약 혼합형 계약 확정가 계약
유형 : CPIF 내용 : 발생원가(간접비포함) + 확정이익(률) + 인센티브(해당시) 적용 . 업무범위가 불명확할 때 -유형 : T&M -내용 : 기본단가(확정)x발생시간(개수) -적용 : 원가정산과 확정가 계약의 혼합형태 -긴급하게 계약을 체결해야 하는 경우 -프로젝트 규모가 작을 때 -유형 : FPIF -내용 : 확정금액 + 인센티브(해당시) -적용 . 업무범위가 명확할 때 . 납기단축, 품질 우수시 인센티브 -유형 : CPPC(CPF), CPFF -내용 : 발생원가(간접비포함) + 확정이익(률) -적용 : 업무범위가 불명확할 때 비영리 기관과 계약시 -위험 : 수요자의 위험부담 가장 높음 -유형 : Fixed Price -내용 : 계약시 협의한 확정금액 -적용 : 업무범위가 명확할 때 -위험 : 공급자의 위험부담 가장 높음 인센티브 제공 인센티브 없음 원가정산 계약 혼합형 계약 확정가 계약 (Cost Reimbursable) ( Time & Material) (Fixed Price) CPIF : Cost Plus Incentive Fee CPFF : Cost Plus Fixed Fee CPPC : Cost Plus Percentage of Cost FPIF : Fixed Price Incentive Fee Page  260

유력한 판매자에게 제안서를 의뢰하기 위한 문서
조달문서 유력한 판매자에게 제안서를 의뢰하기 위한 문서 정보요청서(RFI : Request For Information) 입찰초대서(IFB : Invitation For Bid) 제안요청서(RFP : Request For Proposal) 견적요청서(RFQ : Request For Quotation) 입찰고지서(Tender Notice) Page  261

공급자 선정 기준 요구 조건에 대한 이해 전체원가 또는 생애주기 원가 기술적 역량 리스크관리 관리 접근방식 기술적 접근방식
보증 재정적 역량 생산능력 및 관심 사업규모 및 종류 판매자의 과거성과 참고자료 지적재산권 소유권 Page  262

12.2 조달수행 대상 판매자를 모집하고 판매자를 선정하고 계약을 체결하는 프로세스 도구 및 기법 입찰자 회의(사업설명회)
대상 판매자를 모집하고 판매자를 선정하고 계약을 체결하는 프로세스 도구 및 기법 입찰자 회의(사업설명회) 입찰서 또는 제안서를 제출하기에 앞서 판매자와 구매자가 참석하는 회의(기술 및 계약요구사항 전달, 질의 응답) 제안서 평가 기법 구매자의 조달정책에 따라 공식적인 평가 심의 프로세스 정의 독립산정 제안된 응찰에 대한 기준값으로 사용할 산정치를 산출, 외부 산정 전문가에게 산정 의뢰 전문가 판단(제안서 평가를 위한…) 광고 인터넷 검색 조달협상 Page  263

12.3 조달관리 조달관계를 관리하고 계약의 이행을 감시하고 필요한 사항을 변경·수정하는 프로세스 도구 및 기법
조달관계를 관리하고 계약의 이행을 감시하고 필요한 사항을 변경·수정하는 프로세스 도구 및 기법 계약 변경 통제 시스템 조달 성과 검토 검사 및 감사 성과 보고 기록관리시스템 클레임관리 Page  264

12.4 조달종료 각 프로젝트의 조달을 완료하는 프로세스(모든 작업 및 인도물이 수용 가능한지 확인 : 프로젝트 또는 단계종료) 도구 및 기법 조달감사 조달 계획 수립 프로세스로부터 조달관리에 이르기까지 조달프로세스를 체계적으로 검토하는 프로세스 협상타결 미결이슈, 클레임, 분쟁 등 기록관리시스템 PMIS(계약서, 조달문서), 자동화 툴 등 Page  265

조달관리(참조) 구매획득 및 계획(plan purchases and acquisitions)
수요자의 관점에서 외부 기업을 통해 특정 서비스나 제품을 확보하려는 계획을 수립하는 것 외부에서 조달할 것인지의 여부(whether to), 어떠한 절차로 조달할 것인지(how to), 어떤 서비스나 제품을 조달할 것인지(what to), 어떤 가격에 조달할 것인지(how much to), 어떤 일정으로 조달할 것인지(when to)를 포함한다 Page  266

조달관리(참조) 조달관리계획서 조달관리 계획은 조달 관련 문서를 개발할 때부터 계약이 종료될 때까지 조달 프로세스가 어떻게 관리되는지를 기술한다 사용할 계약 유형 평가 기준으로 개별 산정치가 필요한 경우 그러한 개별 산정치를 준비할 담당자 수행 조직에 조달부, 계약부 또는 구매부가 있는 경우 프로젝트 관리팀에서 전적으로 책임질 수 있는 작업 규격화된 조달 문서 (필요한 경우) 다수의 제공업체 관리 일정 관리 및 성과 보고와 같은 다양한 프로젝트 측면에 맞춰 조달 조정 계획된 구매 및 획득에 영향을 줄 수 있는 제약 및 가정 판매자로부터 구매하거나 획득하는 데 필요한 대기 시간을 다루고 프로젝트 일정 개발에 맞게 조정 제작-구매 의사결정을 다루고 활동 자원 산정 및 일정 개발 프로세스에 연결 계약 인도물에 대해 각 계약에서 예정된 날짜를 설정하고 일정 개발 및 통제 프로세스에 맞게 조정 Page  267

조달관리(참조) 조달관리계획서 프로젝트 리스크의 특정 형태를 완화하는 데 필요한 수행 약정서 또는 보험 계약서 식별
계약 작업분류체계를 개발 및 유지하는 데 있어서 판매자에게 제공될 지시 사항 수립 계약 작업기술서에 사용할 양식과 형식 설정 (사용해야 할 경우) 선정된 사전 유자격 판매자 식별 계약서를 관리하고 판매자를 평가하는 데 사용할 조달 측정기준 ※ 계약작업기술서(contract statement of work) - 각 계약작업기술서는 구매 또는 획득되는 품목에 대해 관련 계약 안에 포함되는 프로젝트 범위의 부분만을 Page  268

조달관리(참조) 계약 체결 계획(plan contracting)
제안요청서를 작성하고 업체선정을 위한 기준과 절차를 수립하는 것 조달문서 입찰초청서(invitation for bid), 제안 요청서(request for proposal), 견적 요청서(request for quotation), 입찰 고지서(tender notice), 협상 초청서(invitation for negotiation) 계약자 초기 응답(contractor initial response) Page  269

조달관리(참조) 제안요청서(request for proposal) 일반정보 범위 및 내용 계약서에 포함될 항목 및 조건
제안배경 기대효과 수행절차 제안서 가이드라인 평가기준 입찰 및 관련 서식 범위 및 내용 계약서에 포함될 항목 및 조건 Page  270

조달관리(참조) 제안요청서(request for proposal) 작성 장점 공급자의 제안 내용을 쉽게 비교할 수 있다
완성도 높은 제안서를 획득할 수 있다 정확한 가격을 결정할 수 있다 Page  271

조달관리(참조) 제안요청서(request for proposal) 평가 기준
요구에 대한 이해 : 판매자의 제안서에서 계약 작업 기술서를 얼마나 잘 다루고 있는가? 전체 또는 생애주기 원가 : 선정된 판매자가 최저 총 원가(구매원가+운영원가)를 산출하는가? 기술적인 능력 : 판매자가 필요한 기술적 기량 및 지식을 갖추고 있는가? 또는 (갖추고 있지 않을 경우) 충분히 획득할 수 있는가? 관리 접근방법 : 판매자가 프로젝트의 성공을 위한 관리 프로세스 및 절차를 갖추고 있는가? 또는 (갖추고 있지 않을 경우) 충분히 개발할 수 있는가? 기술적 접근방법 : 판매자가 제안된 기술적 방법론, 기법, 해결책 및 서비스가 조달관련 문서 요구사항을 충족하는가? 또는 예상 결과 그 이상을 제공할 것으로 생각되는가? 재정적 능력 : 판매자가 필요한 재무 자원을 가지고 있는가? 또는 (가지고 있지 않을 경우) 충분히 확보할 수 있는가? 생산 역량 : 판매자가 향후 잠재적 요구사항을 충족시킬 수 있을 만큼의 역량을 가지고 있는가? Page  272

조달관리(참조) 제안요청서(request for proposal) 평가 기준
사업 규모 및 유형 : 판매자의 회사가 구매자나 정부 기관이 계약 체결 조건으로 정의한 소사업자, 여성 사업자, 영세 소사업자 등 회사의 특정유형이나 규모 조건을 만족하는가? 참고 자료 : 판매자가 판매자의 작업 경험과 계약 요구사항에 부합됨을 입증하는 이전 고객으로부터의 참고 자료를 제공할 수 있는가? 지적 소유권 : 판매자가 자신들이 프로젝트에 대해 생산할 제품이나 사용할 작업 프로세스 또는 서비스에서 지적 소유권을 주장하는가? 소유권 : 판매자가 자신들이 프로젝트에 대해 생산할 제품이나 사용할 작업 프로세스 또는 서비스에서 소유권을 주장하는가? Page  273

조달관리(참조) 판매자 응답 요청(request seller response)
잠재 판매자로부터 프로젝트 요구사항을 어떻게 충족할 수 있는지에 대해 기술한 입찰서 및 제안서와 같은 응답문서를 획득하는 프로세스 판매자 응답요청 기법 입찰자 회의(bidder conference) – 입찰서 또는 제안서 작성 전에 잠재 판매자와 갖는 모임이다. 이 회의는 모든 잠재 판매자가 조달(예: 기술 요구 사항 및 계약 요구사항)을 명확하게 이해할 수 있도록 하기 위한 것이다 광고(advertising) – 신문과 같은 일반 출판물이나 전문저널지와 같은 전문 출판물에 사업을 광고함으로써 발주를 공식화 한다 유자격 판매자 목록 개발 – 우수업체 목록 Page  274

조달관리(참조) 판매자 선정(select sellers)
입찰서 또는 제안서를 받은 후 평가 기준을 적용하여(해당되는 경우) 자격이 있는 적절한 판매자를 선정하는 것이다 판매자 선정 기법 가중치 시스템(weighting system) – 판매자 선정에 미치는 개인 편견의 영향을 최소화하기 위해 사전에 정한 가중치에 따라 항목을 평가하는 방법 필터링 시스템(screening system) – 입찰에 참여할 수 있는 판매자의 최소 기준을 제시하여 부적합한 판매자를 사전에 배제하는 방법 예정가격 산정(independent estimates) – 업무 수행을 위한 적정가격(예정가격)을 사전에 도출하여 차이가 큰 업체를 배제하는 방법 판매자 등급 시스템(seller rating system) – 판매자의 과거 업무 수행실적, 품질등급 등을 평가하는 시스템 Page  275

조달관리(참조) 계약관리(contract administration)
판매자의 성과가 요구사항과 일치하고 구매자가 조항대로 수정하도록 하는 프로세스 계약방식 집중계약 방식 – 회사에서 구매 및 계약을 담당하는 부서를 지정하여 모든 프로젝트가 해당부서를 통해 구매하는 방식 분산계약 방식 – 프로젝트 관리자가 자신의 프로젝트 구매를 담당하는 방식 구분 집중계약 방식 분산계약 방식 장점 -전문가가 계약 진행 -여러 프로젝트의 계약을 통합 발주함으로써 가격 경쟁력 확보 -회사 전체의 계약을 통합관리 -프로젝트의 특수성을 반영한 계약 가능 -프로젝트 관리자가 계약을 통제 -신속한 계약 체결이 가능 단점 -구매 및 계약이 집중될 경우 시간이 많이 소요 -프로젝트의 특수한 요구사항을 반영하지 못할 수 있음 -비용이 높아질 수 있음 -자체적인 계약으로 인해 전문성이 떨어질 수 있음 Page  276

조달관리(참조) 계약종료(contract closure)
모든 작업 및 산출물이 인수 가능한지 검토하고 계약을 종료하는 프로세스 계약종료와 프로젝트 종료의 관계 계약종료는 각 계약 건 별로 실시하지만 프로젝트 종료는 프로젝트 차원에서 이루어진다 계약종료, 프로젝트 종료 모두 업무의 완료를 검증하고 검수하는 활동을 포함한다 계약종료 기법에는 조달 심사(procurement audit)가 포함되고 프로젝트 종료에는 전문가 판단(expert judgment)이 포함된다 프로젝트 종료 프로세스는 계약종료 절차와 행정종료 절차를 포함한다 Page  277

조달관리(참조) 조달관리 프로세스(SUMMARY) 프로세스 설 명
12.1 구매 획득 및 계획수립 12.2 업체선정 및 계획수립 12.3 제안서 제출 요청 12.4 공급자 선정 12.5 계약관리 12.6 계약종료 설 명 프로젝트 범위 가운데 외부에서 구매하거나 획득할 것의 내용, 시기, 가격 등을 결정하는 프로세스 공급자의 제안을 지원하기 위한 제안요청서(RFP)를 작성하고 공급자 선정 프로세스를 수립하는 프로세스 공급자로부터 제안서, 견적서를 확보하는 프로세스 제안서, 견적서에 기초하여 업무를 수행할 공급자를 평가하고 선정 하는 프로세스 공급자·수요자 쌍방간 계약사항 이행여부에 대한 관리 프로세스 계약범위 완료에 대한 최종 검수 및 행정처리를 수행하는 프로세스 조달계획 조달수행 조달관리 조달종료 Page  278

조달관리(참조) 공공 프로젝트 계약관리 프로세스 사업계획수립 및 예산확보 제안요청서(RFP) 작성 사업설명회, 공고, 입찰,
외부에서 조달할 업무에 대한 개략적인 계획을 수립하고 상급자의 승인을 얻은 뒤 수행 예산 확보(국책사업에 대한 계획수립·검토 후 차년도 예산 반영 승인된 사업의 제안서 작성에 대한 가이드를 작성 (제안 요청서에는 목차, 제약조건, 작성 가이드 포함) 사업설명회 : 적합한 공급자들에게 제안요청서 내용에 대한 설명회를 개최하고 질의 응답을 받음 공고 : 제안요청서를 정부기관 홈페이지나 신문에 공지 제안설명회 : 작성한 제안서 내용을 공급자가 수요자에게 설명하고 수요자의 질의에 대한 답변을 함 제안서 및 제안설명회의 발표 내용을 평가하여 공급자를 선정한 뒤 최종 가격 및 업무범위에 대한 협상을 완료하여 계약 체결 체결된 계약서 이행 내용을 정기적으로 평가하고 필요 시 공문을 작성하여 관리 최종 산출물, 제품 등에 대한 검사를 실시하여 이상이 없을 경우 계약종료 사업계획수립 및 예산확보 제안요청서(RFP) 작성 사업설명회, 공고, 입찰, 제안설명회 우선 협상대상자 선정, 기술협상, 공급자 선정 계약 내용 관리 착수보고, 각종보고, 중간검수 최종검수 및 잔금지급 Page  279

조달관리(참조) 공공기관 계약절차 입찰이전 입 찰 단 계 낙 찰 계 약 이 후 낙찰자 결정 계약 체결 계약 이행 검수
입 찰 단 계 낙 찰 계 약 이 후 계약 낙찰자 결정 계약 체결 계약 이행 검수 제품 인수 잔금 지급 선수금 ⓐ Ⓑ 적격심사 낙찰제 종합 낙찰제 협상에 의한 계약 ※ 최저가 낙찰제 제한적 최저가 폐지(99.9) 사업계획 승인 기술·투자 심의 승인 예산승인 일반경쟁 제한경쟁 지명경쟁 수의계약 제한기준 결정 입찰자 지명 공고 2단계 경쟁입찰 규격/가격분리입찰 예정가격 결정 일괄 입찰 입찰 개찰 예상가격 결정 규격서/RFP/과업지시서 ⓐ Ⓑ Page  280

조달관리(참조) 제한 경쟁 지명 경쟁 수의 계약 2단계 경쟁입찰
제한 경쟁 입찰에 의한 계약은 입찰 참가 자격을 일정한 기준에 따라(공사의 경우 도급 한도액, 실적, 기술보유 상황 등으로, 물품 제조의 경우 당해 물품에 제조에 필요한 설비, 기술 보유 상황, 실적 등으로) 제한함으로써 불성실하고 능력 없는 자를 입찰에 참가하지 못하도록 하여 공개성, 공정성, 경제성 등을 유지시키려고 하는 계약방법이다. 지명 경쟁 계약의 성질 또는 목적에 비추어 특수한 설비 · 기술 · 자재 · 물품 또는 실적이 있는 자가 아니면 계약의 목적을 달성하기 곤란한 경우, 특정 다수인을 지명하여 지명된 자들로 하여금 경쟁을 시켜 계약 상대자를 결정하는 계약방법이다. 수의 계약 계약 담당 수요자가 그 상대방이 될 자를 경쟁의 방법으로 선정하지 않고 임의로 특정한 공급자를 선정하여 계약을 체결하는 방법이다. 2단계 경쟁입찰 물품의 제조, 구매 또는 용역계약을 할 때 미리 적절한 규격을 작성하기가 곤란하거나 계약의 특성상 필요하다고 인정되는 경우에는 1단계로 규격 또는 기술 입찰을 실시한 후, 2단계로 가격입찰을 실시할 수 있다. Page  281

프로젝트 형상관리 소프트웨어 형상 관리 개요 소프트웨어 형상 관리 계획 형상 식별 형상 통제 형상 이력 관리 배포 관리
인터페이스 제어 소프트웨어 형상 관리 도구가 제공해야 할 기능 Page  282

프로젝트 형상관리 소프트웨어 형상 관리 소프트웨어 형상 관리는 소프트웨어 생명주기 동안에 생성되는 시스템 내의 소프트웨어 항목을 식별, 정의, 제작, 수정, 저장, 배포하고 소프트웨어 항목에 대한 수정 요구사항을 보고하고 기록하는 행위를 기술적인 절차를 적용해 하나의 프로세스로 관리하는 것 S/W 형상 관리의 목적 산출물 품질 향상 개발 및 유지보수 생산성 향상 사용자 요구사항을 체계적으로 관리 Page  283

프로젝트 형상관리 소프트웨어 형상 관리의 요소 활동 리비전(revision) 관리 – 아카이빙(archiving)기법 활용
버전(version) 관리 빌드(build) 관리 실행 관리 프로모션 관리 변경 요청 관리 테스트 관리 지원 데스크 관리 효과 분석 Page  284

프로젝트 형상관리 기본적 형상관리 완벽한 형상관리 모든 프로젝트에 기본적으로 적용되어야 할 필요한 요소 6가지
Change Request Management Release Management Version Management Build Management Distribution Installation 완벽한 형상관리 기본적인 6가지 관리항목 + 요청 관리, Help Desk관리, 테스트관리 등 Page  285

프로젝트 형상관리 형상 관리 프로세스 개발(중) 단위 테스트 준비 시스템 테스트 수락 테스트 베이스라인 확정 제품 사용 릴리즈
성공적인 완료 시스템 테스트에서 발견한 결함 수락 테스트에서 프로그램 작성 단위 테스트에서 Page  286

프로젝트 형상관리 S/W 생명주기 모델과 형상 관리 프로세스 시스템 엔지니어링 시스템 명세 요구사항 분석
소프트웨어 설계 코딩 테스팅 배포 시스템 명세 소프트웨어 요구사항 명세 설계 명세 소스 코드 테스트 계획/절차/자료 운영가능 시스템 Page  287

프로젝트 형상관리 S/W 형상 관리 계획 형상 관리 일정 형상 관리 자원 조직 및 책임 형상관리 계획 유지보수
S/W도구, 기법, 장비, 명시된 S/W 형상 관리 활동을 위해 필요한 훈련 식별 조직 및 책임 S/W 형상 관리 활동 각각에 대해서 책임지거나 활동에 참여하는 모든 조직 사업구조 내에서 조직의 기능적 역할 조직들 간의 관계 형상관리 계획 유지보수 누가 S/W 형상 관리 계획을 감시할 책임이 있는가? 얼마나 자주 갱신되어야 하는가? S/W 형상 관리 계획에 대한 변경이 어떻게 평가되고 승인되는가? S/W 형상 관리 계획에 대한 변경이 어떻게 이루어지고 전달되는가? Page  288

프로젝트 형상관리 형상 식별 형상 식별 활동은 기준선과 형상 항목들을 인식해 내고, 인식해낸 것들을 구분 가능하도록 명명함으로써 시스템의 변화를 쉽게 추적 할 수 있도록 하는 작업 형상 항목 식별 기준선 설정 기준선에서 통제될 항목 기준선을 설정하거나 변경하기 위해 사용되는 절차 승인된 기준문서에 대한 변경을 승인하기 위해 필요한 권한 발생 가능성과 영향력 발생 가능성 – 해당 위험요소가 실제로 발생할 가능성 영향력 – 해당 위험요소가 발생했을 때 프로젝트의 성공에 미치는 영향력 위험 노출도(risk exposure) – 발생 가능성과 영향력 두 요소에 따라 결정 Page  289

프로젝트 형상관리 형상통제(configuration control)
형상통제 활동은 기준선이 되는 형상 항목들에 대한 변경을 요청, 평가, 승인, 또는 거절하고 실행한다 형상통제 절차 변경의 요청 – 프로젝트 상황에 적합한 제품 및 프로세스 품질표준 정의 변경의 평가 – 프로젝트에서 수행할 품질활동과 간략한 내용 변경의 승인 또는 거절 변경의 실행 Page  290

프로젝트 형상관리 형상 이력 관리 형상 이력 관리 활동은 기준선을 포함하여 통제되는 소프트웨어 형상 항목들의 상태를 기록하고 보고한다 형상 이력 관리 정보 기준선과 변경에 대해 추적되고 보고될 데이터 요소 생성될 형상 상태 보고서의 유형 및 빈도 정보를 수집, 저장, 처리 및 보고하는 방법 상태 데이터에 대한 접근 통제 방법 Page  291

프로젝트 형상관리 형상 평가 형상 평가는 식별된 소프트웨어 형상 통제 항목에 대한 요구사항 관점에서의 기능적 및 물리적 완전성에 대한 평가를 수행하고 결과를 문서화하는 활동이다 형상 평가 정의 목적 평가 또는 검토될 형상 항목 평가 또는 검토 업무의 일정 평가 또는 검토를 위한 절차 직책별 참가자 평가 검토를 위한 필요 문서 결함 및 수정 활동을 위한 보고 절차 승인 기준 및 승인 활동 Page  292

프로젝트 형상관리 배포 관리 배포 관리 및 인도 활동은 소프트웨어 산출물과 관련 문서의 배포 및 인도 과정을 공식적으로 통제하고 경과를 문서화하는 활동이다 소프트웨어 산출물은 형상 통제 절차에 따라 배포되어야 한다 인터페이스 제어 인터페이스 제어 활동은 소프트웨어 형상 관리 계획의 범위 외부에 있는 항목과 인터페이스 하기 위해 변경되는 사업 형상 항목들에 대한 변경을 조정한다 인터페이스 항목 인터페이스 상태 영향을 받는 조직 인터페이스 코드, 문서 및 데이터 통제 방법 인터페이스 통제문서를 승인하고 명시된 기준선으로 인도하는 Page  293

프로젝트 형상관리 소프트웨어 형상 관리 도구가 갖추어야 할 기본적인 특성
이전의 리비전이나 버전에 대한 정보에 언제든지 접근할 수 있어야 한다 허가 받지 않은 사용자가 소스를 수정하지 못해야 한다 동일한 프로젝트에 대해서 여러 개발자가 동시에 개발할 수 있어야 한다 에러가 발생 했을 때 신속히 수정할 수 있어야 한다 고객의 요구사항을 적시에 최상의 소프트웨어를 공급할 수 있어야 한다 Page  294

프로젝트 형상관리 형상관리(SCM)의 효과 Page  295

프로젝트 형상관리 형상 관리 도구의 종류 구분 PVCS V5.0 ClearCase V3.2 Source Safe V5.0
Sofrtbench CM 시스템 지원 환경 - Window, Win95, NT, Os/2, UNIX - LAN 및 Stand Alone - 서버:UNIX, NT - CLIENT:Window, NT, Win95 서버:NT, Win95 CLIENT:Win95 - 서버:UNIX, (NT) - CLIENT:Windows, Win95 제품군 Version Manager Configuration Builder - Production Gateway - Developer’s Toolkit - REPORTER - TRACKER - ClearCase - ClearCase Attache - ClearCase Multisite - 기타 ClearGuide, ClearDOTS, ClearQuest - Visual Source Safe - 유틸리티(Fee) ADD-IN FOR OFFICE97 Back-up COMMAND LINE History Report CM System CM Plan ※ 형상관리도구 : Subversion 결함관리 : BugZilla 테스팅도구 : JUnit Page  296

품질보증개요 품질과 품질보증 개념 품질 관련 표준 소프트웨어 매트릭스 Page  297

품질과 품질보증 개념 SW 품질 개념 SW 품질의 정의 SW 품질 특성
소프트웨어의 구성요소 또는 프로세스 특정하게 규정된 요구조건, 또는 사용자의 요구 및 기대를 충족하는 정도 SW 품질 특성 기능성 : 일련의 기능존재와 규정된 기능특성과 관련된 속성들의 집합 신뢰성 : 명시된 기간동안 명시된 조건에서 그의 성능수준을 유지하는 소프트웨어 능력과 관련된 속성의 집합 사용성 : 사용을 위한 노력과 그러한 사용에 대한 개개인의 심사와 관련된 속성의 집합 효율성 : 규정된 조건에서 소프트웨어 성능수준과 사용된 자원량 사이에 관계된 속성의 집합 유지보수성 : 규정된 수정을 수행하기 위하여 필요한 노력과 관련된 속성의 집합 이식성 : 다른 환경으로 이전되는 소프트웨어 능력과 관련된 속성의 집합 Page  298

품질과 품질보증 개념 SW 품질 보증 개념 SW 품질 보증 활동 품질 보증 정의 품질 보증 효과
사용자가 요구하는 품질이 충분히 충족되고 있는 것을 제품속성의 정도로 나타내는것 품질 보증 효과 품질의 향상 생산성 향상에 따른 유지보수 비용의 감소 고객에게 품질 높은 서비스 제공 SW 품질 보증 활동 검증(Verification)과 확인(Validation) 검증은 “생산물을 올바르게 만들고 있는가?”, 확인은 “올바른 생산물을 만들고 있는가” 관점 워크스루(Walkthrough) 프로젝트 수행 결과물 및 수행 과정에 대해 객관적인 전문가에 의해 비공식적인 검토를 받는것 인스펙션(Inspection) 검토될 품목들의 체크리스트를 가지고 결과물을 전문요원에 의해 검토하는 공식적인 회의 Page  299

품질관련표준 제품관련 표준 ISO 9126 품질 표준 표준별 상세 내용 ISO/IEC 9126-1
사용자 관점에서 본 소프트웨어 품질인자에 대한 국제 표준 소프트웨어 품질특성과 메트릭으로 구분 ISO/IEC SW가 사용될 경우에 SW의 외부적 성질을 나타냄 실행 가능한 SW나 시스템을 시험, 운영 또는 관찰을 통해 측정 ISO/IEC 설계 및 코드와 관련된 SW의 내부 속성을 측정 설게나 코딩 도중에 실행할 수 없는 소프트웨어 제품에 적용 ISO/IEC 12119 정보기술-소프트웨어 패키지에 대해 제3자에 의한 품질 요구사항 및 시험을 대상으로 함 Page  300

품질관련표준 프로세스관련 표준 품질경영관련 표준 ISO 12207 ISO 15504(SPICE) CMMI ISO 9001
소프트웨어 생명 주기 프로세스를 위한 공통의 개념적 준거틀을 제공 참조모형의 프로세스 차원은 소프트웨어 개발, 유지보수, 획득, 공급, 운영과 관련된 프로세스 포함 ISO 15504(SPICE) 프로세스를 평가하고 개선함으로써 품질 및 생산성을 높이고자 하는 표준 CMMI 미국 국방부 지원 아래 산업계와 카네기 멜론대학 소프트웨어 공학 연구소가 공동으로 SW-CMM과 SE-CMM 등의 요소를 통합한 모델 품질경영관련 표준 ISO 9001 설계, 개발, 생산, 설치 및 서비스 과정에 대한 품질 보증 모델 TickIT 소프트웨어 개발자의 능력이 ISO 을 만족하면서 ISO 9001의 요구사항을 만족함을 인증하는 목적으로 개발된 영국의 인증제도 Page  301

SW Metrics SW Metrics의 개념 Measurement/Measure/Metrics 비교
프로세스, 제품, 자원과 환경의 특징을 파악하여 기준을 정의하여 성과와 비교 계획 대비 실적 상태에 대한 평가에 활용 과거 데이터에 기초하여 미래를 예측할 때 활용 지속적인 프로세스 개선 활동에 대한 목표, 방법, 결과의 측정에 활용 Measurement 어떤 현상, 특성, 결과를 숫자로 표현하는 활동 무엇인가를 자로 재고 눈으로 검사하고 기록하는 활동 Measure 측정방법의 표준, 단위로 알고자 하는 개념을 대표하는 측정 항목 FP, 본 수, 결함 수, 투입 공수 Metrics 프로세스, 컴포넌트, 시스템 속성이 숫자로 계량된 측정 항목(Measure) 두 개 이상의 측정항목(Measure)으로 계산된 복합적 지표 Page  302

SW Metrics SW Metrics의 유형 측정 대상에 따른 소프트웨어 측정 유형 측정 유형 유형별 측정방법
Project Metrics 프로젝트 진행 관리와 관련한 측정 공정 진도 준수율, 예산 준수율, 투입 공수 준수율, 교육 이행율 Product Metrics 제품 품질 평가 및 추적과 관련한 측정 규모(FP, 본 수, 화면수), 복잡도 품질특성(기능성, 신뢰성, 사용성, 효율성, 이식성) 소프트웨어 재사용율, 요구사항 변경율, 고객만족도 Process Metrics 프로세스 성과 및 분석과 관련한 측정 프로세스 준수율(이행율), 품질 실패 비용율, 결함제거율, 인스펙션효과성, 인스펙션효율성, 테스트효과성, 테스트효율성 Page  303

SW Metrics SW Metrics의 유형 - 계속 측정 방법에 따른 소프트웨어 측정 유형 측정 방법
측정 방법별 상세 내용 직접 Metrics Cost, Speed, Effort, LOC, memory size, errors 등 간접 Metrics Function, Quality, Complexity, Reliability 등 Page  304

SW Metrics SW Metrics 측정 프로세스 측정 목적 설정 측정 지표 정의 데이터 수집 및 저장 절차 정의
정보의 필요성과 목적을 바탕으로 측정 목적을 설정하고 관리 측정 지표 정의 측정 목표를 이행하기 위한 측정 지표들을 명세화 데이터 수집 및 저장 절차 정의 측정 데이터를 어떻게 수집하고 저장할 것인지를 정의 분석절차 정의 측정 데이터를 어떻게 분석하고 보고할 것인지를 정의 측정 결과 수집 정의된 측정 데이터를 수집 측정 데이터 분석 측정 데이터를 분석하고 그 의미를 해석 결과 보고 및 공유 측정 및 분석 결과를 모든 관련 이해관계자에게 보고 Page  305

품질보증활동 및 기법 품질보증 프로세스 프로세스 품질 성숙도 평가 모델 - CMMI 품질보증 기법 - 인스펙션
Page  306

품질보증 프로세스 품질보증 프로세스별 상세 수행 활동 품질보증 계획 수립 SW 엔지니어링 활동 검토 품질 측정 및 평가 문서화
개발계획에 따라 평가 대상이 되는 산출물과 프로세스를 선정하고 베이스라인을 설정 베이스라인별 형상관리 계획을 수립하고 품질관련 문서에 대한 표준 정의 SW 엔지니어링 활동 검토 소프트웨어를 생산하는 개발활동에 대한 검토를 실시 산출물 작성을 위해 프로세스를 어떻게 수행하였으며 어떤 어려운 점이 있었는지 파악 가능 품질 측정 및 평가 품질사양(시스템과 소프트웨어 요구사항에 대해 구체화하는 절차)과 품질평가(프로젝트 수행과정을 관찰하고 점검) 관점에서 수행 문서화 소프트웨어에 대한 품질 평가가 이루어지면 그 결과는 반드시 문서로 기록 승인 보고 및 통보 Page  307

프로세스 품질 성숙도 평가 모델 - CMMI CMMI 개념 Staged 모델 Continuous 모델
기존 CMM이 모델간의 중복성과 불일치성의 문제, SE엔지니어링과 SW엔지니어링의 유기적 조화 부족, 소프트웨어와 시스템간 상호 의존성 증가를 고려하여 SW 프로세스의 개선만으로는 IT 프로세스 조직의 능력 성숙도가 향상되기 힘드므로 이를 커버하기 위해 CMMI로 통합됨 Staged 모델 조직 전체의 관점에서 프로세스 성숙 수준을 평가하고 순차적으로 성장할 수 있는 접근 방법 Level 1~5까지 5단계로 구분되며 SW-CMM과 유사한 모델 가장 기초적인 관리절차로부터 상위수준으로 향상되기 위해 필요한 실무까지 수행되어야 할 프로세스 영역들을 단계별로 제시 성숙도 수준을 이용한 조직간의 비교가 가능 Continuous 모델 비즈니스 목적에 맞는 프로세스 영역에 대한 능력 수준 평가, 지속적 성장을 위한 접근방법 Level 0~5 까지 6단계로 구분되며 SPICE Model)과 유사한 구조 비즈니스 목적을 충족시키고 위험요소를 완화 시키는데 중요한 개선사항의 순서를 정하여 적용 특정 프로세스 영역에 대한 조직간의 비교가 가능 Page  308

프로세스 품질 성숙도 평가 모델 - CMMI CMMI 4가지 영역에 대한 PA Process Management
Organizational Process Focus : 조직의 프로세스 자산의 강점과 약점을 이해하고 이를 기반으로 프로세스를 개선 Organizational Process Definition : 사용 가능한 조직의 프로세스 자산을 정립하고 유지하는 것으로 PAL을 의미 Organizational Training : 조직의 이해당사자들이 역할을 효과적/효율적으로 수행하기 위하여 기술과 지식을 개발 Organizational Process Performance : 프로세스와 품질의 성과 목표 달성 및 정량적 관리를 위해 성과데이터, 베이스라인 및 모델을 제공 Organizational Innovation and Deployment : 조직의 지속적인 변화와 개선 기회 관리 Page  309

프로세스 품질 성숙도 평가 모델 - CMMI CMMI 4가지 영역에 대한 PA - 계속 Project Management
Project Planning : 프로젝트 활동을 정의한 계획서들을 작성하고 현행화 Project Monitoring and Control : 프로젝트 진행 상태에 대한 현황을 제공하여 이해당사자들이 이해하도록 하고 계획대비 차질이 생길 경우 시정조치 Integrated Project Management : 조직의 표준 프로세스를 재정의 및 통합한 프로세스에 따라 프로젝트계획을 수립 및 관리하고 이해 관계자들을 참여시킴 Risk Management : 잠재적인 위험을 발생하기 전에 파악하여 프로젝트 전반에 걸쳐 미치는 악영향을 줄이기 위해 위험 완화 활동을 지속적으로 수행 Quantitative Project Management : 프로젝트의 정립된 품질 및 프로세스 성과 목표를 달성하기 위해 프로젝트의 정의된 프로세스를 정량적으로 관리 Page  310

프로세스 품질 성숙도 평가 모델 - CMMI CMMI 4가지 영역에 대한 PA - 계속 Engineering
Requirements Management : 프로젝트의 제품 및 컴포넌트에 대한 요구사항 관리 Requirements Development : 고객, 제품, 컴포넌트의 요구사항을 분석하고 개발 Technical Solution : 요구사항에 대한 솔루션을 설계, 개발, 구현 Product Integration : 제품 컴포넌트로부터 제품을 조립, 통합된 제품이 제대로 작동하는 것을 보장하고 사용자에게 인도 Verification & Validation Verification : 선정된 작업산출물들이 명세화된 요구사항과 일치하는지 검증 Validation : 최종 제품이 의도한 환경에서 의도된 사용자 목적에 부합하는지 확인 Page  311

프로세스 품질 성숙도 평가 모델 - CMMI CMMI 4가지 영역에 대한 PA - 계속 Support
Configuration Management : 구성식별, 구성통제, 구성상태보고, 구성감사 등의 활동을 통하여 완료된 산출물의 무결성을 확보 및 유지 Process and Product Quality Assurance : 프로젝트 이해관계자들에게 프로세스 및 관련 작업 산출물에 대한 객관적인 가시성을 제공 Measurement and Analysis : 관리 정보에 대한 필요성을 지원가능하도록 측정 능력을 발전 및 유지하기 위한 영역으로 정량적관리와 지속적개선을 위한 근간이 됨 Decision Analysis and Resolution : 수립된 기준을 근간으로 하여 식별된 대안을 공식적인 프로세스를 통해 평가 Causal Analysis and Resolution : 문제 발생에 대한 근본 원인을 분석하여 지속적인 개선 기회 제공 Page  312

품질보증기법 - 인스펙션 CMMI 4가지 영역에 대한 PA - 계속 Support
Configuration Management : 구성식별, 구성통제, 구성상태보고, 구성감사 등의 활동을 통하여 완료된 산출물의 무결성을 확보 및 유지 Process and Product Quality Assurance : 프로젝트 이해관계자들에게 프로세스 및 관련 작업 산출물에 대한 객관적인 가시성을 제공 Measurement and Analysis : 관리 정보에 대한 필요성을 지원가능하도록 측정 능력을 발전 및 유지하기 위한 영역으로 정량적관리와 지속적개선을 위한 근간이 됨 Decision Analysis and Resolution : 수립된 기준을 근간으로 하여 식별된 대안을 공식적인 프로세스를 통해 평가 Causal Analysis and Resolution : 문제 발생에 대한 근본 원인을 분석하여 지속적인 개선 기회 제공 Page  313

품질보증기법 - 인스펙션 인스펙션의 개념 인스펙션의 정의 인스펙션의 목적
설계서, 코드등의 중간 결과물을 검사하여 결함을 발견하는 작업 인스펙션의 목적 인스펙션을 준비하는 동안 예상되는 결함을 찾아내고 이를 회의에서 확인 발견된 아이템이 실제 결함인지 여부를 확인 결함 여부를 기록 담당자가 수정할 수 있도록 기록을 제시하고 Effort 관리 Page  314

품질보증기법 - 인스펙션 인스펙션 단계별 수행 내용 계획 단계 사전 교육 단계 준비 단계 실시 단계 Rework 단계
주재자가 인스펙션의 작업과 과정을 확립 사전 교육 단계 인스펙션의 대상을 제작한 개발자가 인스펙션 참석자들을 대상으로 간단한 교육 준비 단계 인스펙션 회의를 위한 준비 단계로 자료를 받고 회의 통보를 받은 시점부터 시작 실시 단계 각자 발견한 결함을 발표하고 결함여부를 확인 Rework 단계 발견된 결함을 면밀히 확인하여 필요한 수정 실시 후속조치 단계 인스펙션에서 발견된 모든 결함이 수정되었는지 확인 Page  315

품질보증기법 - 인스펙션 인스펙션 참여 인원 및 역할 Moderator Author Reader Recorder
Overview 필요 여부 결정 Inspection 시작/종료 기준 확인 Inspection을 진행 및 주재 Re-Inspection 수행 여부 결정 기록된 Data의 정확성을 검증 Author Inspection의 대상 작업 산출물을 작성 / Overview를 진행 Reader Inspection 회의 시 작업 산출물을 정해진 순서대로 설명 Recorder 데이터 분석을 위해 데이터를 수집 Inspector 인스펙션에 참여하는 모든 구성원이 Inspector 임 Page  316

품질보증기법 - 인스펙션 인스펙션의 종류 시스템 설계 인스펙션 상세 설계 인스펙션 코드 인스펙션
모듈의 전반적인 설계나 기능을 점검 주요 관심사는 소프트웨어 요구, 성능 명세 관련 사항, 인터페이스 설계 설계 작업의 입력/하드웨어 자원에 대한 기능 할당/기능 흐름/인터페이스/모듈별 설계정의 상세 설계 인스펙션 시스템 전체 설계의 목적을 반영하도록 각 모듈의 설계가 잘되었는지 검사하는 과정 설계를 프로그래밍 언어로 바꾸기 전에 시스템 설계의 목표가 설계에 잘 반영되었는지 점검 코드 인스펙션 새로 작성된 프로그램이거나 다른 시스템에서 개발되었으나 수정한 것이 대상 컴파일 오류가 없는 프로그램만이 대상이 됨 Page  317

품질보증기법 - 인스펙션 코드 인스펙션의 목적 코드가 요구 명세와 설계 명세 및 인터페이스 명세에 적합한지 여부를 검사
상세 설계한 내용이 정확히 프로그래밍 언어로 바뀌었는지 점검 코드의 품질을 동료가 점검 오류를 조기에 파악 코드가 모듈 사이의 인터페이스 요구를 만족하는지 검사 모듈의 테스트 명세를 사전에 미리 검토 적당한 테스트 도구와 환경이 갖추어져 있는지 확인 모듈의 테스트 착수 가능 여부를 결정 개발한 내용이 중요한 계약이나 표준에 어긋나지 않는지 검토 Page  318

품질보증기법 - 인스펙션 코드 인스펙션 체크리스트 사례 대상 구분 체크항목 메소드 헤더 표준
메소드 명명 규칙을 잘 따르고 있는가? 헤더의 주석에 목적과 설계 요소를 기술하고 있는가? 주석에 모든 전제조건과 결과조건을 기술하고 있는가? 문서 표준을 적용하여 작성하였는가? 구현 파라미터의 타입이 일치하는가? Static 가능성은 없는가? 충분히 Private 인가? Page  319

품질보증기법 - 인스펙션 코드 인스펙션 체크리스트 사례 - 계속 대상 구분 체크항목 메소드 내부 표준
표준 표시법을 준수 하고 있는가? 주석은 충분하고 용어는 적정한가? 구현 상세 설계의 내용이 빠짐없이 구현되었는가? 전제조건이 전부 포함되었는가? 결과 조건을 전부 포함하였는가? 반복구조문의 종료 조건이 적정한가? 리턴 타입이 선언부와 일치 하는가? Page  320

품질보증기법 - 인스펙션 인스펙션의 효과성과 효율성 효과성과 효율성 지표 효과성과 효율성 향상 방안 Inspection 효과성
지표사례) 전체(Inspection, 테스트, 운영) 결함건수 대비Inspection 결함건수 효율성 짧은 시간 안에 얼마나 많은 결함을 발견하였는지 여부 지표사례) 투입공수 대비 Inspection 결함건수 Inspection 효과성 향상 방안 - 결함 유형에 대한 기록 및 분석을 통한 정보 공유 - 요구사항명세서와 분석 문서에 대해 집중 실시 Inspection 효율성 - Inspection 선정 대상 기준을 적절히 수립 - 체크리스트 활용 - 자동화 도구를 이용하여 단순/반복 결함 사전 제거 Page  321

실습 #9. 인스펙션 워크샵 주어진 소스 코드를 대상으로 인스펙션 워크샵 실시 (1시간 소요) Hand-out
Page  322

과 정 명 : 개발자가 알아야 할 PM & QA 교육기간 : – 강 사 명 : 김동희

Similar presentations

Presentation on theme: "과 정 명 : 개발자가 알아야 할 PM & QA 교육기간 : – 강 사 명 : 김동희"— Presentation transcript:

Similar presentations

About project

지원

로그인

Auth with social network:

과 정 명 : 개발자가 알아야 할 PM & QA 교육기간 : – 강 사 명 : 김동희

Similar presentations

Presentation on theme: "과 정 명 : 개발자가 알아야 할 PM & QA 교육기간 : – 강 사 명 : 김동희"— Presentation transcript:

Similar presentations

About project

지원