KSEJW_재공학을 위한 레거시시스템의 이해_최종제출용

재공학을 위한 레거시시스템의 이해: 사례연구 545 재공학을 위한 레거시시스템의 이해: 사례연구 (Understanding Legacy systems for Reengineering: a Case Study) 김 진 태* 김 수 현† 강 승 미‡ (Jintae Kim) (Suhyun Kim) (Seungmi Kang) 요 약 시스템의 유지보수 및 재공학(Reengineering)은 프로그램을 이해하는 활동으로부터 시작된다. 이러한 프로그램의 이해는 현재 시스템의 구조에 대한 인식뿐 아니라 구현대상 아키텍처를 개발하기 위한 근간이 되는 활동이다. 본 논문은 소프트웨어 품질 향상과 시스템 리엔지니어링을 위하여 C 언어 기반의 프로그램을 체계적으로 분석한 사례연구를 소개한다. 사례연구를 위해 사용된 시스템은 초고속 네트워크 스위칭 시스템이다. 초고속 네트워크 스위칭 시스템은 1,865,704 LOC, 2,510개의 파일, 21,073개의 함수로 구현되어 있다. 본 논문은 초고속 네트워크 스위칭 시스템 사례연구를 통해 C 프로그램의 이해를 위한 항목, 측정지표, 분석 프로세스를 소개한다. 또한 사례연구를 통해 얻어진 프로그램 이해를 위한 일반적인 원리와 교훈을 설명한다. 키워드 : 재공학, 역공학, 레거시시스템분석, 소프트웨어 메트릭 Abstract Program understanding is the first activity in maintenance and reengineering. This activity is to determine its current structure and use it as a basis for developing a target architecture. We describe a case study in which we systematically understand existing C programs in order to increase the quality of software and re-engineer the systems. We chose an application consisting of over 1,865,704 source lines of C code, over 21,073 functions and over 2,510 files. We describe metrics for understanding, our process for analyzing, the detailed steps involved (some of which can be automated), as well as some lessons learned and perceived limitations with the languages, techniques and tools we used. Key words : Reengineering, Reverse Engineering, Legacy System Analysis, Software Metrics 1. 서 론 1. Legacy System Analysis 3. Restructuring & Re-factoring 재공학(Re-engineering)은 “ 소프트웨어를 새로운 Analyze Legacy Architecture Restructure & Re-factor Analyze Legacy Code Legacy Code 형태로 재구성하기 위한 진단 및 변경” 으로 정의될 수 Verify System 있다[1]. 재공학을 통해 얻을 수 있는 잇점은 다음과 같다. 2. Top- Down Decomposition 첫째, 아키텍처의 의도대로 소스코드가 작성되었는지를 Design Reference Architecture 4. Component Building 확인할 수 있다. 둘째, 새로운 요구사항을 기존 시스템에 Design Alternative Architecture 반영하여 신규 시스템 개발을 통한 비용 발생을 방지할 Certify Components 수 있다. 일반적으로 재공학은 레거시시스템 분석, 참조 아키텍처 설계, 기존 소스코드 리팩토링, 검증 단계를 Register 거쳐 진행된다. SSCCDDBB * 정 회 원 : 삼성전자 정보통신연구소 그림 1. 재공학 프로세스와 논문의 범위 [email protected] 본 논문은 초고속 네트워크 스위칭 시스템에 대한 † 비 회 원 : 삼성전자 정보통신연구소 재공학 프로젝트 중 레거시시스템 분석을 중심으로 [email protected] 소개하며, 특히 레거시시스템의 이해를 위한 측정 항목과 분석 프로세스 및 분석활동을 통해 얻어진 일반적인 ‡ 비 회 원 : 삼성전자 정보통신연구소 원리와 교훈을 중심으로 설명한다. 그림 1은 재공학 [email protected] 프로세스 중 본 논문이 언급하는 범위를 나타낸다. 사례연구를 통한 본 논문의 특징은 3 가지 설명할 수 있다.

