スライド 1

ソフトウェア変更作業の
見積りと支援に関する研究
大学院情報科学研究科
コンピュータサイエンス専攻
井上研究室
早瀬 康裕
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
研究の背景
 様々な種類の大量のソフトウェアが蓄積されている
►商用ソフトウェア
►オープンソースソフトウェア
 蓄積されたソフトウェアを変更する機会は多い
変更を効率的に行いたい
ソースコードの一部分を変更する場合を対象
2
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
ソフトウェアの変更の分類
使用しているソフトウェアを
変更
完成ソフト
ウェアを変更
調達した
ソフトウェアを
部品を変更
変更
して導入
不具合を
解決
要求を実現
修正保守
予防保守
完全化保守
適応保守
カスタマイズ
ホワイトボックス
再利用
3
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
ソフトウェア保守
 ソフトウェア保守とは…
納入後,ソフトウェアに対して加えられる,フォールト修正,性能また
は他の性質改善,変更された環境に対するプロダクトの適応のため
の改訂 [36]
 長期間使用されるソフトウェアでは,総所有コストのうち保
守コストが半分以上となることが知られている[44][51]
 保守作業にかかる労力を正確に見積る必要がある
[36] S. Mamone. The ieee standard for software maintenance. SIGSOFT Softw. Eng. Notes,
19(1):75–76, 1994.
[44] S. R. Schach. Software Engineering. Asken Associates, 1990.
[51] S. Yip and T. Lam. A software maintenance survey. In First Asia-Pacific Conference on
Software Engineering, pp. 70–79, 1994.
4
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
ソフトウェア保守の見積り
 関連研究
► Fioravanti ら[14]
 適応保守の見積りに有用なメトリクスを提案し,実際に見積りを行った.
► Sneed [46]
 保守による影響範囲の大きさを様々な要因で補正して,工数を見積る手
法を提案した.
► Jorgensen [26]
 実際の保守作業で様々なメトリクス値を収集し,見積りに有効なメトリクス
と見積り手法を調べた
 変更行数と工数との相関が高いことを明らかにした.
 問題点
► 適用できる保守作業が限られる
► 保守作業の工程の早い段階で利用できない
 保守工程の後半でしか得られない情報を用いるため
5
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
既存ソフトウェアのカスタマイズ
 調達したソフトウェアを変更することで要求を実現
►新規にソフトウェアを開発するより低コスト
 実現した機能を共有したい
→オープンソースソフトウェア開発
版管理システム
変更された
ソフトウェア
様々な目的を持つ
世界中に分散した
開発者
変更された
ソフトウェア
蓄積された
蓄積された
蓄積された
蓄積された
ソフトウェア
ソフトウェア
ソフトウェア
ソフトウェア
変更された
ソフトウェア
6
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
オープンソースソフトウェア開発支援
 リポジトリマイニング
► 版管理システムに蓄積された情報から有用な情報を抽出して開発者に提示
 ソースコードを対象としたマージ機能
► Westfechtel [49]


構文上のマージアルゴリズムを提案
開発者はタグ付けされたソースコードを編集する必要がある
► Binkley ら [8]

手続きを持つ簡単な言語を対象とした,意味的なマージアルゴリズムを提案
► 問題点



版管理システムに組込まれていない
専用のエディタを必要とする
ソースコードのままエディタで編集できない
[49] B.Westfechtel. Structure-oriented merging of revisions of software documents. In Proc. of the
3rd intl. workshop on Softw. configuation management, pp. 68–79.
[8] D. Binkley et al. Program integration for languages with procedure calls. ACM Trans. Softw. Eng.
Methodol., 4(1):3–35, 1995.
7
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
論文の構成
 第1章: まえがき
 第2章: 影響波及解析を利用した保守作業の労力
見積りに用いるメトリクスの提案 [1-3]
 第3章: 構文木の差分を用いた版管理システム向き
マージ機能 [1-1,1-2]
概要のみ
 第4章: むすび
[1-1] Yasuhiro Hayase, Makoto Matsushita, Katsuro Inoue: ”Revision Control System Using Delta
Script of Syntax Tree”, 12th International Workshop on Software Configuration Management (SCM
2005), pp. 133-149, Lisbon, Portugal, September 5-6, 2005 (国際会議)
[1-2] 早瀬康裕, 松下誠, 井上克郎: ”構文木の差分を用いた版管理システム向きマージ機能”, 情報
処理学会論文誌, Vol.48, No.2, pp. 858-867, 2007 年2 月. (学術論文)
[1-3] 早瀬康裕, 松下誠, 楠本真二, 井上克郎, 小林健一, 吉野利明: ”影響波及解析を利用した保守
作業の労力見積りに用いるメトリクスの提案”, 電子情報通信学会論文誌D [採録決定] (学術論文)
8
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
2章 影響波及解析を利用した
保守作業の労力見積りに用いる
メトリクスの提案
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
背景
 ソフトウェア保守作業の労力見積りは困難
