Microsoft Word ÀÌÀç±â.doc

Size: px

Start display at page:

Download "Microsoft Word ÀÌÀç±â.doc"

주일 도
5 years ago
Views:

1 소프트웨어프로젝트평가모델을통한소프트웨어메트릭스분석 An Analysis of Software Metrics Using the SPEM(Software Project Estimation Model) 이재기 (J.K. Lee) 신상권 (S.K. Shin) 남상식 (S.S. Nam) 박권철 (K.C, Park) ACE시스템팀책임연구원 ACE시스템팀연구원 ACE시스템팀책임연구원, 팀장네트워크전략연구부책임연구원, 부장 본논문은대형프로젝트를수행하는데있어서필요한리소스, 인력, 개발비용및소프트웨어소스에대한데이터를추정하여프로젝트의효율성을평가하는모델인소프트웨어프로젝트평가모델을이용하여기수행된프로젝트의경험데이터와수행되고있는프로젝트의소프트웨어메트릭스 (metrics) 데이터를활용하여생산성, 품질, 자원투입효과, 개발될소프트웨어소스규모등을추정해보고이를경험적인모델 (empirical model) 에적용하여프로젝트별로평가, 비교분석해본다. 또향후유사프로젝트관리 (similar project management) 에필요한사항들을제안한다. I. 서론 초기소프트웨어가격은시스템전체에서차지하는비율이매우적었기때문에발견되는에러에대한소프트웨어해결비용이매우미약했다. 그러나현재는시스템에서소프트웨어가차지하는가격이매우높기때문에개발비용및효과에대한추정방법에많은관심을기울이게되었다. 이러한관심속에대두된것이소프트웨어의개발규모나기능에대한복잡도 (complexity) 를가지고평가하는소프트웨어생산성모델 (software productivity model) 이다. 다시말해서프로그램의 LOC(Line of Code) 나 FP(Function Point) 수를추정하여소프트웨어의생산성을평가하는프로젝트평가모델 (Project Estimation Model: PEM) 에관심을가지게되었다. 이모델은각각의소프트웨어요소들에대한 size 나 variable 에대한생산성측정 (productivity metrics) 으로때로는과거의프로젝트수행결과로부터얻은정보를이용하기도한다. 다시말해서 cost data, size-oriented data, functionoriented data 등을활용하여소프트웨어의품질 (quality) 이나생산성 (productivity) 에대한평가를하는모델이다 [1]. II. 소프트웨어프로젝트관리 소프트웨어프로젝트관리를성공적으로수행하기위해서는처리할일의양이나자원의관리또는 milestone에대한추적관리, 주어진일정관리및 effort(cost) 분석등이수반된다. 이를성공적으로이끌기위해서는우선소프트웨어프로젝트계획에대한연구 (research) 와추정 (estimation) 이뒤따라야 107

2 전자통신동향분석제 17 권제 5 호 2002 년 10 월 한다. 즉, 소프트웨어각요소에대한범위 (scope) 가정의되고이에대한연구가행해져야한다. 그밖에리소스분석, 생산성및품질에대한소프트웨어메트릭스의분석, 소프트웨어프로젝트추정및분석기술을이용한프로젝트추정, 경험적인데이터를활용한프로젝트분석과자동화된툴에의한추정등이수행되어야한다. 특히양질의소프트웨어를획득하기위한 PERT(Program Evaluation and Review), CPM(Critical Path Method) 을도입한프로젝트스케줄링관리등과소프트웨어조직에대한분석등을통해프로젝트계획의실천이수행되어야한다. 다시말해서소프트웨어관리상의문제로서아래와같은사항이제기된다. 1 scope and resource, technical staff와 customer 간의대화 2 비용와스케줄관리에대한리뷰 3 프로젝트전체에대해참여자에게문서를통한소프트웨어개발에대한접근방법제공등이다. III. 소프트웨어측정 소프트웨어측정 (software metrics) 방법은크게 2가지방법으로나뉘는데첫째직접측정 (direct measure) 으로하나의묶음으로소프트웨어의크기로, 둘째는단위생산 (unit product) 된또는거부된소프트웨어의품질등으로측정이되는간접측정 (indirect measure) 으로나눈다. 직접측정 cost, speed(delivery), effort, LOC, memory size, errors 등을측정 간접측정 function, quality, complexity, reliability, maintainability, efficiency 등을측정위와같이소프트웨어측정에대한범주를정리해보면 ( 그림 1) 과같다. Technical metrics Quality metrics Productivity metrics Software Metrics Size-oriented metrics Function-oriented metrics Human-oriented metrics ( 그림 1) 측정범주 (metrics categorization) Quality metrics 사용자요구사항에대한소프트웨어의품질척도를 explicit & implicit 하게표시 Productivity metrics 소프트웨어엔지니어링절차에대한출력에초점을둠 Technical metrics 논리적복잡도나모듈화정도등소프트웨어의특성에초점을둠 Size-oriented metrics 소프트웨어엔지니어링절차에따른산출물을직접측정하여수집함 Human-oriented metrics 개발자의태도나툴또는방법등에대한효율성에대한정보수집 Function-oriented metrics 간접측정에의한정보로품질, 신뢰도, 복잡도, 유지보수성등이속한다 [2],[3]. 1. Size-Oriented Metrics 개발절차나소프트웨어에대해직접측정하는방법으로생산성, 품질, 비용, 문서화에대해 (1)~(4) 로표시할수있다. 1 생산성 (productivity) = KLOC/person-month (1) 2 품질 (quality) = error/kloc (2) 3 비용 (cost) = $/KLOC (3) 108