546 정보과학회논문지: 정보통신 제 31 권 제 6 호(2004.12) 1) 레거시시스템 분석을 위한 측정항목을 정의하였다. LOC 로 구현되어 있다. 분석대상 시스템은 90 명 이상의 C 프로그램을 이해하기 위해 필요한 항목들을 개발자가 참여하고 있다. 정의한다. 사례연구에서 사용한 분석 항목은 설계문서와 소스코드간의 구조일관성(Design-code 3. 사례연구의 방향 traceability), 함수 복잡도(Function complexity), 함수 3 장에서는 레거시 시스템을 분석하기 위한 항목 및 호출의 깊이 (Function call depth), 패키지 의존성 (Package dependency), 전역변수 참조관계(Global 분석 프로세스에 대해 기술한다. 기술된 분석항목과 reference), 미사용 데이터(Unused data)이다. 프로세스는 논문에서 제시된 사례연구에 적용되었으며, 분석대상 레거시 시스템의 이해를 위해 최적화되었다. 2) 레거시시스템 분석을 위한 프로세스를 제안하였다. 재공학에서 다루는 레거시시스템 분석은 구체적인 3.1 측정항목 프로세스가 제시되지 않아 실무에 적용하는데 본 사례연구에서 정의된 측정항목은 표 1에서 명확하기 않다-특히 레거시 시스템 분석의 프로세스는 분석하고자 하는 항목을 어떤 순서에 나타나는 바와 같이 ISO/IEC9126 에 제시된 품질속성 중 의해 이해해야 하는지가 언급되어야 한다. 제안된 유지보수성 (Maintainability) 과 효율성(Efficiency)을 프로세스는 이러한 고려사항을 반영하여 작성되었다. 중심으로 작성되었다 [2]. 3) 유지보수성을 높이기 위한 설계와 구현의 원리를 표 1 측정항목과 ISO/IEC9126 과의 관계 정리하였다. ISO/IEC9126 품질속성 측정항목 본 논문은 사례연구를 통해 얻은 교훈을 기초로 개발 초기 단계부터 유지보수성을 고려한 설계, 구현 Analyzability 설계문서와 방법을 기술하였다. 소스코드간 일관성 본 논문의 구성은 다음과 같다. 2 장에서는 분석대상 시스템인 초고속 네트워크 스위칭 소프트웨어를 함수 복잡도 소개하며, 3 장에서는 레거시시스템 분석 측정항목과 프로세스를 소개한다. 4 장에서는 분석과정에서 얻어진 Maintain 함수 호출 깊이 일반적인 원리와 교훈을 소개하며, 5 장에서는 ability 패키지 의존성 사례연구를 정리하고 향후 진행 사항에 대해 설명한다. 전역변수 참조관계 Changeability 2. 분석대상시스템: 초고속 네트워크 스위칭 S/W 본 사례연구에서의 분석대상은 다양한 휴대 인터넷 Testability 함수 복잡도(중복) Efficiency 미사용 데이터 단말을 이용하여 정지 및 이동 중에서도 언제, 어디서나 고속으로 무선인터넷이 가능한 서비스를 제공하기 위한 본 연구에서 정의된 측정 항목은 표 1에서 나타나는 초고속 네트워크 스위칭 시스템이다. 본 논문에서는 바와 같이 설계문서와 소스코드 간의 일관성, 함수 초고속 네트워크 스위칭 시스템 소프트웨어의 부분에 복잡도, 함수 호출의 깊이, 패키지 의존성, 전역변수 대해 레거시시스템 분석을 실시하였으며, 분석대상은 참조관계, 미사용 데이터(미사용 함수, 미사용 파라미터, 2,510 개의 파일 (1,558 개의 C 소스파일, 952 개의 미사용 필드)이며 각 항목에 대한 측정은 대부분 분석 도구에서 자동화를 지원한다. 각 항목에 대한 지표 및 헤더파일)로 구성되어 있으며 47 개의 블록, 1,865,704 측정 스케일은 표 2와 같으며 각각의 세부내용은 3.1.1 부터 3.1.6 에 걸쳐 설명한다.

