ソフトウェア・シンポジウム 2015 in 和歌山

ソフトウェア開発状況の把握を目的とした変化点検出を用いたソフトウェアメトリクスの時系列データ分析
久木田 雄亮和歌山大学 システム工学研究科
s161018@sys.wakayama-u.ac.jp

柏 祐太郎
和歌山大学 システム工学研究科
kashiwa.yutaro@g.wakayama-u.jp

大平 雅雄
和歌山大学 システム工学部
masao@sys.wakayama-u.ac.jp

要旨

ア開発における進捗・品質管理にとって必要不可欠な存在である．

大規模ソフトウェア開発では，進捗および品質の状況

既存のモニタリングツールを用いた品質管理では，プを随時把握する必要がある．開発状況を把握するため

ロジェクトが計画通りに進んでいるか否か，品質が一定のモニタリングツールは多数存在しているが，異変が起の水準に保たれるかどうかの判断は，未だにプロジェク

こっているかの判断はプロジェクト管理者の勘と経験にト管理者の勘と経験による部分が大きいとされる．そのよる部分が大きい．そこで本研究では，変化点検出アルため，開発の遅延やソフトウェアの障害につながる可能

ゴリズムを用いて，リアルタイムに計測したソフトウェ性のある異変をいち早く検知するための支援が求められ

アメトリクスの値から開発状況の異変を機械的に検出すている．

るための手法を提案する．Eclipse Platform プロジェク

例えば，コード行数（LOC） を計測してソースコー

トを対象としてケーススタディを行った結果，変化点前

ドの規模推移をリアルタイムにモニタリングする状況を後で開発の活動内容が別の活動内容にシフトしていく様考える．実装開始直後は通常，LOC の変化（増加量）は子を見てとることができた．また，トピック分析を併用

日々比較的大きな値をとり，出荷に向けて LOC の変化

した場合，プロジェクト管理者が変化の内容を理解しなは小さな値をとる．テスト工程での欠陥修正による LOC

がら開発状況を把握できることが分かった．

の変化は，実装工程での LOC の変化に比べ小さなもの
であることが多いため，テスト工程でのコード修正にまつわるなんらかの異常を LOC の変化から見て取るこ

1. はじめにとは困難であると考えられる．すなわち，ソースコードの規模推移がすべて見渡せる環境があるが故に，分析者

ソフトウェア製品の大規模化・複雑化に伴って，高品（プロジェクト管理者）は変化の大きさを相対的に認知質なソフトウェアを安定して開発することが困難になっしてしまい，工程や期間毎に意味の異なる変化を見落とてきている．ソフトウェアの品質を維持しつつ開発を行してしまう可能性が高い．プロジェクトの異変を，相対うためには，開発・品質状況を随時把握する必要がある．

的な変化ではなく工程毎のコンテキストに沿った意味的

そのため，ソフトウェアメトリクスのリアルタイム収集な変化として機械的に検知することができれば，早くにおよび定量的な進捗・品質計測を支援するモニタリング

対処することができる可能性がある．

ツールが多数提案されてきた [9][3][5]．ソフトウェアメ

本研究の目的は，変化点検出アルゴリズム [10] を用い

トリクスとは，ソフトウェア開発データの様々な特性かて，プロジェクトの進捗・品質状況の悪化などといったら計測可能な定量的尺度 [11] のことであり，ソフトウェ

27

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

変化を，リアルタイムに計測したソフトウェアメトリク

3）．例えば，取得しているメトリクスの 1 つに CFD(Customer-Found Defect) があり，顧客が発見した欠陥の数を取得して表示していることが見て取れる．

スの値から早い段階で捉えるための手法の構築することである．本論文では，オープンソースプロジェクトから取得したデータに対して変化点検出を行うとともに，トHackystat[1] は，ソフトウェアのプロダクトデータとピック分析 [2] を用いて変化の要因を理解することが可

プロセスデータを収集・分析し，結果を可視化するツー能かどうかを確かめる．

ルである（図 4）．Hackystat は，プロジェクトの開発者や管理者がプロジェクトの開発状況を把握することに

2. モニタリングツールによるソフトウェア管理用いられる以外に，教育分野でも用いられている．

大規模かつ複雑な作業の組み合わせを経て開発され

2.2

既存のモニタリングツールの問題点

る近年のソフトウェアを，定められた納期に定められた品質で開発するのは容易ではない．ソフトウェアをより

既存のモニタリングツールは基本的に，取得・計測し安定して開発するためには，開発者の能力や開発対象にた値のみを可視化する．現在プロジェクトが順調に進ん

よって品質が左右されないようにリソース割当計画や開でいるのか停滞しているのかといった判断は，管理者や発プロセスを策定し，進捗・品質を管理することが必要

開発者の経験や勘に頼る部分が大きい．特に，問題発見となる．プロジェクトの状況を把握し問題点を発見・対は管理者および開発者の判断で行われるため，プロジェ処するために，プロジェクトの状況を可視化するモニタ

クトの遅延につながる問題や，後に大きな障害となりそ