3 소프트웨어프로젝트평가모델을통한소프트웨어메트릭스분석 4 문서화 (documentation) = pages document/ KLOC (4) 2. Function-Oriented Metrics 프로그램의기능성 (functionality) 이나유틸리티 (utility) 에대한측정방법으로 1979년 Albrecht에의해제안된방법으로프로그램의복잡도나소프트웨어의 information domain에대한측정등을카운트하는경험적인방법 (empirical study) 이도입된다. 즉, 입 출력수, 파일개수, 외부인터페이스수, 사용자질의수등이관련되며, 기능수 (FP) 는아래와같은관계식으로표현된다. 그후 1983년에 Albrecht and Gaffney[AG83] 에의해서수정, 제안되었다. FP = count.total [ SUM(F i )] F i : complexity adjustment value(i = 1 to 14) 이모델의생산성, 품질, 비용, 문서화에대한추정식은 (5)~(8) 로표현된다. 1 생산성 (productivity) = FP/person-month (5) 2 품질 (quality) = error/fp (6) 3 비용 (cost) = $/FP (7) 4 문서화 (documentation) = pages document/ FP (8) 그밖에언어별 FP에대한 LOC 규모는 < 표 1> 과같다. < 표 1> 언어별 FP에대한 LOC 규모 언어 (language) LOC/FP COBOL 110 PL/1 65 4GL LOC and FP Estimation 소프트웨어프로젝트를추정하는방법은소프트 웨어규모 ( 혹은크기 ) 나과거에수행한프로젝트로부터얻은 baseline 메트릭스로서개발비용이나효과에대한변수들을추정하여적용하는방법이있다. 즉, FP에의한간접추정시 14개의복잡도조정값들 (complexity adjustment values) 을적용하는데이와같이예상이되는추정값들을조정하여 (weighted) 환경변수에따라최적 (optimistic), 보통 (most likely), 열악 (pessimistic) 으로추정하는프로젝트수행효과 (E) 는아래와같이표현된다. E = (a+4m+p)/6 a: optimistic, m: most likely, p: pessimistic 즉, LOC 또는 FP로표현되는추정자 (estimation factor) 로서 [4] 프로젝트에서개발된소프트웨어규모가 130만라인이라하면 Esterling에의해 1980년도에제안된 time-study model에서추출된 < 표 2> 의파라미터를적용해보면 E = ( )/6 = 0.1 KLOC/PY PY: Person-Year 가된다. 다시말해서 ACE2000 시스템인경우실제프로젝트에참여한프로그래머가 20명, 총소프트웨어규모 (LOC) 가 130만라인으로개발자 1명이한달에약 440 LOC 정도의프로그램을개발한셈이된다. < 표 2> Values for Esterling model parameters Programmers Parameter Range Workers Optimistic Typical Pessimistic a 0~ Empirical Estimation Models 이모델은프로젝트단계별 ( 또는개발순기 : project life cycle) 로요구되는소프트웨어예측데이터를사용하여추정하는모델이다 [5]-[8]. 이때적용되는경험데이터는단일프로젝트 (single project) 수행시얻어진데이터로한정될수밖에없어 109

