Chatpter 10 프로젝트 관리 01 프로젝트의 이해 02 프로젝트 관리의 이해 03 형상 관리 04 유지보수 요약

Presentation on theme: "Chatpter 10 프로젝트 관리 01 프로젝트의 이해 02 프로젝트 관리의 이해 03 형상 관리 04 유지보수 요약"— Presentation transcript:

1 Chatpter 10 프로젝트 관리 01 프로젝트의 이해 02 프로젝트 관리의 이해 03 형상 관리 04 유지보수 요약
연습문제

2 프로젝트관리지식체계PMBOK에 대해 알아본다.
형상 관리에 대해 알아본다. 유지보수 방법에 대해 알아본다.

3 Section 01 프로젝트의 이해

4 1. 프로젝트 정의 및 특징 프로젝트PMI 프로젝트의 특징
유일한 제품이나 서비스를 만들기 위해 일정한 기간을 정해놓고 수행하는 작업 프로젝트의 특징 한시성: 일의 시작과 끝이 명확히 정해져 있다. 유일성: 기간이 종료되어 만들어 내는 인도물은 유일하다. 참여자의 일시성: 참여 인력은 프로젝트 시작과 동시에 참여하고, 종료되면 해체된다. 한정성: 프로젝트가 종료되면 사용된 자원은 원래의 위치로 돌아가던가 없앤다.

5 2. 프로젝트 매니저의 역할 • 프로젝트 시작 시점부터 기획 및 설계
• 프로젝트에 참여하는 팀원들의 능력을 잘 파악하여 적재적소에 배치 • 고객과의 많은 대화를 통해 의견을 조율 • 프로젝트가 시작되면 진행 상황 체크 및 진척 관리 • 프로젝트 수행 중 발생하는 문제에 대해 고민하고, 책임감을 갖고 해결 • 인력 관리를 통한 참여자들의 도중하차 예방 및 의사소통 분위기 조성 • 개발 기간 내에 최종 결과물을 고객에게 인도

6 Section 02 프로젝트 관리의 이해

7 0. 프로젝트 관리 프로젝트 관리의 수행 • 프로젝트 완수를 위해 활동에 필요한 기술, 기법, 도구들을 적절히 배치
• 필요한 자원들을 계획하고 적기에 사용할 수 있도록 공급 • 필요한 인력을 적재적소에 배치 • 프로젝트의 진행 상황 확인 및 진도 관리 • 예상대로 되지 않는 것들에 대해 대비 계획을 세우고, 대응책 마련

8 1. PMBOK의 5가지 프로세스 그룹(1) ① 시작initiating 그룹
핵심 프로세스: 범위 관리 착수 및 프로젝트 또는 프로젝트를 구성하는 단계 정의 및 승인

9 1. PMBOK의 5가지 프로세스 그룹(2) ② 기획planning 그룹
프로젝트 목표 설정 및 목표 달성을 위한 활동 계획과 예산, 인력, 자원 등의 계획 수립 • 범위 기획: 프로젝트의 목적을 정의하는 ‘범위 기술서 개발 • 범위 정의: 프로젝트 수행을 위해 더 작고 관리 가능한 구성 요소로 세분화 • 작업 정의: 프로젝트 수행을 위해 실행되어야 할 특정 활동들 식별 • 작업 순서: 활동 간의 상호 의존성을 식별하고 기록 • 작업 기간 산정: 단위별 활동을 완료하기 위해 필요한 작업 기간 산정 • 일정 개발: 활동 순서와 활동 기간, 프로젝트 일정을 세우기 위해 필요한 자원 산정 • 위험 관리 기획: 위험 관리를 위한 접근 방법과 계획을 세운다. • 자원 기획: 프로젝트 수행 시 필요한 자원의 종류와 양 결정 • 비용 산정: 프로젝트 수행 시 필요한 비용 산정 • 비용 예산 수립: 개별적인 작업들에 소요되는 모든 비용 산정 • 프로젝트 계획 개발: 다른 기획 프로세스에서 세운 결과들과 일관되고 명확하게 문서화

