NCA IV-RER- 소프트웨어유지보수대가기준개선 A Study on the Improvement of Software Maintenance Cost Estimation Guidelines 2002. 12.
100 소프트웨어유지보수대가기준개선 A Study on the Improvement of Software Maintenance Cost Estimation Guidelines 2002. 12.
정보화사업의확대와함께정확한소프트웨어유지보수대가기준에대한관심이높아지고있으나현행소프트웨어유지보수대가기준은소프트웨어유지보수규모와는무관하게유지보수비용을책정하므로유지보수비용이과다또는과소책정되는문제점을가지고있습니다. 이처럼정량적인유지보수규모의측정에의한과학적인관리가시행되지않아유지보수사업에서의사용자에대한총체적인서비스수준저하의악순환이계속되는문제점을해결하는대가기준을정립할필요성이높아지고있습니다. 본연구는이러한필요성에입각하여소프트웨어유지보수규모에기초한유지보수대가기준( 안) 을제시하는목적으로수행되었습니다. 소프트웨어유지보수대가기준안을도출하기위하여현재의소프트웨어유지보수비용산정방식을분석하고, 문제점을도출하였으며, 미국등을비롯한선진국의유지보수비용산정방식을분석하여바람직한대안을모색하였습니다. 특히소프트웨어유지보수비용에관해서는국내의실증적인연구가거의없으므로, 실제데이터수집을통한대가기준유도와검증과함께전문가패널에의한의견의수렴을주요방법론으로사용하여현실적인산출기준이될수있도록노력하였습니다. 소프트웨어유지보수대가기준( 안) 은소프트웨어유지보수의업무범위및표준 공정을정의하고, 각공정의공수비중을도출하였습니다. 산정된유지보수기능점 수에실제유지보수프로젝트데이터를기초로유도된기능점수당인건비를곱한 후품질보정계수, 규모보정계수, 어플리케이션유형보정계수, 하드웨어유형보 정계수, 프로그래밍언어보정계수를적용하여최종적인유지보수비용을산정할 수있도록하였으며, 실제유지보수사업비용데이터를수집하여통계적인검증을 수행하여대가기준( 안) 을검증하였습니다. 본연구의결과는정부및공공기관의소 프트웨어유지보수비용산출기준으로활용될수있을것입니다. 중장기적인관점 에서소프트웨어유지보수사업의품질이향상되고생산성이높아져서, 국가경쟁력 이제고될수있도록본연구결과에대한많은활용이있기를기대합니다. 2002년 12월 30일 한국전산원 원장 서삼영
제출문 정보통신부장관귀하 본연구보고서를 고서로제출합니다. 소프트웨어유지보수대가기준개선 의최종연구개발결과보 2002년 12월 30일 연구책임자 : 부장이현옥( 한국전산원정보기술감리부) 공동과제책임자 : 교수권기태( 강릉대학교컴퓨터공학과) 참여연구원 : 선임연구원임재남( 한국전산원정보기술감리부) 선임연구원신수정( 한국전산원정보기술감리부) 주임연구원박찬규( 한국전산원정보기술감리부) 주임연구원김정미( 한국전산원정보기술감리부) 부장진경문(LG CNS S/W 공학센터) 교 교 박사 박사 수신동익( 홍익대학교경영정보학과) 수안연식( 경원전문대학비서학과) 과정김미숙( 강릉대학교컴퓨터공학과) 과정변분희( 강릉대학교컴퓨터공학과)
요약문 1. 제목 소프트웨어유지보수대가기준개선 2. 연구개발의목적및필요성 본과제의연구목적은소프트웨어유지보수사업의발전과정부및공공기관예 산집행의효율성증대, 소프트웨어유지보수업무효율의극대화를위한소프트웨어 유지보수대가기준안을도출하는것이다. 현행소프트웨어사업대가기준에서유지 보수대가는변경/ 유지보수규모실적과무관하게개발비용의 10~15% 범위내에서 수발주자간의협의에의해설정하도록되어있다. 이로써소프트웨어유지보수규 모나시스템의특성과는관계없이유지보수비용이책정되므로고품질의유지보수 서비스를기대하기어려우며, 적정한소프트웨어유지보수사업비를산출하기어렵 다. 따라서, 소프트웨어유지보수의규모와유지보수생산성에영향을미치는제반 요소를발견하고, 이들을비용에연결시키는소프트웨어유지보수대가기준의마련 이필요하다. 본연구는이러한객관적인소프트웨어유지보수대가기준안을마련 하기위하여수행되었다. 3. 연구개발의내용및범위 본연구는소프트웨어유지보수대가기준안도출을위해다음과같은주요연구 를수행하였다. 우선국내외소프트웨어유지보수비용산정모델및사업의유형을 분석한후, 소프트웨어유지보수업무와표준공정을정의하였다. 이를바탕으로사 용자요구조사를통해국내환경에적합한유지보수비용산정의후보모형을선정 하였다. 선정된각후보모형에대해심층적인검토를수행하여최종적인유지보수 비용산정모형을확정하고, 실제수행된소프트웨어유지보수사업의데이터를조 사하여통계적인방법에의해모형의타당성을검증하였다. 검증된모형에대해전 문가집단의의견을수렴하여유지보수대가기준안을완성하였다. - i -
4. 연구결과 (1) 소프트웨어유지보수의대가구조분석 - 국내공공기관의대가기준적용현황분석 - 문헌연구및해외선진사례수집분석을통한개선기본방향검토 (2) 소프트웨어유지보수대가기준의도출 - 소프트웨어유지보수의역무범위와표준공정정의 - 기능점수기법을적용한소프트웨어유지보수규모산정 - 소프트웨어유지보수생산성요소를고려한보정계수정의 - 소프트웨어유지보수소요공수와유지보수규모와의회귀모형정의 (3) 소프트웨어유지보수대가기준에대한실증분석 - 소프트웨어유지보수사례에대한실적데이터수집 - 관련데이터를대가기준에적용한후통계분석 (4) 소프트웨어유지보수사업대가( 안) 제시 5. 활용에대한건의 본연구의결과는공청회등의추가적인절차를거쳐보완되어소프트웨어유지보수사업의대가기준으로활용될예정이다. 이기준은소프트웨어유지보수사업비의예정가격을산정하고계약의기초로활용될수있을것이다. 본소프트웨어유지보수대가기준은소프트웨어개발비산정기준의발전과정과같이시안으로서활용될수있으며, 현업에서활용되면서지속적인보완이필요할것이다. 6. 기대효과 현행소프트웨어유지보수비용산정방법의체계적인개선 유지보수규모에기초한비용산정모델의사용으로당사자의상호이해증진 지속적인활용을통한생산성증대및비용절감기여 - ii -
Summary 1. Title S Study on the Improvement of Software Maintenance Cost Estimation Guidelines 2. Objective and Necessity The purpose of this research is to develop an estimation model for software maintenance costs. It is necessary to carry out the standardization on scopes and process of software estimation, and the improvement of software maintenance cost estimation guidelines. 3. Scope Current software maintenance cost estimation practices and models have been reviewed and analysed. For each types of projects, cost factors are found and a structure of software maintenance cost estimation model is defined. The new software maintenance cost estimation models have been tested by real projects data. Statistical analysis shows that derived models are statistically significant. User groups' opinion on these draft cost estimation model has been surveyed and analysed. 4. Results This research report consists of several parts: 1) analysis on the types of software maintenance projects, 2) investigation on the current software maintenance cost estimation models and researches, 3) derivation of draft - iii -
software maintenance cost estimation models, 4) statistical analysis of cost estimation models with real maintenance project data, and 5) proposition of software maintenance cost estimation guidelines 5. Recommendation The results of this study can be used for cost estimation of software estimation projects. The cost estimation guideline need to be revised by public hearings in the near future. And the guideline can be used as an official cost estimation guideline for software maintenance projects. 6. Expected Impact Through this report, we want to improve the quality of software maintenance project and contributes to the establishment of correct estimation. - iv -
목 차 제 1 장서론 15 1.1 연구의필요성 15 1.2 연구목표 16 1.3 연구의내용및방법 16 제 2 장문헌연구 20 2.1 소프트웨어유지보수의정의및유형분류 20 2.2 소프트웨어유지보수규모견적 25 2.3 소프트웨어유지보수비용산정모델 35 2.4 소프트웨어유지보수생산성요소 49 제 3 장소프트웨어유지보수대가기준후보모형 58 3.1 ISO/IEC 12207 의소프트웨어유지보수공정 58 3.2 일본시스템감사실시기준의유지보수공정 63 3.3 소프트웨어유지보수관련아웃소싱유형 68 3.4 소프트웨어유지보수유형별견적기법 79 3.5 소프트웨어유지보수대가기준사용자요구조사 84 3.6 소프트웨어유지보수대가기준후보모형 95 제 4 장실데이터에의한모형도출및검증 104 4.1 표본의선정및데이터수집 104 4.2 소프트웨어유지보수개념과공정정의 109 4.3 소프트웨어유지보수대가기준개선모형의정의 112 4.4 모형의검증및결과분석 119 제 5 장결론 123 5.1 연구결과의요약 123 - v -
5.2 연구결과의활용방안 123 참고문헌 125 부록(1) 소프트웨어유지보수대가기준사용자요구조사설문 128 부록(2) 소프트웨어유지보수실적데이터수집설문 132 부록(3) 소프트웨어유지보수대가기준( 안) 142 - vi -
그림목차 < 그림 2-1> 소프트웨어유지보수절차 20 < 그림 2-2> 시간에의한분류 21 < 그림 2-3> 대상에의한분류 22 < 그림 2-4> 목적에의한분류 23 < 그림 2-5> 소프트웨어공학, 역공학, 재공학단계별진행과정 24 < 그림 2-6> Oman 모델의포괄적인계층구조 44 < 그림 2-7> 대상소프트웨어유지보수성평가를위한계층구조 45 < 그림 2-8> 국방정보체계소프트웨어유지보수생산성요소 51 < 그림 3-1> 유지보수업무수행절차도 78 < 그림 3-2> SLA 프로세스 82 < 그림 4-1> 소프트웨어유지보수사업대가개요 104 - vii -
표목차 < 표 2-1> 기능유형별복잡도에대한가중치 26 < 표 2-2> 데이터기능의영향인자 31 < 표 2-3> 트랜잭션기능의영향인자 33 < 표 2-4> 소프트웨어개발/ 유지보수노력보정계수 37 < 표 2-5> 용역유지보수대가산정기준 42 < 표 2-6> 소프트웨어유지보수관련대가산정기준( 예) 49 < 표 2-7> 긍정적인생산성요소 52 < 표 2-8> 부정적인생산성요소 53 < 표 3-1> ISO/IEC 12207 유지보수활동대결과물 58 < 표 3-2> 일본시스템감사실시기준유지보수활동대결과물 64 < 표 3-3> 공기업 A 에서의유지보수관련아웃소싱유형 69 < 표 3-4> S 사의유지보수관련아웃소싱유형 70 < 표 3-5> VAF 의세가지관점 98 < 표 4-1> 일반적인유지보수작업의공수비율 106 < 표 4-2> 유지보수표준공정공수비율 106 < 표 4-3> 수집된실제데이터의규모관련상세내역 108 - viii -
< 표 4-4> ISO/IEC 12207 유지보수활동의공수비율 1 < 표 4-5> 공정별기능점수(FP) 당인건비단가 113 < 표 4-6> 규모보정계수 114 < 표 4-7> 어플리케이션유형보정계수 115 < 표 4-8> 어플리케이션유형분류기준 ( 예시) 115 < 표 4-9> 하드웨어유형보정계수 116 < 표 4-10> 프로그래밍언어보정계수 116 < 표 4-11> 언어유형보정계수적용범위 ( 적용대상공정) 117 - ix -
CONTENTS Chapter 1. Introduction 15 Section 1. Research Necessity 51 Section 2. Research Objective 61 Section 3. Research Contents 61 Chapter 2. Previous Researches 02 Section 1. Definitions and types of software maintenance 0 2 Section 2. Software maintenance size estimation 5 2 Section 3. Software maintenance estimation model 5 3 Section 4. Maintenance cost factors 94 Chapter 3. Software maintenance cost model candidate 8 5 Section 1. ISO/IEC 12207 software maintenance process 8 5 Section 2. Japan software maintenance process 3 6 Section 3. Types of software maintenance outsourcing 8 6 Section 4. Sizing approach on software maintenance 9 7 Section 5. Requirements analysis of software maintenance 4 8 Section 6. Software maintenance cost model candidate 5 9 Chapter 4. Model derivation and validation with real data 104 Section 1. Selection of samples and collection of data 40 1 Section 2. Definition of software maintenance and process 90 1 Section 3. Improvement of software maintenance cost estimation model 211 Section 4. Validation and analysis of estimation model 19 Chapter 5. Conclusions 123 Section 1. Summary of results 123 - x -
Section 2. Usage of the study 123 References 125 Appendix 1. Questionnaire for requirements analysis 128 Appendix 2. Questionnaire for real data 132 Appendix 3. Draft of software maintenance estimation guidelines 24 1 - xi -
Figures <Figure 2-1> Software maintenance process 02 <Figure 2-2> Classification by time 21 <Figure 2-3> Classification by object 2 <Figure 2-4> Classification by goal 23 <Figure 2-5> Software engineering, reverse engineering, and reengineering 4 2 <Figure 2-6> Overview of Oman model 4 <Figure 2-7> Hierarchical structure of maintenance 5 4 <Figure 2-8> Maintenance factors of defence information software 1 5 <Figure 3-1> Maintenance process diagram 87 <Figure 3-2> SLA process 82 <Figure 4-1> Overview of software maintenance cost estimation 104 - xii -
Tables <Table 2-1> Weight of functional complexity 62 <Table 2-2> Impact factor of data function 13 <Table 2-3> Impact factor of transaction function 33 <Table 2-4> Software effort multipliers 73 <Table 2-5> Current guideline of maintenance cost estimation 2 4 <Table 2-6> Example of maintenance cost estimation guideline 9 4 <Table 2-7> Positive cost factors 25 <Table 2-8> Negative cost factors 35 <Table 3-1> Maintenance activities vs. artifacts of ISO/IEC 12207 8 5 <Table 3-2> Maintenance activities vs. artifacts of Japan audit guideline 4 6 <Table 3-3> Maintenance outsourcing type of a public enterprise A 9 6 <Table 3-4> Maintenance outsourcing type of S inc. 07 <Table 3-5> Three views of VAF 98 <Table 4-1> Effort ratio of general maintenance activities 106 <Table 4-2> Effort ratio of a standard maintenance process 106 <Table 4-3> Detailed description of maintenance size 108 - xiii -
<Table 4-4> Effort ratio of ISO/IEC 12207 1 <Table 4-5> Cost per FP 13 <Table 4-6> Size adjustment factor 14 <Table 4-7> Application adjustment factor 15 <Table 4-8> Guideline for classification of application 15 <Table 4-9> Hardware adjustment factor 16 <Table 4-10> Programming language adjustment factor 16 <Table 4-11> Coverage of language adjustment factor 17 - xiv -
제 1 장서론 1.1 연구의필요성 현행소프트웨어사업대가기준에서유지보수대가는변경, 추가, 삭제되는유지 보수규모실적과무관하게개발비용의 10~15% 범위내에서수발주자간의협의에 의해설정하도록되어있다. 이로써소프트웨어유지보수규모나시스템의특성과는 관계없이유지보수비용이책정되게되어있어조직간유지보수비용이과다또는 과소책정되는문제점을내포하고있는실정이다. 또한소프트웨어유지보수와관련된생산성향상마인드가정립되지않고있을 뿐만아니라, 정량화된측정에의한과학적관리가구현되지않아, 그결과정보시 스템운영(SM) 사업에서의사용자에대한총체적인서비스수준저하로이어지는 악순환의고리를형성하는원인중의하나로작용하고있다. 정보시스템구축및소프트웨어개발분야의사업대가기준은국내에서 1980년대 부터연구되어그결과가현업에적용되어어느정도정착되었으며, 최근에는사용 자의수준및인식제고에바탕을두고사용자관점에서의사업대가척도가스텝수 방식에서기능점수방식으로제2 의전환단계에이르고있으나, 정보시스템운영 분야의아웃소싱은대기업을중심으로활성화단계에있음에도불구하고유지보수 분야의대가산정연구는거의전무한실정이다. 또한대기업을중심으로정보시스템운영을업무의효율성, 생산성및서비스품 질을고려하여내부조직으로자체운영하기보다별도의전문회사에아웃소싱하는 경향이강화되고있다. 여기에서소프트웨어유지보수는정보시스템운영업무중의중요한부문을차지하 고있음에도시스템운영, 보완개발등과혼재되어있는실정으로뚜렷한역무범위 의정의나사업대가기준이없어사업의전문화에의한사업활성화, 사업품질향상 및관련기술발전을저해하고있다. 소프트웨어유지보수대가기준과관련된연구는아직거의전무한실정에있으 며, 따라서본연구의필요성은다음과같이요약될수있다. o 소프트웨어유지보수관련용역의전문성제고및활성화유도 o 소프트웨어유지보수비용산정기준의부재로인한발주기관및수주업체의혼란을감소시키고상호신뢰도제고 o 소프트웨어유지보수관련역무범위및역할정립 - 15 -
o 소프트웨어유지보수업무관련기술력제고및제값받기에대한과학적틀을 마련함으로써관련사업품질제고 1.2 연구목표 본연구의목표는다음과같이요약할수있다. o 소프트웨어유지보수대가기준의도출 - 소프트웨어유지보수의역무범위정의 - 기능점수기법을적용한소프트웨어유지보수규모산정 - 소프트웨어유지보수생산성요소를고려한보정항목정의 - 소프트웨어유지보수소요공수와유지보수규모와의회귀모형정의 o 소프트웨어유지보수대가기준에대한실증분석 - 정보시스템운영사업아웃소싱사례중소프트웨어유지보수유형분석 - 관련데이터수집및대가기준에의적용을통한분석 o 소프트웨어유지보수사업대가관련법령( 안) 제시 1.3 연구의내용및방법 본연구의연구내용과범위를정리하면다음과같다. 1) 소프트웨어유지보수의역무범위및비용구조조사분석 2) 소프트웨어유지보수관련아웃소싱유형의도출 3) 소프트웨어유지보수유형별견적기법정의 4) 소프트웨어유지보수사업대가산정개선모형정의 5) 소프트웨어유지보수사업대가산정모형관련데이터수집및검증 6) 소프트웨어유지보수사업대가기준( 안) 도출 - 16 -
첫째, 소프트웨어유지보수의역무범위및비용구조조사분석 소프트웨어유지보수는개발이완료됨에따라고객에게인계된산출물 (product) 인소프트웨어제품을대상으로사용자에의해부분적으로필요한기능을수정또 는최적화하는작업이다. 이러한소프트웨어유지보수는크게오류교정유지보수 (corrective maintenance), 기능개선유지보수(perfective maintenance), 환경적응유 지보수(adaptive maintenance), 예방조치유지보수(preventive maintenance) 등으로 분류된다. 그러나현실적으로는정보시스템아웃소싱의역무상아주경미한사항은시스템 운영의역무에포함되며, 또아주많은인력이투입되는유지보수는재개발, 보완개 발등으로별도의개발프로젝트로추진되는것이일반적인경향이다. 본연구에서 는이와관련된기존연구결과및지침등을분석, 정리하고, 정보시스템운영(SM) 사업에서의소프트웨어유지보수역무범위와관련용역의역무에포함되는대가책 정실태를정리분석한다. 이러한분석결과는소프트웨어유지보수비용산정기준 의객관적/ 과학적틀을설정하는데기초자료로활용한다. 국내사례는물론해외의 선진적인소프트웨어유지보수비용산정기준이나방법론에대한분석도수행된다. 둘째, 소프트웨어유지보수관련아웃소싱유형의도출 소프트웨어유지보수는별도의유지보수프로젝트로서개발업체또는소프트웨어사업자에게위탁되기도하며, 소프트웨어유지보수를정보시스템운영역무중의일부로서사업자에게위탁되고있다. 특히후자의경우정보시스템운영역무중에서소프트웨어유지보수와소프트웨어재개발역무를서로구분하기어려운경우가많다. 본연구에서는특정시스템의소프트웨어유지보수를별도의프로젝트로서용역에의해수행하는경우와, 시스템운영역무중의일부로서소프트웨어유지보수부문이포함된경우를고려하여사업대가기준을도출하기위해각각의경우를포함하는비용구조를정의할필요가있다. 일반적인경향으로는전자의경우에는해당유지보수작업물량을기준으로견적하여사업비를추정하고, 후자의경우에는시스템운영사업의위탁용역계약기간에따라서예를들면유지보수대상시스템의전체규모를기준으로익년도유지보수예상물량을추정하여그에따른사업비를추정하는방식이다. - 17 -
셋째, 소프트웨어유지보수견적기법정의 소프트웨어유지보수의작업에소요되는소요공수를산정하기위해우선유지보 수규모를측정해야한다. 본연구에서는유지보수규모측정에사용될규모견적기 법을정의한다. 이를위해기존의관련연구결과를분석정리한다. 여러가지견적 기법중에서현단계에서는유지보수작업물량을직접견적하는방법, 스텝수에의 한견적방법, 기능점수에의한견적방법등이적용가능한대안이된다. 이러한대안 들은전문가의의견, 설문조사및자료수집과정에서비교, 검증을통해장단점등 을분석한다. 또한정보시스템아웃소싱의발주기관및사업자의관점에서견적의용이성, 활 용수준에적합성등을고려하여가장적합한견적기법을도출하고, 이기법이본 연구의소프트웨어유지보수사업대가산정모형의기본모형설정에응용된다. 넷째, 소프트웨어유지보수사업대가산정개선모형정의 소프트웨어유지보수역무에적용가능한산정개선모형은규모견적결과와유지 보수사업대가의관련성을정의하는구조를갖게되며, 소프트웨어유지보수사업 대가는크게소프트웨어개발사업대가등과유사하게인건비, 제경비, 기술료및직 접경비등으로산정될수있으나가능한한직접비중심으로산정하는방안을제시 한다. 소프트웨어유지보수규모의견적은소프트웨어개발비용산정의새로운기준에 적용되고있는기능점수척도가적용될수있다. 또한소프트웨어유지보수사업대 가의기준이되는인건비의산정을위한소요공수는소프트웨어유지보수생산성과 깊은관련을갖는다. 특히소프트웨어유지보수생산성요소는소프트웨어개발특 성및환경과유사한측면이있다. 예를들면 IFPUG 의기능점수산정지침(Function Point Counting Practice Manual) 에서는유지보수프로젝트(enhancement project) 의규모견적치인조정된 기능점수(Adjusted Function Point) 산정시미조정된기능점수(Unadjusted Function Point) 를소프트웨어개발특성과동일한 14 개시스템특성요소(GSC) 에 의해보정하게되어있다. 또한 COCOMO 81, COCOMO II 등을비롯한대부분의선진소프트웨어유지보 수비용산정모델에서도개발생산성요소와유지보수생산성요소를동일한것으 로간주하고있다. 그러나소프트웨어유지보수특성을반영하는객관적이고정량 화된생산성요소의도출이가능한경우, 더욱정확한비용산정을위해유지보수 - 18 -
생산성요소를반영할수도있다. 다섯째, 소프트웨어유지보수사업대가산정모형관련데이터수집및검증 본연구에서제시될소프트웨어유지보수사업대가산정모형은국내의대기업을 중심으로한정보시스템운영업무를수행하고있는현장의데이터를통해검증하여 최적의모형으로서검증된산정모형이채택될것이다. 소프트웨어유지보수사업대가산정모형의검증에는일반적인회귀모형의검증을 위해통계분석이활용될수있으며, 이중에서유지보수규모와소요공수또는인건 비와의관계식에는지수회귀분석모형등이검토될것이다. 특히이번연구에서는국내에서적용중인기존의소프트웨어사업대가기준에 포함된일차선형회귀모형과는달리지수형회귀모형도하나의대안으로서검토한 다. 즉, 회귀식은투입인력( 또는인건비로바로표현가능함) 을산정하기위해서기 능점수와의관계식에서각종보정치들이상수화되어이들이지수로표현됨으로써 사용자의입장에서적용이간편한구조를갖는다. 여섯째, 소프트웨어유지보수사업대가기준( 안) 도출 궁극적으로는연구결과에서도출된최적의소프트웨어유지보수사업대가기준이제도적으로활용되기위해서는관련법( 령) 또는고시에반영될수있어야할것이다. 이를위해서본연구에서는관련전문가등의자문을통해관련법에반영할수있는법령의초안을제시할것이다. 이기준에는소프트웨어유지보수비용산정의방법, 절차그리고이에적용되는각종기준치등이포함된다. - 19 -
제 2 장문헌연구 2.1 소프트웨어유지보수의정의및유형분류 소프트웨어유지보수는 < 그림 2-1> 과같이소프트웨어산물이사용자에게인도 된다음에이루어지는소프트웨어산물에대한수정과보완을뜻하며소프트웨어의 수명을연장시키는일련의행위를말한다 [1]. 소프트웨어기능개선 유지보수요구 현시스템에대한이해 수정및시험 폐기 < 그림 2-1> 소프트웨어유지보수절차 소프트웨어유지보수는개발을진행시키듯이분석, 설계, 구현, 시험단계를거칠 수밖에없으며신규개발과는달리기존의소프트웨어를교정하고새로운기능을추 가하며모든기능들이예전처럼작동하여야하므로개발보다힘든작업이라평가할 수있다. 따라서일반적으로소프트웨어기술자들은소프트웨어생명주기의단계별 활동중에서유지보수활동을가장싫어하며유지보수의작업에참여하는기술자들 의사기는개발에비해상대적으로낮은편으로유지보수작업의양이많아지면이 러한경향이조직전체에파급되어조직의생산성이급속도로저하될수있는요인 으로작용될수도있다. 소프트웨어유지보수는시간, 대상, 목적에의해구분될수 있다 [1]. 2.1.1 시간에의한분류 < 그림 2-2> 와같이소프트웨어유지보수업무가시간적인개념에기인하여처 - 20 -
리되는형태의유지보수를말하며시간에의한분류에는계획보수, 예방보수, 응급 보수, 지연보수가포함되어있으며각각을간단히기술하면다음과같다. 지연 계획 응급 에방 < 그림 2-2> 시간에의한분류 가. 계획보수: 미리정해진내용의소프트웨어변경을정해진기일에계획적으로 실시하는유지보수를말한다. 나. 예방보수: 컴퓨터시스템의정기보수와같이소프트웨어의에러발생을미리 방지하기위하여수행하는형태로특히, 소프트웨어에러가발생하는것에대비하 여예방수단을미리강구하는것이다. 예를들면동일한종류로다른사이트에서 운영중인소프트웨어에서발생한에러에대비한처리를하는것이다. 다. 응급보수: 소프트웨어사용중에예측하지못한에러가발생하였을경우에 이루어지는소프트웨어의변경이다. 라. 지연보수: 소프트웨어의보수가필요하나긴급한정도와소프트웨어변경에 필요로하는자원의이용가능성여부에따라즉시실시되지는않지만추후수행하 는경우이다. 2.1.2 대상에의한분류 < 그림 2-3> 과같이유지보수의대상에따라처리하는형태로서데이터/ 프로그 램의보수, 문서의보수, 시스템의보수등으로구별된다. - 21 -
데이타 문서 프로그램시스템 < 그림 2-3> 대상에의한분류 가. 데이터/ 프로그램보수: 유지보수소요발생에의해데이터( 또는데이터베이 스) 나프로그램을변경하는경우이다. 즉사용중이던데이터의변경이나에러에 의한데이터의복구등이나프로그램의보수를의미한다. 나. 문서보수: 소프트웨어명세서, 기타문서를변경하는경우로소프트웨어그 자체의보수와함께실시되는것이많다. 다. 시스템보수: 조작, 운용절차등응용시스템전체에관한변경의경우이다. 2.1.3 목적에의한분류 < 그림 2-4> 와같이목적에의한소프트웨어유지보수의분류는소프트웨어의 유지보수발생요인에따라처리하는보수형태를의미한다. 가. 오류교정유지보수: 프로그램사용도중에발생된에러를진단하고수정하는 과정으로프로그램이비정상적으로종료되는경우나부적당한정보를출력하는처 리상의에러를수정하며평균응답시간, 트랜잭션의에러발생율등의성능상의에러 를수정하고프로그래밍표준에기준이되지못한경우, 기능명세서와설계내용이 일치되지않는경우등의소프트웨어작성에관한에러를수정하는유지보수를말 한다. 즉시스템의개발및시험당시처리되어야할사항이발견되지못하여발생 된단순오류의수정이나시스템구성에큰변화없는입출력양식의변경정도를 말한다. - 22 -
환경적응 : 25% ( Adaptive M aintenance) 오류교정 : 21% ( Corrective M aintenance) 기능개선 : 50% ( Perfective M aintenance) 예방조치유지보수 : 4% ( Preventive M aintenance) < 그림 2-4> 목적에의한분류 나. 기능개선유지보수: 기존의소프트웨어가성공적으로그기능을수행하는중 에개선요구를받았을때의시행으로보다좋은알고리즘으로수정한다든지, 보다 효율적인사용을목적으로하는변경이다. 다시말하면, 보다편리한사용 을위한 목적에서의출력형식의개선, 새로운출력정보의추가등이른바기능상의보완 또는소스코드의설명을충실하게함으로써프로그램을이해하기쉽고유지보수가 용이하게하고자하는유지보수를말한다. 다. 환경적응유지보수: 소프트웨어사용에따른하드웨어, 운영체제, 네트워크 등의급속한환경변화나분류코드의변경, DBMS 변경등의데이터환경변화에대 해기존의소프트웨어시스템의무결성을유지하기위하여수행하는활동으로프로 그램의수정, 분류코드의변경, DBMS 변경등에따른유지보수를말한다. 실제로 현재하드웨어는점점더빠른주기로발표되고있으며새로운운영체제나그이전 에개발되었던운영체제의새로운버전도정기적으로발표되고있고주변기기와다 른시스템요소들도자주개선되거나수정되고있으므로, 환경적응유지보수의필 요성이강하게제기된다. 라. 예방조치유지보수: 소프트웨어의유지보수성을향상하고신뢰도를개선하기 위하여소프트웨어를변경하는활동으로미래의성능향상을위한더좋은조건을 제공하기위해서변경될때발생한다. 기존의소프트웨어를수명연장이라는목적을위해가능한효과적으로사용하기 위한개념으로 < 그림 2-5> 와같이역공학(Reverse engineering) 과재공학 (Re-engineering) 같다. 기법의필요성이대두되고있으며각각을좀더기술하면다음과 - 23 -
정의 설계 소프트웨어공학 구현 정의 설계 소프트웨어역공학 구현 재정의 재설계 재구현 소프트웨어재공학 < 그림 2-5> 소프트웨어공학, 역공학, 재공학단계별진행과정 (i) 역공학(Reverse engineering): 특정소프트웨어에관련된문서가전혀없어서소스코드가유일한프로그램이해의단서가되는경우에소스코드로부터다양한정보를만들어내는기술을말한다. 즉기존의프로그램에서설계정보나분석정보를복구시키는개념이며완성된하드웨어제품으로부터설계사항과제조사항의정보를추출하는데서비롯된다. (ii) 재공학(Re-engineering): 기존의소프트웨어에서설계정보나분석정보를추출할뿐만아니라, 이정보를이용하여기존의소프트웨어를변경하거나재구성하는개념이다. 2.1.4 소프트웨어재개발 소프트웨어재개발과소프트웨어유지보수와의범위는명확하게설정하기어려 운점이있으나, 소프트웨어재개발에대한정의는일반적으로다음과같다[1]. 첫째, 소프트웨어공학에서는기존소프트웨어를완전히새로운버전으로만들거 나, 객체지향기법과같은새로운기법을적용하여새로운소프트웨어를만드는것 을의미하며다음과같은관점에서통상적으로유지보수와구별된다. 먼저인원을 포함한조직의자원을기존의소프트웨어를개발할때이상으로많이투입한다는 것과기존의산물에바탕을둔것이아닌새로운산물을배포한다는점이다. 둘째, 현행소프트웨어대가산정기준에서재개발이란 개발된소프트웨어의일 - 24 -
부를다시개발하는것으로서업무량또는산정된비용이유지보수의범위를초과 하는경우 를말한다. 셋째, 소프트웨어재개발에대해서 Boehm은같은기능을수행하기위한새소프 트웨어가기존의코드를 재개발로보아야한다고명시하고있다. 50% 이상변경및수정하였다면유지보수의차원을넘어서 따라서, 재개발은기존의소프트웨어와구별되는소프트웨어를다시개발하는것 을말하며, 재개발을 3 가지로분류하면다음과같다. 첫째, 순수재개발은기존시스템의내용을참조하여완전히새로운시스템을개 발하는것이다. 둘째, 확대재개발은기존시스템에새로운기능을추가하여개발하는것이주목 적이다. 여기에서는일부기존시스템의기능변경이수반될수있다. 셋째, 보완개발은기존시스템의기능을변경하는것이주목적이며, 일부기존 시스템에새로운기능이추가될수도있다. 2.2 소프트웨어유지보수규모견적 소프트웨어유지보수비용산정을위한소프트웨어유지보수규모는정확한산정이쉽지않다. 본연구에서는먼저소프트웨어규모산정을위한연구를요약하여소개하고, 소프트웨어유지보수규모를산정하는데참고로활용한후소프트웨어유지보수규모견적방안을분석한다. 2.2.1 IFPUG 의기능점수 소프트웨어규모산정을위한가장보편적인척도인기능점수는기능수계산, 기 술적복잡도계산, 기능점수계산등의 3 단계절차에의해계산된다. 기능수(UFP) 는정보처리규모를계산하는데, 개발대상소프트웨어가명확하게정의되고, 외부 시스템과의인터페이스가분명해진상태에서다음과같이 출하여각각의복잡도를측정한다 [2]. 5가지유형의기능을추 1 외부입력(external input types) : 시스템( 소프트웨어시스템을의미함) 의경 계밖에서시스템에데이터를입력하는기능. 2 외부출력(external output types) : 시스템의경계밖으로데이터를출력하는 - 25 -
3 4 5 기능. 내부논리파일(logical internal file types) : 시스템내에서논리적으로유지되 는파일로서사용자관점에서볼때시스템에의해생성되고, 사용되며, 또한 관리되는논리적인데이터의그룹. 외부인터페이스파일(external interface file types) : 응용시스템간에공유되 거나전송되는파일로서시스템밖의응용시스템이논리적으로유지하는파 일. 외부조회(external inquiry types) : 입력이출력을즉시요구하는입력/ 출력 조합을외부조회로판단한다. 입력또는출력중의하나라도포맷이다르거나, 내부처리로직이다르면별개의기능으로간주함. 각기능의복잡도는단순, 보통, 복잡의 3 단계로구분하여평가한다. 복잡도에 주어지는가중치는기능유형별로상이하다. 많은토론과시행착오를거쳐아래와 같은가중치를도출하였다. < 표 2-1> 기능유형별복잡도에대한가중치 기능유형 가중치 단순보통복잡 기능수 (UFP) 외부입력 _ 3 = 4 = 6 = _ 외부출력 _ 4 = 5 = 7 = _ 내부논리파일 _ 7 = 10 = 15 = _ 외부인터페이스파일 _ 5 = 7 = 10 = _ 외부조회 _ 3 = 4 = 6 = _ 기능수(UFP) 합계 기능수(UFP) 는기술적복잡도를이용하여생산성을측정하는지표인기능점수로 변환된다. 기술적복잡도는아래와같은 14개의항목에대해영향도를평가하여계 산한다. 영향도(Degree of Influence: DI) 는 0 부터 5 까지의정수로나타낸다. a 데이터통신의필요정도 - 26 -
b c d e f g h i j k l m n 분산처리기능의정도 응답속도나처리율(throughput) 과같은시스템의성능(performance) 요구 운용될시스템의사용용이성정도 트랜잭션율(Transaction rate) 이높은정도 온라인자료입력및제어기능요구정도 온라인입력이복수개의스크린또는오퍼레이션을사용하는트랜잭션으로 구성되는정도 내부논리파일을온라인갱신하는정도 처리의복잡성정도 ( 예: 많은제어상호작용과의사결정수반, 광범위한논 리및수학식사용, 많은예외처리로인한불완전한처리) 프로그램재사용의고려정도 변환및설치용이성을고려하는정도 효과적인백업, 복구등운용상의편리함을고려하는정도 복수의조직을위한복수장소에의설치를고려하는정도 변경용이성을고려하는정도 14개항목의영향도를평가하여합산한총영향도는 0 부터 70 사이의값이된다. 기술적복잡도값인값조정인자 계산된다. VAF(Value Adjustment Factor) 는다음식으로 VAF = 0.65 + 0.01 총영향도 기능점수(FP) 는 UFP와 VAF 로부터다음과같이계산된다. FP = UFP VAF 기능점수모형은사용자관점에서소프트웨어를견적하는유용한방법이지만, 적 용범위, 측정의신뢰성, 가중치적용등에서여러가지문제점을내포하고있다. 기 능점수모형을개선하는연구는모형의구조를개선하는방향, 활용성을향상하는 방안, 적용범위를확대하는방향등 3 가지방향으로진행되고있다[3]. 2.2.2 IFPUG 의소프트웨어유지보수기능점수 - 27 -
유지보수프로젝트의기능점수는다음의식으로계산된다 [2]. EFP = (ADD + CHG + CFP) VAF a + (DEL VAF b) 이식에서 ADD는유지보수프로젝트에의해추가되었거나추가될기능의미조정된기능점수 CHG는유지보수프로젝트에의해변경되었거나변경될기능의미조정된기능점수 CFP 는변환(conversion) 에의해추가된기능을나타내는기능점수 VAF a 는유지보수프로젝트가끝난후의어플리케이션값조정인자 DEL은유지보수프로젝트에의해삭제되었거나삭제될기능의미조정된기능점수 VAF b 는유지보수프로젝트를시작하기전의어플리케이션값조정인자 IFPUG의소프트웨어유지보수기능점수계산의특징은개발과유지보수의 GSC 가동일하고다만유지보수전후의 VAF 가상이하다고가정한다는점이다. 따라서 미조정된기능점수인 UFP로규모산정을할경우에는유지보수되는규모만고려하 면되고, 유지보수되는소프트웨어규모와비용간의관계를유도할필요가있다. 2.2.3 NESMA 의소프트웨어유지보수기능점수 NESMA의유지보수프로젝트의기능점수분석은아래의 8 단계로진행된다[4]. 1 유지보수프로젝트의범위내에서트랜잭션기능과데이터기능을식별 2 추가되는트랜잭션기능과데이터기능의유지보수규모를결정 3 삭제되는트랜잭션기능과데이터기능의유지보수규모를결정 4 변경되는데이터기능의유지보수규모를결정 5 변경되는트랜잭션기능의유지보수규모를결정 6 유지보수프로젝트의미조정된기능점수규모를계산 7 값조정인자를적용하여유지보수프로젝트의조정된기능점수규모를계산 8 유지보수이후의시스템의조정된기능점수규모를계산 - 28 -
이방법의특징은삭제된기능과변경된기능의처리이다. 각데이터기능과트 랜잭션기능에대한변경정도는영향인자(impact factor) 로표현된다. 삭제되거나 변경된기능의유지보수기능점수규모는표준기능점수기법에따라계산된기능 점수에영향인자를곱해결정된다. 추가, 변경혹은삭제된각기능의규모를표준기능점수기법을이용하여미조 정된규모 (UFP BASE ) 를먼저계산한다. 트랜잭션기능과데이터기능은추가, 변경 혹은삭제될수있고, 그기능은유지보수제안서에기술된그이상의영향을끼칠 수도있다. 예를들어, 논리파일이나트랜잭션의변경은다른트랜잭션이나논리 파일에영향을줄수도있으므로, 영향받는모든데이터기능과트랜잭션기능이 주의깊게분석될필요가있다. 영향인자(I) 는식별된각각의데이터와트랜잭션 기능의변경의정도를반영한다. 영향을받는각트랜잭션기능과데이터기능의유지보수규모는그기본규모 (UFP BASE ) 에영향인자(I) 를곱해계산된다. 유지보수규모는표준기능점수가아 닌 확장기능점수 (EFP) 로측정되는데둘은상이하다. 소프트웨어의규모를표현 하는데이용되는단위인표준기능점수(FP) 와유지보수의규모를표현하는데이 용되는단위(EFP) 사이의구분을유지하는것이필수적이다. 1) 유지보수프로젝트의범위내에서트랜잭션기능과데이터기능을식별 유지보수제안서, 현재시스템의기능문서그리고기존시스템의기능점수분석 이유지보수프로젝트의범위내에서트랜잭션기능과데이터기능을식별하기위 해이용된다. 기존시스템의기능점수분석은필수적인데그이유는유지보수에의 해직접적으로혹은간접적으로영향받는기존의모든기능들이유지보수기능점 수규모에기여하기때문이다. 만일어떤이유로기존시스템의기능점수분석이가 능하지않으면, 최소한유지보수에의해영향받는기능이라도식별해야한다. 기존시스템의규모혹은유지보수프로젝트에의해영향받는부분은미조정된 기능점수 UFPBASE로표현된다. 2) 추가되는트랜잭션기능과데이터기능의유지보수규모를결정 유지보수제안서는어플리케이션에추가될트랜잭션기능과데이터기능을명세해야한다. 제안서로부터추가될기능의규모를표준기능점수기법을적용하여계 - 29 -
산하는것이가능해야한다. 추가되는기능의합은 UFP ADDED 로표현된다. 추가되는 기능의영향인자는항상 의수는다음과같이결정된다. 1이므로추가기능에대한미조정된유지보수기능점수 UEFP ADDED = UFP ADDED 3) 삭제되는트랜잭션기능과데이터기능의유지보수규모를결정 기존시스템으로부터삭제될데이터기능과트랜잭션기능은유지보수제안서로 부터식별된다. 삭제되는기능의규모는 UFP DELETED 로표현된다. 삭제되는기능의경우영향인자는 결정된다. 0.4이므로미조정된기능점수는다음과같이 UEFP DELETED = UFP DELETED 0.4 예를들어, 삭제되는기능점수가 6이면유지보수기능점수는 2.4 라는의미이다. 4) 변경되는데이터기능의유지보수규모를결정 변경되는데이터기능이식별되고변경이후의각데이터의규모가결정된다. 데 이터기능은내부논리파일(ILF) 이나외부인터페이스파일(EIF) 이될수있다. 데이터기능의각유형은다음을식별하기위해평가된다. - 내부적으로변경되는데이터기능: 추가, 삭제혹은변경되는 DET - 내부적으로변경되지않고유형이변경되는데이터기능 ( 즉, EIF는 ILF로혹 은그반대로변경됨 ) 변경되는데이터기능과변경이후에각데이터기능의기능점수를계산한다. 표 준기능점수기법은변경이후의데이터기능의규모를결정하기위해이용되고변 경된데이터기능의 ( 미조정된) 기능점수는 UFP CHANGED 이다. 내부적으로변경되는데이터기능의경우, 영향인자는변경되는 DET의비율로 부터계산된다. 변경비율은다음의식으로계산된다. - 30 -
변경비율 = 추가 / 변경 / 삭제된 DET 의수 100 원래데이터기능에서 DET 의수 영향인자 (I CHANGED ) 는 < 표 2-2> 로부터 DET 의변경비율을이용하여결정된다. < 표 2-2> 데이터기능의영향인자 DET 비율 33% 67% 100% >100% 영향인자 0.25 0.50 0.75 1.00 만일외부인터페이스파일이내부논리파일이되는것처럼데이터기능의유형 이변경되면, 영향인자로 0.4 의값이이용된다. 만일유형뿐만아니라데이터기능이변경되면, DET의변경에기인한영향인자 가결정되어야한다. 유형의변경에기인한영향인자의값과 DET의변경에기인 한것과비교되어더높은값이유지보수기능점수규모의계산에이용된다. 변경된데이터기능의유지보수기능점수는다음과같이계산된다. UEFP CHANGED = UFP CHANGED I CHANGED 따라서데이터기능의변경으로인한유지보수기능점수는데이터기능의변경 정도에좌우된다. 만일 EIF나 ILF 가둘이상의데이터기능으로나누어지면, 하나 의삭제된데이터기능과둘이상의추가된데이터기능으로계산된다. 만일 EIF와 ILF 가결합되면, 두개의삭제된데이터기능과하나의추가된데이터기능으로계 산된다. 5) 변경되는트랜잭션기능의유지보수규모를결정 변경되는트랜잭션기능이식별되고변경이후의각트랜잭션의규모가계산된 다. 변경이후의트랜잭션의규모를계산하기위해표준기능점수기법이사용된다. 변경이후의 ( 미조정된) 기능점수는 UFP CHANGED 로표현된다. 트랜잭션기능은데이터기능에대한변경에의해영향을받을수도있다. 유지 보수제안서에명세되고데이터기능에대한변경에의해영향을받는모든트랜잭 - 31 -
션기능이분석된다. 다시말하면유지보수제안서에서식별된트랜잭션이포함되거나, 유지보수제안서에정의된다른변경의결과로기능이변경되는트랜잭션에대해계산된다는것이다. 일반적으로사용자가변경되는트랜잭션을식별할수있다면, 트랜잭션은계산되는데다음기준중의하나가만족되었다는것을의미한다. - 추가, 변경, 삭제되는 DET 에의해트랜잭션이영향을받는다. - 추가, 변경, 삭제되는 FTR(ILF 혹은 EIF) 에의해트랜잭션이영향을받는다. - 스크린이나리포트의결합과같이사용자인터페이스가변경된다. - 트랜잭션데이터에수행되는규칙이나계산을편집하는것과같이트랜잭션을 지원하는비즈니스로직이변경된다. - 리포트의합계에대한변경혹은리포트나스크린에서표제가대치되는것과 같은사용자인터페이스에표면적인변경이행해진다. DET 이름의변경은트랜잭션의변경으로간주되지않는다. 만일 DET의이름만 변경되면 다. DET 의속성은변경되지않는다. 트랜잭션변경에대한유지보수기능점수규모는다음의 4 단계를통해계산된 1 트랜잭션에의해이용된 DET와 FTR을식별 변경된트랜잭션기능의유지보수기능점수는변경이후의기능점수와변경영 향인자로부터계산된다. 영향인자는트랜잭션에의해이용된 DET와 FTR의변 경비율에의해결정된다. 만일변경이표면적인것이라면, 그러한변경의영향은최소한으로고려되고영 향인자의값이 0.25 라는것은상대적으로낮은영향을반영한다. 2 유지보수의결과로변경된 DET와 FTR의비율을결정 영향인자는트랜잭션에의해이용된 DET와 FTR을원래의 DET와 FTR과비 교한변경비율로결정된다. - 32 -
DET 비율 = 추가 / 변경 / 삭제된 DET 의수 100 원래트랜잭션의 DET 의수 FTR 비율 = 추가 / 변경 / 삭제된 FTR 의수 100 원래트랜잭션의 FTR 의수 DET와 FTR이트랜잭션에추가될때 100% 를넘는변경이가능하다. 3 트랜잭션에관한영향인자를결정 트랜잭션에관한영향인자 (I CHANGED ) 는 < 표 2-3> 에서 DET와 FTR의변경비율 로부터결정된다. < 표 2-3> 트랜잭션기능의영향인자 DET 비율 FTR 변경비율 67% 100% >100% 33% 0.25 0.50 0.70 67% 0.50 0.75 1.00 100% 0.75 1.00 1.25 >100% 1.00 1.25 1.50 만일영향인자가 1.00 이상이면, 유지보수를기존기능의삭제와새로운대치기 능의추가로취급하는것이더욱적절하다. 4 유지보수기능점수를계산 트랜잭션기능의미조정된유지보수기능점수규모는다음과같이계산된다. UEFP CHANGED = UFP CHANGED I CHANGED 6) 유지보수프로젝트의규모를계산 유지보수프로젝트의 ( 미조정된) 규모는영향받는모든트랜잭션기능과데이터 - 33 -
기능에관한유지보수기능점수의합이다. UEFP PROJECT = UEFPADDED + UEFPCHANGED + UEFP DELETED 7) 값조정인자를적용하여유지보수프로젝트의조정된기능점수규모를계산 값조정인자 적용할 (VAF) 를적용하기원하는조직에서는유지보수프로젝트규모에 14 개의시스템특성이유지보수된시스템에관해재평가되어야한다. 유지보수이후의값조정인자 (VAF AFTER ) 는추가되고변경된기능에적용되고 유지보수이전의값조정인자 (VAF BEFORE ) 는삭제된기능에적용된다. EFP PROJECT = UEFPADDED VAF AFTER + UEFPCHANGED VAF AFTER + UEFPDELETED VAF BEFORE 8) 유지보수이후의시스템의규모를계산 시스템의규모는유지보수의결과로변경될수있다. 유지보수이후의규모는전체어플리케이션을새로분석하거나원래의기능점수에변경을고려하여계산될수있는데, 다음의단계를따른다. 1 표준기능점수기법을이용하여변경이전의어플리케이션의미조정된기능 점수 (UFP BEFORE ) 를계산한다. 2 기존어플리케이션으로부터삭제된트랜잭션기능과데이터기능을식별하고 그들의기능점수 (UFP DELETED ) 를계산한다. 3 변경된트랜잭션기능과데이터기능을식별한다. 유지보수이전과이후에이 들의기능점수 (UFP AFTER 와 UFP BEFORE ) 를계산한다. 4 시스템에추가된트랜잭션기능과데이터기능을식별하고이들의기능점수 (UFP ADDED ) 를계산한다. 5 유지보수이후시스템의값조정인자 (VAFAFTER) 를계산한다. 6 유지보수이후의시스템규모 (UFPAFTER) 를계산한다. - 34 -
유지보수이후의시스템의규모를미조정된기능점수로나타내면다음과같다. UFP AFTER = UFP BEFORE + ( UFPADDED + UFPAFTER CHANGE) - ( UFPBEFORE CHANGE + UFP DELETED) 유지보수이후의시스템의조정된기능점수규모는다음과같다. FP AFTER = UFP AFTER VAF AFTER 2.3 소프트웨어유지보수비용산정모델 2.3.1 COCOMO 81 모델 COCOMO 81 모델[5] 에서소프트웨어유지보수란기존에운영중인소프트웨어의기본적인기능을유지한채수정하는프로세스로정의된다. 이정의는소프트웨어유지보수의범주에서다음유형의작업을제외한다. 실제로동일한기능을수행하는새로운소프트웨어제품의주요재설계와재개 발(50% 이상의새로운코드) 기존제품의재설계를요구하지않는인터페이스소프트웨어패키지( 기존제품 의소스코드 20% 이상) 의설계와개발 데이터베이스의값들을처리, 데이터입력, 수정하는데이터베이스관리시스 템자체의수정 따라서소프트웨어유지보수에는다음유형의작업이포함된다. 기존소프트웨어제품의작은부분의재설계와재개발 기존소프트웨어제품의부분적인재설계를요구하는소규모인터페이스소프 트웨어패키지의설계와개발 소프트웨어제품의코드, 문서, 혹은데이터베이스구조의수정 - 35 -
소프트웨어유지보수는두가지주요범주로구분될수있다. 1 2 소프트웨어제품의기능명세를변경시키는소프트웨어 기능명세를그대로유지하는소프트웨어정정 (repair) 갱신 (update) 소프트웨어정정(repair) 은세가지범주로분류될수있다. a b c 오류교정유지보수 ( 처리, 성능, 혹은구현결함의수정) 환경적응유지보수 기능개선유지보수 ( 처리나데이터환경의변경) ( 성능이나유지보수성의향상) 이러한범주에드는모든노력이 COCOMO 유지보수모델에의해산정된다. COCOMO 개발모델에관한모든가정이대부분유지보수모델에적용된다. 유지 보수비용산정은유지보수동안수행되는요구분석작업의비용산정을포함한 다. 따라서 WBS의계층구조에서소프트웨어유지보수작업은데이터베이스관 리(administration) 를제외한모든작업을포함한다. COCOMO 유지보수모델의기본적인가정은소프트웨어유지보수비용이소프 트웨어개발비용을결정하는동일한비용요인속성들에의해마찬가지로결정된 다는것이다. 소프트웨어유지보수를위한제품크기를결정하는데이용되는양을 Annual Change Traffic(ACT) 이라고하는데, 변경되는소프트웨어제품의소스코드의비율이다. 이는일년동안추가나수정을통해 만일유지보수를위한모든비용요인속성이개발과동일하다면, 년간유지보수 비용은다음과같이산정된다. (MM) AM = (1.0)(ACT)(MM) DEV 그러나 Intermediate COCOMO와 Detailed COCOMO에서산정은다음두가지 이유로수정될수있다. 1 유지보수를위한비용요인속성과개발을위한비용요인속성의등급이다 를수있다. ( 예를들어학습효과, 이직등) 2 RELY와 MODP 수를가진다. 비용요인속성이유지보수에관해개발과상이한노력승 - 36 -
두가지비용요인인 RELY와 MODP는개발단계와유지보수단계에서상대적 인영향의차이를나타내는생산성승수를가진다. RELY( 요구되는소프트웨어신 뢰도) 의경우, 비용요인의등급은개발과유지보수에서모두동일한것으로가정 된다. < 표 2-4> 는두가지의미를가진다. < 표 2-4> 소프트웨어개발/ 유지보수노력보정계수 Product Attributes Cost Driver Very Low Nom Low inal High Very High Extra High ( 개발시)Required software reliability ( 유지보수시)Required software reliability Data base size Product complexity Computer Attributes Execution time constraint Main storage constraint Virtual machine volatility Computer turnaround time Personnel Attributes Analyst capability Applications experience Programmer capability Virtual machine experience Programming Language experience Project Attributes ( 개발시)Use of modern programming practices ( 유지보수시)Use of modern programming practices Use of software tools Required development schedule 0.75 1.35 0.70 1.46 1.29 1.42 1.21 1.14 1.24 1.45 1.24 1.23 0.88 1.15 0.94 0.85 0.87 0.87 1.19 1.13 1.17 1.10 1.07 1.10 1.20 1.10 1.08 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.15 0.98 1.08 1.15 1.11 1.06 1.15 1.07 0.86 0.91 0.86 0.90 0.95 0.91 0.84 0.91 1.04 1.40 1.10 1.16 1.30 1.30 1.21 1.30 1.15 0.86 0.91 0.86 0.90 0.95 0.82 0.70 0.91 1.04 1.65 1.66 1.56 1 요구되는신뢰도가낮을수록, 요구되는수준을유지하는데더적은노력이 요구된다. 2 요구되는신뢰도가낮을수록, 소프트웨어에잠재된결함을수정하고, 부정확 한문서와코드를가진소프트웨어제품을갱신하는데더많은노력이요구된다. 개발과유지보수동안현대적프로그래밍실제(MPP) ( 구조적코드, 하향식설계 와개발, 검토회, 프로그램지원라이브러리, 문서화) 의사용효과는소프트웨어유 - 37 -
지보수의수준에두가지측면에서영향을미친다. 1 2 더많은 MPP 가이용될수록, 유지보수노력이더욱절감된다. 더많은 MPP 가이용될수록, 소규모의제품에필요한효율성의정도로대형 제품을쉽게유지보수할수있다. 다시말하면, 소프트웨어신뢰도의투자가증가하고소프트웨어개발동안현대 적 프로그래밍 기법의 사용이 유지보수 동안 커다란 이익이 되었다는 사실을 COCOMO 81 유지보수비용산정모델은반영한다. 그러한경우에조정된승수들 이원래의개발승수들을대치하고, 유지보수노력조정인자 (EAF) M 가노력승수 들의곱으로계산된다. (MM) AM = (1.0)(ACT)(MM) NOM(EAF) M 여기에서 (MM) NOM 은소프트웨어제품의전체 KDSI 의함수로명목(nominal) 노 력방정식으로부터계산된다. (MM) NOM = 3.2 (KDSI) 1.05 (Organic mode) = 3.0 (KDSI) 1.12 (Semidetached mode) = 2.8 (KDSI) 1.20 (Embedded mode) ACT 는전체시스템에서동일하거나혹은컴포넌트( 혹은서브시스템이나모듈) 별 로상이하여 (MM) AM 을구하는위의식을 유지보수산정값을결정하기위해그결과를더한다. N개의컴포넌트각각에적용하여전체 (MM AM ) i = (ACT) i (MM NOM ) i (EAF) i (MM)AM = N i = 1 (MM AM ) i Basic COCOMO와 Intermediate COCOMO에관한 COCOMO 유지보수산정식 의적용예는다음과같다. Detailed COCOMO에관한절차는 Intermediate COCOMO 와동일한절차를따른다. 예를들어, 32 KDSI의소프트웨어제품이 1년간의유지보수기간동안 4000 DSI 가추가되고 2400 DSI 가수정된다고가정하자. - 38 -
ACT = 4000+2400 32,000 = 6400 32,000 = 0.20 개발비용의산정값이 (MM) D 로주어지면, 기본적인년간유지보수비용 (MM) AM 의산정값은다음식으로계산된다. (MM) AM = 1.0 (ACT) (MM) D 전일제인력(FSP) 이년간 12 MM 만큼필요하므로, 유지보수를위해필요한 FSP 인 (FSP) M 를다음과같이쉽게계산할수있다. (FSP) M = (MM) AM /12 예를들어, ACT가 0.20인 302 KDSI의소프트웨어제품의유지보수를고려해보 자. 개발비용이 91 MM 라면, 유지보수기간첫해동안의유지보수비용은다음과 같다. (MM)AM = (0.2) (91) = 18 MM 그리고유지보수를위해필요한 FSP 의수는다음과같다. 18/12 = 1.5 FSP Intermediate COCOMO 의노력승수들도개발단계와마찬가지로유지보수단계 에적용될수있다. 비용요인대부분이유지보수단계와개발단계에서모두동일 하다고가정할수있다. 비용요인중의하나인 SCED( 요구되는개발일정) 는개발 동안의인자이다. 소프트웨어의일부가상이한일정에개발되었다는사실이그소 프트웨어를유지보수하는데필요한노력에차이를유발하지않는다. 따라서 SCED 노력승수는유지보수단계동안 1.00 으로조정된다. 2.3.2 COCOMO Ⅱ 모델 - 39 -
소프트웨어유지보수는기본적인기능은변경하지않고기존소프트웨어를수정 하는과정으로정의된다. COCOMO II 모델[6] 의기본적인가정은 COCOMO 81과 마찬가지로소프트웨어유지보수비용이일반적으로소프트웨어개발비용과동일한 비용요인을가진다는것이다. 유지보수는원래제품의작은부분의재설계와재코 딩, 인터페이스의재설계와재개발, 그리고제품구조의작은수정을포함한다. 유 지보수는갱신혹은수리(repair) 로정의될수있다. 제품수리는오류교정, 환경적 응, 혹은기능개선유지보수로구분될수있다. COCOMO II는수정되는제품의크기에 COCOMO 81의모드를적용하는것이 아니라수정된코드의크기에 COCOMO II 스케일인자를적용하는면에서 COCOMO 81 과상이하다. 소프트웨어유지보수의범위는 COCOMO 81의지침을따르므로새로운기능을 추가하고기존의기능을수정하거나확장하는것을포함한다. 여기에는기존소프 트웨어의 50% 이상을변경하는것과기존시스템의재작업이없는시스템의인터 페이스의개발(20 % 이상의변경) 인재구축은배제한다. 유지보수규모는기본적으로다음식으로계산된다. (Size) M = [(Base Code Size) MCF] MAF 베이스코드에대한변경비율을유지보수변경인자 (Maintenance Change Factor: MCF) 라고부른다. MCF는 1년이상의유지보수기간이이용된다는것을 제외하고는 COCOMO 81의 Annual Change Traffic 과유사하다. MCF는다음식으 로나타낼수있다. MCF = Size Added+ Size Modified Base Code Size 유지보수기간동안기존의베이스코드에추가되거나수정되는코드의부분을알고있을때더간단한형식으로표현할수있다. 삭제된코드는계산되지않는다. (Size)M = (Size Added + Size Modified) MAF 규모는 KSLOC, 기능점수, 객체점수[7] 를말한다. 기능점수나객체점수가사 용될때변경에의해영향받는입력, 출력, 스크린, 리포트등의부분보다는변경 되는전체어플리케이션의부분으로 MCF 를추정하는것이바람직하다. Boehm에 - 40 -
의하면변경에의해영향을받는항목들을계산하는것은비교적작은변경이상대 적으로많은항목들에영향을미침으로써과대추정을야기한다고한다 [6]. 다음식의유지보수조정인자(MAF) 는유지보수규모를조정하는데이용된다. COCOMO II 는소스코드의구조와이해용이성이유지보수에미치는영향을모델 링하기위해소프트웨어이해(SU) 와프로그래머비친숙(UNFM) 인자를이용한다. MAF = 1 + ( SU 100 UNFM) COCOMO II 를소프트웨어유지보수비용산정에이용하는데특별히고려해야할 것들이있다. 1 SCED( 요구되는개발일정) 비용요인은유지보수비용산정에이용되지않는 다. 그이유는유지보수사이클은대개고정된기간동안이기때문이다. 2 RUSE( 요구되는재사용성) 비용요인은유지보수비용산정에이용되지않는 다. 그이유는컴포넌트의재사용성을유지하는데필요한추가노력이컴포넌트의 신중한설계, 문서화, 테스팅으로인해유지보수노력을감소시켜개략적으로균형 을맞추기때문이다. 3 RELY( 요구되는소프트웨어신뢰도) 비용요인은유지보수의경우개발과상 이한노력승수를가진다. 유지보수의경우, RELY 비용요인은제품이개발된환 경에서요구되는신뢰도에좌우된다. 만일제품이낮은신뢰도를가지고개발되었 다면, 잠재적인결함을수정하기위한많은노력을요구할것이다. 만일제품이매 우높은신뢰도를가지고개발되었다면, 그수준의신뢰도를유지하기위해필요한 노력은보통이상이될것이다. 4 스케일링지수 E가전체레거시시스템의 KSLOC가아닌변경된 KSLOC의 값에적용된다. 유지보수비용산정식은 SCED와 RUSE를제외하고는 COCOMO II의 Post-Architecture 개발모델과동일하다. PM M = A (Size M) E 1 5 i = 1 E M i 소프트웨어유지보수비용산정을위한 COCOMO II 기법은임의의원하는작업 - 41 -
기간 TM을이용할수있는점에서 COCOMO 81의유지보수비용산정과상이하 다. 평균유지보수인력수준 FPSM 은다음식으로부터계산될수있다. FPSM = PM M/TM 2.3.3 현행소프트웨어용역유지보수대가기준 현행소프트웨어사업대가기준[8] 에서연간소프트웨어용역유지보수의대가는 유지보수계약시점에서의소프트웨어개발비산정가의 10 ~ 15% 범위내에서 < 표 2-5> 의용역유지보수대가산정기준에따라산정하며동일한소프트웨어를다 수의기관에서사용하는경우에는수발주자가상호협의하여용역유지보수대가를 조정할수있다고제시하고있다. [8] 의소프트웨어유지보수비용산정기준에서고려한요소는 (i) 유지보수횟수: 연간유지보수를실시하는횟수의정도, (ii) 자료처리건수: 처리하는자료의건수 의정도, (iii) 타시스템연계: 몇개의다른시스템과의연계가필요한지그정도, (iv) 실무지식필요: 업무에관한기초지식이나전문실무능력이필요한지의정도, (v) 분산처리여부: 통합하의분산처리인지순수분산처리인지를말한다. < 표 2-5> 용역유지보수대가산정기준 유지보수대상 시스템의특성 유지보수횟수 자료처리건수 단순보통복잡기준( 연간) 점수기준( 연간) 점수기준( 연간) 점수 4회이하 0 12회이하 20 12회초과 35 10만미만 0 10-50만 10 50만초과 25 타시스템연계없음 0 1-2시스템 5 3개이상 10 실무지식필요 별도지식 불필요 분산처리여부실시않음 0 0 기초지식 이해필요통합하의 분산처리 5 10 전문 실무능력필요 10 순수분산처리 20 이를바탕으로제시한소프트웨어유지보수비용산정모델은유지보수대상시스 템의특성별로단순, 보통, 복잡성을판단하여총점수(TMP: Total Maintenance Point) 를계산한다. - 42 -
연간유지보수비용 = 유지보수난이도(%) 총소프트웨어개발비 유지보수난이도 (%) = 10 + 5 TMP / 100 현행용역유지보수대가기준의문제점은다음과같이요약될수있다. 1 실제로유지보수되는소프트웨어의규모를고려하지않는다. 2 하한과상한값이규정되어범위를벗어나는경우에적용될수없는경직성이 존재한다. 3 소프트웨어유지보수를정확히정의하고있지않아, 실제현장에서수주자와 발주자간에혼란이야기된다. 4 유지보수대상시스템을기술하는항목에대한정의가없어적용에많은모 호성이있다. 5 전체유지보수점수(TMP) 의산출근거가없어신뢰감을주지못한다. 6 유지보수계약시점에개발비산정시오류가있을경우, 용역유지보수대가기 준의오류와함께급격하게오류가증폭된다. 7 선진유지보수비용산정모델처럼개발비산정과의일관성이존재하지않는 다. 8 기준자체가실제프로젝트를대상으로유도되지않았고, 이론적인배경이부 재하며그동안실제의유지보수프로젝트를대상으로검증되지않았다. 2.3.4 Oman 모델 Oman 모델은소프트웨어유지보수비용산정에영향을미치거나결정하는속성 92 개를포함한다차원계층구조를형성하였다. 그리고이것을바탕으로소프트웨어 의유지보수비용을평가하는요소로사용했다 [1]. 이러한측정은계층구조의각차원과속성에대하여영향력을미치는가중치를 정의하고, 각계층의가중치합은 1 이라하였다. 그하위계층의속성중유지보수에 영향을미치는속성은 0과 1 사이의가중치로부여하여속성의측정값을곱했다. 소 프트웨어유지보수성에관한포괄적인계층구조는 < 그림 2-6> 과같고이를바탕으 로 < 그림 2-7> 과같은대상소프트웨어시스템의유지보수어려움의정도를평가 - 43 -
하기위해각속성들을열거하여세부계층구조를만들었다. 단, 계층구조의숫자는 [1] 에서이해를돕기위하여주관적인가중치를부여한것이다. 소프트웨어유지보수어려움의정도 Di 관리적인요소 WD1=0.2 운용환경 WD2=0.2 대상소프트웨어시스템 WD3=0.6 Aj 인적요소 WA1=0.5 공정요소 WA2=0.5 현재환경목표환경 WA1=0.5 WA2=0.5 성숙도 WA1=0.4 원시코드지원문서 WA2=0.4 WA3=0.2 < 그림 2-6> Oman 모델의포괄적인계층구조 연간소프트웨어유지보수비용 = 소프트웨어유지보수어려움의정도 소프트 웨어총개발비용 여기에서나이: 시스템운용기간을월단위로측정한값 규모: 주석을제외한 1,000단위의스텝수 안정성: 일정기간동안라인변화에대한비율 유지보수강도 : 시스템총운용시간에대한유지보수시간의비율 결함정도 : 일정기간동안총스텝수에대한결함스텝수의비율 - 44 -
Di 대상소프트웨어시스템 WD3=0.6 Aj 성숙도 WA1= 0.4 원시코드 WA2=0.4 지원문서 WA3=0.2 나이 W= 0.2 규모 W= 0.3 안정성 W= 0.1 유지보수강도 W=0.3 결함정도 W=0.1 제어구조 WA21=0.4 시스템구성성분 WA211=0.6 WA212=0.4 모듈성내포성복잡성응집력일관성 정보구조 WA22=0.4 코딩기술 WA23=0.2 문서화 WA31=0.5 시스템구성성분시스템구성성분 WA221=0.4 WA222=0.6 WA231=0.6 WA232=0.4 전역자료유형 전역자료구조 시스템결합도 지역자료유형 지역자료구조 자료결합도 전체프로수평간격그램형태 W= 0.5 W= 0.3 수직간격전체프로 W= 0.5 그램주석 W= 0.3 모듈구분 W= 0.2 서술성 W=0.4 구현성 W=0.3 완전성 W=0.3 물리성 WA32=0.5 가독성 W=0.6 변경성 W=0.4 심볼사용 W=0.2 < 그림 2-7> 대상소프트웨어유지보수성평가를위한계층구조 Oman 모델에서는 < 그림 2-6> 및 < 그림 2-7> 의계층구조를바탕으로아래의 식을만들었다. 유지보수어려움의정도 = m i = 1 W Di ( n W Aj M Aj j= 1 n ) 여기에서 WDi: Di WAj: Aj MAj: Aj 차원의부여한유지보수가중치 속성의부여한유지보수가중치 속성의측정된유지보수값 2.3.5 기타소프트웨어유지보수비용산정모델 그외에관련문헌에서언급된대표적인소프트웨어유지보수비용산정모델을 요약하면다음과같다 [9]. - 45 -
1 Perfective Maintenance Estimation 모델[10] Vianney Cote와 Denis St-Pieerre가제안한모델 E = ( MFPi MAIN i KNOW i) TCF EF SCP - MFP i = UFP i w i (i가 add이면 1.00, mod 0.80, sup 0.33, unt 0.06) 가중치는전문가들의델파이기법으로결정 - MAIN은 maintainability factor Max. favorable: 0.76, 0.76, 0.84, 0.88 Max. unfavorable: 1.54, 1.58, 1.40, 1.27 - KNOW는분석가와프로그래머의 knowledge level factor KNOW i = A_KNOW i P_KNOW i 최근 3(2, 1, 0) 년간 12(6, 3, 0) 개월이상의경험 A1: 0.73, 0.69, 0.71, 0.72 - EF 는개발과유지보수에공통적인생산성요인 - SCP는 Standard Cost per FP 특징: 개발과유지보수의 TCF가동일 단위 FP 당비용을유지보수 FP에적용하여유지보수비용을구함 등 2 기능점수기반의 SMPEEM 모델[11] 안연식, 김현수등이제안한가장최근의유지보수비용산정모델 새로운 VAF를유도하여 UFP에적용한후 FP 계산 - Engineer's skill Knowledge of application domain Familiarity with programming language Experience with system software - Technical characteristics Structuredness of software modules Independence between software modules Changeability/readability of programming language Reusability of legacy software modules - Maintenance environment Up-to-dateness of documentation Conformity with software engineering standard Testability - VAF = [ (scores w f/100) (w g/100)] - 46 -
- FP = FC {0.80 + (0.008 VAF)} 유지보수비용 E = a(fp) b = 0.054(FP) 1.353 3 COSMIC-FFP 기반의유지보수비용산정모델[12] Alain Abran, Ilionar Silvar, Laura Primera 동일한특성의프로젝트를대상 - 15 등이제안한모델 언어학분야의응용을위한인터넷기반소프트웨어프로그램에관한 개의유지보수프로젝트 - 국방분야의실시간임베디드소프트웨어프로그램에관한 19개의유 지보수프로젝트 인력의경험과프로젝트의난이도를각각반영하는 3 수준인자적용 평균단위비용모델과회귀모형( 단순회귀모형과다중회귀모형) 제시 다른유형의대규모프로젝트에적용하는추가연구필요 4 Maintainability Index 모델[13] COCOMO 기반의 Maintainability index 적용모델 Juan Carlos, Granja-Alvares, Manuel Jose Barranco-Garcia 단계 1) Maintainability 척도설정 등이제안 2) 설정된척도와 index와의관계를가지는 maintainability 함수유도 MMMAIN = MM U + MM M + MM T = ACT MM DEV (I U + I M + I T) Maintainability index 의적용 - I U = F U(X U) : X U 는 understandability metric - I M = F M(X M) : X M 은 modifiability metric - I T = FT(X T ) : X T 는 testability metric - 이전프로젝트의이력데이터로부터유도 본연구에반영하기힘들고, 실제데이터로입증이어려운이론적인연구 5 Estimation by Analogy 기법을적용한모델[14] Hareton K. N. Leung 이제안한모델 배경 - 인공신경망, 사례기반추론, rule induction 등의다양한기계학습기법 이현재소프트웨어비용산정에적용됨 - 47 -
AVN(Analogy with Virtual Neighbor) 기법: CBR의개선된형식 - cost drivers: #input, #output, #inquiry, #update, #int-itf, #ext-itf Simple: 1~9 objects Medium: 10~39 objects Complex: 40 objects - cost drivers 와비용간의관계를회귀분석으로직접유도 Skills와 expertise - 요인은포함시키지않음 낮은이직율을가지는개발팀이그대로유지보수하기때문 개발비용산정에적용된기법을유지보수비용산정에그대로적용하는것 을전제로함 - 개발과유지보수는동일한생산성요인을가지는것을전제로함 6 기타모델 Jorgensen 은규모, 원인, 변경, 모드, 자신감등의요소를이용하여유지보 수비용을예측 [15] 유성열등의연구에서는유지보수자의경력수준, 관리자가정의한숙련도, 유지보수의유형, 요구되는신뢰도등으로유지보수노력을결정[16] 2.3.6 공기업 A의소프트웨어유지보수비용산정기준 국내의 SI 업체에서소프트웨어유지보수만별도로비용을산출하는경우는드물 고거의대부분하드웨어및전체시스템의유지보수비용을함께산출하거나정보 시스템운영사업의일환으로처리하고있다. 그마저도이러한계약시에사용하는 비용산출방식이대외비로분류되어공개되지않으므로, 본연구에서이들을소개 하기는어렵다. 따라서여기서는기존의연구에서제한적으로공개된공기업의비용산출사례를 소개한다. 국내의대표적인공기업 A에서사용하고있는정보시스템외주위탁비용 산정기준을소개하면 < 표 2-6> 과같다[3]. - 48 -
< 표 2-6> 소프트웨어유지보수관련대가산정기준( 예) 구분항목산정방법산정기준 소프트웨어유지보수 소프트웨어일상운영 전산기운전비 전산입출력자료처리비 직접인건비 제 경 비 기 술 료 직접인건비 제 경 비 기 술 료 직접인건비 제 경 비 기 술 료 재료비 직접인건비 제 경 비 이 윤 총스텝수 : 유지보수본수 유지보수총스텝수 유지보수율 보정후스텝당인건비 440Steps 유지보수율 : 용역결과보고서 직접인건비 110 기준 ( 직접인건비+ 제경비) 15% 보정후스텝당시기준 인건비 : 정부고 운용스텝수 유지보수율 운영비율 보정후스텝당인건비 직접인건비 110 ( 직접인건비+ 제경비) 15% 운영비율준 : 용역결과보고서 기 소요공수 소프트웨어사업대가기 소요공수: 투입인력기준준노임단가 소프트웨어사업대가기준노임 직접인건비 110 단가 ( 직접인건비+ 제경비) 15% 재료비 100% 전년도집행실적기준 소요공수 소프트웨어사업대가기 소요공수 : 용역결과보고서기준노임단가준 직접인건비 52.6% 용역결과보고서 ( 직접인건비+ 제경비) 10% 기타인력지원 직접인건비 제 경 비 기 술 료 소요공수 소프트웨어사업대가기준노임단가 소요공수: 투입인력기준 직접인건비 110 ( 직접인건비+ 제경비) 15% 2.4 소프트웨어유지보수생산성요소 유지보수의성패는유지보수단계의활동에달려있는것이아니라산출물이정의 되고개발되는단계에서부터얼마나많이유지보수에관련된사항을고려하였는가 에달려있다. 즉, 이해하기쉽고, 수정하기가용이하며, 모듈화가잘되어있고, 독립 성이우수하도록하는것과같이유지보수를고려하여모든산출물이만들어졌다 면유지보수는그만큼쉬워질것이며, 유지보수비용도절감할수있을것이다. 일반적으로유지보수비용을산정하기어려운이유는비용이소프트웨어생산성 에관련된다수의제품, 프로세스, 조직의요인들과관련이되기때문이다. 대부분 의비용산정모델들은소프트웨어유지보수의생산성요인을소프트웨어개발의생 산성요인과구분하지않는다. 그러나소프트웨어유지보수생산성요인은개념적 으로소프트웨어개발의생산성요인과상이한특성이일부있다. - 49 -
중요한유지보수비용요인은규모, 나이, 복잡도와관련이있다. Sommerville은 소프트웨어유지보수환경과관련된생산성요인이모듈독립성, 프로그래밍언어, 프로그래밍스타일등과같은특성을포함한다고했다 [11]. 1985년에 Software Productivity Research(SPR) 는기능점수를계산하는새로운 방법을제안했다. 복잡도를처리하는 SPR 기법은전체적인복잡도를문제복잡도, 코드복잡도, 데이터복잡도로구분했다. 이방식에서계산을위한노력은감소된 다. Belady 등은유지보수노력을앞에서기술한생산성노력, 소프트웨어설계와문 서화의복잡도, 소프트웨어에대해친숙한정도로고려했다 Jorgensen의비용산정 모델에서는작업의원인, 코드의변경정도, 코드의운영형태, 유지보수자의신뢰 와같은변수를포함한다. [11] 의실무자에대한설문조사에서는기술적요인( 응답 시간, 보안성, 사용자의수, 플랫폼), 유지보수도구와기술( 개발방법론 CASE 도 구), 사람에관련된요인( 프로그래머의수, 경험) 이도출되었으나, 유지보수비용산 정모델에그대로적용될수없다. 2.4.1 국방정보체계소프트웨어유지보수생산성요소 일반적으로볼때유지보수의성패는유지보수단계의활동에달려있는것이아니 라산출물이정의되고개발되는단계에서부터얼마나많이유지보수에관련된사항을 고려하였는가에달려있다고해도과언이아닐것이다[1]. 즉, 일반적으로단순하게생 각하면이해하기쉽고, 수정하기가용이하며, 모듈화가잘되어있고, 독립성이우수하 도록하는것과같이유지보수를고려하여모든산출물이만들어졌다면유지보수는 그만큼쉬워질것이며, 유지보수비용도절감할수있을것이다. 그러나실제적으로이 들요소들과소프트웨어유지보수비용과의연관성을규명하기가어려운일이고, 실제 로유지보수비용과의유의한수준의관련성이연구되지않았다. [1] 에서는소프트웨어 유지보수비용에영향을미치는요소중에서국방정보체계의소프트웨어유지보수비 용에영향을미치는요소를식별하여, 분석/ 설계, 구현, 시험으로구분하여각각에영향 을미치는요소별로그룹화하여제시하였다. - 50 -
유지보수산정영향그룹요소 TMP1( 분석 / 설계 ) W=0.53 TMP2( 구현 ) W=0.19 TMP3( 시험 ) W=0.28 목적에의한분류요소 (50) 기존소프트웨어구조와수정방법요소 (30) 기능 / 성능요소 (40) 환경적응유지보수 (10) 기능개선유지보수 (30) 하자유지보수 (10) 복잡성요소 (25) 복잡도 (5) 모듈독립성 (2) 스텝수 (8) 프로그래밍스타일 (1) 무모순성 (1) 스텝당인건비단가 (4) 공정별스텝당인건비단가 (4) 소프트웨어환경요소 (5) 수명 ( 나이 )(1) 운용환경 (H/W,S/W) 변화정도 (2) 자동화도구사용 (1) 유지보수횟수 (1) 문서화요소 (5) 비구조적인코드를수정하여유지보수 (30) 구조적인코드를수정하여유지보수 (25) 구조적 / 비구조적코드에독립모듈을추가하여유지보수 (20) 소프트웨어용도요소 (20) 지휘. 통제통신용 (20) 자원관리용 (17) 정보화기반체계용 (14) 프로그래밍요소 (20) 프로그래밍언어유형 (8) 프로그래밍언어의제어구조 (6) 프로그램모듈의평균크기 (3) 모듈에서호출되는평균모듈수 (3) 소프트웨어주변기능요소 (15) 분산처리 (2) 응답시간 ( 실시간성 )(2) 반환시간 (2) 처리량 (2) 완전성 (2) 이해용이성 (2) 이용률 (2) 처리복잡성 (2) 대화형처리 (1) 이식성 (2) 모듈이용성 (2) 실행효율성 (2) 기억장치효율성 (2) 신뢰성 (2) 보안성 (2) 상호운용성 (2) 운용성 (2) 가용성 (2) 감리증적 (1) 정확성 (2) 모듈내포성 (2) 소프트웨어유지보수용이성요소 (30) 프로젝트계획및감독 (1) 요구분석 (1) 설계 (1) 자격시험 (1) 소프트웨어사용에대한준비 (0.5) 소프트웨어전환준비 (0.5) 정보처리형태요소 (5) 배치처리 (2) 온라인처리 (3) 실시간처리 (5) 유지보수주체요소 (5) 개발업체유지보수 (3) 비개발업체유지보수 (5) 시간에의한분류요소 (5) 입력 (4) 출력 (4) 타시스템연계 (7) 대상에의한분류요소 (15) 데이터보수 (5) 프로그램보수 (6) 문서보수 (4) 시험용이성 (8) 엑세스가능성 (2) 일관성 (2) 전달공통성 (2) 추적가능성 (2) 사용자 (3) 지식 / 의욕 (1) 시스템이해 (2) 이해용이성 (8) 수정용이성 (8) 간결성 (2) 구조성 (2) 자기기술성 (2) 수정성 (2) 모듈성 (2) 표준성 (2) 문서화 (2) 유연성 (2) 융통성 (6) 재사용성 (2) 장치독립성 (1) 범용성 (1) 확장성 (2) 인적요소 (20) 유지보수자 (11) 유지보수조직 (3) 개발자 / 개발조직 (3) 근무기간 (1) 개발참여 (3) 인력등급 (1) 학력 (1) 경험수준 (3) P/L 경험 (1) 유지보수전담조직 (2) 유지보수조직의업무중복 (1) 개발경험 (1) 개발인력등급 (1) 개발전담조직 (1) 대상기기운영체제경험 (1) 관리및제도적인요소 (10) 응급보수 (5) 지연보수 (3) 계획보수 (4) 유지보수주관기관수준 (2) 사용자교육기회정도 (2) 인사이동 (2) 유지보수평가회의 (2) 사용자의의견수렴 / 전파 (2) ( ) : 그룹요소및세부영향요소의최고점수 < 그림 2-8> 국방정보체계소프트웨어유지보수생산성요소[1] - 51 -
2.4.2 SPR 의소프트웨어유지보수생산성요소 오래전에개발된레거시소프트웨어의유지보수는매우노동집약적인작업이므 로현재존재하는수많은어플리케이션들의유지보수에가장효과적인최선의방법 을연구하는것이매우중요하다. Capers Jones에의하면유지보수에긍정적인영 향을주는요소와부정적인영향을주는요소가서로간에대칭적인것은아니라고 한다. 예를들어, 유지보수생산성에가장긍정적인영향을주는생산성요소가훈 련된유지보수전문가의활용인반면에가장부정적인요소는유지보수중인어플 리케이션에있는 에러유발모듈(error-prone module) 의존재라는것이다. < 표 2-7> 은어플리케이션의유지보수에긍정적인영향을미치는생산성요소들 과이들의생산성향상비율을평균값과비교한것이다 [17]. < 표 2-7> 긍정적인생산성요소 생산성요소 영향 유지보수전문가 35% 높은수준의경험 34% 테이블중심의변수와데이터 33% 소스코드의낮은복잡도 32% Y2K 검색엔진 30% 코드재구조화도구 29% 재공학도구 27% 고급프로그래밍언어 25% 역공학도구 23% 복잡도분석도구 20% 결함추적도구 20% Y2K 전문가 20% 자동화된변경관리도구 18% 급여를받지않는초과근무 18% 품질측정 16% 정형화된소스코드인스펙션 15% 회귀시험라이브러리 15% 빠른응답시간 12% 년간 10일이상의교육 12% 높은수준의관리경험 12% 헬프데스크자동화 12% 에러유발모듈의부재 10% 온라인결함보고 10% 생산성측정 8% 뛰어난사용용이성 7% 사용자만족도측정 5% 높은팀사기 5% 합 503% - 52 -
Capers Jones 는기존어플리케이션을갱신하거나수정하는데부정적인영향을 끼치는생산성요소들을제시했다. 유지보수생산성을낮추는가장부정적인요소 는에러유발모듈의존재이다. 에러유발모듈의부재가유지보수작업의속도를 향상시키지는않지만에러유발모듈의존재는유지보수작업의속도를낮추는결 정적인요인이다. < 표 2-8> 은소프트웨어유지보수에부정적인영향을미치는생산성요소들을정 리한것이다[17]. 에러유발모듈의존재외에도많은요인들이유지보수에부정적 이다. 예를들어, 매우복잡한스파게티코드를안전하게유지보수하기란극히어려 운일이다. 또한유지보수작업을훈련된전문가가아닌일반인에게맡긴다는것은 문제를유발하게된다. < 표 2-8> 부정적인생산성요소 생산성요소 영향 에러유발모듈 -50% 임베디드변수와데이터 -45% 무경험 -40% 소스코드의높은복잡도 -30% Y2K 검색엔진의부재 -28% 수작업에의한변경관리도구 -27% 저수준프로그래밍언어 -25% 결함추적도구의부재 -24% Y2K 점문가의부재 -22% 낮은수준의사용용이성 -18% 품질측정의부재 -18% 유지보수전문가의부재 -18% 늦은응답시간 -16% 관리의무경험 -15% 소스코드인스펙션의부재 -15% 회귀시험라이브러리의부재 -15% 헬프데스크자동화의부재 -15% 온라인결함보고의부재 -12% 년간교육의부재 -10% 코드재구조화도구의부재 -10% 재공학도구의부재 -10% 역공학도구의부재 -10% 복잡도분석도구의부재 -10% 생산성측정부재 -7% 낮은팀사기 -6% 사용자만족도측정의부재 -4% 급여를받지않는초과근무부재 0% 합 -500% - 53 -
2.4.3 연간유지보수비용요인(cost driver) 에관한사례연구 어플리케이션의생명주기동안더욱많은비용이소프트웨어개발보다소프트웨어유지보수에소모된다. 그러나연간소프트웨어유지보수비용에영향을주는요인들에대해거의알려지지않았다. 여기에서는소프트웨어유지보수비용요인들을결정하기위해소프트웨어유지보수데이터베이스[21] 를분석한다. 1) 배경 만일유지보수비용을측정하지않고관리하지않으면, 유지보수비용은필요이 상으로증가할것이다. 연간유지보수비용의예산편성을개선하기위해, 유지보수 제공자와어플리케이션의소유자는실제비용, 규모, 운영햇수, 결함, 위험요인등 을포함하는방대한양의데이터를수집했다[21]. 이데이터의분석은수집된어떤 데이터가유지보수비용에실제영향을주었는가를결정하는데유용하다. 2) 데이터 유지보수규모는초기에명령문으로측정되었다. 이에상응한기능점수는 Capers Jones의 Backfiring value 표를이용하여계산되었다. 각언어에대한기능점수는 전체기능점수를구하기위해결합되었다. 어플리케이션의규모는매년일정시간 에결정되고그해의어플리케이션의평균규모를나타낸다. 운영비용은어플리케이션을계속운영하기에필요한변경비용으로정의된다. 여기에는버그수정, 레이아웃을개선하기위해새로운특성을구현하고시험하는 것과같은매우쉬운기술적인개선, 환경이변경될때의어플리케이션의적응등 을포함한다. 여기에서운영비용에는어플리케이션을실행( 매개변수변경, 입력수 리, 데이터전송인터페이스제어) 하는데필요한일일노력이나고객을위한어플 리케이션의확장이나수정에필요한노력이포함되지않는다. 결함데이터는매우주의깊게수집되었다. 모든결함은어플리케이션설계, 매개 변수데이터, 연산자, 데이터통신, 장치등의유형과사소한것에서부터매우심각 한것까지의 5 개의범주로구분되고기록되었다. 모든실행시간결함은결함추적 시스템에의해기록되고최종사용자에의해탐지되는모든논리적인에러는담당 - 54 -
자나헬프데스크직원에의해기록되었다. 기록된모든결함의 8% 는설계결함이 다. 설계결함은요구명세단계동안발생한결함으로정의되었다. 3) 연간운영비용 연간운영비용에가장큰영향을주는변수는어플리케이션의규모이다. 연간 운영비용은어플리케이션규모가커짐에따라증가한다. 규모다음으로중요한변 수는어플리케이션구조이다. 증권거래시스템은기능점수당가장높은운영비 용을요구했는데이시스템들은완전히통합된대형일괄처리시스템이었다. 어플리케이션이유지보수되는개월수가연간운영비용에커다란영향을준다. 오래된어플리케이션이더적은운영비용이드는것으로나타났다. 아래의식은 연간운영비용과어플리케이션의운영햇수간의관계를나타낸다. 연간운영비용 은상수에 나이승수(age multiplier) 를곱한것과같으므로, 나이에종속되는지 수함수이다. 이나이승수는어플리케이션이유지보수단계에들어가면 1이고그 이후감소된다. effort = ke -0.0157 age 경영학, 경제학, 과학에서대상물의성장과소멸의비율을표현하기위해서는일 반적으로시간에종속되는지수함수가이용된다. 이경우에, 나이와노력사이에 발견한관계는 carbon 14와같은원소의자연붕괴비율을계산하는데이용되는식 과매우유사하고, 나이승수를 소프트웨어유지보수감소비율 로생각할수있 다. 사례연구[21] 에서연간운영비용은연간대략 17.2% 의비율로감소함을발견했 다. 따라서유지보수를하는첫해에연간유지보수노력이 100 시간이필요한어 플리케이션은그다음해에 82.8 시간, 그다음해에 68.6 시간이필요함을예상할 수있다. 연간운영비용의추가적인변동을설명하는다른변수는없다. 설계결함변수 가다중변수모형에나타나지않는다는것은설계결함이어플리케이션의규모와 상관관계가매우높기때문이다. 어플리케이션이크면클수록, 더욱많은설계결 함이존재한다. 따라서규모의효과가연간운영비용모델에더해지면, 설계결함 의수는더이상중요하지않다. 설계결함단독으로는노력의변동의 3.5% 를설명 하는반면에규모는단독으로변동의 27% 를설명한다. 규모는설계결함의수보다 노력에대한더욱중요한척도이다. - 55 -
2.4.4 기능점수와소프트웨어유지보수 1) 기능점수를적용한유지보수척도 1 유지보수성 (Maintainability) 유지보수성(Maintainability) 은어플리케이션을유지보수하는데필요한노력( 비용) 의척도로어플리케이션수준의유지보수비용을관리하는데이용된다. 핵심적인비즈니스어플리케이션이나높은유지보수비용을나타내는어플리케이션에주로적용된다. 다음과같이계산된다. 유지보수비용 / 어플리케이션의기능점수 일부유지보수작업은규모( 기능점수) 에직접적으로관련되지않는다. 아웃소싱 계약에서이범주의비용을종종제로기능점수유지보수라고부른다. 예를들어, 수정(repair) 유지보수는어떤새로운기능이나변경되는기능을생성하지않으므로 기능점수로측정될수없다. 그러나비용은수리를하는데기인한다. 조직은이러한 제로기능점수유지보수를설명하는정책을수립해야한다. 2 신뢰성 (Reliability) 신뢰성(Reliability) 은기능규모(functional size) 당어플리케이션의고장횟수의 척도이다. 이척도는시스템성능을추적하고어플리케이션에관련된가능한서비 스수준의척도를관리하는데이용될수있다. 다음과같이정의된다. 고장횟수 / 어플리케이션의전체기능점수 3 할당범위 (Assignment scope) 할당범위(Assignment scope) 는어플리케이션을유지보수하는데필요한전일제 (full-time equivalent) 자원수의척도이다. 이척도는유지보수중인어플리케이션을적절하게지원하는데필요한자원의수준을관리하기위해이용될수있다. 생 - 56 -
명주기동안어플리케이션의기능규모가증가함에따라어플리케이션을유지보수하는데필요한자원도증가할것으로예상된다. 이척도는때로는유지보수할당범위라고부른다. 다음과같이계산된다. 어플리케이션의전체기능점수 / 어플리케이션지원에필요한자원의수 4 성장비율 (Rate of growth) 성장비율(Rate of growth) 은규정된유지보수기간동안어플리케이션기능의 증가척도이다. 성장비율은어플리케이션의급격한성장을관리하거나, 역으로어 플리케이션이성숙수준에도달했거나성장비율이감소할때를판단하는수단으로 IT 부서에의해이용될수있다. 이척도는또한포트폴리오성장비율을관리하는 데이용될수있다. 성장비율은다음과같이계산된다. 현재의기능점수 / 원래의기능점수 5 포트폴리오규모 (Portfolio size) 포트폴리오규모(Portfolio size) 는조직의포트폴리오기능점수척도이다. 이척 도는예산설정목적혹은아웃소싱계약과결합하여종종이용된다. 조직의어플 리케이션개발과유지보수작업의아웃소싱은조직에서의어플리케이션의규모측 정을요구한다. 서비스수준은제3의벤더가제공하는서비스의기능점수의총수에 기반을둔다. 관한기능점수의총수이다. 포트폴리오규모는조직의포트폴리오에있는모든어플리케이션에 2) 유지보수아웃소싱의서비스수준척도 서비스수준의척도는주로공통적으로아웃소싱계약과관련된다. 이척도들은 소프트웨어서비스의외부제공자의성과(performance) 를측정하는수단으로설정 된다. 기능점수는어플리케이션개발과유지보수(AD/M) 서비스수준척도의설정 에중요한역할을한다. 기능점수가중요한역할을할수있는세가지전형적인 아웃소싱시나리오는단일프로젝트나어플리케이션, 어플리케이션유지보수, 전체 AD/M 환경의아웃소싱에대해존재한다[22]. - 57 -
제 3 장소프트웨어유지보수대가기준후보모형 3.1 ISO/IEC 12207 의소프트웨어유지보수공정 소프트웨어유지보수의목표는무결성을유지하면서현시스템을수정하는것 이다. 이공정은소프트웨어의전환과폐기를포함하며, 유지보수공정은소프트웨 어의폐기로종료된다. 유지보수업무의세부활동별입출력물의관계는 < 표 3-1> 과같이정의할수있다 [18]. < 표 3-1> ISO/IEC 12207 유지보수활동대결과물 5510 활동 (Activity) 공정구현 입력물 5520 문제및수정분석변경요청서 5530 수정실시 출력물 유지보수계획서 변경요청절차및변경요청 서 형상관리구현계획서관련시스템및산출물영향분석서( 문제검증포함) 분석결과서 수정구현계획서( 승인포함) 영향분석서변경대상상세분석서수정구현계획서시험및평가계획서변경대상시스템및산변경프로그램출물변경결과서 시험결과서 5540 5550 5560 기 변경결과서검토및승인시험결과서변경결과서변경프로그램전환표준문서구소프트웨어폐사용자교육계획서사용자지침서 수정완료승인서전환계획서사용자교육계획서운영후검토결과서구데이터관리계획서폐기계획서폐기결과서 - 58 -
3.1.1 공정구현(5510) 1) 유지보수공정계획수립유지보수담당자는유지보수공정의활동과세부업무를위한계획과절차를개발하고, 계획과절차를문서화하며실행해야한다. 2) 문제보고및수정요구처리절차수립 유지보수담당자는사용자로부터문제보고와수정요구사항을접수및추적하여 야한다. 또한사용자에게피드백을위한절차를수립하여야하며, 문제및수정요 구사항은기록관리하고문제해결공정으로넘겨야한다. 3) 형상관리공정구현수립유지보수담당자는현재시스템에대한수정요구사항및수정내역을관리하기위하여형상관리공정을수립해야한다. 3.1.2 문제및수정분석(5520) 1) 문제보고및수정요구영향분석유지보수담당자는아래사항을파악하기위하여문제및수정요구사항이조직, 현시스템및관련시스템에미치는영향을분석하여야한다. 유형 : 오류교정, 기능개선, 예방조치, 새로운환경적응 범위 : 수정량, 소요비용, 수정시간 중요성 : 예를들면, 처리성능, 안전, 보안에의영향 2) 문제재현또는검증유지보수담당자는수정을위하여수정요구사항에대하여재현하거나검증해야한다. 3) 수정구현대안문제보고및수정요구영향분석에근거하여유지보수담당자는수정구현을위한대안을고려하여야한다. - 59 -
4) 문제접수, 분석결과및구현안의문서화유지보수담당자는문제/ 수정요구, 그분석결과및구현안을문서화해야한다. 5) 수정안에대한승인유지보수담당자는계약서에명시된범위에서선택된수정안에대해서승인을받아야한다. 3.1.3 수정실시(5530) 1) 분석및수정필요부분결정유지보수담당자는상세한분석을해야하며관련문서와소프트웨어유니트및버전의수정이필요한지를결정해야한다. 이결정결과들은문서화되어야한다. 2) 개발공정이용유지보수담당자는수정요구사항을구현하기위하여개발공정을실행하여야한다. 개발공정의요구사항은아래와같이보충되어야한다. 1 시스템의수정된부분과수정안된부분( 유니트, 구성요소, 형상항목) 의테스트 및평가를위한기준을정의하고문서화해야한다. 2 새롭고수정된요구사항의완전하고정확한구현이보증되어야한다. 또원래 의수정안된요구사항이영향받지않도록보증해야한다. 그시험결과는문서화되 어야한다. 3.1.4 검토및승인(5540) 1) 무결성검토유지보수담당자는수정된시스템의무결성을판단하기위하여수정권한을부여한조직과함께검토를해야한다. 2) 수정완료승인 - 60 -
유지보수담당자는유지보수요청서에명시된대로수정이만족하게완료되었는지 승인을받아야한다. 3.1.5 전환(5550) 1) 전환중의소프트웨어, 데이터의표준부합만약시스템이나소프트웨어가새로운운영환경으로전환되면, 전환중에생성또는수정된어떤소프트웨어나데이터는이표준에따르도록보증해야한다. 2) 전환계획개발및실행 전환계획을개발하고, 문서화하고, 그리고실행해야한다. 이러한계획수립활동 은사용자를포함해야한다. 계획에포함된항목들은아래사항을포함해야하지만, 여기에국한된것은아니다. 1 2 3 4 5 전환의요구분석및정의전환도구개발소프트웨어및데이터의변환전환실행전환검증 3) 전환계획의통보전환계획및활동은사용자에게통보되어야하며, 해야한다. 통보내용은다음사항을포함 1 2 3 구환경이왜더이상지원되지않는지에대한설명전환가능한일정과함께새로운환경에대한기술구환경지원이없어진후, 가능한다른대안에대한기술 4) 병행운영새로운환경으로의원활한전환을위하여구환경및새로운환경을병행운영할수도있다. 이기간중에는어떤필요한사용자교육훈련이마련되어야한다. 5) 전환시관련자통보및문서보관 - 61 -
예정된전환일정이도래하면, 모든관련자에게통보해야한다. 관련된모든구환 경의문서, 로그및코드는기록보관소에보관해야한다. 6) 운영후검토 새로운환경으로의변경영향을평가하기위하여운영후검토가수행되어야한 다. 검토결과는정보, 지침및조치를위하여적절한책임자에게제출되어야한다. 7) 구환경의데이터관리구환경에서사용되었거나관련된데이터는데이터보호및감사를위한조직의요구에따라접근이가능해야한다. 3.1.6 구소프트웨어폐기(5560) 구소프트웨어는소유자의요구에따라폐기해야한다. 1) 폐기계획수립운영및유지보수조직은소프트웨어폐기계획을개발하고문서화해야한다. 폐기계획수립활동은사용자를포함해야한다. 계획은아래에열거된항목들을강조해야하고수행되어야한다. 1 2 3 4 일정한기간후전체또는부분지원의중지소프트웨어및그에관련된문서의보관향후남아있는어떠한지원사항에대한책임 위의사항에해당되면, 새로운소프트웨어로의전환 2) 폐기계획및활동의통보폐기계획및활동은사용자에게통보되어야한다. 야한다. 통보내용은다음사항을포함해 1 폐기가능한일정과함께교체또는개선에대한기술 2 소프트웨어가왜더이상지원될수없는지에대한설명 3 지원이없어진후, 가능한다른지원대안에대한기술 - 62 -
3) 병행운영및사용자교육새로운시스템으로의원활한전환을위하여폐기될소프트웨어와신규소프트웨어를병행운영하도록한다. 이기간중에는사용자교육훈련이마련되어야한다. 4) 폐기시관련자통보및문서보관 예정된폐기일정이도래하면, 모든관련자에게통보해야한다. 모든관련된개발 문서, 로그및코드는기록보관소에보관해야한다. 5) 구환경의데이터관리폐기된소프트웨어에의해사용되었거나관련된데이터는데이터보호및감사를위한조직의요구에따라접근이가능해야한다. 3.2 일본시스템감사실시기준의유지보수공정 본절에서는일본시스템감사실시기준의유지보수업무에대하여기술한다. 유 지보수업무실시기준은정보시스템을정상으로운용하기위하여소프트웨어변경 에대하여유지보수하는것을말한다. 유지보수의종류는사용자에의한변경의뢰, 소프트웨어변경이필요한오류수정, 환경의변경으로인한소프트웨어의변경으 로분류한다. 업무별상세내역은실시기준의착안점을중심으로설명하며세부업 무별입출력물의관계는 < 표 3-2> 와같이정의할수있다[18]. - 63 -
< 표 3-2> 일본시스템감사실시기준유지보수활동대결과물 활동 (Activity) 6510 유지보수순서 6520 유지보수계획 6530 유지보수실시 6540 유지보수확인 6550 이행 6560 구정보시스템기 입력물 유지보수대상산출물 - 개발매뉴얼 - 시스템설계서 - 프로그램사양서 - 소스프로그램 - 등 시험데이터및결과 인계완료보고서 보수순서 유지보수대상산출물 - 시스템설계서 - 프로그램사양서등시험계획서 변경프로그램 사용자지침서 변경시스템 폐유지보수대상시스템 인계규칙서 인계완료보고서 출력물 보수순서( 승인포함) 보수계획서 변경의뢰서 영향분석서 시험계획서프로그램변경및검증순서 변경프로그램 변경승인서( 산출물및 S/W) 검증순서 시험결과서( 승인포함) 이행순서지침서 변경전프로그램및데이터관리 서 이행영향분석서폐기계획서 폐기지침서 3.2.2 유지보수순서(6510) 정보시스템의유지보수업무시작은준비작업인개발부문에서이어지며, 보수순서를확립하는것이다. 개발업무의개발순서에해당한다. 유지 1) 자료인계 인계규칙은개발, 운용및유지보수책임자가승인하여야하며, 인계절차및 보수범위를명확하게정의하여야한다. 또한유지보수에필요한자료등은인계사 항으로기록관리한다. - 64 -
2) 유지보수순서결정 유지보수규칙을명문화하고충분히설명한다. 모, 기간, 시스템특성등을고려하여결정한다. 유지보수순서는유지보수규 3) 유지보수책임자승인유지보수순서는유지보수책임자가승인하여야하고유지보수관계자에게통보및준수하도록설명한다. 3.2.2 유지보수계획(6520) 개별적인유지보수안건마다유지보수계획을수립하고, 영향범위의조사 분석을 실행하며, 시험계획을책정하는것이다. 기획업무의개발계획및개발업무의시스 템설계에해당한다. 1) 유지보수계획수립및승인 유지보수계획에필요한내용을기술하며, 다음과같은사항이추가될수있다 1 목적, 유지보수범위및기간 2 3 4 관련정보시스템에미치는영향범위를중심으로조사 분석결과 유지보수내용, 시험내용, 이행내용, 작업체제 유지보수일정 2) 유지보수내용, 영향범위조사및분석 유지보수규칙에기초하여변경의뢰서등을작성하여야한다. 또한유지보수 대상의자료, 프로그램및데이터등의분석결과를기록관리한다. 변경의뢰내역 은유지보수책임자가승인하여야한다. 3) 유지보수시험계획수립개발업무에서인계된시험환경을이용할지고려되어야하며, 용, 유지보수및사용자의책임자에의해승인되어야한다. 시험계획에는운 3.2.3 유지보수실시(6530) - 65 -
유지보수계획에기초하여개별적인유지보수안건에대응하는소프트웨어를변 경하는것이다. 개발업무의시스템설계, 프로그램설계및프로그래밍에해당된다. 1) 관련산출물개정및승인 시스템설계서, 프로그램사양서는유지보수계획에기초하여변경하고, 유지 보수및사용자의책임자가승인한다. 2) 프로그램변경및승인프로그램변경시오류및부정방지를위하여변경은유지보수순서에기초하여유지보수책임자의승인을득하고실시한다. 또한유지보수순서에의거유지보수책임자가승인할필요가있다. 3) 프로그래밍검증프로그래밍시오류를방지하기위하여변경된프로그램명세서에기초하여프로그래밍을하고있는지검증한다. 유지보수자는프로그램검증순서를명확히정의하여야한다. 3.2.4 유지보수확인(6540) 변경을실시한개별유지보수작업에대한결과를시험하고확인하는작업이다. 개발업무의시스템시험에해당된다. 1) 시험실시프로그램시험을원활하고명확히하기위해유지보수시험계획에기초하여실행하여야한다. 유지보수시험계획에기초하여변경한프로그램시험을실시하며, 유지보수작업이변경의뢰등의요구를충족하는지를확인한다. 2) 신규개발과동일한수준의시험실시정보시스템의기능및성능저하를초래하지않도록신규개발의시험과동일한수준의시험을실시할필요가있다. 유지보수자가시험지침서를철저히이해하도록유지보수담당자가설명한다. 또한변경한부분이외에영향을미치지않는가를확인하여야한다. 3) 시험시사용자참여및사용자지침서에근거한실행 - 66 -
변경의뢰등의요구사항을충족하는지확인하기위해프로그램시험은사용 자가계획에참가하고, 사용자지침서에의거실시할필요가있다. 시험시업무를 많이파악하고있는사용자가참여하여야하며, 시험에참여하는사용자는시험의 목적을충분히이해하여야한다. 또한시험을사용자지침서에기초하여실시하여 야한다. 4) 시험결과승인 시험의적정성을확인하고정보시스템의기능및성능을확인하기위하여시 험결과를개발, 운용, 유지보수및사용자의책임자가승인할필요가있다.( 시험실 시결과에대한검증 ) 5) 시험결과기록및관리시험의적정성을확인하고장애등의문제원인을규명하기위한기초데이터로활용하기위해시험데이터및시험결과를기록관리할필요가있다. 이때시험데이터및시험결과의보관기간을설정하고시험시의환경상황을기록관리한다. 3.2.5 이행(6550) 이행순서를작성하고개별적인유지보수의확인후에프로그램데이터의백업 을한후본격적으로수행하는것으로개발업무의이행에해당된다. 1) 이행순서수립 이행을정확하고원활히하기위해기간, 방법및체제등의조건을명확히정 의하고이행순서를작성한다. 수립된이행순서는운용, 유지보수및사용자의책 임자가승인한다. 2) 프로그램및데이터백업이행의문제에대비하기위하여변경전프로그램및데이터의백업을할필요가있다. 이때백업된프로그램및데이터의보관기간을정하여야한다. 3) 이행에따른영향검증타정보시스템의기능및성능저하를방지하기위하여운용책임자는정보시스템의이행으로인하여미치는영향을검증할필요가있다. - 67 -
1 2 이행전과이행후의정보시스템기능및성능을명확히정의한다 이행시타시스템에미치는영향을운용책임자가검증한다. 3.2.6. 구정보시스템폐기(6560) 정보시스템의유지보수업무종료에따른작업으로폐기계획을책정하고부정방지및기밀보호를고려하여정보시스템을폐기한다. 개발업무에는구정보시스템폐기에대응되는활동이없다. 1) 폐기계획수립및승인 구정보시스템의폐기를원활히하고확실히하기위해폐기계획을수립하고 운용및사용자의책임자가승인을얻어실시한다. 폐기계획및폐기작업은사전 에관련자에게통보하여야한다. 폐기계획수립시다음의내용을참조할수있다 1 폐기계획의내용, 목적, 대상 2 폐기시기, 방법및관련자등 2) 폐기방법및시기의결정폐기방법및폐기시기는부정방지, 기밀보호및프라이버시보호를고려하여결정하여야한다. 추가로폐기방법은정보시스템의중요도를고려하여야한다. 3.3 소프트웨어유지보수관련아웃소싱유형 국내의소프트웨어유지보수관련아웃소싱에관한세부적인자료는대외비로분 류되어공개되지않으므로, 본연구에서이들을소개하기는어렵다. 따라서여기서 는 [3] 에서제한적으로공개가된일부사례들과기타사례를소개하기로한다. 공기업인 A 기업에서는 < 표 3-3> 과같이소프트웨어유지보수와관련한아웃소 싱업무를소프트웨어운영및유지보수, 전산기운전, 전산입출력자료처리및전산 소모품조달, 기타인력지원등으로구분하고, 수행내역을정의하였다. 공기업 A에서사용하고있는소프트웨어유지보수관련비용산정기준은이미 < 표 2-8> 에소개하였다. A사는또한운영되고있는시스템의응용시스템유지보 수, 서버운영, 네트워크운영, 사용자지원체계에대해서서비스수준목표를설정 - 68 -
하였으며, 구체적인측정지표는아웃소싱후 6개월동안운영데이터를활용하기로 하고, 업무수행에중요한일부서비스에대해서만서비스수준을설정하였다. < 표 3-3> 공기업 A에서의유지보수관련아웃소싱유형 구분수행내용 소프트웨어운영및유지보수 전산기운전 전산입출력, 자료처리및전산 소모품조달 기타인력지원 유지보수및보완개발 - - - - - 요구분석및변경설계 변경작업및테스트 문서화 시행 기타연관업무 일상운영 - JOB 의뢰, 오류수정, 처리결과확인 - 프로그램튜닝 - 전산자원및 DB종합관리 - - - - - - 운영에따른자료및출력물관리 수시요청자료작성및출력 사업소문의응대및이용자교육 정보시스템이설 정보시스템이용실태조사및현장지원 신기술도입조사연구 - 기타효율적인업무수행을위한제반업무 주전산기및중간전산기운영 - 시스템관리( 운영체제, 온라인, 시스템자원등) - 일상업무처리( 프린터운전포함) - 전산설비관리 - 기타이와관련된업무 전산입출력자료처리 - - - - 자료입력및변환과오류의체크 우편봉함 홍보물발송관리 기타자료처리 전산소모품조달 - - 일반및디자인전산용지조달 전산기프린터용소모품조달 - MT, 기타소모품 기타이와관련된업무 인트라넷시스템운영인력지원 - 경영, 기술정보및전사자료실정보입력 - 69 -
대형 SI 업체인 S 사에서정의하는소프트웨어유지보수와관련한일반적인아 웃소싱유형은 < 표 3-4> 와같다. < 표 3-4> S사의유지보수관련아웃소싱유형 정보전략기획신기술지원 S/W개발 정보시스템및 정보기술에대한 중장기계획 선진정보기술의 도입지원 신규어플리케이션 S/W 의개발 APPL운영 기존어플리케이션 S/W 에대한 유지보수 정보시스템교육정보MIND 확산, 정보시스템교육, 사용자교육 아웃소싱컨설팅정보시스템운영사업 센터운영 DATA CENTER, Back-up,Recovery, N/W CENTER H/W 지원통신망운영시스템운영고객서비스 H/W 의임대, 백업체제지원등 통신망의 안정적/ 효율적 설치, 운영지원 정보보안관리 / 기계실운영관리 시스템이용자교육 HELP DESK 서비스 또다른대형업체인 을포함하고있다. D사에서는정보시스템아웃소싱사업의범위에다음내용 전산시스템운영 전산시스템도입에관한심의, 네트워크관리 데스크탑서비스 사무자동화업무지원등 구매업무 L 기업의경우시스템운영관리를 정보시스템을통해사용자에게서비스를제 공하기위한일반적인운영활동및원활한운영을위한제반지원활동( 운영지원) 으로정의하고, 다음과같이사업유형을구분하고있다. IT 자원분야 - 70 -
- - - 네트워크운영 데이터센터운영 데스크탑관리 IT관리분야 - 시스템관리 응용시스템이실제업무에적용되어제대로운영될수있도록시스템을 관리하고유지보수 시스템기능향상위한변경, 기존업무의절차변경및신규추가업무 발생등여러가지제도적 환경적요인에맞추어업무를처리할수있 도록응용시스템을관리및운영 1 2 3 4 유지보수 변경관리 CSR 처리 신규시스템추가개발 - 데이터베이스관리 데이터의투명성있는관리를위한효율적감시체제구축하여장애에대한신속한대응및데이터의신뢰성보장과성능관리 - 보안관리 정보자원을보호하고모든위험요소를사전에파악하고사고발생가능성을평가분석 - 상용소프트웨어관리 서버및데스크탑에설치/ 운영되는각종시스템S/W를효과적으로운영 하여서비스품질을향상시키기위한활동및절차 ( 즉, 각종시스템 S/W 관리, 운영지원및유지보수업무) - 고객지원 시스템사용중발생된각종장애의접수및처리, 시스템사용에대한각종안내, 고객요구수렴등사용자에대한모든사항을종합적으로지원 - 71 -
H 기업의소프트웨어유지보수사례를나타내는소프트웨어유지보수용역시방 서를소개하면다음과같다. 1. 업무내용및기간 가. 내용 : OOO시스템일괄유지보수 나. 기간 : 2002.01.01 ~ 2002.12.31(1 년간) 다. 시스템구성현황 구분 OOO시스템 H/W HP9000-L2000 O/S HP-UX 11 DB ORACLE 8i, IMS 사용언어 처리방식 PB 5.0, COBOL Ⅱ C/S 라. 프로그램세부내역 개발툴 DBMS 프로그램 : PB 5.0, COBOL : ORACLE 8i, IMS : 76본 Ⅱ 2. 유지보수범위와기준 가. 유지보수범위 요구분석및변경설계 변경작업및테스트 문서화 시행 JOB 의뢰, 에러수정, 처리결과확인 전산자원및 DB종합관리 운영에따른자료및출력물관리 - 72 -
- 수시요청자료( 예측관련영업, OO 자료등) 작성및출력 사업소문의응대및이용자교육 시스템이설 시스템이용실태조사및현장지원 신기술도입조사연구 적응보수 환경변화에대응한소프트웨어변경 - 분류코드, DB변경등데이터 - 하드웨어나 OS, DBMS 등처리환경의변경에대응 - - - - 완전한유지보수 보다좋은알고리즘으로수정 보다효율적인사용을목적으로출력방식의개선 보다편리하게할목적으로출력방식의개선 새로운출력정보의추가등기능상의보완등 시스템기능향상을위한소프트웨어 기타효율적인업무수행을위한제반업무 Version Up-Grade 작업 나. 유지보수기준 1 요구분석결과신규개발규모가 젝트로추진한다. 20본초과시는재개발로간주하여별도프로 2 보완개발과유지보수와의구분은아래산식에의해산출된합계가큰쪽으로 결정하며동점일경우는유지보수로판정한다. - 73 -
구분항목보완개발유지보수비고 1. 추가프로그램개발및보완작업규모(40 점) 추가프로그램개발본수가 10 본이상인가? 2. 추가프로그램의성격 (60 점 : 10 점 / 항목) 기존시스템과다른 O/S 또는 DBMS 를적용하는가? 기존시스템과다른언어를사용하는가? 기존시스템과처리형태가다른가? ( 분산처리, GUI, Client/Server 등) 기존시스템에유사한 Sub system 이존재하는가? DB 구조의변경이있는가? ( 신규DB 생성, SEG 추가등) 신규입출력장표( 화면) 가있는가? Y Y Y Y N Y Y N N N N Y N N 합 계 3. 유지보수업무수행절차및장소 가. 유지보수업무의수행은 유지보수업무수행절차도 에따른다. 나. 계약자가본유지보수업무의역무를수행하여야하는장소는 OOO를포함한 다 4. S/W 의성능유지및품질기능 계약자는 S/W의성능과품질을최상의상태로유지하기위한품질보증계획 을수립하여시행하여야하며, 품질보증계획및시행에대하여확인또는검 검할수있으며, 점검결과개선을요구하는경우계약자는즉시조치하여야 한다. 5. 유지보수업무수행및책임 가. 유지보수업무수행방법계약자는발주자의전산규정, 정보시스템업무절차등운영절차에따라유지보수업무를수행하며, 발주자는작업지시서의요구시한을현재진행중인업무량, 작업일정등을감안하여정한다. 나. 유지보수업무수행책임 1) 계약자는능률적인업무수행은물론수행요원의자질향상, 인력의확보, 보 - 74 -
2) 안및업무수행기간준수등에대한책임이있으며, 이를태만히하여발 생된책임은계약자가진다 계약자는유지보수업무를계약자귀책사유로발주자가정한기한내에완 료하지못하였거나, 발주자의업무수행에지장을초래하게하였을경우에 는정산처리시에 16항에의한지체상금을구매시방서 8 항 에준하여발 주자에게납부하여야한다. 3) 작업지연이천재지변등불가항력적이거나, 계약자의귀책사유가되지않 4) 는다고발주자가인정할때에는책임을면할수있다 발주자는계약자의계약업무와관련하여필요시업무수행실태와당해계 약금액을구성하는정산변경간의비목의적정이행여부에관하여조사 할수있다. 이경우계약자는필요한제반자료제공에협조하여야하며, 지적사항은발주자관련부서의지시에의하여시정조치를취하여야한다. 6. 유지보수체제및인력확보 가. 계약자는 24시간보수체제를구축하여소프트웨어품질지원을위한밀착유 지보수체제를수립, 운영하여야한다. 나. 계약자는본계약을수행하는데필요한인력등을충분히확보해야한다. 다. 계약자는발주자의요청시 10일이내에투입인력을발주자와협의하여교체 투입하여야한다. 발주자는교체투입요구를할경우는서면으로교체일자, 교체원인등을명시하여야한다. 7. 유지보수관련서류제출 계약자는역무수행과관련하여다음서류를기성고요청시또는발주자요청시 제출하여야하며, 발주자는기성고검사시이의이행여부를확인하여야한다. 가. 작업지시및작업결과( 예방점검포함) 현황 나. 기타발주자가요구하는유지보수업무수행관련서류 8. 유지보수확인 계약자는유지보수를시행하고작업지시자에게확인을받아야한다. 9. 계약이행실태확인 가. 발주자는계약자의계약업무와관련하여필요시업무수행실태와당해계약 금액을구성하는실적정산비목의적정이행여부에관하여조사할수있다. 나. 이경우계약자는필요한제반자료제공에협조해야하며, 지적사항은발주자 - 75 -
관련부서의지시에의하여시정조치를취하여야한다. 10. 대가의지불가. 발주자는계약대가를일할비율에따라매분기말계약자의청구에의해지급한다. 나. 발주자는본계약서상의유지보수업무중계약금액에대한공제사유가발생하였을때에는계약자에게지급할타지급금에서이를공제할수있으며, 지급금이없을때에는계약자는발주자가정한소정기일까지해당금액을발주자에게납부하여야한다. 11. 일할계산및원미만의단수계산방법 가. 본계약에서기간계산은역년을기준으로계산하고일수는년의 365분의 1로계산 한다. 나. 원미만의단수는절사하여계산한다. 12. 기술관리 가. 계약자는유지보수업무수행상필요한기술사항을시스템관련문서와함 께지속적으로작성관리하여발주자의시스템관리업무에활용할수있도록 하여야한다. 나. 계약자는발주자의운영절차및발주자가소유한제반기술자료를역무수행 에활용할수있으며, 발주자는계약자의요청시이를활용할수있도록 협조하여야한다. 단, 보안에관련되는자료는 15 보안및개인정보보호준수 에따라야한다. 13. 전산기사용계약자는발주자의전산기등기기사용을발주자가유지보수한업무에한하여사용한다. 14. 하도급의금지및유지보수인력관리가. 계약자는본업무를수행함에있어하도급을줄수없다. 나. 계약자는시스템유지보수담당인력의변동시변동내역을발주자에게통보하여야한다. - 76 -
15. 보안및개인정보보호준수 가. 계약자는발주자의보안업무취급요령, 정보통신보안업무처리지침및정보 시스템보안대책을준수하여야한다. 나. 계약자는공공기관의개인정보보호에관한법률에의거수립된발주자의개 인정보보호제도운영지침을준수하여야한다. 16. 지체상금 가. 소프트웨어유지보수업무는상호협의에의한작업지시서상의처리기한을기 준으로한다. - 지체상금 : 소프트웨어유지보수비 해당업무본수 / 총본수 지체상금율 지 연일수 단, 계약서에지체상금율대한구체적인명시가없는경우 0.25% 로한다. 나. 단, 발주자의사정에의하여지연된경우그지연시간을공제한다. 17. 유지보수업무의해지역무범위에따른업무의해지는다음과같다. 가. 유지보수업무의해지유지보수중인소프트웨어및정보통신설비가라이프싸이클이도래했거나용도폐기등의사유로인해더이상운영될필요가없는경우에는계약자에게통보후유지보수대상에서제외한다. 나. 효력발생발주자가계약자에게문서로통보함으로서효력을발생한다. 다. 업무의추가및해지에따른대가는유지보수계약금액을기준으로계약종료시점아래와같은방법으로정산한다. 1) 업무의해지 정산금액 = 계약금액 계약시유지보수대상 추가분 유지보수제외일수 계약일수 18. 계약효력 본계약체결전에이행한역무에대하여는 2002년 1월 1일이후본계약조건에 의거정산하며, 차기계약이본계약종료후에체결되지않더라도계약자는발 - 77 -
주자의업무에지장을초래하지않도록본계약조건에의거계약을이행하고 대가는차기계약조건에의거정산한다. 유지보수업무관리부서 계약자 비고 - S/W 유지보수 업무분석 작업지시 협 의 유지보수계획 유지보수시행 결과보고 실적관리 결과분석 대가수령 ( 분기말 ) - 장애시조치절차 고장신고 원격처리 협 의 장애분석및시스템상태확인 장애처리 장애조치결과분석 종 료 실적관리 < 그림 3-1> 유지보수업무수행절차도 - 78 -
3.4 소프트웨어유지보수유형별견적기법 일반적으로비용산정방식은 [3] 에서소개한것처럼투입비용을중심으로산정하 는방식과산출물을중심으로비용을산정하는방식, 위험과보상중심의비용산정 방식, 서비스수준협약방식등 4 가지로나눌수있다. 아래에서이들방법을소프 트웨어유지보수비용산정에적용할수있도록수정한다. 어떠한소프트웨어유지 보수비용산정방법을사용하든, 그결과계산방식은관리하기용이하고, 사용자 원의통제가용이하도록해야한다. 또한서비스의유연성을제공하고, 가격을그에 연동하여책정할수있는체계가필요하다. 3.4.1 투입중심비용산정 서비스의유연성을보장하는가격정책을확보하기위해서는다음과같은가격요 소를가질필요가있다. 표준요소 : 변동요소 : 보편적이고일상적인기본적요구사항다루는요소 하지않는요소 부가서비스요소 : 이전요소 : 보편적인요구사항이지만그빈도수와양이표준유형에는부합 서비스제공자의능력과서비스제공범위내에서예상하 지못하였거나잘알수없는서비스요구사항을위해제공되는요소 자산의양도와직원고용승계또는퇴직수당의무등을포함하 는서비스개시와관련된비용요소 표준요금의주요구성요소는다음과같다. 장비리스, 임대, 할부및상환 보편적이고일상적이며계량화가능한것 설비및시설 ( 임대, 회의비용, 유지보수, 기본시설등) 환경 ( 공기정화시설, 전기등) 고용승계된직원 수주자의관리팀과직원 수주자가제공하는장비 수주자의이윤 - 79 -
수주자는내부성과개선프로그램의예상견적을참조하여표준요금을제시한 다. 변동요금은소모품비용, 시간외수당등을포함하여쉽게예상될수있는변동 성비용을의미하며, 부가서비스요금은요구사항에따라변화되는요금으로서표 준요금에대한인상분또는중장기적인증가분으로계산된다. 적절한부가서비스 요율은수주자와발주자가합의하여결정하며, 인력에관련된경우장기간의표준 요금보다높은가격이일반적이다. 이전요금은기존자산의구매, 이전관리와오버헤 드비용, 퇴직수당등으로서한번에지불되어처리되거나, 표준요금의요소별로구 분되어삽입될수있다. 따라서유지보수업무투입을중심으로한비용은일정기 간에대해다음요소를합산하여계산한다. 투입요금 = 표준요금 + 변동요금 + 부가서비스요금 + 이전요금 투입중심의계산방식은유지보수업무투입의단위량에적용하게되므로, 의초점은수주자의오버헤드와이익기여도에맞추어지게된다. 협상 3.4.2 산출중심비용산정 산출중심비용산정방법은산출물의예측결과를단위별로확인하여합의한가격을기준으로산출물을예측하여가격을정하는방식이다. 이방식을사용하기위해서는다음과같은조건이충족되어야한다. 산출단위를예측할수있는가? 소프트웨어유지보수업무에서산출을산정하기는쉽지않다. 소프트웨어유지보 수의규모는기능점수방식이사용될수있다. 소프트웨어유지보수서비스수준과 연계된산출확인은많은노력이필요하다. 산출단위를정확하게계산할수있는가? 산출단위를계산할수있는노력이필요하다. 예를들어소프트웨어유지보수 규모이외에사용자의 서비스요청건수 를산출의기준으로채택하였다면, 서비스 요청의규모, 내용등을감안하여건수를측정할수있는방안을마련할필요가있 다. 산출단위당비용의합리성을시험할수있는가? 소프트웨어유지보수규모와서비스수준의산출의단위가격이결정되면최소량 - 80 -
과최대량을포함한산출량의범위에대한가격범위민감도분석이수행되어야한다. 민감도분석이수행된후에실질적인단위가격이합의된다. 3.4.3 위험과보상중심의비용산정 이방법은성과중심비용산정방식이다. 공급업체( 수주자) 의서비스요금은고객 ( 발주자) 의실제적인소프트웨어유지보수규모, 총매출이나총수익과연계되어결정된다. 다음과같은요소를활용하여가격을산정한다. 이방식의계약은수주자에게다음활동을수행할수있도록해야한다. - - - - - - 아웃소싱서비스업체비용의절감 고객의사업비용절감 고객의총매출증대 고객마진증가 잘못된투자결정에대한저지 투자사업개발에높은열정 이방식은사업이익이조작되는비합리적인기회를없애기위해장부공개등 이필요하다. 비용베이스라인과요금상한계수: 고객의연총수익에곱해질수있는조정 계수가필요하며, 이값이최대허용요금을결정하게된다. 3.4.4 유지보수서비스수준협약(SLA) 소프트웨어유지보수에서서비스수준협약및관리는매우중요한프로세스이 다. 이프로세스가잘관리되고활용될때소프트웨어유지보수아웃소싱사업은 성공할수있다. 유지보수서비스수준을설정하고관리하기위해 [3] 에서제안한 < 그림 3-2> 의 SLA 표준프로세스에소프트웨어유지보수특성을반영하여적용 한다. - 81 -
SLA 프로세스 SLA Templete SLA Guide 현수준 Teaming SLA 항목, 대상선정 SLA 수준설정 측정방법정의 - 고객사 - Vendor Interview 희망수준 반영평가측정 SLA 완성 - SLA - Vendor 평가 < 그림 3-2> SLA 프로세스 1) 소프트웨어유지보수팀구성및공급업체의자원파악 고객사와공급업체가함께유지보수팀을구성 공급업체의소프트웨어유지보수서비스제공능력파악 2) 소프트웨어유지보수 SLA 항목, 대상선정 소프트웨어유지보수를위해어떤자원이현재이용되는지이해 - 전체적인부분과세부적인부분을이해 전체적인부분은현재의유지보수서비스레벨을발전시키고새로운어플리 케이션을개발할수있게한다. 세부적인부분에대한이해는유지보수서비스레벨의확고한베이스라인 을설정하고현재의유지보수서비스레벨을발전시킨다. 정 SLA Template 과 SLA Guide를이용하여유지보수 SLA 항목과대상을선 - 82 -
3) 소프트웨어유지보수 SLA 수준설정 해당어플리케이션의현재유지보수서비스레벨파악 - 어플리케이션의유지보수서비스레벨을매트릭스형태로작성 고객의요구사항정의 - - - 발주기관의만족도조사 요구하는유지보수서비스레벨 매트릭스형태로작성 현수준과희망수준의차이를분석하고유지보수 SLA 수준설정 4) 소프트웨어유지보수서비스수준측정방법정의 예측된소프트웨어유지보수서비스수준과비교하여실제제공되는소프트웨 어유지보수서비스의수준을측정하는방법정의 소프트웨어유지보수서비스수준측정방법, 측정빈도등을정의. 결과데이터의간략한설명및향후예측방법정의 5) 소프트웨어유지보수 SLA 완성 소프트웨어유지보수 배경 - SLA 에포함될최소한의요소는다음과같다. 어떠한사람이읽더라도소프트웨어유지보수서비스의수준을이해할수 있도록충분한정보를제공할수있어야한다. 계약당사자 - 소프트웨어유지보수 SLA 의수행자, IT 의책임자, 어플리케이션사용자그 룹의담당자등을명시 제공될소프트웨어유지보수서비스의볼륨 - 제공될소프트웨어유지보수서비스의볼륨을정의한다. 어플리케이션사 용자그룹은소프트웨어유지보수서비스수준의평균값과최고값, 일당소프트웨 어유지보수서비스제공해당시간을요구할수있다. 한다. 소프트웨어유지보수서비스적시제공 - 예: 어플리케이션유지보수요청후규정시간내에처리된다. 소프트웨어유지보수서비스유효성 - 사용자는소프트웨어유지보수서비스를언제이용할수있는가? 소프트웨어유지보수서비스의제한 - 워크로드를쌍방이정확하게파악함으로써향후지적요인이되지않도록 - 83 -
소프트웨어유지보수서비스에대한만족 - 소프트웨어유지보수서비스수준이높을수록비용은더증가하게된다. 소프트웨어유지보수서비스측정 소프트웨어유지보수서비스재협상 - 시간이갈수록어플리케이션의사용도는변화하게됨으로써추가적인어 플리케이션유지보수요구사항이등장하게된다. 그러므로유지보수팀간의긴밀한 연락체계를갖추는것이소프트웨어유지보수 SLA 를수행하는성공요인이다. - 소프트웨어유지보수 SLA 작성후계약의당사자들과수행사항에대해 검토를실시한다. 각부분의책임자와회의를갖고소프트웨어유지보수 SLA 수행 시필요한사항을자세히논의한다. 6) 소프트웨어유지보수 SLA 측정 자동화도구등에의하여예정된소프트웨어유지보수서비스수준측정및모니터링수행 7) 평가 소프트웨어유지보수서비스수준이통제범위를넘게될경우조치방법을 제공. 사용자그룹이비정상적인소프트웨어유지보수서비스수준을요구할경우 이를조기에발견하고적절한대안을제공. 8) 반영 소프트웨어유지보수비용의증감에반영 소프트웨어유지보수서비스수준의조정에반영 3.5 소프트웨어유지보수대가기준사용자요구조사 실제사용자요구사항분석및의견수렴을위해 소프트웨어유지보수발주자및수주자 으로설문조사를실시하였다. 2002. 8. 28 ~ 2002. 9. 27 까지 33인을대상으로서면및방문조사의방법 설문은크게 1 인적사항, 2 사용실태에관한설문, 3 개선모델에관한설문, 4 대가기준의적용에관한설문으로구분하여질문하였다. - 84 -
3.5.1 인적사항 설문은응답자의기본적인인적사항과소속기관의소프트웨어유지보수와관련된 업무형태에관한설문을하였다. 또한응답자의소프트웨어개발및유지보수경 력에대한설문을하였다. 설문에대한답변은주로공공기관소프트웨어유지보수발주자와수주자들이응 했으며업무형태별로수주자와발주자가전체응답자중각각 27% 와 73% 씩응답 하였고, 응답자중소프트웨어개발경력은 15 년이상이, 유지보수경력은 9년이상 ~ 12 년미만이가장많았다. 소속기관분류 27% 73% 발주자 수주자 소프트웨어개발경력 6% 16% 52% 10% 16% 6년미만 6년이상 ~9년미만 9년이상 ~12년미만 12년이상 ~15년미만 15년이상 - 85 -
유지보수경력 36% 3% 3% 32% 26% 6년미만 6년이상 ~9년미만 9년이상 ~12년미만 12년이상 ~15년미만 15년이상 3.5.2 현행용역유지보수대가기준사용실태 소프트웨어유지보수대가기준의사용실태에관한설문에서는 가. 정부가제정고시한 소프트웨어사업대가기준 의용역유지보수대가산 정기준에대해서알고계십니까? 설문에대한응답자의대부분(93%) 은소프트웨어사업대가기준중용역유지보 수산정기준에대해알고있는것으로나타났으나, 기준을이용하고있는비율은 절반에도미치지못하는 39% 로나타났다. 나. 현행유지보수대가산정기준을사용하지않는다면그이유는무엇입니까? 설문에대해응답한답변중몇가지를들면다음과같다. - 서비스레벨에대한언급없이개발비의 10~15% 로기준이되어있음. - 차원높은서비스는이루어질수없으며, 돈에맞춘저급서비스위주가됨. - 지속적인추가개발등고객의요구에적극적으로대응하기위한방법은되지못함. - 용역유지보수대가기준이개발비의몇 % 범위내에서단순한산정기준에 - 86 -
따라하도록되어있으나, 그기준이명확하지않고, 산정기준도주관적인요 소가많이가미된듯하고( 실무지식필요여부등), 일부는자료산정이회사내 에서이루어지지않아서이기도함. - 포괄적유지보수( 오류수정+ 추가개발) 에적용하기에는산정기준이너무낮은 것같음. 또한다년간에걸쳐단계적으로이루어진경우전체개발비를산정 하기가힘든경우도있음. - 당사는고객에대하여 SM 을실시하고있으며, 프로젝트종료후운영요원 투입공수에따라대가를받고있고, 또한 SLA를적용하여 SLA 기준에따른 reward/penalty 를주기적으로받고있음. - 사실대가기준이현실성이없다고판단됨. - 특히정부출연( 연) 에서는항상부족한예산으로인하여유지보수부분에대 한설득이어려움. - 당사의현실에맞지않음. 현행기준인지여부 3% 39% 58% 알고있으며적극적으로이용하고있다. 알고는있으나이용하고있지는않다. 잘모른다. 다. 현행유지보수대가산정기준을이용한산정값과실제의비용을비교하면? 응답자중발주자는대부분비용이높게산정(31%) 되는것으로답하였으며, 수주 자는반대로낮다는의견(37%) 이많았다. 따라서현재의비용산정에대해문제점이 - 87 -
있는것으로판단된다. 그러나발주자및수주자공히자신의응답에대한근거자료를제시하지못하는것으로보아발주자및수주자의입장차이로인한심정적인것일가능성이제기된다. 산정값과실제값의비교 13% 19% 37% 31% 산정되는비용과실제유지보수비용이대체적으로일치한다. 산정되는비용이실제유지보수비용보다대체적으로높다. 산정되는비용이실제유지보수비용보다대체적으로낮다. 산정된비용이일관성이없다. 라. 현행유지보수대가기준에의한산정값과실제유지보수비용이일치하지않거나산정의일관성이없다면그이유는무엇때문이라고생각하십니까? 설문에대한서술식답변중몇가지를들면다음과같다. - 유지보수의중요성미인식. - 유지보수예산미확보. - 유지보수대가기준자체의모호성 ( 수주자와발주자가협의하여결정한다는 것은기준이라할수없는수준임 ). - 대부분의공공기관은수주자에게 MM 을지정하여유지보수를요청함. - 유지보수시제공하여야하는서비스의다양성이존재. - 많은서비스품질의차이가존재함에도수주자입장에서는가장저급한서 비스만을제공. - 88 -
- 다양한서비스들을규정하고그서비스레벨에따라확보가능한예산을 차별화하여야함. - 유지보수의경우사용자교육, 소프트웨어운영지원, 에러처리지원, CSR 지원등업무유형이다양한데반해계약시다양한유형을조목조목상세화하 기어려움. - 소프트웨어개발비의 10~15% 는계약당시금액을기초로한유지보수대 가이므로, 계약금액은통상산정가격보다낮고, 규모는최초계약규모보다커 지므로계약당시개발비로산정하는경우에는유지보수대가비용이터무니없 이적게나오고있음. - 현실적으로고객과의합의하에종료시점의규모를다시산정해서그규모 를기준으로한소프트웨어개발비를산정하고, 이를유지보수대가에반영하 는실정이나이것도성향에따라고객에따라받아들이는고객이있는반면에 원칙을고수하자는고객도있어난감한상황임. - 유지보수의여러유형을모두충족시킬수없고, 보정계수( 다수기관등) 에 대한정확한적용이힘듬. - 유지보수대가산정기준에의거하여계약을하고있으나, 극히다수의사이 트에서사용하는관계로개선요구사항이많아타당성검토및분석/ 설계하는 시간이많이소요됨( 전체사이트의공통적인사항인지사이트별상이한프로 세스 ). - 프로그램에대한유지보수뿐만아니라각업무를지원하는운영조직이없 는관계로유지보수요원이각사이트별업무담당자의운영지원도병행하고 있음. - 기능추가에대해유지보수차원에서개발할것인지, 추가프로젝트화할 것인지에대한명확한기준이없는관계로모두유지보수차원에서개발함으 로써추가비용이발생함. - 회사내유지보수기준이상이하고이에는업무의중요도, 적용되는기준에 따라차등적용하게됨. - 유지보수라는업무가해당시스템의특징에따라작업량이차이가많이남. 즉, 시스템의특징에따라편차가너무큼. - 시스템속성을고려하지않고과거호스트언어중심으로설계되고비용을 산정함으로신규시스템은일부기준을맞추기곤란함. - 신규시스템(WEB) 은화면제어(JSP, ASP 등) 와비즈니스로직부분으로 나누어개발되는데과거의기준을적용하므로화면제어부분은대가를받지 못하는경우발생. - 89 -
- 호스트의화면제어(BMS, MFS 등) 는모듈화되어화면제어작업시시스템 에서많은지원을해주지만 WEB 이소요됨에도대가를받지못하는경우가발생. 방식은일일이코딩해야하므로많은노력 - SI 업계의현황으로볼때, 경쟁적저가수주또는전략적저가수주에따른 계약금액을기준으로소프트웨어유지보수대가 않음. - 10~15% 산정은현실에맞지 예산범위내에서유지보수비용을산정하기위하여물량을대가기준에따 라조정. - 납품되는하드웨어와소프트웨어를통합하여계약하고전체금액에대한 일정비율을유지보수금액으로책정. - 특정제품의경우비율이아닌특정금액으로유지보수비용을청구. 마. 현재의유지보수대가산정기준이존속해야한다고생각하십니까? 응답자중대부분(73%) 이현행기준을보완하여존속해야한다고답하였다. 비록 앞의응답과같이현행기준의부정확성에대해서는공감을하고있지만, 소프트웨 어유지보수사업의시행및운영을위해보완된대가기준의존속을강력히희망하 고있다. 폐지시실제공공기관관련유지보수계약은기준의법적근거가없으므 로계약추진이더욱힘들어질것이라는것이그이유이다. 현행기준의존속여부 6% 21% 73% 존속해야한다. 일부보완하여존속해야한다. 폐지하여야한다. - 90 -
3.5.3 유지보수대가산정개선모델 소프트웨어유지보수대가산정의개선모델에관련된설문에서는 가. 연간용역유지보수대가로유지보수계약시점에서의개발비산정가의 10~ 15% 를적용하는현행기준은적절하다고생각하십니까? 설문결과대부분(73%) 의응답자가유지보수계약시점에서의개발비산정가의 10~15% 를적용하는현행기준이부적절하다고응답하였다. 대부분의발주자의경우실제유지보수업무에드는비용에비해기준이지나치 게높다는응답을하였다. 유지보수업무가거의없거나별다른노력이요구되지 않는업무의경우에도최소 10% 의기준이지나치게높으므로실제유지보수예산 이책정되는기준이 8% 가적절하다는응답이었다. 그러나유지보수를단순한일상 적인운영으로간주하여현행기준이높다고응답한경우가다수있어유지보수의 정의에혼동이있다는것을발견하였다. 또한대부분의수주자는현행기준이지나치게낮다는응답을하였다. 대부분의 발주자와마찬가지로유지보수를단순한일상운영으로간주하는경우에는실제유 지보수과정에서일상적인운영외에기능개선및확장등의유지보수고유의업 무로인한추가부담을그이유로들기도했다. 그밖에응답의결과현행기준의해석및적용에심각한오해가있음을발견하 였다. 현행기준에서 유지보수계약시점에서의개발비산정가 라는규정이있음에 도불구하고많은응답자가개발비의산정가가아닌할인가격인계약비용으로해 석하고있었다. 현행기준의적절성 27% 73% 적절하다. 적절하지못하다. - 91 -
나. 위의문항에서적절하지못하다는답을선택하셨다면그이유는무엇입니까? 설문에대한서술식답변중몇가지를들면다음과같다. - 논리적근거와신뢰성이없음. - 인원, 서비스수준별대가의반영이전혀되어있지않음. - IT 규모에대한일정비율은탁상공론임. 즉서비스대가산정, 산업별, ERP 등의시스템별, 전문분야별대가를산정치못함 (ERP 전문가는 1인당 단가가매우높음 ). - 시장가를미적용. - 개발비는수주시많은할인이있음. 따라서개발비를기준으로하는것은 합당하지못함. - 유지보수시많은공공기관의발주담당들은정상적인유지보수범위외의서 비스를요구하고있으나, 위의조항으로는한정된예산만을확보가능함. - 고급의유지보수서비스를하기에는역부족. - 있음. 개발된업무시스템의특성에따라개발후의유지보수대가가변동될수 - 개발비의일정비율로결정되어서는안되고, 유지보수시고객이원하는서 비스수준을결정한후그에따른가격산정을해야함. - 유지보수비용이개발비의 10~15% 비율이라는것은현실적이지못함. - 유지보수난이도판정기준이현실적이지못함. - 실제개발본수및상주인력지원( 운영관련) 과관련하여실제유지보수비용 이상이하므로, 일률적인비율적용은어려운점이있음. - 유지보수대상시스템의특성항목이추가( 멀티사이트수) 되어야하며따 라서비율의상한선이조정되어야함. - 시스템별특이사항을반영하기엔그조정폭이낮다고생각됨. - 시스템의특징에따라차이가심함. 유지보수및추가개발이빈번히발생하 는시스템에서는적용하기힘듬. - 유지보수실적을근간으로일정기준( 전체대상중유지보수가일어난물량 및횟수) 을적용하여재산정필요. - 개발된시스템이인도된후소프트웨어유지보수는유지보수유형에대한 유동성이크기때문에 10~15% 를기준으로적용하는것은맞지않으며, 또한 기술자등급이다른영향도반영하기어려움. - 92 -
다. 현행유지보수대가산정기준에의하면, 연간유지보수대가를개발비산정값 의 10% 를기본으로아래의 5 개항목의특성을단순, 보통, 복잡으로판정한후개 발비의 15% 까지계상하도록하고있습니다. 다음의유지보수대상시스템의특성 중삭제해야할항목이있다면, 해당항목들을선택하시고각각그이유를간략하 게답해주십시오. 설문결과모든수주자와발주자가공히삭제할항목이없다고응답하였다. 라. 현행유지보수대가기준에서고려하는대상시스템의특성에추가해야할항목이있다면어느것입니까? 설문결과언급된항목들은다음과같다. a b c d e f g h i j k l m n o 레거시소프트웨어모듈의구조화정도 레거시소프트웨어모듈간의독립성 프로그래밍언어의변경용이성/ 가독성 레거시소프트웨어모듈의재사용성 레거시소프트웨어의문서화정도 소프트웨어공학표준과의일치성 레거시소프트웨어의시험용이성 (testability) 시스템의노후도 업무변경의빈도 비즈니스영향도 패키지적용유무 사용기관수 ( 나이) ( 멀티사이트) 프로그램본수당사용자수 요구되는응답시간 사용자의수와숙련도 3.5.4 소속기관의소프트웨어유지보수대가기준 소속기관의소프트웨어유지보수대가기준의적용에관한질문에서는 - 93 -
가. 귀사에서적용하는유지보수대가산정규모의기준은무엇입니까? 설문결과대부분본수(52%) 와투입공수나별도계약등의기타(39%) 방식에 의한기준을적용하고있는것으로나타났다. 기능점수는극히일부분(3%) 에불과 한것으로나타났다. 나. 유지보수대가관련계약기준은무엇입니까? 설문결과년간베이스기준이가장많은비율(67%) 을차지하였으나그외에도다양한방식의계약이존재함을알수있었다. 유지보수규모기준 39% 52% 3% 6% 본수스텝수기능점수기타 유지보수계약기준 9% 3% 21% 67% 연간베이스시스템베이스 다년간베이스프로젝트베이스 - 94 -
3.6 소프트웨어유지보수대가기준후보모형 실제사용자요구사항분석및의견수렴을위해실시한설문조사를통해얻어 진자료를바탕으로소프트웨어유지보수대가기준의잠재적인후보모형을선정하 였다. 3.6.1 현행용역유지보수대가기준의수정 실제사용자요구사항분석및의견수렴을위해실시한설문조사에서연간용 역유지보수대가로유지보수계약시점에서의개발비산정가의 는현행기준에대해발주자는하한을 10~15% 를적용하 8% 로낮출것을요구하고있는반면에수주 자는상한을 20% 혹은심지어 30% 로높여줄것을요구하였다. 현행기준에의하면사소한유지보수의경우에도개발비산정가의 10% 를지급해 야한다는발주자의불만도나름대로일리가있어기준의하한을낮추는것이타당 하다고판단된다. 또한실제연간유지보수비용이개발비의 15% 를넘는경우에도 현행기준에의거그이상지급이불가능하므로유지보수의품질의떨어진다는점 을지적한발주자도있었다. NASA 의경우[19] Single-mission 시스템의년간유지보수비용은개발비의 5%, Multi-mission 시스템은 15% 를적용하고있다. REVIC 모델의경우소스코드의 유지보수비율을예측하지못할때 ACT의디폴트값을 0.10으로가정하므로개발 비용의 10% 를유지보수비용으로간주하는셈이다. SASET 모델은 ACT의상한을 20% 로제한하고있다. SOFTCOST 모델은 ACT의디폴트값을 0.10으로가정한다 [20]. 현행기준의상한과하한을조정하는데대한발주자와수주자의입장차이로나 름대로의견해가존재하므로실적데이터의수집을통한현행기준의검증결과조 정필요성이제기되면수정하는것이바람직하다. 3.6.2 연간유지보수비율을적용한유지보수비용산정 이상적인소프트웨어유지보수비용산정은 NESMA의유지보수기능점수방식 [4] 처럼유지보수규모를기준으로실제필요한업무에투입할노력을산정하는것 - 95 -
이다. 그러나유지보수규모나유지보수되는코드의비율을추정[5, 6] 하기어려울 경우에는수주자와발주자가합의한 ACT 의디폴트값을적용[20] 하거나현행대가 기준및 NASA 의기준[19], 기타유지보수비용산정모델[20] 처럼개발비용을기초 로유지보수비용을추정할수밖에없다. 현행용역유지보수대가기준처럼규모와무관하게일률적으로개발비의상한과 하한을갖는일정범위의값을제한하는것이아니라, 연간유지보수비율을개발 비에적용하는방식이가능하다. COCOMO의 ACT 적용과같은방식이다. 그외에도현행대가기준의유지보수대상시스템의특성대신다양한유지보수 생산성요소를고려해야한다는요구가있다. 각각의유지보수생산성요소가차지 하는영향의정도를나타내는가중치는실적데이터나델파이기법[6] 을이용한유 지보수전문가의판단또는수주자와발주자의합의에의해결정될수있다. 유지보수비용은다음식으로산정한다. 유지보수비용의상한은연간유지보수 비율인 ACT 로규정될수있으나하한은제한되지않는다. 상한은해당조직이나 기관에서유지보수와신규개발을구분하는경계가될수도있다. 즉, 개발비용의일 정비율이상을신규개발로간주하는경우그값이상한이될수있다. 연간소프트웨어유지보수비용 = 순수소프트웨어총개발비 유지보수난이도 (%) 단, 유지보수난이도 (% ) = ACT * ( j i= 1 W i TMP i 100 ) ACT의값은 COCOMO 81 모델에서와같이연간유지보수비율이될수도있 고, COCOMO II와같이수발주자가합의하는일정기간의유지보수비율이될수도 있다. 이는유지보수비용의상한을결정하는것으로수주자와발주자가협의하여 결정할수있다. 문헌연구에의하면디폴트값은 10% 가적당하다고판단된다[20]. TMP i 는유지보수공정의각단계별영향을미치는그룹요소의획득점수이고, W i 는유지보수공정별가중치이다. < 표 3-1> 의유지보수공정을표준공정으로가정 하거나수주자와발주자가합의한공정을기준으로한다. 유지보수공정의각단계 가차지하는공수의비중에따라가중치 W i 의값을부여한다. 유지보수각단계의 생산성요소에의해그룹요소 TMP i 가결정된다. - 96 -
3.6.3 기능점수를이용한규모산정후보정계수적용 비록현재소프트웨어유지보수규모의기준으로기능점수가거의활용되지않고 있지만, 유지보수규모척도로기능점수가가장적합한척도이다[25]. 본연구과제 는기능점수중심의소프트웨어사업대가기준의일환으로유지보수규모의산정에 있어서기능점수의이용이전제가되어야한다. 유지보수기능점수를계산하는기 법은대표적으로 IFPUG 의기능점수기법[2] 과 NESMA 의유지보수기능점수[4] 계 산기법이있다. 단순한에러수정이아닌기능개선및환경적응유지보수의경 우유지보수공정은개발공정의반복이다. 실제사용자요구사항분석및의견수렴을위해실시한설문조사에서도대부분 의발주자와수주자가공히단순한하자보수가아닌유지보수는개발과동일한차 원의노력이소모됨을인식하고있다. COCOMO를비롯해현재활용되는대부분의 비용산정모델들도개발과유지보수비용산정에동일한비용인자를적용하고있 다. IFPUG의표준기능점수기법과 NESMA의유지보수기능점수기법에서도유 지보수전후의값조정인자 (VAF) 를계산하는데이용되는 14개의일반시스템특 성 (GSC) 을동일한것으로간주하고있다[9]. 따라서여기에서제안하는유지보수대가기준은유지보수기능점수를이용하여 유지보수규모를계산한후, 개정소프트웨어사업대가기준의보정계수를적용한 다. 이때소프트웨어사업대가기준의평균복잡도가중치기준을실적데이터를 근거로도출한유지보수공정별기준값을적용한다. 납기보정계수는유지보수의 경우정해진일정기간동안이루어지는작업이므로적용하지않는다. 3.6.4 값조정인자(VAF) 를수정한기능점수적용 안연식등[11] 은기존의소프트웨어유지보수비용산정모델과는달리 10개의값 조정인자(VAF) 를조정하였다. 이는전통적인 IFPUG 기능점수방식과상이한 GSC를이용하여 VAF 를계산하는것으로볼수있다. 안연식등이제안한 SMPEEM 모델에서 VAF 의세가지유형은 < 표 3-5> 와같이 (1) 사람의관점에 서고려하는엔지니어의기술, (2) 제품의관점에서고려하는기술적특성, (3) 프로 세스의관점에서고려하는유지보수환경특성으로구분된다. 첫번째특성의그룹인엔지니어의기술은소프트웨어유지보수에필요한세가 지요인인어플리케이션도메인의지식, 프로그래밍언어에대한친숙함, 시스템소 프트웨어의경험을포함한다. 이요인들은유지보수담당자의역량수준을기술한 - 97 -
다. 만일어플리케이션도메인이잘이해되면, 시스템요구사항은쉽게이해될수 있다. 또한어플리케이션경험, 언어와도구의경험, 플랫폼의경험요인이 COCOMO II 의생산성요인으로고려되었다. 두번째기술적특성그룹은소프트웨어모듈의구조화, 소프트웨어모듈의독립 성, 프로그래밍언어의변경용이성/ 가독성, 레거시소프트웨어모듈의재사용성과 같은네가지요인들로구성된다. 이요인들은프로그램모듈의상태를나타낸다. 어플리케이션의나이와재사용성요인들은소프트웨어의기술적생산성척도로채 택되었다. 마지막특성그룹은유지보수환경으로문서화의최신성, 소프트웨어공학표준 의준수, 시험용이성을포함한다. 이요인들은유지보수프로세스와더욱관련이 있다. 문서화는생명주기요구에일치하고, 프로세스성숙(maturity) 과시험용이성 은유지보수비용을감소시시키는생산성요인으로언급된다. 이들 10가지요인은유지보수프로젝트관리자의관점에초점을맞추어선택되었 다. 기능점수의계산이후에조정을하기위한것이므로예를들어, 유지보수비율, 소프트웨어시스템이나데이터베이스의규모와같은유지보수프로젝트의규모와 관련된일부요인들은배제되었다. 안연식등의 SMPEEM은이단계에서산정된 노력을구하기위한것이므로예를들어, 요구되는노력이나팀의규모와같은산 정의출력척도와관련된일부요인들은배제되었다. 아웃소싱을위한유지보수조 직의특성에관련된일부요인들도또한배제되었는데, 그이유는우리는단지내 부의유지보수프로젝트만고려하기때문이다. 그리고유지보수도구와관련된요 인들을포함시키지않은이유는 [11] 에서모델을유도하기위해기초조사설문에 응답한조직이어떠한자동화된유지보수도구도이용하지않기때문이다. < 표 3-5> VAF의세가지관점 특성그룹 유지보수생산성요인 (1) 어플리케이션도메인의지식 엔지니어의기술 (2) 프로그래밍언어에대한친숙함 (3) 시스템소프트웨어의경험 (4) 소프트웨어모듈의구조화 기술적특성 (5) 소프트웨어모듈간의독립성 (6) 프로그래밍언어의변경용이성/ 가독성 (7) 소프트웨어모듈의재사용성 (8) 문서화의최신성 유지보수환경 (9) 소프트웨어공학표준의준수 (10) 시험용이성 - 98 -
미조정된기능점수에 VAF 를곱해최종적인조정된기능점수가계산된다. SMPEEM에서 10개의 VAF의세그룹은각그룹에대해가중치와각그룹내의 각요인들에대해가중치를각각가진다. 소프트웨어유지보수프로젝트의 VAF는 다음식으로계산된다. VAF = 3 group = 1 [ k factors = 1 scores W f 100 W g 100 ] 여기에서 W g 와 W f 는각그룹과각요인들의가중치이다. Scores는소프트웨어유 지보수프로젝트관리자에의해 0( 가장낮은수준) 부터 5( 가장높은수준) 의값을 취한다. VAF의범위는 0부터 50 까지이다. 이 VAF는미조정된기능점수에곱해져서조 정된기능점수가계산된다. 그대신기능점수는다음식에의해계산될수있는데, 조정범위는 ± δ% 이다. FP = FC(1 - δ 100 )+ ( 2δ 5000 )VAF 여기에서 δ는조정범위의절대값이다. 조정범위는실제의데이터와관련된조직 의반복적인실험에의해결정될수있다. 예를들어, 만일조직이기능점수를 ± 20% 범위내에서조정하기를원하면, 앞의식의 δ는 ±20의절대값으로대치되어 다음식을생성할수있다. FP = FC(0.80 + (0.008VAF )) 앞의식으로부터, 소프트웨어유지보수비용의추정치를계산하는데이용될수 있는조정된기능점수를구한다. VAF = 0 인경우에, 기능점수는미조정된기능점 수의 80% 로계산된다. 반면에 VAF 의최대값(5) 은미조정된기능점수의 120% 를 최종적인조정된기능점수로취하게한다. 따라서앞의식은다양한조정범위내 에서조정된기능점수를산출하게된다. - 99 -
3.6.5 SLA 의적용명문화 소프트웨어유지보수에서유지보수서비스수준협약및관리는매우중요한프 로세스이다. 이프로세스가잘관리되고활용될때소프트웨어유지보수아웃소싱 사업은성공할수있으므로 할수있다. 소프트웨어유지보수 수있다. SLA의적용을필요로하는경우별도의비용을포함 SLA를고려할때비용산정식은다음과같은형태가될 유지보수및유지비용 = 유지보수비용 + SLA 유지비용 Softcost-ADA 유지보수비용산정모델[20] 에서는명시적으로유지비용을유지 (sustaining) 공학이라는이름으로포함하고있다. 이모델의유지보수산정식은다 음과같다. MM an = A * ((MM nom * EAF m * ACT) + (MM nom * SEF a )) 여기에서 MM an = 연간 O&S 단계노력 A = 조정계수 1 MM nom = 명목(nominal) 개발노력 2 EAF m ACT = = 노력조정인자 3 년간변경비율 4 SEF a = 유지(sustaining) 공학인자 5 MM nom = TC * (Size) P1 여기에서 TC = 노력기술상수 SIZE = 소프트웨어시스템의규모 P1 = 노력지수 1 조정계수는비용산정모델의상수, 비용인자, 승수들이결합된효과를나타 낸다. 만일사용자가그값들을바꾸기원한다면, 수작업으로입력할수있다. 2 명목개발노력은소프트웨어시스템을초기에개발하는데필요한노력의양 - 100 -
을나타낸다. 만일개선된산정이나실제값이활용가능하다면, 사용자가그값을 변경할수있다. 3 노력조정인자는유지보수와관련된매개변수를재조정하여결정된다. 4 연간변경비율은유지보수기간동안변경될 SLOC의백분율의추정값으로 실제로는시스템의예정수명에기반을둔평균값이다 ( 즉, 10 년, 20 년등). 예정된 (scheduled) 보수, 수정, 개선과함께계획된방식으로변경된다는것을가정한다. 5 유지공학인자는운영작업에투입될노력의비율산정값이다. 유지공학은 소프트웨어를운영가능하도록유지하는데필요한작업들로정의된다. 이것은사용 자지원과훈련, 시스템소프트웨어와지원소프트웨어의업그레이드, 예정에없는 보수와같은작업들이다. 3.6.6 후보모형의검토 본과제의연구팀은전문가자문팀과유지보수대가기준개선위원들과함께후보소프트웨어유지보수대가기준후보모형에대한검토를통해후보모형을수정하고자체세미나를통해개선된개념모델을선정하였다. 다음은전문가자문팀과대가기준개선위원회의후보모형검토의견을모형별로간략하게요약한것이다. 1 현행용역유지보수대가기준의수정 사용자요구조사분석결과를바탕으로전문가자문팀과대가기준개선위원회의 검토결과현행대가기준의부분적인수정은바람직하지못하다는결론을내렸다. 현행기준이유지보수계약시점에서의개발비산정가의 10~15% 를일률적으로적 용한다는것이모호한점이있고, 유지보수난이도를계산하기위한유지보수대상 시스템의특성평가에도객관적이지못한문제점이있는것은사실이다. 그러나현행기준자체가객관적인근거에의해서개발되었다기보다는하드웨어 유지보수비용이나패키지나시스템소프트웨어의유지보수비용을개발비및구입 가격의 10% 내외에서산정하는현실과유지보수사업이진행되는현장에서관례적 으로진행되어온실제(practice) 를반영하는것에기인하였기때문에, 비과학적으로 - 101 -
유도된기준을과학적인방식으로부분적인수정을한다는것은의미가없다는결 론을내렸다. 개발비산정가에대한일정비율의상한과하한을두는현행기준과유사한모형 이 NASA 의모델[19] 을비롯한일부모형이존재함을고려할때, 현행기준의부분 적인수정보다는유지보수규모산정이불가능한경우개발비의일정비율을디폴트 값의의미로수발주자간의합의와정책적인판단에의해현행기준을부분적으로 적용하는것이대안이될수있다. 2 연간유지보수비율을적용한유지보수비용산정 개발비에대해일정유지보수비율을적용하거나, 개발비에대한비율의상한을 적용하는모형에대해서는발주자측의입장에서는받아들일수있는모형으로검 토되었다. 또한유지보수난이도를현행기준이외에다양한유지보수생산성요인 을반영하는것이개념적으로는타당하고필요한것으로판단되었다. 그러나개발비에대한상한은두지만하한을두지않는방안은발주자측의입장 만을대변하는반면에, 실제다양한유지보수활동을요구하는유지보수사업의특 성상수주자의입장에서수용이매우곤란한모형으로검토되었다. 다양한유지보수생산성요인을반영하는것은개념적으로는타당하더라도, 현실 적으로는불가능한것으로의견이모아졌다. 우선기존의대다수상용선진유지보 수비용산정모델들이개발과유지보수의생산성요인을구분하지않는것에주목 하였다. 기존연구와사례분석을통해유지보수생산성요인이유지보수비용산정 모델에독립적인요소로반영되어야할정도로유의하지않는것으로나타났고, 실 제유지보수업무의특성상유지보수가결국개발의반복적인작업이라는것을고 려할때객관적인계량화된유지보수생산성요인의도출이단기간에불가능하고, 현실적으로타당하지않는것으로검토되었다. 그러나유지보수란본질적으로기존레거시시스템의수정, 개선, 확장등의작업 으로정의되는것이므로, 장기적인관점에서기존시스템의특성을유지보수생산 성요인과연계시키는것이장기적인과제로필요하다는결론을내리게되었다. 3 기능점수를이용한규모산정후보정계수적용 본후보모형은공시예정인소프트웨어사업대가기준의원칙을따르는모형이 다. 즉, 기능점수에의한규모산정을기반으로하는소프트웨어사업대가기준의틀 을유지하는모형이다. 이는기존의선진모델인 COCOMO에서개발의비용요인 - 102 -
(cost driver) 과유지보수비용요인을동일하게간주하고, IFPUG와 NESMA의기 능점수모델에서유지보수전후의 14 개의일반시스템특성(GSC) 을동일한것으로 간주하는것과맥락을같이한다. 본과제의연구팀, 전문가자문팀, 대가기준개선위원회는선진사례분석을통해 이모형이후보모형중에서가장타당성이있는것으로결론을내렸다. 실적데이 터수집을통한모형도출과검증은 4 장에서제시된다. 모형도출방향은유지보수 표준공정의정의후에실데이터를통한단계별공수비중을구하고, 단위기능점 수당비용을유도하는것이다. 유지보수비용은유지보수규모를기능점수로산정 한후에유도된기능점수당비용이곱해진후보정계수가적용되어계산될것이다. 4 값조정인자(VAF) 를수정한기능점수적용 이후보모형은기존의기능점수방식의유지보수비용산정모델과는달리유지 보수시의일반시스템특성(GSC) 이개발과정의일반시스템특성과다르다는것을 전제로, 유지보수되는기존레거시시스템의특성을반영하는모형이다. 그러나후 보모형 2의검토에서논의된것처럼, 후보모형에서제안하는기존레거시시스 템의특성은객관적이고계량화된척도의도출이어려운모호한것이다. 뿐만아니 라기능점수산정에서일반시스템특성자체를반영하지않으려는최근의동향과 일치하지않는것으로선진모형과는방향을다르게하는모형으로후보모형에서 제외하였다. 5 SLA 의적용명문화 유지보수대가기준에 SLA의적용을명문화하려는시도는바람직한것으로검토 되었다. 그러나구체적인 SLA 항목은유지보수시스템의특성이나수주자와발주 자의상황에따라달라져야하기때문에, SLA 적용을명문화하여유지보수비용에 반영하는것이가능하도록하였다. 6 기능점수와공수간의회귀모형 본모형은연구팀이제안한후보모형중에서별도의독립적인모형으로언급되어있지는않았으나, 전문가의검토에의해실데이터수집을통해도출하기로한모형이다. 유지보수비용산정뿐만아니라개발비용산정을포함하는기존의다수의연구에서도규모와공수간의회귀모형은중요한의미를가진다. - 103 -
제 4 장실데이터에의한모형도출및검증 소프트웨어유지보수사업대가는 < 그림 4-1> 과같이사용자요구에의한유지보 수범위를정의하는것에서시작한다. 발주자및수주자가합의하는소프트웨어유 지보수범위에대한정의후표준공정에의한공수를산정하고비용을산정하게 된다. 공수는업계의생산성을기준으로유동적이며비용은시장가격및서비스와 기술수준에의거하여제경비와기술료등을조정한다. 이때앞으로구축될업계의 소프트웨어유지보수비용에관한데이터베이스를근거로합리적인비용을산정할 수있다. < 그림 4-1> 소프트웨어유지보수사업대가개요 4.1 표본의선정및데이터수집 4.1.1 설문조사실시 소프트웨어유지보수대가기준모형을유도하고검증하기위해본연구에서는국내에서수행된소프트웨어유지보수사업에대한실제데이터를수집하였다. 현재비용관련데이터가상당수기업에서철저히보안을유지하고있으며, 또한비용데이터가정확하게관리되고있지않다. 뿐만아니라기업별로소프트웨어유지보수에관한정의및관련업무의실제(practice) 가상이하기때문에본연구팀에서실제소프트웨어유지보수데이터수집에많은어려움을겪었고, 많은비용과시간 - 104 -