ソフトウェア品質の第三者評価のための基盤技術－ソフトウェア … · Redmine Trac MS Project (30 « Product DB CVS SVN git « er （半自動） r （ス

Copyright © 2014 Nara Institute of Science and Technology

ソフトウェア品質の第三者評価のための基盤技術－ソフトウェアプロジェクトトモグラフィの開発－

奈良先端科学技術大学院大学情報科学研究科

ソフトウェア工学研究室

松本健一


2

自己紹介

奈良先端科学技術大学院大学情報科学研究科，ソフトウェア工学研究室教授 HP: http://se-naist.jp/

研究分野：ソフトウェア工学ソフトウェア解析，ソフトウェアメトリクス

ソフトウェア開発の定量的管理

ソフトウェア計測環境

最近の主な共同研究先，学生交流先大阪大，九州大，和歌山大，近畿大，奈良高専，…タイ・カセサート大，フィンランド・オウル大，米国・ハワイ大，カナダ・クィーンズ大，中国・香港城市大，…

日立製作所，ＮＴＴ西日本，東芝，経済調査会，ＪＡＸＡ，…


3


共同研究先との最近の主な共著論文

MSR: Ahmed Hassan, Bram Adams, Emad Shihab E. Shihab, A. Ihara, Y. Kamei, W. M. Ibrahim, M. Ohira, B. Adams,

A. E. Hassan, and K. Matsumoto, “Studying Re-Opened Bugs in

Open Source Software,” Empirical Software Engineering, vol.18,

no. 5, pp.1005-1042, Oct. 2012.

GQM paradigm: Victor R. Basili (U. of Maryland) A. Monden, T. Matsumura, M. Barker, K. Torii, and V.R. Basili,

“Customizing GQM Models for Software Project Monitoring,”

IEICE Trans. Information & Systems, vol.E95-D, no.9, pp.2169-

2182, Sep. 2012.

Cost Estimation: Jacky Keung (City U. Hong Kong) P. Phannachitta, J. Keung, A. Monden, K. Matsumoto, “Improving

Analogy-based Software Cost Estimation through Probabilistic-

based Similarity Measures,” Proc. of APSEC2013 (to appear).


4


主な実験設備

Software Data StorageRAID6 HDD 25TB，Cache SSD 1TB

2.53GHz x 64 cores

Main Memory 4GB/core

vSphere Advanced

Virtual Platform

Intensive Data Analysis ServerXeon X7550(8 cores, 2GHz) ｘ 4

Main Memory 256GB, SSD 480GB

Software

- PG Relief C/C++ 2011

- PG Relief J2011

- QAC++ 2.5.1J

- QAC 7.2.3J

- Klocwork Insight

- RSM windows

- Understand 2.5

Data & Analysis Result DisplayFull HD 60inch x 6

Wearable

Near Infra-red Spectroscopy (NIRS)


5

背景ソフトウェア開発における「情報の非対称性」

ソフトウェア品質そのものや品質に大きな影響を与える開発過程の情報の多くはベンダのみが知り得る．（ユーザとベンダで，知り得る情報量に大きな差がある．）

引き起こされる問題逆選択：ユーザは低品質なソフトウェアしか選べなくなる．

モラル・ハザード：ベンダは手抜きや虚偽報告をしがちになる．

対策シグナリング：ベンダがユーザに積極的に情報を発信する．

スクリーニング：ベンダの自発的行動を読み取って選別する．

制度と組織：認証制度や監視制度を整備する．

「情報の非対称性」については【IT経済基礎講座】篠崎彰彦教授のインフォメーション･エコノミー，ソフトバンクビジネス＋IT http://www.sbbit.jp/article/cont1/18480 を参考にしました．


6

技術開発の目的

ソフトウェア品質の第三者評価のための技術基盤をソフトウェアユーザ・ベンダに提供する．（ソフトウェア開発における「情報の非対称性」を解決するための「シグナリング」技術基盤をベンダに提供する．）

ソフトウェア開発データを第三者評価に適した形態に再構成するための枠組みの構築．

再構成されたデータを解析する「技術・ツール」の開発

技術・ツールの利用方法を明示する「シナリオ」の提供


7

ソフトウェア開発データの再構成がなぜ必要か．

今日，多くのソフトウェア開発プロジェクトでは，開発管理システム（構成管理システム，工程管理システム，不具合管理システム，…）が導入されており，それらシステムには，開発状況を表す定量データ（開発データ）が蓄積されている．


8

ソフトウェア開発データの再構成がなぜ必要か．

しかし，開発データを解析しようとすると，データの取得と整形に多くの工数を要する．解析工数の95%は，プロジェクトデータの取得と整形に費やされる．

2010年に米国で発生したトヨタ車の急加速問題では，ソフトウェアとその開発過程の検証に１０ヶ月を要した．

A. Mockus, “How to run empirical studies using project

repositories”, Proc. of 4th International Advanced School of

Empirical Software Engineering (IASESE 2006), Sep. 2006.


9

データの取得・整形に多くの工数がなぜ必要か．

開発データは，（第三者による）ソフトウェアとその開発過程の評価のために蓄積されているわけではない．

開発管理システムでは，コスト超過，スケジュール遅延，品質低下といった，開発リスクを検知し，対処するため開発データが用いられる．

開発リスクが解決・回避されれば，開発データは不要となる．

ソフトウェアとその開発過程の評価の目的は，開発リスクの原因究明と再発防止である．

原因究明と再発防止には，要素技術として

プロジェクト全体の俯瞰

プロジェクト構成要素（間）の傾向や関係性の顕在化・評価

仮説の生成・検証

が不可欠で，データの一貫性，完全性，信頼性等の確認も必要となる．


10

「ソフトウェア品質の第三者評価」のスコープ

プロセス実施の妥当性（開発）プロセスは規定通りに実施されているか．

プロセスを構成するタスクやアクティビティは確実に実施されているか．

採用規格・技術の妥当性（開発に際して）採用した規格や技術は適切か．

採用した技術は適切に利用されているか．

従事者の妥当性（開発）従事者のスキルや適性は適切か．

利用者・利用状況との妥当性利用者や利用状況の情報は適切に収集・利用されているか．

利用者に対してそれら情報は適切に提供されているか．

情報処理推進機構，“ソフトウェアの品質説明力強化のための制度フレームワークに関する提案（中間報告）”，平成23年9月．【一部加筆修正】


11

ソフトウェアプロジェクトトモグラフィ技術Software Project Tomography (SPT)

医療におけるコンピュータ断層撮影CTを，ソフトウェア品質の第三者評価に適したデータ構造を考える上でのモデルとする．

ソフトウェア開発プロジェクトをからだに見立て，プロジェクト開始から終了（あるいは，現時点）までのいくつかの時点において，プロジェクトの状況を定量的に表すスナップショットを断面画像のように作成する．

断面画像の系列から身体の3次元モデルを再構成するように，スナップショットの系列によって，プロジェクトの全体像，および，ソフトウェアやその品質が実現される過程（プロセス）を表す．


12

ソフトウェアプロジェクトトモグラフィ技術

ソフトウェア開発プロジェクトを「スナップショットの系列」で表現する．スナップショット＝ソフトウェア開発データ

＋解析結果＋ソフトウェアプロダクト断片

開発データ（リポジトリ）

ソフトウェアプロジェクト

要件作業組織プロダクト課題

構成管理システム工程管理システム不具合管理システム

構成管理データ工程管理データ不具合管理データ

・・・

・・・

スナップショットの系列

プロジェクトの実体

マネージド・データとして表現されたプロジェクト

スナップショットの集合体として表現されたプロジェクト

時間の進行


13

開発データ（リポジトリ）

ソフトウェアプロジェクト

要件作業組織プロダクト課題

構成管理システム工程管理システム不具合管理システム

構成管理データ工程管理データ不具合管理データ

・・・

・・・

スナップショットの系列

プロジェクトの実体

マネージド・データとして表現されたプロジェクト

スナップショットの集合体として表現されたプロジェクト

時間の進行

スナップショットプロトタイプ


14

３つの基本機能

スナップショット生成解析

Project DB

•Redmine

•Trac

•MS Project

•EPM,…

Product DB

•CVS

•SVN

•git …

Ma

pp

er

（半自動）

Re

triev

er

（スクリプト）

プロジェクト構造モデル

要件

作業

組織

プロダクト

課題

プロダクト断片

要件項目

ソースコード

不具合票

作業記録

プロジェクト定義書

テストデータ

・・・

・・・

一次解析結果

一次解析ツールライブラリ

スナップショット

クラウド型開発管理環境

総合解析ツールライブラリ

可視化

可視化統合プラットフォーム（リプレイヤ拡張）

可視化ツールライブラリ

（スタンドアロン）

要素モデル

ビューコレクション

推移

分布

特長抽出

相関解析

・・・

要素モデル

要素モデル

・・・

スナップショット生成スナップショット解析

スナップショット可視化


15

ペイン

要素技術要件作業組織プロダクト課題

全体の俯瞰

傾向・関係性の顕在化・評価


ケーススタディ

階層的可視化分析ツールHCEを用いた仮説生成

非機能要件

キーワード自己組織化マップ

特性レーダーチャート

低品質モジュール予測

ソースコード修正Treemap

開発行動記録システムTaskpit

作業時間サマリー

作業時間フィードバック

ソースコードメトリクスTreemap

UCIソースコード

データセットに基づく基準値

コミュニケーション分析に基づく

組織構造グラフ

中心性メトリクス


16

スナップショットに基づく「全体の俯瞰」

ある時点の俯瞰 RFP上の非機能要件

ある期間を対象とした俯瞰ソースコード修正

プロジェクトを通しての俯瞰コミュニケーション分析に基づく組織構造グラフ


17

ケーススタディ：ある時点における俯瞰例

RFP上の非機能要件

非機能要件にマッピングされたキーワード間の類似性を自己組織化マップにより示す．

テキストマイニングのためのフリーソフトKH Coderを使用


18

ケーススタディ：ある期間を対象とした俯瞰例

ソースコード修正

ある期間内に行われたソースコード修正作業量をTreemap

により示す． Step 1：ソースコードをコンポーネントごとに

色分け表示．面積は，修正作業量に比例．

Step 2：あるコンポーネントを担当者ごとに色分け表示．面積は，修正作業量に比例．明度は，担当作業量に比例．（担当チケット数で算出．暗いほど「いそがしい」）

Ben Fryが公開しているTreemapライブラリを使用


19

ケーススタディ：プロジェクトを通しての俯瞰例

コミュニケーション分析に基づく組織構造グラフ

Apacheプロジェクト, １ヶ月毎


20

ケーススタディと第三者評価との関係

評価対象

要素技術

第三者評価に求められるスコープ*品質

プロセス実施採用規格・技術従事者

傾向・関係性の顕在化・評価

内的妥当性Internal

Validity

外的妥当性External

Validity


非機能要件特性レーダーチャート

コミュニケーション中心性メトリクス

ソースコードメトリクス基準値作成


Taskpit

作業時間フィードバック

* 情報処理推進機構，“ソフトウェアの品質説明力強化のための制度フレームワークに関する提案（中間報告）”，平成23年9月．【一部加筆修正】

階層的可視化分析ツールHCE

を用いた仮説生成


21

内的妥当性コミュニケーション中心性メトリクス

Taskpit作業時間フィードバック


外的妥当性ソースコードメトリクス基準値作成


スナップショットに基づく「傾向・関係性の顕在化・評価」

メトリクス計測

199909 200206 200503

0.0

0.1

0.2

199910 200104 200210

0.0

00

.15

0.3

0

200111 200309 200507

0.0

00

.10

0.1

50. 05

199909 200206 200503

0.0

0.2

0.4

199910 200104 200210

0.4

0.6

200111 200309 200507

0.0

0.2

0.4

0.1

0.3

0.0

0.2

次数中心性

200111 200309 200507

0.0

0

199910 200104 200210

0.0

00

.15

0.3

0

199909 200206 200503

0.0

00

.06

0.1

2

0.0

50.1

50

.10

媒介中心性

近接中心性

：開発者：ユーザ：コーディネータ

(A-3)

(A-4)

(A-5)

(G-3)

(G-4)

(G-5)

(N-3)

(N-4)

(N-5)

Eclipse platform ver.3.1 開発プロジェクト

予測に基づくスナップショット（低品質モジュール群）

終了時9/6/3ヶ月前予測モデル

終了時9/6/3ヶ月前


予測モデル構築


22

199909 200206 200503

0.0

0.1

0.2

199910 200104 200210

0.0

00

.15

0.3

0

200111 200309 200507

0.0

00

.10

0.1

50

. 0

5

199909 200206 200503

0.0

0.2

0.4

199910 200104 200210

0.4

0.6

200111 200309 200507

0.0

0.2

0.4

0.1

0.3

0.0

0.2

次数中心性

200111 200309 200507

0.0

0

199910 200104 200210

0.0

00

.15

0.3

0

199909 200206 200503

0.0

00

.06

0.1

2

0.0

50

.15

0.1

0

媒介中心性

近接中心性

：開発者：ユーザ：コーディネータ

(A-3)

(A-4)

(A-5)

(G-3)

(G-4)

(G-5)

(N-3)

(N-4)

(N-5)

ケーススタディ：傾向・関係性の顕在化・評価

コミュニケーション中心性メトリクス

組織構造グラフによる俯瞰だけでは「プロジェクト理解」は難しいので，２つの中心性メトリクスで評価する．


次数中心性組織内コミュニケーションの活発さを表す．

媒介中心性メンバーが扱う情報・リソース量を表す．

開発者

ユーザ

コーディネータ

コーディネータ

ユーザ開発者

組織内でのコミュニケーションが活発になると，コーディネータの負担がそれに比例して増大する傾向にあることが分かる．（開発者の負担はそれほど増えない．）

組織内でのコミュニケーションが活発になると，コーディネータの負担がそれに比例して増大する傾向にあることが分かる．（開発者の負担はそれほど増えない．）


23



2004/08から1年間のデータでランダムフォレスト法で予測モデルを構築

2005/08から1年間のデータに対して，開発終了の９ヶ月，６ヶ月，３ヶ月前の時点で予測

学習用（モデル構築用）プロジェクト（1年間）予測対象（モデル適用）プロジェクト（1年間）


予測に基づくスナップショット（低品質モジュール群）

終了時9/6/3ヶ月前予測モデル

終了時9/6/3ヶ月前


予測モデル構築

0.645 0.652 0.664 0.680

0.871 0.863 0.885 0.899

0.741 0.743 0.759 0.774

0.000

0.100

0.200

0.300

0.400

0.500

0.600

0.700

0.800

0.900

1.000

9か月前 6ケ月前 3か月前従来

(開発終了時)

Precision

Recall

F-measure

F値

9ヶ月前 6ヶ月前 3ヶ月前開発終了時


24

内的妥当性コミュニケーション中心性メトリクス

Taskpit作業時間フィードバック


外的妥当性ソースコードメトリクス基準値作成


スナップショットに基づく「傾向・関係性の顕在化・評価」

UCI ソースコードデータセット

計測値

基準値


基準値作成

比較Treemap化

基準値作成

基準値

評価対象ソフトウェア開発プロジェクトRFP（非機能要件）で高評価が得られたプロジェクト

0

0.5

1

1.5

2

2.5

3

3.5

4運用テスト

運用開始条件の明確化

運用容易性

稼働率目標

稼働品質性能

異常検知条件

セキュリティ対策

異常中断時の処理機能

冗長化障害予防

災害対策

問題点把握及び修正分析

保守容易性

サービス提供時間

ライセンス保守

障害対応

導入教育

基準値プロジェクトD


25



UCIソースコードデータセット：利用プロジェクト数 12,191

コードクローン以外の計測では，LOCが1,000未満のプロジェクトを除外したので，利用プロジェクト数は10,087

計測メトリクス数４５

基準値例上限値：第三四分位＋1.5×（第三四分位－第一四分位）下限値：第一四分位＋1.5×（第三四分位－第一四分位）

UCI

ソースコードデータセット

計測値

基準値


基準値作成

比較Treemap化

基準値作成用プロジェクト評価対象プロジェクトＯＳＳ５プロジェクト


26



評価対象プロジェクト JHotDraw （１６バージョン）サイクロマティック複雑度の最大値がVersion 7.0.9で上限値を超過．

同値が急上昇したファイルをTreemap

で確認．

Ver.7.08 Ver.7.09


27



RFP

大項目中項目非機能要件重み

運用開始準備

運用テスト運用移行許容障害発生率 6.0

運用開始条件の明確化テスト密度 2.6

テストカバレッジ 2.2

システム運用評価

運用容易性介入オペレーションの最小化 1.9

介入オペレーションの容易性 1.9

稼働率目標平均稼働率 5.3

オンラインシステム稼働率 1.0

稼働品質性能バッチ処理正常終了率 6.2

応答時間 3.7

応答時間（最悪時の応答時間比率） 1.3

スループット 3.6

最大負荷スループット 1.1

最大停止時間 1.3

業務停止回数／年 1.0

既定時間外停止回数 1.0

ターンアラウンド時間 2.6

通常時余裕率 1.0

ピーク時余裕率 1.0

非機能要件評価シート（抜粋）

0

0.5

1

1.5

2

2.5

0.5

1

1.5

2

2.5

3

3.5

大項目レーダーチャート

中項目レーダーチャート

総合評価点

X点


28



非機能要件評価シートの作成ベースとした３つのガイドライン

開発段階

JUAS「非機能要求仕様定義ガイドライン」

保守・運用・サービスレベルアグリーメント

IPA「情報システム調達のための技術参照モデル（TRM）」

日経ソリューションビジネス編「システム構築のトラブルを回避するためのITシステム契約締結の手順とポイント」

ユーザにとって重要な非機能要件の抽出

IPA「プロダクト品質メトリクスＷＧ実施内容 ―ソフトウェアメトリクス高度化プロジェクト」

非機能要件の構造化

IPA-SEC 「共通フレーム2007」

JUAS 「ソフトウェア開発管理基準に関する調査報告書」


29



ケーススタディ対象プロジェクト

大学，病院，官公庁，地方自治体，独立行政法人など．ベンダ候補企業向けの入札情報としてWWW上で公開している29件．

特性評価者

システム発注・開発に10年以上携わってきたエキスパート１名．

基準値作成

基準値

評価対象ソフトウェア開発プロジェクトRFP（非機能要件）で高評価が得られたプロジェクト

0

0.5

1

1.5

2

2.5

3

3.5

4運用テスト


運用容易性

稼働率目標

稼働品質性能

異常検知条件




災害対策


保守容易性



障害対応

導入教育



30



総合評価が60点以上（100点満点）となったのは2プロジェクトのみ．

総合評価トップ３の各特性の平均評価点を基準値として，レーダチャートを作成．改善が必要な特性がより明確に．

0

0.5

1

1.5

2

2.5

3

3.5

4運用テスト


運用容易性

稼働率目標

稼働品質性能

異常検知条件




災害対策


保守容易性



障害対応

導入教育


10

20

30

40

50

60

自治体基幹情報システム

政府機関情報システム

大学情報システム

病院情報システム

図書情報システム

0


31


スナップショットに基づく「仮説の生成・検証」

課題（不具合）データ約7,000件

11項目

比較HCE

知識あり・なし被験者による仮説生成

仮説

学術論文

法則関係性

Eclipse Platform開発プロジェクト


32

ケーススタディ：仮説の生成・検証


HCE: Hierarchical Clustering Explorer

可視化方式：Ranked-by-feature framework

ヒストグラム

階層的クラスタリング

散布図


33



仮説生成実験対象データ（HCEへの入力データ）

Eclipse Platformの不具合報告データ：約7000件，11項目（変数）

方法

OSS開発についての知識を持つ被験者と，持たない被験者の2グループが生成した仮説の量と質を比較．

主要学術論文誌・国際会議で既出の法則・関係性に合致する仮説を有用とする．

被験者持ち時間：1時間

被験者

知識あり：学生3名，知識なし：学生3名

項目（変数）詳細

AssignTime 修正者が決定するまでの時間

Fixtime 修正されるまでの時間

Priority 優先度

Severity 重要度

CCCount メーリングリストの登録者数

Comment コメントの総文字数

Attachcount 添付ファイルの数

Descriptionword 記述情報の文字数

reporter 報告者の名前

fixer 修正者の名前

component 不具合が発生したコンポーネント名


34



生成された仮説数知識なし被験者：計8件．うち，有用な仮説 2件．

知識あり被験者：計18件．うち，有用な仮説 4件．

生成された仮説例

「課題が報告されてから担当者に割り当てられるまでの時間」と「課題が割り当てられてから解決されるまでの時間」は反比例する．

（課題対応プロセスの実施・適用技術の妥当性評価につながる）

対象ソフトウェアの知識が十分でない場合でも，有用な仮説を生成することが可能．


35

まとめ：ソフトウェアプロジェクトトモグラフィ技術

ソフトウェア品質の第三者評価のための技術基盤

（「情報の非対称性」を解決するための「シグナリング」技術）

ソフトウェア開発データを第三者評価に適した形態に再構成するための枠組みの構築

スナップショット：プロジェクトの状況を定量的に表す断面画像

ソフトウェア開発データ＋解析結果＋ソフトウェアプロダクト断片

再構成されたデータを解析する技術・ツールの開発

ケーススタディ：俯瞰，傾向・関係性の顕在化・評価，仮説の生成・検証

技術・ツールの利用方法を明示するシナリオの提供

（現在，開発中）


36

謝辞

本発表は，独立行政法人情報処理推進機構技術本部ソフトウェア・エンジニアリング・センター（現，ソフトウェア高信頼化センター）が実施した「2012年度ソフトウェア工学分野の先導的研究支援事業」の公募による採択を受けて奈良先端科学技術大学院大学情報科学研究科（研究責任者松本健一）が実施した研究の成果の一部を取りまとめたものです．

同研究の成果報告書は，

http://www.ipa.go.jp/files/000026806.pdf

からダウンロード可能です．

Documents

ソフトウェア品質の第三者評価のための基盤技術 －ソフトウェア … · Redmine Trac MS Project (30 « Product DB CVS SVN git « er （半 自 動 ） r （ス

ソフトウェア品質の第三者評価のための基盤技術－ソフトウェア … · Redmine Trac MS Project (30 « Product DB CVS SVN git « er （半自動） r （ス