碩 士 學 位 論 文

소프트웨어 제품 개발 프로젝트 환경에 기초한 PMS활용이 프로젝트 관리 지표에 미치는 영향에 관한 실증적 연구

Effect of the Project Management

Key Performance Indicator

under Software Product Development

高麗大學校 컴퓨터情報通信大學院

소프트웨어工學科

李 東 旼

2016 年 07 月 07日

李 喜 造 敎 授 指 導

碩 士 學 位 論 文

소프트웨어 제품 개발 프로젝트 환경에 기초한 PMS활용이 프로젝트 관리 지표에 미치는 영향에 관한 실증적 연구

Effect of the Project Management

Key Performance Indicator

under Software Product Development

이 論文을 工學 碩士學位 論文으로 提出함

2016 年 07 月 07 日

高麗大學校 컴퓨터情報通信大學院

소프트웨어工學科

李 東 旼

李東旼의 工學 碩士學位 論文 審査를 完了함

2016 年 07 月 07 日

委員長  李 喜 造 (印)

委  員  印    浩 (印)

委  員  李 錫 周 (印)

요  약

오늘날 정보통신 산업의 규모의 발전과 함께 융복합화가 급속하게 진행되면서, SW가 최종 제품의 가치와 경쟁력을 좌우하는 핵심요소가 되었고, 개발해야하는 SW의 규모나 복잡도는 점차 확대되고 있는 것이 현실입니다. 이에 경쟁력이 있는 SW를 개발하는 것이 더욱 중요하게 되었습니다. 하지만, 현실은 품질이 확보된 SW만들기도, SW개발과정을 관리하기도 어려운 상황입니다.

아직도 SW개발 현장은 밤낮을 지새우지만, 프로젝트는 관리자의 경험적인 정성적 평가로 인하여 명확한 관리의 어려움 때문에, SW산업의 경쟁력 확보를 위해서 차별화된 SW 현장 친화적 관리 기술 체계와 체계적이고 정량적인 관리기술과 같은 경쟁 우위 요소가 필요함을 프로젝트 이해관계자 모두가 공감하고 있습니다.

이것을 해결 할 수 있는 방안을 찾고자 본 논문에서는 SW공학기반에서 선행 연구자들이 제시한 프로젝트 관리 지식 체계(이하 PMBOK)를 조사하고 프로세스 능력 성숙도 모형 결합(이하 CMMI)를 기준으로 상호 교차 대응을 분석하여, 학술적 고찰을 기반으로 정량적인 프로젝트 관리 지표 항목을 구분하였습니다.

그리고 프로젝트 관리 시스템(이하 PMS)에 대한 고찰을 기반으로 PMS 선정 및 기업에 도입, 전사 활용 데이터를 전 방위로 수집한 결과와 소프트웨어 형상 관리 시스템(이하 SCM)을 바탕으로 프로젝트 관리 지표 항목 데이터를 선별하였습니다.

선별된 데이터를 기반으로 PMS가 프로젝트 관리 지표에 주는 영향 및 효과에 대하여 파악한 내용을 체계적이고 객관적으로 분석한 내용을 수록했습니다.

또한, 본 연구를 통하여 앞으로 끊임없이 발전하며 진행될 프로젝트 관리에 대한 지식체계와 맞물려 확장될 PMS의 방향에 대하여 제시하고자 합니다.

Keyword : Project, Project Management, PMBOK, CMMI, 프로젝트 관리 시스템, Project Management System(PMS), Project Management KPI

Abstract

Along with the development of the scale of the telecommunication industry, today integration service  are  conducted rapidly.  SW  became  value of the final end and key factor to determine. It is reality that SW size and complexity is gradually expanded. It is important to develop SW to competitive.

However, the reality is difficult situation to make and to manage.

SW developing scene is still on.  Project manager is empirical assessment. Because the difficulty of managing is clear. In order that the competitiveness of the industries  SW  field management techniques and systematic and quantitative manages  technology secure, Project stakeholders have a shared understanding of their management technology system and Quantitative elements are needed competitive edge control technology.

In this paper to seek ways to be able to address this (less than PMBOOK) give leading researchers in project management based on knowledge systems engineering SW to conduct an investigation. Capability Maturity Model Integration process (less than CMMI) based on reciprocal crossing over analyze possible. Divided control index items based on quantitative consideration the academic projects.

And project management system (less than PMS) based on a consideration of the selected PMS and introduced in companies. Bring data collection in all directions.  As a result, and software configuration management system project data selection control index items based on (less than SCM).

Selected PMS the project based on data about the impact and effect indicators of controlled by identifying a systematic and objective analysis of the information on the contents.

Further, this will constantly developed in the future through a study. To be carried out in front of the project control, coupled with the body of knowledge on PMS to extend to suggest the direction.

Keyword : Project, Project Management, PMBOK, CMMI, Project Management System(PMS), Project Management KPI

목   차

요    약..........................................................................................................................ⅰ

Abstract..........................................................................................................................ⅱ

목    차..........................................................................................................................ⅲ

그림목차..........................................................................................................................ⅴ

표 목 차..........................................................................................................................ⅵ

제 1장 서 론...................................................................................................................1

1.1 연구의 배경............................................................................................................1

1.2 연구의 목적............................................................................................................4

1.3 논문의 구성............................................................................................................5

제 2장 이론적 배경 및 관련 연구.............................................................................6

2.1 프로젝트 관리(Management)에 관한 고찰.....................................................6

2.2 프로젝트 관리 시스템(PMIS)에 관한 고찰...................................................18

제 3장 연구 설계 및 접근 방법...............................................................................21

3.1 연구방법................................................................................................................21

3.2 접근방법................................................................................................................22

제 4장 연구 분석 및 결과.........................................................................................32

4.1 기초 데이터의 분석............................................................................................32

4.2 연구 분석..............................................................................................................38

제 5장 요약 및 결론...................................................................................................44

참고문헌.........................................................................................................................48

감사의 글.......................................................................................................................53

<그림 1-1> 소프트웨어 시장 규모 추이				.........................................................					1
<그림 1-2> SW공학 주요 영역별 국내 수준						..................................................			2
<그림 1-3> PMBOK 5th, ISO-21500 비교 및 대응							.........................................		11
<그림 3-1> 연구 모형	............................................................................................								21
<그림 3-2> PMS 선정 기준 참고 자료			............................................................						23
<그림 3-3> 이슈 데이터 수집 분포 현황					.....................................................				27
<그림 3-4> 형상 데이터 수집 분포 현황					.....................................................				29
<그림 3-5> 이슈 추적 및 동료 리뷰 데이터 수집 분포 현황								...............	31
<그림 4-1 > 표본 데이터 분포		............................................................................							33
<그림 5-1> 향후 연구 모형과 소프트웨어 프로젝트 모형도								...............	47

그 림 목 차

[표 2-1] 프로젝트관리 지식 및 단위프로세스 정의 ....................								........................			8
[표 2-2] 프로젝트관리 지식 및 단위프로세스 정의 ........							.....................................				10
[표 2-3] CMMI 모델의 프로세스 영역 분류			........................................................								12
[표 2-4] CMM의 프로세스 레벨별 상세 및 KPA						................................................					13
[표 2-5] CMMI 프로세스 영역과 PMBOK 지식영역 대응 구분								........................			15
[표 2-6] Mapping CMMI to PMBOK ...........				......................................................							16
[표 2-7] PMS 기능 기준 주요 연구 목록 ..................................								........................			19
[표 3-1] Code Commit Comment 규칙 변화 .................................										....................	25
[표 3-2] 이슈(Issue)와 위험(Risk)의 상관관계					.................................................						25
[표 3-3] 이슈 데이터 수집 결과 ........................					.................................................						26
[표 3-4] 형상 데이터 수집 결과 .............		............................................................									28
[표 3-5] 이슈 추적 및 동료 리뷰 데이터 수집 결과 ..................								........................			30
[표 4-1] 케이스 처리 요약 결과	....................................................................										34
[표 4-2] 기술 통계 결과 .............................			........................................................								34
[표 4-3] 정규성 검정 결과 .......................................................								........................			36
[표 4-4] 검정 결과 도표 ............................................................									.........................		37

표 목 차

[표 4-5] 신뢰도 분석 결과 도표 ....................................................								......................					38
[표 4-6]가설 설정 .....................................................................................											..........		38
[표 4-7] 독립 표본 T 검정에 대한 검정결과 ( 이슈 연결율 ) ............										...............			39
[표 4-8] 독립 표본 T 검정에 대한 검정결과 정리 ( 이슈 연결율 ) ...........												.........	40
[표 4-9] 독립 표본 T 검정에 대한 검정결과 ( 동료 리뷰율 )									..................				41
[표 4-10] 독립 표본 T 검정에 대한 검정결과 정리 ( 동료 리뷰율 )												.........	42
[표 4-11] 가설 검․추정 결과			.........................................................................										43

제 1장 서 론

제 1장은 서론으로 연구 배경과 목적을 서술하고, 본 논문의 구성에 대해

설명하였습니다.

1.1 연구의 배경

어플리케이션은 이제 비즈니스 전 영역에 걸쳐 핵심전인 존재로 자리 잡았다. 어플리케이션 요구 수집 및 기획 단계에서부터 개발, 테스트, 배포, 관리에 이르는 어플리케이션 생애 주기개념 및 프로젝트 관리 개념이 등장하게 된 배경이며, 현재는 “글로벌 소프트웨어 시장이 연간 4~5%씩 꾸준히 성장하고 있다. 어느덧 전 세계 시장 규모는 1조 1,000억 달러에 이른다. 국내 시장 또한 매년 4% 이상의 성장률을 유지하며 113억 달러, 한화로 100조 원 규모를 형성하고 있다.” <그림 1-1>에서 보는 바와 같다(소프트웨어 시장규모추이, 2013).

<그림 1-1> 소프트웨어 시장 규모 추이  (출처 : IDC, 유진투자증권, 2014)

이는 비지니스의 확장을 의미하고, 어플리케이션 규모의 증가로 이어진다. 또한 어플리케이션 규모의 증가는 복잡성의 증가를 야기하며, 정교함을 기반으로 효율적으로 지원하고, 관리하는 소프트웨어의 필요성이 증대되어, PMS(Project Management System, 이하 PMS)는 과거의 업무보조 수단에서 벗어나 시장 조사 및 제품 개발, 생산, 판매 계획 수립 등 기업의 모든 업무가 프로젝트 단위로 실행되고 있으며, 현재 기업에서는 프로젝트 관리 시스템(PMS: Project Management System)을 도입하고 있으며(정두진,2004), 프로젝트의 성공을 위한 필수적인 도구 중의 하나로 인식되고 있다.

이처럼 현재 프로젝트 관리 솔루션 비즈니스는 성장기 중에 있으며, 기존에 도입한 사례를 살펴보아도 PMS는 단위 프로젝트의 관리를 통한 생산성 향상 및 비용절감 뿐만 아니라 기업의 위기관리를 위한 대안으로 제시되어 왔다(정두진,2004).

2013년 정보통신산업진흥원 소프트웨어공학센터가 발간한 SW공학백서에 따르면 우리나라의 경우 <그림 1-1>에 따르면 기술 부문에서는 만족도가 대단히 높다. 100점 만점에 80점에 근접해 있으며 이는 CMM레벨로 따질 때 2,3,4 정도의 수준에 해당한다. 반면 관리 부문은 60점대 초반, 또는 그 이하의 수준에 머무른 것으로 나타났다.

<그림 1-2> SW공학 주요 영역별 국내 수준  (출처 : SW 공학백서, 2013)

소프트웨어 시장이 꾸준히 성장하고 있는 가운데, 바로 관리 부문에서 병목 현상이 나타나고 있는 것이다. 특히 소프트웨어 제품 개발 프로젝트는 제품의 안정성과 목적, 기능이 품질의 척도가 되므로 프로젝트를 지원하는 정보시스템의 중요성이 부각되고 있으며, 프로젝트 효율적인 관리는 소프트웨어 제품 개발 프로젝트의 성패를 좌우하는 중요한 요소로 부각되고 있다.

