EASEプロジェクトの概要

実証的ソフトウェア工学環境
とEASEプロジェクトについ
て
大阪大学
大学院情報科学研究科
井上克郎
ソフトウェア開発の現状と問題
点

ソフトウェアの信頼性
多数のバグを含んだソフトの流通
一度ダウンすると多大な社会的損失

ソフトウェアの生産性
開発期間の短縮要請
人海戦術による限界
経験的なノウハウやアドホックな手法，
ツールを使う場合が多い
 個別要素技術研究の他に管理・統合技術
研究が必要

2004/3/31
クリティカルソフトウェアWS2004
2
科学的手法に基づくソフトウェア
開発


多くの他の科学、工学分野では、計測して定量
化・モデル化し、評価を行い、それをフィード
バックして改善を行うのが普通（フィードバッ
クループ）
ソフトウェア開発の分野では？
 30年に亘って，いろいろな技法，システム，ツール
などの提案がなされたが，その多くは消え去り，十
分な評価も行われていない．
 評価するために手間暇かかる
→歴史で評価（ICSE n-10)
2004/3/31
クリティカルソフトウェアWS2004
3
エンピリカルソフトウェア工学

目的に応じた定量的なデータに基づいて
ソフトウェアの生産性や信頼性向上を行
う諸技術

科学的根拠に基づいてプロジェクトの改
善を行うには必須

エンピリカルソフトウェア工学に
関する雑誌、国際会議、研究会
などができている
2004/3/31
クリティカルソフトウェアWS2004
4
Journal by Kluwer
Empirical Software Engineering
2004/3/31
クリティカルソフトウェアWS2004
5
International Symposium
on Empirical Software Engineering
第1回：2002年，日本（奈良）
第2回：2003年，イタリア（ローマ）
第3回：2004年，米国（ロサンジェルス）
・・・
2004/3/31
クリティカルソフトウェアWS2004
6
ISERN
（International Software Engineering Research
Network）
 米国，ドイツ，オーストラリア，日本を
はじめとする世界12カ国の産学の研究者
により1993年に創設
 会員制の形態をとり，年一度の会合
 ソフトウェアの開発・利用・管理を支援
する技術について，理論面での議論と共
に，技術の有用性を確かめる実証実験も
行う
2004/3/31
クリティカルソフトウェアWS2004
7
文部科学省リーディングプロジェクトe-Society
「データ収集に基づくソフトウェア開発支援システ
ム」
EASEプロジェクト
1.
エンピリカル環境の提案と構築
2.
エンピリカル環境の配布・実プロジェク
トへの適用
3.
エンピリカルデータやその分析による知
見の蓄積
適用先の組織の生産性、品質の向上
4.
2004/3/31
クリティカルソフトウェアWS2004
8
プロジェクトの推進方法：
ラボ方式による技術移転
実データ
産業界
プロジェクト
ラボ
フィードバック
2004/3/31
結果の検証
大学
モデル、知見
クリティカルソフトウェアWS2004
9
プロジェクトの構成
協力大学
-国内・国外大学
中核大学
•奈良先端大
•大阪大
プロジェクト・ラボ
-専任スタッフ
中核企業
-大学兼任者
•NTTソフトウェア
-企業出向者
•日立製作所
•日立公共システム
•SRA
2004/3/31
クリティカルソフトウェアWS2004
協力企業
-国内・国外企業
技術委員会
-メトリクス
-安全性
-プロセス改善
-形式手法
…
10
エンピリカルSEラボ in千里

産官学の交流の拠点

エンピリカル環境の各種ツールの開発拠点

企業からの出向研究者，ポスドク

大阪・千里中央・千里ライフサイエンスセン
ター11階
 大阪空港、新大阪駅までそれぞれ15分程度
2004/3/31
クリティカルソフトウェアWS2004
11
国際アドバイザー

Prof. Victor R. Basili

Prof. Dr. Dieter H. Rombach

Prof. Barry W. Boehm

Prof. Ross Jeffery
（米国・メリーランド大学教授，
フラウンホーファセンター・メリーランドセンター
長）
（ドイツ・カイザースロータン大学教授、
フラウンホーファ実験的ソフトウェア工学研究所所
長）
（米国・サザンカリフォルニア大学教授）
（オーストラリア・ニューサウスウェールズ大学教
クリティカルソフトウェアWS2004
2004/3/31
授）
12
EASEで目指すエンピリ
カルソフトウェア工学環
境について
エンピリカルソフトウェア工学
の
３つのフェーズ
収集
分析
2004/3/31
改善
クリティカルソフトウェアWS2004
14
エンピリカルソフトウェア工学の規模による分類
規模
巨大
本
プ
ロ
ジ
ェ
ク
ト
の
タ
ー
ゲ
ッ
ト
大
既
存
の
技
術
小
収集
分析
改善
本プロジェクトのターゲット
１～何万というプロジェクトを扱うことができる
エンピリカルソフトウェア工学支援環境
エンピリカル環境
2004/3/31
クリティカルソフトウェアWS2004
16
ターゲット選定理由