4 전자통신동향분석제 17 권제 5 호 2002 년 10 월 정확한데이터추정에어려움이많지만개발환경이나소프트웨어의모든클래스에적용함으로써프로젝트수행에필요한판단근거를제시하는데활용이많은모델이다. 여기에속하는대표적인모델로는자원평가모델 (resource estimation model), 시간추이모델 (time study model), COCOMO 모델 (Constructive COst MOdel), Putnam 모델등이있다. 가. 리소스모델 (Resource Model: RM) 하나또는그이상의수식으로표현되는모델로서예측자원투입효과 (predict effort), 개발기간 (project duration), 타프로젝트의예측데이터 ( 경험데이터 ) 등을토대로 single-variable, staticmultivariable, dynamic-multivariable model 등으로구분되며, 1980년 Basili에의해제안되어다양하게평가되는모델이다. - Single 변수모델식 C R = C 1 (estimated characteristic) 2 C 1, C 2 : 과거프로젝트로부터얻은경험데이터 estimated characteristic: effort(e), project duration(d), staff size(s), software documentation(doc), etc. 나. Walston & Felix[WAL77] 모델 이모델은 60여개의프로젝트로부터 ( 소스규모는 4,000~467,000라인, 참여자규모는 12~11,758 PM 정도 ) 수행된결과를토대로설정한평가모델로여기서추출된데이터는 (9)~(13) 으로표현된다. E = 5.2 L (9) D = 4.1 L (10) D = 2.47 E (11) S = 0.54 E (12) DOC = 49 L (13) E : effort(person-months : 자원투입량 ) DOC : pages of document( 문서작성분량 ) L : source lines(kloc : 소스규모 ) D : duration(calendar months : 프로젝트기간 ) 다. 비용평가모델의 COCOMO 모델 Boehm에의해 1982년에제안된 cost estimation 모델로소프트웨어의비용또는개발자원투입량 (development effort) 을평가해보는대표적인비용평가모델이다. 이모델은 basic, intermediate, advanced model 등 3가지로구분제안하고있으며, 다양한프로젝트성격에따라서 organic( 소형프로젝트에적합 ), semi-detached( 중형프로젝트에적합하며, 데이터베이스시스템을사용 ), embedded mode( 대형프로젝트에적합하며, 자체개발환경을가지고수행 ) 로클래스를달리하고 (< 표 3> 참조 ) 15개의 cost driver 를사용하여 6단계의범위 (scale) 로 EAF(Effort Adjustment Factor) 를두어평가한다. 기본모델식은 (14)~(16) 과같다. E = a b (KLOC)exp(b b ) (14) D = c b (E)exp(d b ) (15) E = a i (KLOC)exp(b i )EAF (16) E : effort-person month, D : project duration, EAF : range(0.9~1.4) < 표 3> Intermediate COCOMO 모델 Software project a i b i Organic Semi-detached embedded COCOMO-II PA(Post-Architecture) 모델개발된소스를가지고규모요인 (scaling driver) 과가격요인 (cost driver) 등을이용하여프로젝트의생산성, 가격등을결정하는모델이다. 110

5 소프트웨어프로젝트평가모델을통한소프트웨어메트릭스분석 E( = MM) = A (KLOC) B 17 EM EM i : effort multipliers of cost driver B : multipliers scaling driver A : constant 즉, 소프트웨어개발에필요한소요공수 (E: Ef fort in Man-Months, 또는 MM으로표기 ) 의예측및비용산정을목적으로 1981년 Dr. Barry Boehm 에의해최초의 COCOMO가제안되었으며, 현대의발전된정보화기술을반영하여 1995년수정된모델인 COCOMO-II 모델이소개되었다. COCOMO- II 모델은시스템개발순기중각단계별로다음과같이세가지모델을적용할수있다. Application Composition 모델개발초기프로토타입시제품개발시적용할수있는모델 Early Design 모델개발될제품의규모를알기어려운프로젝트의초기단계에기능점수 (function point) 와같은사이징메트릭을이용하는모델 PA(Post-Architecture) 모델프로젝트개발이완료되어소프트웨어규모및가격요인들을정확하게적용할수있는모델또프로젝트의소프트웨어개발규모를알고있는경우는 PA 모델적용이가능하며, PA 모델에서고려할변수들은다음과같다. Total source line 수 (SLOC) 규모요인 Precedent, Flexibility, Process Maturity, Architecture/Risk Resolution, Team Cohesion 가격요인 - Product Factors: Required Software Reliability, Database Size, Product Complexity, Required Reusability, i i Documentation Match to Life-cycle Needs - Platform Factors : Execution Time Constraint, Main Storage Constraint, Platform Volatility - Personnel Factors: Analyst Capability, Programmer Capability, Application Experience, Programmer Experience, Language and Tool Experience, Personal Continuity - Project Factors : Use of Software Tools, Multi-state Development, Required Development Schedule 그외에인건비산출은아래의식으로표현된다. 직접인건비 = 소요공수 (MM) 기술자의월급여 위에서소개한변수들외에요구사항의변경으로일부코딩되었던부분을수정해야하는경우 Breakage 변수를고려할수있으며, 기존의소프트웨어를수정해서재사용할경우기존소프트웨어의수정된비율 (percent design modified, percent code modified, percent of integration required), 소프트웨어의이해정도 (software understanding) 등의변수들이고려된다. 라. Putnam estimation model 이모델은 1978년도에 Putnam에의해제안되어동적다변수모델 (dynamic multivariable model) 로서전체프로젝트수행기간중각분야별 ( 요구사항분석및설계, 기능구현, 시험, 문서화 etc.) effort 분포를추정할수있는모델이며, 대형프로젝트에 < 표 4> State of Technology Constant(C k) C k Software development environment ~ 2,000 Poor ~ 8,000 Good ~ 11,000 Excellent 111