재공학을 위한 레거시시스템의 이해: 사례연구 547 표 2 측정 항목과 스케일[3] 본 연구에서는 함수 복잡도를 측정하기 위한 항목으로 Tom MacCabe 의 Cyclomatic Complexity 를 사용하였다. 측정항목 측정세부항목 측정스케일§ Cyclomatic Complexity 는 프로그램의 복잡도가 설계문서와 제어흐름에 의해서 정의된다는 가정하에, 한 루틴 안에 소스코드와 설계문서와 Ratio 있는 결정점 (decision points)의 수를 세어 복잡도를 의 일관성 소스코드와의 일관성 측정하는 방법이다[5]. Cyclomatic Complexity 는 언어 및 함수복잡도 언어형식에 제약 받지 않는 가장 많이 사용되는 함수 호출 Cyclomatic Complexity Absolute 소프트웨어 지표중의 하나이다[6]. 깊이 패키지 함수 호출 깊이 Absolute 함수 복잡도 측정은 프로그램 간의 복잡도에 대한 비교 의존성 분석이 가능하도록 절대적인 수치(absolute scale)를 재귀함수 Ratio 제공하고 있다. 프로그램의 복잡도가 리엔지니어링의 전역변수 위험 요소 중 하나라는 것을 감안할 때, 프로그램 참조관계 패키지 의존성 Nominal 복잡도는 리엔지니어링 활동의 비용 및 위험 분석에 긍정적인 효과를 제공한다. 미사용 패키지간 역방향 호출 Ratio 데이터 또한 Cyclomatic Complexity 는 테스트의 입장에서도 모듈간 전역변수 중요한 정보를 제공한다. 함수 복잡도는 제어문에 의해 참조관계 Nominal 분기되는 수행흐름을 의미하므로, 유닛테스트 시점에서 작성되는 테스트케이스의 수와 비례한다. 예를 들어 어떤 미사용 전역변수 Ratio 함수의 복잡도가 50 이라면 이것은 함수의 테스트커버리지(Test coverage) 100%를 달성하기 위한 모듈변수 전환 가능한 유닛테스트 케이스의 수가 50 이라는 것을 나타낸다. Ratio 이는 해당 함수에 대한 테스트가 거의 불가능함을 의미하며, 테스트를 통해서 함수에 대한 품질 보증이 전역변수 이루어질 수 없음을 뜻한다. 미사용 함수 Ratio 3.1.3 함수 호출 깊이 함수 호출 깊이(Function Call Depth)는 함수 간의 미사용 파라미터 Ratio 호출관계를 통해 시스템의 구조를 보여주는 항목이다. 미사용 필드 Ratio 함수의 호출 깊이 수치가 높아지면 프로그램의 이해가 어려우며, 변경 및 유지 보수가 용이하지 않다. 초고속 3.1.1 설계문서와 소스코드와의 일관성 네트워크 스위칭 시스템에서는 함수 호출 깊이의 설계문서와 소스코드의 일관성(Design-code 적정수치인 5 이하를 나타내고 있다[5]. 함수 호출 깊이에 대한 분포는 시스템에 있는 함수들의 연관되어 있는 traceability)은 설계의도가 소스코드에 반영되어 있는 정도에 대한 정보를 제공한다 (그림 2 참고). 정도에 대한 항목이다. 일반적으로 소프트웨어 개발 및 유지보수 단계에서 개발자는 변경이 이루어진 내용을 본 연구에서는 함수 호출의 깊이의 수치 높은 설계문서에 반영하지 않는 경향이 있다. 따라서 이후에 것만으로는 문제를 발생의 요인으로 분석하지는 않았다. 참여한 개발자가 설계의도를 파악할 수 없어 유지보수에 그러나, 분포에서 3σ 이상 벗어나는 함수 호출 깊이를 많은 비용이 소요된다[4]. 갖는 함수들에 중점을 두고 분석을 실시하였고, 이러한 함수는 관리대상 함수로 지정하였다. 측정방법은 설계에 나타난 모듈(Module)과 모듈간의 관계(Relation)를 기준으로 얼마나 소스코드에 정확하게 나타나 있는지에 대한 비율을 분석하는 것이다. 대부분의 경우는 분석가의 역량에 의해 결정된다. 3.1.2 함수 복잡도 § Ratio(비율로 표기), Nominal(우열을 가를 수 있음), Absolute(절대수치로 비교)