（実用化はまだまだだが）個人や組織を対象と
したソフトウェア工学の技術は多数ある
多数のプロジェクトまでを対象としたソフト
ウェア工学技術（Multi-Project Software
Engineering）まだあまりない
組織の利益に直結する結果が得やすい
基礎となる技術の種はいろいろある
計算機のパワーアップ、ネットワークの高速化
によって、実現できそうな気配
2004/3/31
クリティカルソフトウェアWS2004
17
エンピリカル環境の概念
組織内で情報のやりとり
外部に流す必要なし
収集
分析
インターネット
（パブリックドメインソフト、
オープンソース開発データ）
改善
関連会社
2004/3/31
クリティカルソフトウェアWS2004
ソフトウェア開発会社
18
エンピリカル環境の
実現
（１）収集に関する実現方針

目標を決めてから収集するデータを決める
（理想的しかし組織によって目標は異なる）





→ 取れるデータ全てを取っておく（現実的アプ
ローチ）
プロダクトデータを中心に収集（プロセスデータはプロ
ダクトデータから計算して得る）
できるだけ簡単で、開発作業者の負担なく収集できる仕
掛け
人為的な操作の少ない生データを収集
できるだけリアルタイムに収集
既存の開発環境と連携しつつ種々なプロジェクトに対応



2004/3/31
小規模
XPなど非ウォーターフォールプロセス
分散開発（外部発注）クリティカルソフトウェアWS2004
20
（２）分析に関する実現方針
段階的実現（簡単なものから順に）
困難
５． …
４．再利用部品・知識抽出検索
３．プロジェクト分類、発展解析
２．複数プロジェクトにまたがるメトリクス
容易
2004/3/31
１．プロジェクト内のプロセス・プロダクトメトリクス
クリティカルソフトウェアWS2004
21
（３）改善に関する実現方針

目的に応じたフィードバック
様々な仕掛けが必要
当面は収集データおよび１，２の分析結果
を視覚的に表示するブラウザ
2004/3/31
クリティカルソフトウェアWS2004
22
Empirical Project Monitor
EPM
エンピリカル環境の一部として開発中
 プロジェクトの制御に有益な作業情報を
収集、分析、表示
 データ収集源

構成管理ツールCVS
メーリングリスト管理ツールMailman
障害管理ツールGNATS
2004/3/31
クリティカルソフトウェアWS2004
23
EPMのアーキテクチャ
分析Tool群
開発者
管理者
個別プロジェクト、プロジェクト間メトリクス計測
PostgreSQL(Repository)
標準エンピリカルSEデータ形式（XML）
開発者
管理者
構成管理
履歴
メール
履歴
障害
履歴
その他:
メトリックス予測
他ツールのデータ
など
CVS, Mailman, GNATS, (WinCVS, CorporateSource)
既存の開発環境
2004/3/31
クリティカルソフトウェアWS2004
24
EPMの特長
オープンソース開発に使われているツール
利用
→
容易に導入可能
 データ収集の負担
→
簡単な規約で可能

プロダクトデータ（例えば1日1回CVSに保
存）
連絡はメールで、障害は管理ツールで記録を
残す

他のツールから標準エンピリカルSEデー
タ形式への変換容易
2004/3/31
クリティカルソフトウェアWS2004
25
EPMの適用対象

大規模プロジェクト
情報の共有がリアルタイムで可能
管理の負荷が低減
人為的なデータ操作が入りにくい

小規模プロジェクト
今まで手間等の問題で管理しにくかったプロ
ジェクトにも適用しやすい
いろいろなプロセス（XPなど）や組織をまた
がる分散開発にも適用可能
2004/3/31
クリティカルソフトウェアWS2004
26
Empirical
Project Monitor
の機能
EPMの分析ツール

今は主に個別プロジェクト対象
ソースコード規模
障害解決時間
累積・未解決障害件数/平均障害滞留時間
更新/参照数
更新・障害報告/メール投稿数
更新と障害件数
ほか
2004/3/31
クリティカルソフトウェアWS2004
28
個別分析(ソースコードの規模の推
移)
2004/3/31
クリティカルソフトウェアWS2004
29
ソースコード規模の推移（3ヶ月）
2004/3/31
クリティカルソフトウェアWS2004
30
ソースコードの規模推移
オープンソース開発プロジェクトnkf
2004/3/31
クリティカルソフトウェアWS2004
31
累積・未解決障害件数/平均障害滞留時間
2004/3/31
クリティカルソフトウェアWS2004
32
関連分析(更新と参照)
2004/3/31
クリティカルソフトウェアWS2004
33
CVS詳細情報

更新一覧

2004/3/31
CVSの更新情報を一覧できる
クリティカルソフトウェアWS2004
34
関連分析(更新・障害報告とメール投稿

メール投稿数とCVSの更新時期、障害発生・解決時期の関連
数)
2004/3/31
クリティカルソフトウェアWS2004
35
メール詳細情報

トップメールトピックス一覧