10 1. PMBOK의 5가지 프로세스 그룹(3) ③ 실행executing 그룹 ④ 통제controlling 그룹
핵심 프로세스는 프로젝트 계획 실행으로 계획을 세운대로 실제 프로젝트 수행 ④ 통제controlling 그룹 프로젝트 통제: 계획 대비 목표의 진척 상황을 주기적으로 감시하고 성과를 측정 ⑤ 종료closing 그룹 • 성과 보고: 상태 보고, 진척도 측정, 예측 등이 포함된 성과 정보를 수집하고 배포 • 통합된 변경 통제: 프로젝트의 변경 사항 조정 • 계약 종료: 진행 중인 모든 항목들을 마무리하고 계약 종료 • 관리 종료: 공식적으로 프로젝트를 완료하기 위해 정보를 생성, 수집, 보급

11 2. 프로젝트 관리의 9가지 관점

12 2-1 프로젝트 통합 관리 ① 프로젝트 계획 개발 ② 프로젝트 계획 실행 ③ 통합된 변경 통제 프로젝트 계획서 작성
- 프로젝트 수행과 통제를 가이드하기 위한 관련 문서 프로젝트 계획서 - 프로젝트 실행을 위하여 공식적으로 승인된 문서 - 프로젝트에 새로운 정보가 추가됨에 따라 변경 가능 ② 프로젝트 계획 실행 계획된 프로젝트를 예정대로 구현하는 프로세스 프로젝트를 완료하기 위해 수행한 활동들의 성과로서 작업 결과물 산출 ③ 통합된 변경 통제 변경통제시스템이나 형상 관리 등의 변경 관리를 통해 수정된 내용으로 개정된 프로젝트 기준을 만든다.

13 2-2 프로젝트 범위 관리 프로젝트 범위 관리 프로젝트 범위 관리 프로세스
프로젝트를 성공적으로 완료하기 위해 필요한 모든 작업을 프로젝트에 포함시키기 위해 요구되는 프로세스들로 구성 제품 범위(product scope) 구성 프로젝트 범위(project scope) 프로젝트 범위 관리 프로세스 ① 착수: 새로운 프로젝트가 시작됨을 공식적으로 승인하는 프로세스 ② 범위 기획: 프로젝트 작업을 문서화하고 순차적으로 완성해가는 프로세스 ③ 범위 정의: 주요 프로젝트 인도물을 더 작고 관리 가능한 구성 요소로 나누는 작업 ④ 범위 검증: 이해 관계자들에 의해 프로젝트 범위 승인을 획득하는 프로세스 ⑤ 범위 변경 통제: 프로젝트 범위 변경에 관한 절차를 정의

14 2-3 프로젝트 일정 관리 프로젝트 일정 관리 프로젝트를 주어진 기간 내에 완료하기 위해 요구되는 프로세스들로 구성
① 작업 정의: 프로젝트 목적에 부합하는 활동을 정의 ② 작업 순서: 활동 간의 논리적 상호 관계를 식별하고 문서화 ③ 작업 기간 산정: 프로젝트를 수행하는 데 필요한 개발 기간이 얼마나 되는지를 산정 ④ 일정 개발: 프로젝트를 언제 시작해서 언제 끝낼 것인지, 즉 시작일과 종료일을 결정 ⑤ 일정통제: 일정에 대한 변경을 결정하고, 변경이 발생했을 때 변경 관리

