履歴情報を用いたソースコードの変更危険度計測手法の提案
村尾 憲治 ††

松下 誠 †井上 克郎 †大阪大学 大学院情報科学研究科〒 560-8531 大阪府豊中市待兼山町 1-3

近年のソフトウェアの大規模化，複雑化により，ソフトウェアの全体像を把握することは困難になってきている．そのため，ソフトウェアに対して不具合の修正や新機能の追加等の変更を行う際，その変更により新たな不具合が発生することがある．しかし，このような不具合の発生する可能性を事前に知るにはソフトウェアに対する十分な理解が必要であり容易ではない．本稿ではソフトウェアに対して変更を行う際に注意を必要とする箇所を知るため，変更危険度という「変更によって問題が発生する可能性の大きさ」を示すメトリクスを定義し，ソフトウェアのソースコードに対して変更危険度を計測する手法の提案を行う．

Change Risk Measurement Using Revision History
for Source Code
Murao Kenji††Makoto Matsushita†

Katsuro Inoue†

Graduate School of Information Science and Technology, Osaka University
1-3 Machikaneyama-cho, Toyonaka, Osaka 560-8531, JapanAs a software system evolves, it becomes difficult to understand. Therefore, programmers sometimes makechanges which lead to problem. It is very difficult to know the possibility that such problem occurs unless they
understand the software system well enough. In this study, we define the metrics ”change risk” - the possibility
that some problems occur because programmers change the source code - and propose the method of measuringthe ”change risk” in order to know the location we need to be careful when we change the source code.

-1-

1

まえがき

節では評価実験について述べる．最後に 6 節で本オープンソースソフトウェアの開発規模の増大

研究のまとめと今後の課題について述べる．に伴い，その開発形態は多人数化，分散化してい2 オープンソースソフトウェア開発る．大規模なオープンソースソフトウェア開発で

本節では，オープンソースソフトウェアの開発環

は，複数の開発者が互いにソースコードを共有し境，特に版管理システム CVS について述べ，オーながら同時に一つの開発作業に携わることが一般

プンソースソフトウェアの持つ問題点を説明する．

的になりつつある．開発過程で新規の開発者が参2.1 オープンソースソフトウェア開発環境加することも珍しくないが，特にこのような新規オープンソースソフトウェア開発では，各開発の開発者にとってソフトウェアの全体像を把握す者がそれぞれ分散して並列的に開発作業を行うこることは困難になってきている．とが一般的である．一方，開発中のソースコードまた，開発過程で機能の追加，拡張あるいは不やドキュメント等のプロダクトを広く公開するた具合の修正等の必要から，開発者はしばしばソーめ，それらの管理を行う必要がある．そこで，開スコードに何らかの変更を施す．その際，本来変更発者はオープンソースソフトウェア開発環境と呼すべきでない機能を変更したり，変更によって新たばれる環境を用いてプロダクトの管理を行う．

開発者 開発者 開発者な不具合を引き起こしてしまうことがある．ソー
スコードに対してこのような問題を引き起こす変更を行ってしまう可能性を事前に知ることはソフ編集

トウェアに対する十分な理解を必要とする．ソフ

入手

送受信・閲覧

トウェアの全体像の把握が困難な新規開発者にとっCVSて，これは大きな問題となる．
一方，ソフトウェアを効率よく管理する為に，近CVS
リポジトリ

年のオープンソースソフトウェア開発では，版管WWW
rsync / ftp

アーカイブ

電子メール
メーリングリスト
GNATS

理システムを用いることが多くなっている．版管図 1: オープンソースソフトウェア開発環境の例

理システムではソフトウェアに対する変更の履歴が全て個別のアーカイブに保存されている．このアーカイブを閲覧することによって，ソフトウェ

オープンソースソフトウェア開発環境の構成例

アの開発過程についてより深い理解が得られるこを図 1 に示す．オープンソースソフトウェア開発環とが知られている [1]．従って，この版管理システ

境は，一般に複数のシステムから構成される．図 1

ムに蓄積された変更の履歴を解析することで，ソの構成例の場合，ソースコードやドキュメント等フトウェアに対して変更を行う際に注意を必要とのプロダクトは，版管理システム [2] の一つであする箇所の特定が可能であると期待できる．

る Concurrent Versions System(CVS)[3] [4] を用い