リングツールが多数存在している．本章では，既存のモうな可能性のある変更（code change）が混入したかど

ニタリングツールをいくつか紹介し，本研究の立場の違うか，などを時系列のグラフや値から読み取ることは難いを説明する．

しい．プロジェクト遅延や品質低下を招く原因となりうる変化を機械的にできるだけ早く見つけることができれ

2.1. プロジェクト管理を目的としたモニタリングツール

ば，手戻りコストを減らすことができると言える．
本研究では，プロジェクトの進捗・品質管理において

プロジェクトモニタリングツールのひとつとして，大今後大きな問題につながる変化を，開発者や管理者の勘平らの EPM(Empirical Projet Monitor) [9][4] があるや経験に頼らず，自動的にリアルタイムで抽出する手法（図 1）．EPM は，リアルタイムのプロジェクトモニタ

を提案する．

リングを目的としたツールであり，より安定したソフト
ウェア開発のために開発状況を随時把握することを支援

3. 変化点検出を用いたソフトウェアメトリクスの時系列データ分析手法

する．EPM は，バージョン管理システム，メーリング
リスト管理システム，障害管理システムのリポジトリに保存された履歴データを収集して利用する．収集したメ

本章では，変化点検出を用いたソフトウェアメトリク

トリクスデータから，ソースコードの規模推移やチェッスの時系列データ分析手法を提案する．提案手法は，大クインとチェックアウトの関連など，グラフィカルにプきく分けて，変化点検出アルゴリズム [10] をソフトウェ

ロジェクトの状況を表現することができる．

アメトリクスに適用するための処理と，検出した変化点

Teamscale[3] は，リアルタイムにソフトウェアの品質の前後でどのような話題が議論されていたかを分析するを管理することを目的として開発されたツールであるためのトピック分析 [2] からなる．

（図 2）．ソフトウェアの品質状況を示す様々な指標を可視化する．バージョン管理システムに開発者が差分

3.1

ソースコードをコミット（登録）した直後に，分析結果をフィードバックすることができる．開発者が普段使う

3.1.1

開発ツール（Eclipse, や Visual Studio など）に組み込

変化点検出
データ収集とメトリクス集計

版管理システム，不具合管理システム，メーリングリ

むことができる．

スト管理システムなどのリポジトリからメトリクスデー

Cisco の Software Quality Dashboard(SWQD)[5] は，顧客に関するメトリクスを取得しモニタリングする（図

28

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

図 2. Teamscale[3] の使用例

図 1. EPM[9] の使用例

図 4. Hackystat[1] の使用例
図 3. SWQD[5] の使用例
タを時系列データとして取得する．リボジトリの種類に

3.1.2

よって，時系列データの整形方法は異なる．

変化点検出

集計したメトリクスの時系列データに対して変化点検

版管理システム：コミットログに従ってリビジョン毎

出アルゴリズム [10] を適用する．変化点検出とは，デーにソースコードからメトリクスを抽出する．さらに，各タマイニングの分野で用いられている異常検知手法のリビジョンのタイムスタンプに従って，データを 1 日単

1 つである．変化点とは，時系列データのモデル（トレンド）の変わり目を指す．一時的なデータの大きな変動（外れ値等）は変化点とはみなさず，あるデータの大き位にまとめて集計する．例えば，1 日に 2 回のコミットがあり，それぞれ異なるファイルにコードを追加している場合は，二つのファイルの追加行数の合計がその日のな変動がある程度継続して続く場合，本質的なデータのソースコード増加行数として集計される．

変動を変化点としてみなす．

不具合管理システム：不具合管理システムに登録され本研究では，ChangeFinder[6] を用いた変化点検出をた不具合票には，報告日時，割当日時，修正完了日時な行う．ChangeFinder とは時系列モデルの 2 段階学習にどの異なるタイムスタンプが記録されているため，取得基づいている．時系列モデルとは，過去の時系列データ

するメトリクス毎にタイムスタンプを区別して集計する．

をもとにして将来の時系列データを予測するために定式

例えば，不具合報告数は，すべての不具合報告の報告日

化されたものである．時系列モデルには様々な種類のモ時を計測し，1 日毎に集計して算出する．

デルが存在しており，自己回帰モデル（Auto Regressive

メーリングリスト管理システム：メーリングリストデー

Model)，移動平均モデル（Moving Average Model），自タからは送信（受信）日時を用いて，メール送信数や送己回帰移動平均モデル（Auto Regressive Moving Aver-

信者数を 1 日毎に集計する．

age Model）などがある．ChangeFinder では，時系列
データに対して自己回帰モデル（AR モデル）を用いて

なお，本稿のケーススタディでは時間の最小単位を 1日としたが，上述のデータをまとめることで 1 週間単位モデル化し，SDAR アルゴリズムを適用し，学習する．

や 1ヶ月単位での時系列データを作成することもできる．

AR モデルは，時系列データの定常性を仮定した下でし

29

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

ධຊ

;ϭͿ