15 2-4 프로젝트 비용 관리 프로젝트 비용 관리 주어진 예산 범위 안에서 프로젝트를 완료하기 위해 요구되는 프로세스들로 구성
① 자원 기획: 무슨 자원(인력, 장비, 도구 등)이 언제, 얼마나 필요한지를 결정 ② 비용 산정: 필요한 자원(인력, 장비, 도구 등)에 대해 어느 정도의 비용이 발생하는지 계산 ③ 비용 예산 수립: 산정된 프로젝트 비용을 합산하여 승인된 비용 기준선을 설정 ④ 비용 통제: 프로젝트 상태를 모니터링 하면서 프로젝트 예산을 갱신하고, 비용 기준선에 따라 부적절하거나 승인되지 않은 변경을 방지

16 2-5 프로젝트 품질 관리 프로젝트 품질 관리 사용자의 품질 요구를 만족시키기 위해 요구되는 프로세스들로 구성
① 품질 기획: 프로젝트에 적합한 품질 요구 사항과 품질 표준을 식별하고 이를 프로젝트에 서 어떻게 달성할 것인지 계획하는 프로세스 ② 품질 보증: 품질 요구 사항과 품질 통제 측정치를 감시하면서 해당하는 품질 표준을 사용 하고 있는지 확인하는 프로세스 ③ 품질 통제: 프로젝트 결과물에 대한 모니터링을 통해 관련 품질 표준을 만족하였는지 결 정하고 부적합이 발생할 경우 원인을 찾아 해결하는 프로세스

17 2-6 프로젝트 인적 자원 관리 프로젝트 인적 자원 관리 참여 인력들에 대한 지원과 팀 환경을 만들어주는 프로세스
① 조직 기획: 프로젝트의 역할, 책임 사항, 필요한 역량 등을 문서화, 직원 관리 계획서 작성 ② 팀 확보: 가용 인적자원을 확인하여 꼭 필요한 인력을 확보해서 팀을 구성 ③ 팀 개발: 프로젝트 성과를 향상시키기 위해 팀원들의 역량과 팀원 간 협력, 전반적인 팀 분위기를 개선하는 프로세스

18 2-7 프로젝트 의사 소통 관리 프로젝트 의사 소통 관리
이해 관계자들 간의 메시지를 누구에게, 언제, 어떻게 보낼 것인가를 결정하고 관리 ① 의사소통 기획: 이해 관계자들이 원하는 요구 사항을 식별해서 프로젝트가 진행됨에 따라 발생하는 정보들을 적시에 적합한 형태로 제공할 수 있도록 계획을 세워야 한다. ② 정보 배포: 이해 관계자들이 원하는 정보를 제공 ③ 성과 보고: 프로젝트에 대한 결과 정보를 생성해서 배포 성과 정보: 프로젝트 비용, 일정, 품질과 실적 대비 예측치 등

19 2-8 프로젝트 위험 관리 프로젝트 위험 관리 프로젝트의 위험을 식별, 분석, 대응하기 위해 요구되는 6개의 프로세스들로 구성
① 위험 관리 기획: 위험들을 언제, 어떤 방법으로, 어떻게 관리할 것인가를 계획 ② 위험 식별: 무엇이 위험인지 파악하고 찾아내는 것 ③ 정성적 위험 분석: 도출된 위험들이 미치는 영향력과 빈도수 등을 분석 ④ 정량적 위험 분석: 위험의 빈도수, 위험의 크기 등을 수치화하여 계량하는 프로세스 ⑤ 위험 대응 기획: 대응 전략(회피, 전가, 완화, 수용)을 세우고, 그 대응 전략 이후에도 남아 있을 위험과 이차적인 위험, 위험 대응을 위해 필요한 시간과 비용, 위험 에 대한 비상 계획, 예비 계획 등을 세운다. ⑥ 위험 모니터링 및 통제: 식별된 위험에 대해 추적하고, 잔존하는 위험을 감시하며, 새롭게 발견되는 위험을 식별하고, 위험 감소 효과를 평가하는 프로세스