548 정보과학회논문지: 정보통신 제 31 권 제 6 호(2004.12) 전역변수 참조관계 항목에서는 시스템의 모듈화 정도 및 사용되지 않는 전역변수에 대한 정보를 제공한다. 설계에 나타난 모듈간의 관계는 함수 호출관계뿐 아니라 전역변수 참조관계에 의해서도 구현될 수 있다. 전역변수 참조 관계에 의해 모듈간의 의존관계가 구현되어 있을 경우 시스템의 모듈화 및 모듈간의 분리가 용이하지 않다. 그러므로, 전역변수 참조관계를 파악하여 전역변수 참조를 최소화 하는 것이 필요하다. 그림 2 함수 호출 깊이 또한 전역변수 참조관계 항목에서는 전역변수의 함수 호출 깊이 항목에서는 함수의 재귀호출에 대해서도 분석한다. 재귀호출은 함수 내에서 자신을 사용이 적합여부를 분석하며 그 내용은 다음과 같다. 호출하는 직접호출과 다른 함수를 호출하는 관계에서 자신이 호출되는 간접호출로 분류될 수 있다. 직접호출의 첫째로, 전역변수 중 모듈변수(동일한 파일 안에서만 경우 개발자에 의해 의도적으로 구현되었을 가능성이 높다. 또한 자동화 도구의 도움 없이도 명시적으로 참조가 되는 변수)로 전환 가능한 변수를 파악한다. 확인이 가능하기 때문에 유지보수가 용이하다. 그러나 간접호출의 경우는 대부분 개발자가 시스템에서의 함수 모듈변수를 선언하기 위해서는 함수 외부에 선언된 호출관계를 이해하지 못한 상태에서 다른 함수의 호출함으로써 발생한다. 또한 간접호출은 자동화 도구의 변수에 “ static” 키워드를 추가한다. 모듈변수로 도움 없이는 현황 파악이 불가능 하기 때문에 이에 대한 해결 및 지속적인 관리가 요구된다. 선언되면 선언된 파일 내에서만 참조되는 것을 보장하므로, 해당 변수에 대한 참조 범위(scope)가 좁아져 유지보수성 (Maintainability)을 향상시킨다. 둘째로, 선언 되었으나 사용되지 않는 전역변수를 파악한다. 미사용 전역변수는 명백한 메모리 낭비 요소이므로, 이를 제거하여 시스템의 효율성(Efficiency)를 향상시킨다. 3.1.4 패키지 의존성 3.1.6 미사용 데이터 패키지 의존성(Package Dependency)은 블록 내에 본 논문에서 정의하는 미사용 데이터는 선언되었으나 존재하는 패키지간의 관계를 파악하기 위한 항목이다. 본 호출되지 않는 함수, 미사용 파라미터, 구조체내에서 사례연구에의 패키지는 “ 논리상 의미를 갖는 최소의 사용되지 않는 필드를 의미한다. 미사용 데이터를 단위” 를 의미한다. 패키지 의존성은 패키지간의 의존 파악하면, 메모리 낭비를 막을 수 있고 시스템을 관계가 설계의도를 반영하고 있는가를 보여준다. 만약 유지보수하기가 수월해진다. 시스템이 ‘ 계층 아키텍처 (Layer Architecture)’ 로 구현되어 있다면 패키지 의존성은 매우 중요한 미사용 데이터가 발생하는 원인은 기존 개발자와 신규 측정항목이 된다. 왜냐하면 패키지간의 관계는 계층간의 개발자간에 업무 인수인계가 제대로 되지 않기 때문이다. 관계를 의미하므로, 하위계층에서 상위계층을 호출하는 소프트웨어의 개발 및 유지보수 담당자가 변경되었을 역방향 호출(backward call)은 상위계층의 변화에 따라 경우 새로 투입된 개발자는 이전 개발자가 작성한 미사용 하위 계층이 변경되어야 함을 의미하므로 하위계층이 데이터 부분에 대해서는 고려하지 않는다. 그러므로 독립적으로 사용될 수 없기 때문이다. 대부분의 통신관련 인수인계 과정에서 미사용 데이터에 대한 해결이 반드시 소프트웨어는 ‘ 계층 아키텍처’ 를 기반으로 개발되고 필요하다. 미사용 함수가 많다는 것은 프로젝트의 관리가 있으므로, 패키지 의존성 항목은 소스코드의 구조분석 효율적으로 이루어지지 않았음을 의미하므로 미사용 측면에서 매우 중요한 정보를 제공한다. 데이터에 대한 분석은 매우 중요하다. 3.1.5 전역변수 참조관계 3.2 분석 프로세스 3.2 절에서는 본 사례연구에서 레거시 시스템을 이해하기 위한 사용한 분석 프로세스를 소개한다.