䝕䞊䝍᫬⣔ิ䝰䝕䝹䛾Ꮫ⩦;ϮͿ䝇䝁䜰䝸䞁䜾

;ϯͿ

ᖹ⁥໬

;ϰͿ

䝇䝁䜰᫬⣔ิ䝰䝕䝹䛾Ꮫ⩦;ϱͿ䝇䝁䜰䝸䞁䜾

;ϲͿ

ᖹ⁥໬

;ϳͿ

変化点スコアである．第 1 段階の学習の時点では，外れ値と変化点が両方がスコアとして高い値が出力されるが，式 (4) で平滑化を行うことで，外れ値を除去できる．
そして，第 2 段階の学習によって本質的な変動のみがScore(t)(変化点スコア) の値が高くなる．

3.2

トピック分析

変化点検出によって検出された変化点の前後でどのような議論がなされていたのかを確認できれば，変化点の意味を理解するために役立つと思われる．提案手法では，変化点として観察される事象が発生した要因を特定するための方法としてトピック分析を用いる．

図 5. 時系列モデルの 2 段階学習

3.2.1

トピック分析

提案手法では，後述する LDA に基づくトピック分析
か扱うことができないが，SDAR アルゴリズムを適用すを，メーリングリストや不具合報告のコメントデータにることにより 非定常な時系列データに対応することが適用する．トピック分析を用いることで，それぞれのコできる．SDAR アルゴリズムとは AR モデルの忘却学習

ミュニケーションメディアで行われた議論の要点をトピッ

アルゴリズムのことである．忘却学習とは，過去のデー

ク（話題）の分布として捉えることができる．提案手法

タが現時点からさかのぼればさかのぼるほどモデルの学

では，変化点が検出された前後のトピックを，設定した習に与える影響が減少する学習のことである．SDAR ア

期間（1 日や 1 週間など）毎に集計する．トピックの移ルゴリズムでは忘却パラメータを設定することにより忘り変わりを見ることにより，変化点の前後でプロジェク

却型学習を行っている．この忘却型学習によって，ARトに何が起きていたのか理解することを支援する．

モデルを用いて非定常な時系列データを学習することが
できる．

3.2.2

図 5 に，時系列モデルの 2 段階学習のアルゴリズム

潜在的ディリクレ配分法（LDA）

を示す．式 (1) で時点 t におけるデータ xt を入力とし潜在的ディリクレ配分法は，文書の生成を確率的にモて受ける．式 (2) の Pt−1 (x) は xt−1 = x1 , ..., xt−1 からデル化したトピックモデルである．トピックモデルとは，

SDAR を用いて学習 (第 1 段階の学習) をした確率密度

文書内に潜在しているトピック（話題）を推定するモデ関数を示している．式 (3) の Score(xt ) は対数損失関数

ルである．本手法でのトピック分析において潜在的ディである．つまり，入力されたデータ xt が Pt−1 からどの

リクレ配分法（Latent Dirichlet Allocation）[2] を用い

程度外れているかを表している．式 (4) では，式 (3) でる．ひとつの文書には複数のトピックが存在し，それぞ求めた Score(xt ) の移動平均を求めることで平滑化し，れのトピックがある確率によって文書内に生起するとい

yt とする．平滑化することにより，一時的なデータの変う考えのもと，それぞれのトピックの確率分布を求める

動に対して反応した外れ値を除去する．T は移動平均の手法である．文書に含まれる可能性の高いトピックを抽ウインドウサイズで，与えられた正数である．式 (5) の出することで，文書内に潜在しているトピックを推定でQt−1 は新しく得られた時系列データ {yt : t = 1, 2, ...}

きる．

の確率密度関数で，式 (2) と同様に yt−1= y1 , ..., yt−1

近年では，LDA はリポジトリマイニングの分野で使から SDAR を用いて学習 (第 2 段階の学習) をして得る．

われることが多い [7][8]．主にリポジトリのデータに対す

式 (6) は式 (3) と同様に，yt が Qt−1 からどの程度外れる開発者の理解を手助けする目的などで用いられている．

ているかを表している．式 (7) で得られる Score(t) が

30

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

䠖₯ᅾኚᩘ

䠖ほ

システムから不具合報告に関するメトリクスを抽出ኚᩘ

する．本ケーススタディでは，不具合報告数，不具合解決数，修正待ち不具合数を 1 日毎に抽出した．

2. コードメトリクスの時系列データの整形：コードメ
トリクスデータを時系列データにまとめる．各リビ
ジョンのタイムスタンプに従い，メトリクスデータ

図 6. LDA のグラフィックモデル

を 1 日単位の時系列データに整形する．不具合メト
リクスは，抽出時点で時系列データとなっているた
め，本ステップでは何も行わない．

図 6 に，潜在的ディリクレ配分法のグラフィックモデ
ルを示す．文書毎にトピック分布 θ を持ち，文書上の各3. 時系列データを用いた変化点検出：コードメトリク
スおよび不具合メトリクスの時系列データを入力と単語について，θ によってトピック z が選ばれ，トピッ
ク z の単語分布 ϕ に従って，単語 w が生成される．K