20 2-9 프로젝트 조달 관리 프로젝트 조달 관리 조직의 외부에서 물품과 서비스를 조달하기 위해 요구되는 6개의 프로세스로 구성
① 조달 기획: 조달 여부 결정하는 것부터 무엇을, 어떻게, 언제, 얼마나 할 것인지 고려 ② 권유기획: 제안요청서 작성하는 것 ③ 권유(공급자 유치): 입찰자들이 작성하는 제안서 ④ 공급자 선정: 응찰 업체 중 하나의 업체를 선정 ⑤ 계약 관리: 선정된 업체와 계약을 맺을 때 계약과 관련해서 필요한 모든 작업 ⑥ 계약 종료: 납품(또는 개발)이 완료되면 처음의 요구 사항과 같은지 검수하고, 문제가 없 으면 최종 산출물 관련 자료들을 받는 것으로 끝을 내는 데 필요한 프로세스

21 Section 03 형상 관리

22 1. 변경 관리(1) 소프트웨어 변경에 대한 견해 Eric J.Braude:
“프로젝트는 진행되어가면서 새로운 산출물들이 축적되고, 축적된 산출물들은 계속해서 버전 업이 된다”, “이렇게 변경되는 산출물들을 관리하는 것이 형상 관리다” Bersoff: “시스템은 소프트웨어 개발 생명주기의 모든 단계에서 변경이 일어나고, 시스템을 변경하고자 하는 욕구는 개발 생명주기 동안 지속적으로 일어날 것이다”

23 1. 변경 관리(2) 변경의 요인 ① 업무 환경의 변화 ② 기술 환경의 변화 새로운 기능의 추가와 같이 고객의 요구의 변경
시장 여건의 변경 예산과 일정 계획 등에서의 변경 ② 기술 환경의 변화 하드웨어의 사양 및 운영체제의 변경

24 2. 버전 관리(1) full model change minor change 소프트웨어에서 버전
자동차 외형의 디자인도 대폭 바뀌고, 내부 인테리어뿐 아니라 엔진까지도 바뀌는 경우 대표적인 예: 소나타 III에서 EF 소나타로 바뀐 것 소프트웨어: Ver.1.0에서 Ver.2.0으로 바뀌는 것 minor change 자동차의 외형적인 디자인과 내부 인테리어 정도가 바뀌는 것 대표적인 예: 소나타II에서 소나타 III로 바뀐 것 소프트웨어: Ver.1.0에서 Ver.1.1 또는 Ver.1.1.1에서 Ver.1.1.2로 바뀌는 것 소프트웨어에서 버전 개발 단계 또는 순서를 번호로 표시한 것

25 2. 버전 관리(2) 버전 관리의 필요성 질문: “서로 다른 버전의 원시 파일에 어떤 차이점이 있는가?”
바로 대답할 수 있는 방법: 각 버전의 정보를 데이터베이스화하여 언제라도 과거의 릴리스된 파일을 가지고 작업할 수 있도록 관리하면 가능 파일의 이력이나 차이점을 관리해 애플리케이션의 버전과 각 원시 파일이나 문서를 유용하게 활용하기 위함

26 2. 버전 관리(3) • 릴리스 1.0 : 요구 분석 명세서(V1.1) - 설계 사양서(V1.2) - 원시 코드(V1.1)

27 3. 형상 관리(1) 형상 항목configuration item 형상 관리
수만에서 수십만 개의 부품으로 이루어져 있는 자동차나 비행기의 작은 단위의 부품들 형상 관리 특정 항목의 변화에 대해 관리하면서 시스템의 통합과 일치를 보장하는 것 소프트웨어 형상 관리SCM: Software Configuration Management 개발 중 발생하는 모든 산출물들이 변경됨으로써 점차 변해가는 소프트웨어 형상을 체계적으로 관리하고 유지하는 기법 소프트웨어 개발 생명주기 전반에 걸쳐 생성되는 모든 산출물의 종합 및 변경 과정을 체계적으로 관리하고 유지하는 일련의 개발 관리 활동