재공학을 위한 레거시시스템의 이해: 사례연구 549 재공학에서 다루는 레거시시스템 분석은 구체적인 이번 단계에서는 개발팀 인터뷰 단계에서 획득된 빌드 프로세스가 제시되지 않아 실무에 적용하는데 명확하지 정보를 기반으로 하여 위한 자동화된 분석도구를 않다-특히 레거시 시스템 분석의 프로세스는 분석하고자 사용하여 소스코드로부터 정의된 분석항목에 대한 하는 항목을 어떤 순서에 의해 이해해야 하는지가 지표를 측정한다. 언급되어야 한다. 제안된 프로세스는 이러한 고려사항을 반영하였다. 본 사례연구에서는 레거시 시스템 분석을 위하여 삼성전자에서 개발한 리엔지니어링 도구인 DaRT 제안된 프로세스는 개발 조직 외부의 전문가가 (Dashboard for Reengineering Tool) 를 사용하였다. 개발팀의 진행과제에 대하여 분석을 진행하는 것을 DaRT 는 정적분석 도구(Static Analysis Tool)이며 고려하여 정의되었으며 여러 차례의 분석 경험에 표 2 에서 나타난 측정항목 중 ‘ 설계문서와 근거하여 효율적인 레거시 시스템 분석을 목적으로 하고 소스코드와의 일관성’ , ‘ 패키지 의존성’ 등 nominal 있다 (그림 3 참조). scale 을 제외한 지표에 대해 자동화된 측정이 가능하도록 지원하고 있다. 단, 도구에 의해 측정된 수치만으로는 레거시 시스템을 이해할 수 없으며, 설계서 분석 및 개발팀 인터뷰를 토대로 하여 전문가에 의해 수치를 해석하는 작업이 필요하다. 본 연구에서는 여러 차례의 분석을 통하여 얻어진 도메인의 특성을 반영하여 각 항목에 대해 양호, 주의, 경고 등의 3 단계의 등급으로 수준을 측정하는 기준을 마련하였다. 그림 3 분석 프로세스 3.2.4 문제점 도출 및 해결방안 모색 이번 단계에서는 레거시시스템의 전반적인 특성에 3.2.1 상세설계분석 상세설계 분석단계에서는 개발팀이 제공한 대해 이슈가 되는 문제점을 도출하고 각 문제에 대한 원인 및 파급효과에 대해서 분석한다. 그리고 시스템의 상세설계서를 기반으로 분석대상 블록에 대한 설계의도 개선을 위해 필요한 활동 및 문제해결 방법에 대해 및 블록의 내부 구조에 대해서 분석하고 해당 블록의 제시한다. 도메인 특성에 대해 파악한다. 본 연구에서는 해석된 수치적인 결과를 기반으로 설계서에 기술된 논리적인 구조는 실제 소스코드 소스코드 레벨에서의 원인 분석 및 해결방안을 상에서 폴더 및 파일명의 prefix 형태로 나타나므로 도출하였으며, 도출된 결과에 대하여 여려 명의 소스코드의 구조 및 코드와 설계와의 일관성을 파악하기 전문가들이 함께 검토작업을 수행하였다. 위해 필요하다. 3.2.5 개발팀 리뷰 3.2.2 개발팀 인터뷰 각 측정 항목마다 도출된 문제점 및 해결방안에 대해 개발팀 인터뷰 단계에서는 개발팀으로부터 블록의 개발팀과의 리뷰를 실시한다. 우선 각 항목의 원인 분석 개발과정에 대한 이력 및 자원 할당 정보, 빌드 정보 등을 내용 및 파급효과에 대한 타당성에 대해 개발팀의 의견을 획득한다. 이번 단계에서는 이전 단계에서 산출된 수렴한다. 그리고 3.2.3 단계의 활동에서 측정된 주의, 상세설계 분석 결과 및 기존에 정의된 분석을 위한 사전 경고 등급의 항목에 대해서 제안된 해결방안 중 개발팀에 체크리스트를 기반으로 하여 수행된다. 본 사례연구에서 의해 타당하다고 분석된 항목에 대한 수행여부 및 개발팀 인터뷰는 온-오프라인을 병행하여 실시하였다. 수행일정을 결정한다. 3.2.3 도구를 통해 추출된 데이터 분석