して，変化点検出を行う．ChangeFinder を使う際

はトピック数，D は文書数，Nd は文書 d 上の単語の出に設定するパラメータには，AR モデルの次数，平現回数を表している．また，α は θ が従うディリクレ分

滑化のウィンドウサイズ，忘却パラメータの 3 つが布のパラメータで，β は ϕ が従うディリクレ分布のパラある．本ケーススタディでは，それぞれ 4，7，0.01

メータである．

として変化点検出を行った．

4. ケーススタディ

4. トピック分析：開発者のメーリングリストおよび不具合報告に含まれるのコメント（テキストデータ）

提案手法の有用性を確認するために，本論文ではオーに対して，1 週間毎に LDA を適用する．設定する

プンソースプロジェクトの 1 つである Eclipse Platform

トピック数が多すぎると分析が困難になるため，本プロジェクトを対象としたケーススタディを行う．

ケーススタディでは，トピック数を 10 個に設定する．

4.1

5. 変化点の要因特定：高い変化点スコアが現れた時点

分析対象データの前後 1 週間のトピック分析の結果を抽出し，各分析対象とするデータは，Eclipse Platform プロジェ

トピックに含まれる単語を確認する．変化点前後にクトのソースコード，ソースコードの変更履歴，不具合

おけるプロジェクト内での議論内容を確認できるた

報告，メーリングリストである．対象とする期間は 2003

め，大きな変化点が計測された要因が特定しやすく

年 7 月から 2008 年 7 月までの 5 年間とする．

なる．本ケーススタディでは，変化点スコア 5 以上の変化点の前後 1 週間のトピックを抽出することと4.2

した．変化点スコアを 5 に設定した理由は，5 以上

分析方法の変化点スコア計測されることは本データセットで本ケーススタディにおける分析の手順を説明する．

は稀であったことから，コード行数およびサイクロ
マティック数に大きな変化をもたらすイベントが生

1. メトリクスの抽出：まず，Eclipse Platform プロジェ

じた可能性が高く，それらに関連する議論がなされクトが利用している版管理システムから，ソースている筈と考えたためである．

コードおよびソースコードの変更履歴（コミットロ
グ）をすべて取得する．次に，コミットログに従い，

4.3

分析結果

リビジョン毎にソースコードを取り出す．その後，ソースコード解析ツール Understand を用いてコー

4.3.1

ドメトリクスを抽出する．本ケーススタディでは，

ソースコードメトリクスでの変化点検出結果

コード行数（LOC）およびサイクロマティック数に対

コード行数（LOC）およびサイクロマティック数をして変化点検出を行った結果を次の図 7，図 8 に示す．

リビジョン毎に抽出した．また同様に，不具合管理

横軸は 1 日単位の時系列を表し，左縦軸はそれぞれコー

31

SEA

ソフトウェア・シンポジウム 2015 in 和歌山ϭϲϬϬϬϬϬ

䝁䞊䝗⾜ᩘ;>KͿ

ኚ໬Ⅼ䝇䝁䜰

ϭϰϬϬϬϬϬ

Ϯϱ

ϲϬϬϬϬ

ϮϬ

ϱϬϬϬϬ

ϮϬ

ϭϱ

ϰϬϬϬϬ

ϭϱ

ϭϬ

ϯϬϬϬϬ

ϭϬ

ϱ

ϮϬϬϬϬ

ϱ

Ϭ

ϭϬϬϬϬ

Ϭ

୙ලྜሗ࿌ᩘ

Ϯϱ

ኚ໬Ⅼ䝇䝁䜰

ϭϮϬϬϬϬϬ
ϭϬϬϬϬϬϬ
ϴϬϬϬϬϬ
ϲϬϬϬϬϬ
ϰϬϬϬϬϬ
ϮϬϬϬϬϬ
ϬϮϬϬϯͬϳͬϭͲϱϮϬϬϰͬϳͬϭϮϬϬϱͬϳͬϭϮϬϬϲͬϳͬϭϬϮϬϬϯͬϳͬϭϮϬϬϳͬϳͬϭ

図 7. コード行数に対する変化点検出の結果ϭ͘ϴϱᖹᆒ䝃䜲䜽䝻䝬䝔䜱䝑䜽ᩘ

ኚ໬Ⅼ䝇䝁䜰

ͲϱϮϬϬϰͬϳͬϭϮϬϬϱͬϳͬϭϮϬϬϲͬϳͬϭϮϬϬϳͬϳͬϭ

図 9. 不具合報告数に対する変化点検出の結果

Ϯϱ

ϲϬϬϬϬ

ϮϬ

ϱϬϬϬϬ

ϮϬ

ϭϱ

ϰϬϬϬϬ

ϭϱ

ϭϬ

ϯϬϬϬϬ

ϭϬ

ϱ

ϮϬϬϬϬ

ϱ

Ϭ

ϭϬϬϬϬ

Ϭ

୙ලྜゎỴᩘ

Ϯϱ