28 3. 형상 관리(2) 형상 관리(IEEE-Std-1042)
언제라도 특정 시간대에 가장 안정적인 버전의 소프트웨어를 유지할 수 있도록, 소프트웨어 제품이 변경되어가는 상태에 대한 가시성을 확보해준다. 누가 변경했는지, 변경된 것은 무엇인지, 언제 변경되었는지, 왜 변경했는지와 같은 질문에 대답해준다. 궁극적으로 프로젝트를 개발하는 동안 생산성과 안전성을 높여 좋은 품질의 소프트웨어를 생산하고 유지보수도 용이하게 해주는 데 목적이 있다. 형상 관리 절차를 중심으로 형상 항목을 식별하여 그 기능적 물리적 특성을 문서화하고, 그러한 특성에 대한 변경을 공식적으로 통제하고, 변경 처리 상태를 기록 및 보고하고, 명시된 요구 사항에 부합하는지 확인하는 일련의 사항에 대해 기술적, 행정적인 지침과 관리적 인 감독, 감시 활동을 포함한 사후 관리를 적용하는 원칙

29 3. 형상 관리(3) 형상 관리 형상 관리 효과 변경되어가는 상태에 대한 가시성 확보 언제라도 가장 안정적인 버전의 SW 유지
변경에 관한 질문에 답변 가능 누가, 언제, 무엇을, 왜 변경했는지 답변 가능 목적: 생산성과 안전성 향상 좋은 품질의 소프트웨어 생산, 유지보수 용이 적절한 변경 관리 무절제한 변경의 사전 예방, 변경에 따른 부작용 최소화 형상 관리 효과 프로젝트의 적절한 통제 체계적이고 효율적 관리 가능 가시성과 추적성 보장함 소프트웨어의 생산성과 품질 향상 가능

30 3. 형상 관리(4) 형상 관리 수행 절차

31 3-1 형상 식별(1) 형상 식별configuration identification ① 형상 항목 선정
형상 관리의 가장 밑바탕이 되는 활동 프로젝트 계획 시 형상 관리 계획을 근거로 형상 관리의 대상이 무엇인지 식별하는 과정 ① 형상 항목 선정 제품 개발 초기 단계에 관리방법이나 변경에 대한 통제 여부에 따라 산출물을 구분하고, 이 중 변경에 대한 통제가 필요한 산출물을 선정 ② 형상 식별자 규칙 선정 어떤 프로젝트에서 사용되는 파일인지, 어떤 내용의 문서인지, 버전이 어떻게 되는지를 같은 작업을 하는 소속 팀원들끼리 한눈에 알아볼 수 있도록 이름을 명명하는 규칙 (예) ‘TIS_Design_UC_V1.0’: 종합정보시스템(TIS)의 디자인 단계(Design)에서 사용하는 유 스케이스 다이어그램(UC)으로, 버전은1.0(V1.0)임

32 3-1 형상 식별(2) ③ 베이스라인 기준 선정 베이스라인baseline : 소프트웨어 개발 과정 중 특정 시점에 만들어진 산출물의 집합 (예) 특정 시점: Ver.2015 출시, 베이스라인: V1.3, V1.2, V1.4, V1.3

33 3-1 형상 식별(3) Ver. 2016(출시 예정)의 개발 작업

34 3-1 형상 식별(4) 브랜치를 이용한 패치 파일 작업

35 3-1 형상 식별(5) 병합을 이용한 파일 작업

36 3-2 형상 통제 형상 통제configuration control ① 변경 요청 ② 변경 삼사 ③ 변경 확인
형상 목록의 변경 요구를 검토 및 승인하여 현재의 소프트웨어 기준선에 반영될 수 있도록 통제하는 일련의 과정 ① 변경 요청 고객/개발자는 변경 사항 발생 시 변경 요청서 작성 변경 관리 담당자에게 제출 ② 변경 삼사 고객/개발자가 변경 요청서 제출 형상통제위원회의 검토 수락/거절 결정 ③ 변경 확인 변경 완료: 개정 이력들과 함께 새로운 버전 번호 부여 형상통제위원회: 변경된 내역 확인 및 승인 후 체크인 저장소에 새로이 저장된 변경 항목: 다시 베이스라인으로 수립