本研究では版管理システムを利用し，変更によって管理される．それらのプロダクトは，rsync や ftpて問題が発生する可能性を事前に把握する為の手を利用して，各開発者に複製，配布される．また，法を提案する．具体的には，リポジトリに蓄積され開発者間で相互に行われる意志疎通の手段として，たソフトウェアの開発履歴を解析し，ソースコー電子メールやメーリングリストが用いられる．そドの行毎の「変更危険度」を計測する．変更危険の内容はアーカイブとして保存され，World Wide

度とは「変更によって問題が発生する可能性の大すことにより，ソースコードの変更を行う際，開Web(WWW) を用いて自由に検索や閲覧が可能である．開発者からのバグ報告等フィードバックは，
GNU Problem Report Management System(GNATS)

発者の注意が喚起できると期待される．

を用いたバグデータベースによって管理される．

きさ」を表すメトリクスである．変更危険度を示

以降，2 節ではオープンソースソフトウェア開以下では，これらのシステムの中から，オープ発とその開発環境及び問題点について述べ，3 節

ンソースソフトウェア開発で用いられる版管理シでは本稿で提案する変更危険度の計測手法についステム CVS について説明する．て説明する．4 節では手法の実装について述べ，5-2-

2.2

版管理システム CVS大きな問題となる．

CVS は UNIX 上で動作するシステムとして構築

3 変更危険度の計測手法された版管理システムであり，近年最も良く使わ本節では，本稿で提案する手法について述べる．

れるシステムの１つである．

3.1 用語
本手法における主な用語についての説明を以下に記す．

• 更新履歴情報
更新履歴情報とは，現行のソースコードに至るまでの全ての更新についての情報である．この情報は，版管理システムのリポジトリに蓄積された開発履歴情報から得られる．

図 2: CVS を用いた作業の例• 更新パターン
更新パターンとは現行のソースコードに至るまで「どのような更新を行ってきたか」を示す

CVS では，プロジェクトの開発履歴をリポジトリというデータベースにリビジョンの列として格更新履歴を示す．

納する．このリビジョンとはプロジェクトのある• 変更危険度

時点でのスナップショットを表すものである．図 2

変更危険度とは「変更によって問題が発生すに示すように，開発者はチェックイン，チェックアる可能性の大きさ」を表す．

ウトという作業を行って，リポジトリから特定の本稿で提案する手法では更新パターンを分析リビジョンを取得したり，更新内容をリポジトリし，それぞれの更新パターンについてトランクに反映したりする．また，あるリビジョンからバ上の最新リビジョンにおけるソースコードの各グ修正などの為に新たにリビジョン列を派生させ行に対する変更危険度を計測する．

ることもでき，この派生したリビジョン列はブラ3.2 手法の概要

ンチと呼ばれる．ブランチに対し，元のリビジョ本節では，版管理システムの更新履歴情報からン列をトランクという．

2.3

更新パターン毎の変更危険度を計測する手法につ問題点いて述べる．

オープンソースソフトウェア開発に携わる開発

変更危険度の値が大きい箇所に見られると考え者はソフトウェアの理解に費やす時間が限られてる更新パターンとして，以下の 3 つのパターンをいる．さらにソフトウェアが複雑化するにつれて用いることとした．

理解に必要な情報量は増大するため，新規に参加• 一度変更した内容が後になって戻されているパターン (Undoing pattern，以降更新パターン U)

した開発者であるほど開発の全体像を把握しにくくなる傾向がある．

このパターンが見られるとき，過去に問題のまた，開発過程で機能の追加・変更あるいは不ある変更を行ってしまったと考えられる．その具合の修正等の必要から，開発者はしばしばソーため，将来変更を行った場合，同様の問題を引スコードに何らかの変更を施す．その際，変更にき起こす可能性がある．

よって新たな問題が引き起こされてしまうことが• 変更されている量が多いパターン (large changeある．例えば，仕様で定められた変数の初期値をAmount pattern，以降更新パターン A)
このパターンが見られるとき，重大な不具合変更してしまったり，他の開発者が新しい機能を実装するため頻繁に更新を行っている箇所に別のが発生してしまったか，あるいは大きな機能の意図で変更を行ってしまう等の事態が起こり得る．