550 정보과학회논문지: 정보통신 제 31 권 제 6 호(2004.12) 본 사례연구에서는 리엔지니어링작업 완료 이후 연구도 진행되고 있으며, 객체지향 분야에 적용되는 OO 개발팀의 해당작업에 대한 수행여부 및 성과에 대한 Metric 을 통한 결함발생 예측에 대한 연구도 진행되고 분석을 실시할 예정이다. 있다[9]. 4. 일반적인 원리와 교훈 본 연구에서는 함수복잡도와 결함밀집도 간의 관계를 본 논문에서 사례연구를 통해 얻어진 교훈을 기술한다. 규명하였다. 그림 4에서 확인할 수 있는 바와 같이 함수 복잡도가 1~10 인 함수들의 경우에는 2%의 1)파일명 및 코드에 대한 명명규칙을 작성하는 것은 결함발생률을 나타내고 있으나 함수 복잡도가 번거로운 일이지만 유지보수를 위해 반드시 필요하다. 증가할수록 결함 발생률은 증가하고 있으며 복잡도가 101 이상인 함수들은 34% 이상의 결함발생률을 보이고 설계상의 모듈이 소스코드에 반영되어 있는 정도를 있다. 즉 함수의 복잡도가 증가할수록 결함의 밀집도는 파악하는 과정에서 파일명에 대한 명명 규칙이 없을 경우, 급속도로 증가함을 알 수 있다. 각 파일의 기능 및 논리적인 의미를 파악할 수 없다. 설계서의 각 모듈이 구현된 코드를 확인할 수 없으므로 소스코드의 논리적인 구조에 대한 분석이 불가능 하다. 또한 코드의 명명 규칙이 없어 함수 및 변수명에 대한 일관성이 지켜지지 않을 경우 기존에 존재하는 기능을 가진 함수 및 변수에 대한 파악이 어려워진다. 또한 새로운 기능을 생성하는 추가 작업이 발생시 추가되는 함수명 및 변수명에 대한 명명작업에도 많은 노력이 소요된다. 2)프로토타입 빌딩 방법은 설계와 구현이 일치되지 그림 4 복잡도와 결함밀집도의 관계 않는 현상을 방지할 수 있다. 3.1.4 에서 제시된 바와 연관 지어 보면, 함수 복잡도가 높을수록 결함발생률은 증가하는데 해당 함수에 대한 실제로 소프트웨어를 개발할 때에 상세설계 후 구현이 테스트는 불가 하므로 개발과정에서 함수의 복잡도를 이뤄지는 경우는 극히 드물다. 대부분의 경우 개략 낮추기 위한 노력이 필요함을 알 수 있다. 본 설계를 통해 API 와 함수관계를 정의하고 이를 바탕으로 사례연구에서는 분석을 실시하면서 알고리즘의 재검토, 세부 알고리즘이 구현된다. 이러한 방법을 프로토타입 필요한 경우 함수의 분리 구현, 코드의 최적화 등을 빌드를 통한 구현이라 부른다. 본 사례연구에서는 설계와 통하여 함수의 복잡도를 낮추는 것을 개발팀에 구현간의 일관성을 검증하기 위해 개략설계 후 구조의 제안하였다. 일관성을 검증하고 이를 바탕으로 실제 알고리즘을 구현하도록 하였다. 이후 구현이 완료된 후 구조의 4)소프트웨어 프로젝트 관리는 결국 사람을 관리하는 일관성 여부를 재검증한다. 것이다. 3)본 사례연구의 경우 함수의 복잡도가 결함(Defect) 일정에 대한 압박으로는 일정을 단축시킬 수는 있어도, 밀집도와 관련이 있음을 확인하였다. 고품질의 소프트웨어를 보장할 수 없다. 분석과정에서 나타난 문제점들에 대한 원인을 분석한 결과 대부분은 현재 소프트웨어 구현 단계에서 측정되는 메트릭을 촉박한 일정에 의해 발생된 것들이 대부분이었으며, 이용하여 제품의 결함발생을 예측하려는 연구들이 많이 특정 부분에서 문제점들이 많이 발생하는 것을 확인할 진행되고 있다. Fenton et al.은 모듈의 개수, 모듈의 크기, 수 있었다. 차후 발생된 문제들을 해결하기 위하여 LOC, 복잡도 등의 지표와 결함발생과의 연관관계에 재작업에 소요해야 하는 시간을 고려할 경우 대한 정량적인 분석을 실시하였다[7]. 그 밖에도 소프트웨어의 변경이력과 결함발생과의 관계[8]에 대한