37 3-3 형상 상태 보고 형상 상태 보고configuration status reporting 형상 상태 보고 내용
베이스라인으로 설정된 형상 항목 구조와 변경 상태 기록 관련된 사람들에게 보고 형상 상태 보고 내용 • 프로젝트에서의 변경 횟수 • 최근 SW 항목의 버전, 릴리스 식별자, 릴리스 횟수, 릴리스 간의 비교 내용 • 베이스라인의 상태 • 변경 제어 상태 • 형상통제위원회 활동 내역

38 3-4 형상 감사 형상감사configuration audit 형상 감사 내용
형상 관리 계획서대로 형상 관리가 진행되고 있는지, 형상 항목의 변경이 요구 사항에 맞도록 제대로 이뤄졌는지 등을 살펴보는 활동 단계별 베이스라인의 적정성과 무결성을 평가하고 승인 형상 감사 내용 • 승인된 변경 요청이 제대로 반영되었는지 검증 • 승인되지 않은 내용이 혹시 반영되었는지 검증 • 승인된 변경과 관련된 항목들이 갱신되었는지 검증

39 4. 형상관리에 대한 역할과 책임(1) 형상 관리 담당자configuration manager 형상 관리 담당자의 역할
프로젝트 관리자가 정의한 형상 관리 계획서에 따라 운영 환경을 구현하고 형상 관리 활동을 수행 형상 관리 담당자의 역할 • 형상 관리 계획서 작성에 참여 • 형상 관리 환경 구축 및 형상 관리 저장소(repository) 생성 • 형상 관리 절차 개발 및 문서화 • 베이스라인 설정 • 형상 항목 식별 및 관리 • 주기적으로 형상 상태 보고

40 4. 형상관리에 대한 역할과 책임(2) 형상통제위원회CCB: Configuration Control Board
형상 항목의 변경을 수락하거나 거절하는 역할 변경의 필요성, 계약, 일정, 비용에 미치는 영향, 유지보수에 미치는 영향, 변경 결과의 적절성 등을 판단하여 검증 구성: 프로젝트 관리자, 형상 담당자, 품질 담당자, 기술 담당자 및 고객 측 담당자와 같은 형상 항목의 변경으로 인해 영향을 받는 사람들로 구성 역할: 형상 항목 결정, 베이스라인 수립 여부 결정, 승인된 변경에 대한 책임 및 보증, 베이스라인의 변경 요청이 필요한 경우 이에 대한 검토 및 승인

41 4. 형상관리에 대한 역할과 책임(3) 형상통제위원회의 형상 변경 절차

42 5. 형상관리 계획서 형상관리 계획서 형상 관리 활동을 비롯해 형상 관리 활동을 수행하기 위한 절차와 일정 등이 포함

43 Section 04 유지보수

44 1. 소프트웨어 유지보수(1) 소프트웨어 유지보수의 분류

45 1. 소프트웨어 유지보수(2) ① 수정correction 유지보수 ② 적응adaption 유지보수
개발된 소프트웨어를 사용자가 인도받은 후 사용하면서 발견되는 오류를 잡는 것 개발 과정에서 미처 바로잡지 못한 오류를 유지보수 단계에서 해결하는 것 ② 적응adaption 유지보수 개발된 소프트웨어가 처음 설치된 곳에서 문제없이 실행되다가 환경이 바뀌어도 이에 맞도록 수정·보완해주는 것 ③ 기능 보강enhancement 유지보수 변경이 필요할 때 하게 되는 유지보수 ④ 예방prevention 유지보수 미리 예상되거나 예측되는 오류를 찾아 수정하는 것

46