ኚ໬Ⅼ䝇䝁䜰

ϭ͘ϴ
ϭ͘ϳϱ
ϭ͘ϳ
ϭ͘ϲϱ
ϭ͘ϲ
ϭ͘ϱϱ
ϭ͘ϱ
ϭ͘ϰϱ
ϭ͘ϰ
ϭ͘ϯϱ
ϮϬϬϯͬϳͬϭͲϱϮϬϬϰͬϳͬϭϮϬϬϱͬϳͬϭϮϬϬϲͬϳͬϭϬϮϬϬϯͬϳͬϭϮϬϬϳͬϳͬϭ

図 8. サイクロマティック数に対する変化点検出のͲϱϮϬϬϰͬϳͬϭϮϬϬϱͬϳͬϭϮϬϬϲͬϳͬϭϮϬϬϳͬϳͬϭ

図 10. 不具合解決数に対する変化点検出の結果

結果
ϰϬϬϬ

ಟṇᚅ䛱୙ලྜᩘ

Ϯϱ

ኚ໬Ⅼ䝇䝁䜰

ϯϱϬϬ

ϮϬ

ϯϬϬϬ
ϭϱ

ϮϱϬϬ

ド行数，サイクロマティック数の平均値を表し，右縦軸

ϮϬϬϬ

は変化点スコアを表している．

ϭϱϬϬ

ϭϬ
ϱ

ϭϬϬϬ

コード行数では，変化点スコアが 5 以上であったもの

Ϭ

ϱϬϬ
Ϭ
ϮϬϬϯͬϳͬϭ

は，2005 年 10 月，2006 年 11 月，2006 年 2 月，2007 年

9 月の計 4 箇所であった．コード行数が急増あるいは急減したことを示している．

ͲϱϮϬϬϰͬϳͬϭϮϬϬϱͬϳͬϭϮϬϬϲͬϳͬϭϮϬϬϳͬϳͬϭ

図 11. 修正待ち不具合数に対する変化点検出の結果

サイクロマティック数では，2005 年 5 月，2006 年 10月，2007 年 9 月，2007 年 11 月の計 4 箇所で 5 以上の変化点スコアが計測されており，サイクロマチック数の5 以上の時点は共通しており，2005 年 5 月，2006 年 4月，2006 年 10 月，2007 年 6 月 2 の計 4 箇所でそれぞ

大きな増加あるいは減少があったことが見て取れる．

れ計測された．共通する 4 時点は，不具合解決数の急増

4.3.2と修正待ち不具合数の急減に対応しており，妥当な結果

不具合メトリクスでの変化点検出結果といえる．

不具合管理システムから抽出したメトリクスである不具合報告数，不具合解決数，修正待ち不具合数に対して

4.3.3

変化点検出を行った結果を図 9，図 10，図 11 に示す．横トピック分析結果

軸は 1 日単位の時系列を表し，左縦軸はそれぞれ累計不設定した期間のメーリングリストと不具合報告のコメ具合報告数，累計不具合解決数，修正待ち不具合数を表

ントに対してトピック分析を行った結果，それぞれ表 1，

し，右縦軸は変化点スコアを表している．

表 2 のように 10 種類のトピックが分類された．各トピッ

不具合報告数に関しては，5 以上の高い変化点スコア

クに含まれる単語からトピック（議論の内容）を推測す

は見ることができなかった．

るために利用できる．

不具合解決数と修正待ち不具合数では変化点スコアが

32

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

表 1. メールのトピック分類
トピック番号

トピックに含まれる単語

M1
M2

table tree swt event public column object viewer item tom selection text string int jface return tableviewer void method
eclipse wrote problem code don application cvs swt java work ve windows time user project make find rcp bug

M3
M4

view menu eclipse ui action org extension editor id add perspective views plugin class actions page point rcp shellbtn
eclipse plugin file project jar build plugins xml plug ant org application wrote java run rcp directory class files

M5
M6
M7

java org eclipse internal core ui main osgi run framework runtime lang swt workbench invoke reflect sun launcher method
backslash nbsp font br face size courier serif sans div wb ah wc ep wd mj ad yt ai
eclipse org http news wrote message www bugs html swt bug platform cgi index browser show id https wiki

M8
M9

editor file class method code wrote null line thread public string eclipse return object text resource plugin run problem
swt shell display composite org eclipse import public text image button widgets void layout griddata label parent settext int

M10backslash eclipse org lib jar java plugins ui usr dll core bundle message swt system subentry missing required home

表 2. 不具合コメントのトピック分類
トピック番号

トピックに含まれる単語

B1
B2
B3

lib eclipse usr jar plugins xp java home dll org system opt rw aab jre gtk rwxp javac bin
eclipse org ui core plugins file jar update platform xml http java plugin jdt id plug osgi version feature
swt shell display line int public string event void import class org eclipse null table os text item return

B4
B5
B6

file project cvs workspace eclipse build files problem error run ant log user set case projects dialog view launeclipse swt problem gtk java version windows linux running build browser time vm run comment work code system osjava eclipse org internal core ui swt run widgets main lang workbench jface runtime method display invoke object reflect