재공학을 위한 레거시시스템의 이해: 사례연구 551 일정상으로도 많은 손실을 끼치게 되므로, 일정에 [8] Todd L. Graves, Alan F. Karr, J.S. Marron, and Harvey 맞추는 것도 중요하지만 개발자가 고품질의 Siy, “Predicting Fault Incidence Using Software Change 소프트웨어를 개발 할 수 있도록 환경을 개선하는 History”, IEEE Transactions On Software Engineering, 노력도 시급하다. 또한 특정 부분에서 문제점이 집중되는 것에서 개발자의 역량의 차이에 의한 결과를 Vol. 26, No. 7, July 2000, pp.653-661. 확인할 수 있으며, 이로 인해 개발자의 개발역량을 [9] Tibor Gyimothy, Rudolf Ferenc, and Istvan Siket, 향상시키는 노력이 필수적임을 확인하였다. “Empirical Validation of Object-Oriented Metrics on Open Source Software for Fault Prediction”, IEEE Transactions On Software Engineering, Vol. 31, No. 10, October 2005, pp.897-910. 5. 결론 김진태 본 논문에서는 시스템의 구조를 개선하고 보증하기 1998년 서강대학교 컴퓨터학과 졸업(학사) 위한 재공학 중 레거시시스템 분석활동에 대한 2000년 서강대학교 컴퓨터학과 사례연구를 소개하였으며, 특히 레거시시스템의 이해를 졸업(석사) 위한 측정 항목과 분석 프로세스 및 분석활동을 통해 2002년 데이콤시스템 테크놀로지(S/W 얻어진 일반적인 원리와 교훈을 제시하였다. Engineer) 2005년 서강대학교 컴퓨터학과 졸업(박사) 본 연구에서 소개된 레거시시스템의 분석과정에서 2005년 ~ 삼성전자 정보통신연구소 Software Engineering 나타난 문제점에 대한 원인 및 해결점을 종합한 결과 part 실무책임자. 관심분야는 S/W Metric, Reengineering, 해당 도메인에서 필요한 항목으로 (1)각 블록에 대한 Architecture, Software Product Line, Requirements 담당자 및 책임자를 명확히 하는 것, (2)소스코드 및 개발 engineering. 인력 등에 대한 변경관리를 철저히 하는 것, (3)함수의 복잡도를 낮추기 위하여 지속적인 노력을 투입할 것 등을 김수현 도출하였다. 2005년 한동대학교 전산전자공학부 향후 연구에서는 본 사례연구에서 계획된 시스템에 대한 재공학 활동을 지속적으로 수행하여 해당 활동의 졸업(학사) 수행과정에서 발생한 이슈 및 계획 대비 수행 결과, 사례연구 대상 과제에서의 재공학의 효과에 대해 제시할 2007년 한국과학기술원 전산학과 예정이다. 졸업(석사) 2007년~ 삼성전자 정보통신 연구소 Software Engineering Lab. 관심분야는 S/W Metric, Software Process Improvement, Reengineering, Architecture. 참고문헌 강승미 2001년 숙명여자대학교 전산학과 [1] Chikofsky, E., Cross, J., “Reverse engineering and design 졸업(학사) recovery: a taxonomy”. IEEE Software Vol. 7, No. 7, 2006년 성균관대학교 컴퓨터공학과 졸 업(석사) 1990, pp13-17. 2001년~ 삼성전자 정보통신연구소 [2] ISO/IEC 9126, Product Quality – Quality Model Software Engineering Lab. 관심분야는 [3] Norman E. Fenton, “Software Metrics: A Rigorous and Reengineering, Architecture. Practical Approach 2nd Edition”, PWS Publishing Company 1997. [4] Perry, D.E., Wolf, A.L., “Foundations for the study of architecture”. ACM SIGSOFT Software Engineering Notes, Vol. 17, No. 4, 1992, pp. 40-52. [5] Steve McConnel, “Code Complete 2nd Edition”, Microsoft Press 2005 [6] McCabe, Thomas J. & Watson, Arthur H. \"Software Complexity.\" Crosstalk, Journal of Defense Software Engineering, Vol. 7, No. 12, December 1994, pp. 5-9. [7] Norman E. Fenton, Niclas Ohlsson, “Quantitative Analysis of Faults and Failures in a Complex Software System”, IEEE Transactions On Software Engineering, Vol. 26, No. 8, August 2000, pp.797-814.