하지만, <그림 1-2>에 따르면 여전히 공유되지 못하는 파일의 형태로 프로젝트를 관리하고 있으며, 이로 인하여 “관리를 위한 관리” 작업이 수반되고 있는 실정이다.

<그림 1-3> SW공학 진척관리도구 적용 현황  (출처 : SW 공학백서, 2013)

요구 수집, 기획 단계에서부터 구현, 배포, 관리에 이르는 전 과정을 효율적으로 지원한다는 ‘프로젝트 관리 시스템’(PMS)이라는 개념이 대두되고 공감을 얻어가는 시대적 요인이 바로 이것이다.

PMS는 CMMI, PMBOK와 같은 글로벌 모델이 권고하는 기준을 기반으로 주요 기능이 구현되어있으며, PMS적용에 따른 효과는 정성적, 정량적 효과로 구분할 수 있다. 대표적인 정성적 효과로는 SW개발 기업의 이미지 및 경쟁력 향상이며, 아울러 대표적인 정량적 효과로는 프로젝트 수행 현장의 이슈 추적성을 제공하고, 자동화된 관리 지표 산출과 이로 인한 프로젝트의 결함 및 잠재적 문제를 관리하여 품질을 향상하는데 있다. 이에 현장에서 PMS를 도입하고 사용하고 있으나, 실증적이고, 정량적 효과를 증명하기 위한 “PMS 도입 이전과 이후”에 대한 프로젝트 관리 성과 지표 변화를 관리 지표 대상으로 분석한 연구는 없는 실정이다.

1.2 연구의 목적

본 연구는 SW개발 현장에서 PMS를 선정 및 도입하고 활용하는 학술적기반의 현실적인 프로젝트 관리 지표를 기준으로 한 실증적인 조사 및 분석에 대한 연구가 부족하고, PMS 활용 이전과 이후의 프로젝트 관리 지표 항목을 기준으로 정량지표를 수집, 분석하여 PMS의 도입 및 활용이 프로젝트 관리 지표에 어떠한 영향을 끼치는지에 대한 연구는 이루어지지 않고 있다.

이러한 문제를 토대로 하여, 본 연구에서 알아보고자 하는 바는 다음과 같다. SW 개발 현장에서 PMS를 선정하고 기업의 전사 업무에서 활용하고, 프로젝트 관리 지표를 선정하여, 활용 전과 후를 비교, 분석 후 프로젝트 성과지표에 어떤 변화가 있는지, 객관적인 기준에 의한 통계 검 추정을 하는 것이다.

따라서 PMI(The Project Management Institute)의 프로젝트 관리 지식체계(PMBOK)와 능력 성숙도 모형 결합(CMMI)에 대한 개념적 고찰과 관리활동 기준을 분석하고, 평가항목을 선정 후 고려해야 할 요인들을 도출하여 제품 개발 프로젝트에서 PMS를 선정 및 도입, 활용 후. PMBOK과 CMMI를 대응하여 분류한 기준으로 프로젝트 성과 관리 지표를 선정 후, 객관적이고 정량적인 데이터 확보를 통하여 도입이전의 데이터와 도입 이후의 데이터를 분석, 통계적 방법으로 변화를 증명하였다.

이 연구를 통해 PMS에 대한 인식제고와 프로젝트 관리 평가 기준을 근거로 PMS의 도입으로 프로젝트의 성공적인 수행에 도움이 되고자 한다. 또한 국내 소프트웨어 제품 개발 기업의 경쟁력 제고와 SW개발 및 관리에 대한 개선방향의 식별에 도움이 되고자 한다.

1.3 논문의 구성

본 논문은 총 5장으로 구성하였다.

제 1장은 서론으로 본 연구의 배경 및 목적에 대해 설명하고, 연구 논문의 구성 체계를 설명하였다.

제 2장에서는 문헌 조사와 관련 연구로서, 프로젝트 관리에 대한 연구와 프로젝트 관리 성과 지표에 대한 연구를 기준으로 PMBOK과 CMMI를 세부항목으로 구분지어 프로젝트 관리 평가 기준을 기존 문헌과 연구로 고찰하였다.

또한 PMS에 대한 연구를 기준으로 PMS에 대한 개념, 기능 구성에 대하여 기존 문헌과 연구로 고찰하였다.

제 3장에서는 연구 개요를 서술하고, 연구 모형을 제시한다.

PMBOK과 CMMI의 대응을 통해 프로젝트 관리 지표 항목을 선정하고, 선정된 PMS를 사용하여 대응 항목을 제공하는 요소 데이터 범주를 구분지어, 연구모형을 이행한다.

이어서 PMS를 활용한 표본자료의 수집과 분석 방법에 대해 서술하였다.

제 4장에서는 표본자료의 특성을 서술하고, 연구 모형을 검증하기 위하여 표본자료의 통계적 활용 가치를 증명하기 위한 기초 통계를 수행, 수집 데이터의 통계적 검․추정을 실시하기 위한 신뢰성을 확보했다.

분석결과를 PMBOK과 CMMI의 대응 및 선정 한 세부항목별로 연구가설을 대입하여 실증적으로 증명하였다. 또한 표본자료를 이용해 가설에 대한 검․추정을 실시하여 통계적으로 증명하였다.

마지막으로 제 5장에서는 요약 및 결론으로 연구 결과에 대한 요약과 향후 연구의 시사점을 서술하였다.

제 2 장 이론적 배경 및 관련 연구

제 2장에서는 프로젝트와 프로젝트 관리에 대한 고찰 및 프로젝트 관리 시스템 및 관련 연구에 대해 고찰한다.

2.1 프로젝트 관리(Management)에 관한 고찰

2.1에서는 프로젝트와 프로젝트 관리에 대한 고찰로 프로젝트에 대한 정의와 프로젝트 관리에 대해 접근한다.

2.1.1 프로젝트(Project)의 정의

프로젝트는 “고유한 제품, 서비스 또는 결과물을 창출하기 위해 한시적으로 투입하는 노력 (A temporary endeavor undertaken to create a unique product, service, or result)”으로 정의한다(PMI PMBOK, 2013).

PMI의 정의 외에도 프로젝트를 정의함에 Duncan(2000)은 “독특한 생산품이나 서비스를 창출해내기 위해 행하는 일시적인 노력”으로 정의하였다.

PMI(Project Management Institute)에서는 프로젝트의 특성을 다음과 같이 정의한다. “한시적이다(Temporary), 독특하다(Unique), 점진적 구체화(Progressively Elaboration)”로 정의된 세 가지 속성 이외에도 구체적인 목적(specific objective)을 가지고 있으며, 자금의 한계(Funding Limit)가 있으며, 인적자원 및 비인적자원을 소비하고, 다기능적(multifunctional)인 속성들이 포함된다고 정의하였다.(Kerzner, 2009).

또한, Turner(1993)는 프로젝트를 정성적, 정량적 목표에 의하여 정의된 유익한 변화를 얻기 위해서 비용과 기간의 계약조건하에서 주어진 규격의 독특한 업무를 수행하기 위하여 인력, 자재, 재정적 자원을 새로운 방법으로 조직화하는 노력이라고 정의했다.

2.1.2 프로세스(Process)의 정의

프로세스(Process)란 원하는 제품이나 결과 또는 서비스를 달성하기 위하여 수행되는 서로 연관된 처리나 활동의 묶음이라 할 수 있고, 부연 설명하면 한 개 이상의 입력을 통해 가치 있는 산출물을 제공하는 모든 관련 활동들의 집합이라 정의했다( 산업통상자원부 기술표준원, 2013 ).

이외에도 조형식(2008)은 프로세스(Process)란 서로 연관성 있는 활동(Activity)들의 집합체이며, 커다란 프로세스는 한 개 이상의 부 프로세스(Sub-Process)를 가진다. 그리고 이 부 프로세스는 여러 개의 활동(Activity)들을 가지며, 이러한 활동 더 작고 간단한 임무(Task)로 나누워진다. 이러한 임무는 아주 단순 단계(Step)로 구성되어있으며, 특정한 목적을 가진 여러 개의 프로세스 집합을 일상적으로 시스템이라고 부른다.

프로세스를 공정(Process), 절차(Procedure), 업무흐름(Workflow)등을 혼용하여 사용한다. 공정이란 산출물(Output)이 목적이지만 절차는 반드시 산출물이 필요한 것은 아니고 과업의 완수가 목적이다. 업무흐름은 반복성이 있고 재사용이 가능한 복수의 공정과 절차의 혼합된 업무표현이라고 생각된다. 참고로 차이점은 절차(Procedure)는 과업(Task)의 완수가 목적, 실행에 초점, 서로 다른 복수의 목표를 가질 수 있다. 공정(Process)은 목표산출물의 달성이 목적이며, 운용에 초점을 두고 단일 목표를 가지는 것이라고 정의했다.

2.1.3 프로젝트 관리(Project Management)의 정의

프로젝트 관리에 대하여 ISO-21500에서는 “프로젝트의 목표 달성을 위하여 수행되는 고유한 프로세스의 집합으로 구성되며, 프로세스는 시작일과 종료일이 정해져 있고, 조정되고, 통제되는 활동”이라고 정의하였다.

또한 PMI PMBOK(2013)에서는 프로젝트 관리(Project Management)란 프로젝트의 요구사항을 충족시키기 위해 지식, 기술, 도구, 기법 등을 프로젝트 활동에 적용하는 것이며 프로젝트관리는 47개의 논리적인 프로세스를 적용하고 통합하여 수행되며, 이 프로젝트 관리 프로세스는 착수(Initiating), 계획(Planning), 실행(Executing), 감시 및 통제(Monitoring & Controlling), 종료(Closing)의 5개 그룹으로 이루어져 있다. 프로젝트 관리는 통합(Integration)관리, 범위(Scope)관리, 시간(Time)관리, 원가(Cost)관리, 인적자원(Human Resource)관리, 품질(Quality)관리, 의사소통(Communication)관리, 위기(Risk)관리, 구매조달(Procurement)관리, 이해관계자(Stakeholder)관리의 10가지 지식 지식영역으로 이루어져 있다고 정의했다.

2.1.4 프로젝트 관리 및 프로세스에 관한 고찰

2.1.4.1 ANSI/PMI PMBOK에 대한 고찰

프로세스(process)란 미리 정의된 제품, 결과 혹은 서비스를 달성하기 위해 수행되는 서로 연관이 있는 action 혹은 활동(activities)들의 집합이다.  프로젝트 관리는 프로젝트의 요구사항을 만족시키기 위해 지식, 기술, 도구, 기법들을 프로젝트 활동에 적용하는 것이며, 이러한 지식의 적용을 위해서는 적절한 프로젝트 관리 프로세스들의 적용을 필요로 한다(PMI PMBOK, 2013).

PMBOK 5th에서 제시하는 10개의 프로젝트 관리 지식 영역과 단위 프로세스 정의는 아래 [표2-1]과 같다.

[표 2-1] 프로젝트관리 지식 및 단위프로세스 정의