B7
B8

bug duplicate marked fixed fix verified build problem head released bugs patch comment verify issue closing marking rc report
api code comment change don method make case class work content add support point ui implementation part extension typeB9
B10

created details attachment patch test screenshot fix tests file log screen attached updated problem added applied error shot image
view editor text menu dialog window open problem key button selection tab windows perspective ctrl show don click set

5. 考察

2005 年 5 月におけるメールトピックでは，トピック
M2 が増加している．一方，不具合コメントトピックで

本稿では紙面の都合上，サイクロマティック数の推移

は，トピック B7 が増加していることが見て取れる．メー（図 8）に対して大きな増減を捉えた 4 時点の変化点の内ルトピック M2 には， “eclipse”, “wrote”, “problem”,

2 時点（2005 年 5 月と 2007 年 11 月），および，不具合
解決数と修正待ち不具合数の推移（図 10 と図 11）対し“code”, “bug” などの単語が含まれており，不具合に関て大きな増減を捉えた 4 時点の変化点の内 2 時点（2005

ントトピック B7 には， “bug”, “duplicate”, “marked”,

年 5 月と 2007 年 6 月）のみに着目する．それぞれの変化
な変化点の原因となった要因を理解できるかどうか，す“fixed”, “fix” などの単語が含まれており，リリースに向けた活動に関する議論がなされていたものと思われる．
これらのことから，サイクロマティック数の大幅な減少

なわち，提案手法がプロジェクト内に発生した何らかのに対する理由としては，以下のようなことが考えられる．

変化の原因を理解するために有用かどうかを議論する．

2005 年 5 月に大規模なリファクタリングが行われた結する議論が行われていると推察できる．また，不具合コメ

点の前後のトピックの変化を確認することにより，大き果，不具合が増加したと考えられる．そして，不具合が5.1

コードメトリクスに対する変化点検出増加したため，リリースに向けた修正活動が活発になされていたものと推測される．

サイクロマティック数の減少に対して大きな変化点が一方，2007 年 11 月におけるメールトピックは，トピッ

計測された 2005 年 5 月における変化点の前後 1 週間のク M3 が増加している．不具合コメントトピックでは，

メールトピックおよび不具合コメントトピックの確率分

トピック B5 が減少していることが見て取れる．メールト

布を比較した結果を，図 12 および図 13 に示す．同様に，

ピック M3 には，“jar”, “view”, “menu”, “ui”, “action”

サイクロマティック数の増加に対して大きな変化点が計といった単語が含まれており，UI に関する議論が行わ測された 2007 年 11 月における変化点の前後 1 週間のれていると推察できる．また，不具合コメントトピック

メールトピックおよび不具合コメントトピックの確率分

B5 には， “problem”, “version”, “windows”, “linux”,

布を比較した結果を，図 14 および図 15 に示す．

33

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

ϭϬϬй
ϴϬй
ϲϬй
ϰϬй
ϮϬй
Ϭй

ϭϬϬй
ϴϬй
ϲϬй
ϰϬй
ϮϬй
Ϭй
ϮϬϬϱͲϱͲϴ௨๓
Dϭ
DϮ
Dϯ
Dϲ
Dϳ
Dϴ

ϮϬϬϱͲϱͲϴ௨㝆
Dϰ
Dϱ
Dϵ
DϭϬ

ϮϬϬϱͲϱͲϴ௨๓
ϭ
Ϯ
ϯ
ϲ
ϳ
ϴ

ϮϬϬϱͲϱͲϴ௨㝆
ϰ
ϱ
ϵ
ϭϬ

図 12. 2005-5-8 の前後 1 週間のメールトピックの図 13. 2005-5-8 の前後 1 週間の不具合コメントト

確率分布

ピックの確率分布

ϭϬϬй
ϴϬй
ϲϬй
ϰϬй
ϮϬй
Ϭй

ϭϬϬй
ϴϬй
ϲϬй
ϰϬй
ϮϬй
Ϭй
ϮϬϬϳͲϭϭͲϮϴ௨๓
Dϭ
DϮ
Dϯ
Dϲ
Dϳ
Dϴ

ϮϬϬϳͲϭϭͲϮϴ௨㝆
Dϰ
Dϱ
Dϵ
DϭϬ

ϮϬϬϳͲϭϭͲϮϴ௨๓
ϭ
Ϯ
ϯ
ϲ
ϳ
ϴ

ϮϬϬϳͲϭϭͲϮϴ௨㝆
ϰ
ϱ
ϵ
ϭϬ

図 14. 2007-11-28 の前後 1 週間のメールトピック

図 15. 2007-11-28 の前後 1 週間の不具合コメントの確率分布

トピックの確率分布

ϭϬϬй
ϴϬй
ϲϬй
ϰϬй
ϮϬй
Ϭй