►保守作業に適した見積り手法がない
 熟練者の経験に依存
→作業者によって結果が異なる.客観的根拠に欠ける.
 新規開発の見積り手法を流用
→変更するソフトウェアを考慮しない.
►文書が整備されていないことが多い
►保守作業の早い段階で見積りを行いたい
→利用できる情報が少ない
10
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
研究の目的
 保守労力を見積るためのメトリクス「保守ポイント」を
提案
►限られた情報で正確な見積りを行う
必要な情報: ソースコードと,作業により変更されるモジュール
 指針
►ソフトウェア保守作業をモデル化
►モデル上で保守作業量を反映する値を計算
11
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
一般的な保守作業
保守プロセス
プロダクト
システム理解
•変更箇所特定
•テスト範囲特定
変更
変更要求
 入力: プロダクトと変更要求
 保守プロセスは以下の3つのステップから成る
► システム理解

影響範囲 (=変更とテストが必要な範囲) の特定
► 変更
► テスト
テスト
変更された
プロダクト
主要なコスト要因
[13][15][19][38]
理解やテストの労力は,
対象の複雑さに依存す
る[10][30]
 出力: 変更されたプロダクト
12
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
プロダクトのモデル化
 プロダクトを有向グラフとしてモデル化する
► 頂点はプロダクトを構成するモジュール


メソッド,クラス,パッケージなど
複雑さを表す値 eff を持つ
► 有向辺は,モジュール間の影響波及関係
 辺の起点のモジュールを変更したときに,終点のモジュールに何らかの作業が必要に
なる関係
 影響波及の強さを表す重み wを持つ
モジュール1
w = 0.5
eff = 2
モジュール3
eff = 4
モジュール2
w = 0.5
eff = 2
w = 0.7
13
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
プロダクトモデルの詳細
 モジュールの複雑さ eff
►そのモジュールだけを変更するときの作業量を反映する値
►本研究の実験では,McCabe の循環的複雑度と
LOC(行数)を用いた
 影響波及の強さ w
►0 から 1 までの値 (1に近いほど影響波及が強いことを表
す)
►本研究の実験では定数を用いた
14
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
保守ポイント
影響範囲内の複雑さを表現するメトリクス
 保守作業の労力は,主に変更されるモジュールとそ
の影響範囲に依存
 プロダクトモデル上で影響範囲の複雑さを計算
15
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
保守ポイントの計算方法
 保守ポイントの計算式
►Gp : プロダクトモデルのグラフ
►R : 保守作業によって変更されるモジュールの集合
►eff(m) : モジュール m の複雑さ
►imp(R, m) : R によってモジュール m が受ける影響の強
さ (0以上1以下) (次ページ以降で説明)
16
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
影響の強さ imp(R, m) (1/2)
 経路 p = (s1, s2, s3, … , si) の重み
v(p) = Πw(sj)
 モジュールm1が変更されたときにm2が受ける影響の
強さ
1 (m1  m2のとき)

impm (m1 , m2 )  0 (m1からm2 への経路が存在しない とき)
max({v( p) | p  {m からm への全ての経路 }})
1
2

モジュール1
w = 0.5
eff = 2
モジュール3
eff = 4
モジュール2
w = 0.5
eff = 2
w = 0.7
0.5×0.7=0.35
17
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
影響の強さ imp(R, m) (2/2)
 変更要求 R からモジュール m への影響の強さ
多くのモジュールから影響を受けるほど,理解およびテスト
しなければならない割合が増える
18
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
保守ポイントの計算例
 下のプロダクトモデルで,
R={モジュール1, モジュール2}
であるときの保守ポイントの値
eff(モジュール1) + eff(モジュール2)
+ (1-(1-0.5)×(1-0.7))×eff(モジュール3)
= 2 + 2 + 0.85×4
= 7.4
w = 0.5
モジュール1
モジュール3
eff = 2
eff = 4
モジュール2
w = 0.5
eff = 2
w = 0.7
19
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
評価実験
 目的
► 保守ポイントの値と労力との関係を調査
 実験設定
► 被験者: 情報科学研究科の大学院生 6 人
► 作業対象: 酒屋問題 [50] のJavaによる実装
 8 クラス, 25 メソッド, 309 行
► 作業内容
 欠陥修正 2 件,機能追加 3 件
► 各被験者が5件の作業を終えるまでの時間
 1時間43分 ~ 5時間2分
→個々の作業に費やした時間の割合を労力の値とする
[50] 山崎. 共通問題によるプログラム設計技法解説. 情報処理, 25(9):934–935, 1984.
20
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
評価1: 相関の調査
 相関係数を計算
► 労力
► メトリクス (保守ポイント,単純和(変更されたメソッドの複雑度の和),変更行
数)
 保守ポイントの計算方法