영 역	Process 정 의	단위 Process
프로젝트통합관리 (Project Integration Management)	프로젝트의 다양한 요소를 적절하게 통합조정 하기위해 필요한 프로세스	프로젝트 차터 작성, 프로젝트 관리 계획서 작성, 프로젝트 실행관리, 프로젝트 모니터링 및 통제, 통합 변경 통제, 프로젝트 단계종료
프로젝트범위관리 (Project Scope Management)	프로젝트에 꼭 필요한 업무정의와 프로젝트의 성공을 위한 프로세스로 프로젝트의 성공적인 완결을 위한 프로세스	요구사항수집, 범위정의, WBS작성, 범위검증, 범위통제
프로젝트일정관리 (Project Time Management)	프로젝트 납기 준수를 위해 필요한 프로세스로 프로젝트를 주어진 시간 내에 완성하는 것을 확인하기 위한 프로세스	활동정의, 활동 연관관계 정의, 활동 자원 추정, 활동기간 추정, 일정계획 수립, 일정통제
프로젝트원가관리 (Project Cost Management)	승인된 예산 내에 프로젝트를 완료하기 위해 필요한 프로세스	원가견적, 예산확정, 원가통제
프로젝트품질관리 (Project Quality Management)	프로젝트가 요구하는 사항을 만족시켜 주는지를 보증하기 위해 파악하는 프로세스	품질관리 계획수립, 품질보증 수행, 품질통제 수행
프로젝트 인적자원 관리 (Project Human Resource Management)	프로젝트 팀원을 대상으로 책임과 역할을 정의한 뒤 목표를 달성할 수 있도록 팀원들을 관리하는 프로세스로 프로젝트에 관계하는 인력을 가장 잘 활용하기 위해 요구되는 프로세스	인적자원 계획 수립, 프로젝트 팀원 확보, 프로젝트 팀 개발, 프로젝트 팀원 관리
프로젝트의사소통관리(Project Communication Management)	이해관계자 관심사항을 분석하여 원하는 정보를 제공하고, 이해관계자 기대사항을 관리하는 프로세스	인적자원 계획 수립, 프로젝트 팀원 확보, 프로젝트 팀 개발, 프로젝트 팀원 관리
프로젝트위기관리 (Project Risk Management)	프로젝트의 위기를 체계적으로 식별, 분석, 대응, 통제하는 프로세스	위기관리 계획수립, 위기인식, 정성적 위기분석, 정량적 위기분석, 위기 대응 계획수립, 위기 모니터링 및 통제
프로젝트 구매조달관리 (Project Procurement Management)	고정 조직의 외부에서 제품이나 서비스 확보를 위해 필요한 프로세스로 프로젝트 이행조직 외부로부터 재화나 서비스를 획득하기 위해 요구되는 프로세스	구매조달 계획 수립, 구매조달 실행, 구매조달 관리, 계약 종료
프로젝트 이해관계자 관리 (Project Stakeholder Management)	프로젝트에 영향을 주거나 프로젝트의 영향을 받을 수 있는 모든 사람, 집단 또는 조직에 대한 식별, 이해관계자의 기대사항과 프로젝트에 미치는 영향 분석, 프로젝트 의사결정 및 실행에 이해관계자의 효율적인 참여를 유도하기 위한 관리 프로세스	이해관계자 식별, 이해관계자관리 계획수립, 이해관계자 참여관리, 이해관계자 참여통제

(출처 : PMI PMBOK, 2013)

또한, ISO-21500에서는 동일한 목적인 “프로젝트를 성공적으로 실행하는데 있어 중요한 프로젝트 관리 개념 및 프로세스에 대한 일반적인 지침을 제공”하고 있으며, 표<2-2>를 통하여 PMBOK 4th, ISO-21500, PMBOK 5th 을비교 분석한 자료를 근거로, <그림 2-1>은 5개의 프로세스 그룹과 10개의 주제 그룹과 39개의 프로세스를 PMBOK 5th에 대응하였다.

[표 2-2] 프로젝트관리 지식 및 단위프로세스 정의

	PMBOK® Guide 4th	ISO 21500	PMBOK® Guide 5th
Process Groups	1. Initiating 2. Planning 3. Executing 4. Monitoring & Controlling 5. Closing	1. Initiating 2. Planning 3. Implementing 4. Controlling 5. Closing	1. Initiating 2. Planning 3. Executing 4. Monitoring & Controlling 5. Closing
Knowledge Areas	1. Integration 2. Scope 3. Time 4. Cost 5. Quality 6. Human Resource 7. Communications 8. Risk 9. Procurement	1. Integration 2. Scope 3. Time 4. Cost 5. Quality 6. Resource 7. Communication 8. Risk 9. Procurement 10. Stakeholder	1. Integration 2. Scope 3. Time 4. Cost 5. Quality 6. Human Resource 7. Communications 8. Risk 9. Procurement 10. Stakeholder
Stages	5 process groups	5 process groups	5 process groups
Topics	9 knowledge areas	10 subject groups	10 knowledge areas
Processes	42 processes	39 processes	47 processes

(출처 : STS Sauter Training & Simulation S.A., www.sts.ch, 2010)

<그림 2-1> PMBOK 5th, ISO-21500 비교 및 대응

2.1.4.2 CMMI 모델의 프로젝트 관리 프로세스 고찰

미국 카네기멜론 대학의 소프트웨어공학연구소가 미 국방성의 요청으로 연구 개발한 CMMI 모델의 현재 버전 1.3은 총 22개의 프로세스 영역으로 구성되어 있으며, 소프트웨어 프로젝트의 성공 가능성을 높이고 위험을 최소화하기 위하여 개발되었다. 이러한 CMMI 모델은 CMM 모델간의 상호 중복성과 구조적 차이 등의 문제가 발생하여 CMM의 여러 모델을 하나로 통합한 CMMI 모델이 2001년 발표되었으며, ISO/IEC 15504 표준과의 호환성을 갖춘 모델로 통합된 평가 방법을 제공한다(이진국, 2005).

CMMI 모델의 22개의 프로세스 영역들은 프로젝트 관리, 지원, 프로젝트 관리, 엔지니어링으로 분류되며, 총 4개의 분류 영역으로 다음의 [표 2-3]와 같이 구성 되어 있고, 프로젝트 관리 그룹은 7개의 프로세스들로 구성되어 있다(Carnegie Mellon University SEI CMMI product team,2010).

[표 2-3] CMMI 모델의 프로세스 영역 분류

프로세스 분류	프로세스 영역
Process Management (프로세스 관리)	조직 프로세스 중점 (Organizational Process Focus)(OPF) 조직 프로세스 정의 (Organizational Process Definition)(OPD) 조직 훈련 (Organizational Training)(OT) 조직 프로세스 성과 (Organizational Process Performance)(OPP) 조직 혁신 및 이행 (Organizational Innovation and Deployment)(OID)
Support (지원)	형상관리 (Configuration Management)(CM) 프로세스 및 제품 품질보증 (Process and Product Quality Assurance)(PPQA) 측정 및 분석 (Measurement and Analysis)(MA) 통합을 위한 조직 환경 (Organizational Environment for Integration) (OEI) 결정분석 및 해결 (Decision Analysis and Resolution)(DAR) 원인분석 및 해결 (Causal Analysis and Resolution)(CAR)
Project Management (프로젝트 관리)	프로젝트 계획 (Project Planning) (PP) 프로젝트 감시 및 통제 (Project Monitoring and Control)(PMC) 공급자 계약 관리 (Supplier Agreement Management)(SAM) 통합 프로젝트 관리 (Integrated Project Management)(IPM) 요구사항 관리(Requirements Management)(REQM) 위험관리 (Risk Management)(RSKM) 통합팀 (Integrated Teaming)(IT) 정량적 프로젝트 관리 (Quantitative Project Management)(QPM)
Engineering (엔지니어링)	요구사항 개발 (Requirements Development)(RD) 기술 솔루션 (Technical Solution)(TS) 제품통합 (Product Integration)(PI) 검증 (Verification)(VAL) 확인 (Validation)(VER)

(출처 : Carnegie Mellon University, 2010)

CMM은 소프트웨어 프로세스를 성숙시키기 위해 사용되는 잘 정의된 진화모형으로써 5개의 성숙도 단계를 가지고 있다(Paulk, 1993).  [표2-4]는 CMM의 각 성숙도 단계와 단계별 특성을 나타낸 것이다.

[표 2-4] CMM의 프로세스 레벨별 상세 및 KPA

레벨	소프트웨어 프로세스 성숙도 레벨 5단계
레벨 1 Initial 초기수준	개인의 역량에 따라 프로젝트의 성공과 실패가 좌우된다. 소프트웨어 개발 프로세스는 거의 없는 상태를 의미한다.
	표준화된 프로세스가 없어서 수행결과 예측이 곤란한 조직
	KPA	없음
레벨 2 Managed 관리수준	프로세스 하에서 프로젝트가 통제되는 수준으로 조직은 프로세스에 대한 어느 정도의 훈련이 되었다고 볼 수는 있지만, 일정이나 비용과 같은 관리 프로세스 중심이다. 기존 유사 성공사례를 응용하여 반복적으로 사용한다.
	기본 프로세스 구축에 의해 프로젝트가 관리되고 있는 조직
	KPA	요구사항 관리 소프트웨어 프로젝트 계획 수립 소프트웨어 프로젝트 추적 소프트웨어 외주관리 소프트웨어 구성관리 소프트웨어 품질 보증
레벨 3 Defined 정의수준	레벨 2에서는 프로젝트를 위한 프로세스가 존재한다면 레벨 3에서는 조직을 위한 표준 프로세스가 존재한다. 모든 프로젝트는 조직의 프로세스를 가져다 상황에 맞게 조정하여 승인받아 사용한다.
	세부 표준 프로세스가 있어 프로젝트가 통제되는 조직
	KPA	조직 프로세스 지향 조직 프로세스 정의 교육 프로그램 통합 소프트웨어 관리 소프트웨어 제품 엔지니어링 그룹간 조정 동료 검토
레벨 4 Quantitatively Managed 정량적 관리수준	소프트웨어 프로세스와 품질에 대한 정량적인 측정이 가능해진다. 조직은 프로세스 데이터베이스를 구축하여 각 프로젝트에서 측정된 결과를 일괄적으로 수집하고 분석하여 품질평가를 위한 기준으로 삼는다.
	프로젝트 활동이 정략적으로 관리․통제되고 성과 예측이 가능한 조직
	KPA	정량적인 프로세스 관리 소프트웨어 품질 관리
레벨 5 Optimizing 최적화 수준	이 레벨에서는 지속적인 개선에 치중한다. 조직적으로 최적화된 프로세스를 적용하여 다시 피드백을 받아 개선하는 상위 단계이다.
	지속적인 개선활동이 정착화 되고 최적의 관리로 프로젝트가 수행되는 조직
	KPA	결함 예방 기술 변경 관리 프로세스 변경 관리

(출처 : Paulk, 1993; Carnegie Mellon University, 2010, 연구자 보완, 2016 )

2.1.4.3 PMBOK 과 CMMI 대응 고찰

본 장에서는 CMMI의 각 영역을 PMBOK의 지식영역과 비교 분석하여 각각의 영역을 서로 대응시킨 결과를 설명하고 또한 프로젝트를 체계적이고 객관적으로 관리할 수 있는 소프트웨어 매트릭스에 대해서 고찰한다.

CMMI는 프로젝트 프로세스를 포함한 전사조직관점의 프로세스 측면에서 품질(Quality) 및 생산성(Productivity) 향상을 추구하는 모델이고 PMBOK는 순수 프로젝트 관점에서 관리측면을 다룬다는 차이점이 있다( 이돈희외 . 2009).

기본적인 프로젝트 관리 프로세스가 확립되어 있는 CMMI 레벨2의 프로세스 영역과 프로젝트 관리를 위한 PMBOK의  10가지 지식영역을 <표 2-5>와 같이 서로 대응시켰다(김경환, 2005).

CMMI		PMBOK
성숙도 레벨	프로세스 영역	지식영역	개요
레벨2 : 반복 가능 레벨	요구 관리	스코프	요구사항 중 프로젝트 스코프에 관한 계획과 관리
	프로젝트 계획 책정	통합, 스코프, 시간, 비용, 품질, 획득, 인적자원, 리스크, 커뮤니케이션	각 영역의 계획 및 프로젝트 계획서 작성
	프로젝트 감시와 제어	커뮤니케이션, 리스크	진척관리와 리스크 감시
	공금자 합의관리	이해관계자, 획득	발주처 선정과 관리
	프로세스와 제품의 품질보증	품질	품질계획과 품질보증
	구성 관리	통합 (변경관리)	구성관리
	측정과 분석	-	(전반적으로 사용)

[표 2-5] CMMI 프로세스 영역과 PMBOK 지식영역 대응 구분

(출처 : CMMI와 PMBOK의 비교 분석을 통한 정량적 프로젝트 관리, 2005 )

상기 표[2-4]에서처럼 CMMI 레벨2의 6개 프로세스 영역(측정과 분석 제외)을 기준으로 PMBOK의 각 지식영역을 비교 분석한 결과 실제 CMMI의 각 영역이 PMBOK의 지식영역과 모순 없이 서로 대응 될 수 있음을 알 수 있다. ( 김경환, 2005 )