ϭϬϬй
ϴϬй
ϲϬй
ϰϬй
ϮϬй
Ϭй
ϮϬϬϱͲϱͲϭϮ௨๓
Dϭ
DϮ
Dϯ
Dϲ
Dϳ
Dϴ

ϮϬϬϱͲϱͲϭϮ௨㝆
Dϰ
Dϱ
Dϵ
DϭϬ

ϮϬϬϱͲϱͲϭϮ௨๓
ϭ
Ϯ
ϯ
ϲ
ϳ
ϴ

ϮϬϬϱͲϱͲϭϮ௨㝆
ϰ
ϱ
ϵ
ϭϬ

図 16. 2005-5-12 の前後 1 週間のメールトピックの図 17. 2005-5-12 の前後 1 週間の不具合コメントト

確率分布

ピックの確率分布

ϭϬϬй
ϴϬй
ϲϬй
ϰϬй
ϮϬй
Ϭй

ϭϬϬй
ϴϬй
ϲϬй
ϰϬй
ϮϬй
Ϭй
ϮϬϬϳͲϲͲϮϱ௨๓
Dϭ
DϮ
Dϯ
Dϲ
Dϳ
Dϴ

ϮϬϬϳͲϲͲϮϱ௨㝆
Dϰ
Dϱ
Dϵ
DϭϬ

ϮϬϬϳͲϲͲϮϱ௨๓
ϭ
Ϯ
ϯ
ϲ
ϳ
ϴ

ϮϬϬϳͲϲͲϮϱ௨㝆
ϰ
ϱ
ϵ
ϭϬ

図 18. 2007-6-25 の前後 1 週間のメールトピックの図 19. 2007-6-25 の前後 1 週間の不具合コメントト

確率分布

ピックの確率分布

34

SEAソフトウェア・シンポジウム 2015 in 和歌山“running” などの単語が含まれており，テスト活動に関する議論がなされていたものと思われる．これらのことから，サイクロマティック数の大幅な増加に対する理とが考えられる．プラグインに関する不具合を解決する
方法が見つかった結果，多数の不具合修正が行われたと推測される．

由としては，以下のようなことが考えられる．2007 年

5.3

11 月に UI に関する大きな修正が必要であったとテスト

本論文の制約活動によって判明した思われる．その結果，サイクロマ
本論文では変化点のスコアが高くなっている要因を特

ティック数が増加したと推測される．

定するために LDA を用いて前後 1 週間のトピック分析

5.2を行った．トピックモデルの LDA を適用して得られた結不具合メトリクスに対する変化点検出

果として，不具合コメントとメールで 10 個づつのトピッ
不具合解決数の増加と修正待ち不具合数の減少に対しクがある．それぞれのトピックの議論の内容をトピックて大きな変化点が計測された 2005 年 5 月における変化に含まれる単語から推測していた．そのため，今後は分点の前後 1 週間のメールトピックおよび不具合コメント

類されたテキスト（メールや不具合コメント）も含めてトピックの確率分布を比較した結果を，図 16 および図

確認し，総合的に議論の内容を推測する必要があると考17 に示す．同様に，不具合解決数の増加と修正待ち不具合数の減少に対して大きな変化点が計測された 2007

えられる．

年 6 月における変化点の前後 1 週間のメールトピックおメータ，AR モデルの次数，平滑化のウィンドウサイズ，

よび不具合コメントトピックの確率分布を比較した結果

忘却パラメータの 3 つがある．AR モデルの次数についてを，図 18 および図 19 に示す．

は参考文献で使われていた４次に設定した [6, pp.57-58]．

2005 年 5 月におけるメールトピックでは，トピック
M3 が減少している．一方，不具合コメントトピックでは，平滑化ウインドウサイズは小さすぎると移動平均の値のトピック B7 が減少していることが見て取れる．メールトるので，平滑化ウィンドウサイズについては１週間つま本論文で用いた変化点検出には事前に設定するパラ

動きが大きすぎるため毎日変化点が検出されることにな

ピック M3 には，“jar”, “view”, “menu”, “ui”, “action”

り７日毎の移動平均を取るために７に設定した．忘却パといった単語が含まれており，UI に関する議論が行われラメータについては，0.01 に設定した．これ以上小さくていると推察できる．また，トピック B7 には， “bug”,

すると変化点を計測することができなくなるため，変化“duplicate”, “marked”, “fixed”, “fix” などの単語が含まれており，リリースに向けた活動に関する議論がされ点検出可能な忘却パラメータのうち最も小さい値を設定した．

ていると思われる．このことから，修正待ち不具合数の6. まとめ

大幅な減少，不具合解決数の大幅な増加に対する理由としては，以下のようなことが考えられる．UI に関する不具合を解決する方法が見つかった結果，多数の不具合

本論文では，プロジェクトにおけるソフトウェア開発

修正が行われたと推測される．

状況の異変を機械的に早い段階で検知することを目的と

一方，2007 年 6 月におけるメールトピックでは，トしたトピック分析を併用した変化点検出手法を提案した．

ピック M4 が減少している．不具合コメントトピックで提案手法は，変化点検出アルゴリズムをソフトウェアメ