6 전자통신동향분석제 17 권제 5 호 2002 년 10 월 투입되는인력분포의특징을알수있는유용한모델이다. 특히인력 (manpower) 분포곡선이 Rayleigh 분포를나타내는것이특징이다. 이모델의추정식은아래와같이표현되며, 개발환경지수는 < 표 4> 에언급된값이적용된다. L = C k K 1/3 T 4/3 d, K = L 3 4 /C k T d L : source line C k : state of technology constant(2,000~ 11,000) K : effort expended(person-years) over the entire life cycle for software development & maintenance T d : project 수행기간 (year) 마. Time study model Esterling[EST 80] 에의해제안된생산성모델로개발환경특성을적용한모델이다. 특히이모델은회의등비생산적인활동변수와근무시간 [1일 8 시간기준 ] 외초과근무에대한변수들을고려하였다. 변수들에대한상세내역은 < 표 5> 에나타내었다. w = 0.125[8-8a+g-4r/60p(t+r)/60-k(n-1)(t+r)/ 60] (17) T = 7/5nw (18) c = ns[gd +8(1+i)] (19) E = nw/c (20) C = c/nw (21) w : useful working time per work day-per person T : ratio of calendar time to person days to complete project c : labor cost per work day for an average base salarys E : cost efficiency C : project cost per person day n : project 참여인원 g : over-time working day/day < 표 5> Values for Esterling Model Parameters [EST 80] Programmers Parameter Range Workers Optimistic Typical Pessimistic a 0~ t 1~ r 5~ k 1~ p 1~ i 1~ d 1~ a : average fraction of workday( 운용또는간접활동에소비하는시간 ) t : average duration of work interruptions (minute) r : average recovery time after interruption k : number of interruptions/workday( 프로젝트에직접참여하는사람 ) p : number of interruptions/workday( 다른원인으로부터영향받는경우 ) i : indirect cost/person( 기본연봉기준 ) d : differential pay for overtime( 기본연봉기준 ) 5. 프로젝트수행에소요되는자원투입 (effort) fort) 분포현황 일반적으로각각의소프트웨어프로젝트추정법에의거하여 effort 분포를살펴보면 ( 그림 2) 와같은분포를이루는것으로밝혀졌다 [1]. 즉, 소프트웨어를설계 ( 분석 ), 구현, 시험하는데 40/20/40% 가소요되는것으로보고되었으며, 대부분의소프트웨어프로젝트평가모델분석결과도이와유사하게 coding 20% testing 40% design & analysis 40% ( 그림 2) 자원투입의분포 112