다음 [표 2-6]는 Yassine Rdiouat, Naima Nakabi, Khadija Kahtani, Alami Semma(2012)가 분석한 CMMI 모델을 구성하는 전체 22개의 프로세스 영역이 미국 PMI에서 개발한 프로젝트관리 지식체계(PMBOK 4th )의 9개 관리영역과 직⦁간접적으로 서로 관련됨을 확인 할 수 있는 표이다.

[표 2-6] Mapping CMMI to PMBOK

PMBOK		CMMI
4. Project Integration Management	4.1 Develop Project Charter	IPM, GP2.1
	4.2 Develop Project Management Plan	PP, IPM, REQM, CM, GP2.1, 2.2, 2.3, 2.6
	4.3 Direct and Manage Project Execution	REQM, IPM, CM , PP, IPM , GP2.1, 2.6
	4.4 Monitor and Control Project Work	PMC, MA, GP2.8
	4.5 Perform Integrated Change Control	PMC, CM, IPM, GP2.10
	4.6 Close Project or Phase	IPM, GP3.2
5. Project Scope Management	5.1 Collect Requirements	REQM
	5.2 Define Scope	RD
	5.3 Create WBS	PP
	5.4 Verify Scope	RD
	5.5 Control Scope	PMC
6. Project Time Management	6.1 Define Activities	PP, IPM
	6.2 Sequence Activities	PP, IPM
	6.3 Estimate Activity Resource	PP, IPM, GP2.3
	6.4 Estimate Activity Durations	PP, IPM
	6.5 Develop Schedule	PP, IPM
	6.6 Control Schedule	PMC
7. Project Cost Management	7.1 Estimate Costs	PP, GP 2.3
	7.2 Determine Budget	PP
	7.3 Control Costs	PMC
8. Project Quality Management	8.1 Plan Quality	PPQA, RD, MA, QPM, VER, VAL, OPP
	8.2 Perform Quality Assurance	PPQA, RD, MA, QPM, VER, VAL, GP2.6,2.9
	8.3 Perform Quality Control	PPQA, PMC, PMC, MA, CM, VER, VAL, OPP, GP2.8, 2.9, 2.10
9. Project Human Resource Management	9.1 Develop HR plan	IPM,PP,OT, GP2.2
	9.2 Acquire project Team	IPM
	9.3 Develop Project Team	IPM, OT, GP2.5, 2.7
	9.4 Manage Project Team	IPM, GP2.7
10. Project Communications Management	10.1 Identify Stakeholders	PP, REQM , GP2.4, 2.7
	10.2Plan Communications	IPM, REQM
	10.3 Distribute Information	IPM, GP2.7
	10.4 Manage Stakeholder expectations	IPM, REQM, GP2.7
	10.5 Report Performance	PMC
11.Project Risk Management	11.1 Plan Risk Management	RSKM, GP2.2
	11.2 Identify Risks	RSKM, PP
	11.3 Perform Quantitative Risk Analysis	RSKM, PP
	11.4 Perform Qualitative Risk Analysis	RSKM, PP
	11.5 Plan Risk Responses	RSKM
	11.6 Monitor and Control Risks	RSKM, PMC
12.Project Procurement Management	12.1 Plan Procurement	SAM, GP2.3
	12.2 Conduct Procurements	SAM
	12.3 Administer Procurements	SAM
	12.4 Close Procurements	IPM, GP3.2

(출처 : Towards a new approach of continuous process improvement

based on CMMI and PMBOK, 2012 )

2.2 프로젝트 관리 시스템(PMS)에 관한 고찰

2.2에서는 프로젝트 관리 시스템에 대한 고찰로 프로젝트 관리 시스템에 대한에 대한 정의와 목적 및 기능에 대해 접근한다.

2.2.1 프로젝트 관리 시스템의 정의

초기의 프로젝트 관리시스템은 전통적인 관리위주의 성격이었으나 자원 관리적 측면과 위험분석, 민감도 분석 등이 제시되면서 1980년 초기에 현대적 프로젝트 관리시스템으로 변화되었다. 소프트웨어 공학적 연구가 대두되면서 자원, 환경, 기술 등을 관리할 수 있는 모델이나 절차 등에 관한 연구, 소프트웨어 개발 비용 산정에 관한 연구 등을 중심으로 현대적 프로젝트 관리시스템이 도출되게 되었다(Bienkowski, 1998: Burrill, 1980).

이후 PMS를 “성공적인 프로젝트 관리에 필요한 여러 요소 중 프로젝트 관리 시스템은 IT 프로젝트를 수행하면서 계획된 시간과 예산 등 최적의 자원을 활용하여 사용자가 만족할 만한 품질의 시스템을 구축하는 데 필요한 관리적 활동을 지원하는 소프트웨어”으로 정의했다.(이영희 외, 2006).

이 외에도 PMS를 정의함에 있어 환경 요인의 일부로서 프로젝트관리 정보시스템을 통해 일정 관리 도구, 작업 승인 시스템, 형상 관리 시스템，정보 수집 및 배포 시스템과 같은 도구 또는 기타 온라인 자동 시스템에 접근할 수 있다. 핵심성과지표(KPI)에 대한 자동화된 수집 및 보고가 이 시스템의 일부일 수 있다. 즉 PMS는 프로젝트를 관리하는데 사용되는 도구, 기법, 방법론, 자원, 절차들의 집합체를 의미하며, 프로젝트 관리자가 프로젝트를 성공적으로 추진하기 위한 중요한 도구(PMI, 2013)로 정의할 수 있다.

2.1.2 프로젝트 관리 시스템의 목적 및 기능

옹상순(2009)은 최근 정보화 프로젝트분야의 급성장으로 인해 많은 기업들이 사업목표 달성을 위해 체계적인 프로젝트관리시스템(Project Management System, 이하 PMS)에 많은 투자를 하고 있고, 특히 기업들은 미국의 프로젝트 관리협회(PMI)에서 발표한 프로젝트 관리를 위한 핵심지식체계인 PMBOK(Project Management Body of Knowledge)을 기반으로 한 프로젝트관리도구 개발 및 구축에 많은 투자를 하고 있으며, 이를 통해 프로젝트 관리 비용을 절감하고 사업수행을 극대화 하고자 노력하고 있다고 정의했다.

프로젝트의 계획, 공고, 신청, 평가, 선정, 과제종료 등 프로젝트의 전 수명주기에 걸쳐 일정관리, 각종 평가, 예산의 통제, 관련 통계의 산출 및 분석 등의 업무가 PMS에 의해 수행된다.(김석훈외,2009)

그리고 가장 최근에 전형권(2015)은 프로젝트 관리 시스템(PMS)은 PMBOK 및 CMMI 글로벌 모델 기반이 권고하는 모범 사례를 기반으로 주요 기능이 정의되고 구현되고 있다고 정의하였다.

PMS의 기능을 PMO의 필수기능 기준으로 분류하여 기능에 대입하면 [표 2-7] 과 같다(정천수 외, 2011).

[표 2-7] PMS 기능 기준 주요 연구 목록

PMS 기능	기능 상세 설명	기능 범주	주요 연구
멀티프로젝트관리 프로그램 관리	유연한 멀티 프로젝트 관리 기능	자원통합관리	Hill(2004)
Dashboard 기능	프로젝트의 실시간 현황 파악을 위한 시각적 Dashboard 기능 PMO만의 개인화된 UI	자원통합관리	Hill(2004)
인력자원관리	소속별, 등급별, 투입계획, R&R등에 따른 상세 인력자원 관리 기능	인력관리	Dai and Wells(2004)
요구사항관리	요구사항 추적관리 기능	실행관리	Hill(2004)
의사소통관리 정보공유	회의록과 연계된 실행항목관리 기능	실행관리	Hill(2004)
품질관리	시스템을 통한 품질관리기능	품질관리	Parasuraman et al.(1991)
이슈/리스크관리	PMO가 이슈/리스크를 실시간 모니터링 및 합의할 수 있는 기능	자문, 멘토, 실행관리	Rad and Levin(2002)
일정관리	WBS 일정등록 및 변경관리 기능	실행관리	Hill(2004)
범위변경관리	PMO가 범위변경에 대해 승인 및 합의 할 수 있는 기능	자문, 멘토, 실행관리	Rad and Levin(2002)
산출물관리	WBS와 연계된 산출물 버전관리기능	프로젝트관리표준, 방법론	Dai and Wells(2004)

(출처 : IS프로젝트에서 PMS품질이 성과에 미치는영향 연구, 2012 )

프로젝트 관리 기법의 다양화와 체계적인 개념의 분화로 PMS의 기능도 점차 분산되어 국제적 모델의 표준 관리 Task 대비 PMS 주요 기능 기준이 추가되었으며, 확인된 추가 기능으로는 원가(EVM) 관리, 비용 관리, 생산성 관리, 사용자 관리, 메신저&쪽지 기능이 추가 정의되었다( 전형권외, 2015 )

Paulk(1993)와 Pfleeger(1995)는 “추측이 아니라 사실에 바탕을 둔 의사결정을 위하여 측정은 필요한 도구이다”라고 주장했다.

또한, Cooper and Kleinschmidt(1995), Griffin(1997)은 우수한 기업일수록 명료한 성과측정기법을 R&D에 적용한다고 밝혔다. 그러한 측정도구는 R&D 프로세스와 그 성과를 정량적으로 측정할 수 있게 고안된 일종의 척도로서 결과중심적인 자료를 제공해야 할 것이라고 밝혔다.

제 3장 연구 설계 및 접근 방법

제 3장에서는 연구 및 접근 방법에 대한 고찰로 문헌과 유사연구를 고찰하고, 자료수집과 분석․평가 방법에 대해 고찰한다.

3.1 연구방법

기존문헌 및 관련연구를 기반으로 자료수집과 통계분석을 통한 연구 접근 방법은 <그림 3-1>과 같다.

<그림 3-1> 연구 모형

본 연구는 기존 문헌과 관련 연구로 프로젝트 관리 시스템의 성과 관리 영향도와 미국 PMI의 PMBOK 5th Edition 프로젝트 관리에 대한 세부 활동에 대한 문헌조사 및 미국 카네기멜론대 부설 소프트웨어 공학 연구소(Software Engineering Institute, SEI) CMMI의 소프트웨어 개발 및 유지보수 프로세스를 지속적으로 개선하기 위한 모델의 각 레벨별 목적 등에 대한 이해와 가설 설정에 대한 실증적 데이터 수집 및 통계적 검․추정이 요구되었다.

3.2 접근 방법

3.2.1 분석 방법

SW통계분석에는 spss win.22.1을 사용하였다. 조사대상의 일반적 특성, 프로그램 평가에 대해서는 기초통계, 탐색, 신뢰도, 백분율, 평균, 독립 T 검증 등을 이용하였다. PMBOK 과 CMMI 의 대응을 통한 프로젝트 성과 항목 관련해서는 먼저 PMS 와 SCM(Software Configuration Management : 형상관리시스템)을 통한 자료 수집을 거쳐 개별 수집항목을 요인들로 묶어준 뒤 대응 표본 T 검정을 통해 PMS 적용 전과 적용 후 간의 차이를 살펴보았다. 또한 성과 항목 개별을 대상으로 정규성 검정을 통해 검정치의 신뢰성을 분석하였다.

3.2.2 자료 수집

3.2.2.1 PMS 선정

프로젝트 관리 영역의 일부를 기준하여 활용도와 효용성, 신뢰성에 대한 가트너의 보고서(그림 4)를 활용하여 프로젝트 관리 시스템을 선정 및 구축하여 연구모형에 의거한 데이터를 추출 하였다.

선정기준 분류

1) 소프트웨어 요구사항 정의 및 관리

2) 소프트웨어 변경 및 구성관리

3) 프로젝트 플래닝

4) 버전관리와의 통합

5) 결함관리를 포함한 품질관리를 제공

6) 리포팅 기능, 워크플로우 제공