追加や修正などのためにソースコードを大きくこのような変更の難しさは箇所によって異なる変更する必要があった可能性がある．一般にこが，それ事前に知ることはソフトウェアに対するのような箇所に対する変更は注意を要すと考え十分な理解を必要とする．ソフトウェアの全体像られる．の把握が困難な新規開発者にとって，このことは-3-• 頻繁に更新されているパターン (high change
Frequency pattern，以降更新パターン F)
このパターンが見られるとき，何らかの機能が開発途中である可能性があり，安易に変更を行うことは危険である．
本手法ではこの 3 つの更新パターンを分析し，変更危険度を計測する．以降では更新パターン U,A, F から計測される変更危険度をそれぞれ CR(U)，CR(A)，CR(F) とする．

図 4: 行（及び行間）の対応関係の例
ビジョン 1.6 の行間 7+〜行間 11+ が対応関係にあると定義する．同様に，図 4 を例にとると，リビジョン 1.5 の行間 8+〜行間 10+ とリビジョン

1.6 の行間 12 + 〜行間 13+，リビジョン 1.5 の行間 16+〜行間 19+ とリビジョン 1.6 の行間 19+ がそれぞれ対応関係にある．

3.4 更新パターンの検出
更新履歴情報から得られた過去の更新過程を追図 3: 提案手法の概要

跡することにより，更新パターン U, A, F の検出を本手法は図 3 に示されるように，3 つの手順に分行う．また，更新パターン U, A についてはそれぞけられる．まず，ソースコードの更新履歴情報をれ値 u,a を検出箇所の各行に記録する．値 u,a は取得し，それを基に過去の更新の過程を導出する．

変更危険度を計測する際に用いる．以下では，そ次に，過去の更新の過程から各更新パターンの検れぞれの更新パターンついて説明する．

出を行う．最後に，更新パターンの検出結果をそれぞれ統合し，変更危険度 CR(U),CR(A),CR(F) を• 更新パターン U
図 5 及び図 6 は更新パターン U の例である．

計測する．なお，CR(U),CR(A),CR(F) はトランク

なお，図 5 及び図 6 のリビジョンは右に行くほ

上の最新リビジョンにおけるソースコードの各行ど新しいものを表している．

に対して計測する．以下では，これら 3 つの手順について説明する．

3.3

更新履歴情報の取得

リポジトリを解析し，分析対象のソースコード

図 5: 更新パターン U の例 1

ファイルに対応した更新履歴情報を取得する．
また，取得した更新履歴情報の差分情報から更新が行われた前後のリビジョン間における行の対応付けとその行の内容を保存する．行の対応付け

図 6: 更新パターン U の例 2

は，行だけでなく行と行間の対応を考える．

図 5 及び図 6 のような更新過程が見られると例えば，図 4 のような更新がなされたとする．i

き，一度変更した内容が後になって戻されてい行目と (i + 1) 行目の行間を i+ と表記すると，リると判断する．図 5 の場合は，対応関係にある

ビジョン 1.5 の行間 7+ に対してリビジョン 1.6 の範囲内で削除または変更されたリビジョン A の8 行目〜11 行目が追加されたことは更新履歴情報

行と同じ内容を持つリビジョン C の行それぞれから知ることができる．しかし，この 2 つが対応に値を u = 1 として記録する．図 6 の場合は，関係にあると定義すると，リビジョン 1.6 の行間

リビジョン C から削除されてできたリビジョン

7+,11+ に対応するリビジョン 1.5 の箇所が存在しため，本手法ではリビジョン 1.5 の行間 7+ とリD の行間に値を u = kj として記録する．j はリビジョン A に対して追加されたリビジョン B の-4-

更新作業
追加削除
変更

更新前
行間
n行
n行

更新後
m行
行間
m行

表 1: 変更量と値 a の記録
総変更量
値 a の記録m
更新後のリビジョンの m 行 それぞれに a = 1n
更新後のリビジョンの行間に a = nn+m
更新後のリビジョンの m 行 それぞれに値 a = n+mm※ n,m は正数
以下では，変更危険度 CR(U), CR(A), CR(F) の行数，k はリビジョン C から削除された行に対応するリビジョン B の行数である．更新パター

計測方法を説明する．基本となる計測方法を図 7 にン U が見られない箇所では u = 0 と記録する．

示す．なお，トランク上の最新リビジョンを i = 0• 更新パターン A
更新パターン A はその存在の有無を明確に決とし，トランク上の過去のリビジョンを新しいもの
から順に 1, 2, 3, 4, · · · とする．変更危険度 CR(U),定できない．従って本手法では，過去の更新過CR(A), CR(F) では，それぞれ図 7 の検出した値 vi