7 소프트웨어프로젝트평가모델을통한소프트웨어메트릭스분석 분석되어발표되고있다. IV. 프로젝트적용결과 IV장에서는과거에경험한데이터를참고로신규프로젝트에대한개발비용, 에러수, 생산성규모, 기술문서작성등문서화율에대한자료를가지고프로젝트평가모델에적용한결과를추정하고각프로젝트 (ACE64/256/2000 시스템 ) 별로데이터를비교, 분석해본다. 그대상은아래와같다. ( 데이터분석대상 ) 1 개발비용평가 2 에러수 3 생산성규모 (KLOC) 4 기술문서종류및분량 1. 문서작성현황과소프트웨어메트릭스기술문서작성형태는시스템개발에직접적으로관련된문서와개발에간접적으로지원되는문서로나눈다. < 표 6> 은시스템개발에직접영향을미치는기술문서중핵심이되는문서의작성현황에대한일부분으로새로운프로젝트가진행되면서유사한개발환경에서는설계문서나세부기능구현에필요한문서들의양이많아지는경향을보였다. 이이유는초기시스템설계시고려치못했던내용에대한기술과추가보완작업이이루어진결과라할수있다. 새로운설계개념도입과개발환경의변화를시도한 ACE2000 프로젝트인경우는앞서경험한프로젝트에비해전반적으로문서작성량이줄어드는경향이있는데시스템의상세설계문서의작성분량 은늘어난반면기타문서들은정보의분산화와재활용 (re-use) 및변경 (change) 기법을사용하여필요시해당부분만가져다가사용하는방법을택했다. 이러한예는입 출력메시지에대한데이터를참조하면쉽게알수있다. 핵심기술문서에대한작성현황및소프트웨어종합결과는 < 표 6>, < 표 7> 과같다. < 표 7> 의결과를살펴볼때시스템규모 (1랙기준 2.5G 40G 증대 ) 가확장되는경우에도펌웨어종류가축소되어사용되고있는컴포넌트수가별로증가하지않은이유는초기시스템 (ACE64) 개발시다양한개발환경에서개발되던 device control 용소프트웨어인펌웨어의개발환경을점차동일한그룹으로통합, 관리함으로써소스관리의용이함과동일환경하에서응용프로그램 (application program) 만교체하고핵심 (core) 부분인 operating system(os) 은통합시켜시스템개발기간을단축시켰으며, 시스템의유지보수성을향상시켰다. < 표 8> 은각프로젝트별소스라인규모및에러, 품질및투입된소프트웨어인력, 개발비용등에대한측정결과로초기시스템에비해최종시스템의품질과 KLOC 당에러발생수, 개발비용의효율성, 생산성등이향상되고있음을단적으로보여준다. 즉, 소프트웨어개발인력에대한변동률은거의변화가없는반면에프로젝트수행효율성이경험의축적및개발툴의향상, 개발환경의개선에따라이전에수행한프로젝트에비해효과가상당히향상되고있음을말해준다. < 표 9> 및 < 표 12> 의두모델에대한프로젝트별평가결과는다소차이가있으나우리가수행한프로젝트의성격에적합한 COCOMO-II PA 모델과 < 표 6> 기술문서작성현황 Project Rel. 설명서 기능규격서 기능설계서 블록규격서 블록설계서 imd omd ACE64 141(1.5) 324(5.79) 324(7.86) 122(6.14) 122(13.11) 376(7.5) 480(8.3) ACE (3.5) 184(9.38) 184(17.17) 144(9.31) 144(17.15) 418(3.4) 539(6.7) ACE (2.5) 148(6.7) 148(7.83) 157(9.42) 157(17.92) 678(2) 770(2) 주 ) 괄호안의숫자는페이지수 ( 평균값적용 ) 113