7) 다른 도구와의 통합 지원 등

<그림 3-2> PMS 선정 기준 참고 자료 (가트너 자료,2015)

또한 실증적이며, 실용을 위한 PMS 선정을 위하여 PMS 기능을 추가적으로 확장 및 기 확장프로그램을 Plugin 할 수 있는 제품을 선택하였다.

3.2.2.2 PMBOK 과 CMMI의 대응 항목 선정

본 연구에서 선정한 PMS를 프로젝트에 적용하여 수집할 데이터 항목을 선정하기 위하여 관련 연구였던, CMMI와 PMBOK 대응항목을 대응 및 구분하여 선정에 대하여 접근한다.

성과 지표 선정 항목

동료 리뷰 : 본 논문에서 선정한 동료 리뷰는 표[2-3]의 CMM의 프로세스 레벨별 상세 및 KPA에 의하여 CMMI 레벨 3의 Defined 정의 수준의 KPA이며, 표[2-2]의 CMMI 모델의 프로세스 영역 분류에서 Engineering(엔지니어링) 프로세스 분류에서 확인 (Validation)(VER) 프로세스 영역에서 동료 리뷰를 다루고 있다. 이는 표 [2-5]의 Mapping CMMI to PMBOK에 의하여 PMBOK대응 항목인 프로젝트품질관리 (Project Quality Management)에 해당하며, 단위 프로세스로는 8.2 Perform Quality Assurance, 8.3 Perform Quality Control 에 해당한다. 즉 동료 리뷰는 CMMI의 엔지니어링 프로세스와 PMBOK의 품질관리영역에 해당하며, 이는 SCM Commit Comment에 의하여 선정된 PMS에서 제공하는 모듈이며, 기존 데이터와의 변화를 추적하기에 용이하므로 선정되었다.

이슈 추적 : 본 논문에서 선정한 이슈 추적은 표[2-3]의 CMM의 프로세스 레벨별 상세 및 KPA에 의하여 CMMI 레벨 2의 Managed 정의 수준의 KPA이며, 표[2-2]의 CMMI 모델의 프로세스 영역 분류에서 Project Management(프로젝트 관리)프로세스 분류에서 확인 요구사항 관리(Requirements Management)(REQM)와  프로젝트 감시 및 통제 (Project Monitoring and Control)(PMC)프로세스 영역에서 이슈 추적을 다루고 있다. 이는 표 [2-5]의 Mapping CMMI to PMBOK에 의하여 PMBOK대응 항목인 프로젝트통합관리(Project Integration Management) 에 해당하며, 단위 프로세스로는 4.3 Direct and Manage Project Executionm, 4.4 Monitor and Control Project Work에 해당한다. 즉 이슈 추적은 CMMI의 프로젝트 관리 프로세스와 PMBOK의 프로젝트통합관리영역에 해당하며, 이는 SCM Commit Comment에 의하여 선정된 PMS에서 제공하는 기본 모듈이며, 기존 데이터와의 변화를 추적하기에 용이하므로 선정되었다.

A사의 PMS의 활용 전․후 형상 관리 규칙 변화는 [표 3-1]과 같다

[표 3-1] Code Commit Comment 규칙 변화

PMS 활용 전	PMS 활용 후
[실행 파일명][실행 파일의 버전] [개발자 성명][BT:버그 번호] [RV:Review 참석자][Review 날짜] [내용]	한 줄 요약 [BT] 이슈 번호 [RV] 리뷰 번호 or 리뷰어 추가 내용

3.2.2.3 이슈 데이터 수집

이슈(Issue) 조작적 정의

프로젝트 진행에 차질을 가져올 수 있는 “발생된(Realized)” 위험이다

[표 3-2] 이슈(Issue)와 위험(Risk)의 상관관계

분류	Issue	Risk
정의	원치 않는 결과를 초래하게 될 발생 가능한 미래의 사건	현재 프로젝트에 장애 혹은 도움이 되는 영향을 미치는 문제
발견 시점	프로젝트 진행 중에 발견될 수도 있으나, 진행 전에 모두 발견해 내는 것을 추구한다.	모든 프로젝트 진행 중에 발견된다.
처리 시점	발견된 후, 당장 해결되지 않아도 프로젝트는 진행 될 수 있다. 일부는 완화전략 이행으로 발생가능성을 통제한다.	발견되면 바로 처리된며, 발생한 이슈를 해결하지 못하면 프로젝트 진행에 차질이 발생한다.

프로젝트를 진행해 나갈 때, 리스크는 피해갈 수 있지만, 이슈의 경우는 이미 발생해 버린 문제점이기 때문에 어떤 형태로든 해결이 되어야 한다. 이슈를 목록으로 정리하고, 우선순위를 정하고, 담당자를 지정하고, 해결 상황을 체크하는 일련의 행위를 이슈관리라고 하고, 이러한 이슈를 적절히 관리하는 기능을 이슈관리기능 혹은 이슈추적기능이라고 한다.

PMS 사용 이전 이슈 데이터는 SCM(코드 저장소)에 개발자의 코드를 커밋(Commit)할 때 이슈의 번호를 기록(Commit Comment)하게 하는 규칙( Subversion Post Function 활용)으로 인하여 PMS 활용과 상관없이 유지되는 속성을 활용하였으며, PMS 활용 이전과 PMS 활용 이후 데이터는 PMS 자체의 기능을 활용하여 구분하여 데이터를 수집 할 수 있었다.

A사 이슈 데이터 수집

날짜	이슈 생성 수	이슈 해결 수	이슈 종료 수	합계
Feb 2013	1814	1196	1100	4110
Mar 2013	2062	1006	896	3964
Apr 2013	3093	2164	1970	7227
May 2013	3207	3003	2749	8959
Jun 2013	2754	1692	1568	6014
Jul 2013	3514	5153	5000	13667
Aug 2013	2713	2625	2439	7777
Sep 2013	2,642	1,289	1,126	5,057
Oct 2013	2,662	2,497	2,359	7,518
Nov 2013	2,834	4,932	4,714	12,480
Dec 2013	2,249	3,126	2,922	8,297
Jan 2014	2,337	1,392	847	4,576
Feb 2014	2,490	2,103	1,502	6,095
Mar 2014	2,777	2,756	2,055	7,588
Apr 2014	2,996	3,085	2,372	8,453
May 2014	2,590	4,088	2,812	9,490
Jun 2014	2,743	2,885	1,849	7,477
Jul 2014	3,167	4,438	3,073	10,678
Aug 2014	2,419	3,151	1,559	7,129
Sep 2014	2,859	3,730	7,267	13,856
Oct 2014	2,813	2,631	2,353	7,797
Nov 2014	2,854	1,853	1,798	6,505
Dec 2014	3,329	2,950	4,059	10,338
Jan 2015	3,005	2,859	3,065	8,929
Feb 2015	2,620	2,435	2,147	7,202
Mar 2015	3,093	3,876	4,460	11,429
Apr 2015	3,523	5,367	9,181	18,071
May 2015	2,726	4,394	4,305	11,425
Jun 2015	3,620	5,675	5,515	14,810
Jul 2015	3,142	3,065	2,887	9,094
Aug 2015	2,825	2,780	3,334	8,939
Sep 2015	2,160	7,261	7,328	16,749
Oct 2015	3198	3421	3620	10239
Nov 2015	3156	3249	3359	9764
Dec 2015	3114	3159	3604	9877
Jan 2016	3373	3141	2642	9156
Feb 2016	3059	2720	2747	8526
Mar 2016	4204	3817	4232	12253
Total	109736	120964	120815	351515

[표 3-3] 이슈 데이터 수집 결과

이슈 데이터 수집 현황을 chart로 식별해 보면 <그림 3-3>과 같다.

<그림 3-3> 이슈 데이터 수집 분포 현황

3.2.2.4 소프트웨어 형상 관리 데이터 수집

소프트웨어 형상 조작적 정의

소프트웨어 개발 산출물(문서나 소스 코드 등)이 배치되어 있는 배열

형상 관리 정의

- 형상 항목을 식별하여 그 기능적 물리적 특성을 문서화하고,

- 그러한 특성에 대한 변경을 제어하고,

- 변경 처리 상태를 기록 및 보고하고,

- 명시된 요구사항에 부합하는지 확인하는 기술적이고 관리적인 감독, 감시 활동 [IEEE-Std-1042]

A사 형상 데이터 수집

날짜	소스 코드 저장소 반영 회수	날짜	소스 코드 저장소 반영 회수	날짜	소스 코드 저장소 반영 회수
2013년 2월	4175	2014년 3월	3977	2015년 4월	3985
2013년 3월	5496	2014년 4월	4105	2015년 5월	3367
2013년 4월	5765	2014년 5월	2728	2015년 6월	3931
2013년 5월	5914	2014년 6월	3501	2015년 7월	4484
2013년 6월	5346	2014년 7월	3859	2015년 8월	4205
2013년 7월	5661	2014년 8월	3432	2015년 9월	5058
2013년 8월	3263	2014년 9월	2776	2015년 10월	5166
2013년 9월	3209	2014년 10월	3261	2015년 11월	4972
2013년 10월	3984	2014년 11월	2965	2015년 12월	4684
2013년 11월	3886	2014년 12월	3091	2016년 1월	4356
2013년 12월	2547	2015년 1월	3439	2016년 2월	3113
2014년 1월	3195	2015년 2월	2818	2016년 3월	3926
2014년 2월	3681	2015년 3월	3967	합계	151288

[표 3-4] 형상 데이터 수집 결과

형상 데이터 수집 현황을 chart로 식별해 보면 <그림 3-4>과 같다.

<그림 3-4> 형상 데이터 수집 분포 현황

3.2.2.5 형상 데이터 분석 및 선정 항목 수집

본 연구에서 수집한 이슈 추적 및 동료 리뷰 데이터를 분석하여, 제시한 선정 항목 데이터를 수집하였다. 수집 방법은 소스 코드 저장소SCM(소스코드 저장소 : Subversion )에 반영된 형상 데이터 ( Commit Comment )를 파싱하여 PMS의 DashBoard 모듈의 데이터베이스 스키마에 데이터를 주기적으로 Import하는 방법을 사용하였다.

PMS 활용 이전 데이터 중 이슈 연결 회수가 기록된 이유는 A사의 과거 버그 추적 시스템(Bug Tracking System)인 Mantis를 사용하고 있었기 때문이며, 단순히 버그를 추적하기 위하여 제작되어 프로젝트를 전체적으로 관리하는 과정에 있어, PMS의 범주에 포함되지 않았기 때문에 프로젝트 관리의 범주 확대 및 3.2.2.1의 선정 이유로 인하여 PMS를 도입 및 활용하였다.

단, 기존 데이터는 이슈만으로 한정지어 데이터를 수집하였고, 월별 소스코드 형상 데이터와 통합하여 결과를 도출하였다.

[표 3-5] 이슈 추적 및 동료 리뷰 데이터 수집 결과