は，トピック B7 が減少していることが見て取れる．メー

トリクスの時系列データに適用し変化点を検出する．検ルトピック M4 には “jar”, “build”, “plugins”, “plug”,

出された時点のメールや不具合コメントにトピックモデ“ant” といった単語が含まれており，プラグインに関す

ルの LDA を用いてトピック分析を行うことで，変化点る議論が行われていると推察できる．また，不具合コメが検出された要因を特定する．

ントトピック B7 には， “bug”, “duplicate”, “marked”,

提案手法の有用性を確かめるために，オープンソース“fixed”, “fix” などの単語が含まれており，リリースに向けた活動に関する議論がされていると思われる．このことから，修正待ち不具合数の大幅な減少，不具合解決

プロジェクトの Eclipse Platform プロジェクトを対象と数の大幅な増加に対する理由としては，以下のようなこら取得できるメトリクス（コード行数，サイクロマティッ

するケーススタディを行った．ケーススタディではソー
スコード，不具合管理システムの 2 つのデータソースか

35

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

ク数の平均値，不具合報告数，不具合解決数，修正待ちInternational Conference on Software Engineering(ICSE2014), pp. 592–595, 7 2014.

不具合数）の時系列データを用いて変化点検出を行った．
その結果，不具合報告数の時系列データ以外で高い変化[4] Masao Ohira, Reishi Yokomori, Makoto Sakai,
Ken-ichi Matsumoto, Katsuro Inoue, and Koji

点スコアの持つ変化点を検出することができた．また，
不具合管理システムから取得できる不具合コメントと開Torii. Empirical project monitor: a tool for mining multiple project data. In Proceedings of the

発者メーリングリストから取得できるメールに対してト
ピック分析を行った．そして，変化点が検出された前後

1st International Workshop on Mining Software
Repositories (MSR2004), pp. 42–46, 5 2004.

1 週間の不具合コメントとメールトピックの割合を比較した．

[5] Pete Rotella and Sunita Chulani. Implementing quality metrics and goals at the corporate

ケーススタディを行った結果，ソースコードから取得したメトリクスを使った変化点検出と不具合管理システ

level. In Proceedings of the 8th Working Conference on Mining Software Repositories (MSR2011),
pp. 113–122, 5 2011.

ムから取得したメトリクスを使った変化点検出において変化点を検出することができた．そして，変化点の前後

1 週間のメールトピックと不具合コメントトピックの比
較をすることによって，変化点の前後で，開発者間で議[6] Jun-ichi Takeuchi and Kenji Yamanishi. A uni-論がシフトしている様子を確認することができた．した

fying framework for detecting outliers and change
points from time series. Transactions on Knowledge and Data Engineering (TKDE2006), Vol. 18,がって，管理者が開発活動の状況を把握することに役立つと言える．
今後は複数のプロジェクトに対して同じ分析手法を適

No. 4, pp. 482–492, 4 2006.

用し，より高い一般性のある結果を得る必要がある．変[7] Stephen W. Thomas, Bram Adams, Ahmed E.
Hassan, and Dorothea Blostein. Modeling the evo-

化点検出に用いたメトリクスについてもソースコードと
不具合管理システムから取得したメトリクスだけでなく，

lution of topics in source code histories. In Proceedings of the 8th Working Conference on Mining
Software Repositories (MSR2011), pp. 173–182, 5

別の視点でのメトリクスを対象とすることで，プロジェ
クトにおける開発状況の異変を別の観点から検知できると考えている．

2011.

謝辞[8] Shamima Yeasmin, Chanchal K. Roy, andKevin A. Schneider. Interactive visualization of
bug reports using topic evolution and extractive

本研究の一部は，文部科学省科学研究補助金（基盤(C): 15K00101）による助成を受けた．

summaries. In Proceedings of International Conference on Software Maintenance and Evolution

参考文献(ICSME2014), pp. 421–425, 9 2014.
[9] 大平雅雄, 横森励士, 阪井誠, 岩村聡, 小野英治, 新[1] Hackystat. https://code.google.com/p/hackystat.

海平, 横川智教. ソフトウェア開発プロジェクトの[2] David M. Blei, Andrew Y. Ng, and Michael I. Jor-

リアルタイム管理を目的とした支援システム. 電子

dan. Latent dirichlet allocation. The Journal of
Machine Learning Research (JMLR2003), Vol. 3,
pp. 993–1022, 5 2003.

情報通信学会論文誌 D-I, Vol. J88-D-I, No. 2, pp.

228–239, 2 2005.
[10] 山西健司. データマインニングによる異常検知. 共立出版, 東京, 2005.

[3] Lars Heinemann, Benjamin Hummel, and Daniela
Steidl. Teamscale: Software quality control in[11] 阿萬裕久, 野中誠, 水野修. ソフトウェアメトリク

real-time. In Companion Proceedings of the 36th

スとデータ分析の基礎. コンピュータソフトウェア,

Vol. 28, No. 3, pp. 12–28, 8 2011.

36

SEA