► 頂点: メソッド
► 辺の重み: 定数 0.3
► 頂点の複雑さ: McCabe の循環的複雑度と LOC
保守ポイント 単純和
[McCabe] [McCabe]
労力との
0.82
0.73
相関係数 (<0.01)
(<0.01)
符号付 二乗誤差: 101 (<0.01)
順位和検定
MRE: 105 (<0.01)
保守ポイント
[LOC]
単純和
[LOC]
0.77
0.65
(<0.01)
(<0.01)
二乗誤差: 95 (<0.01)
MRE: 86 (<0.01)
変更
行数
0.87
(<0.01)
→保守ポイントは単純和より労力との相関が高い
21
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
評価2: クロスバリデーション
 見積り精度を擬似的に評価
► 30件のデータをランダムに3群に分割
► 2群を線型回帰分析の学習に,残りの1群を見積りに使用
► 学習・見積りに用いる群を入れ替えて,全ての組み合わせで実行
 評価基準
► MAE: 絶対誤差の平均
► MMRE: 相対誤差の絶対値の平均
小さいほど良い
► PRED(25): 相対誤差が 25% 以下である割合
► PRED(50): 相対誤差が 50% 以下である割合
保守ポイント 単純和 保守ポイント
[McCabe] [McCabe] [LOC]
MAE
0.07840 0.09270
0.09405
MMRE
0.9616
1.427
1.263
PRED(25)
0.3667 0.3000
0.3333
PRED(50)
0.6667 0.6000
0.6000
大きいほど良い
単純和
[LOC] 変更行数
0.1177 0.07868
1.766 0.8266
0.1667 0.3667
0.5000 0.6000
22
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
2章のまとめ
保守作業の労力見積りのためのメトリクスを提案
 保守対象のソフトウェアプロダクトをモデル化
 モデル上での影響範囲内の複雑さから計算
メトリクスと労力との相関を評価
►他のメトリクスよりも労力と高い相関を持つ
23
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3章 構文木の差分を用いた
版管理システム向きマージ機能
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
版管理システム
 機能
►ソースコードやドキュメントなどの開発履歴を保存
►複数人による同時開発をサポート
 ほとんどのオープンソースソフトウェア開発で使われて
いる
例: CVS, subversion
25
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
版管理システムを用いた複数人での開発
X3
X2
取得
X
X1
X
リポジトリ
格納
編集
X1
取
得
開発者A
最新版
格納
このまま格納すると
(X1)の取得
開発者Aの変更が失われる
開発者B
X
X2
編
集
版管理システム
によるマージ
X3
26
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
問題
 既存の版管理システムは,マージを行単位で行っ
ていた
 行単位のマージは,不正確な場合がある
1. 同じ行が変更されていると,衝突しなくて良い変更が衝
突する
2. 衝突すべき変更が,行が違うことにより見逃される
システムがマージに失敗したときは,開発者が手で
直さねばならず,負担となっている
27
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
ソースコードの構造を考慮したマージ
 木構造の差分計算とマージを行う
1. ソースコードを解析し,構文木に基いた木構造のデータを作成す
る
2. 2つの木の差分を編集操作の列(編集スクリプト)として計算する
3. 編集スクリプトを適用対象の木に適用する.
差分の計算元
差分の計算先
編集
スクリプト
ソース
コード
ソース
コード
適用対象
ソース
コード
ソース
コード
マージ結果
28
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
評価実験
 提案手法が有効に働くかを検証した
►サンプルコードに対する適用
 典型的な同時変更を作成して動作を確認
►実際の開発履歴に対する擬似的な適用
 オープンソースソフトウェアのリポジトリから,マージが行なわれたと
考えられる事例を取得
 行単位のマージと提案手法とで比較
29
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
実際の開発履歴に対する擬似的な適用
 実際のリポジトリからマージが行なわれたと考えられる事例を
取得
► 対象リポジトリ
 Eclipse プロジェクト(22606 ファイル,162683リビジョン)
 Jakarta プロジェクト(19420 ファイル, 103358 リビジョン)
► 84件のマージ事例を取得
 提案手法と行単位の手法とを比較
► 提案手法では,出力に正しいマージ結果が含まれれば成功とみな
した
 結果
行単位のマージ 件数 提案手法 件数
成功
71 成功
71
失敗
成功
13
失敗
9
4
30
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
行単位のマージが失敗した場合の詳細
行単位のマージが失敗した原因 件数 提案手法 件数
同じ行への空白文字の追加削除
4 成功
4
意味的な変更と整形
改行コードの変更
重なりあった編集
後の変更が最初の変更を上書き
意味的な衝突
編集に失敗したファイルの格納
1 成功
1 成功
2 成功
成功
2
失敗
2 失敗
1 失敗
1
1
2
1
1
2
1
→提案手法は 1 件を除いて正しい結果を出力できた
31
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
むすび
 既存のソフトウェアに対する変更を効率的に行う方
法を提案
►保守労力の見積りメトリクス「保守ポイント」
 保守作業の早い段階で得られる情報から計算可能
 労力と高い相関を持つことを確認
►同時に更新されたソースコードを木構造によってマージす
る手法
 実際のソフトウェア開発のデータでも有効に動作することを確認
32
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
33
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University