날짜	소스 코드 저장소 반영 회수	리뷰 회수	리뷰 율	이슈 연결 회수	이슈 연결 율
2013년 2월	4175	690	16.53%	1040	24.91%
2013년 3월	5496	878	15.98%	1026	18.67%
2013년 4월	5765	1396	24.22%	1653	28.67%
2013년 5월	5914	1146	19.38%	1714	28.98%
2013년 6월	5346	1134	21.21%	1477	27.63%
2013년 7월	5661	1402	24.77%	1807	31.92%
2013년 8월	3263	911	27.92%	1210	37.08%
2013년 9월	3209	823	25.65%	1208	37.64%
2013년 10월	3984	1008	25.30%	1411	35.42%
2013년 11월	3886	1072	27.59%	1488	38.29%
2013년 12월	2547	630	24.73%	879	34.51%
2014년 1월	3195	938	29.36%	1273	39.84%
2014년 2월	3681	1159	31.49%	1503	40.83%
2014년 3월	3977	1420	35.71%	1504	37.82%
2014년 4월	4105	1677	40.85%	1500	36.54%
2014년 5월	2728	1603	58.76%	984	36.07%
2014년 6월	3501	1690	48.27%	1599	45.67%
2014년 7월	3859	1762	45.66%	1627	42.16%
2014년 8월	3432	1752	51.05%	1444	42.07%
2014년 9월	2776	1477	53.21%	815	29.36%
2014년 10월	3261	1555	47.68%	849	26.03%
2014년 11월	2965	1285	43.34%	866	29.21%
2014년 12월	3091	1250	40.44%	1208	39.08%
2015년 1월	3439	1555	45.22%	1354	39.37%
2015년 2월	2818	1512	53.66%	1023	36.30%
2015년 3월	3967	2287	57.65%	1596	40.23%
2015년 4월	3985	2266	56.86%	1498	37.59%
2015년 5월	3367	1897	56.34%	1254	37.24%
2015년 6월	3931	2224	56.58%	2033	51.72%
2015년 7월	4484	1985	44.27%	2612	58.25%
2015년 8월	4205	1980	47.09%	2560	60.88%
2015년 9월	5058	1964	38.83%	2732	54.01%
2015년 10월	5166	2282	44.17%	2824	54.67%
2015년 11월	4972	2580	51.89%	3022	60.78%
2015년 12월	4684	2487	53.10%	3002	64.09%
2016년 1월	4356	2439	55.99%	2864	65.75%
2016년 2월	3113	1677	53.87%	1836	58.98%
2016년 3월	3926	1981	50.46%	2434	62.00%
Total	151288	59774		62792

Dash-Line 그래프 : 형상 관리 소스 저장소 반영 회수

S-Line 꺽은선 그래프 : 리뷰 연결 비율

S-Line 곡선 그래프 : 이슈 연결 비율

연한 회색 막대 그래프 : 리뷰 회수

진한 회색 막대 그래프 : 이슈 연결 회수

이슈 데이터 수집 현황을 chart로 식별해 보면 <그림 3-5>과 같다.

<그림 3-5> 이슈 추적 및 동료 리뷰 데이터 수집 분포 현황

제 4 장 연구 분석 및 결과

제 4장에서는 제 3장에서 제시한 방법으로 수집한 표본자료를 바탕으로 분석 자료 현황을 도출하고 아래와 같은 분석을 실시하고자 한다.

첫째, 수집한 표본 자료를 대상으로 한 대상의 특징을 구분 하고,

둘째, 표본 자료를 대상으로 통계 분석에 들어가기에 앞서 어떤 통계적 분포를 띄고 있는지, 자료의 치우침이나 특이점은 없는지 파악하기 위하여 탐색적 자료 분석을 통하여 자료의 분포가 실제로 정규분포에 근사하는지, 그리고 회귀분석을 시행하기에 앞서 두 변수가 실제로 선형의 관계를 보이고 있는지 파악한다.

셋째, 표본 자료를 대상으로, PMBOK과 CMMI의 대응을 통해 선정된 항목을 기준으로 수집된 PMS의 적용 전․후 데이터를 독립 T 검증을 통해 프로젝트 성과 간 차이 유무를 검․추정하고자 한다.

이를 위해 가설을 설정하여 통계학적 접근을 통해 검․추정하고자 한다.

4.1 기초 데이터의 분석

4.1.1 표본 자료 특성

본 연구에 사용한 표본자료는 2013년 2월 01일부터 2016년 03월 31일까지 PMS를 적용하기 이전 기준일 1년 7개월( 2013년 02월 ~ 2014년 08월 )데이터와 PMS를 적용한 이후 기준일 1년 7개월( 2014년 09월 ~ 2016년 03월 )데이터를 통해 수집한 SCM 1155건 및 PMS 자료 310698건을 대상으로 하였다.

표본자료인 일별 합계는 1155건을 월별 합계 36건으로 합산하여 데이터를 처리하였다. 또한 PMS 적용 이전과 이후의 집단간 변화는 없었으며, PMS 기준 이슈 데이터의 총합산은 2016년 02월 29일 기준 248,723 건이었고, 프로젝트 구분은 262개 였다.

조사 대상 인원은 정규직 연구원 총 894명 이었으며, 이중 해외 영업 상주 인원 71명과 사업인력 165명은 프로젝트에 참여하는 인원이 아니므로 제외하였다. 경영지원 관련 부서 인원은 사용자 계정 관리 시스템에서 따로 관리되어 수집대상에서 분리하였다.

<그림 4-1> 표본 데이터 분포

4.1.2 표본 자료의 기초 통계

본 수집 자료의 본격적인 통계에 들어가기 위하여 자료의 치우침이나, 특이성을 분석하여, 통계적 검증의 유의미를 검증하기 위하여 탐색적 자료 분석을 통해 자료의 특징과 내재하는 구조적 관계를 알아내기 위해 시행하는 모든 방법으로 얻은 정보를 바탕으로 통계 모형을 구축하고, 실제로 수집 데이터의 분포가 독립 표본 T 분석을 시행하기 위해 정규분포에 근사하는지를 파악한다.

4.2.1.1 케이스 처리 요약

[표 4-1] 케이스 처리 요약 결과

각 군별로 결측치 없이 19개월의 자료를 월별로 구분하여 자료를 포함하고 있다.

측정 변수 구분	PMS 활용 여부 구분	케이스
		유효함		결측값		총계
		N	퍼센트	N	퍼센트	N	퍼센트
동료 리뷰 백분위	PMS 활용 전	19	100.0%	0	0.0%	19	100.0%
	PMS 활용 후	19	100.0%	0	0.0%	19	100.0%
이슈 연결 백분위	PMS 활용 전	19	100.0%	0	0.0%	19	100.0%
	PMS 활용 후	19	100.0%	0	0.0%	19	100.0%

4.2.1.2 기술 통계

각 군 별로 평균, 중위수, 분산, 표준편차, 최소값과 최대값 범위, 사분위수범위, 왜도와 첨도를 계산하였다. 왜도와 첨도 두 값 모두 –2~2 사이에 있으므로 치우침이 없는 분포로 계산되었다.

[표 4-2] 기술 통계 결과

측정 변수 구분	PMS 활용 여부 구분			통계	표준 오류
동료 리뷰 백분위	PMS 활용 전	평균		31.2845	2.79880
		평균의 95% 신뢰구간	하한	25.4044
			상한	37.1645
		5% 잘린 평균		30.6085
		중앙값		27.5862
		분산		148.832
		표준 편차		12.19969
		최소값		15.98
		최대값		58.76
		범위		42.79
		사분위수 범위		16.64
		왜도		.902	.524
		첨도		-.074	1.014
동료 리뷰 백분위	PMS 활용 후	평균		50.0336	1.36906
		평균의 95% 신뢰구간	하한	47.1573
			상한	52.9099
		5% 잘린 평균		50.2328
		중앙값		51.8906
		분산		35.612
		표준 편차		5.96762
		최소값		38.83
		최대값		57.65
		범위		18.82
		사분위수 범위		11.72
		왜도		-.426	.524
				-1.127
		첨도			1.014
이슈 연결 백분위	PMS 활용 전	평균		34.9863	1.54403
		평균의 95% 신뢰구간	하한	31.7424
			상한	38.2302
		5% 잘린 평균		35.2992
		중앙값		36.5408
		분산		45.297
		표준 편차		6.73028
		최소값		18.67
		최대값		45.67
		범위		27.00
		사분위수 범위		10.86
		왜도		-.797	.524
		첨도		.486	1.014
이슈 연결 백분위	PMS 활용 후	평균		47.6603	3.04701
		평균의 95% 신뢰구간	하한	41.2587
			상한	54.0618
		5% 잘린 평균		47.8568
		중앙값		51.7171
		분산		176.401
		표준 편차		13.28160
		최소값		26.03
		최대값		65.75
		범위		39.71
		사분위수 범위		23.54
		왜도		-.174	.524
		첨도		-1.542	1.014

4.2.1.3 정규성 검정

각 수집된 자료를 Kolmogorov-Smirnov 검정 방법과 Shapiro-Wilk 검정 방법을 통하여 다음과 같이 자료를 검정 하였다.

[표 4-3] 정규성 검정 결과

측정 변수 구분	PMS 활용 여부 구분	Kolmogorov-Smirnova				Shapiro-Wilk
		통계	df	유의 수준	통계		df	유의 수준
동료 리뷰 백분위	PMS 활용 전	.194	19	.057	.905		19	.059
	PMS 활용 후	.170	19	.152	.922		19	.121
이슈 연결 백분위	PMS 활용 전	.157	19	.200*	.950		19	.391
	PMS 활용 후	.186	19	.084	.902		19	.052

*. 실질적인 유의수준의 하한입니다. a. Lilliefors 유의수준 정정

Kolmogorov-Smirnov 검정		Shapiro-Wilk 검정
RV-NONPMS : P = 0.057 > 0.05	채택	RV-NONPMS : P = 0.059 > 0.05	채택
RV-PMSAPPLY : P = 0.152 > 0.05	채택	RV-PMSAPPLY : P = 0.121 > 0.05	채택
BT-NONPMS : P = 0.200 > 0.05	채택	BT-NONPMS : P = 0.391 > 0.05	채택
BT-PMSAPPLY : P = 0.084 > 0.05	채택	BT-PMSAPPLY : P = 0.052 > 0.05	채택

따라서, 4개의 그룹 모두 정규성을 띈다고 가정할 수 있다.

[표4-4]는 수집한 자료를 정규 Q-Q도표로 분석한 결과이다.

[표 4-4] 검정 결과 도표

도표 구분	PMS 적용 구분	동료 리뷰 백분위	이슈 연결 백분위
정규 Q-Q 도표	NON PMS
	PMS APP LY

검증 결과에 의하여, 수집된 데이터는 정규성 검증을 충족하고, 독립 표본 분석을 위한 종속 변수 값으로 사용될 요인들이 정규 분포해야하는 전제를 충족한다.

4.2.1.4 신뢰도 분석

본 연구에서 수집한 자료를 도표로 분석한 결과이다.

[표 4-5] 신뢰도 분석 결과 도표

케이스 처리 요약

신뢰도 통계

구분		N	%
케이스	유효함	38	100.0
	제외됨a	0	0
	총계	38	100.0

Cronbach 의 알파	항목의 N
.711	2

검증 결과인 Cronbach 알파값이 0.711로 데이터에 대한 신뢰도가 양호하다

4.2 연구 분석

4.2.1 연구 내용

4.2.1.1 연구 가설(Hypothesis)의 설정

본 연구에서는 「소프트웨어 제품 개발 프로젝트 환경에서 PMS활용이 프로젝트 성과 지표 중 “이슈 연결율”에 차이가 존재하는가?」와  「소프트웨어 제품 개발 프로젝트 환경에서 PMS활용이 프로젝트 성과 지표 중 “동료 리뷰율”에 차이가 존재하는가?」 의 의미로 접근하여 [표 4-6]와 같이 연구 가설을 설정하였다.

구분	Hypothesis
H1	소프트웨어 제품 개발 프로젝트 환경에 기초한 PMS활용이 프로젝트 성과 지표 중 이슈 연결율에 차이가 있는가?
H2	소프트웨어 제품 개발 프로젝트 환경에 기초한 PMS활용이 프로젝트 성과 지표 중 동료 리뷰율에 차이가 있는가?

[표 4-6] 가설 설정

4.2.2 연구 가설(Hypothesis) 검․추정

4.2.2.1 PMS 사용 이전, 이후의 이슈 연결 율 영향에 대한 검․추정

소프트웨어 제품 개발 프로젝트에 기초한 PMS 활용 이전, 이후의 진척 관리(PMBOK) 중 CMMI에 대응하는, 이슈 연결율 영향에 대한 차이가 있는지를 증명하기 위해 가설을 제시하고 이에 대한 검․추정 방법을 사용하였다.

귀무가설(H0) : PMS 적용 이전과 이후 간에 이슈 연결율 차이가 없다.

대립가설(H1) : PMS 적용 이전과 이후 간에 이슈 연결율 차이가 있다.