2004/3/31
議論の活発な話題を確認できる
トピックはサブジェクトからML名、”Re:”を除いて作成
クリティカルソフトウェアWS2004
36
関連分析(更新と障害件数)

障害件数の推移

2004/3/31
CVSの更新時期を線で示し，バージョンごとの障害状況を確認できる
クリティカルソフトウェアWS2004
37
エンピリカル環境へ
の発展
分析や改善に関する機能拡張
より深い分析や解析を行い、組織の知識
蓄積する
 より手軽に知識が取り出せて、有効利用
されるようにする

2004/3/31
クリティカルソフトウェアWS2004
39
Code clone
detection
Component
search
Metrics
measurement
Product data archive
(CVS format)
Process data archive
(XML format)
Format
Translator
Managers
Corporate
Source
Developers
GUI
Project
categorization
Versioning
(CVS)
Format
Translator
Mailing
(Mailman)
Format
Translator
Issue
tracking
(GNATS)
Cooperative
filtering
EPM（開発中）
Format
Translator
Other tool
data
Project x
Project y
Project z
...
エンピリカル環境
拡張機能利用のシナリオ (1)
プロジェクトXの進捗予定
1
実際のプロジェクトXの進捗
2
E
W
2004/3/31
A
X
Y
P
Xの類似プロジェクトを探す
- プロジェクト分類技術
- 協調フィルタリング
C
T
Q
V
クリティカルソフトウェアWS2004
41
拡張機能利用のシナリオ(2)
同類の再利用率
3
Xの再利用率
- コードクローン検出
4
ソフトウェアの再利用を促進させる
- ソフトウェア部品検索エンジン
2004/3/31
クリティカルソフトウェアWS2004
42
期待される効果
社内的な再利用やオープンソースの利用
でプログラムの生産性が劇的に上がった
 管理しきれなかった膨大な社内資産が、
見通しよく整理できた
 過去の同類のプロジェクト情報を有効利
用して、コスト管理が厳密になった
 蓄積した欠陥情報を利用して、信頼性を
大幅に改善された

2004/3/31
クリティカルソフトウェアWS2004
43
分析技術（1）
コードクローン検出（ソースコード中に存在する類似コー
ド片）
Linux 2.4.0
NetBSD 1.5
NetBSD 1.5
Linux 2.4.0
FreeBSD 4.0
FreeBSD 4.0
2004/3/31
クリティカルソフトウェアWS2004
44
分析技術（2）
クローンに基づくソフトウェアシステムの類似度
2004/3/31
クリティカルソフトウェアWS2004
45
分析技術（３）
協調フィルタリングに基づく類似プロジェクトの発見とメトリクス予測


ソースコードA と「テスト済みソースコードB，C，D」との間で類似度を計算す
る
「B，C，D のバグ数」と「類似度」から「Ａのバグ数」を予測する．
言語
行数
複雑さ
実装者の
スキル
バグ数
ソースコード A
Java
1000
非常に複雑
(9)
低い
(4)
予測値
？
37
ソースコード B
Java
1100
複雑
(7)
低い
(3)
38
類似度：高（0.8）
ソースコード C
Java
700
非常に複雑
(9)
低い
(4)
33
類似度：高（0.7）
ソースコード D
C++
2000
普通
(5)
高い
(7)
48
類似度：低（0.2）
2004/3/31
クリティカルソフトウェアWS2004
46
分析技術（４）
Javaプログラム検索エンジン
2004/3/31
クリティカルソフトウェアWS2004
47
まとめ
まとめ
エンピリカル環境の概念の提案
 エンピリカル環境の一部としての
Empirical Project Monitor EPMの紹介

導入の壁が低い
いろいろな環境に適応可能

EPM
EPMの拡張の方向性
より深い分析と知見の抽出
エンピリカル環境
2004/3/31
クリティカルソフトウェアWS2004
51
エンピリカル環境導入のメリッ
ト（１）
まだプロジェクトの計測を行っていない場
既存の開発環境と連携して手軽にプロ
合
ジェクトのモニターができる
プロジェクトの異常検出
過去や予想との比較

プロジェクトの蓄積が容易
どんなプロジェクトでも将来
に残せる
2004/3/31
クリティカルソフトウェアWS2004
52
エンピリカル環境導入のメリッ
ト（２）

全社的に統一的なデータをリアルタイムで揃え
すでに計測を行っている場合
られるようになる
 個人の目標と比べて
 部署やプロジェクトの間の比較
 他社と比べて、海外と比べてどうか？

エンピリカルデータの統合により、情報の共有
や再利用が（個人の経験や勘に頼らずに）自動
的に行えるようになる
 似たようなプロジェクト、似たようなソフトウェア
開発での知見の発掘、重複作業の排除
2004/3/31
クリティカルソフトウェアWS2004
53
スケジュール

現在
EPMのデモ版

今年度中
EPMの配布版αリリース

来年度
EPMの現場での適用、フィードバック
分析ツール追加

ユーザーグループ、研究会、コンソーシ
アムなど、興味ある人の集まる場の提供
を検討中
2004/3/31
クリティカルソフトウェアWS2004
54

Download Report