KR20160088737A - 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법 - Google Patents

토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법 Download PDF

Info

Publication number
KR20160088737A
KR20160088737A KR1020150008201A KR20150008201A KR20160088737A KR 20160088737 A KR20160088737 A KR 20160088737A KR 1020150008201 A KR1020150008201 A KR 1020150008201A KR 20150008201 A KR20150008201 A KR 20150008201A KR 20160088737 A KR20160088737 A KR 20160088737A
Authority
KR
South Korea
Prior art keywords
bug
developer
report
recommendation
severity
Prior art date
Application number
KR1020150008201A
Other languages
English (en)
Other versions
KR101691083B1 (ko
Inventor
이병정
장도
양근석
Original Assignee
서울시립대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 서울시립대학교 산학협력단 filed Critical 서울시립대학교 산학협력단
Priority to KR1020150008201A priority Critical patent/KR101691083B1/ko
Publication of KR20160088737A publication Critical patent/KR20160088737A/ko
Application granted granted Critical
Publication of KR101691083B1 publication Critical patent/KR101691083B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G06Q10/063112—Skill-based matching of a person or a group to a task
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Physics & Mathematics (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Game Theory and Decision Science (AREA)
  • Computer Hardware Design (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Stored Programmes (AREA)

Abstract

본 발명은 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법에 관한 것으로, 보다 상세하게는 버그의 심각성을 예측하고, 소프트웨어의 개발 시간과 비용을 줄일 수 있는 버그 정정 개발자를 추천하는 시스템 및 방법에 관한 것이다.
이러한 목적을 달성하기 위하여 본 발명의 일 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템은 제1 추출부, 선정부 및 추천부를 포함한다.

Description

토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법 {System and Method for Bug Fixing Developers Recommendation and Bug Severity Prediction based on Topic Model and Multi-Feature}
본 발명은 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법에 관한 것으로, 보다 상세하게는 버그의 심각성을 예측하고, 소프트웨어의 개발 시간과 비용을 줄일 수 있는 버그 정정 개발자를 추천하는 시스템 및 방법에 관한 것이다.
본 발명은 미래창조과학부 및 한국연구재단의 차세대정보컴퓨팅기술개발사업의 일환으로 수행한 연구로부터 도출된 것이다[과제관리번호: 2014050304, 과제명: 의미기반 상시모니터링을 위한 SW 공학 기법 및 도구 원천기술 개발 (상시모니터링 연동 의미기반 테스트 지원 기술].
PC(개인용 컴퓨터)나 스마트 폰, 비디오 게임기와 같은 컴퓨터 기기를 통해 각종 소프트웨어를 이용하는 과정에서 이유 없이 오류 메시지가 출력되거나 기기가 오작동하는 경우를 종종 볼 수 있다. 이런 현상은 단순한 기기 고장 때문에 일어나기도 하지만 사용하는 하드웨어나 소프트웨어 자체의 결함에 의한 경우도 많으며, 이는 해당 하드웨어와 소프트웨어를 구성하고 있는 프로그램의 내용 중에 잘못된 코드가 들어 있음을 의미한다. 이렇게 프로그램 상의 결함에 의해 컴퓨터 오류나 오작동이 일어나는 현상을 버그(Bug)라고 한다.
버그는 복잡한 소프트웨어일수록 많이 발생되며, 발생된 버그는 정정을 위하여 버그 리포트와 함께 개발자에게 할당된다. 이때, 새로운 버그는 버그 저장소에 있는 배정자(triager)에 의하여 개발자에게 할당된다.
종래의 대규모 소프트웨어는 대부분 버그 정정 활동을 수행하기 위하여 제출되는 버그 리포트에 많이 의존하고 있다. 하지만, 종래에는 많은 버그 리포트가 제출됨에도 불구하고, 각각의 버그가 얼마나 조속히 처리되어야 하는지를 알 수 없었기 때문에, 제출되는 버그 리포트를 효과적으로 정정하는 작업이 이루어지지 못했다.
또한, 종래에는 많은 버그 리포트가 적절한 개발자에게 할당되지 못함에 따라 재할당되는 경우가 빈번히 발생하였으며, 이는 버그 정정의 시간 및 비용을 증가시키고, 소프트웨어의 개발 비용 또한 증대시키는 문제가 있었다.
한편, 한국공개특허 제2012-0069388호 "정적 결함 분류 및 보고 자동화 시스템 및 그 방법"은 하나 이상의 버그 검출기로부터 추출된 데이터를 바탕으로, 버그의 유형에 따른 클래스를 분류하여 기본 점수를 부여하고, 버그의 오류발생 조건(precondition) 및 버그 검출기들로부터 각각 추출된 버그 검사 데이터를 비교 검토(Cross-check)하여 가산점을 부여하고, 부여된 점수에 따른 버그 항목을 클래스 별로 최종 조정함으로써, 버그 검출기를 통해 보고된 버그 중 True Alarm일 가능성이 높은 항목을 쉽게 할당할 수 있으며, 전체적으로는 False Alarm rate를 줄일 수 있는 기술을 제시한다.
하지만, 상기 선행기술은 단순히 버그 검출기로부터 추출된 방대한 양의 결과 데이터를 효율적으로 검토하고, 대상 소프트웨어의 버그를 빠른 시간 안에 찾아내기 위한 버그 할당 기술일 뿐, 상기 할당된 버그를 정정하기 위하여 상기 버그를 개발자에게 효율적으로 할당하는 기술에 대해서는 전혀 언급하고 있지 않다.
즉, 상기 선행기술은 많은 버그 리포트가 적절한 개발자에게 할당되지 못하여 재할당되는 경우가 발생하게 되며, 이에 따라 버그 정정의 시간 및 비용이 증가하고, 소프트웨어의 개발 비용 또한 증대되는 종래의 문제가 여전히 존재하며, 또한, 상기 선행기술은 제출되는 버그 리포트를 효율적으로 정정하지 못하고 있다.
한국공개특허 제2012-0069388호 (공개일: 2012.06.28)
본 발명은 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법에 관한 것으로, 보다 상세하게는 버그의 심각성을 예측하고, 소프트웨어의 개발 시간과 비용을 줄일 수 있는 버그 정정 개발자를 추천하는 시스템 및 방법을 제공하려는 것을 목적으로 한다.
본 발명은 제출되는 버그 리포트의 심각성을 예측함으로써 제출되는 버그 리포트를 효율적으로 정정하려는 것을 목적으로 한다.
본 발명은 복잡한 소프트웨어에서 발생하는 많은 버그를 정정하기 위한 적절한 버그 정정 개발자를 추천함으로써, 소프트웨어의 품질을 향상시키고 개발의 시간 및 비용을 절감하려는 것을 목적으로 한다.
이러한 목적을 달성하기 위하여 본 발명의 일 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템은 제1 추출부, 선정부 및 추천부를 포함한다.
상기 제1 추출부는 모델링된 토픽을 기반으로 수신한 새로운 버그 리포트와 대응하는 토픽을 식별하고, 상기 식별된 토픽을 가진 과거 버그 리포트를 추출하고, 상기 선정부는 상기 새로운 버그 리포트를 정정할 개발자를 추천하기 위하여, 상기 추출된 과거 버그 리포트를 이용하여 후보 개발자를 선정하며, 상기 추천부는 상기 선정된 후보 개발자의 활동 경험 정보를 이용하여 상기 후보 개발자의 추천 순위를 연산하고, 상기 연산된 추천 순위를 기반으로 상기 새로운 버그 리포트를 정정할 개발자를 추천한다.
또한, 상기 제1 추출부는 상기 새로운 버그 리포트에 나타나는 토픽 용어의 빈도수를 이용하여 식별할 수 있으며, 상기 선정부는 상기 과거 버그 리포트로부터 추출된 담당자와 코멘터를 포함하는 제1 개발자와, 상기 과거 버그 리포트와 같은 특성을 갖는 버그 리포트로부터 추출된 제2 개발자를 기반으로 상기 후보 개발자를 선정할 수 있다. 이때, 상기 선정부는 상기 과거 버그 리포트 내에 포함된 제품, 구성 요소, 우선 순위, 심각성 중 적어도 하나 이상의 특성 정보를 이용하여 상기 제2 개발자를 추출할 수 있다.
또한, 상기 추천부는 상기 활동 경험 정보로서, 상기 후보 개발자가 버그 정정에 참여한 활동을 나타내는 코멘트(comments) 수와 커밋(commits) 수, 및 상기 후보 개발자가 버그 정정에 참여한 경험을 나타내는 할당(assignments) 수와 첨부 파일(attachment) 수를 이용할 수 있으며, 이때, 상기 추천부는 상기 코멘트 수, 상기 커밋 수, 상기 할당 수가 높고, 상기 첨부 파일의 할당 수가 낮을수록, 상기 후보 개발자들의 추천 순위가 높은 것으로 판단할 수 있다.
또한, 본 발명의 시스템은 상기 제1 추출부에서 추출된 과거 버그 리포트를 기반으로, 상기 새로운 버그 리포트의 심각성을 예측하는 예측부를 더 포함할 수 있다.
이때, 상기 예측부는 상기 제1 추출부에서 추출된 과거 버그 리포트로부터 같은 특성을 갖는 공통 버그 리포트를 추출하는 제2 추출부와, 상기 추출된 공통 버그 리포트와 상기 새로운 버그 리포트 간에 텍스트 유사도를 계산하는 계산부를 포함할 수 있으며, 상기 예측부는 상기 계산된 텍스트 유사도를 기반으로 하고, K-최근접 이웃(K-nearest Neighbor) 알고리즘을 이용하여 상기 새로운 버그 리포트의 심각성을 예측할 수 있으며, 상기 계산부는 벡터로 표현된 상기 새로운 버그 리포트와 KL 발산(Kullback-Leibler divergence)을 이용하여 상기 텍스트 유사도를 계산할 수 있다.
한편, 본 발명의 일 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법은 모델링된 토픽을 기반으로 수신한 새로운 버그 리포트와 대응하는 토픽을 식별하고, 상기 식별된 토픽을 가진 과거 버그 리포트를 추출하는 단계, 상기 새로운 버그 리포트를 정정할 개발자를 추천하기 위하여, 상기 추출된 과거 버그 리포트를 이용하여 후보 개발자를 선정하는 단계, 상기 선정된 후보 개발자의 활동 경험 정보를 이용하여 상기 후보 개발자의 추천 순위를 연산하고, 상기 연산된 추천 순위를 기반으로 상기 새로운 버그 리포트를 정정할 개발자를 추천하는 단계를 포함할 수 있다.
또한, 상기 과거 버그 리포트를 추출하는 단계는 상기 새로운 버그 리포트에 나타나는 토픽 용어의 빈도수를 이용하여 식별할 수 있으며, 상기 후보 개발자를 선정하는 단계는 상기 과거 버그 리포트로부터 추출된 담당자와 코멘터를 포함하는 제1 개발자와, 상기 과거 버그 리포트와 같은 특성을 갖는 버그 리포트로부터 추출된 제2 개발자를 기반으로 상기 후보 개발자를 선정할 수 있다. 이때, 상기 후보 개발자를 선정하는 단계는 상기 과거 버그 리포트 내에 포함된 제품, 구성 요소, 우선 순위, 심각성 중 적어도 하나 이상의 특성 정보를 이용하여 상기 제2 개발자를 추출할 수 있다.
또한, 상기 개발자를 추천하는 단계는 상기 활동 경험 정보로서, 상기 후보 개발자가 버그 정정에 참여한 활동을 나타내는 코멘트(comments) 수와 커밋(commits) 수, 및 상기 후보 개발자가 버그 정정에 참여한 경험을 나타내는 할당(assignments) 수와 첨부 파일(attachment) 수를 이용할 수 있으며, 이때, 상기 개발자를 추천하는 단계는 상기 코멘트 수, 상기 커밋 수, 상기 할당 수가 높고, 상기 첨부 파일의 할당 수가 낮을수록, 상기 후보 개발자들의 추천 순위가 높은 것으로 판단할 수 있다.
또한, 본 발명의 방법은 상기 과거 버그 리포트를 추출하는 단계에서 추출된 과거 버그 리포트를 기반으로, 상기 새로운 버그 리포트의 심각성을 예측하는 단계를 더 포함할 수 있다.
이때, 상기 심각성을 예측하는 단계는 상기 과거 버그 리포트를 추출하는 단계에서 추출된 과거 버그 리포트로부터 같은 특성을 갖는 공통 버그 리포트를 추출하는 단계와 상기 추출된 공통 버그 리포트와 상기 새로운 버그 리포트 간에 텍스트 유사도를 계산하는 단계를 포함할 수 있으며, 상기 심각성을 예측하는 단계는 상기 계산된 텍스트 유사도를 기반으로 하고, K-최근접 이웃(K-nearest Neighbor) 알고리즘을 이용하여 상기 새로운 버그 리포트의 심각성을 예측할 수 있으며, 상기 텍스트 유사도를 계산하는 단계는 벡터로 표현된 상기 새로운 버그 리포트와 KL 발산(Kullback-Leibler divergence)을 이용하여 상기 텍스트 유사도를 계산할 수 있다.
본 발명은 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법에 관한 것으로, 보다 상세하게는 버그의 심각성을 예측하고, 소프트웨어의 개발 시간과 비용을 줄일 수 있는 버그 정정 개발자를 추천하는 시스템 및 방법을 제공할 수 있는 효과가 있다.
본 발명은 제출되는 버그 리포트의 심각성을 예측함으로써 제출되는 버그 리포트를 효율적으로 정정할 수 있는 효과가 있다.
본 발명은 복잡한 소프트웨어에서 발생하는 많은 버그를 정정하기 위한 적절한 버그 정정 개발자를 추천함으로써, 소프트웨어의 품질을 향상시키고 개발의 시간 및 비용을 절감할 수 있는 효과가 있다.
본 발명은 버그 리포트의 토픽 모델과, 버그 리포트의 제품, 구성 요소, 우선 순위 및 심각성을 포함하는 다중 특성을 이용하여, 보다 적절한 버그 정정 개발자를 추천하고, 버그 리포트의 심각성을 예측할 수 있는 효과가 있다.
도 1은 본 발명의 일 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템의 구성도이다.
도 2는 본 발명의 제2 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템의 구성도이다.
도 3은 버그 ID 번호가 36465인 Eclipse JDT 버그 리포트의 세부 정보를 나타낸 도면이다.
도 4는 본 발명의 일 실시예에 따른 버그 정정 개발자 추천을 위한 프레임워크를 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따른 버그 리포트의 심각성 예측을 위한 작업 흐름을 나타낸 도면이다.
도 6은 본 발명의 일 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법에 대한 동작 흐름도이다.
이하, 본 발명의 바람직한 실시예를 첨부된 도면들을 참조하여 상세히 설명한다. 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략하기로 한다. 또한 본 발명의 실시예들을 설명함에 있어 구체적인 수치는 실시예에 불과하다.
본 발명은 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법에 관한 것으로, 보다 상세하게는 버그의 심각성을 예측하고, 소프트웨어의 개발 시간과 비용을 줄일 수 있는 버그 정정 개발자를 추천하는 시스템 및 방법에 관한 것이다.
도 1은 본 발명의 일 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템의 구성도이다.
도 1을 참조하면, 본 발명의 일 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템(100)은 제1 추출부(110), 선정부(120) 및 추천부(130)를 포함한다.
제1 추출부(110)는 모델링된 토픽을 기반으로 수신한 새로운 버그 리포트와 대응하는 토픽(Topic)을 식별하고, 상기 식별된 토픽을 가진 과거 버그 리포트를 추출한다.
제1 추출부(110)는 상기 수신한 새로운 버그 리포트에 나타나는 토픽 용어의 빈도수를 이용하여, 상기 수신한 새로운 버그 리포트와 대응하는 토픽을 식별할 수 있다. 이때, 빈도 수는 높을수록 수신한 새로운 버그 리포트와 토픽이 일치하는 것을 의미한다.
더 자세히 말하자면, 제1 추출부(110)는 먼저, 수신한 새로운 버그 리포트와 대응하는 토픽을 식별하기 위하여, 토픽을 모델링할 수 있다. 이때, 제1 추출부(110)는 토픽을 모델링하기 전에, 버그 리포트에 미리 정의된 필드(예를 들어, "요약(summary)", "설명(description)" 등)를, 단어 토큰(word tokens)으로 되돌리는(returns) coreNLP로 가져온다. 즉, 제1 추출부(110)는 단어 토큰을 얻기 위한 전처리(preprocessing)를 수행하기 위하여, 각각의 새로운 버그 리포트를 coreNLP로 가져온다.
그런 다음, 제1 추출부(110)는 특성(features)으로써, 각 버그 리포트로부터 상기 단어 토큰을 연결시키고, 그리고, 각 토픽에 대한 용어(terms)를 생성하기 위하여 스탠포드 TMT(Stanford TMT)에 상기의 특성들을 플러그(plug)한다. 제1 추출부(110)는 수신한 새로운 버그 리포트와 대응하는 토픽을 식별하기 위하여, 단어 토큰을 사용하게 된다.
아래 표 1은 TMT으로부터 추출된 이클립스(Eclipse)의 각 토픽에 대한 용어를 나타낸다.
Figure pat00001
즉, 본 발명의 시스템(100)은 모델링된 토픽으로 표 1과 같은 데이터를 저장하고 있을 수 있으며, 상기 표 1을 참조하면, 토픽 1(Topic-1)에는, 기 정의된 버그 리포트의 필드를 기반으로 전처리하여 획득한, "time", "set", "run", "execution" 등의 단어 토큰이 포함되어 있을 수 있고, 토픽 2(Topic-2)에는 "context", "text", help" 등의 단어 토큰이, 토픽 3(Topic-3)에는 "import", "export", "jar" 등의 단어 토큰이 포함되어 있을 수 있다.
따라서, 제1 추출부(110)는 새로운 버그 리포트가 도착하면, 기 저장된 모델링된 토픽에서 수신한 새로운 버그 리포트와 매칭(matching)되는 토픽을 식별하여 선택하게 된다.
이때, 제1 추출부(110)는 수신한 새로운 버그 리포트와 매칭되는 토픽을 선택할 때, 새로운 버그 리포트에 나타나는 토픽 용어의 빈도수를 계산함으로써 선택할 수 있다. 만약에, 빈도수가 가장 높은 경우, 주어진 새로운 버그 리포트는 토픽에 속해 있는 것처럼 고려할 수 있다. 예를 들어, 새로운 버그 리포트를 전처리한 결과, 새로운 버그 리포트에 토픽 2에 포함되어 있는 "context", "text", help" 등의 단어가 토픽 3의 "import", "export" 등의 단어 보다 많이 출현한 경우, 상기 새로운 버그 리포트는 토픽 2에 속하는 것으로 판단할 수 있다.
그리고 제1 추출부(110)는 주어진 새로운 버그 리포트를 정정할 적절한 개발자를 추천하고 새로운 버그 리포트의 심각성을 예측하기 위하여, 수신한 새로운 버그 리포트와 같은 토픽에 속해 있는 과거 버그 리포트를 추출한다. 즉, 제1 추출부(110)는 수신한 새로운 버그 리포트가 토픽 2에 속할 경우, 토픽 2에 속한 과거 버그 리포트들을 모두 추출하게 된다. 즉, 본 발명은 모델링된 각 토픽에 대응하는 과거 버그 리포트들을 저장하고 있을 수 있다.
본 발명에서는 주어진 새로운 버그 리포트를 정정할 적절한 개발자를 추천하고, 새로운 버그 리포트의 심각성을 예측하기 위하여, 앞서 설명한 버그 리포트의 토픽 모델 뿐만 아니라, 버그 리포트의 멀티-특성(multi-feature)을 이용하게 된다.
이하에서는 본 발명에서 활용하는 멀티-특성의 개념에 대해 설명한다.
버그 리포트는 자유 형식의 텍스트 콘텐츠(content)이며, 일반적으로 버그 리포트는 소스 코드 파일에 나타나는 기본값(defeauts)을 포함한다. 버그 리포트는 사전에 정의된 "Bug ID", "제목(Title)", "구성 요소(Component)" 등으로 구성되어 있다.
도 3은 버그 ID 번호가 36465인 Eclipse JDT 버그 리포트의 세부 정보를 나타낸 도면이다.
도 3을 참조하여, 버그 ID 번호가 36465인 Eclipse JDT 버그 리포트의 세부 정보를 살펴보면, 도 3의 버그 리포트는 Jason Sholl에 의해 제출되었고, 현재 상태는 "CLOSED"와 "FIXED"이고, Eplipse 제품(product)는 "JDT"로 분류되며, 구성 요소(Component)는 "Core"이다. 게다가 상기 버그 리포트는 수정되기 위하여 Philipe Mulet이라는 이름의 개발자에게 할당되었다.
상기 버그 리포트의 맨 밑에 부분에는, 도면상에 도시되지는 않았지만, 버그 설명(description), 첨부 파일(예를 들어, 패치(patch), 테스트 케이스(test case) 등), 코멘터(즉, 코멘트를 단 사람, commenters) 등과 같은 상세 정보가 제공된다. 이때, 버그 리포트에는 커밋(commits) 정보가 나타나 있지 않는 것에 주목할 필요가 있다.
실제로, 커밋은 버그 저장소(bug repository)의 이력 로그(history log)에 저장된다. 만약에 개발자가 코드 라인을 변경한 경우, 개발자들은 코드 변경을 선언하는 메시지를 보내야 한다. 이에 본 발명은 이러한 버그 리포트의 특성(feature)을 통해, 버그를 정정하는 개발자들의 경험 검증을 향상시킬 수 있다.
즉, 버그 리포트에는 "제품(Product)", "구성 요소(Component)", "우선 순위(Priority)", "심각성(Severity)" 등과 같이 중요한 메타-필드(meta-fields)가 있다. 본 발명에서는 상기와 같은 중요한 메타-필드를 멀티-특성(multi-feature)으로서 채택하였다.
멀티-특성(multi-feature) 중에서, "제품(Product)"은 Eclipse의 "JDT", "PDE"와 같이, 고객의 요구 사항(requirements)을 개발하는 첫번째 카테고리(category)를 나타낸다. 그리고, "구성 요소(Component)"는 "Debug", "UI'와 같이, 특정 제품에 속하는 서브-카테고리(sub-category)를 나타낸다. "우선 순위(Priority)"와 "심각성(Severity)"은 주어진 새로운 버그 리포트가 긴급한지 안한지의 정도를 나타내는 스케일 영향 요소이다.
또한, "우선 순위(Priority)"는 버그를 수정하는 우선 순위를 나타내는 것으로서, P1에서 P5까지 5단계를 포함하며, 여기서 P1은 가장 높은 우선 순위를, P5는 가장 낮은 우선 순위를 나타낸다. 예를 들어, 도 3의 버그 리포트 36465는 버그 리포트가 가능한 빨리 수정되어야 하는 것을 의미하는, 가장 높은 우선 순위인 P1을 가진다.
"심각성(Severity)"은 버그에 대한 심각성의 정도를 의미하며, 일반적인 방법으로 "심각성(Severity)"은 7 단계(예를 들어, 차단(Blocker), 비판적인(Critical), 주요한(Major), 보통(Normal), 작은(Minor), 사소한(Trivial), 향상(Enhancement))를 포함한다. 심각성 중 Enhancement 단계는 새로운 기능을 위해 필요한 버그가 아니지만, 본 발명에서는 심각성 예측에 이를 포함시킨다.
상기의 7단계 중에서, Blocker, Critical, Major 단계는 프로그램에서 충돌(crashes), 데이터 손실(loss of data), 메모리 누수(memory leak)와 같은 심각한 문제를 나타낸다. 그리고, Normal, Minor, Trivial, Enhancement 단계는 작은 에러(minor errors), 미용 문제(cosmetic problem), 기능의 작은 손실(minor loss of function)을 나타낸다.
특히 Blocker는 가장 높은 심각성을 갖는 버그 유형을 나타내고, Trivial은 가장 낮은 심각성을 갖는 버그 유형을 나타낸다. 예를 들어, 도 3의 버그 리포트 36465는 "Blocker"로 표시되어 있는 바, 이는 가장 심각한 오류임을 알 수 있다.
본 발명에서는 토픽 모델과 멀티-특성을 이용함으로써, 새로운 버그를 정정하기 위해 적절한 개발자를 추천하고, 버그의 심각성을 예측하는 기술을 제공한다.
한편, 선정부(120)는 상기 수신한 새로운 버그 리포트를 정정할 적절한 개발자를 추천하기 위하여, 상기 추출된 과거 버그 리포트를 이용하여 후보 개발자를 선정한다. 이때, 후보 개발자는 토픽 모델을 이용한 개발자들 집합과 특성 정보를 이용한 개발자들 집합의 교집합으로부터 선정할 수 있다.
선정부(120)는 상기 과거 버그 리포트로부터 추출된 담당자(assigness)와 코멘터(commenters)를 포함하는 제1 개발자(즉, 토픽 모델을 이용하여 추출된 개발자들의 집합)와, 상기 과거 버그 리포트와 같은 특성을 갖는 버그 리포트로부터 추출된 제2 개발자(즉, 다중-특성을 이용하여 추출된 개발자들의 집합)를 기반으로 상기 후보 개발자를 선정할 수 있다.
이때, 선정부(120)는 상기 과거 버그 리포트 내에 포함된 제품(Product), 구성 요소(Component), 우선 순위(Priority), 심각성(Severity) 중 적어도 하나 이상의 멀티-특성(Multi-Feature) 정보를 이용하여 상기 제2 개발자를 추출할 수 있다.
더 자세히 말하자면, 선정부(120)는 제1 추출부(110)가 새로운 버그 리포트와 동일한 토픽을 가진 과거 버그 리포트를 추출하면, 상기 추출된 과거 버그 리포트로부터 해당 버그 리포트를 정정하기 위해 참여했던 모든 개발자들(이때의 참여 개발자는 제1 개발자로서, 담당자(assigness)와 코멘터(commenters)를 포함할 수 있음)을 추출하며, 뿐만 아니라 상기 추출된 과거 버그 리포트와 같은 특성(즉, 이때 특성은 제품(Product), 구성 요소(Component), 우선 순위(Priority), 심각성(Severity)을 포함하는 멀티-특성을 의미함)을 가진 버그 리포트로부터 해당 버그 리포트를 정정하기 위해 참여했던 개발자들(이때의 참여 개발자는 제2 개발자를 의미함)을 추출할 수 있다.
선정부(120)는 제1 개발자와 제2 개발자를 추출한 후, 제1 개발자와 제2 개발자의 교집합을 후보 개발자로서 선정할 수 있다. 이때, 새로운 버그를 정정할 후보 개발자들의 리스트는 수학식 1에 의해 생성될 수 있다. 이하 수학식 1은 후보 개발자의 교집합 프로세스(process)를 나타낸다.
Figure pat00002
수학식 1에서 D는 버그 리포트를 정정하는 데에 기여한 후보 개발자들의 집합을 의미하며, 이러한 버그 리포트들은 같은 토픽, 제품(product), 같은 구성 요소(component), 같은 우선 순위(priority), 같은 심각성(severity)을 갖는다. 즉, 선정부(120)는 새로운 버그 리포트와 같은 토픽을 갖는 과거 버그 리포트로부터 추출된 개발자 뿐만 아니라, 새로운 버그 리포트와는 다른 멀티-특성을 가지는 버그 리포트로부터 추출된 개발자를 이용함으로써, 후보 개발자를 선정할 수 있다.
한편, 추천부(130)는 상기 선정된 후보 개발자의 활동 경험 정보(예를 들어, 코멘트 수, 커밋 수, 할당 수, 첨부 파일 수 등)를 이용하여 상기 후보 개발자의 추천 순위(즉, 랭킹)를 연산하고, 상기 연산된 추천 순위를 기반으로 상기 새로운 버그 리포트를 정정할 개발자를 추천한다.
추천부(130)는 상기 선정된 후보 개발자들의 활동 경험 정보로서, 상기 후보 개발자가 버그 정정에 참여한 활동을 나타내는 코멘트(comments) 수와 커밋(commits) 수, 및 상기 후보 개발자가 버그 정정에 참여한 경험을 나타내는 할당(assignments) 수와 첨부 파일(attachment) 수를 이용할 수 있다.
이때, 추천부(130)는 상기 코멘트 수, 상기 커밋 수, 상기 할당 수가 높고, 상기 첨부 파일의 할당 수가 낮을수록, 상기 후보 개발자들의 추천 순위가 높은 것으로 판단할 수 있다. 이에 대해 자세히 설명하면 다음과 같다.
추천부(130)는 새로운 버그를 정정할 적절한 개발자를 추천하기 위하여, 소셜 네트워크를 통해 후보 개발자들의 활동 정보(예를 들어, 코멘트와 커밋 활동)를 고려할 수 있다. 즉, 추천부(130)는 먼저, 후보 개발자들의 행동(혹은 활동)을 분석하기 위해, Eclipse, Mozilla and Netbeans 등의 저장소로부터 XML 파일을 파싱(parsing)함으로써, 후보 개발자들의 활동을 수집할 수 있다. 이때, 파싱은 다른 형식으로 저장된 데이터를 원하는 형식의 데이터로 변환하는 방식을 의미한다.
또한, 본 발명에서 추천부(130)는 적절한 개발자 추천 성능을 향상시키기 위한 요소로서, 코멘트(comment) 수와 커밋(commit) 수 뿐만 아니라, 할당(assignments) 수와 첨부 파일(attachments) 수를 고려할 수 있다.
그리고, 추천부(130)는 상기 후보 개발자들의 활동 경험 정보(예를 들어, 코멘트 수, 커밋 수, 할당 수, 첨부 파일 수 등)를 기반으로 한 수학식 2를 통해, 후보 개발자들의 추천 순위(즉, 랭킹)를 연산할 수 있다. 수학식 2는 후보 개발자들의 추천 순위(즉, 랭킹 점수)를 연산하는 계산법을 나타낸다.
Figure pat00003
여기에서, Devassignments는 버그 정정을 위해 개발자 Dev에게 할당된 수를 나타내고, Devattachments는 Dev에게 할당된 버그 리포트에 있는 첨부 파일(예를 들어, 업로드된 패치 파일 등)의 수를 나타낸다. 또한, Devcommit은 Dev에 의해 보내진 커밋(예를 들어, 버그 리포트의 이력에 대한 변경) 수를 나타내고, Devcomment는 Dev에 의해 달려진 코멘트 수를 나타낸다. n은 토픽 수를 나타낸다.
수학식 2를 참조하면, 본 발명은 버그 정정에서 개발자들의 활동 경험을 더욱 명확히 구분하기 위하여, 소셜 네트워크에서 후보 개발자들에 의해 게시된 코멘트와 커밋 수 외에, 할당 수와 첨부 파일 수를 고려하였다.
이때, 경험적 분석(empirical aesthetics) 면에서 보았을 때, 할당 수가 높을수록 개발자들의 경험이 더 많은 것으로 생각할 수 있다. 또한, 할당 수와 마찬가지로, 커밋 수는 개발자들의 경험을 증명하는 데에 이용될 수 있다.
한편, Hooimeijer와 Weimer가 발표한 논문("Modeling bug report quality," Proc. of IEEE/ACM Inlernational Conference on Automated Software Engineering 2007, pp. 34-43.)에 따르면, Hooimeijer와 Weimer는 코멘트 수가 양의 계수임을 증명하였으며, 그 이유는 해당 버그가 정정될 가능성이 높으므로, 할당된 버그가 사용자의 관심을 더 많이 받았다는 것을 의미하기 때문이다. 또한 그들은 첨부 파일 수가 음의 계수임을 발견했으며, 그 이유는 첨부 파일의 존재는 버그를 수정하기 위해 증가된 비용을 의미하기 때문이다.
이에 따라, 본 발명의 추천부(130)는 후보 개발자들의 추천 순위를 연산하기 위하여, 수학식 2에서 Devassignments, Devcommit, Devcomment는 분자로, Devattachments는 분모로 지정하였다. 즉, 추천부(130)는 상기 코멘트 수, 상기 커밋 수, 상기 할당 수가 높고, 상기 첨부 파일의 할당 수가 낮을수록, 상기 후보 개발자들의 추천 순위가 높은 것으로 판단할 수 있다. 추천부(130)는 각 후보 개발자들의 DRScore를 계산함으로서, 상기 후보 개발자의 추천 순위(즉, 랭킹)를 연산할 수 있으며, 상기 연산된 추천 순위를 기반으로 상기 새로운 버그 리포트를 정정할 적절한 개발자를 추천할 수 있다.
도 4는 본 발명의 일 실시예에 따른 버그 정정 개발자 추천을 위한 프레임워크를 나타낸 도면이다.
상기에 자세히 설명된 내용을 기반으로, 이하에서는 본 발명의 일 실시예에 따른 버그 정정 개발자 추천을 위한 프레임워크를 간단히 설명하기로 한다.
도 4를 참조하면, 본 발명의 시스템(100)은 수신한 새로운 버그 리포트를 정정할 적절한 개발자를 추천하기 위하여, 먼저, 스텝 1(Step 1)에서는 제1 추출부(110)를 통해, 모델링된 토픽을 기반으로 수신한 새로운 버그 리포트와 대응하는 토픽을 식별하고, 상기 식별된 토픽을 가진 과거 버그 리포트를 추출한다.
그리고 나서, 스텝 1에서 선정부(120)는 상기 추출된 과거 버그 리포트를 이용하여 후보 개발자를 선정한다. 이때, 후보 개발자는 과거 버그 리포트로부터 추출된 담당자(assigness)와 코멘터(commenters)를 포함하는 제1 개발자(토픽 모델을 이용한 개발자)와, 상기 과거 버그 리포트와 같은 특성을 갖는 버그 리포트로부터 추출된 제2 개발자(다중-특성을 이용한 개발자)를 기반으로 선정될 수 있다. 이에 대한 설명은 상기에 자세히 설명되어 있으므로, 이를 참조하기로 한다.
그리고 스텝 2(Step 2)는 상기 후보 개발자들의 추천 순위를 연산하기 위하여, 추천부(130)를 통해, 각 후보 개발자들의 활동 경험 정보를 추출할 수 있다. 이때, 후보 개발자들의 활동 경험 정보로서, 상기 후보 개발자가 버그 정정에 참여한 활동을 나타내는 코멘트(comments) 수와 커밋(commits) 수, 및 상기 후보 개발자가 버그 정정에 참여한 경험을 나타내는 할당(assignments) 수와 첨부 파일(attachment) 수가 추출될 수 있다.
마지막으로, 스텝 3(Step 3)에서는 추천부(130)를 통해, 상기 스텝 2에서 추출된 후보 개발자들의 활동 경험 정보를 기반으로, 상기 후보 개발자의 추천 순위(즉, 랭킹 순위)를 연산하고, 상기 연산된 추천 순위를 기반으로 상기 새로운 버그 리포트를 정정할 개발자를 추천할 수 있다. 이에 대한 설명은 상기에 자세히 설명했으므로, 이를 참조하기로 한다.
한편, 도 2는 본 발명의 제2 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템의 구성도이다.
도 2를 참조하면, 본 발명의 제2 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템(100)은 제1 추출부(110)와 예측부(140)를 포함할 수 있다. 그리고 예측부(140)는 제2 추출부(141)와 계산부(142)를 포함할 수 있다. 우선, 각 구성의 역할에 대해 간단히 설명하면 다음과 같다.
제1 추출부(110)에 대한 설명은 상기에 자세히 설명했으므로, 이하 생략하기로 한다. 예측부(140)는 제1 추출부(110)에서 추출된 상기 식별된 토픽을 가진 과거 버그 리포트를 기반으로, 상기 새로운 버그 리포트의 심각성을 예측한다.
제2 추출부(141)는 상기 제1 추출부에서 추출된 상기 식별된 토픽을 가진 과거 버그 리포트로부터 같은 특성을 갖는 공통 버그 리포트를 추출한다. 즉, 제2 추출부(141)는 상기 식별된 토픽을 가진 과거 버그 리포트들을 기반으로, 같은 특성을 지닌 버그 리포트들끼리 집합으로 형성하고, 상기 형성된 집합들의 교집합을 공통 버그 리포트로서 추출할 수 있다.
계산부(142)는 상기 추출된 공통 버그 리포트와 상기 새로운 버그 리포트 간에 텍스트 유사도를 계산한다. 이때, 계산부(142)는 벡터로 표현된 상기 새로운 버그 리포트(즉, smoothed UM)와 KL 발산(Kullback-Leibler divergence)을 이용하여 상기 텍스트 유사도를 계산할 수 있다.
그리고 예측부(140)는 계산부(142)에서 계산된 텍스트 유사도를 기반으로 하고, K-최근접 이웃(K-nearest Neighbor) 알고리즘을 이용하여 상기 새로운 버그 리포트의 심각성을 예측할 수 있다.
이에 대해 보다 자세히 설명하면 다음과 같다. 앞서 도 1을 참조한 실시예에서는, 새로운 버그 리포트를 정정할 적절한 개발자를 추천하기 위하여, "제품(Product)", "구성 요소(Component)", "우선 순위(Priority)", "심각성(Severity)"을 포함하는 멀티-특성(multi-feature)을 이용하였지만, 이하의 실시예에서는, 새로운 버그 리포트의 심각성을 예측하기 위하여, "심각성(Severity)"을 제외한 "제품(Product)", "구성 요소(Component)", "우선 순위(Priority)"를 포함하는 멀티-특성(multi-feature)을 이용하기로 한다.
본 발명의 시스템(100)은 수신한 버그 리포트의 심각성을 예측하기 위하여, "제품(Product)", "구성 요소(Component)", "우선 순위(Priority)"를 포함하는 멀티-특성(multi-feature)을 이용해 해당 버그 리포트를 필터링한 후, 잠재적인(potential) 버그 리포트를 생성할 수 있다. 그리고 본 발명의 시스템(100)은 KL 발산을 통해 새로운 버그 리포트와 과거 버그 리포트 사이에 유사도를 계산하고, 새로운 버그의 심각성을 예측하기 위하여 KNN에 상기의 유사성 측정 값을 적용함으로써, 새로운 버그 리포트의 심각성을 예측할 수 있다. 이에 대한 설명은 도 5를 참조하여 더 자세히 설명하기로 한다.
도 5는 본 발명의 일 실시예에 따른 버그 리포트의 심각성 예측을 위한 작업 흐름을 나타낸 도면이다.
도 5를 참조하면, 본 발명의 시스템(100)은 수신한 새로운 버그 리포트의 심각성을 예측하기 위하여, 앞서 도 1을 참조한 실시예와 마찬가지로 토픽 모델과 멀티-특성을 이용할 수 있다.
먼저, 도 5의 스텝 1(Step 1)에서 보는 바와 같이, 제1 추출부(110)는 먼저, 수신한 새로운 버그 리포트가 속한 토픽을 식별하고, 상기 식별된 토픽을 포함하는 과거 버그 리포트, 즉 새로운 버그 리포트와 동일한 토픽을 가진 과거 버그 리포트를 추출한다.
그리고 스텝 1에서 제2 추출부(141)는 추출된 과거 버그 리포트로부터 같은 특성을 갖는 공통 버그 리포트를 추출한다. 이때, 제2 추출부(141)는 제1 추출부(110)에서 추출된 과거 버그 리포트를 기반으로, 같은 특성(예를 들어, 제품, 구성 요소, 우선 순위)을 가진 버그 리포트들끼리 하나의 집합을 형성한다. 그리고 각 특성끼리 형성된 집합들의 교집합은 공통 버그 리포트가 된다. 이하 수학식 3은 버그 리포트 집합의 교집합 프로세스를 나타낸다.
Figure pat00004
즉, 수학식 3을 참조하면, 제2 추출부(141)는 새로운 버그 리포트가 속하는 토픽을 갖는 과거 버그 리포트들을 기반으로, 동일한 "제품(product)" 특성을 갖는 버그 리포트의 집합, 동일한 "구성 요소(component)" 특성을 갖는 버그 리포트의 집합, 및 동일한 "우선 순위(priority)" 특성을 갖는 버그 리포트의 집합을 형성할 수 있다. 그리고, 제2 추출부(141)는 각 집합들의 교집합으로부터, 필터핑된 버그 리포트 B(즉, 최종 추출된 버그 리포트)를 획득할 수 있다.
다음으로, 스텝 2에서 계산부(142)는 smoothed UM과 KL 발산(Kullback-Leibler divergence)을 이용하여, 새로운 버그 리포트와 제2 추출부(141)에서 획득한 필터링된 버그 리포트 B와 사이에, 텍스트 유사성을 계산한다.
이때, smoothed UM과 KL 발산(Kullback-Leibler divergence)에 대해 자세히 설명하면 다음과 같다.
상기 smoothed UM(smoothed unigram model)은 평활화된 유니그램 모델을 의미하는 것으로서, 이는 특정 문서에 대한 확률 벡터의 발생 확률이 0이 되는 것을 방지하기 위하여, 문서의 전체 컬렉션에서 특정 단어의 발생 확률을 측정하는 컬렉션 모델을 사용함으로써 유니그램 모델을 smoothed하게 만든 것을 의미한다. 본 발명은 smoothed UM을 이용함으로써, 필터링된 버그 리포트 B와 새로운 버그 리포트 간에 텍스트 유사성을 계산할 수 있다.
각 문서의 유니그램(unigram)은 벡터 공간 상에 둘 이상의 확률 변수로 구성된 벡터(즉, 확률 벡터)로 표현될 수 있다.
하지만, 만약 어떤 단어가 한 문서에서 발생하지 않았을 경우, 이 문서에 대한 확률 벡터의 발생 확률은 0이 되며, 이러한 현상은 확률 수식에서 문제를 야기할 수 있다. 따라서, 이러한 문제를 해결하기 위하여, 최초의 유니그램 모델은 문서들의 전체 컬렉션에서 특정 단어의 발생 확률을 측정하는 컬렉션 모델을 사용함으로써 유니그램 모델(unigram model)을 평활(smoothed)하게 만든다.
아래에 정의된 수학식 4는 K번째 문서의 smoothed UM을 나타내며, 이 식의 두번째 부분은 컬렉션 모델을 나타낸다. 다시 말해, 수학식 4의 두번째 부분은, 만약에 특정 단어가 버그 리포트에서 전혀 발생하지 않았을 경우에 발생 확률이 0이 되는 것을 회피하기 위해 평활화된 유니그램 모델(smoothed UM)을 사용한, 컬렉션 모델을 의미한다. 이하 수학식 4는 smoothed UM을 나타낸다.
Figure pat00005
이때, ω는 용어를 의미하고,
Figure pat00006
는 k 리포트의 가중치 벡터(weight vector)를 의미한다.
Figure pat00007
는 k 리포트 안에 단어 수를 의미하며, ωk(n)은 k 리포트 안에 n번째 출현 빈도를 나타낸다. K는 리포트의 총 개수를 의미하며, μ는 수학식 1에서 두 부분의 서로 다른 가중치를 의미한다.
한편, 계산부(142)는 KL 발산(Kullback-Leibler divergence)을 이용함으로써, 필터링된 버그 리포트 B와 새로운 버그 리포트 간에 텍스트 유사성을 계산할 수 있다.
KL 발산은 새로운 버그 리포트와 필터링된 버그 리포트 B(즉, 과거 버그 리포트) 사이에 유사도를 계산하기 위해 사용되는 것으로서, 두 확률 분포의 차이를 계산하는 데에 사용하는 함수이다. 이때, KL 발산이 높을수록 유사도는 낮은 것을 의미한다.
즉, 이하 수학식 5는 KL 발산을 이용한 유사도 계산법을 나타낸다.
Figure pat00008
이때,
Figure pat00009
는 쿼리 q에서 용어 ω가 나타나는 확률을 의미하고,
Figure pat00010
는 버그 리포트 k에서 용어 ω가 나타나는 확률을 의미한다.
따라서, 계산부(142)는 smoothed UM과 KL 발산(Kullback-Leibler divergence)을 이용하여, 새로운 버그 리포트와 필터링된 버그 리포트 사이에, 텍스트 유사성을 계산할 수 있다. 즉, 본 발명의 시스템(100)은 상기 수학식 5에 따른 KL 발산을 이용함으로써, 버그 리포트 간에 텍스트 유사성을 측정할 수 있다.
마지막으로, 스텝 3에서 예측부(140)는 상기의 텍스트 유사도 값을 가져옴으로써, 차단(Blocker), 비판적인(Critical), 주요한(Major), 보통(Normal), 작은(Minor), 사소한(Trivial) 또는 향상(Enhancement) 중 하나로 상기 새로운 버그 리포트의 심각성을 예측하기 위하여, R 언어에서 실행되는 KNN을 사용한다.
즉, 본 발명의 시스템(100)은 새로운 버그가 도착했을 때, 주어진 새로운 버그 리포트와 같은 토픽과 같인 멀티-특성을 가지는 상위 k와 유사한 과거 버그 리포트를 검색하기 위하여, KNN을 사용하며, 본 발명은 K-최근접 이웃(K-nearest Neighbor) 알고리즘의 심각성 라벨(severity labels)을 고려함으로써, 새로운 버그에 속한 심각도 상태를 예측할 수 있다.
KNN은 비모수적(non-parametric) 지연 학습 알고리즘을 나타내는 것으로서, 이는 주어진 인스턴스(instance)(이때, 인스턴스는 어떤 집합 내의 개별적인 요소를 의미함)와 유사한 상위 K 개체(objects)를 찾는 기술을 의미한다.
더 자세히 말하자면, KNN은 라벨링 되어있는 데이터를 기반으로, 거리를 통해 어떤 데이터가 어떤 군집에 속하는지를 판별하는 기술로서, 새로 추가된 데이터와 가장 가까운 거리에 있는 K 개의 데이터를 모두 확인한 후, 확인된 K 개의 데이터에서 가장 많은 특성을 나타내는 라벨로 새로운 데이터의 라벨을 결정하는 것을 말한다.
이를 통해, 예측부(140)는 KNN을 기반으로 수신한 버그 리포트의 심각도 상태를 분석함으로써, 새로운 버그의 심각성을 쉽게 예측할 수 있다.
이하에서는 상기에 자세히 설명된 내용을 기반으로 본 발명의 동작 흐름도를 간단히 설명하기로 한다.
도 6은 본 발명의 일 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법에 대한 동작 흐름도이다.
도 6을 참조하면, 본 발명의 일 실시예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법은 우선, 시스템(100)의 제1 추출부(110)에 의하여, 모델링된 토픽을 기반으로 수신한 새로운 버그 리포트와 대응하는 토픽(Topic)을 식별하고, 상기 식별된 토픽을 가진 과거 버그 리포트를 추출한다(S610).
이때, 제1 추출부(110)는 상기 수신한 새로운 버그 리포트에 나타나는 토픽 용어의 빈도수를 이용하여, 상기 수신한 새로운 버그 리포트와 대응하는 토픽을 식별할 수 있다. 상기 빈도 수는 높을수록 수신한 새로운 버그 리포트와 토픽이 일치하는 것을 의미한다. 이는 상기에 자세히 설명했으므로 이를 참조하기로 한다.
다음으로, 시스템(100)의 선정부(120)가 상기 새로운 버그 리포트를 정정할 적절한 개발자를 추천하기 위하여, 상기 추출된 과거 버그 리포트를 이용하여 후보 개발자를 선정한다(S620).
이때, 후보 개발자는 토픽 모델을 이용한 개발자들 집합과 특성 정보를 이용한 개발자들 집합의 교집합으로부터 선정할 수 있다.
더 자세히 말하자면, 선정부(120)는 상기 과거 버그 리포트로부터 추출된 담당자(assigness)와 코멘터(commenters)를 포함하는 제1 개발자(즉, 토픽 모델을 이용하여 추출된 개발자들의 집합)와, 상기 과거 버그 리포트와 같은 특성을 갖는 버그 리포트로부터 추출된 제2 개발자(즉, 다중-특성을 이용하여 추출된 개발자들의 집합)를 기반으로 상기 후보 개발자를 선정할 수 있으며, 이때, 선정부(120)는 상기 과거 버그 리포트 내에 포함된 제품(Product), 구성 요소(Component), 우선 순위(Priority), 심각성(Severity) 중 적어도 하나 이상의 멀티-특성(Multi-Feature) 정보를 이용하여 상기 제2 개발자를 추출할 수 있다. 이는 상기에 자세히 설명했으므로 이를 참조하기로 한다.
다음으로, 시스템(100)의 추천부(130)가 상기 선정된 후보 개발자의 활동 경험 정보(예를 들어, 코멘트 수, 커밋 수, 할당 수, 첨부 파일 수 등)를 이용하여 상기 후보 개발자의 추천 순위(즉, 랭킹)를 연산하고, 상기 연산된 추천 순위를 기반으로 상기 새로운 버그 리포트를 정정할 개발자를 추천한다(S630).
이때, 추천부(130)는 상기 선정된 후보 개발자들의 활동 경험 정보로서, 상기 후보 개발자가 버그 정정에 참여한 활동을 나타내는 코멘트(comments) 수와 커밋(commits) 수, 및 상기 후보 개발자가 버그 정정에 참여한 경험을 나타내는 할당(assignments) 수와 첨부 파일(attachment) 수를 이용할 수 있다. 그리고, 추천부(130)는 상기 코멘트 수, 상기 커밋 수, 상기 할당 수가 높고, 상기 첨부 파일의 할당 수가 낮을수록, 상기 후보 개발자들의 추천 순위가 높은 것으로 판단할 수 있다. 이는 상기에 자세히 설명했으므로 이를 참조하기로 한다.
다음으로, 본 발명의 시스템(100)은 예측부(140)에 의하여, 제1 추출부(110)에서 추출된 상기 식별된 토픽을 가진 과거 버그 리포트를 기반으로, 상기 새로운 버그 리포트의 심각성을 예측할 수 있다(S640).
이때, 단계 S640에서는 새로운 버그 리포트의 심각성을 예측하기 위하여, 우선, 예측부(140) 내의 제2 추출부(141)에 의하여, 상기 제1 추출부에서 추출된 상기 식별된 토픽을 가진 과거 버그 리포트로부터 같은 특성을 갖는 공통 버그 리포트를 추출할 수 있다. 상기 제2 추출부(141)는 상기 식별된 토픽을 가진 과거 버그 리포트들을 기반으로, 같은 특성을 지닌 버그 리포트들끼리 집합으로 형성하고, 상기 형성된 집합들의 교집합을 공통 버그 리포트로서 추출할 수 있으며, 이는 상기에 자세히 설명했으므로 이를 참조하기로 한다.
그리고 단계 S640에서는 예측부(140) 내의 계산부(142)에 의하여, 상기 추출된 공통 버그 리포트와 상기 새로운 버그 리포트 간에 텍스트 유사도를 계산할 수 있다. 상기 계산부(142)는 벡터로 표현된 상기 새로운 버그 리포트(즉, smoothed UM)와 KL 발산(Kullback-Leibler divergence)을 이용하여 상기 텍스트 유사도를 계산할 수 있으며, 이는 상기에 자세히 설명했으므로 이를 참조하기로 한다.
그리고 단계 S640에서 예측부(140)는 계산부(142)에서 계산된 텍스트 유사도를 기반으로 하고, K-최근접 이웃(K-nearest Neighbor) 알고리즘을 이용하여 상기 새로운 버그 리포트의 심각성을 예측할 수 있다. 이는 상기에 자세히 설명했으므로 이를 참조하기로 한다.
이에 따라, 본 발명의 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법은 버그 리포트의 토픽 모델과, 버그 리포트의 제품, 구성 요소, 우선 순위 및 심각성을 포함하는 다중 특성을 이용함으로써, 보다 적절한 버그 정정 개발자를 추천하고, 버그 리포트의 심각성을 예측할 수 있는 효과가 있다.
본 발명의 일 실시 예에 따른 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상과 같이 본 발명에서는 구체적인 구성 요소 등과 같은 특정 사항들과 한정된 실시예 및 도면에 의해 설명되었으나 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐, 본 발명은 상기의 실시예에 한정되는 것은 아니며, 본 발명이 속하는 분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형이 가능하다.
따라서, 본 발명의 사상은 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐 아니라 이 특허청구범위와 균등하거나 등가적 변형이 있는 모든 것들은 본 발명 사상의 범주에 속한다고 할 것이다.
100: 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템
110: 제1 추출부 120: 선정부
130: 추천부 140: 예측부
141: 제2 추출부 142: 계산부

Claims (19)

  1. 모델링된 토픽을 기반으로 수신한 새로운 버그 리포트와 대응하는 토픽을 식별하고, 상기 식별된 토픽을 가진 과거 버그 리포트를 추출하는 제1 추출부;
    상기 새로운 버그 리포트를 정정할 개발자를 추천하기 위하여, 상기 추출된 과거 버그 리포트를 이용하여 후보 개발자를 선정하는 선정부; 및
    상기 선정된 후보 개발자의 활동 경험 정보를 이용하여 상기 후보 개발자의 추천 순위를 연산하고, 상기 연산된 추천 순위를 기반으로 상기 새로운 버그 리포트를 정정할 개발자를 추천하는 추천부;
    를 포함하는 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템.
  2. 제1항에 있어서,
    상기 제1 추출부는
    상기 새로운 버그 리포트에 나타나는 토픽 용어의 빈도수를 이용하여 식별하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템.
  3. 제1항에 있어서,
    상기 선정부는
    상기 과거 버그 리포트로부터 추출된 담당자와 코멘터를 포함하는 제1 개발자와, 상기 과거 버그 리포트와 같은 특성을 갖는 버그 리포트로부터 추출된 제2 개발자를 기반으로 상기 후보 개발자를 선정하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템.
  4. 제3항에 있어서,
    상기 선정부는
    상기 과거 버그 리포트 내에 포함된 제품, 구성 요소, 우선 순위, 심각성 중 적어도 하나 이상의 특성 정보를 이용하여 상기 제2 개발자를 추출하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템.
  5. 제1항에 있어서,
    상기 추천부는
    상기 활동 경험 정보로서, 상기 후보 개발자가 버그 정정에 참여한 활동을 나타내는 코멘트(comments) 수와 커밋(commits) 수, 및 상기 후보 개발자가 버그 정정에 참여한 경험을 나타내는 할당(assignments) 수와 첨부 파일(attachment) 수를 이용하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템.
  6. 제5항에 있어서,
    상기 추천부는
    상기 코멘트 수, 상기 커밋 수, 상기 할당 수가 높고, 상기 첨부 파일의 할당 수가 낮을수록, 상기 후보 개발자들의 추천 순위가 높은 것으로 판단하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템.
  7. 제1항에 있어서,
    상기 제1 추출부에서 추출된 과거 버그 리포트를 기반으로, 상기 새로운 버그 리포트의 심각성을 예측하는 예측부;
    를 더 포함하는 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템.
  8. 제7항에 있어서,
    상기 예측부는
    상기 제1 추출부에서 추출된 과거 버그 리포트로부터 같은 특성을 갖는 공통 버그 리포트를 추출하는 제2 추출부; 및
    상기 추출된 공통 버그 리포트와 상기 새로운 버그 리포트 간에 텍스트 유사도를 계산하는 계산부;
    를 포함하고,
    상기 계산된 텍스트 유사도를 기반으로 하고, K-최근접 이웃(K-nearest Neighbor) 알고리즘을 이용하여 상기 새로운 버그 리포트의 심각성을 예측하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템.
  9. 제8항에 있어서,
    상기 계산부는
    벡터로 표현된 상기 새로운 버그 리포트와 KL 발산(Kullback-Leibler divergence)을 이용하여 상기 텍스트 유사도를 계산하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템.
  10. 모델링된 토픽을 기반으로 수신한 새로운 버그 리포트와 대응하는 토픽을 식별하고, 상기 식별된 토픽을 가진 과거 버그 리포트를 추출하는 단계;
    상기 새로운 버그 리포트를 정정할 개발자를 추천하기 위하여, 상기 추출된 과거 버그 리포트를 이용하여 후보 개발자를 선정하는 단계; 및
    상기 선정된 후보 개발자의 활동 경험 정보를 이용하여 상기 후보 개발자의 추천 순위를 연산하고, 상기 연산된 추천 순위를 기반으로 상기 새로운 버그 리포트를 정정할 개발자를 추천하는 단계;
    를 포함하는 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법.
  11. 제10항에 있어서,
    상기 과거 버그 리포트를 추출하는 단계는
    상기 새로운 버그 리포트에 나타나는 토픽 용어의 빈도수를 이용하여 식별하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법.
  12. 제10항에 있어서,
    상기 후보 개발자를 선정하는 단계는
    상기 과거 버그 리포트로부터 추출된 담당자와 코멘터를 포함하는 제1 개발자와, 상기 과거 버그 리포트와 같은 특성을 갖는 버그 리포트로부터 추출된 제2 개발자를 기반으로 상기 후보 개발자를 선정하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법.
  13. 제12항에 있어서,
    상기 후보 개발자를 선정하는 단계는
    상기 과거 버그 리포트 내에 포함된 제품, 구성 요소, 우선 순위, 심각성 중 적어도 하나 이상의 특성 정보를 이용하여 상기 제2 개발자를 추출하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법.
  14. 제10항에 있어서,
    상기 개발자를 추천하는 단계는
    상기 활동 경험 정보로서, 상기 후보 개발자가 버그 정정에 참여한 활동을 나타내는 코멘트(comments) 수와 커밋(commits) 수, 및 상기 후보 개발자가 버그 정정에 참여한 경험을 나타내는 할당(assignments) 수와 첨부 파일(attachment) 수를 이용하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법.
  15. 제14항에 있어서,
    상기 개발자를 추천하는 단계는
    상기 코멘트 수, 상기 커밋 수, 상기 할당 수가 높고, 상기 첨부 파일의 할당 수가 낮을수록, 상기 후보 개발자들의 추천 순위가 높은 것으로 판단하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법.
  16. 제10항에 있어서,
    상기 과거 버그 리포트를 추출하는 단계에서 추출된 과거 버그 리포트를 기반으로, 상기 새로운 버그 리포트의 심각성을 예측하는 단계;
    를 더 포함하는 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법.
  17. 제16항에 있어서,
    상기 심각성을 예측하는 단계는
    상기 과거 버그 리포트를 추출하는 단계에서 추출된 과거 버그 리포트로부터 같은 특성을 갖는 공통 버그 리포트를 추출하는 단계; 및
    상기 추출된 공통 버그 리포트와 상기 새로운 버그 리포트 간에 텍스트 유사도를 계산하는 단계;
    를 포함하고,
    상기 계산된 텍스트 유사도를 기반으로 하고, K-최근접 이웃(K-nearest Neighbor) 알고리즘을 이용하여 상기 새로운 버그 리포트의 심각성을 예측하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법.
  18. 제17항에 있어서,
    상기 텍스트 유사도를 계산하는 단계는
    벡터로 표현된 상기 새로운 버그 리포트와 KL 발산(Kullback-Leibler divergence)을 이용하여 상기 텍스트 유사도를 계산하는
    토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 방법.
  19. 제10항 내지 제18항 중 어느 한 항의 방법을 실행하기 위한 프로그램이 기록되어 있는 것을 특징으로 하는 컴퓨터에서 판독 가능한 기록매체.
KR1020150008201A 2015-01-16 2015-01-16 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법 KR101691083B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020150008201A KR101691083B1 (ko) 2015-01-16 2015-01-16 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020150008201A KR101691083B1 (ko) 2015-01-16 2015-01-16 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법

Publications (2)

Publication Number Publication Date
KR20160088737A true KR20160088737A (ko) 2016-07-26
KR101691083B1 KR101691083B1 (ko) 2016-12-29

Family

ID=56680935

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150008201A KR101691083B1 (ko) 2015-01-16 2015-01-16 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법

Country Status (1)

Country Link
KR (1) KR101691083B1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109918100A (zh) * 2019-01-25 2019-06-21 扬州大学 一种面向版本缺陷的基于修复模式的修复推荐方法
CN112667492A (zh) * 2020-11-06 2021-04-16 北京工业大学 一种软件缺陷报告修复人推荐方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050054150A (ko) * 2003-12-04 2005-06-10 한국전자통신연구원 실시간 디버깅 방법
KR20120069388A (ko) 2010-12-20 2012-06-28 엠디에스테크놀로지 주식회사 정적 결함 분류 및 보고 자동화 시스템 및 그 방법
JP2013065228A (ja) * 2011-09-20 2013-04-11 Hitachi Solutions Ltd バグ対策優先度表示システム
KR101390220B1 (ko) * 2012-11-07 2014-04-30 서울시립대학교 산학협력단 소프트웨어 버그 정정을 위한 적합한 개발자 추천 방법 및 장치

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050054150A (ko) * 2003-12-04 2005-06-10 한국전자통신연구원 실시간 디버깅 방법
KR20120069388A (ko) 2010-12-20 2012-06-28 엠디에스테크놀로지 주식회사 정적 결함 분류 및 보고 자동화 시스템 및 그 방법
JP2013065228A (ja) * 2011-09-20 2013-04-11 Hitachi Solutions Ltd バグ対策優先度表示システム
KR101390220B1 (ko) * 2012-11-07 2014-04-30 서울시립대학교 산학협력단 소프트웨어 버그 정정을 위한 적합한 개발자 추천 방법 및 장치

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109918100A (zh) * 2019-01-25 2019-06-21 扬州大学 一种面向版本缺陷的基于修复模式的修复推荐方法
CN109918100B (zh) * 2019-01-25 2022-05-17 扬州大学 一种面向版本缺陷的基于修复模式的修复推荐方法
CN112667492A (zh) * 2020-11-06 2021-04-16 北京工业大学 一种软件缺陷报告修复人推荐方法
CN112667492B (zh) * 2020-11-06 2024-03-08 北京工业大学 一种软件缺陷报告修复人推荐方法

Also Published As

Publication number Publication date
KR101691083B1 (ko) 2016-12-29

Similar Documents

Publication Publication Date Title
US11449379B2 (en) Root cause and predictive analyses for technical issues of a computing environment
US10977293B2 (en) Technology incident management platform
US11314576B2 (en) System and method for automating fault detection in multi-tenant environments
Yang et al. Towards semi-automatic bug triage and severity prediction based on topic model and multi-feature of bug reports
EP3483797A1 (en) Training, validating, and monitoring artificial intelligence and machine learning models
US20170109657A1 (en) Machine Learning-Based Model for Identifying Executions of a Business Process
US10671352B2 (en) Data processing platform for project health checks and recommendation determination
US20170109676A1 (en) Generation of Candidate Sequences Using Links Between Nonconsecutively Performed Steps of a Business Process
US20170109668A1 (en) Model for Linking Between Nonconsecutively Performed Steps in a Business Process
US11269901B2 (en) Cognitive test advisor facility for identifying test repair actions
US20170109667A1 (en) Automaton-Based Identification of Executions of a Business Process
Ahmed et al. Capbug-a framework for automatic bug categorization and prioritization using nlp and machine learning algorithms
US20200242623A1 (en) Customer Support Ticket Aggregation Using Topic Modeling and Machine Learning Techniques
US20170109636A1 (en) Crowd-Based Model for Identifying Executions of a Business Process
KR20150046088A (ko) 소프트웨어 빌드 에러를 예측하기 위한 방법 및 시스템
AU2019208146B2 (en) Information transition management platform
US20170109639A1 (en) General Model for Linking Between Nonconsecutively Performed Steps in Business Processes
US9990268B2 (en) System and method for detection of duplicate bug reports
US20220309332A1 (en) Automated contextual processing of unstructured data
US11550707B2 (en) Systems and methods for generating and executing a test case plan for a software product
US20220188181A1 (en) Restricting use of selected input in recovery from system failures
Mısırlı et al. Different strokes for different folks: A case study on software metrics for different defect categories
US20170109640A1 (en) Generation of Candidate Sequences Using Crowd-Based Seeds of Commonly-Performed Steps of a Business Process
KR101691083B1 (ko) 토픽 모델과 다중 특성 기반의 버그 정정 개발자 추천 및 버그 심각성 예측 시스템 및 방법
Husain et al. Application of data mining techniques for improving software engineering

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20191202

Year of fee payment: 4