검정 결과를 독립 표본 T 분석으로 검증하여 정량적 변수인 프로젝트에 PMS 적용 여부가 PMBOK의 진척관리와 대응되는 CMMI의 이슈 연결율에 미치는 영향에 대해 분석한 결과를 정리하면 아래와 같다.

[표 4-7] 독립 표본 T 검정에 대한 검정결과 ( 이슈연결율 )

>그룹통계

측정 변수 구분	PMS 활용 여부 구분	N	평균	표준 편차	표준 오차 평균
이슈 연결 백분위	PMS 활용 전	19	34.9863	6.73028	1.54403
	PMS 활용 후	19	47.6603	13.28160	3.04701

>독립표본 검정

측정 변수 구분	등분산 가정 여부 구분	Levene의 등분산 검정		평균 등식에 대한 T 검정
		F	유의 수준	t	df	유의수준 (양쪽)
이슈 연결 백분위	등분산을 가정함	22.441	.000	-3.710	36	.001
	등분산을 가정하지 않음			-3.710	26.672	.001

측정 변수 구분	등분산 가정 여부 구분	평균 등식에 대한 T 검정
		평균 차이	표준 오류 편차	차이의 95% 신뢰구간
				하한	상한
이슈 연결 백분위	등분산을 가정함	-12.67399	3.41589	-19.60174	-5.74625
	등분산을 가정하지 않음	-12.67399	3.41589	-19.68685	-5.66114

[표 4-8]에 의하면 Levene의 등분산 검정 결과, p값이 0.000으로 0.05 보다 작은 경우 이므로, 등분산이 가정되지 않아 결과적으로 t=-3.710, p=0.001으로 나타났습니다. p값이 0.05 보다 작기 때문에, 종속 변수인 이슈 연결 백분위는 독립 변수인 PMS 활용 전과 활용 후의 평균 차이는 통계적으로 유의미 하다. 분석한 결과를 표로 정리하면 아래와 같다.

PMS 활용 여부 구분	M	SD	t	p
PMS 활용 전	34.9863	6.73028	-3.710	.001
PMS 활용 후	47.6603	13.28160

[표 4-8] 독립 표본 T 검정에 대한 검정결과 정리 ( 이슈연결율 백분위 )

M(Mean): 평균, SD(Standard Deviation): 표준편차

결과적으로, “PMS 활용 전과 PMS 활용 후의 이슈 연결율은 통계적으로 유의미한 차이가 있으며 ( p<0.05 ), PMS 활용 후의 이슈 연결율은 PMS 활용 전보다 높은 것으로 판단되었다.”

종합해 보면, PMS활용이 이슈연결율에 차이가 있나 살펴보니, 통계학적으로 유의미한 차이가 있었고, 소프트웨어 제품 개발 프로젝트 환경에 기초한 PMS활용이 PMBOK의 대응 CMMI 성과 지표 중 이슈연결율 올린다는 결과를 도출할 수 있었다.

4.2.2.2 PMS 사용 이전, 이후의 동료 리뷰 율 영향에 대한 검․추정

소프트웨어 제품 개발 프로젝트에 기초한 PMS 활용 이전, 이후의 품질 관리(PMBOK) 중 CMMI에 대응하는, 동료 리뷰율 영향에 대한 차이가 있는지를 증명하기 위해 가설을 제시하고 이에 대한 검․추정 방법을 사용하였다.

귀무가설(H0) : PMS 적용 이전과 이후 간에 동료 리뷰율 차이가 없다.

대립가설(H1) : PMS 적용 이전과 이후 간에 동료 리뷰율 차이가 있다.

검정 결과를 독립 표본 T 분석으로 검증하여 정량적 변수인 프로젝트에 PMS 적용 여부가 PMBOK의 진척관리와 대응되는 CMMI의 동료 리뷰율에 미치는 영향에 대해 분석한 결과를 정리하면 아래와 같다.

[표 4-9] 독립 표본 T 검정에 대한 검정결과 ( 동료 리뷰율 )

>그룹통계

측정 변수 구분	PMS 활용 여부 구분	N	평균	표준 편차	표준 오차 평균
동료 리뷰 백분위	PMS 활용 전	19	31.2845	12.19969	2.79880
	PMS 활용 후	19	50.0336	5.96762	1.36906

>독립표본 검정

측정 변수 구분	등분산 가정 여부 구분	Levene의 등분산 검정		평균 등식에 대한 T 검정
		F	유의 수준	t	df	유의수준 (양쪽)
동료 리뷰 백분위	등분산을 가정함	7.213	.011	-6.018	36	.000
	등분산을 가정하지 않음			-6.018	26.148	.000

측정 변수 구분	등분산 가정 여부 구분	평균 등식에 대한 T 검정
		평균 차이	표준 오류 편차	차이의 95% 신뢰구간
				하한	상한
동료 리뷰 백분위	등분산을 가정함	-18.74910	3.11571	-25.06805	-12.43016
	등분산을 가정하지 않음	-18.74910	3.11571	-25.15177	-12.34644

[표 4-9]에 의하면 Levene의 등분산 검정 결과, p값이 0.000으로 0.05 보다 작은 경우 이므로, 등분산이 가정되지 않아 결과적으로 t=-6.018, p=0.000으로 나타났습니다. p값이 0.05 보다 작기 때문에, 종속 변수인 동료 리뷰율은 독립 변수인 PMS 활용 전과 활용 후의 평균 차이는 통계적으로 유의미 하다. 분석한 결과를 표로 정리하면 아래와 같다.

PMS 활용 여부 구분	M	SD	t	p
PMS 활용 전	31.2845	12.19969	-6.018	.000
PMS 활용 후	50.0336	5.96762

[표 4-10] 독립 표본 T 검정에 대한 검정결과 정리 ( 동료 리뷰율 )

M(Mean): 평균, SD(Standard Deviation): 표준편차

결과적으로, “PMS 활용 전과 PMS 활용 후의 동료 리뷰율은 통계적으로 유의미한 차이가 있으며 ( p<0.05 ), PMS 활용 후의 리뷰 연결율은 PMS 활용 전보다 높은 것으로 판단되었다.”

종합해 보면, PMS활용이 동료 리뷰율에 차이가 있나 살펴보니, 통계학적으로 유의미한 차이가 있었고, 소프트웨어 제품 개발 프로젝트 환경에 기초한 PMS활용이 PMBOK의 대응 CMMI 성과 지표 중 동료 리뷰율을 올린다는 결과를 도출할 수 있었다.

4.2.3 연구 검․추정 결과 및 의미 분석

지금까지의 표본자료를 이용한 가설 검․추정을 종합해 보면 다음과 같은 연구결과를 얻을 수 있다.

[표 4-11] 가설 검․추정 결과

구분	Hypothesis	Results
H1	소프트웨어 제품 개발 프로젝트 환경에 기초한 PMS활용이 프로젝트 성과 지표 중 이슈 연결율에 차이가 있는가?	true
H2	소프트웨어 제품 개발 프로젝트 환경에 기초한 PMS활용이 프로젝트 성과 지표 중 동료 리뷰율에 차이가 있는가?	true

[표 4-11]의 검증결과는 소프트웨어 제품 개발 프로젝트를  대상으로 「진척 관리(PMBOK) 중 CMMI에 대응하는 이슈 연결율과 진척 관리(PMBOK) 중 CMMI에 대응하는, 동료 리뷰 비율을 PMS 활용이전과 이후로 비교해 보니 통계학적으로 유의미한 차이가 있었으며, 이 차이는 PMS 활용 이후 평균 비율이 증가하여, 프로젝트 성과에 (+)정의 영향을 주었다.」는 것을 의미한다.

즉,  소프트웨어 제품 개발 프로젝트에 성과지표에 (+)정의 영향을 주기 위해서는 PMS의 활용이 도움이 된다는 것이 통계학적으로 유의미함을 참조할 필요가 있다.

제 5 장 요약 및 결론

SW산업의 지속적인 발전은 단순히 생산성을 높임으로써 달성되는 것이 아니라 창조적인 혁신에 의해 이루어진다. 또한, 기존 SW 공학에 집중해야 하는 이유는 개선의 출발점이자 향후 지속적인 개선의 발판이 되기 때문이다.

이에 본 연구는 PMS 적용 및 활용 결과를 분석하여 SW의 품질 및 생산성 제고를 위해 기업이 체감할 수 있는 실질적인 성과를 도출하고 SW개발과 관련된 현안과 문제점을 정량적이고 객관적인 데이터를 기반으로 파악하고, SW 프로젝트 관리를 정량적으로 제시하고, 개발에 소요되는 활동을 정량적으로 측정함으로써 SW를 개발하고 폐기하기까지의 과정인 요구사항, 분석/설계, 구현, 테스트 관련 기술과 이를 효과적으로 운영, 관리하기 위한 형상관리, 프로젝트 관리, 프로세스 관리 자동화 도구인 PMS의 활용이 미치는 영향에 관한 연구를 진행하였다.

본 연구는 국내 A기업의 262개 프로젝트 현장에서 도입, 적용되고 있는 프로젝트 관리 시스템(PMS)의 적용 효과를 관리 지표를 중심으로 파악하였다. 실제 기업에 적용된 PMS 시스템의 적용 사례를 분석하였고, 그 결과 PMS를 적용하였을 경우 동종업계 보다 조직 차원의 프로젝트 관리 지표의 정량적인 효과차이를 얻었다.

본 연구를 통해 정량적인 효과차이를 증명하기 위하여 통계적인 분석으로 소프트웨어 제품 개발 프로젝트를 대상으로 독립변수인 PMS활용 여부를 기준으로 종속변수인 이슈 연결 백분위 비율, 동료 리뷰 백분위 비율에 통계학적으로 유의미한 차이가 있는지를 비교해 보았다. 이 때 PMS의 활용을 독립변수로 가설에 담아 비교 작업을 해 볼 수 있었다. 본 연구 결과를 종합해 보면 다음과 같다.

첫째, PMS 활용 전과 활용 후를 구분하여 진척 관리(PMBOK) 중 CMMI에 대응하는 이슈 연결율에 차이가 있는지 살펴보니, PMS 활용 후에 통계학적으로 유의미한 수준으로 더 많은 비율로 진척 관리가 되었다는 것을 알 수 있었다.

둘째, PMS 활용 전과 활용 후를 구분하여 품질 관리(PMBOK) 중 CMMI에 대응하는 동료 리뷰 비율에 차이가 있는지 살펴보니, PMS 활용 후에 통계학적으로 유의미한 수준으로 더 많은 비율로 품질 관리 지표가 개선되었고, SW프로젝트를 수행하는데 있어, PMS 활용 역량을 확보한 조직이 그렇지 못한 조직에 비해 SW프로젝트의 관리 지표(진척 관리, 품질)에서 모두 상대적으로 높은 수준을 나타냈다는 것을 알 수 있었다.

이러한 결과를 참조하여, 소프트웨어 제품 개발 프로젝트 환경에서 PMS의 기능에 대한 분석과 활용이 프로젝트의 성공에 기여하는 부분이 검증된 바, PMS가 이미 구축되 있다면, 활용성을 늘리고, PMS 구축 및 활용이 되고 있지 않다면 도입 및 운영 방안에 대해 진지한 검토가 필요할 것으로 판단된다.

마지막으로 본 연구 결과를 향후 소프트웨어 제품 개발 프로젝트를 위한 프로젝트 관리에 참조한다면 진척관리와 품질 관리 등의 특성을 고려한 비율을 적절히 산정함으로써 전반적인 소프트웨어 제품 개발 프로젝트의 관리 향상을 기대할 수 있을 것이다.

2) 연구의 한계점

본 연구의 한계점으로는 특정 A 기업의 소프트웨어 제품 개발 프로젝트만을 대상으로 하였고, 시간과 노력의 한계로 인해 262개의 프로젝트만을 대상으로 분석하였다. 향후, 타 소프트웨어 제품 개발 수행 업체의 실적 정보에 대한 지속적인 자료 수집이 필요하다.

3) 향후 연구 방향