程から全ての変更においてその変更量の多さをが異なるのみで，検出した値 vi の基本的な統合手求め，更新パターン A による変更危険度を計測法は同じである．

する．変更量の定義及び値 a の記録については
表 1 に示す通りである．a の値が記録されない箇所は a = 0 と記録する．

• 更新パターン F
更新パターン F はその存在の有無を明確に決定できない．従って本手法では，過去の更新過

図 7: 基本となる変更危険度の計測方法

程において，ある箇所の更新が行われたかどうかを判定し，更新パターン F による変更危険度計測の具体的な手順を以下に示す．変更危険度を計測する．計測には更新パターン A の検出しを計測する最新リビジョンのある 1 行を target とた値を利用するため，更新パターン F としての表記する．

値は記録しない．

3.5(1) トランク上の各リビジョン i について時間的な重み wi を設定する．最新リビジョンの時間的変更危険度の計測

変更危険度はトランク上の最新リビジョンの各な重み w0 は 1 となる．

行について，CR(U), CR(A), CR(F) が計測される．

(2) target に記録された値 u, a から，更新パター

これらの変更危険度の計測において，本手法では

ン U,A の値をそれぞれ v(U )0 = u，v(A)0 = a,時間的な重みを考慮する．時間的な重みを用いるとする．更新パターン F の値は v(A)0 > 0 ならのは以下のような理由による．

ば v(F )0 = 1，v(A)0 = 0 ならば v(F )0 = 0 と• 最近のリビジョンで更新パターンが検出された場合のほうが最新のソースコードに与えている

する．

(3) トランク上の過去のリビジョンにおいて，target影響が大きいと考える．に対応する範囲を定める．対応する範囲は，各• 過去のリファクタリング等による変更危険度の低下を表現する．

リビジョン間の行と行間の対応を追跡すること

本手法では時間的な重みを以下のように設定し(4) 過去のリビジョン i の対応する範囲 Ri 内の行と行間に記録された更新パターン U,A の値 u,a を∑∑それぞれ合計し，v(U )i =u, v(A)i =aにより求める．

た．更新時間については更新履歴情報から得る．
x

時間的な重み = (1 − d) t

d = 0.2
x = (最新リビジョンの更新時間 [秒])− (対象のリビジョンの更新時間 [秒])t=RiRiとする．また v(A)i > 0 ならば v(F )i = 1，v(A)i = 0 ならば v(F )i = 0 とする．
(5) 各リビジョンの値 v(U )i , v(A)i , v(F )i と時間的

60 × 60 × 24 × 365[秒 ]10な重み wi から，target の変更危険度を以下のように計測する．

-5-CR(U ) =CR(A) =CR(F ) =∑i≥0∑

また，行番号にはリンクが貼られている．リン(v(U )i × wi )ク先の HTML ファイルでは，図 10 のような分析(v(A)i × wi )i≥0∑

対象ファイルの各行に対する変更危険度の詳細情報が記載されている．

(v(F )i × wi )i≥0

このようにして計測された CR(U) は，ある行の内容がそれ以前の内容に戻されたことがある行数に，それぞれの時間的な重みを掛け合わせた値を意味している．また CR(A) は，最新のソースコー
ドの行が現在の内容に至るまでに変更された行数に，それぞれの時間的な重みを掛け合わせた値を意味し，CR(F) は，最新のソースコードの行が現在の内容に至るまでに変更された回数にそれぞれ

図 10: 分析対象ファイルの各行に対する変更危険の時間的な重みを考慮した値を意味している．

度の詳細情報の出力の例

4実装

5 評価実験

本節では，3 節で述べた提案手法を実装したシ

本節では 4 節で述べたシステムを用いて実験をステムについて述べる．

行い，得られた結果について述べ，考察を行う．

本システムは，提案手法に従って変更危険度を5.1 実験目的計測し，HTML 形式で結果の出力を行う．出力例を図 8 に示す．

本実験の目的は，変更危険度計測システムが出力する変更危険度の値を参考にすることにより，変更することによって問題が発生する危険性のある箇所を知ることが可能であるかを調べることである．

5.2 実験対象
実験対象には開発履歴理解支援システム
CREBASS[5] を用いる．本実験では CREBASS のソースコードの内，Java で記述されたものに対してシステムを適用した．