8 전자통신동향분석제 17 권제 5 호 2002 년 10 월 < 표 7> 프로젝트별소프트웨어종합결과 ACE64 ACE256 ACE2000 Remark Function 116종 250종 148종 S/W Block 129개 132개 137개 S/W(TMN 제외 ) Firmware 24종 19종 7종 Device 제어용 Component 7,220( 개수 ) 7,034( 개수 ) 8,769( 개수 ) S/W SLOC 1,990,312 2,168,760 2,480,888 DB/OS/FPGA 제외 < 표 8> Analysis of Software Metrics for Systems Project Size(KLOC) Error Quality Manpower( 인력 ) Cost( 억원 ) ACE /KLOC 29 PY( 순수 S/W 개발인력 ) Y(6.5 년 ) 1,178 억 (117,864) ACE /KLOC 26 PY( 순수 S/W 개발인력 ) Y(2.5 년 ) 246 억 (24,629) ACE /KLOC 22 PY( 순수 S/W 개발인력 ) (1.5 년 ) 129 억 (12,948) 주 1) Cost 중 ACE64 의 1998 년은 50%, ACE256 의 1998/2000 년은 50%, ACE2000 의 2000 년은 50% 임 2) Size 는 OS/DBMS/TMN/F/W 기능은제외 ( 순수응용프로그램만적용 ) 3) 인력은순수 S/W 개발인력 (H/W 는제외 ) 4) 총투입비용은 10 년간 1480 억 [148,211( 백만원 )] < 표 9> 비용평가모델 COCOMO 모델적용분석결과 ( 단위 : PM) Project Effort(E) Duration(D) BM IM PA BM IM PA Rpmp (E=MM) ACE ACE ACE 주 ) BM: Basic Model, IM: Intermediate Model(EAF 고려, EAF=1.15 적용 ) PA: Post-Architecture model, Rpmp: Real project man-power( 평균값적용 ) Walston & Felix 모델을상호비교해보면개발기간 (D) 은 COCOMO 모델이 1.15~2.5배적게, 자원투입비 (E) 는반대로 1.7~1.85배정도높은것으로추정되었다. 실제프로젝트수행기간 (< 표 12> 참조 ) 과비교할경우는개발기간은 COCOMO 모델이자원투입은 Walston & Felix 모델이더근접한것으로추정된다. 그러나초기시스템에대해서는개발기간은반대로된다. 정확한데이터추정을위해서는 WF 모델및 COCOMO 모델파라미터에대한연구가좀더필요하다. 2. 소프트웨어생산성분석결과과거초기에개발된소프트웨어를가지고소프트웨어생산성분석에대한시도 ( 과기부모델및 CO- COMO-II PA 모델과의비교, 분석 ) 가있었으나지속적인연구가없는실정이다 [9]. 소프트웨어생산성결과는 < 표 9> 에서추정된내용을가지고 (22) 에적용하면쉽게계산할수있다. 추정된결과와실제프로젝트에서얻은결과를비교해볼때 COCOMO 모델보다는 Esterling 모델 (EST) 이더근접한결과로나타났다. 이는대형프로젝트에적합한모델로서 COCOMO 모델의 BM, IM, PA 모델이 EST보다근접하지못한원인은가격요인및규모요인에대한정확한값의결정에어려움이있기때문인것으로추정된다 [9]. 그밖에정보통신부모델에적용하여프로젝트별생산성을분석해보면 125~130SLOC/MM 정도로분석되었다. 정보통신부모델에의한소프트웨어생산성 114

9 소프트웨어프로젝트평가모델을통한소프트웨어메트릭스분석 - 기초소요공수 (MM) = (SLOC/10만 ) 10만라인기준기초소요공수 (MM) - 보정된소요공수 (MM) = 기초소요공수 개발언어별보정계수 규모별보정계수 프로젝트형태별보정계수 적용대상기종별보정계수 * 소프트웨어생산성 = 총개발소스 (SLOC)/ 보정된소요공수 (MM) P = SLOC/E, p : productivity (22) FP에의한프로그램생산성평가는 4GL 기준으로볼때 < 표 10>, < 표 11> 에언급된것과같이추정되었다 [12]. < 표 11> 의내용은 ACE256/2000 프로젝트에대한데이터로대형교환시스템의대표기능인호제어, 운용, 보전기능에대한샘플링분석데이터이다. 이결과는실제프로젝트수행결과로생성된코드와비교시프로젝트별로 0.58~3.73배정도차이 가난다. 즉기능별로적용된 FP 수가평균값을적용하였기때문에실제상황과는다소차이가있음을밝혀둔다. 시스템개발초기의데이터를가지고평가한과거데이터와비교시 COCOMO-II의 PA 모델은프로그램생산성이비슷한반면 EST 모델과는많은차이를보인다. 특히자원투입량을가지고평가한생산량은상대적으로낮아지는경향을보이는데이는현실과맞지않고점차증가되는추세를보이는 EST 모델이실제프로젝트수행결과와유사한경향을보인반면경험모델의대표적인 LOC 모델과비교할때약 2배정도차이가난다. 이러한차이는 < 표 12> 의 Putnam 모델에서도발견되는데, L값 ( 프로젝트총수행기간동안생산될프로그램규모 ) 을보면실제수행된결과 (real code) 와약간의차이가난다. 이원인은유사시스템개발에따른소스코드의재활용및개조 (ACE2000 시스템인경우기완료된 ACE256 소스코드를활용하여소프트웨어전 < 표 10> 시스템및모델별 S/W 생산성비교 ( 단위 : SLOC/month) Project BM IM PA Rpmp EST 정통부모델 ACE ACE ACE 주 1) PA(A=2.45, B=1.15, cost driver=0.7 적용 ) 모델은 COCOMO-II 모델을의미함 2) EST: Esterling model(loc & FP 로평가 ) < 표 11> Function Point 측정모델에의한 S/W 생산성비교분석결과 버전별규모 (SLOC) 파일수 FP 추정치 Function category Language Avg. FP SV , ,748 CHILL 9.58 SV , ,325 CP (Call Processing) C/C SV , ,495 C/C SV , ,827 CHILL SV , ,210 Ad (Administration) C/C SV , ,506 C/C SV , ,150 DH C 2.53 SV , ,650 (Data Handling) C 2.65 SV , ,123 OM C/C SV , ,802 (Maintenance) C/C 주 1) Avg. FP는기능블록내평균제어문수로평균값임 2) FP 추정치계산식 = 파일수 Avg. FP 수 25(4GL), SLOC는실제개발된소스코드 3) SV5.1.2는 ACE256, sv7.1.x는 ACE2000 프로젝트에서수행된결과임 115

