NCA Ⅵ - PER - 04027 50 소프트웨어개발비대가기준개선연구 A Study on the Improvement of the Software Cost Estimation Guidelines 2004. 11 수탁기관 : 한국소프트웨어산업협회
제출문 한국전산원장귀하 본보고서를 소프트웨어개발비대가기준개선연구 의최 종연구개발결과보고서로제출합니다. 2004 년 10 월 30 일 수탁기관 : 한국소프트웨어산업협회연구책임자 : 채효근 ( 한국소프트웨어산업협회진흥사업팀장 ) 참여연구원 : 권기태 ( 강릉대학교컴퓨터공학과교수 ) 유종호 ( 한국소프트웨어산업협회 ) 천성민 ( 한국소프트웨어산업협회 ) 류승한 ( 한국소프트웨어산업협회 ) 과제관리자 : 이현옥 ( 한국전산원지식정보기술단감리연구팀장 ) 심황섭 ( 한국전산원지식정보기술단감리연구팀 ) 이병만 ( 한국전산원지식정보기술단감리연구팀 ) 김광식 ( 한국전산원지식정보기술단감리연구팀 ) 김정엽 ( 한국전산원지식정보기술단감리연구팀 ) 이창민 ( 한국전산원지식정보기술단감리연구팀 ) 김소정 ( 한국전산원지식정보기술단감리연구팀 ) 신다울 ( 한국전산원지식정보기술단감리연구팀 ) 이충희 ( 한국전산원지식정보기술단감리연구팀 ) 이규엽 ( 한국전산원지식정보기술단감리연구팀 )
요약문 1. 제목 소프트웨어개발비대가기준개선연구 2. 연구개발의목적및중요성 소프트웨어개발에있어서가장중요한작업중의하나는소프트웨어개발비용을정확하게예측하는것이며, 소프트웨어산업의건전한발전을위해보다현실적이고타당한대가기준및표준의제정이요구된다. 소프트웨어개발비용을정확하게추정하기위한소프트웨어개발비용산정모형에관한연구는국내외적으로활발하게진행되어왔다. 국내에서는 2004년기능점수방식에따라소프트웨어개발비대가기준이개정고시되었다. 개정소프트웨어개발비대가기준은선진모형과비교하여볼때, 일부기존보정계수의조정및신규보정계수의도입을중심으로개선필요성이제기되고있다. 따라서소프트웨어사업대가산정의정확성을제고하고정보화사업의예산및비용산정의과학화를위해납기보정계수등소프트웨어개발비대가기준모형을개선하기위한지속적인연구가필수적이다. 3. 연구개발의내용및범위 본연구는선진모형의벤치마킹과설문조사를통해비용산정모형의개선요구사항의도출과소프트웨어사업에관한신뢰성있는자료수집을통해소프트웨어사업대가기준의실증적인검증및신규보정계수의도입으로대가기준의현실화와정확도향상에그의의가있다. 연구범위는크게비용자료수집모형제시실무자대상의설문조사, 신 - i -
뢰성있는비용자료수집분석과이를통한현행대가기준의검증및보정계수조정이다. 통계분석의결과가신뢰성을가질수있도록충분한양질의데이터를수집하고, 제한된범위의각종보정치를다양한시스템특성을반영하는융통성있는보정치로개선하고납기보정계수를도입한다. 비용자료조사대상은먼저조사대상업체를선정한후소프트웨어사업의회계정리기준안에따른원가자료, 소프트웨어개발비로나누어조사한다. 또한실데이터를통해현행대가기준을검증하고, 규모자료를근거로적정납기산정식을도출하며, 설문조사및실증적인정확성분석을통해적절한납기보정계수를유도한다. 4. 연구결과 소프트웨어사업대가기준의지속적인개선을위해비용자료수집모형과비용자료리포지토리프로토타입을제시하였다. 또한대가기준의개선 ( 안 ) 을유도하기위해선진비용산정모형들을벤치마킹하고실무자들을대상으로대가기준개선요구사항에관한설문조사를실시하였다. 설문항목은기본사항, 보정계수일반, 보정계수개선에관한부분으로구성되었다. 벤치마킹결과와상기설문조사의분석을기초로소프트웨어개발비데이터를조사하였다. 데이터조사양식은 2004년소프트웨어사업의원가정리기준 ( 안 ) 에따른데이터조사양식을이용하고, 개발비조사양식을보완하였다. 데이터조사항목은프로젝트기본사항, 규모산정, 실투입공수및규모조사양식, 계약및실적조사양식, 기존보정계수의타당성조사양식, 일반시스템특성조사양식등으로구성되었다. 상기실데이터조사양식에의해수집된비용자료를이용하여현행대가기준을검증하였으며, 보정계수별적합도측면에서는규모보정계수가가장의미있는것으로나타났고, 나머지보정계수는비용산정의정확도를향상시키지못하는것으로나타났다. 따라서기존의어플리케이션유형보정계수와품질및특성보정계수를 IFPUG의일반시스템특성을반영하는 - ii -
보정계수로대치하는것이의미가있다는것을알수있다. 수집된비용자 료의규모관련자료를근거로적정납기산정식과납기보정계수를유도하 였다. 5. 활용에대한건의 본연구의결과는우리나라소프트웨어산업분야의규모, 생산성, 원가등에관련한기초데이터베이스를구축하는데활용되며, 프로젝트간, 업계간시기별유형별공정별등각종형태의생산성, 규모, 원가등을비교평가하는기초자료로활용될수있다. 또한소프트웨어개발비대가기준의적절성을판단하는자료로폭넓은활용이가능함으로써대가기준개선모형의기초자료로활용할계획이다. 6. 기대효과 소프트웨어실무자들의의견과선진비용산정모형들의벤치마킹을통해개선요구사항이도출되고실제의비용자료를통해소프트웨어사업대가기준의개선안이유도및검증되었다. 개선안은객관성과합리성이외에도다양한시스템특성들을반영한보정계수와납기보정계수의도입으로소프트웨어산업의건전한발전을위한공정한대가산정에기여를할것이다. - iii -
Summary 1. Title A Study on the Improvement of the Software Cost Estimation Guidelines 2. Objective and Importance How to estimate correct the software development cost is one of the most significant tasks. It is required to set up realistic and reliable cost and standard for sound development of software industry. A study on the software cost estimation have processed over the world. New guidelines based on FP method released on 2004. But software cost estimation guidelines have many problems about indefiniteness and inconsistency of effort multipliers. So we have to calibrate the existing multipliers and to derive schedule adjustment factors. It is important to study on the continuous improvement of software estimation guidelines for accurate and scientific estimation of software development cost. 3. Scope It is a meaningful work to derive the requirements of software cost estimation guidelines and to collect reliable data on software business, and to improve correctness of cost drivers and effort multipliers. This study consists of three parts: 1) questionnaire survey of practitioners in software industry, 2) analysis and investigation on the - iv -
current cost estimation guideline, 3) determination and adjustment of the cost drivers and effort multipliers. We select target companies for collecting reliable industry data and investigate basic cost, software development cost according to basic accounting rules. We collect software industry data to replace some existing adjustment factors with new factors. We derive delivery estimation formula based on software size and find reasonable schedule factors after experimental investigation. 4. Results We propose the cost collection model and the repository prototype of cost data. In order to improve correctness and to derive schedule factors, questionnaires were developed. The questionnaires were consisted of 3 parts; basic items, general cost drivers, improvement of cost drivers. In order to collect real software industry data, we developed questionnaires. The questionnaires were consisted of 6 parts; basic items, size estimation, actual effort and size, accounting information, current adjustment factors, general system characteristics. With real data, we investigate existing cost drivers and derive new cost drivers and schedule factors based on for the General System Characteristics and FP respectively. 5. Recommendation The results of this study can be used for analysis of size, productivity and cost of domestic software industry. It is used as the benchmarking - v -
for the best practices. It will be used as basic data for determination about the reason of the cost estimation guidelines and the improvement model. 6. Expected Impact The revised estimation guidelines of development cost based on this study will contribute to the sound development of software industry and help to establish reasonable price for all stakeholders. This study offers IT organization insights into the software development practices that can contribute to improved cost estimation methods for designing, developing, and deploying software on time and within budget. - vi -
목차 제1장연구개발의개요 1 제1절연구개발의필요성 1 제2절연구개발의목표및내용 2 제3절연구개발추진일정 8 제4절연구개발추진전략및방법 9 제2장소프트웨어개발비대가기준의개선요구사항 12 제1절소프트웨어비용산정개요 12 제2절보정계수도출방안 16 제3절현행대가기준의구성및문제점 23 제4절소프트웨어개발비대가기준의개선방안 40 제 3 장비용자료수집모형 47 제 1 절소프트웨어비용자료수집양식 47 제 2 절소프트웨어비용자료리포지토리 56 제4장소프트웨어개발비대가기준의개선 69 제1절비용산정모델의보정계수와비교 69 제2절 IFPUG의일반시스템특성의반영 78 제3절납기보정계수의도입 88 제5장현행대기기준과개선안의비교분석 94 제1절설문조사를통한현행대가기준의분석 94 제2절비용자료를이용한현행대가기준의검증 105 제3절신규보정계수의검증 112 제4절지속적인대가기준개선방안 117 제 6 장결론 123 - vii -
참고문헌 125 부록 1. 소프트웨어개발비산정기준에대한설문양식 127 부록 2. 소프트웨어비용자료수집양식 137 - viii -
표목차 [ 표 2-1] 거시적인산정도구의보정예 17 [ 표 2-2] 미시적인산정도구의보정예 18 [ 표 2-3] 생산성에긍정적인보정요인 20 [ 표 2-4] 생산성에긍정적인보정요인 21 [ 표 2-5] 주요보정요인의우선순위 23 [ 표 2-6] 본수와기능점수산정방식비교 26 [ 표 2-7] 소프트웨어사업대가기준구성 28 [ 표 2-8] 단계별기능점수당단가 29 [ 표 2-9] 단계별코드라인당단가 29 [ 표 2-10] 규모 ( 코드라인 ) 보정계수 30 [ 표 2-11] 어플리케이션유형보정계수 30 [ 표 2-12] 개발언어보정계수 31 [ 표 2-13] 품질및특성보정계수 32 [ 표 4-1] 비용산정모델과현행대가기준의보정계수비교 69 [ 표 4-2] ACAP 보정계수 70 [ 표 4-3] PCAP 보정계수 71 [ 표 4-4] PCON 보정계수 71 [ 표 4-5] APEX 보정계수 72 [ 표 4-6] PLEX 보정계수 72 [ 표 4-7] LTEX 보정계수 73 [ 표 4-8] TOOL 보정계수 74 [ 표 4-9] SITE 보정계수 75 [ 표 4-10] Early Design 모델의보정계수 77 [ 표 4-11] 현행기준의보정계수와 VAF 범위 84 [ 표 4-12] 일반시스템특성의 VAF와보정계수범위 85 [ 표 4-13] 보정계수변환표 87 [ 표 4-14] COCOMO Ⅰ의납기보정계수 89 [ 표 4-15] COCOMO Ⅱ의납기보정계수 89 [ 표 4-16] 납기보정계수 (1 案 ) 93 [ 표 4-17] 납기보정계수 (2 案 ) 93 - ix -
[ 표 5-1] 소속기관분류 94 [ 표 5-2] 담당업무 94 [ 표 5-3] 소프트웨어업무경험 95 [ 표 5-4] 대가기준의인지도및활용도 96 [ 표 5-5] 일반시스템특성 (GSC) 반영방안 102 [ 표 5-6] 납기보정계수 (1 案 ) 104 [ 표 5-7] 납기보정계수 (2 案 ) 104 [ 표 5-8] 보정계수적용효과 109 [ 표 5-9] 보정계수별적용효과 110 [ 표 5-10] GSC 응답데이터의보정계수적용효과 112 [ 표 5-11] 현행기준과 GSC를적용한개선안의비교 112 [ 표 5-12] 현행기준과조정된 VAF를적용한개선안의비교 114 [ 표 5-13] 납기보정계수 ( 案 ) 116 [ 표 5-14] 시간기록양식 118 [ 표 5-15] 시간및결함기록양식 119 [ 표 5-16] 코드라인정의양식 120 - x -
그림목차 [ 그림 2-1] 소프트웨어생명주기에따른산정정확도 14 [ 그림 2-2] 소프트웨어비용산정기법 16 [ 그림 2-3] 인사기본정보관리프로그램 25 [ 그림 2-4] 소프트웨어사업대가계산방식의개선 27 [ 그림 3-1] 기본사항조사양식 49 [ 그림 3-2] 규모산정조사양식 51 [ 그림 3-3] 실제의공수와규모를조사하는양식 52 [ 그림 3-4] 계약및실적원가조사양식 53 [ 그림 3-5] 기존보정계수조사양식 54 [ 그림 3-6] 일반시스템특성조사양식 55 [ 그림 3-7] 소프트웨어비용자료의활용 58 [ 그림 3-8] 소프트웨어비용자료리포지토리구성 60 [ 그림 3-9] 소프트웨어비용자료리포지토리 61 [ 그림 3-10] 기능점수산정 61 [ 그림 3-11] 리포지토리비용산정초기화면 62 [ 그림 3-12] 보정전개발원가산정결과 63 [ 그림 3-13] 비용산정결과 63 [ 그림 3-14] 리포지토리리포트기능 64 [ 그림 3-15] COCOMO Ⅱ와의산정결과비교 64 [ 그림 3-16] CBR 기반비용산정도구 V-ANGEL과비교 65 [ 그림 3-17] 산업계의데이터를이용한벤치마킹 65 [ 그림 3-18] 비용자료리포지토리의활용 66 [ 그림 5-1] 사업대가기준의미사용이유 96 [ 그림 5-2] 산정비용과실제비용비교 96 [ 그림 5-3] 불일치및일관성부족이유 97 [ 그림 5-4] 기능점수단가와실제단가비교 97 [ 그림 5-5] 규모보정계수의적절성 98 [ 그림 5-6] 규모보정계수가부적절한이유 98 [ 그림 5-7] 어플리케이션유형보정계수의적절성 99 [ 그림 5-8] 어플리케이션유형보정계수부적절이유 99 - xi -
[ 그림 5-9] 언어보정계수의적절성 100 [ 그림 5-10] 언어보정계수의부적절이유 100 [ 그림 5-11] 품질및특성보정계수의적절성 101 [ 그림 5-12] 품질및특성보정계수의부적절이유 101 [ 그림 5-13] 일반시스템특성반영의적절성 102 [ 그림 5-14] 적정납기및납기단축율산출공식 103 [ 그림 5-15] 납기보정계수적용방안 105 [ 그림 5-16] 사업대가기준의추정편향성 108 [ 그림 5-17] 사업대가기준의추정편향성 (MRE>0.25인경우 ) 109 [ 그림 5-18] 현행대가기준의평가결과 (MMRE) 110 [ 그림 5-19] 현행대가기준의평가결과 (PRED(0.25)) 111 [ 그림 5-20] GSC를적용한개선안의평가 (MMRE) 113 [ 그림 5-21] GSC를적용한개선안의평가 (PRED(0.25)) 113 [ 그림 5-22] 조정된 VAF를적용한개선안의평가 (MMRE) 115 [ 그림 5-23] 조정된 VAF를적용한개선안의평가 (PRED(0.25)) 115 [ 그림 5-24] 납기보정계수의정확성비교 116 - xii -
CONTENTS Chapter 1 Introduction 1 Section 1 Necessity 1 Section 2 Goals and Contents 2 Section 3 Schedule 8 Section 4 Strategy and Method 9 Chapter 2 Requirements of S/W Estimation Guidelines 12 Section 1 Overview of Software Cost Estimation 12 Section 2 Derivation Method of Adjustment Factors 16 Section 3 Structure and Problems of Current Guidelines 23 Section 4 Improvement Method of S/W Estimation Guidelines 40 Chapter 3 Collection Model of Cost Data 47 Section 1 Questionnaire of Software Industry Data 47 Section 2 Repository of Software Industry Data 56 Chapter 4 Improvement of S/W Estimation Guidelines 69 Section 1 Comparison of Software Cost Estimation Model 69 Section 2 IFPUG General Systems Characteristics 78 Section 3 Application of Schedule Adjustment Factor 88 Chapter 5 Comparison of Current and New Guidelines 94 Section 1 Analysis of Current Guidelines by Questionnaire 94 Section 2 Validation of Current Guidelines by Cost Data 105 Section 3 Validation of Schedule Adjustment Factor 112 Section 4 Continuous Improvement of Guidelines 117 Chapter 6 Conclusion 123 - xiii -
References 125 Appendix 1. Questionnaire of Adjustment 127 Appendix 2. Questionnaire of Cost Data 137 - xiv -
Tables [Table 2-1] Example of Macroestimating Adjustment 17 [Table 2-2] Example of Microestimating Adjustment 18 [Table 2-3] Positive Impact of Adjustment Factors on Productivity 20 [Table 2-4] Negative Impact of Adjustment Factors on Productivity 21 [Table 2-5] General Ranking of Key adjustment Factors 23 [Table 2-6] Comparison between BON and FP Estimation Method 26 [Table 2-7] Structure of Software Cost Estimation Guidelines 28 [Table 2-8] Price per FP 29 [Table 2-9] Price per LOC 29 [Table 2-10] Size(LOC) Adjustment Factor 30 [Table 2-11] Application Type Adjustment Factor 30 [Table 2-12] Language Adjustment Factor 31 [Table 2-13] Quality and Characteristics Adjustment Factor 32 [Table 4-1] Comparison between Estimation Model and Guidelines 69 [Table 4-2] ACAP Cost Driver 70 [Table 4-3] PCAP Cost Driver 71 [Table 4-4] PCON Cost Driver 71 [Table 4-5] APEX Cost Driver 72 [Table 4-6] PLEX Cost Driver 72 [Table 4-7] LTEX Cost Driver 73 [Table 4-8] TOOL Cost Driver 74 [Table 4-9] SITE Cost Driver 75 [Table 4-10] Cost Driver of Early Design Model 77 [Table 4-11] Adjustment Factor and VAF Range 84 [Table 4-12] VAF of GSC and Adjustment Factor Range 85 [Table 4-13] Adjustment Factor Conversion 87 [Table 4-14] Schedule Adjustment Factor of COCOMO Ⅰ 89 [Table 4-15] Schedule Adjustment Factor of COCOMO Ⅱ 89 [Table 4-16] Schedule Adjustment Factor (Proposal 1) 93 [Table 4-17] Schedule Adjustment Factor (Proposal 2) 93 - xv -
[Table 5-1] Classification of Organization 94 [Table 5-2] Classification of Job 94 [Table 5-3] Experience of Software Business 95 [Table 5-4] Awareness and Usage Level of Guidelines 96 [Table 5-5] Application Method of GSC 102 [Table 5-6] Schedule Adjustment Factor (Proposal 1) 104 [Table 5-7] Schedule Adjustment Factor (Proposal 2) 104 [Table 5-8] Application Effects of Adjustment Factors 109 [Table 5-9] Application Effects per Adjustment Factor 110 [Table 5-10] Application Effects of Factors based on GSC 112 [Table 5-11] Comparison between Guidelines and Proposals 112 [Table 5-12] Comparison between Guidelines and Adjusted VAF 114 [Table 5-13] Schedule Adjustment Factor (Proposal) 116 [Table 5-14] Time Recording Log 118 [Table 5-15] Time and Defects Recording Log 119 [Table 5-16] LOC Counting Standard Template 120 - xvi -
Figures [Figure 2-1] Estimation Accuracy based on S/W Life-cycle 14 [Figure 2-2] Software Cost Estimation Techniques 16 [Figure 2-3] Employee Management Program 25 [Figure 2-4] Improvement of S/W Cost Estimation Guidelines 27 [Figure 3-1] Survey Form of Basic Items 49 [Figure 3-2] Survey Form of Size Estimation 51 [Figure 3-3] Survey Form of Actual Effort and Size 52 [Figure 3-4] Survey Form of Contract and Actual Cost 53 [Figure 3-5] Survey Form of Existing Adjustment Factors 54 [Figure 3-6] Survey Form of GSC 55 [Figure 3-7] Application of S/W Cost Data 58 [Figure 3-8] Organization of S/W Cost Data Repository 60 [Figure 3-9] S/W Cost Data Repository 61 [Figure 3-10] FP Estimation 61 [Figure 3-11] Initial Screen of Cost Estimation 62 [Figure 3-12] Unadjusted S/W Development Cost 63 [Figure 3-13] Software Cost Estimation Value 63 [Figure 3-14] Report Function of Repository 64 [Figure 3-15] Comparison of COCOMO Ⅱ 64 [Figure 3-16] Comparison of V-ANGEL 65 [Figure 3-17] Benchmarking using Industry Data 65 [Figure 3-18] Application of Cost Data Repository 66 [Figure 5-1] Reason of Unusage of Guidelines 96 [Figure 5-2] Comparison between Estimated Cost and Actual Cost 96 [Figure 5-3] Reason of Inconsistencies 97 [Figure 5-4] Comparison between FP Cost and Actual Cost 97 [Figure 5-5] Accuracy of Size Adjustment Factor 98 [Figure 5-6] Reason of Unaccuracy of Size Adjustment Factor 98 [Figure 5-7] Accuracy of Application Type Adjustment Factor 99 [Figure 5-8] Reason of Unaccuracy of App. Type Adjustment Factor 99 - xvii -
[Figure 5-9] Accuracy of Language Adjustment Factor 100 [Figure 5-10] Reason of Unaccuracy of Language Adjustment Factor 100 [Figure 5-11] Accuracy of Quality Adjustment Factor 101 [Figure 5-12] Reason of Unaccuracy of Quality Adjustment Factor 101 [Figure 5-13] Accuracy of GSC 102 [Figure 5-14] Schedule Estimation Equation 103 [Figure 5-15] Application Method of Schedule Adjustment Factor 105 [Figure 5-16] Estimation Trends of S/W Cost Guidelines 108 [Figure 5-17] Estimation Trends of Cost Guidelines (MRE>0.25) 109 [Figure 5-18] Analysis of Current Guidelines (MMRE) 110 [Figure 5-19] Analysis of Current Guidelines (PRED(0.25)) 111 [Figure 5-20] Analysis of Proposal based on GSC (MMRE) 113 [Figure 5-21] Analysis of Proposal based on GSC (PRED(0.25)) 113 [Figure 5-22] Analysis of Proposal based on Adjusted VAF (MMRE) 115 [Figure 5-23] Analysis of Proposal based on Adjusted VAF(PRED) 115 [Figure 5-24] Comparison of Schedule Adjustment Factor 116 - xviii -
제 1 장연구개발의개요 제 1 절연구개발의필요성 소프트웨어공학에는해결해야할많은문제들이있다. 특히소프트웨어개발에있어서가장중요한작업중의하나는소프트웨어개발비용을정확하게예측하는것이다. 소프트웨어개발비용을정확하게추정하기위한소프트웨어개발비용산정모형에관한연구는국내외적으로활발하게진행되어왔다. 국내의소프트웨어개발비대가기준은 1989년에최초로고시된후에소프트웨어산업발전에맞춰꾸준히개선연구를추진하여현재정부및공공, 민간에서널리활용되고있는실정이다. 그러나소프트웨어개발비대가기준은과거 10여년이상본수및스텝수기반의규모측정방식이사용되어객관적이고신뢰성있는비용산정이불가능하였다. 또한객관적인근거없이설정된보정계수및비용산정구조의영향으로산정결과에대한논란이지속적으로제기되었다. 이에합리적인소프트웨어개발비산정을위해 2003년에정보통신부, 한국전산원, 한국소프트웨어산업협회를중심으로사용자요구를반영하는기능점수기반의소프트웨어사업대가기준개선연구가진행되었고, 그결과 2004년기능점수방식에따라소프트웨어개발비대가기준이개정고시되었다. 미국은정부차원의소프트웨어개발비대가기준을마련해놓고있지는않지만, 계약자로하여금과거실적데이터에기반한객관성이입증된합리적인알고리즘비용산정모델 (Boehm의 COCOMO, Freiman의 PRICE-S, Galorath의 SEER-SEM, Putnam의 SLIM, Rubin의 ESTIMACS, Jones의 - 1 -
KnowledgePlan 등 ) 의이용을권장하면서이를위한구체적인산정지침을 제공하고있다. 2004년고시된개정소프트웨어개발비대가기준은위에제시한선진모형과비교하여볼때, 일부기존보정계수의조정및신규보정계수의도입을중심으로개선필요성이제기되고있다. 또한기능점수기반사업대가기준개선작업의일환으로수행된 2003년한국전산원위탁과제 민간부문정보화사업비용자료구축 의연구에의하면설문응답대상 85% 의수발주자가납기보정계수의필요성을느끼고있는것으로조사되었다. 따라서소프트웨어사업대가산정의정확성을제고하고정보화사업의예 산및비용산정의과학화를위해납기보정계수등소프트웨어개발비대 가기준모형을개선하기위한지속적인연구가필요하다고하겠다. 제 2 절연구개발의목표및내용 1. 연구개발의목표 2004년고시된소프트웨어개발비대가기준에대한추가개선사항도출 - 과년도연구과제에서조사된설문결과분석을기초로추가개선사항유도 - 선진비용산정모형들과의비교분석을통한거시적관점에서의추가개선사항유도 - 선진비용산정모형들과의비교분석을통한미시적관점에서의추가개선사항유도 - 2 -
소프트웨어개발비산정을위한기존보정계수의타당성검토및신규보정계수의도출 - 비용산정모형의정확성분석을위한척도를이용하여기존보정계수의타당성을각각검토 - 검증결과타당성이인정되지않은기존보정계수의조정 - 선진비용산정모형들과의비교분석을통한신규보정계수의도출 - 과년도연구과제에서도출필요성이이미제기된바있는납기보정계수의유도 소프트웨어개발비대가기준개선모형제시 - 현행모형과개선모형과의모형비교및차이분석 - 현행모형과개선모형의보정계수간정확성비교 / 분석 2. 연구개발내용및범위 가. 소프트웨어개발비대가기준의추가개선 (1) 목적 현행소프트웨어개발비대가기준모형의추가적보완및개선사 항을도출 (2) 문제점 개정고시된현행대가기준은규모척도를기능점수로변경하고일부보정계수를조정하는데중점을두었다. 즉, 기능점수의도입에따라대가기준의비용산정체계를조정하여기능점수당통합단가체제로변환한것이외에전체대가기준의산정체계를수정하지는않아선진비용산정모형과는기본적인구조에차이가있다. - 3 -
현행대가기준에서는기능점수당단가기준을이용하여개발비용을직접적으로산정하고있다. 그러나선진비용산정모형의경우소프트웨어규모를이용하여개발노력인공수 (MM) 를구한후월간인건비기준에따라개발비용을구하거나, 앞에서구한공수를이용하여개발기간 ( 적정납기 ) 을산정하고있다. 또한현행대가기준은매우거시적인관점에서개발비용을산정하는것이외에는프로젝트관리에필요한유용한정보를도출할수없는반면, 선진비용산정모형의경우개발노력, 개발기간등의유용한정보들을생명주기단계별로산출할수있는미시적관점을지원하고있다. 발주기관의경우개정고시된현행대가기준을이용하면지나치게 많은개발비용이산정된다는불만을가지고있다. (3) 접근방법 선진비용산정모형을벤치마킹하여추가개선요구사항을도출한 다. 관련된각종사례분석을통해서기존의연구결과및지침등을분 석, 정리한다. 이러한분석결과는소프트웨어개발비대가기준의객 관적 / 과학적틀을설정하는데기초자료로활용된다. 나. 비용자료수집모형제시 (1) 목적 - 4 -
소프트웨어사업대가기준의지속적인개선및검증을위한비용자 료수집모형을개발 (2) 문제점 그동안오랜기간동안소프트웨어사업대가기준개선및비용자료구축에관한연구가진행되었음에도불구하고비용산정및단가고시에필요한비용자료수집모형이제시되지못하고있다. 따라서많은프로젝트로부터산출가능한유용한비용자료가사장되 거나, 많은비용을들여왜곡된비용자료의수집이이루어지고있다. (3) 접근방법 소프트웨어사업대가기준의지속적인개선및검증을위한비용자료수집모형을개발한다. 또한이수집모형을이용하여국내대가기준과해외소프트웨어비용산정모형간의산정결과의비교가가능하도록한다. 다. 보정계수에대한개선연구 (1) 목적 소프트웨어산업환경변화를반영할수있도록보정계수의현실화와정확도개선 (2) 문제점 소프트웨어개발비대가기준의보정계수항목은선진비용산정모형의보정계수와비교할때매우제한된다. 즉, 프로젝트에서고려해야하는특성이매우다양함에도불구하고, 국내대가기준에서는소수의특성만을고려하고있다. - 5 -
현행대가기준에서는규모, 언어, 유형, 품질및특성보정계수등의 4개의항목만을고려하고, 품질및특성보정계수에서세부적으로 4 가지특성을고려하는데비해, IFPUG의일반시스템특성은 14개항목, COCOMO의경우 15개이상의보정계수를고려하고있다. 특히소프트웨어납기단축정도에따라소프트웨어개발비용이크게좌우되고있으나, 현행사업대가기준에는이에대한고려가없다. 이처럼다양한보정요소를고려하지못함으로인해대가기준의정확도개선에한계가있다. (3) 접근방법 비용산정의정확도분석을위한대표적인척도인 PRED와 MMRE를이용하여각보정계수의타당성을검토한후문제점및개선방향을제시한다. 전년도연구에서이미필요성이제기된바있고다수의선진비용산정모형에서채택하고있는납기보정계수를도출한다. 이를위해납기보정계수의대표적인유형을분석한후에이를기초로보정계수를유도한다. 소프트웨어사업대가기준에서의납기보정계수유도방안은다음과같다. - 비용자료를이용하여규모와개발기간간의관계를이용하여적정납기를구할수있는모형을개발한다. - 전문가들의의견및해외선진모형을참고하여적절한납기보 정계수를유도한다. 기존보정계수이외의신규보정계수의도입을검토한다. - 6 -
라. 소프트웨어개발비대가기준의개선모형제시 상기세부적인연구주제인 1) 소프트웨어개발비대가기준의추가개 선, 3) 보정계수에대한개선연구결과를적용한대가기준의개선모 형을제시한다. 마. 현행소프트웨어개발비산정모형과개선모형의비교분석결과제출 궁극적으로는본연구결과에서도출된대가기준의개선모형이제도적으로활용되기위해서는수집자료를이용하여검증되어야한다. 이를위해서는현행소프트웨어개발비산정모형과개선모형에수집자료를적용한후두모형간의비교분석결과를제출한다. - 기능점수의보급및활용과함께새로수집된비용자료를바탕으로현행대가기준과본연구에서제안하는개선모형은지속적으로검토되어야한다. - 개선모형의정확성은기수집된비용자료로검증하기어려우므로신규수집자료를적용한다. - 현행소프트웨어개발비산정모형과개선소프트웨어개발비산정모형과의모형비교및차이분석을실시한다. - 현행소프트웨어개발비산정모형과개선소프트웨어개발비산정모형의보정계수간정확성을비교 / 분석한다. - 7 -
제 3 절연구개발추진일정 과제내용 추 진 일 정 ( 월별 ) 6 7 8 9 10 1. 과제착수 --> - 계획서작성 - 킥오프미팅 2. 개발비대가기준추가개선요구사항도출 --- --> - 개발비대가기준적용현황분석 - 문헌연구및개선기본방향검토 - 해외선진사례수집분석 3. 비용자료수집모형제시 -- ---- -> - 자료항목선정 - 리포지토리개념모형설계 4. 보정계수에대한개선연구 ---- ---- ---> - 기존보정계수의타당성검토 - 보정계수개선방향제시 - 선진모형의납기보정계수분석 - 적정납기계산식유도 - 납기보정계수도출 - 신규보정계수검토 5. 현행모형과개선모형의비교분석 ---- --> - 모형비교및차이분석 - 보정계수간정확성비교분석 - 비교분석결과평가 7. 최종보고서작성및최종발표 --> - 최종보고서작성 - 최종발표 - 8 -
제 4 절연구개발추진전략및방법 1. 연구개발추진체계 본연구는현행소프트웨어개발비대가기준의개선을위하여포괄적 이고실제적인연구가수행될수있도록다음과같은입체적인연구 추진체계로서수행된다. 대가기준개선연구팀 연구협력팀운영 상호공조운영 전문가활용 소프트웨어개발비대가기준개선요구사항도출소프트웨어개발비비용자료수집모형제시개발비대가기준의기존보정계수타당성검토납기보정계수및신규보정계수유도 관련기관의실무자및전문가검토 현행소프트웨어개발비대가기준개선모형제안실데이터를적용한개선모형의타당성검증 연구팀및전문가그룹전체검토최종보고서작성 - 9 -
2. 연구개발추진전략 제 1 단계는현재의소프트웨어비용산정에대한현황분석및자료수집 단계이다. 이단계에서는지금까지국내외비용산정모델의연구현황과사 용현황을분석한다. 향후의수요에대한기초조사를실시한다. 제 2 단계는 1단계에서분석된현황분석을토대로개선된소프트웨어개발비대가기준의초안을마련하는단계이다. 이단계에서는국내외의관련기법을심층적으로분석하게되는데특히납기보정계수를중심으로다양한보정계수에관한심도있는검토가필요하다. 연구팀은납기보정계수등을포함하는개선된대가기준의초안을제시하고, 이와관련된전문위원그룹의역할을강화하여실질적인역할을할수있도록연구의초안자료를제시하고적극적인피드백을요청한다. 또한연구팀은연구자별로담당분야를지정하여깊이있는연구가되도록한다. 제 3 단계는 2단계에서도출된개발비대가기준의개선모형의초안을포괄적으로검증하고보완하는단계이다. 본연구에서는개선모형이최대한체계적이고실용적으로도출되도록하기위해비용자료를활용하여최적의대가산정개선모형을유도한다. 이때도출된개선모형은전문가들로하여금검토및의견을수렴하는것을포함하여그타당성을검증하도록한다. 3. 연구개발방법 본연구는실무현장조사, 문헌조사, 기초자료통계분석, 전문가면담, 워크샵, 브레인스토밍, 실증분석등의방법을통하여수행된다. 연구개발추진단계중제 1 단계에서는문헌조사, 실무및해외선진사 례조사, 전문가면담등의방법으로서연구를수행하고, 제 2 단계에서는 - 10 -
통계분석, 전문가면담, 워크샵, 브레인스토밍등의방법을활용한다. 통계분석은다양한보정계수에대해수행되어최적의모형이개선대가기준에반영될것이다. 또한제 3 단계에서는검토회의와실무전문가면담등의방법을활용하며, 특히비용자료를적용하여본개선모형의타당성및객관성을실증분석한다. 연구과정과방법을도시하면다음과같다. 연구목표관련문헌조사실무현장조사신진기법분석 소프트웨어개발비대가기준개선모형 검토회및면담수행 통계분석 브레인스토밍및워크샵 모형의실증분석및관련실무자의견반영 대가기준개선모형의최적화및확정 - 11 -
제 2 장 S/W 개발비대가기준의개선요구사항 제 1 절소프트웨어비용산정개요 소프트웨어개발초기단계에서소프트웨어개발비용을정확하게예측하는것은프로젝트의성패를결정짓는중요한요소이다. 비용을과대추정하여고객이프로젝트를취소할수도있고, 실제소요될비용보다비용을적게예측함으로써개발업체는실제로이윤을남기지못하고많은시간만을낭비하게될수도있다. 소프트웨어생명주기초기에개발비용을정확히예측하면프로젝트관리자들은어떤자원이필요한지적합한자원들을언제배정해야할지를알수있다. 프로젝트예산에는설비, 구성원, 방법론및도구등에관련된여러종류의비용이포함될수있다. 설비비용에는하드웨어, 사무실, 가구, 전화, 냉난방기, 디스크, 종이, 필기구, 복사기등의개발자들이작업할수있도록제공되는제반물리적항목들이포함된다. 이런환경이이미구비되어있는프로젝트의경우에는비용산정이용이하다. 그러나어떤프로젝트의경우에는이런환경을새로이갖추어야할수도있다. 예를들면, 새로운프로젝트를위한시건장치, 마루, 온도및습도조절기, 특수가구들이필요할수도있다. 이런경우에도비용을산정할수는있지만, 주변환경이구축되거나변화됨에따라초기산정액은변경될수도있다. 때로는관리자들이나개발자들이예측하지못한숨겨진비용이있을수있다. 예를들면, 프로그래머가효과적으로작업하기위해서는최소한의공간과조용한환경이필요하다. 전화나예상치못한방문객의방해를받지않은프로그래머들이반복적인방해를받는프로그래머들보다생산성이훨씬높다. - 12 -
다른프로젝트비용으로는개발에필요한소프트웨어와도구의구입비용이있다. 설계와구현을지원하는도구뿐만아니라요구사항분석, 명세서작성, 문서화, 코드시험, 변경사항의추적, 시험자료의생성, 그룹회의를지원하는데필요한소프트웨어를구입할수도있다. 특히 CASE(Computer Aided Software Engineering) 도구들은고객이요구하기도하고, 회사의소프트웨어개발표준공정의부분으로서필요할수도있다. 대부분의프로젝트에서가장많은비용이소요되는부분은노력 (effort) 이다. 프로젝트를완료하기위해얼마나많은노력에대한공수 (person-months) 가요구되어질것인가를사전에예측해야한다. 노력은불확실성이가장높은비용요소이다. 작업스타일, 프로젝트의구성, 능력, 관심, 경험, 훈련등은개발비용에많은영향을미친다. 더군다나그룹내의구성원들이의견을교환해야하고다른그룹과의토의가필요한경우, 회의나문서화또는훈련에소모되는시간만큼의노력이추가로필요하다. 소프트웨어개발비용, 일정, 노력의정확한산정은프로젝트에서자원의할당및프로젝트의수행여부결정에영향을주기때문에소프트웨어생명주기에서가능한빨리완료되어야한다. 만일이산정비용이너무커서예산을초과하게되면고객은프로젝트를취소할수도있다. 또한비용산정은생명주기동안지속적으로반복되어야한다. 프로젝트가변경될경우, 산정비용은프로젝트특성에대한좀더많은정보를바탕으로수정되어야한다. < 그림 2-1> 은생명주기초기의불확실성이비용및규모산정의정확도에끼치는영향을보여준다 [1]. - 13 -
elativecostrange4x e4x 2x 1.5x 1.25x x 0.8x 0.67x 0.5x 0.25x Concept of operation Requirements specification Product design specifications Detailed design specification softwareraccepted Feasibility Plans and Product Detailed Development requirements design design and testing < 그림 2-1> 소프트웨어생명주기에따른산정정확도 < 그림 2-1> 에서는실제소프트웨어의규모와비용을산정한것을생명주기단계별로나타낸것이다. 오른쪽으로좁아지는깔때기모양의선은프로젝트에대해더많은정보를알게되면산정이정확해지는정도를표현한것이다. 여기에서프로젝트의상세한내용이알려지지않은초기에는산정비용이실제비용과최대 4배까지도차이가날수있음을알수있다. 제품과개발공정이안정됨에따라이러한차이점은점차감소한다. 정확한산정값을얻기위해소프트웨어공학분야에서는개발비용과구성원의특성과의관련성, 프로젝트요구사항및개발기간, 노력, 비용에영향을미치는다른요소들을발견하는기술들을개발하기위해노력해왔다. 본보고서는정보통신부가 2004년 2월에개정고시한소프트웨어개발비대가기준의개선에관한것이다. 소프트웨어비용산정모델은여러가지목적으로활용된다. 대표적인활 용분야를정리하면다음과같다. - 14 -
예산수립 : 가장기본적인사용분야로, 전체적인산정의정확도가가장중요한요소이다. Tradeoff 분석과리스크분석 : 소프트웨어프로젝트진행시범위설정, 인력배치, 도구, 재사용등의의사결정이비용과일정에미치는영향을분석한다. 프로젝트계획과관리 : 개발비용과일정을컴포넌트, 단계, 작업별로분해한다. 투자분석 : 소프트웨어개발을위한도구, 재사용, 프로세스성숙도에관한전략을채택했을때의이익을추정한다. 다른분야와마찬가지로소프트웨어비용산정모델분야의연구도많은문제점을가지고있다. 매우빠르게변화하는소프트웨어개발의특성상모든영역의소프트웨어개발에관해정확도가높은모델을개발하기가매우어렵다. 소프트웨어개발비용은계속증가하고있지만, 비용산정분야에종사하는실무자들은소프트웨어개발비용을정확하게예측할수없다는점에고심하고있다. 소프트웨어공학분야의가장중요한목표중의하나는소프트웨어생명주기를잘설명하고개발비용을정확하게예측하는유용한모델을개발하는것이다. 소프트웨어비용산정모델에관한주요연구는 1965년 169개소프트웨어프로젝트의 104가지의속성에관한 SDC의광범위한연구로시작되었다. 이모델을기초로 1960년대후반과 1970년대초반부분적으로유용했던일부모델들이유도되었다. 1970년대후반에 SLIM, Checkpoint, PRICE-S, SEER, COCOMO 등과같은알고리즘모델이개발되었다. 이들비용산정모델의개발자대부분이동일한시기에비용산정모델을개발하기시작했지만, 그들은모두유사한딜레마에빠졌다. 즉, 소프트웨어의크기가커지고복잡해짐에따라소프트웨어개발비용을정확하게예측하기가점점더어렵다는것이다. 알고리즘모델자체의문제점과더불어매우빠르게변화하는개발환경의영향으로정확도가높은알고리즘모델을개발하기란 - 15 -
매우어렵다. 고전적인기법인회귀분석을포함하여소프트웨어비용산정기법은 < 그림 2-2> 와같이크게여섯개의범주로분류할수있다. Software Estimation Techniques Model-Based- Learning-Oriented- Regression-Based- SLIM, COCOMO, Neural, Case-based OLS, Robust Checkpoint, SEER Dynamics-Based- Composite- Expertise-Based- Abdel-Hamid-Madnick Bayesian-COCOMO II Delphi, Rule-Based < 그림 2-2> 소프트웨어비용산정기법 제 2 절보정계수도출방안 1. 보정요인 상용소프트웨어산정분야에서거시적인산정 (macoestimation tools) 도구와미시적인산정도구 (microestimation tools) 가산정값을보정 (adjustments) 하는방식은다소상이하다. 거시적인산정도구는전형적으로기술수준, 도구, 기법과같은다양한조정요인으로부터정보를축적하여전체프로젝트에대한승수 (multiplier) 로사용한다. 예를들어, 만일보통의도구와기법을이용하는평균수준팀의월간 생산성이 PM 당 10FP 혹은 1000LOC 라면, 우수한도구와기법을갖춘상위 수준팀의생산성은 2 배로 PM 당 20FP 혹은 2000LOC 가될것이다. 역으로 - 16 -
그저그런도구와기법을갖춘하위수준팀의생산성은 PM당 5FP 혹은 500LOC에불과할것이다. 이상황에서팀의능력과개발도구의수준은 2 에서 1의범위의생산성승수로변환된다. 비용산정도구내부에 < 표 2-1> 과유사한테이블이있을수있다 [2]. < 표 2-1> 거시적인산정도구의보정예 요인들의조합 승수 우수한도구를가진상위수준팀 2.00 보통의도구를가진상위수준팀 1.75 우수한도구를가진평균수준팀 1.50 그저그런도구를가진상위수준팀 1.25 보통의도구를가진평균수준팀 1.00 그저그런도구를가진평균수준팀 0.90 우수한도구를가진하위수준팀 0.75 보통의도구를가진하위수준팀 0.65 그저그런도구를가진하위수준팀 0.50 비록이러한 9개의조합이어느특정산정도구에서얻어진것은아니지만, 그것들은다양한요인들의조합이테이블검색기능에의해생산성보정으로변환되는방식을보여준다. 보통의도구를가진평균수준팀이 PM당 10FP의생산성을가정하면, 우수한도구를가진상위수준팀은 PM 당 20FP의생산성을가정할수있을것이고, 반면에그저그런도구를가진하위수준팀은 PM당 5FP에불과한생산성을가정할수있을것이다. 예시한것과같이, 이두가지요인의 9가지조합은평균중심값을생성하고, 평균에비해양호하거나양호하지않은상황을다루기위해평균을중심으로양쪽방향으로 4가지조합을산출한다. 보정방식에대한이러한예시는단지보기일뿐이고, 보정가중치나승수가실제로추정되는것을나타낸것은아니다. 실제로이러한조합은그들의영향범위내에서합리적이다. - 17 -
미시적인산정도구도마찬가지로보정요인을다루지만, 여러요인들을동시에커버하는집합적인보정요인을이용하는것이아니라, < 표 2-2> 와같이전형적으로각요인을독립적으로적용한다. 각요인을개별적으로적용하는미시적인산정방식은상황에따라특정요인을포함하거나배제한다. 이렇게하는것이매우유용한이유는소프트웨어생산성이라는것은소프트웨어프로젝트의결과에영향을미칠수있는최소한 100개이상의요인들을가진복잡한현상이기때문이다. < 표 2-2> 미시적인산정도구의보정예 등급팀승수도구승수 Excellent 1.50 1.20 Good 1.25 1.10 Average 1.00 1.00 Below average 0.75 0.90 Poor 0.50 0.80 더욱이각요인을독립적으로적용하는것은각보정요인의가능한범위를제시하는것과동일한의미이다. 예를들어, 보통수준의도구를가진평균수준팀이 PM당 10FP의생산성을가진다고가정하면, 다음조합이얻어질수있다. Excellent team Excellent tools 10 1.5 = 15 FP/PM 15 1.2 = 18 FP/PM Excellent team Poor tools 10 1.5 = 15 FP/PM 15 0.8 = 12 FP/PM Poor team Excellent tools 10 0.5 = 5 FP/PM 5 1.2 = 6 FP/PM - 18 -
Poor team Poor tools 10 0.5 = 5 FP/PM 5 0.8 = 4 FP/PM 각요인을순차적으로적용하는이러한방식은무한히계속될수있다. 그러나만일한요인이보통 (average) 이고곱하는효과가 1이라고가정하면, 프로젝트가보통보다양호하거나양호하지못한요인인경우에만보정을할필요가있다. 실제로는소프트웨어프로젝트결과에영향을줄수있는 100개이상의요인들이존재하기때문에, 보정범위가매우크다는것을알수있다. SPR 지식베이스에의하면대략 8000개의소프트웨어프로젝트가 PM당 0.13FP에서부터 PM당 140FP에달한다. 즉, 소프트웨어생산성의범위는매우광범위하다. 그렇다면여기에서평균생산성보다매우높거나낮은원인에관한의문이제기될수있다. 소프트웨어생산성에영향을미치는요인중에서일부는소프트웨어프 로젝트팀의통제밖에있다. 비록이러한요인들이중요하더라도, 그것들 을조정할수있는능력은거의없다. 예를들어, 규모가 10,000FP 이상의대형시스템이규모가 100FP 미만의소형프 로젝트보다생산성이낮다. 미국의경우, DoD 2167 과같은표준을준수하는국방소프트웨어프 로젝트는방대한양의문서작업을요구하기때문에유사한민간프로젝 트보다생산성이낮다. 여기에서소프트웨어개발팀의통제밖에있는요인들을논의하는것은 가치가없다. 대신우리가관심을가지는것은도구의선택, 프로그래밍언 - 19 -
어, 개발공정과같은통제수단이존재하는요인들이다. 2. 소프트웨어생산성과보정요인 소프트웨어개발프로젝트에긍정적인영향과부정적인영향을미칠수 있는요인들을살펴볼필요가있다. < 표 2-3> 은소프트웨어생산성에긍정 적인영향을미치는요인들을나타낸것이다. < 표 2-3> 생산성에긍정적인보정요인 요인 영향 Reuse of high-quality deliverables 350% High management experience 65% High staff experience 55% Effective methods or process 35% Effective management tools 30% Effective technical CASE tools 27% High-level programming languages 24% Quality estimating tools 19% Specialist occupations 18% Effective client participation 18% Formal cost and schedule estimates 17% Unpaid overtime 15% Use of formal inspections 15% Good office ergonomics 15% Quality measurement 14% Low project complexity 13% Quick response time 12% Moderate schedule pressure 11% Productivity measurements 10% Low requirements creep 9% Annual training of > 10 days 8% No geographic separation 8% High team morale 7% Hierarchical organization 5% 합 800% - 20 -
소프트웨어생산성을향상시킬수있는세가지가장중요한요인들은 고품질의재사용가능자료들과유사한종류의어플리케이션을구축한바 있는관리자와기술인력모두의경력수준이다. < 표 2-4> 의요인들은소프트웨어생산성을낮추거나떨어뜨릴수있는 보정요인들이다. < 표 2-4> 생산성에부정적인보정요인 요인 영향 Reuse of poor-quality deliverables -300% Management inexperience -90% Staff inexperience -87% High requirements creep -77% Inadequate technical CASE tools -75% No use of inspections -48% Inadequate management tools -45% Ineffective methods or process -41% No quality estimation -40% High project complexity -35% Excessive schedule pressure -30% Slow response time -30% Crowded office space -27% Low-level programming languages -25% Geographic occupations -24% Informal cost and schedule estimates -22% Generalist occupations -15% No client participation -13% No annual training -12% No quality measurements -10% Matrix organization -8% No productivity measurements -7% Poor team morale -6% No unpaid overtime 0% 합 -1067% < 표 2-3> 과 < 표 2-4> 에서알수있는것처럼, 소프트웨어재사용보정 요인은소프트웨어생산성을향상시키는데가장큰영향을끼칠수도있고 - 21 -
또한생산성을감소시키는데에도가장큰영향을미칠수있다. 소프트웨어재사용의긍정적인효과는재사용가능산출물이결함이없을때에만가능하다. 만일재사용가능산출물이에러나버그로가득차면, 소프트웨어재사용이부정적인영향을미칠것이다. 소프트웨어재사용은단지소스코드이상의많은것과연관된다. 효과적으로조정된재사용프로그램은다음과같이적어도 5개의재사용가능산출물을포함할것이다. 1 재사용가능요구사항 2 재사용가능설계 3 재사용가능소스코드 4 재사용가능테스트자료 5 재사용가능문서화 소프트웨어재사용으로부터최적의긍정적인효과를얻기위해, 각주요 한소프트웨어산출물은최소한 75% 재사용된것을포함해야하는데, 이 것은결함이없는것으로인증을받은것이어야한다. < 표 2-4> 의또다른흥미있는측면은부정적인요인의영향도의총합은 < 표 2-3> 의긍정적인요인에대한총합보다훨씬크다는것이다. 이것은바르게진행하고생산성을향상시키는것보다는그릇된방향으로진행하고생산성을낮추는것이더욱쉽다는것을의미한다. 일반적으로긍정적인영향과부정적인영향사이가대개균형을이루지못한다. 예를들어, 좋은개발공정은소프트웨어생산성에어느정도긍정적인영향을미칠것이지만, 실제로나쁜개발공정은생산성에매우심각한부정적인영향을미칠수있다. 일상생활에서담배를예로들면, 흡연은건강에부정적인영향을미치는것이훨씬심각하다. 반면에금연을한다고해서건강하지못할위험성을감소시키는것이지, 사람을건강하게 - 22 -
만들지는못한다는것과유사하다. < 표 2-5> 는전체적인영향도가큰 8개의주요보정요인들의일반적인순위를보인것이다. 상식적인수준에서보더라도, 상위수준의능력있는팀과우수한도구를가진소형프로젝트가하위수준의팀과효과가의문시되는도구를가진대형프로젝트에비해더욱생산적이라는것을알수있다. < 표 2-5> 주요보정요인의우선순위우선순위보정요인 1 Size of project 2 Team experience 3 Reusable material 4 Schedule pressure 5 Creeping changes 6 Methodologies 7 Tools 8 Ergonomics 제 3 절현행대가기준의구성및문제점 1. 현행대가기준의구성 가. 사업대가기준의근거및경과 1) 제정근거 소프트웨어산업진흥법제 22 조및동시행령제 15 조에의해정보통신부 고시로규정하고있는소프트웨어사업대가기준은국가기관등이소프트 - 23 -
웨어개발, 데이터베이스구축, 정보전략계획수립등의정보화사업을추진함에있어정보통신기술의발전및사회적여건변화에유연하게대처하고, 소프트웨어산업과의선순환적구조를가질수있도록소프트웨어사업에대한예산수립이나발주시적정비용등을산정하기위한기준을제공하는것을목적으로하고있다. 2) 개정경과 - 89. 4. 소프트웨어개발비산정기준 최초제정및고시 ( 과학기술처 ) - 94. 1. 유지보수대가신설등 1 차개정고시 ( 과학기술처 ) - 96. 3. 스텝당단가개념도입등 2 차개정고시 ( 정보통신부 ) - 97. 7. SI 사업개념을도입한대가구조로 3차개정고시 ( 정보통신부 ) * 소프트웨어개발촉진법개정 (95.12) 으로 소프트웨어개발비산정기준 에서 소프트웨어사업대가기준 으로확대개정 * 정보전략계획수립비, 시스템운영환경구축비, DB구축비등이신설 - 98. 12. 한국형기능점수모형의도입을위한연구 ( 정보통신부 ) * 신뢰성이검증되지않아서채택되지못함 - 99. 12. 97 년고시기준의보완및현실화방안연구 ( 정보통신부 ) 유 권해석이모호한부분 ( 제경비, 기술료등의보정계수및기타 ) 보완 * 공감대가형성되지못하여채택되지못함 - 24 -
나. 기능점수기반의사업대가기준 소프트웨어사업대가기준은 1989년제정된이후기술발전과환경변화에따라수차례개정되어왔으나, S/W개발규모산정방식인 본수방식 의비일관성과규모ㆍ언어ㆍ애플리케이션유형등보정계수의비현실성문제점이수년간공공발주기관, 산업계등으로부터지속적으로제기되어왔다. 개정전기존소프트웨어사업대가기준에서적용되어온규모산정방식은본수방식이다. 본 ( 本 ) 은입력, 조회, 수정, 출력등유형별기능을독립적으로실행할수있는프로그램의최소단위로서본들간의결합도는낮고본내부스텝들간의응집도는높게설계된스텝들의집합단위를나타낸다. 산정방법은프로그램의유형 ( 온라인, 배치, 실시간 ) 을식별한후, 유형별평균스텝수를곱하여산정한다. 사용자 : 업무기능요구사항제시 인사기본정보를관리 ( 등록, 조회, 수정, 삭제 ) 하는기능 개발자 : 업무기능을프로그램화 인사기본정보를등록, 조회, 수정, 삭제하는프로그램 사용자화면 응용프로그램서버 DB 서버 인사기본정보관리 인사기본정보등록 인사기본정보등록프로그램 인사기본정보조회인사기본정보수정인사기본정보삭제 인사기본정보조회프로그램인사기본정보수정프로그램인사기본정보삭제프로그램 인사기본정보 < 그림 2-3> 인사기본정보관리프로그램 하나의예로서 < 그림 2-3> 과같은인사기본정보를관리하는프로그램을 가정해볼수있다. 인사기본정보관리프로그램에서사용자화면은인사 - 25 -
기본정보를등록, 조회, 수정, 삭제하는기능으로구성되고, 응용프로그램 서버는인사기본정보를등록, 조회, 수정, 삭제하는프로그램으로구성된다 고가정할수있다. 본수방식으로산정할경우산정하는관계자의관점에따라산정범위가달라질수있다. 인사기본정보관리를하나의본으로산정할수도있고, 인사기본정보관리 ( 등록, 조회, 수정, 삭제 ) 에중점을두어 4개의본으로산정할수도있으며, 인사기본정보관리화면과응용프로그램서버상의프로그램을각각본으로산정하여 8개의본으로산정될수도있기때문에일관적인산정결과를얻을수없다는문제점을지니고있다. 또한개발기술에의해서도산정범위가달라질수있기때문에객관적인측정을할수없다. 그러나기능점수를이용한규모산정은본수방식과는다르게 < 표 2-6> 과같이일관된값을얻을수있기때문에개정대가기준에서는규모척도로기능점수를채택하였다. < 표 2-6> 본수와기능점수산정방식비교 산정범위 본수방식 기능점수방식 1 안 2 안 3 안 인사기본정보관리인사기본정보등록, 조회, 수정, 삭제인사기본정보등록, 조회수정삭제화면과응용프로그램서버상의프로그램 1 본 4 본 8 본 ILF : 1 개 x 10 = 10 EI : 3 개 x 4 = 12 EO : 1 개 x 5 = 5 EQ : 1 개 x 4 = 4 --------------- 31 ( 가중치는 보통 으로가정함 ) 산정규모 1 본 8 본 31 기능점수 다. 개정사업대가기준 - 26 -
2004 년개정된고시에서는그동안지속적으로제기되었던문제점을해결 하도록하였다. 주요한개정내용은다음과같다 [3]. 1 소프트웨어의규모산정방식을본수방식에서국제표준 (ISO/IEC 14143) 에입각하여보다객관적이고일관된측정이가능한규모척도인기능점수방식으로변경하였다. 2 보정계수체계를보완및현실화하여현실적으로사용되지않는보정항목들을삭제하고보정계수를정보기술의발전과사업환경의변화에맞게조정하였다. 3 소프트웨어개발의공정구분을국제표준 (ISO/IEC 12207) 에따라 13 개공정으로세분화하고, 이를 4개단계로구분하였다. 4 비용산정방식을엔지니어링대가기준체계에서국가계약법등을반영하여국제표준의기업회계기준으로변경하였다. < 그림 2-4> 소프트웨어사업대가계산방식의개선 즉, < 그림 2-4> 와같이개선된대가기준방식을통하여, 보다선진화되고 - 27 -
국제표준에따르는소프트웨어규모산정기준을채택함에따라소프트웨어의규모산정의정확성과일관성을높임으로서국내정보화사업의품질을향상시키고소프트웨어산업의경쟁력을제고하는효과를거둘수있게되었다. 소프트웨어사업대가기준은 < 표 2-7> 과같이크게소프트웨어개발비의산정, 시스템운용환경구축비산정, 데이터베이스구축비및자료입력비의산정, 그리고정보전략계획수립비의산정등다섯가지영역으로구성되어있다. < 표 2-7> 소프트웨어사업대가기준구성 구분 정보전략계획수립비 소프트웨어개발비 시스템운용환경구축비 데이터베이스구축비 자료입력비 비용산정단위 컨설팅지수 기능점수코드라인수 시스템운용환경조성비 ( 공사비 ) 미디어별데이터량 스트로크 비용구성 컨설팅대가 = 3,522,622 ( 컨설팅지수 ) 0.95 +10,000,000 1 개발원가 2 이윤 = ( 개발원가 )x 10% 3 직접경비 - 시스템사용료 - 개발도구사용료등 1 시스템운용환경조성비 ( 공사비 ) 2 시스템운용환경설계비 - 기본설계비 - 실시설계비 1 데이터제작비 2 직접경비 - 원시자료수집비 - 기타경비 1 인건비 2 제경비 = 인건비 70% 3 이윤 = ( 인건비 + 제경비 ) 10% 소프트웨어개발비에대한산정은다음절차에따라수행한다. 1) 개발할소프트웨어의규모를산정한다. 소프트웨어규모산정은국 제표준의기능점수방식으로하는것을원칙으로하고있다. 하 지만, 소프트웨어사업의특성상기능점수방식보다는코드라인 - 28 -
수방식으로산정하는것이적정하다고판단되는경우에는코드라 인수방식을적용할수있도록하고있다. 2) 절차 1에서산정된개발규모에의해소프트웨어개발비는개발원가, 직접경비및이윤의합으로산정한다. 기능점수또는코드라인수에각각기능점수당단가또는코드라인당단가를곱하여보정전개발원가를구한다. 개발원가는보정전개발원가에보정계수를곱하여산정한다. 보정전개발원가는기능점수방식에의한개발규모산정의경우에는위에서산정된기능점수에 < 표 2-8> 의단계별기능점수당단가를곱하여보정전개발원가를산출하고, 코드라인수방식에의한개발규모산정의경우에는코드라인수에 < 표 2-9> 의단계별코드라인당단가를곱하여보정전개발원가를산출한다. < 표 2-8> 단계별기능점수당단가 단계 분석 설계 구현 시험 계 기능점수당단가 86,974 111,156 146,491 116,460 461,081 < 표 2-9> 단계별코드라인당단가 단계 분석 설계 구현 시험 계 코드라인당단가 1,841,1 2,353.0 3,100.9 2,465.2 9,760.2 3) 절차 2에서도출된보정전개발원가는개발하고자하는소프트웨어의규모, 어플리케이션의복잡성등과같은각사업별로발생할수있는특성적요인들을고려하지않은개발비용이다. 본기준에서는이러한요인들을크게소프트웨어개발규모, 어플리케이션유형, 개발언어, 품질및특성으로구분하였으며각각에대한보정계수를적용하여개발원가를구하도록하고있다. 규모보정 - 29 -
계수는규모척도가코드라인수인경우에는 < 표 2-10> 을기준으로 결정되고, 규모척도가기능점수인경우에는다음식을이용하여 보정계수를구한다. 단기능점수가 300 미만인경우 0.65 를취한다. 규모보정계수 = 0.108 log e (FP)+0.2229 < 표 2-10> 규모 ( 코드라인수 ) 보정계수 규모 ( 코드라인수 ) 보정계수 10,000 0.65 30,000 0.85 70,000 0.97 150,000 1.05 300,000 1.11 500,000 1.17 700,000 1.21 1,000,000 1.24 4) < 표 2-11> 의어플리케이션유형보정계수는동일소프트웨어사업 에어플리케이션유형이 2 개이상일경우구분하여적용한다. < 표 2-11> 어플리케이션유형보정계수 어플리케이션유형 업무처리용과학기술용멀티미디어용지능정보용시스템용통신제어용공정제어용지휘통제용 범위 인사, 회계, 급여, 영업등경영관리및업무처리용소프트웨어등과학계산, 시뮬레이션, 스프레드시트, 통계, OR, CAE 등그래픽, 영상, 음성등멀티미디어응용분야, 지리정보시스템, 교육? 오락용등자연어처리, 인공지능, 전문가시스템, 운영체제, 언어처리프로그램, DBMS, 인간? 기계인터페이스, 윈도시스템, CASE, 유틸리티등통신프로토콜, 에뮬레이션, 교환기소프트웨어, GPS 등생산관리, CAM, CIM, 기기제어, 로봇제어, 실시간, 내장형소프트웨어등군, 경찰등군장비? 인력의지휘통제를요하는소프트웨어 보정계수 1.0 1.2 1.3 1.7 1.7 1.9 2.0 2.2-30 -
5) < 표 2-12> 의언어보정계수는발주자가특정언어를요구하는경 우, 사용된언어의비율에따라소프트웨어개발단계중구현과 시험단계에만적용한다. < 표 2-12> 개발언어보정계수 언어구분 보정계수 Assembly, 기계어, 자연어 COBOL, FORTRAN, PL/1, PASCAL, Ada C, CHILL, C++, JAVA, C#, PROLOG, RPG, UNIX Shell Scripts ABAP4, Delphi, HTML, Power Builder, Program Generator, Query default, Small Talk, SQL, Visual Basic, Statistical default, XML default, Script default(jsp, ASP, PHP 등 ) EXCEL, Spreadsheet default, Screen painter default 1.9 1.2 1.0 0.8 0.6 6) < 표 2-13> 의각어플리케이션시스템의품질및특성보정계수는 다음과같이계산된다. 품질및특성보정계수 = 0.025 * 총영향도 + 1.0 총영향도 = 분산처리영향도 + 성능영향도 + 신뢰성영향도 + 다중사이트영향도 7) 절차 3 에서구한개발원가에는소프트웨어개발사업에서일반적으 로소요되는직접경비항목은포함되지않는다. 따라서, 이러한직 접비항목을별도로고려할수있도록하고있다. 8) 이윤은개발원가의 10% 범위내에서반영할수있도록한다. - 31 -
분산처리 성능 < 표 2-13> 품질및특성보정계수 보정요소판단기준영향도 분산처리에대한요구사항이명시되지않음어플리케이션 0 이구성요소클라이언트 / 서버및웹기반어플리케이션과같이분산처리와자료전송간에데이터이온라인으로수행됨 1 를전송하는정도어플리케이션상의처리기능이복수개의서버또는프로세서상에서동적으로상호수행됨 2 응답시간또는처리율에대한사용자요구수준 성능에대한특별한요구사항이나활동이명시되지않으며, 기본적인성능이제공됨 응답시간또는처리율이피크타임또는모든업무시간에중요함. 연동시스템의처리마감시간에대한제한이있음. 성능요구사항을만족하기위해설계단계에서부터성능분석이요구되거나, 설계 개발 구현단계에서성능분석도구가사용됨 0 1 2 신뢰성 장애시는영향의정도 신뢰성에대한요구사항이명시되지않으며, 기본적인신뢰성이제공됨 0 미치고장시쉽게복구가능한수준의약간불편한손실이발생함. 1 고장시복구가어려우며, 재정적손실이많이발생하거나, 인명피해위험이있음 2 다중사이트 상이한하드웨어와소프트웨어환경을지원 하도록개발되는정도 설계단계에서하나의설치사이트에대한요구사항만고려됨. 어플리케이션이동일한하드웨어또는소프트웨어환경하에서만운영되도록설계됨 설계단계에서하나이상의설치사이트에대한요구사항이고려됨. 어플리케이션이유사한하드웨어또는소프트웨어환경하에서만운영되도록설계됨 설계단계에서하나이상의설치사이트에대한요구사항이고려됨. 어플리케이션이상이한하드웨어및소프트웨어환경하에서동작하도록설계됨 0 1 2 2. 소프트웨어개발비대가기준의문제점 Conte, Dunsmore, Shen, Pfleeger는비용산정모델의정확성에관한연구를목적으로기존문헌을조사했다. Conte 그룹은비용산정결과의 PRED(0.25) 가 0.75를넘을때모델이수용가능하다고생각했는데, 고가의상용모델이라하더라도실제이런모델은존재하지않는다. Bredero는모델정확성에관한 24개이상의사례연구를인용하여비용산정모델의정확성을분석하는기법을다음과같이정리하였다 [4]. - 32 -
1 다수의프로젝트로부터얻은과거프로젝트데이터에모델을적용 하여예측한결과와실제값을비교한다. 2 특정프로젝트나제품에관한노력 ( 혹은기간 ) 을산정하기위해여 러모델들을선택한다. 첫번째경우에, 모든입력값이알려졌음에도불구하고실제값은대개 예측값과매우다르다. 두번째경우에, 상이한모델들은동일한입력에대 해서도매우다른결과를낸다. 소프트웨어개발비대가기준이가지는문제점을살펴보면다음과같다. 가. 이론과실제의차이 대부분의연구자와실무자들은소프트웨어의규모가비용산정을위한가장중요한요소라는것에동의하고있다. 그러나실제로비용과규모간의관계가분명하지않다. 대부분의알고리즘비용산정모델은비용산정에관한실험을통해비용과규모간의관계가지수 b와항 a를가지는규모에관한함수로모델링될수있다는결론을내렸다. 그러나값 a와 b는데이터집합에따라달라진다. 즉, 대부분의모델들은비용이규모에거의비례하지만, 규모의비경제 (b가 1보다큰 ) 를포함하므로규모가큰것이규모가작은것에비해생산적이지못하다. 실제로, 지수 b가 1과어느정도다르다는것을암시하는증거는없다. Banker와 Kemerer는 7개의데이터집합을분석하여유의수준 p=0.05에서유일하게하나의데이터집합이 1과큰차이를나타내는지수값을가진다는것을발견했다. 위와같이실제의프로젝트데이터를통해유도된모델이라고하더라도, - 33 -
모델이적용되는환경에따라비용과규모와의관계는상이한결과를가진다. 국내의소프트웨어개발비대가기준에서는일단선형관계를가정하고있으나, 이는실제의데이터를통해유도되지도않았고, 검증된바도없다. 심지어대가기준에서는일반적인알고리즘모델에서가정하는규모의비경제를반영하기위해규모보정계수를채택하였다. 뿐만아니라기존의연구에서실제데이터의경우에도이런현상을발견할수없었음에도이를반영하기위한기능점수기반의규모보정계수산출식을유도하였고, 실제데이터를통해검증되지못한코드라인수기반의규모보정계수를그대로유지하였다. 비용산정모델의개발자들은프로젝트의최적개발기간이대략노력의세제곱근임을예상하지만, 개발기간을줄이거나늘이는것이실제로비용에어떤효과를내는지에대한일치된견해가존재하지않는다. Putnam의모델은기간을단축시키는것이비용을증가시키므로, 비용을증가시키는것이노력을감소시킨다는것을함축한다. 동시에 Boehm의 COCOMO 모델의납기보정계수 SCED cost driver는개발기간을연장시키거나단축시키는것이프로젝트비용을증가시킨다는것을가정했다. 반면에 Jeffery에의한실험결과는상기모델의가정과는다른결과를나타낸다. 그는다수의프로젝트에관해일정의단축과비용의단축의정도를계산한후둘을비교하는산점도를그렸다. 그결과그래프는일정이단축된프로젝트는비용이또한감소된다는것을나타내므로 Putnam과 Boehm의모델과는모두모순되었다. Jeffery의실험과유사한결과가 MERMAID 프로젝트에관해서도관찰되었다. 따라서비록모델이유도된환경에서잘들어맞아도, 보편적으로타당할수없는것같다. 더욱이개발비대가기준은특정데이터집합의사후분석을통해개발되 므로정확도가떨어진다. 이기준이포함하는데이터의어떤특성들은종 - 34 -
종프로젝트시작단계에서는정확하게추정하기어려운입력매개변수를포함한다. 또는프로젝트완료후와초기의산정값은많은변동이발생하므로, 대가기준을적용하는초기단계에서이와같은불완전성을고려할필요가있다. 따라서더신뢰성있는기준을구축하기위한첫번째단계는생명주기초기에알수있는매개변수들을포함하여야하는것이다. 나. 모델의구조 프로젝트와조직의어떤특성들이생산성에영향을미칠수있다는것은분명하다. 예를들어, 이런이유때문에 COCOMO의 cost driver와 SLIM 의 technology factor와같은조정인자를포함하는많은비용산정모델들이이특성들의차이를반영하기위해보정계수를통해융통성을제공한다. 마찬가지로소프트웨어개발비대가기준에서도다양한보정계수를제공하고있다. 그러나이러한일반적인접근법은문제점을가진다. COCOMO cost driver 의적용이산정의정확도를항상향상시키는 것은아니다. 개발비대가기준의각종보정계수도정확도를오히려떨 어뜨릴수도있다. SLIM을이용한비용산정의경우, technology factor의정확한산정이어렵고 technology factor에극히민감하다. 개발비대가기준의경우, 어플리케이션유형보정계수의산정기준이애매하여, 수발주자들이서로유리하게적용하려할수도있다. 예를들어, 신용카드관련어플리케이션의경우, 성격상업무처리용어플리케이션이나인증관련빈번한트랜잭션을이유로통신제어용으로해석하려고할소지도있다. Cost driver 들이실제로독립적이지않지만, COCOMO 등의모델에 서는마치이것들이독립적인것처럼취급한다. 이상황은 cost driver - 35 -
들이부적절하게곱해져, 모델이유도된데이터집합이아닌다른데이터집합에비용산정식들이적용될때일관되지못하고부정확한결과를내는경향이있다. 개발비대가기준에서는어플리케이션유형보정계수와품질및특성보정계수의경우동일한성격의보정계수로볼수도있다. 특정유형의어플리케이션의경우에는중복해서보정될수도있다. Cost driver의값들은, 예를들어인력의경험혹은복잡도와같이대개전체프로젝트에대한일부요인의영향을주관적으로평가하는데기반을둔다. 상이한사람이비용요인을일관성있게평가하고모델을사용하는사람이모델제작자가의도한방향으로보정계수를결정한다는것을보장하기란어렵다. 개발비대가기준도마찬가지이다. 현재모델들은상이한여러유형의프로젝트에대한일부분의조정인자들을포함한다. 단일개발그룹에의해수행된프로젝트는대개유사하므로단지소수의인자들만을고려할필요가있을수있지만, 개발비대가기준이적용되는다양한환경을고려할때, 어플리케이션의다양한특성을반영할수있는 IFPUG의일반시스템특성 (GSC) 과같은객관적인조정인자를고려할필요가있다. 다. 소프트웨어규모산정 소프트웨어개발비대가기준뿐만아니라대부분의알고리즘비용산정모델들은정확한소프트웨어규모의산정을요구한다. 그러나이변수는예를들어, 입찰가격추정, 초기예산설정, 프로젝트계획수립과같은생명주기초기에측정이쉽지않다. COCOMO와 SLIM 같은모델들은기본적으로 LOC로소프트웨어규모를가정하지만, LOC는요구문서나입찰문서로부터측정할수없다. 더욱이 LOC의추정은매우부정확하다. 예를들면 Conte 등의연구에의하면경험있는프로젝트관리자의경우 LOC - 36 -
추정의정확도는 PRED(0.25)=0.25 에불과하였다. 소프트웨어개발비대가기준에서는규모척도로 LOC인코드라인과기능점수를제공하고있으며, 기능점수의적용을의무화하고있지는않고완곡하게권장사항으로표현하고있다. LOC 추정의부정확성을고려할때, 분야에관계없이기능점수의적용을의무화할필요가있다. 마지막으로, 알고리즘비용산정식의상수와지수및소프트웨어개발비대가기준의규모보정계수를구하는식은해당개발조직에서소프트웨어규모와노력을계산하는규칙에의해영향을받는다. 모델의계산규칙이실제이용되는규칙과동일하지않으면, 모델은정확한결과를내지않을것이다. 라. 보정계수의문제 공수산정에필요한생산성수준이많은개발환경의변화와기술력의향 상으로상당수준향상되었음에도불구하고산정된개발비의보정에필요한 여러보정치도근거와체계성이부족하다. - 대가기준이사용하고있는보정치는언어보정, 어플리케이션유형 보정, 규모보정, 품질및특성보정등 4 종류가있으나이것만으로 는다양한비용요인들의보정을충분히했다고볼수가없다. - 규모보정이란소프트웨어의양을질 ( 문제의복잡도, 처리의복잡도, 데이터의복잡도등 ) 적인측면을감안해야하고, 다양한비용요인들의보정이란제품의특성, 프로젝트의속성, 어플리케이션의용이성등이다양하게고려되어야한다. - 선진모델인 IFPUG 의기능점수, COCOMO II 나 SLIM, KP 등은이 - 37 -
러한보정치를다양하고다차원적으로조합하여활용하고있는것을 볼수있다. - 프로젝트규모가클수록증가하는투입인력으로커뮤니케이션채널이 늘어나생산성이떨어진다는견해를반영하는규모보정계수가도입 되었다. - 그러나이론과는다르게조사된자료로부터규모보정치를구할의미있는데이터를찾을수가없었다. 그럼에도불구하고기존연구 [5] 에서개정전과거대가기준의규모보정치의변화와비슷한형태를취하도록하였고, 그결과가실증적인검증없이현행대가기준에반영되었다. - 실제로보정치란사업자의능력에해당되고기술력에해당되며소프트웨어의본질적인속성에해당되기때문에우리의현실에맞는보정치를찾아적용하는것이바람직하나, 객관적이고일관된수치를얻을수있는보정계수를적용하여야한다. - 그렇다고해서국내의소프트웨어비용자료를통해애초에실증적으로유도되지도못했고그후단한번도보정계수의신뢰성이입증되지도않았음에도, 단지기존대가기준과의일관성을위해현행보정계수체제를유지한다는것은매우비과학적인일이다. 이제는선진모델에서채택되고있고, 실제로정확성이입증되었으며개발비대가기준에적합한보정계수를채택하는것을전향적으로검토할때가되었다. 마. 일반시스템특성의미반영 현행대가기준은선진견적모델에비해여러가지측면에서상당히낙 - 38 -
후되어있다. - 정보기술의패러다임이바뀌고소프트웨어개발기술과방법도급격한 변화를겪었음에도우리나라소프트웨어사업대가기준은 1989 년에 만들어진당시의보정계수구조에서벗어나지못하고있다. - 기존대가기준개정시 IFPUG 의일반시스템특성은다음과같은이 유에서생략하였다 [5]. 개정기준에서는규모산정결과를보정해주기위해서네가지의보정치를정의하고있다. 네가지의보정치란규모보정, 어플리케이션유형보정, 개발언어보정, 품질및특성보정등인데이들은 14 개일반시스템특성과상당부분중복되기때문에이중으로고려한다고판단하였다. 기능점수에대한국제표준화그룹 (ISO/IEC JTC1/SC7 WG12) 에서도 14개 GSC로부터도출되어계산되는 VAF(Value Adjustment Factor) 에대해서는그배경이과거메인프레임환경하에서만들어져서현재와같은기술환경에서는상당부분적용의의미가떨어지거나이미일반화되어누구나비슷한환경이되어버렸다는이유로제외하는쪽으로검토를한소수의의견을참고하였다. 기존연구 [5] 에서수집된부정확하고편중된 73개의데이터에대한 VAF 값을조사해본결과최소 0.86에서최대 1.22에평균이 1.02 로거의 1.0에가까워조정전기능점수 (UFP) 와조정후기능점수 (AFP) 의차이가 1.5% 에그쳤기때문에적용효과가크지않았다고판단을하였다. - 39 -
제 4 절소프트웨어개발비대가기준의개선방안 1. 대가기준의예측정확성향상 개발비대가기준의예측정확성을향상시키기위해서는다음단계를거 쳐야한다. 가. 일관성있는데이터의수집 특정환경에서비용산정의정확성을향상시키는가장중요한첫번째방법은전체환경에일관성있게정의되는규모척도와노력척도를이용하는것이다. 척도를이용한측정은모든사람이이해할수있어야하고, 동일한제품을측정하는두사람이동일한수치나등급을산출해야한다. 측정도구는이측면에서도움을줄수있다. 기존의도구들은자신의조직의특성에맞게조정되거나조직에특화된모델이개발될수있다. 나. 대가기준의개선 소프트웨어개발비대가기준의정확도는개선과조정을통해크게향상 된다. 조정과정은크게두단계로정의된다. 1 대가기준에적용되는데이터가모델의요구및기대와일치하도록 보장한다. 2 새로운환경에서구해진기본생산성을반영하기위해과거프로젝 트에관한데이터를사용하거나근거없이설정된보정계수들을재조 정한다. 현행기준으로부터특정보정계수들을배제하거나기존의보 - 40 -
정계수들을사용목적에알맞게조정하거나, 또한대가기준의필요와 관심사를반영하는새로운보정계수들을도입할필요가있다. 이과정에서두번째단계이후에만정확도가실제로개선될수있다. 조정은한번에끝나는작업이아니다. 대가기준은주기적으로재평가되고재조정되어최신의정보를유지할수있도록개선되고, 개선절차를제도화해야한다. 다. 대가기준을이용한독립적인산정 특정그룹의사람에게산정책임을부여하는것이유용하다. 산정그룹은모든프로젝트의산정을책임지고, 소프트웨어비용자료리포지토리에모든획득한데이터와분석결과를저장한다. 이접근법에몇가지장점이있다. 1 산정그룹의멤버는산정기법과조정기법에익숙하므로프로젝트 간에일관성이있을수있다는것이다. 2 산정그룹의경험은프로젝트가평균적인프로젝트나표준프로젝트 로부터일탈할때더욱유용하다. 3 비용자료리포지토리를관찰함으로써단일프로젝트에서는불가능한 추세의인식과성과분석을할수있다. 4 산정그룹을프로젝트개발인력으로부터분리함으로써프로젝트멤 버들로부터유도된데이터를근거로산정그룹은주기적으로재산정할 수있다. 라. 주관적인입력의최소화 - 41 -
보정계수의선택의주관성과소프트웨어규모의초기산정이산정의부정확성의원인이될수있다. 소프트웨어제품의규모를정확하게반영할수있도록정확한기능점수계산과이를가능하게하는요구사항의도출이필요하다. 경우에따라균일한특성을가지는데이터집합에기반을둔로컬모델이일반적인복잡한모델보다더욱정확할수있다. 이러한로컬모델은보정요인들의수가적으므로주관성을감소시킬수있다. 특정조직에적합한로컬모델의산정결과와대가기준의산정결과를비교할필요가있다. 마. 예비산정과재산정 초기의산정은불완전한정보의이용을필요로한다. 따라서활용가능한척도를기반으로한예비산정후에더많은정보가활용가능하게되고요구분석및설계결과와같은더많은산출물들이생산됨에따라재산정한다. 개발비대가기준은예가산정단계에서적용되는경우, 가용정보의부족으로산정정확성에많은한계를가지고있다. 그러나제안서를기초로도비교적정확한기능점수계산이가능하고이를이용한개발비산정이가능하며, 요구분석후에는정확한기능점수의계산이가능하므로산정의정확도가향상된다. 이와같은예비산정과재산정을통해실제비용에근접한값을추정할수있어, 프로젝트관리에유용한수단이될수있다. 또한이과정에서얻어진정보는비용자료리포지토리에구축되고, 대가기준의개선에활용될것이다. - 42 -
예비산정은부분적으로전문가의판단과유추에기반을둘가능성이있 으므로, 그결과를개선하기위한다음과같은방법을적용한다. 1) 그룹산정 개인에의존하는산정보다는그룹이예비산정을한다. 그룹산정을이용하면, 각개인은다양한분야의프로젝트에경험을쌓을수있고산정결과는특정개인에게편향되지않을수있다. 그룹산정은 Delphi 기법을이용하여조직적인방식으로유도하는것이바람직하다. 2) 유추에의한산정 완료된유사한프로젝트의실제노력과기간은새로운프로젝트의예비산정에대한입력으로유용하다. 예비산정결과값들은새로운프로젝트와이전의프로젝트사이의차이가를반영하여조정되어야한다. 만일새로운프로젝트가이전의프로젝트보다 10% 크다고믿어지면, 비용산정값은 10% 증가될수있다. 예를들어, 각종비용요인에대해새로운프로젝트는과거의프로젝트데이터와비교하고, 필요하면조정한다. 3) 재산정 많은정보가활용가능할수록대가기준의입력값을다시평가하고출력을대상으로재산정하는것이필요하다. 산정과정은실제로생명주기의상이한단계에서다른정보를활용할수있으므로, 각산정은적절한식, 규모척도, 보정계수에관한가용정보를취한다. 만일수행중인프로젝트가이전에개발된프로젝트와유사하지않더라 도, 전문가의의견이나유추에의한산정은여전히필요하다. 예를들어, - 43 -
만일특이한어플리케이션이개발중이거나만일새로운개발기법이채택 되면, 완료된다른프로젝트와의유사점이나차이점을평가하는데전문가 의견이포함될수있다. 2. 소프트웨어개발비대가기준의개선절차 기존에개발된개발비대가기준은당시의환경을반영하는데반해서, 개선되는대가기준은현재의전형적인어플리케이션과개발환경의특성을반영하기때문에더욱정확해야한다. 소프트웨어개발비대가기준을개선하는일반적인절차는다음과같다. 가. 비용요인의인식 소프트웨어개발과정에포함되는단계와작업을인식함으로써시작한다. 즉, 어떤작업의노력과기간이전체프로젝트산정을구성하는지를판단한다. 어떤조직에서비용산정은요구사항의유도와명세화를포함하는반면에, 다른조직에서는프로젝트의명세가완성되고인증된후에만비용산정을고려한다. 마찬가지로어떤비용산정은유지보수작업을포함하는반면에다른것은그렇지않다. 일단필요한작업이인식되면, 개발비대가기준을위한비용모델을제안하고기본적인데이터를구성한다. 나. 비용이론의설정 소프트웨어개발비대가기준은출력에영향을주는입력이론에기초해야한다. 가장공통적인비용이론은소프트웨어규모가주요한비용요인이고, 이이론에기반을둔대가기준은프로젝트의각단계에적합한입력으로적절한규모척도를그다음에인식해야한다. 일반적으로비용이론은입력과출력간의관계를기술해야하고, 전체적인모델은개개의모델 - 44 -
이어떻게관련되는가를기술해야한다. 예를들어, 요구분석단계동안이루어지는비용산정은설계단계의산정프로세스의입력이되어야하고, 비용이론은요구사항중심의산정이설계중심의산정과어떻게관련되는가를설명해야한다. 다. 데이터수집 비용이론의타당성을체크하기위해, 개발비대가기준을유도한특정환경에서이미완료된프로젝트데이터를수집해야한다. 공식적인데이터수집시스템이없고그런데이터가부정확하거나편향될수있는완료프로젝트에관한정보를구축할때에는주의해야한다. 공식적인데이터수집이더욱신뢰성이있으므로, 비용자료수집모형을정의하는것이필요하고, 지속적인개선작업을위해비용자료리포지토리의구축이필수적이다. 비용이론을시험하기위해필요한프로젝트의수는비용산정식에포함된입력변수의수에좌우된다. 이론적으로, 세개의프로젝트는하나의입력변수에기반을둔비용이론을시험하기에충분하다. 일반적으로 n+2개의프로젝트가 n개의입력변수를포함하는이론을시험하는데필요하다. 그러나각입력변수에대해실제로 7개에서 10개의프로젝트가이용되어야한다. 그이유는데이터의가변성이너무커서데이터들에내재된관계를감지하기어려울것이기때문이다. 비용모델의수집과그들을지원하는이론들은더욱정확한예측을하는것을목표로한다. 프로젝트의실제데이터를얻을수있으면바로산정의정확성을시험해야한다. 또한비용산정식과모델을단순하고빠르게적용할수있어야한다. 따라서단순한모델과식으로시작하고그것들을실제프로젝트에시험하는것이바람직하다. 이산정식과모델들은정확도를평가하여개선될수있다. - 45 -
라. 데이터분석과모델평가 통계적기법은이전의프로젝트데이터를분석하고결과의유의성을시험하는데이용된다. 통계적으로분석된모델은나름대로의장점을가진다. 그이유는이모델은특정신뢰수준으로모델의산정정확성을표현할수있는척도를제공하기때문이다. 마. 모델검증 통계적유의성만가지고는좋은예측치를제공하기에충분하지않다. MMRE, PRED(0.25) 와같은평가척도들은모델을수용할수있을정도의정확도를가지는가의여부를판단하는데이용된다. 만일모델의정확도가만족스럽지못하다면모델을주의깊게검토한후비용모델과이론을조정하기위해이다섯단계를다시적용해야한다. 단지모델을체크하는것뿐만아니라변경되는프로세스, 자원, 기술들을반영하기위해서도계속적인피드백이필요하다. - 46 -
제 3 장비용자료수집모형 제 1 절소프트웨어비용자료수집양식 소프트웨어사업비용자료는프로젝트규모와생산성및원가등을파악하는것이외에현행대가기준의보정계수의타당성을검토하고, 신규보정계수의도입을검토하는것이목적이기때문에다음과같이구분하여조사를하였다. (1) 기본사항 조사대상프로젝트의개요를파악하고, 조사데이터에대한문의와보완 에필요한조사자의연락처등의일반사항을파악하고자하였다. (2) 규모산정 국제기능점수사용자그룹의기능점수측정기준에입각하여조사대상 프로젝트의규모를기능점수로파악하고자하였다. (3) 실투입공수및규모산정된규모의소프트웨어를개발하는데소요된실투입공수를어플리케이션별및공정별로파악하고, 실제의소프트웨어규모를코드라인수 (LOC) 로파악하고자하였다. (4) 계약및실적원가 - 47 -
정의된범위내산정된규모의소프트웨어를개발하는데소요된개발자 내부의실적원가와함께발주자와의계약가를파악하고자하였다. (5) 기존보정계수 현행개발비대가기준의각종보정계수의타당성을분석하고, 신규보정 계수의도입필요성을검토하고자하였다. (6) 일반시스템특성조사 현행기준의보정계수를보완하기위해도입필요성이제기되는 IFPUG 의일반시스템특성의타당성을분석하고자하였다. 1. 기본사항조사양식 기본사항조사양식은 < 그림 3-1> 과같이조사자에관한사항과프로젝트에관한사항으로구분되고, 조사자에관한사항은소속, 직위, 성명, 연락처, 기관성격등으로구성되고, 프로젝트에관한사항은프로젝트명, 프로젝트기간, 사업영역구분및계약방식등으로구성된다. 기본사항조사는조사대상프로젝트의프로파일을작성하는부분으로조사항목을최소화하도록했다. - 48 -
I. 다음은본데이터조사를위한기본사항입니다. 본엑셀파일은귀사에서조사되는프로젝트의숫자만큼만들어주셔야합니다. 그래서파일명을 " 귀사명 -n.xls"(n 은순번 ) 로붙여주시기바랍니다. 가. 귀하 ( 조사자 ) 의소속과인적사항등에관한질문입니다. 1) 기관 ( 회사 ) 명 2) 부서명 3) 직위 4) 성명 5) 전화번호 6) e-mail 7) 수발주자구분 ( 해당사항에 "x" 표시 ) 1 발주자 2 수주자 나. 조사프로젝트에관한질문입니다. 1) 프로젝트명 2) 프로젝트기간계약기간 부터 까지 0.0 개월 실적기간 부터 까지 0.0 개월 적정납기를구하기위한자료로사용될예정입니다. 정확하게기입하여주시기바랍니다. 3) 사업영역 (' 해당사항 ' 난에 "x" 표시를하나만해주시기바랍니다 ) 1 공공 4 유통 / 서비스 7 유틸리티 2 금융 5 국방 8 교통 3 제조 6 정보통신 9 기타 4) 계약방식 1 경쟁입찰 2 제한경쟁입찰 3 수의계약 4 기타 ( 기재요망 ) < 그림 3-1> 기본사항조사양식 - 49 -
2. 규모산정조사양식 규모산정조사양식은 < 그림 3-2> 와같이기능점수산정의기초인단위업무프로세스를식별하는부분과식별된단위업무프로세스별로복잡도를파악하여가중치 ( 기능점수 ) 를구하는부분으로구성된다. 단위업무프로세스는범위정의에서식별한어플리케이션별로사용자의요구사항을기초로독립적이고의미있는업무단위를식별하는것이고, 복잡도는기능점수유형별로파일수나레코드유형수, 그리고데이터항목수를조사하여상, 중, 하로구분하는것이다. 그외에각단위프로세스별로개발언어를무엇을사용했는지와계약시식별여부등을기록하는양식이다. 2. 기능점수산정방식에따라규모산정을해주시기바랍니다. 아래표의양식에의거하여어플리케이션별로다음의가이드에따라단위업무프로세스를정의하고각프로세스별로소프트웨어기능과기능점수유형 (FP 유형 ) 및복잡도파악을위한필드별해당숫자를채우시기바랍니다. [ 표 2] 어플리케이션규모산정양식 1 어플리케이션명 2 세부업무명 3 단위프로세스명 해당기능의개발언어를표시. 4 개발언어 자동계산자동계산 5FP유형 6 RET/FTR 8복잡 9가중치 7DET 도 (UFP) - 50 -
작성가이드 1 "2. 범위정의 " 에서정의한어플리케이션과동일하다. 특히추가요구활동으로 " 자료변환 " 을식별한경우에는자료변환프로그램의기능을측정한다. 2 세부업무명은어플리케이션을구성하는서브시스템등을의미한다. 3 단위업무명은세부업무를구성하는단위업무로, 소프트웨어기능을가진독립적인업무프로세스이다. 1) 사용자가식별할수있고사용자관점에서정의된단위소프트웨어기능으로, 기능점수측정에사용되는것이다. ( 물리적인형태에따라변할수있음 ) 2) 기술적인이유로사용되는사용자가모르는기능은여기에포함시키지않는다. 3) 어플리케이션을완전하게하는모든기능을중복되지않게, 사용자가소프트웨어기능으로구현하기를원하는것만을식별한다. 4) 업무기능은아니나사용자가필요로하여어플리케이션으로구현되는기능 ( 예, 헬프메시지 ) 도포함한다. 5) 반대로업무기능이지만어플리케이션으로구현이불가능한수작업영역은포함시키지않는다. 6) 외부입력, 외부출력, 외부조회, 내부논리파일, 외부참조파일은물론외부입력도입력, 수정, 삭제를따로식별한다. 4 개발언어는 3에서식별한기능이실제어떠한프로그램언어로구현되었는지를식별한다. 5 FP 유형은 3에서식별한기능이 EI, EO, EQ, ILF, EIF 중어디에해당되는지를식별한다. 6 RET/FTR은 5에서식별한 FP유형별로 EI/EO/EQ면참조하는 FTR의수를, ILF/EIF면 RET의수를식별한다. 7 DET 는 5에서식별한 FP 유형별로참조 / 구성하는데이타항목의유형수를식별한다. 8 복잡도는자동으로계산된다. 9 가중치도자동으로계산된다. 10 계약 / 실적은 3에서식별한기능이계약 / 실적시식별되었으면 'x' 를아니면공백으로둔다. [ 표 3] 어플리케이션규모산정양식 ( 자동계산됩니다 ) 어플리케이션명 구분 EI EO EQ ILF EIF 합계 기능수 - - - - - - UFP - - - - - - AFP - * EI (Exteranl Input : 외부입력 ) EO (External Output : 외부출력 EQ (External Inquiries : 외부조회 ) ILF( Internal Logical Files : 내부논리파일 ) EIF(Externa Interface Files : 외부인터페이스파일 ) < 그림 3-2> 규모산정조사양식 3. 실투입공수및규모조사양식 실투입공수조사는 ISO 12207에서정의한 13개엔지니어링기본공정을기초로공정별로소요된실제공수와규모를조사하는 < 그림 3-3> 과같은양식이다. 또한어플리케이션의실제규모를코드라인수 (LOC) 로조사하는양식도포함된다. 단기적으로는이자료는대가기준의코드라인당단가의적절성을판단하여, 정확한단가를산출하는자료로활용될것이다. 장기적으로비용자료리포지토리에구축된자료들은기능점수당코드라인수의 SPR의 backfiring 규칙을검증하고, 정확한기준을제시하는데활용될 - 51 -
것이다. 3. 귀하가수행한본프로젝트에소요된실제공수의단계별비율을자체와외주공수를합하여표시하시기바랍니다. 계약한공수가아니라귀사에서본프로젝트에실제로투입된공수의단계별비율을자체와외주를합하여표시하는것입니다. 다만공정구분이여기처럼되어있지않을것이므로표의메모를참조하시어표의각해당공정에맞게배분하여환산해주시기바랍니다. 환산이어려우면각어플리케이션별공수의합이 100% 가되게배분하셔도됩니다. 물론해당이없는공정은표시를하지않으셔도됩니다. [ 표 3] 공수산정양식 - 실제투입된공수비중 1 어플리케이션명 2 개발유형구분 3 용도 ( 내부업무 / 고객서비스 ) 5.3.2 5.3.1 시스템요공정구현구분석 분석 5.3.3 SW 요구분석 5.3.4 시스템구조설계 5.3.5 SW 구조설계 설계 5.3.6 SW 상세설계 4ISO/IEC 12207 5.3.7 SW 코딩및시험 구현 5.3.8 SW 통합 현대가기준의 4 단계공정 5.3.9 SW 자격시험 5.3.10 시스템통합 5.3.11 시스템자격시험 시험 5.3.13 5.3.12 SW 수락지 SW 설치원 합계 합계 (MM) 작성가이드 1본프로젝트에서개발한어플리케이션명을기재함 ( 단일어플리케이션을개발하는프로젝트경우는하나만기술 ) 2개발유형은다음에해당하는경우에만, 1에서구분한어플리케이션별로식별함 N 신규개발 3어플리케이션의사용목적이내부업무효율을위한경우는 " 내부 ", 대고객서비스를위한것이면 " 고객 " 으로구분함 4어플리케이션별로프로젝트유형별특성을감안하여수행하는공정을 ISO/IEC 12207의표준공정중에서식별함. ( 각셀의메모참조 ) 식별이곤란하면현행대가기준의 4단계공정을참조하도록함 X 해당공정이필요한경우 N/A 해당공정이불필요한경우 3-1. 귀하가수행한본프로젝트의실제규모를코드라인수 (LOC) 로작성해주시기바랍니다. 과거대가기준의본수및스텝수방식에의한규모의추정치가아니라 LOC( 코드라인수 ) 로카운트한실제의프로젝트규모를기입하는것입니다. [ 표 4] 프로젝트실제규모작성양식 ( 단위 : LOC) 1 어플리케이션명 2 코드라인수 합계 작성가이드 1 본프로젝트에서개발한어플리케이션명을기재함 ( 단일어플리케이션을개발하는프로젝트경우는하나만기술 ) 2 코드라인수 (LOC) 기준의실제규모는과거대가기준의본수및스텝수방식의추정치가아닌, LOC( 코드라인수 ) 로카운트한실제규모 < 그림 3-3> 실제공수와규모를조사하는양식 4. 계약및실적원가조사양식 - 52 -
투입된공수에따라계약과실적으로구분하여원가를조사하되, 직접비 와간접비로구분하고, 각각을인건비, 재료비, 경비등으로구분하여조사 하는 < 그림 3-4> 와같은양식이다. 4. 귀하가수행한본프로젝트의수주와실적원가를다음의양식에맞추어작성가이드에따라작성해주시기바랍니다. [ 표 5] 계약및실적원가조사양식 ( 단위 : 원 ) 개발용역비 구분 합계 1S/W 개발비 S/W 개발직접인건비 (A) S/W 개발외주비 (B) 2 기타개발용역비 (ISP/BPR, DB 구축비등 ) 3 재료비 (H/W, S/W 구매 ) 직접경비간접비 계약가 실적가 작성가이드 - 계약가는계약시점의산출내역서상의금액을중심으로기입하고, 실적가는프로젝트종료후실질적으로발생한비용을중심으로기입해주시기바랍니다. - 계약합계금액과프로젝트총액 ( 개발용역비 + 재료비 + 직접경비 + 간접비 ) 은금액에차이가있을수있읍니다.( 이윤, 가격정책등 ) - 실적합계금액은프로젝트총액 ( 개발용역비 + 재료비 + 직접경비 + 간접비 ) 과동일해야합니다. 1S/W개발비는프로젝트에직접투입되는인력에대한인건비를계상함 ( 외주인력에대한인건비포함 ) 2기타개발용역비 (ISP/BPR, DB구축비등 ) 는S/W개발외의용역수행시발생되는인건비 3재료비는취득원가로계상함. 4직접경비는당해프로젝트에직접부과할수있는비용 5간접비는 2이상의프로젝트에공통적으로발생하는비용 < 그림 3-4> 계약및실적원가조사양식 5. 기존보정계수의타당성조사양식 현행개발비대가기준의각종보정계수의타당성을분석하고, 신규보정계수의도입필요성을검토하려는것으로, 개발언어, 어플리케이션유형, 품질및특성보정계수를조사하는 < 그림 3-5> 와같은양식이다. 규모보정계수의경우에는앞에서조산규모값에의해산출이가능하므로별도의조사양식이필요없다. - 53 -
* 노란색으로표시된부분을입력해주시기바랍니다. 5. 현행대가기준과의비교를위한조사항목입니다. 프로젝트에서실제사용된언어를기입해주세요 (1) 언어보정계수 개 발 언 어 사용언어 보정계수 비 율 (%) Assembly, 기계어, 자연어 1.9 C, CHILL, JAVA, C#, PROLOG, UNIX Shell Scripts 1.2 COBOL, FORTRAN, PL/1, PASCAL, Ada ABAP4, Delphi, HTML, Power Builder, Program Generator, Query default, Small Talk, 사용언어별 1.0 비율합계는 100% 이어야함 SQL, Visual Basic, Statistical default, XML default, Script default(jsp, ASP, PHP 1.0 등 ) ASSEMBLY 언어 2.0 0 0% 유형별비율 (2) 어플리케이션유형보정계수 어플리케이션 유형 보정계수 비 율 (%) 업무처리용 1.0 과학기술용 1.5 멀티미디어용 2.0 지능정보용 2.0 시스템용 2.4 통신제어용 3.0 공정제어용 3.2 지휘통제용 4.0 0.0 0% (3) 품질및특성보정계수다음 4 가지항목 ( 분산처리, 성능, 신뢰성, 설치사이트수 ) 에대한각각의판단기준에따라적절한점수를선택하여주시기바랍니다. 1 분산처리 : 어플리케이션이구성요소간에데이터를전송하는정도판단기준분산처리에대한요구사항이명시되지않음클라이언트 / 서버및웹기반어플리케이션과같이분산처리와자료전송이온라인으로수행됨어플리케이션상의처리기능이복수개의서버또는프로세서상에서동적으로상호수행됨 프로젝트에해당하는항목을 X로선택해점수판단주세요. 0 1 2 2 성능 (Performance) : 응답시간과처리율 (throughput) 에대한사용자요구수준판단기준성능에대한특별한요구사항이나활동이명시되지않으며, 기본적인성능이제공됨응답시간또는처리율이피크타임또는모든업무시간에중요함. 연동시스템의처리마감시간에대한제한이있음 성능요구사항을만족하기위해설계단계에서부터성능분석이요구되거나, 설계. 개발. 구현단계에서성능분석도구가사용됨 3 신뢰성 (Reliabilty) : 장애시미치는영향의정도판단기준신뢰성에대한요구사항이명시되지않으며, 기본적인신뢰성이제공됨고장시쉽게복구가능한수준의약간불편한손실이발생함고장시복구가어려우며, 재정적손실이많이발생하거나, 인명피해위험이있음 점수 0 1 2 점수 0 1 2 판단 판단 4 다중사이트 (Multiple Sites) : 상이한하드웨어와소프트웨어환경을지원하도록개발되는정도 판단기준 설계단계에서하나의설치사이트에대한요구사항만고려됨. 어플리케이션이동일한하드웨어또는소프트웨어환경하에서만운영되도록설계됨 설계단계에서하나이상의설치사이트에대한요구사항이고려됨. 어플리케이션이유사한하드웨어또는소프트웨어환경하에서만운영되도록설계됨설계단계에서하나이상의설치사이트에대한요구사항이고려됨. 어플리케이션이상이한하드웨어및소프트웨어환경하에서동작하도록설계됨 < 그림 3-5> 기존보정계수조사양식 점수 0 1 2 판단 - 54 -
6. 일반시스템특성조사양식 신규보정계수의타당성을검토하기위해 IFPUG 의일반시스템특성의 영향도를항목별로조사하는양식으로 < 그림 3-6> 에는그일부만을나타냈 다. * 노란색으로표시된부분을입력해주시기바랍니다. 6. 일반시스템특성 ( 현행기준에는포함되어있지않거나일부만포함되어있지만, 개선을위해검토되는항목입니다.) 다음 14가지항목에대한각각의판단기준에따라적절한점수를선택하여주시기바랍니다. 1 데이터통신 : 데이터통신은어플리케이션이프로세서와직접통신하는정도를말합니다. 배치 (batch) 어플리케이션은 0~3점에해당합니다. 온라인어플리케이션은 4점에해당합니다. 웹기반어플리케이션은 4~5점에해당합니다. 실시간, 원격통신, 프로세스제어시스템은 4~5점에해당합니다. 판단기준 점수 판단 프로젝트에해당하는 순수한배치 (batch) 처리이거나스탠드얼론 (stand alone) 어플리케이션원격데이터입력또는원격출력기능을가지는배치어플리케이션원격데이터입력과원격출력기능을모두가지는배치어플리케이션온라인데이터수집을포함하는어플리케이션혹은배치처리나질의시스템에대한 TP( 원격처리 ) 프런트-엔드 (front-end) 를포함하는어플리케이션 0 1 2 3 항목을 X로선택해주세요. 하나이상의프런트엔드를가지지만, 한가지유형의 TP 통신프로토콜만을지원하는어플리케이션하나이상의프런트엔드를가지고, 두가지유형이상의 TP 통신프로토콜을지원하는어플리케이션 4 5 2 분산데이터처리 : 분산데이터처리는어플리케이션이내부의구성요소들간에데이터를전송하는정도를의미합니다. 레거시시스템의 경우대부분 0점입니다. 데이터가온라인으로전송되지않는기본적인분산어플리케이션은 1~2점입니다. 클라이언트-서버혹은웹기반어플리케이션은 3~4점입니다. 아주드문경우입니다만, 각각실시간가용성을기초로동적으로 선택되는복수개의서버나프로세서를가지는경우에만 5점을부여합니다. 판단기준 점수 판단 시스템구성요소간의데이터전송이나처리기능을지원하지않는어플리케이션 0 PC 스프레드시트와 PC DBMS 와같은시스템의다른구성요소상에서처리될데이터를준비하는어플리케이션 시스템의다른구성요소로의전송을위한데이터가준비되고, 전송되어처리됨 ( 최종사용자처리는아님 ) 분산처리와데이터의전송은온라인이며한방향으로수행됨분산처리와데이터의전송은온라인이며양방향으로수행됨처리기능은시스템의가장적절한구성요소상에서동적으로수행됨 3 성능 : 성능은응답시간과처리율 (throughput) 을고려하는것이어플리케이션에영향을주는정도를의미합니다. 배치어플리케이션은 0~4점입니다. 대화형클라이언트-서버나웹구동 (web-enabled) 어플리케이션을포함하는온라인어플리케이션은 0~4점입니다. 웹기반어플리케이션은 4~5점입니다. 대부분의 MIS 온라인시스템은 2점입니다. 실시간, 원격통신, 프로세서제어시스템은 0~5점입니다. 개발시성능분석도구의사용이필요하면 5점을부여합니다. 판단기준 점수 판단 사용자가특별한성능요구사항을명시하지않음 0 성능및설계요구사항이명시되고검토되었으나특별한조치가요구되지않음응답시간또는처리율이피크타임에중요함. CPU 사용에대한특별한설계가요구되지않음. 처리기한은다음날까지임응답시간또는처리율이모든업무시간에중요함. CPU 사용에대한특별한설계가요구되지않음. 연동시스템의처리마감시간에대한제한이있음. 위에추가하여, 설계단계에서의성능분석작업이필요할정도로사용자의성능요구사항이엄격함 1 2 3 4 위에추가하여, 사용자의성능요구사항을만족시키기위해성능분석도구가설계, 개발, 구현단계에서사용됨 4 컴퓨터자원제약 : 컴퓨터자원제약은어플리케이션개발에영향을주는컴퓨터자원의제약정도를의미합니다. 대부분의어플리케이션은 2점입니다. 클라이언트-서버, 실시간, 원격통신, 혹은프로세스제어제어시스템은 3~5점이지만, 동일한트랜잭션들을처리하고가장빠른처리수단을찾는전용프로세서나다중프로세서를필요로합니다. 판단기준 점수 판단 명시적이거나암시적인운영상의제한이없음운영상의제한이존재하나일반적인어플리케이션에비해덜제한적임. 이제한을만족하기위한특별한노력이필요하지는않음 0 1 보안또는타이밍고려사항이존재함어플리케이션의특정부분에대해특별한프로세스요구사항이존재함언급된운영상의제한이중앙프로세서나전용프로세서에서의특별한제약을필요로함 위에추가하여, 어플리케이션의분산컴포넌트에대한특별한제한이존재함 1 2 3 4 5 5 2 3 4 5 < 그림 3-6> 일반시스템특성조사양식 - 55 -
제 2 절소프트웨어비용자료리포지토리 1. 비용자료리포지토리의필요성 소프트웨어개발조직들은자신들의비즈니스와유사한조직, 그리고업계의동향에항상귀를기울이고있다. 이들은모범적인실무들을적용해보기도하고타업체와비교하기도하면서더나은방향을모색해나가고있다. 더욱이기능점수를기반으로한데이터는소프트웨어개발에종사하는사람들이항상관심을가지고있다. 소프트웨어개발조직들은이러한소프트웨어비용자료리포지토리를통해벤치마킹이나통계적분석등을이용할수있다. 업계의소프트웨어비용자료에대한요구가너무강하다보니, 많은기관들은공개적으로활용가능한업계데이터를액면가로기꺼이입수하려고한다. 많은업계데이터의제공자들은검증되지않고최신이아닌, 또는불완전한데이터를수집해왔다. 회사들이업계추세를정확히반영하지못하는이러한데이터에기초하여대가기준을개선하거나유도하는등의어떤의사결정을내리게되면바람직하지못한결과가발생될수있다. 이러한위험을방지하기위해리포지토리에구축된소프트웨어사업비용자료는다음과같은기준이적용되어분석및활용되어야한다. 1 데이터가대표하는업종이무엇이며, 데이터의구성비는어떻게되는가? 일반적으로업계데이터는광범위하고다양한분야에걸쳐수집된수많은데이터의결과이다. 하나또는두개정도의산업이대부분의데이터를대표하게되는경우처럼, 데이터가대표성을갖지못하는경우가자주있다. 만약그한두개의산업이우연히자신의업종과일치한다면다행이 - 56 -
지만그렇지않다면그것은아무의미가없을수있다. 2 데이터가나타내는시기는언제인가? 자신의데이터베이스에비록수천개의프로젝트에관한정보를가지고있다고하더라도그데이터를매우긴시간동안수집해왔다고주장하는것은그리현명하지못한것이다. 만약현재의데이터를원한다면, 현재데이터의표본크기는비교적작게될것이고수천개의프로젝트를대표하지못할수도있다. 3 데이터가얼마나유효한가? 대개데이터는많은자료원으로부터수집된다. 이사실은데이터가검증됐을가능성을제한하게된다. 또한많은데이터가경험적인데이터이므로어느정도의왜곡을포함하고있다. 소프트웨어사업비용자료는일반적으로주어진기간동안일련의프로 젝트로부터수집된데이터를대표한다. 서로다른기술이나환경들을대표 할수있도록하기위해서로다른데이터들이제공된다. 수집된자료의활용에관한한가지예를들면, 클라이언트서버프로젝트를나타내는그래프위에업계의기준데이터를놓음으로써분산프로젝트에관한소프트웨어사업비용자료를결합한다. 이렇게함으로써조직이업계에서자신이차지하는위치를곧바로알수있도록해준다. 물론, 조직은여기에기준과의편차를이해하기위해엄격한평가프로세스를수행할필요가있다. 그러한평가를마치고나면개선된소프트웨어프로세스를향해서이동할수있게된다. 또한조직은자신의개선정도를알기위해 - 57 -
이런유형의그래프표현을활용할수있다. 소프트웨어비용자료를중심으로하는업계데이터의표준화되고용이한자료수집프로세스는잘정의된자료집합을리포지토리에저장할수있도록한다. 이과정에서각비용자료들은검증되고안전하게관리되어야한다. 다양한자료원으로부터의자료수집, 검증, 통계적분석기능을수행하기위해자동화된도구인웹기반유틸리티가리포지토리에연동되어야한다. 또한 < 그림 3-7> 과같이소프트웨어사업비용자료에관심이있는개인이나조직이인터넷을통해온라인으로쉽게접근할수있어야할것이다. C o l l e c t i o n R e p o s i t o r y A c c e s s i b i l i t y < 그림 3-7> 소프트웨어비용자료의활용 2. 비용자료리포지토리개념모델 소프트웨어비용자료리포지토리개념모델은다음과같은원리에기반을 둔다. 1) 실무자중심으로구축및운영되어실무자가접근가능해야한다. 각소프트웨어개발조직이리포지토리구축에기여하고리포지토리가 - 58 -
제공하는서비스를이용한다. 2) 리포지토리의목적에동의하는경우, 기관이나조직은자신들의데 이터가제공되었다고하더라도이들기관이나조직으로부터독립적으 로운영되어야한다. 3) 엄격한절차를적용하여리포지토리데이터의무결성이유지되어야 한다. 4) 데이터제공기관이나조직의익명성이보장되어야한다. 소프트웨어비용자료리포지토리를통해제공할수있는서비스는다음 과같다. 1) 리포지토리그자체는내부적인척도데이터베이스의대안으로이 용될수있다. 2) 프로젝트벤치마킹프로파일리포트가리포지토리참여기관이나 조직에게제공된다. 이리포트를통해해당프로젝트와리포지토리내 부의동일부류의타프로젝트를비교할수있다. 3) 모범적인실무들의네트워크를구축하여리포지토리참여기관이나 조직이활용할수있다. 4) 조직수준의벤치마킹이유사한조직과비교하기위해활용가능하 다. 5) 소프트웨어비용자료리포지토리의리포트를제공한다. - 59 -
리포지토리에구축되는데이터는소프트웨어산출물, 소프트웨어프로젝트, 소프트웨어개발조직등으로구성된다. 소프트웨어산출물에는원시코드와설계산출물등이있다. 소프트웨어프로젝트는프로젝트데이터 ( 예 : 결함, 개발및유지보수공수등 ) 이고, 소프트웨어개발조직은개발환경데이터 ( 예 : 요구사항변경, 재사용기능등 ) 이다. 소프트웨어비용자료리포지토리의구성을간략하게나타내면 < 그림 3-8> 과같다. 리포지토리는인터넷을이용하여쉽게서비스의접근및이용이가능하여야하며벤치마킹, 통계적분석과추론, 리포트및그래프생성기능, 비용산정기능, 기능점수산정기능등이제공되어야한다 [6]. 벤치마킹 통계적분석및추론 소프트웨어개발조직소프트웨어프로젝트소프트웨어산출물 개발환경데이터프로젝트데이터코드, 설계산출물 웹기반유틸리티리포지토리 리포트 기능점수산정 비용산정 < 그림 3-8> 소프트웨어비용자료리포지토리구성 본연구에서제안하는비용자료리포지토리개념모델메인화면을 < 그림 3-9> 에나타내었다. - 60 -
< 그림 3-9> 소프트웨어비용자료리포지토리 기능점수산정메뉴에서는어플리케이션의프로세스정보인프로세스명과개발언어, 기능점수유형, 복잡도와가중치계산을위한 RET/FTR 등을입력하면 < 그림 3-10> 과같이해당프로세스의복잡도와가중치가계산되고이를통해미조정된기능점수 (UFP) 와최종적인기능점수 (AFP) 를산정할수있다. < 그림 3-10> 기능점수산정 - 61 -
< 그림 3-11> 의비용산정기능은기본적으로소프트웨어개발비대가기준에기초하여세개의파트로구성된다. 스텝 1에서는보정전개발원가를산출하기위해기능점수를입력하고개발공정을선택한다. 스텝 2에서는현행대가기준을기초로프로젝트에적용되어야할규모보정계수가계산되고, 어플리케이션유형보정계수, 언어보정계수, 품질및특성보정계수의값을선택할수있다. 대가기준의보정계수가조정될경우, 이부분은적절하게수정될수있다. < 그림 3-11> 리포지토리비용산정초기화면 스텝 1 과스텝 2 의과정을통해 < 그림 3-12> 와같이보정전개발원가와 개발원가를산출해낼수있다. - 62 -
< 그림 3-12> 보정전개발원가산정결과 다음으로최종적인소프트웨어개발비를산정하기위해스텝 3 에서직접 경비와이윤의정보를입력하면 < 그림 3-13> 과같이해당프로젝트의최종 적인소프트웨어개발비산정결과를얻을수있다. < 그림 3-13> 비용산정결과 < 그림 3-14> 의리포트기능은프로젝트정보및산출된기능점수, 소프 트웨어개발비등을바탕으로하여개괄적인프로젝트의정보들과생산성, 기능점수당단가등을확인해볼수있고, 이를보고서형식으로출력이 - 63 -
가능하도록하였다. < 그림 3-14> 리포지토리리포트기능비용산정기능에는개발비대가기준이외에도 < 그림 3-15> 의 COCOMO Ⅱ와같은오픈모델및다른패러다임을갖는비용산정모델을이용한산정결과를비교하여, 프로젝트관리에활용할수있도록한다. < 그림 3-15> COCOMO II 와의산정결과비교 - 64 -
예를들면 < 그림 3-16> 과같이 CBR 기반비용산정시스템 V-ANGEL[7, 8] 을이용한산정결과를비교할수도있도록한다. < 그림 3-16> CBR 기반의비용산정도구 V-ANGEL 과비교 벤치마킹과분석및추론은 < 그림 3-17> 과같이프로젝트의특성그래프 를이용하여산업계의데이터와비교한현프로젝트의분석이가능하도록 한다. 10240 5120 2560 1280 Application Size in Function 640 Points 320 160 80 Some Company 40 Industry 20 10 4 8 12 16 20 24 28 32 Function Points per Person-Month < 그림 3-17> 산업계의데이터를이용한벤치마킹 - 65 -
이와같은다양한기능을리포지토리에서제공할경우, 소프트웨어개발 조직은리포지토리활용을위해신뢰성있는데이터를적극적으로제공할 것이다. 2. 소프트웨어비용자료의활용 상기에서제안한기능이모두구현된비용자료리포지토리는소프트웨어 생명주기동안자동화된비용자료구축환경으로 < 그림 3-18> 과같이활용 된다 [9]. 계획수립 추적 시간 사용자요구사항 산정 산정값 시간기록 결함 영향인자 기능점수 계획과실제 기록된결함 범위변경산정 결함추적 보고 관리감독 수집 리퍼지토리 프로젝트데이터 변경된기능점수측정데이터보고 관계자새로운관리자요구사항감독자경영진수준조직범주프로젝트생산성어플리케이션품질플랫폼비용분석 분석 프로세스개선 < 그림 3-18> 비용자료리포지토리의활용 자동화하고자하는첫번째단계는프로젝트계획수립단계이다. 개발 프로세스를시작할때사용자요구에기초한견적서를만들어내야한다. - 66 -
본연구의산정모델을적용시다양한영향인자들을고려한다. 결과는일 정, 노력, 비용측면에서의프로젝트견적서가된다. 이결과는리포지토리 에저장되고프로젝트관리모델의다음단계로보내진다. 일단산출물에대한합의가이루어지고적절히산정된후, 프로세스의다음단계는설계, 구축, 시험단계에서의프로젝트활동을추적하는것이다. 프로젝트추적은생명주기전반에걸쳐일어나며, 일정보고, 결함추적, 요구사항범위의변경관리등을포함한다. 자동화된시스템에서는프로젝트일정이기록되고프로젝트일정및시간보고도구에입력된다. 이시간데이터는리포지토리에도저장됨으로써, 나중에계획대비실적을비교해볼수있도록한다. 주요이정표마다정형화된검토와조사가수행된다. 결함이발견되면기록되고, 결함추적시스템에입력된다. 결함추적시스템은어떤결함이수정되었는지에관한최신의레코드를유지한다. 검토및조사프로세스동안에얻어진추가정보에기초하여개발프로세스가분석된후, 결함의원인, 심각성, 유형이조사수집된다. 결함추적시스템은결함의원인을분석함으로써개발프로세스의효과를자동으로평가한다. 결함이발견된곳과발생한곳은다를수있다. 결함데이터는리포지토리로보내진다. 만약범위의변경이발생하면우리는당연히새로운산정을수행해야한다. 산정값이계산되고, 범위변경, 예상인도일, 비용정보가리포지터리를통해서추적된다. 프로젝트관리임의의시점, 또는프로젝트를완료하고나서도자동화된관리정보시스템도구를활용하여진척도를평가할수있다. 이자동화시스템은프로젝트관리자, 개발관리자, 최고경영진을포함한다양한관계자들에게정보를제공한다. 각보고수준에서는소프트웨어개발프로세스를모니터하고관리하는데필요한데이터를쉽게얻을수있다. 이기능을이용하여조직의성과데이터, 프로젝트프로파일, 어플리케이션평가 - 67 -
정보모두에접근할수있다. 자동화환경의마지막단계는기준선설정이다. 기준선을설정하는것은정량적데이터와정성적데이터를수집해서성과프로파일을만드는것이다. 이것은소프트웨어개발프로세스를관리하기위해데이터를수집, 분석, 분류하는작업을일체화한다. 프로젝트별로수집된프로젝트데이터들은중앙리포지토리에보관되고기준선설정에이용된다. 일단기준선데이터의수집및보고프로세스가시작되고나면, 입수할수있는산출물이갖는가치는매우높다. 프로젝트및조직프로파일은수많은변수들에기초한성과수준을보여준다. 생산성이높은프로젝트는소프트웨어프로세스의강점과약점을평가하기위해생산성이낮은프로젝트와비교될수있다. 측정업무들을자동화함으로써데이터수집및보고프로세스에서의생산성과정확성이향상될수있다. - 68 -
제 4 장 S/W 개발비대가기준의개선 제 1 절비용산정모델의보정계수와비교 대표적인상용비용산정모델을포함한다양한비용산정모델과현행대가기준의보정계수를비교한결과는 < 표 4-1> 과같다. 이표에서보는바와같이인적속성이나프로젝트속성을제외하고는기존의보정계수는대부분포함되어있다. 그러나인적속성이나프로젝트속성은일반적인소프트웨어비용산정모델과는달리소프트웨어사업대가기준의보정계수로적당하지않다. COCOMO 모델을중심으로일반적인소프트웨어비용산정모델의보정계수중에서현행대가기준에포함되지않은보정계수들이소프트웨어사업대가기준의보정계수로타당한지의여부를검토한다. < 표 4-1> 비용산정모델과현행대가기준의보정계수비교 Group Factor SLIM PRICE-S ESTIMACS SEER-SEM SELECT COCOMO II 사업대가기준 Size attributes LOC FP NO NO NO Program attributes Type/domain Complexity Language Reuse Required reliability??? NO NO? NO Computer attributes Resource constraints Platform volatility??? NO NO NO Personnel attributes Personnel capability Personnel continuity Personnel experience???? NO NO NO NO NO NO NO Project attributes Tools and Techniques Breakage Schedule constraints Process maturity Team cohesion Security issues Multisite development????????? NO NO NO NO NO NO? NO NO NO Activities attributes Inception Elaboration Construction Transition and maintenance NO NO - 69 -
1. 인적속성 소프트웨어개발비에는인적속성이제품규모다음으로큰영향을끼친다. 인적속성은개인이아닌개발팀의능력과경험의등급을매기기위한것이다. 이등급은경험의획득이나프로젝트에대한인력의순환을반영하므로프로젝트과정동안변경될가능성이가장높다. 1) 분석가능력 (ACAP) 분석가들은요구사항, 고수준의설계, 상세설계를담당하는사람이다. 등급설정시고려해야하는주요특성은분석과설계능력, 효율성, 완전 성, 의사소통및협력능력이다. 등급은분석가의경험수준을고려하는 것이아니다. 이것은 APEX, LTREX, PLEX 로등급을매긴다. 15 백분위수 에속하는분석가팀은 very low 로등급을매기고, 90 백분위수에속하는 팀은 very high 로등급이매겨진다. COCOMO Ⅱ 의경우에는 < 표 4-2> 와 같이정의된다. 분류기준 15th percentile < 표 4-2> ACAP 보정계수 35th percentile 55th percentile 75th percentile 90th percentile 등급 Very Low Low Nominal High Very High Extra High 노력승수 1.42 1.19 1.00 0.85 0.71 n/a 2) 프로그래머능력 (PCAP) 현재의추세는매우능력있는분석가의중요성을계속강조하고있다. 그러나복잡한 COTS 패키지의역할이증대되고, 이러한 COTS 패키지를다루는프로그래머의능력과관련된생산성의영향력때문에프로그래머능력이더욱중요시되는추세이다. - 70 -
평가는프로그래머가개인보다는팀으로서의능력에기반을두어야한다. 이등급에서고려해야하는주요요인은능력, 효율성, 완전성, 의사소통및협력능력이다. 프로그래머의경험은여기에서고려하지않는다. 이것은 APEX, LTEX, PLEX로등급을매긴다. very low 등급의팀은 15 백분위수에있고, very high 등급의프로그래머팀은 90 백분위수에있다. COCOMO Ⅱ의경우에는 < 표 4-3> 와같이정의된다. < 표 4-3> PCAP 보정계수 분류기준 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile 등급 Very Low Low Nominal High Very High Extra High 노력승수 1.34 1.15 1.00 0.88 0.76 n/a 3) 인력연속성 (PCON) PCON에관한등급스케일은인력의연간이직율에반대되는개념으로연속성이있다. 연간이직율이 3 퍼센트인 very high 등급부터연간이직율이 48 퍼센트까지인 very low 등급까지있다. COCOMO Ⅱ의경우에는 < 표 4-4> 와같이정의된다. < 표 4-4> PCON 보정계수 분류기준 48%/year 24%/year 12%/year 6%/year 3%/year 등급 Very Low Low Nominal High Very High Extra High 노력승수 1.29 1.12 1.00 0.90 0.81 n/a 4) 어플리케이션경험 (APEX) - 71 -
이보정계수의등급은소프트웨어시스템이나서브시스템을개발중인프로젝트팀의어플리케이션경험에좌우된다. 이러한유형의어플리케이션에대한프로젝트팀의해당경험수준으로등급이정의된다. very low 등급은어플리케이션경험이 2개월이하이다. very high 등급은 6년이상의경험이다. COCOMO Ⅱ의경우에는 < 표 4-5> 와같이정의된다. < 표 4-5> APEX 보정계수 분류기준 2 months 6 months 1 year 3 years 6 years 등급 Very Low Low Nominal High Very High Extra High 노력승수 1.22 1.10 1.00 0.88 0.81 n/a 5) 플랫폼경험 (PLEX) COCOMO Ⅱ의 Post-Architecture 모델은그래픽유저인터페이스, 데이터베이스, 네트워킹, 분산미들웨어기능을포함하는더욱강력한플랫폼의중요성을인식하여, 이전에는 PEXP라고불렀던요인의영향을확대시켜플랫폼경험 PLEX를정의했다. COCOMO Ⅱ의경우 < 표 4-6> 에등급기준이제시되어있다. < 표 4-6> PLEX 보정계수 분류기준 2 months 6 months 1 year 3 years 6 years 등급 Very Low Low Nominal High Very High Extra High 노력승수 1.19 1.09 1.00 0.91 0.85 n/a 6) 언어와도구경험 (LTEX) - 72 -
이것은소프트웨어시스템과서브시스템을개발중인프로젝트팀이사용하는프로그래밍언어와소프트웨어도구의경험을나타내는척도이다. 소프트웨어개발은요구분석및설계, 형상관리, 문서화, 라이브러리관리, 프로그램스타일과포맷팅, 일관성검사, 계획과제어등을수행하는도구의사용을포함한다. 프로젝트의프로그래밍언어에대한경험에추가하여, 프로젝트지원도구의사용경험도개발비용에영향을준다. low 등급은 2개월이하의경험에해당한다. very high 등급은 6년이상의경험에해당한다. COCOMO Ⅱ의경우에는 < 표 4-7> 와같이정의된다. < 표 4-7> LTEX 보정계수 분류기준 2 months 6 months 1 year 3 years 6 years 등급 Very Low Low Nominal High Very High Extra High 노력승수 1.20 1.09 1.00 0.91 0.84 n/a 7) 인적속성이대가기준의보정계수로적절하지않은이유 일반적으로비용산정모델의경우, 상기 COCOMO Ⅱ 모델과같이인적속성의수준이높을수록보정계수의값은 1보다작아비용산정값을낮추는효과를낸다. 즉인력의수준이높을수록개발이쉽고기간이단축되는현상을나타내는것이다. 그러나개발현장에서는인력의수준이높을수록개발비용을더받아야 한다는정서가지배적인것을감안하면, 비용산정모델과같은의미의인 적속성의보정계수를가질수없다. 개발비대가기준의경우, 발주자가특정사업을발주할경우특정수주 자를염두에두지않은상태에서개발비가산정되어야한다. 대가기준의 - 73 -
보정계수는결국평균생산성을의미하게되고, 생산성이높은조직은대 가기준을통해산정된비용보다더적은비용으로개발을하여이윤을높 일수있도록하여야한다. 2. 프로젝트속성 프로젝트요인은현대식소프트웨어도구, 개발팀의분산정도, 프로젝 트일정의단축과같은요소들이비용산정에미치는영향을설명한다. 1) 소프트웨어도구 (TOOL) 소프트웨어도구는 COCOMO의이전버전이유도된환경인 1970년대프로젝트이후와비교할때크게발전했다. 도구의등급은단순한편집과코딩만을지원하는도구인 very low부터통합된생명주기관리도구인 very high까지이다. COCOMO 81의 Nominal TOOL 등급은 COCOMO Ⅱ 의 Very Low TOOL 등급에해당한다. COCOMO Ⅱ의경우에는 < 표 4-8> 와같이정의된다. < 표 4-8> TOOL 보정계수 분류기준 edit, code debug simple, frontend CASE, little integration basic lifecycle tools, moderately integrated strong, mature lifecycle tools, moderately integrated strong, mature, proactive life-cycle tools, well integrated with processed, methods, reuse 등급 Very Low Low Nominal High Very High Extra High 노력승수 1.17 1.09 1.00 0.90 0.78 n/a - 74 -
2) 다중사이트 (SITE) 다중사이트에서개발하는빈도가증가하고, 다중사이트에서의개발효과가중요하게인식됨에따라, SITE 보정계수가 COCOMO Ⅱ에추가되었다. 이보정계수의등급을결정하는것은두가지요인으로 site collocation과통신지원이다. 이들요인의평균값으로등급을매긴다. 예를들어, 만일팀이충분히분산되면, 대화식멀티미디어가필요하지않아도 Extra High 등급을달성할수있다. 이경우에 narrowband e-mail이면대개충분하다. COCOMO Ⅱ의경우에는 < 표 4-9> 와같이정의된다. < 표 4-9> SITE 보정계수 분류기준 1 International Multi-city and Multicompany Multi-city or Multicompany Same city or metro. area Same building or complex Wideband Fully collocated 분류기준 2 Some phone, mail Individual phone, FAX Narrow band e-mail Wideband electronic communication electronic communication, occasional Interactive multimedia video conf. 등급 Very Low Low Nominal High Very High Extra High 노력승수 1.22 1.09 1.00 0.93 0.86 0.80 3) 프로젝트속성이대가기준의보정계수로적절하지않은이유 마찬가지로프로젝트속성의경우, 대가기준에포함되지않은보정계수는개발도구, 프로세스성숙도, 개발팀의응집도등이있다. 비용산정모델에서대개개발도구, 프로세스성숙도, 개발팀의응집도수준이각각높을수록개발비용을줄이는결과를내게되므로, 이경우보정계수들은 1보다작은값을가진다. - 75 -
최근에 Brad Clark은 112개의잘정의된데이터를가지고 COCOMO Ⅱ 의 SEI-CMM 프로세스성숙도 cost driver의영향에대한연구를했다. 이결과는조직의환경, 도구의사용, 소프트웨어의재사용에관한동시의변경효과를정규화한후에도 CMM 성숙도수준이한단계향상되면개발비용이약 15% 에서 20% 가감소한다는것을발견하였다. 즉, 프로세스성숙도수준이높을수록보정계수의값이작아진다는것을나타낸다. 그러나개발비대가기준에서는수주자가특정도구를사용하는지의여부를알수없고, 강요할수도없다. 비록특정도구의사용을알수있거나, 의무화할수있다고하더라도일반적인비용산정모델과는다른의미를가지거나일관성이없게될것이다. 프로세스성숙도와개발팀의응집도도마찬가지문제가발생한다. 오히려개발현장의정서는고수준의도구를사용하거나, 프로세스성숙도가높을경우, 개발팀의응집도가높을경우에는비용산정모델과는반대로개발비용을더받는것을요구한다. 즉, 이경우에보정계수가 1보다큰값을가지는것을당연시하는경향이지배적이다. 3. 개발초기단계에적합한보정계수 < 표 4-1> 의다양한보정계수들도개발초기단계에서파악하기어려운경우가일반적이다. 따라서 COCOMO Ⅱ의경우개발초기단계에서도출가능한보정계수만을적용하는 Early Design 모델을정의하였다. Early Design 모델의보정계수들은 < 표 4-10> 에정의되는데, Post-Architecture 모델의보정계수를결합하여얻어진다. - 76 -
< 표 4-10> Early Design 모델의보정계수비교 Early Design Cost Driver RCPX RUSE PDIF PERS PREX FCIL SCED Counterpart Combined Post-Architecture Cost Drivers RELY, DATA, CPLX, DOCU RUSE TIME, STOR, PVOL ACAP, PCAP, PCON APEX, PLEX, LTEX TOOL, SITE SCED Early Design 모델은개발되는제품의규모, 플랫폼의특성, 프로젝트를진행하는인력의특성, 사용된프로세스의상세한특성에관해서알려진것이거의없는소프트웨어프로젝트의초기단계에서이용된다. 이모델은어플리케이션생성기, 시스템통합, 인프라개발부분에서채택된다. < 표 4-10> 에서본것처럼, COCOMO Ⅱ의 Early Design 모델에적용가능한보정계수는소수에불과하므로, 개발비대가기준에부적합한인적속성과프로젝트속성을제외하면, 실제로개발비대가기준의보정계수는전혀다른관점에서접근을해야한다는것을알수있다. 결론적으로, 대가기준의보정계수에적용될수있는비용산정모델의보정계수는거의없다. 따라서대가기준의적용시점에타당한보정계수는일반적인비용산정모델들의보정계수가아니라기능점수를계산하는시점에서확인이가능한속성들을이용하여야한다는것을알수있다. 개발비대가기준이주로적용되는시점에서도출가능한보정계수를찾아야한다는점을고려하면, 기능점수가계산되는시점에서파악하기에적합한보정계수는 IFPUG의일반시스템특성 (GSC) 이적절하다는결론을얻을수있다. 뿐만아니라 IFPUG의일반시스템특성은개발초기단계에서도출가능할뿐만아니라현행대가기준에서반영하지못하는어플리케 - 77 -
이션의다양한속성을나타내는보정계수이다. 제 2 절 IFPUG 의일반시스템특성의반영 1. 일반시스템특성도입의타당성 앞에서분석한것처럼, 현행대가기준의보정계수를비교할때개발자의속성이나프로젝트의속성을제외하고는비용산정모델의보정계수는대부분포함되어있다. 그러나대가기준에서 IFPUG의기능점수를채택하였음에도기능적인규모 (Functional Size) 만을반영하였고, 정작일반시스템특성이의미하는기술적인규모 (Technical Size) 는반영하지못하였다. 일반시스템특성이채택되지못한이유중의하나가앞에서도기술한바와같이현행대가기준의보정계수가 14개일반시스템특성이상당부분중복되기때문에이중으로고려한다고판단하였으나, 오히려현행대가기준의보정계수의보정효과가뚜렷하지않은경우에는, 일반시스템특성을채택하지않을이유가없다. 즉, 일반시스템특성을통해기존보정계수의단점을해결하는방안을검토할필요가있다. 최근발표된 IFPUG의 CPM 4.2에서현재의환경에서적절하게활용할수있는명료한일반시스템특성의정의및영향도선정기준을발표하였을뿐만아니라, 최근의연구 [10] 에의하면일반시스템특성을반영하는것이산정의정확도를향상시켰다고한다. 2. 일반시스템특성의판단기준 - 78 -
기존대가기준의개선작업에서 IFPUG의미조정기능점수만채택되고, 일반시스템특성이채택되지못한근본적인이유는일반시스템특성의판단기준이모호하였기때문이다. 그러나 David Consulting Group[11] 과 IFPUG의 CPM 4.2에서현재의개발환경에쉽게적용할수있는기준을제시하였다. 새롭게제시된전형적인어플리케이션유형에따른영향도 (Degree of Influence) 선정기준은다음과같다. 가. 데이터통신 데이터통신은어플리케이션이프로세서와직접통신하는정도를말한다. 어플리케이션에서사용되는데이터와제어정보는통신설비를통해서전송되거나수신된다. 제어장치에지역적으로연결된터미널들은통신설비들을사용하는것으로간주된다. 프로토콜은두개의시스템또는디바이스간에정보의전송이나교환을가능케해주는일련의규약이다. 모든통신링크는어떤유형의프로토콜을필요로한다. 1 배치어플리케이션 : 0 ~ 3 2 온라인어플리케이션 : 4 3 웹기반어플리케이션 : 4 ~ 5 4 실시간, 원격통신, 프로세스제어시스템 : 4 ~ 5 나. 분산데이터처리 분산데이터처리는어플리케이션이자신의구성요소간에데이터를전송 하는정도를말한다. 데이터나프로세스의분산처리기능은어플리케이션 경계내에서어플리케이션이갖는특성이다. 1 대부분의어플리케이션 : 0 2 데이터가온라인으로전송되지않는기본적인분산어플리케이션 : 1-79 -
~ 2 3 클라이언트-서버혹은웹기반어플리케이션 : 3 ~ 4 4 아주드문경우로, 각각실시간가용성을기초로동적으로선택되는복수개의서버또는프로세서를가지는어플리케이션 : 5 다. 성능 성능은응답시간과처리율 (throughput) 을고려하는것이어플리케이션에영향을주는정도를말한다. 응답시간이나처리율측면에서사용자에의해언급되거나승인된성능목표는어플리케이션의설계, 개발, 설치, 지원에영향을미친다. 1 배치어플리케이션 : 0 ~ 4 2 대화형클라이언트-서버혹은웹구동 (web-enabled) 어플리케이션을포함하는온라인어플리케이션 : 0 ~ 4 3 웹기반어플리케이션 : 4 ~ 5 4 대부분의 MIS 온라인시스템 : 2 5 실시간, 원격통신, 혹은프로세스제어시스템 : 0 ~ 5 6 성능분석도구의사용이필요한어플리케이션 : 5 라. 컴퓨터자원제약 컴퓨터자원제약은어플리케이션의개발에영향을미치는컴퓨터자원의제약정도이다. 설계를할때특별한고려를필요로하는어플리케이션의특성중의하나이다. 예를들어사용자가기존에존재하거나사용중인장치에서어플리케이션을운영하기를원할수도있다. 1 대부분의어플리케이션 : 2 2 클라이언트서버, 실시간, 원격통신이나프로세스제어시스템 ( 동일 - 80 -
한트랜잭션들을처리하고가장빠른처리수단을찾는전용프로세서나 다중프로세서가필요함 ) : 3 ~ 5 마. 트랜잭션비율 트랜잭션비율은비즈니스트랜잭션의비율이어플리케이션의개발에영 향을미치는정도를말한다. 트랜잭션비율이높으면어플리케이션의설계, 개발, 설치및지원에영향을미친다. 1 배치어플리케이션 : 0 ~ 3 2 대화형클라이언트-서버혹은웹기반어플리케이션을포함하는온라인어플리케이션 : 0 ~ 4 3 실시간, 원격통신, 혹은프로세스제어시스템 : 0 ~ 5 4 성능분석도구의사용이필요한어플리케이션 : 5 바. 온라인데이터입력 온라인데이터입력은대화식트랜잭션을통해데이터가입력되는정도 를말한다. 온라인데이터입력과제어기능은어플리케이션이제공하는 특성이다. 1 배치어플리케이션 : 0 ~ 1 2 온라인, 실시간, 원격통신또는프로세스제어시스템 : 5 3 클라이언트-서버혹은웹기반어플리케이션을포함하는대부분의현행온라인어플리케이션 : 5 4 온라인특성을가지는배치시스템이라도최소 71 퍼센트의배치트랜잭션을가지는어플리케이션 : 5 미만 사. 최종사용자효율성 - 81 -
최종사용자효율성은사용자를위한어플리케이션의이용용이성과인 간요소 (human factor) 의고려정도를말한다. 1 순수한배치어플리케이션 : 0 2 캐릭터모드사용자인터페이스 : 1 ~ 2 3 소량의트랜잭션을위해사용되는 GUI 사용자인터페이스 : 3 4 다량의트랜잭션을위해사용되는 GUI 사용자인터페이스와대부분의웹인트라넷사용자인터페이스 ( 인간요소를위한설계작업이필요 ) : 4 5 웹인터넷사용자인터페이스 ( 목표가달성되었음을보이기위한특별한도구와프로세스들의사용이필요 ) : 5 아. 온라인갱신 온라인갱신은내부논리파일이온라인으로갱신되는정도를말한다. 1 순수한배치어플리케이션 : 0 2 어플리케이션의데이터처리혹은검증방식을수정하는파일의온라인갱신 : 1 ~ 2 3 사용자의영속적인 (persistent) 데이터의온라인갱신 : 3 4 MIS 어플리케이션 : 3 이하 5 대부분의 GUI 형식의어플리케이션 : 3 이상 6 SQL 롤백 (roll back) 과완료 (commit) 와같은복구기능이프로그램된어플리케이션 ( 데이터손실을막기위한운영상의 / 일상적인백업은고려하지않음 ) : 4 7 시스템에러가발생할때데이터를복구하거나다시부팅하거나, 다른독립적인기능을수행할것을요구하는어플리케이션 ( 복구는사람이이프로세스를구동하기위해엔터키를누르거나다른최소한의기능을 - 82 -
요구할수있음 ) : 5 자. 다중사이트 다중사이트는상이한하드웨어와소프트웨어환경을대상으로개발되는 정도를말한다. 1 메인프레임에서운영되는대부분의어플리케이션 :0 2 만일매우상이한구성혹은상이한운영체제를가지는메인프레임에서운영되는어플리케이션 : 0보다큰값 3 Windows NT에서운영되는어플리케이션 : 1 4 Windows 95, 98, NT에서모두운영가능한어플리케이션 : 2 5 상이한메모리크기, 다양한기억용량, 상이한프로세서속도, 상이한프린터유형의하드웨어환경에서운영가능한어플리케이션 : 2 6 상이한유형의운영체제인 Windows, OS X, UNIX, Linux, VOS3 등에서운영가능한어플리케이션 : 3 7 상이한하드웨어환경인인텔기반의 PC, MAC, Tandem, Sun, AS400 등에서운영가능한어플리케이션 : 3 3. 값조정인자 (Value Adjustment Factor) 의범위 가. 산출방식 14 개의일반시스템특성 (GSC) 은값조정인자 (VAF) 로요약된다. VAF 는최종조정된기능점수값을산출하기위해미조정기능점수값을 +/- 35% 보정한다. 대체적으로값조정인자의가능범위를매우여유있게잡으면, 단순한 배치어플리케이션은총점수 ( 총영향도, TDI) 가 15 이하, 프런트 - 엔드배 - 83 -
치어플리케이션은 15에서 30사이, 대화식어플리케이션은 30에서 45사이, 온라인어플리케이션은 30에서 65사이, 웹기반어플리케이션은 30에서 70 사이, 실시간, 원격통신또는프로세스제어시스템은 30에서 70사이로예상할수있다. 값조정인자 (VAF) 를계산하는절차는다음과같다. 1 14개의 GSC를각각의지침에따라각 GSC의영향도를결정하기위해 0에서 5까지의점수로평가한다. 2 14개 GSC의영향도를모두더해총영향도 (TDI) 를계산한다. 3 다음공식에 TDI를대입하여값조정인자 (VAF) 를계산한다. VAF = (TDI 0.01) + 0.65 나. 현행대가기준의보정계수와비교 현행대가기준에서어플리케이션자체의특성을반영하는보정계수는어플리케이션유형보정계수와품질및특성보정계수이다. < 표 4-11> 은현행대가기준에서두가지보정계수가가질수있는범위와이속성들을 IFPUG의일반시스템특성으로식별한후값조정인자를구한결과를비교한것이다. < 표 4-11> 현행기준의보정계수와 VAF 범위 어플리케이션유형업무처리용과학기술용멀티미디어용지능정보용시스템용통신제어용공정제어용지휘통제용 보정계수가능범위 ( 품질및특성보정계수반영 ) 1.00 ~ 1.20 1.20 ~ 1.44 1.30 ~ 1.56 1.70 ~ 2.04 1.70 ~ 2.04 1.90 ~ 2.28 2.00 ~ 2.40 2.20 ~ 2.64 VAF 가능범위 0.65 ~ 1.30 0.95 ~ 1.30 0.95 ~ 1.30 0.95 ~ 1.30 0.95 ~ 1.30 0.95 ~ 1.30 0.95 ~ 1.35 0.95 ~ 1.35-84 -
< 표 4-12> 는현행대가기준이아닌 IFPUG 의일반시스템특성의기술 관점에서가능한분류기준에서얻어질수있는값조정인자와현행기준 을이용하여식별하였을때가능한보정계수의범위를비교한것이다. < 표 4-12> 일반시스템특성의 VAF 와보정계수범위 VAF 기준분류배치어플리케이션 Front-end 배치어플리케이션대화식어플리케이션온라인어플리케이션웹기반어플리케이션실시간, 원격통신, 프로세스제어시스템 VAF 범위 0.65 ~ 0.80 0.80 ~ 0.95 0.95 ~ 1.10 0.95 ~ 1.30 0.95 ~ 1.30 0.95 ~ 1.35 현행대가기준보정계수 ( 유형, 품질및특성 ) 1.00 ~ 1.44 1.00 ~ 1.44 1.00 ~ 2.64 1.00 ~ 2.64 1.00 ~ 2.64 1.00 ~ 2.64 일반시스템특성 (GSC) 관점에서는총 14가지의속성을이용하여어플리케이션을분류한다고볼때현행기준이반영하지못하는다양한속성들을반영하므로변별력이더욱뛰어난것은 IFPUG의일반시스템특성 (GSC) 임을알수있다. 또한 < 표 4-11> 에서보는바와같이현행기준의어플리케이션유형만을기준으로품질및특성보정계수를고려하면, 지휘통제용이라고하더라도실제로는매우단순한프로그램이라면보정계수의범위는매우높은값들로이미결정되고, 반대로업무처리용이나과학기술용이라고하더라도어플리케이션의특성이매우복잡한경우에보정계수가높아질수없는문제가있다. 그러나 IFPUG의일반시스템특성의관점에서보정계수를정하면실제적으로어플리케이션이가지는다양한속성에따라적절한보정계수를부여할수있다. < 표 4-12> 에서일반시스템특성의관점에서어플리케이션이가지는속 - 85 -
성에따라분류한어플리케이션들의값조정인자는다양하지만, 현행대 가기준의분류기준으로는어플리케이션의유형에따라기본적으로분류가 되고, 여기에 4 가지속성만을반영하므로변별력이떨어짐을알수있다. 따라서현행대가기준의어플리케이션유형보정계수, 품질및특성보 정계수보다는 IFPUG 의일반시스템특성을이용하여보정계수를정의하 는것이타당함을알수있다. 다. 일반시스템특성을반영한보정계수 개발비대가기준개선 ( 안 ) 에서어플리케이션의다양한특성을반영하기위해일반시스템특성을적용하는것이합리적이다. 그러나 < 표 4-11> 과 < 표 4-12> 와같이 IFPUG의일반시스템특성을이용한 VAF의범위와현행어플리케이션유형보정계수와품질및특성보정계수의범위에는차이가있다. 즉, VAF는최대 1.35로 +35% 의보정효과가있으나, 현행기준의상기보정계수의최대값은 2.64로 +164% 의보정효과가있다. 일반시스템특성을개선안에적용하기위해서는 VAF를그대로보정계수로적용하는것이아니라, VAF 범위와현행기준의보정계수범위가큰차이를보이는어플리케이션유형의경우에만 VAF를조정할필요가있다. 이들유형에는지능정보용, 시스템용, 통신제어용, 공정제어용, 지휘통제용이해당된다. 이들유형은 IFPUG의기능점수를적용하는것이부적절하다고불만이제기된도메인과대체로일치한다. 따라서개선안에서는 IFPUG의일반시스템특성을이용한 VAF를보정계수로적용하되, 기능점수가적용되기에다소부적합한상기유형의경우추가조정인자를적용하는방안을고려한다. 즉, 지능정보및시스템용의경우보정계수는 VAF에 0.75를더하고, 통신제어및공정제어용의경우에는 1을더하고, 지휘통제용인경우에는 1.3을더한다. 각유형에대한보정 - 86 -
계수는다음과같이정의된다. 보정계수 = VAF + 추가조정인자 = (TDI 0.01) + 0.65 + 추가조정인자단, 추가조정인자는지능정보용및시스템용 : 0.75 통신제어용및공정제어용 : 1 지휘통제용 : 1.3 현행대가기준의그외의유형은 0 1 지능정보용및시스템용 : (TDI 0.01) + 0.65 + 0.75 = (TDI 0.01) + 1.4 2 통신제어용및공정제어용 : (TDI 0.01) + 0.65 + 1 = (TDI 0.01) + 1.65 3 지휘통제용 : (TDI 0.01) + 0.65 + 1.3 = (TDI 0.01) + 1.95 4 현행대가기준의그외의유형 : (TDI 0.01) + 0.65 < 표 4-13> 보정계수변환표 유형지능정보용및시스템용통신제어용및공정제어용지휘통제용기타 현행기준 1.70 ~ 2.04 1.90 ~ 2.40 2.20 ~ 2.64 1.00 ~ 1.20 개선 ( 案 ) 1.40 ~ 2.10 1.65 ~ 2.35 1.95 ~ 2.65 0.65 ~ 1.35 상기공식에따른보정계수의허용범위를어플리케이션유형에따라현 행기준과비교하면 < 표 4-13> 과같다. 대체적으로현행기준의보정계수 - 87 -
범위와일치하면서하한의범위가확대되었다. 개선 ( 안 ) 은현행기준에따라단순히어플리케이션유형에의해서만일방적으로과대추정되거나과소추정되는것을막을수있고, 어플리케이션이가지는다양한특성에따라평가할수있는길을열어놓았다. 개선 ( 안 ) 의장점은다음과같다. 1 하한과상한의범위가대체적으로확대됨으로써, 수발주자가현행기 준에대해가지는불만을해소할수있다. 2 IFPUG 의일반시스템특성을그대로적용함으로써, 국제수준과의 벤치마킹이더욱용이해졌다. 3 IFPUG의일반시스템특성은 technical size를반영하여규모를보정하므로상이한특성을가지지만동일한규모를가지는경우보정의여지가없는반면에, 개선 ( 안 ) 은규모는동일하더라도상이한특성의어플리케이션의비용을직접보정할수있으므로기능점수의근본취지에부합한다. 4 장래사업대가기준이유형별상이한단가를적용할경우, 일률적으로 IFPUG 의 VAF 를적용할수있고, 기수집한비용자료를그대로활용할 수있다. 제 3 절납기보정계수의도입 1. 기존비용산정모델의납기보정계수 가. COCOMO 모델의납기보정 - 88 -
(1) 적정납기산정 COCOMO 모델은먼저비용산정식에의해산출된공수 (PM) 를기초로 다음과같은식에의해산정된다. PM = A Size E TDEV = C PM F (2) 납기보정계수 (SCED) COCOMO I 모델에서일정제한비용을보정하기위한일정제한비용 승수는납기보정계수에해당하고, 승수값은 < 표 4-14> 와같다. 75% of nominal < 표 4-14> COCOMO Ⅰ 의납기보정계수 85% of nominal 100% of nominal 130% of nominal 160% of nominal 1.23 1.08 1.00 1.04 1.10 < 표 4-14> 와같이적정납기보다개발기간이단축되는경우 1 보다큰값 을가지지만, 적정납기보다개발기간이길어지는경우에도 1 보다큰값을 가진다는것이특징이다. COCMO Ⅱ 모델에서도납기보정계수에해당하는일정제한비용승수 SCED 가존재하고, 승수값은 < 표 4-15> 와같다. 75% of nominal < 표 4-15> COCOMO II 의납기보정계수 85% of nominal 100% of nominal 130% of nominal 160% of nominal 1.43 1.14 1.00 1.00 1.00-89 -
< 표 4-14> 에서도 COCOMO I 과같이적정납기보다개발기간이단축되 는경우 1 보다큰값을가지지만, COCOMO I 과는달리적정납기보다개 발기간이길어지는경우에는승수값이 1 로정의된다. 나. SLIM 모델의적정납기산정 SLIM 모델에서소프트웨어개발기간은다음식과같이소프트웨어규 모 (S) 뿐만아니라개발노력 (K) 과밀접한관계를가지고있다. 즉, 개발기간 을추정하기위해서는개발노력을알고있어야한다는것이다. t d = (S/C K p ) 1/q 여기에서 S : Size, C : technology constant, K : effort (years) 다. ISBSG 모델의적정납기산정 ISBSG 에서는기본적으로다음산정을위한식을제공하고있다 [12]. 프로젝트생산성 공수 개발속도 적정납기 ISBSG 에서제공하는위의산정식은 ISBSG 리포지토리에있는 731 개의 프로젝트의분석을통해유도되었다. 이프로젝트중에서 300 개는최대팀 규모 (Maximum Team Size) 관련데이터를포함하고있다. - 90 -
산정식들은세그룹으로구분되는데, 각그룹은다음의독립변수를가 지고있다. 1 규모 ( 기능점수 ) 와최대팀규모를이용하는식 2 규모만을이용하는식 3 최대팀규모만을이용하는식 위의세그룹에서, 다음요인별로산정식이제공된다. 1 플랫폼 2 언어유형 3 플랫폼과언어유형의결합 ISBSG 모델의사용자는자신들의필요에따른개발기간을추정하기위 해적절한산정식을선택할수있다. (1) 규모와최대팀규모를이용한프로젝트적정납기산정 N 은산정식의유도에이용된프로젝트의수 산정식 : Months = C Size E1 MxTeam E2 (2) 규모만을이용한적정납기산정 산정식 : Months = C Size E1 2. 적정납기유도방안 가. 공수로부터추정 - 91 -
COCOMO나 SLIM 모델과같이공수로부터개발기간을추정하는방안이다. 그러나현행사업대가기준은공수를추정하는모델이아니라소프트웨어규모를이용하여개발비를직접추정하는모델이므로이방안을적용할수는없다. 나. 생산성수준을이용 평균투입인력이제시되는경우, 규모 (FP) 공수 (E) 평균투입인력 (E/D) 개발기간 (D) 의순서대로구하는방안이다. 그러나이방안을활용하기위해서는평균투입인력이제시되어야하므로사업대가기준에적용할수없는방안이다. 또한이방안은상이한생산성수준의조직간에적용하기에도곤란하므로, 특정수주자를전제로하지않으며다양한수주자들을대상으로하는사업대가기준에적합하지않은방안이다. 그밖에도이방안은상기추정단계별로오차가누적되어편향된결과를유발할가능성이높으므로실제적용하기에무리가있다 [13]. 다. 규모를통해추정 ISBSG 의개발기간추정모델과같이규모를통해직접적정납기를추 정하는방안으로가장단순하고, 누적오차가적어실무적용이용이한현 실성있는방안이다. 따라서본연구에서는이방안을채택하기로한다. 3. 납기보정계수 가. 적정납기산정 ( 案 ) 수집된비용자료의프로젝트규모와개발기간간의관계를이용하여적 정납기산정식을다음식과같이유도하였다. - 92 -
적정납기 = 0.71 규모 (FP) 0.33 나. 납기보정계수적용 적정납기를구하는함수를이용하여프로젝트의적정납기를구한다음, 이를고객이요구한납기와비교하여납기단축율을구하고다시이납기단축율을기초로납기보정계수를적용한다. 즉, 프로젝트규모를기준으로산정한납기를기준으로고객이요구하는납품일자를비교하여, 납품요구기간이적정납기보다짧을때단축비율을기준으로 < 표 4-16> 혹은 < 표 4-17> 의납기보정계수를적용한다. 단축율 = ( 적정납기 - 요구납기 ) / 적정납기 < 표 4-16> 납기보정계수 (1 案 ) 납기단축율 납기보정계수 0% 이하 1.00 0% 1.00 5% 1.00 10% 1.03 15% 1.05 20% 1.07 25% 1.08 30% 1.10 30% 이상 1.10 < 표 4-17> 납기보정계수 (2 案 ) 납기단축율 납기보정계수 0% 이하 1.00 15% 1.14 25% 1.43-93 -
제 5 장현행대가기준과개선안의비교분석 제 1 절설문조사를통한현행대가기준의분석 1. 자료현황및조사항목 소프트웨어실무자를대상으로수행된설문조사는개발비산정기준의사용실태및적절성파악과보완을위해기본사항, 보정계수일반, 보정계수개선의 3가지항목을중심으로수행되었으며, 총 69개소프트웨어개발업체의데이터를수집하였다. 가. 자료현황 총 69개업체의소속기관별구성비율은 < 표 5-1> 과같다. < 표 5-1> 소속기관분류구분발주자수주자발주자 + 기타수주자비율 10% 72% 14% 4% 담당업무의분야별분포는 < 표 5-2> 와같으며, 기타업무로는관리업무 와함께회계또는영업을담당하거나, 관리와개발업무를병행하는경우 등으로조사되었다. < 표 5-2> 담당업무 구분 관리 회계 개발 영업 기획 기타 비율 22% 0% 32% 14% 10% 22% - 94 -
소프트웨어업무경험분포는 < 표 5-3> 과같다. < 표 5-3> 소프트웨어업무경험 구분 3년미만 3년이상 5년이상 10년이상 ~5년미만 ~10년미만 ~15년미만 15년이상 비율 12% 23% 35% 12% 10% 나. 조사항목 설문조사는기본사항, 보정계수일반, 보정계수개선의 3가지부분으로나누어실시되었다. 첫번째, 기본사항의항목으로는 소프트웨어사업대가기준 의소프트웨어개발비산정기준의인식및사용실태, 현행대가기준에의한산정비용와실제비용과의비교항목으로구성되었다. 두번째, 보정계수일반에서는규모보정계수, 어플리케이션유형보정계수, 언어보정계수, 품질및특성보정계수에대한적절성을조사하였다. 세번째, 보정계수개선에서는 14가지일반시스템특성반영의타당성검토와적정납기와납기단축율을계산하는방안등을조사하였다. 2. 설문분석결과 가. 기본사항 정부가제정고시한소프트웨어사업대가기준의인지와활용여부를조사한결과응답자의 97% 가대가기준을인지하고있었으며, 활용여부에서발주자는 알고있으나이용하고있지는않다. 의비율이 57% 로높은반면, 수주자는알고있으며적극적으로이용하고있다. 의비율이 52% 로높게나타났다. 전체적분포는 < 표 5-4> 와같다. - 95 -
< 표 5-4> 대가기준의인지도및활용도 구분알고있으며적극적으로이용하고있다. 알고있으나이용하고있지는않다. 비율 전체 발주자 수주자 50% 43% 52% 47% 57% 44% 잘모른다 3% 0% 4% 현행소프트웨어개발비산정기준을사용하지않는다라고답한 32 개업 체의대가기준미사용이유의분포는 < 그림 5-1> 과같다. < 그림 5-1> 사업대가기준의미사용이유 현행개발비산정기준을이용한산정비용과실제비용비교시 대체적으 로일치함, 대체적으로높다, 대체적으로낮다 가각각 29%, 28%, 23% 로고르게분포했다. < 그림 5-2> 산정비용과실제비용비교 - 96 -
대체적으로일치함 에답한발주자는 0% 인반면, 수주자는 35% 로상반 된의견을보였다. 전체적인분포는 < 그림 5-2> 와같다. 현행개발비산정기준에의한산정비용과실제개발비용이일치하지않거나, 산정값의일관성이없다고응답한경우, 그이유를유형별로구분하여나타내면 < 그림 5-3> 과같다. 업계관계의구체적내용으로는실제비용산정에서는발주자가사전에정한예산에맞추어개발비용이결정되거나, 또는입찰가를적용하는관행을대표적으로들었다. < 그림 5-3> 불일치및일관성부족이유 현행대가기준의기능점수당단가와실제단가를비교할때전체적으로 적절하다 는의견이 53% 로가장높게나타났다. 너무높다 라고응답한발주자는 33% 를차지하는반면수주자는 4% 로나타났다. 또한 적절하다 라고답한발주자는 33% 인반면수주자는 52% 의높은비율로나타났다. 전체적인분포는 < 그림 5-4> 와같다. < 그림 5-4> 기능점수단가와실제단가비교 - 97 -
나. 보정계수일반 (1) 규모보정계수 규모보정계수의적절성에대한응답결과의전체적분포는 < 그림 5-5> 와같다. < 그림 5-5> 규모보정계수의적절성 규모보정계수가 부적절하다, 혹은 매우부적절하다 라고답한이유 를응답유형별로나타내면 < 그림 5-6> 과같다. < 그림 5-6> 규모보정계수가부적절한이유 (2) 어플리케이션유형보정계수 - 98 -
어플리케이션유형보정계수의적절성에대한응답결과의전체적분포 는 < 그림 5-7> 과같다. < 그림 5-7> 어플리케이션유형보정계수의적절성 어플리케이션유형보정계수가부적절하다라고응답한이유를유형별로 분류하면 < 그림 5-8> 과같다. < 그림 5-8> 어플리케이션유형보정계수부적절이유 (3) 언어보정계수 언어보정계수의적절성에대해전체적으로 보통이다 의의견이 52% 으 로높게나타났으며, 발주자는 14%, 수주자는 27% 가 적절하다 라고답하 - 99 -
였다. 발주자는 29%, 수주자는 15% 가 부적절하다 라고답하여발주자와수주자사이에상반된의견을보였다. 또한 매우부적절하다 라고응답한발주자는 14% 의높은비율을나타냈다. 전체적인분포는 < 그림 5-9> 와같다. 그림 4-9 언어보정계수의적절성 언어보정계수가 부적절하다, 혹은 매우부적절하다 라고답한이유 를유형별로나타내면 < 그림 5-10> 과같다. < 그림 5-10> 언어보정계수의부적절이유 (4) 품질및특성보정계수 현행대가기준의품질및특성보정계수에대한적절성에대한응답결 과의전체적인분포는 < 그림 5-11> 과같다. - 100 -
< 그림 5-11> 품질및특성보정계수의적절성 품질및특성보정계수가부적절하다고응답한이유를유형별로정리하 면 < 그림 5-12> 와같다. < 그림 5-12> 품질및특성보정계수의부적절이유 다. 보정계수개선 (1) 일반시스템특성을반영한보정계수 현행대가기준의보정계수를개선하기위해 IFPUG 의 14 가지일반시스 템특성 (GSC) 을반영하는방안에대한의견을물었다. 일반시스템특성 (GSC) 반영의적절성에대한의견은 매우적절하다, 적절하다, 보통이다 가각각 10%, 45%, 41% 로대부분 14 가지일반시