5.3 実験方法

図 8: 分析対象ファイルの各行に対する変更危険度の出力の例

本実験では，データベース作成の機能を実装する

8 つのソースコードファイルについて評価を行う．
各変更危険度はその値を出力するだけでなく，パまず本システムの適用結果から CR(U), CR(A),ターン毎に値の大きさに応じた色を付けている．こCR(F) のいずれかの値が大きい箇所を抽出した．抽の色により，変更危険度の値の大きい箇所が視覚出の際には，コメント部などソースコードの危険的に分かりやすいように配慮されている．彩色の性には関係がないと判断される箇所を除いた．そ基準は図 9 のように，緑から黄を経て赤に至るグの結果，値の大きな箇所は合計で 26 箇所となった．

ラデーションになっている．この基準は 3 種の更次に抽出を行った 26 箇所について，CREBASS新パターン毎に個別に設けられる．

を熟知する開発者 1 人にアンケート調査を行った．
アンケートの内容は以下の通りである．

• 過去にバグが発生したことがあった• アルゴリズムが複雑である• 他のモジュールに影響を及ぼしやすい• 実装方法を何度も変更した

図 9: 変更危険度の彩色基準-6-表 2: アンケートの結果
内訳
箇所数 U A F U,F U,A A,F U,A,F
過去にバグが発生したことがあった
60 1 50000
アルゴリズムが複雑である
00 0 00000
他のモジュールに影響を及ぼしやすい
00 0 00000
実装方法を何度も変更した
120 1 31061
上記以外の問題が過去に存在した
10 0 00010
小計
190 2 81071
該当無し
70 0 70000
合計
260 2 151071
上記以外の問題が過去に存在した…仕様の変更
U…CR(U) の値のみが大きい箇所
A…CR(A) の値のみが大きい箇所
F…CR(F) の値のみが大きい箇所
U,F…CR(U) と CR(F) の 2 つの値のみが大きい箇所
U,A…CR(U) と CR(A) の 2 つの値のみが大きい箇所
A,F…CR(A) と CR(F) の 2 つの値のみが大きい箇所
U,A,F…CR(U),CR(A),CR(F) の 3 つの値全てが大きい箇所• 上記以外の問題が過去に存在した開発者は，このアンケートの項目に当てはまるものがあれば，そのうち最も適切であるものを選えられる．本手法ではそのような珍しい出来事が発生した箇所を CR(U) の値として検出できていることが分かる．

ぶ．アンケートのいずれかの項目に該当する箇所

また，本実験において CR(U) の値が大きい箇

は，変更することによって問題が発生する危険性

所は，実装を何度も変更した箇所であることかがあると判断した．

ら，ソースコードの振る舞いに問題があったの

実験結果ではなく，仕様や設計上の問題により更新を以5.4前の状態に置き換えた箇所であると考えられる．

アンケートの結果を表 2 に示す．

本実験では，CR(U) の値は過去にバグを発生

全 26 箇所の内，19 箇所がアンケートの項目に19該当している．これより適合率はとなり，お26よそ 0.73 となった．

5.5

した箇所の抽出に役立ってはいない．これが偶然の結果なのかどうかは更なる実験によって確認する必要がある．しかし上記の事柄より，CR(U)

考察の値は仕様や設計上の問題による危険性を把握

実験結果を見ると，適合率が 0.73 と比較的高いするのに有用であることが示されている．
• CR(A)

ことが分かる．このことより，本手法が概ね有効であることが示された．

本実験において CR(A) の値が大きい箇所は全

以下では各更新パターンの変更危険度

部で 10 箇所あるが，その内 8 箇所では CR(A)CR(U),CR(A),CR(F) に つ い て ，実 験 結 果 か ら
分かる事柄について記載する．
• CR(U)だけでなく CF(F) の値も大きい．このことから，更新パターン A の見られる箇所では，同時に更新パターン F が見られやすいことが確認できる．

今回の実験では，CR(U) の値のみが大きい箇

本実験において，このような箇所は，いずれも所，または CR(U) と CR(A) の値のみが大きい危険性のある箇所に該当している．

箇所はなかった．すなわち，CR(U) の値のみがまた，CR(A) の値のみが大きい箇所について大きい箇所では必ず CR(F) の値も大きかった．