10 전자통신동향분석제 17 권제 5 호 2002 년 10 월 체에대해약 17.2% 정도개조, 16.3% 재활용함 ), 개발경험의축적등에의한개발기간의단축에따른원인으로추정된다. 특히, ACE256 인경우는개발환경의변화없이사용된언어도동일한 CHILL- Language를사용함으로인해 ACE64에서개발된코드를거의재사용하였으며, ACE2000 시스템은위에언급한것과같이일부코드 ( 주로호제어관련프로그램 ) 를재활용하고새로운개발방법론 ( 즉, 설계방법으로 UML(Unified Modeling Language) 을사용하고미들웨어를사용 ) 을채택하여소프트웨어개발플랫폼을통일하였다. 즉다양한 OS 환경을일관된환경으로동작시키기위해미들웨어를사용하고 M&A 프로그램을교환시스템에서워크스테이션으로분리, 독립시켜개발일정을앞당기는방법을채택하였다 [10]-[12]. 프로젝트수행기간인개발일정은실제수행결과가추정된결과보다상당히적게나타나는데 ACE64인경우에만추정치보다 30개월정도더소요된것으로분석되었다 (< 표 13> 참조 ). 이것은초기시스템개발에대한경험부족과 PSTN(Public Switched Telephone Network) 위주의개발경험을바탕으로새로운환경으로의방향전환, 하드웨어의존이심한 ATM 교환기술에대한기술축적미비로인한시행착오반복, 시제품개발에따른시범서비스운용후상용제품개발등으로이루어진개발일정으로타프로젝트에비해개발기간이상대적으로길어졌기때문이다. 즉, 개발기간은단축되었으나 release 이후사후 A/S 등을고려할때실제기간은모델추정치와근사한것으로나타났다. 실례로 ACE256인경우소프트웨어배포후추가보완기간 (18개월) 을가져실제수행기간은약 48개월정도이다. Effort 적용시개발기간은더욱줄어드는경향을보이며기간의오차는 1.2배정도차이, 실제수행결과와는 1.2~2배정도의차이를보인다. 또각프로젝트별 documentation 비율을살펴보면 < 표 6> 의핵심기술문서에대한문서화작성현황데이터를참고로하여 W&F 모델에의해추 정하면 < 표 14> 와같다. 핵심기술문서는시스템구조도, 요구사항문서, 시험절차서및결과서, 변경요구관리문서등많은종류가있으나이는전체문 < 표 12> Putnam 모델적용결과 Project C k (=good) L(SLOC) Real code ACE64 8, , K ACE256 8,000 1,129, K ACE2000 8,000 1,303, K 주 1) C k : state of technology constant 2) K: development effort for the entire life cycle < 표 13> W&F 모델적용결과 Project E(effort)- PM K Remark 1st develop. ACE64 소스 reuse ACE256 소스 reuse D(duration/month) D (effort 적용시 ) S(staff) ACE (78) (1명) ACE (30) (1명) ACE (18) (1명) 주 1) D의괄호안의숫자는실제프로젝트수행기간임, 스태프는프로 젝트관리책임자를의미함 2) PM: Person-Month < 표 14> W&F 모델에근거한문서작성비율 project 문서작성분량 (PD) D( 추정치 ) - page 비율 (PD/D) ACE64(1) 13,786 51,284 27% ACE256(2) 14,308 59,615 24% ACE2000(3) 9,701 68,966 14% 주 ) PD: Practice Documentation, D: Documentation page 80,000 70,000 60,000 50,000 40,000 30,000 20,000 10,000 0 documentation ratio ACE64 ACE256 ACE2000 project name 실측 추정 116