프로젝트 성공에 영향을 미치는 분류를 기준으로 PMBOK과 CMMI에 대응 개념 중 본 논문의 제시 이외의 분류를 PMS기능으로 수집 할 수 있는지 구분하여 각 프로젝트 수명주기별 다양한 요소 검토 및 검증할 필요가 있다. 향후 보다 많은 프로젝트를 대상으로 프로젝트 성공과의 관계를 연구한다면 프로젝트 성공을 위한 PMS 활용을 보다 신뢰할 수 있는 결과를 제시할 수 있을 것이다.

PMBOK과 CMMI의 대응 기준으로 PMS의 성과 관리 지표를 구성하였으나, 실제 두 기준 모두 멀티 프로젝트 관리 및 ROI에 대한 명확한 가이드라인은 없는 상황이다. 따라서 OPM3의 대응 구분을 추가하여, 멀티 프로젝트 및 ROI 에 대한 가이드를 기준으로 PMS　적용이 프로젝트 관리 지표에 영향을 주는지 확인 해 볼 필요가 있다.

현재 시중의 PMS를 구현하는 경우, 이론적 관리기능 구현이 어렵고, 담당하는 분석 및 설계자가 현장경험이 부족한 경우가 많다. 그래서 현장에서 실무적으로 발생하는 문제에 대하여 PMS에 반영하는 것이 어려운 경우도 많다. 이는 SW개발 프로젝트 환경에서 PMS가 개발 친화적이고 활용도를 올리기 위한 발전에 방향성을 제시하는 것이기도 하며, 향후 연구 방향의 발전성과도 연계됨을 생각해 볼 필요가 있다.

따라서, 향후 PMS와 프로젝트 관리와의 상관성을 아래와 같이 다이어그램으로 제시하며, 본 논문의 한계점을 넘어 현장 친화적인 프로젝트 관리 부문과 PMS사이에서 소프트웨어 개발에 도움이 되는 소프트웨어 아키텍쳐와 소프트웨어 방법론을 품고 있는 시스템이 구현되고 증명되어 대한민국 소프트웨어 산업과 나아가 국제적인 소프트웨어 개발선진국 으로서의 위신이 세워지길 바란다.

<그림 5-1> 향후 연구 모형과 소프트웨어 프로젝트 모형도

참고 : http://www.313.co.kr/

참고 문헌

국내문헌

[1] 정천수, 안현철 “IS프로젝트에서 PMS 품질이 성과에 미치는 영향에 대한 연구“, “한국지식경영학회”, 2012

[2] 양종곤 "6시그마 프로젝트 관리시스템의 활용이 프로젝트 균형성과지표에 미치는 영향에 관한 실증적 연구", “한국산학기술학회논문지”, 2009

[3] 김원섭, 권영모 “BPM 기반의 전사적프로젝트 관리시스템(EPM)을 통한 기업경쟁력 강화 사례”, “대한산업공학회”, 2005

[4] 趙俊熙 “IT 기업 내 시스템 개발 지식 공유 활동이 역량강화 향상에 미치는 영향”, “고려대학교 석사학위 논문”, 2014

[5] 백재용외 5명 공저, “프로세스 기반의 협업 프로젝트 관리 시스템 구조 설계”, “한국CAD/CAM학회 논문집”, 2009

[6] 楊玉洙, "PMS(Project Management System)을 활용한 통합진척관리“, ”한국IT서비스학회 학술대회 논문집“, 2011

[7] 정우승외 3명 공저, “QFD를 활용한 전사적 프로젝트 관리 시스템 구축사례 연구”, “한국산업경영시스템학회”, 2009

[8] 김종수, 오현승 “웹서비스 기술의 프로젝트 평가관리시스템에의 응용”, 한국산업경영시스템학회, 2004

[9] 곽송해외 3명 공저, “정량적 프로젝트 관리를 위한 자동화도구 개발 연구”, “한국IT서비스학회 학술대회 논문집”, 2010

[10] 이정구, “프로젝트관리정보시스템의 효과에 관한 연구”, “한국산업경영시스템학회”, 2006

[11] 정수진외 2명 공저, "PMIS 의 시각화를 위한 BIM활용에 관한 연구", “한국 CAD/CAM 학회 학술발표회 논문”, 2012

[12] 이슬기외 2명 공저, "PMIS의 품질이 프로젝트관리의 성공에 미치는 영향 분석", 한국건축시공학회, 2010

[13] 정천수외 2명 공저, "PMO 기반 프로젝트 관리 시스템의 설계 및 적용", 한국정보시스템학회, 2011

[14] 강재화, 김승관 "PMS 연계를 통한 EA 현행화 개선 사례 연구:

국토해양부 정보화프로젝트 관리시스템을 중심으로", 정보기술아키텍처연구, 2012

[15] 임태종, 이상완 "PMS의 상호작용적 이용이 보상갈등, 조직시민행동,그리고 조직성과에 미치는 영향", 한국국제회계학회, 2013

[16] 김진원 “Project Management System 전산프로그램 개발”, 대한전기협회, 1996

[17] 박구락 “프로젝트 관리 시스템에 관한 연구”, 한국디지털정책학회, 2015

[18] 김순기외 2명 공저, “경영전략, 성과측정시스템의 이용,그리고 조직역량 간의 관계：한국과 일본 기업을 중심으로”, 대한회계학회, 2014

[19] 문용은, 이재범 “소프트웨어 개발을 위한 통합 프로젝트 관리의 개념적 모형에 관한 연구”, 경영정보학연구, 1996

[20] 윤승옥, 이창호 “전사적 Risk Management System의 개념적 모형에 관한 연구”, 대한안전경영과학회, 2012

[21] 김순기외 3명 공저, “혁신전략과 조직역량간의 관계에서 성과측정시스템과 보상시스템의 역할”, 한국국제회계학회, 2012

[22] 이상완외 2명 공저, “성과측정시스템의 이용과 조직성과간의 관계에서 성과측정지표의 다양성과 조직학습의 역할”, 관리회계연구, 2011

[23] 윤재희외 2명 공저, “조직문화와 조직성과간의 관계에서 PMS 이용과 조직학습의 매개효과에 관한 연구：공공기관을 중심으로”, 대한회계학회, 2012

[24] 조형식외 1명 공저, “PLM 지식 = PLMBOK : product lifecycle management body of knowledge”, 2008

[25] 강창욱외 11명 공저, “경쟁우위 확보를 위한 프로젝트 관리학”, 북파일, 2009

[26] 지식경제부, 정보통신산업진흥원 SW공학센터, “소프트웨어공학 백서”, 2013

[27] 김경환외 2명 공저, “CMMI와 PMBOK의 비교 분석을 통한 정량적 프로젝트 관리”, 정보처리학회, 2005

[28] 박정하, “CMM개념을 활용한 건설 PMIS 평가 모델 개발”, 동국대학교 석사학위, 2002

[29] 김석훈, 정진영, 안우영, “MIS 환경에서의 중소 기업형 프로젝트 성과관리 시스템,” 한국항행학회논문지, 제13권, 제6호,2009, pp.964-970.

[30] 김희영,“연구개발 프로젝트관리시스템(PMS)의 개발 및 구현에 관한 연구,” 석사학위논문, 한양대학교 대학원, 2008.

[31] 옹상순, 최재현, 박제원, 이남용, “UML기반의 공공부문 정보화 프로젝트관리 모델에 관한 연구,” 한국IT서비스학회지, 제8권, 제3호, 2009, pp.101-109.

[32] 이돈희, 김종은, “SI 개발 프로젝트 생산성 향상을 위한 프로젝트 관리 방법론 구축에 관한 연구”, 한국IT서비스학회 학술대회, 2009

[33] 전형권, 박구락, 정진영, “SW개발 프로젝트 관리시스템 도입 및 적용사례에 대한 연구”, 한국컴퓨터정보학회논문지, 2015

[34] 산업통상자원부 기술표준원, “프로젝트관리 표준(ISO-21500) 이행가이드”, 2013

[35] 이진국, “CMM 적용의 문제점 분석을 통한 효율적인 CMMI의 적용방안”, 서강대학교 정보통신대학원, 석사학위논문, 2005

[36] 전형권, “소프트웨어 프로젝트 관리 시스템 기능 특화 및 적용효과에   관한 연구”, 공주대학교 대학원, 석사학위논문, 2015

[37] 정두진, “신제품 개발 프로젝트의 통합관리 시스템에 관한 연구”, 경남대학교 대학원 박사학위논문, 2004

[38] 정천수, 김승렬, 김남규(2011), “PMO 기반 프로 젝트 관리 시스템의 설계 및 적용”, 정보시스템 연구, 제20권 제4호, 119-143.

[39] 이영희, 김영신, 천정락, “IT 프로젝트 성과제고를 위한 프로젝트 지원도구 활용 사례연구”, 금융지식연구, pp171-172 2006

국외문헌

[1] PMI(PROJECT MANAGEMENT INSTITUTE) "A Guide to the Project Management body of  knowledge" 5th Edition, 2013

[2] Duncan, W.R. (2000), A Guide to the Project Management Body of  Knowledge 2000 edition, Project Management Institute.

[3] Kezner, Harold 『Project Management : A Systems approach to Planning, Scheduling, and Controlling』10th edition, John Wiley & Sons. 2009

[4] Jurison, Jaak, "Software Project Management : The Manager's view", Communications of AIS, Vol.2, Article 17, 1999

[5] Mary Beth Chrissis, Mike Konrad, Sandy Shrum CMMI : Guidelines for Process Integration and Product Improvement, 2003

[6] Carnegie Mellon University SEI CMMI product team, (2010) “CMMI-Dev ver 1.3”

[7] M.C Paulk, B.Curtis, M.B. Chrissis, and Charles V.Weber, “Capability Maturity Model For Software, Version 1.1”, Software Engineering Onsitute, CMU/SEI-93-RT-24, 1993

[8] Cooper, R. G. and Kleinschmidt, E. J. (1995), Benchmarking the Firms's Critical Success Factors in New Product Development, Journal of Product Innovation Management, 12, 374-391.

[9] Pfleeger, S. L. (1995), Maturity, Models, and Goals: How to Build a Metrics Plan, Journal of System & Software, 31, 143-155

[10] Griffin, A. (1997), PDMA Research on New Product Development Practices: Updating Trends and Benchmarking Best Practices, Journal of Product Innovation Management, 14, 429-458.

[11] Burrill, C.W., & L. W. Ellsworth, Modern Project Management : Foundations for Qulity and Productivity, Burrill-Ellsworth Associates, Inc., N.J., 1980

[12] Turner, J. R., The Handbook of Project-Based Management, McGRAW-HILL,1993.

[13] Yassine Rdiouat, Naima Nakabi, Khadija Kahtani and Alami Semma,
“Towards a new approach of continuous process improvement based on CMMI and PMBOK”, International Journal of Computer Science Issues, 2012

[14] ISO, “FINAL DRAFT INTERNATIONAL STANDARD ISO/FDIS 21500 Guidance on project management”, 2012

감사의 글

본 논문을 마감할 때 까지 항상 마음에 품고 있는 내 철학이자 삶의 자세는 내 유일한 장점인 정직함과 꾸준함이었다. 그리고 지금 이 논문을 탈고하는 지금 이 순간에 내 눈앞에 새로운 도전이 내 가슴으로 하여금 끓어오르기 시작한다. 지금까지 배운 수많은 지식을 서로 연결하여 대한민국의 소프트웨어를 조금 더 바르고 조금 더 향상 시킬 수 있다는 꿈을 꾸며, 나와 같은 꿈을 꾸는 개발자들과 새로운 도전을 시도해 보고자 한다. 항상 어렵고 힘든 길을 걷는 피곤함과 지친 마음에 끊임없는 열정을 몸소 보여주시고 지식의 끝엔 겸손함을, 동시에 마음과 머리에 채워주신 지도교수님 이석주 교수님과 이희조 교수님, 인호 교수님께 진심으로 고개 숙여 감사드립니다.

그리고 나를 믿고 세상을 바꾸고자 직장을 다니고 있지만 잠을 줄여가며 우리의 꿈을 향해 뛰는 내 동지 313 개발자 그룹에게 고개 숙여 경의를 표합니다.

2016년 7월

이 동민