は，本実験結果を見ると過去にバグが発生してこのことは，更新パターン U が見られる可能いたり，実装方法を何度も変更していることが性が低いことを表している．すなわち，更新を分かる．しかし，全体的に CR(A) の値は CF(F)行った後に更新前の状態に戻すような事態になの値が大きい箇所と一致する傾向が強く，CR(A)ることは珍しく，またそのような事態が発生し単体の特徴を把握するには更なる実験が必要でた箇所は頻繁に更新されている傾向にあると考ある．

-7-

• CR(F)

今後の課題としては，以下のものが挙げられる．

部で 24 箇所と最も多い．また，CR(F) の値のみ

• 構文解析の導入
今回の評価実験においては，変更危険度の高が大きい箇所は 15 箇所であるが，この内 7 箇

い箇所を選択する際，コメント部などのソース所がアンケートのどの項目にも該当しておらず，コードの危険性に関係のない箇所は除いた．プ

しかもアンケートのどの項目にも該当しなかっログラミング言語に応じた構文解析を実行できたのはこの 7 箇所だけである．

るように変更危険度計測システムを拡張すれば，本実験において CR(F) の値が大きい箇所は全

これら 7 箇所について開発者に意見を求めた

コメント部などのソースコードの危険性に関係ところ，これらの箇所は設計やアルゴリズムののない箇所を判別可能になる．これにより，変変更に伴い，最近更新を行った箇所であること更危険度計測の精度向上が期待できる．

が分かった．アンケート調査を行った開発者は，• 新たな更新パターンの考案

実質 1 人で CREBASS の開発を行っているた

今回の評価実験時に得られた開発者の意見かめ，CREBASS の開発過程を十分に理解しておら，本来は変更危険度が大きいと判定されるべり，これらの 7 箇所には危険性がないと判断しき箇所が本手法では完全には抽出できていないた．しかし，最近更新を行った箇所は，開発過ことが分かっている．このような箇所を抽出す程を十分に理解していない新規の開発者にとっるため，新たな更新パターンの考案が望まれる．ても危険性が無いとは言えない．更新が行われ• 多人数で開発されているソフトウェアに対する評価実験
今回の評価実験において実験対象とした CRE-た意図を理解せずにこれらの箇所に変更を加えると，開発を混乱させる可能性は十分にあると考えられる．

BASS は実質 1 人で開発が行われていたため，今後は多人数で開発されているソフトウェアに対以上のことから，CR(F) の値が大きい箇所は全ての開発者にとって変更すると問題が発生すする評価実験も行う必要がある．

る危険性のある箇所を示している訳ではないが，CR(F) から得られる情報は十分に有用であると

参考文献[1] Peter H. Feiler, “Configuration Management Models in Commercial Environments”,言える．
また，アンケート調査を行った際に「データベー

CMU/SEI-91-TR-7 ESD-9-TR-7, March, 1991.

スを実装したソースコードファイルには，今回抽出した 26 箇所以外にも存在する」という意見を[2] Jacky Estublier, “Software Configuration Man-開発者から得ることができた．これより，本手法

agement: A Roadmap”. The Future of Software
Engineering in 22nd ICSE, pp.281–289, 2000.

で抽出できていない箇所が存在することが分かる．
この問題を解決するには，更新パターン U, 更新パ[3] Brian Berliner, “CVS II:Parallelizing Software

ターン A, 更新パターン F 以外に新しい更新パター

Development”, In USENIX Association, editor,
Proceedings of the Winter 1990 USENIX Con-ンを考案する必要がある．

6まとめ
本稿では版管理システムのリポジトリを解析し，更新パターンを分析することで計測する変更危険ference, pages 341–352, Berkeley, CA, USA,1990.
[4] Karl Fogel, “Open Source Development with

度をユーザに提示することにより，更新作業におCVS”, The Coriolis Group, 2000.

いて特に注意を要す箇所を特定し，ソフトウェア開発を支援する手法を提案した．

[5] 中山崇, 松下誠, 井上克郎，“関数の変更履歴

さらに，手法を実装したシステムを用いて評価と呼び出し関係に基づいた開発履歴理解支援実験を行った．本実験において，高い適合率で変更システム”, 電子情報通信学会技術研究報告,に注意を要する箇所を特定することができた．こSS2004-2, Vol.104, No.47, pp.7-12, 2004.

れにより，本手法はユーザのソフトウェア開発において有益な情報を提供できることが確認された．

-8-⌋