11 소프트웨어프로젝트평가모델을통한소프트웨어메트릭스분석 서의 30% 정도이며, 그밖에많은문서들다시말해서직 간접으로시스템개발에필요한문서를작성하게된다. 즉, 프로젝트가거듭될수록문서화비율은적어지는데이는경험데이터축적및개발기간단축등을골자로핵심세부설계문서작성분량은늘어나는반면에시스템개발에필요한간접적인문서의작성비율을줄여나가시스템개발의효율성을높이고있음을보여준다. 또한과거에수행한프로젝트들이중복적인요소에대해서문서작성비율이높은반면가장최근에수행되고있는프로젝트 (ACE2000) 는정보의분산공유및재활용으로비슷한내용의문서분량을과감히줄여프로젝트수행의효율성및개발자의부담을경감시켰으며, 문서표준화와관리툴의효율적인사용으로과거개발문서작성에많은시간을투자하고도크게활용되지못하였던것을관리의일원화를통해개발기간단축및불필요한사항을줄임으로써문서작성의효율성을향상시켰다. 이러한현상은 ATM 교환시스템 이라는유사한프로젝트를연속수행한결과로비슷한기능의구현이많았던점이다. V. 결론 다양한소프트웨어프로젝트평가모델중소프트웨어의개발과정을투명하고효율성있게밝힐수있는모델이생산성평가모델이다. 이모델은소프트웨어가시간에따라안정화되어가는과정을평가해보는신뢰도성장모델과는달리프로젝트전체에대해그효율성을평가해보는모델로서그의의가크다. 특히, 신뢰도성장모델이개발된또는개발과정에있는소프트웨어의안정도및품질을평가해보는반면프로젝트생산성평가모델은프로젝트전체에대한비용, 품질, 생산성, 문서화상태등을다각도로여러측면을평가할수있는모델로서실제프로젝트를수행하는데실무측면에서매우활용이큰모델이라할수있다. 그러나이모델의단점은여러변수 (cost driver & size factor etc.) 에대 한값의미묘한차이에도그파급효과가크다는것이다. 이와같은단점을극복하려면실제프로젝트의성격을정확히파악하고모델적용변수들에대한설정값에유의해야한다. 즉, 과거의유사프로젝트수행시경험한경험데이터들을활용하여정확한추정이되도록노력해야한다. 향후연구방향은다양한프로젝트의수행결과를정리하고프로젝트성격에맞는적합한모델을개발하여차기유사프로젝트수행시프로젝트에대한예측, 평가의기초모델로발전시켜야한다. 참고문헌 [1] Roger S. Pressman, Software Engineering : A Practitioner s Approach, McGRAW-HILL series in Software Engineering and technology 2 nd edition, 1987, pp [2] A.J. Albrecht, Measuring Application Development Productivity, Proc. IBM Applic. Dev. Symposium, Monterey, CA, Oct. 1979, pp [3] A.J. Albrecht and J.E. Gaffney, Software Function, Source Lines of Code and Development Effort Prediction: A Software Science Validation, IEEE Trans. Software Engineering, Nov. 1983, pp [4] R. Esterling, Software Manpower Costs: A Model, Datamation, Mar. 1980, pp [5] C. Walston and C. Felix, A Method for Programming Measurement and Estimation, IBM System Journal, Vol. 16, No. 1, 1977, pp [6] L. Putnam, A General Empirical Solution to the Macro Software Sizing and Estimation Problem, IEEE Trans. Software Engineering, Vol. 4, No. 4, 1978, pp [7] B. Boehm, COCOMO-II Model Definition Manual, Univ. of Southern California, [8] B. Boehm, Software Engineering Economics, Prentice Hall, [9] 이재기외 2, 소프트웨어이식성분석과생산성평가, ETRI, 전자통신동향분석제14권제5호, , pp [10] 이재기외 3, 교환소프트웨어복잡도연구, ETRI, 전자통신동향분석제17권제2호, , pp

12 전자통신동향분석제 17 권제 5 호 2002 년 10 월 [11] 이재기외 3, 미들웨어와 UML을활용한교환소프트웨어의개발과관리, ETRI, 전자통신동향분석제16권제5호, , pp [12] 이재기외 3, 통신소프트웨어의복잡도분석사례연구, 대한전자공학회하계학술대회논문집 1권, Vol. 25, No. 1, , pp

SW¹é¼Ł-³¯°³Æ÷ÇÔÇ¥Áö2013

SW¹é¼Ł-³¯°³Æ÷ÇÔÇ¥Áö2013 SOFTWARE ENGINEERING WHITE BOOK : KOREA 2013 SOFTWARE ENGINEERING WHITE BOOK : KOREA 2013 SOFTWARE ENGINEERING WHITE BOOK : KOREA 2013 SOFTWARE ENGINEERING WHITE BOOK : KOREA 2013 SOFTWARE ENGINEERING