EASEプロジェクトの現状と展望 JEITAソフトウェアエンジニアリング技術専門委員会

Presentation on theme: "EASEプロジェクトの現状と展望 JEITAソフトウェアエンジニアリング技術専門委員会"— Presentation transcript:

1 EASEプロジェクトの現状と展望 JEITAソフトウェアエンジニアリング技術専門委員会
大阪大学 井上克郎

2 プロジェクトの概要

3 ソフトウェア開発の現状と問題点 ソフトウェアの信頼性 ソフトウェアの生産性 経験的なノウハウやアドホックな手法，ツールを使う場合が多い
多数のバグを含んだソフトの流通 一度ダウンすると多大な社会的損失 ソフトウェアの生産性 開発期間の短縮要請 人海戦術による限界 経験的なノウハウやアドホックな手法，ツールを使う場合が多い 個別要素技術研究の他に管理・統合技術研究が必要

4 科学的手法に基づくソフトウェア開発 多くの他の科学、工学分野では、計測して定量化・モデル化し、評価を行い、それをフィードバックして改善を行うのが普通（フィードバックループ） ソフトウェア開発の分野では？ 30年に亘って，いろいろな技法，システム，ツールなどの提案がなされたが，その多くは消え去り，十分な評価も行われていない． 評価するために手間暇かかる →歴史で評価 （ICSE n-10)

5 EASEプロジェクトにおける エンピリカルソフトウェア工学
定量的なデータに基づいてソフトウェアの生産性や品質の向上を目指す諸技術 データの収集が必須 実際の開発現場のデータ オープンソース開発プロジェクトのデータ エンピリカルソフトウェア工学に関する雑誌、国際会議、研究会などができている

6 Journal by Kluwer Empirical Software Engineering

7 International Symposium on Empirical Software Engineering
第1回：2002年，日本（奈良） 第2回：2003年，イタリア（ローマ） 第3回：2004年，米国（ロサンジェルス） ・・・

8 ISERN （International Software Engineering Research Network）
米国，ドイツ，オーストラリア，日本をはじめとする世界12カ国の産学の研究者により1993年に創設 会員制の形態をとり，年一度の会合 ソフトウェアの開発・利用・管理を支援する技術について，理論面での議論と共に，技術の有用性を確かめる実証実験も行う

9 e-Society:基盤ソフトウェアの総合開発
15年度予算における科学技術振興費 35,916億円（前年度35,444）：472億円増 ライフサイエンス、情報通信、環境、エネルギー、 ナノテクノロジー・材料、製造技術、社会基盤、 フロンティアの各分野 情報通信分野の施策 ユビキタスネットワークの研究開発（総） 25億 e-Society基盤ソフトウェアの総合開発（文） 12億→10億(16年度) 戦略的情報通信研究開発推進制度（総） 25億 超高速コンピュータ網形成（文）　 20億 ビジネスグリッドコンピューティング（経） 07億

10 テーマ一覧 高い生産性を持つ高信頼ソフトウェア作成技術の開発（代表 片山卓也） 片山卓也（北陸先端大） 湯淺太一(京都大)
高い生産性を持つ高信頼ソフトウェア作成技術の開発（代表　片山卓也） 片山卓也（北陸先端大） 湯淺太一(京都大) 中島達夫(早稲田大) 高信頼組込みソフトウェア構築技術 石川裕(東京大) 次世代高性能コンピュータシステム上の高信頼ソフトウェアシステムの開発支援技術 米澤明憲(東京大) 大堀淳（北陸先端大） プログラム自動解析に基づく高信頼ソフトウェアシステムの構築技術 鳥居宏次(奈良先端大) 井上克郎(大阪大) 松本健一(奈良先端大) データ収集に基づくソフトウェア開発支援システム 武市正人(東京大) 高信頼構造化文書変換技術 阿草清滋（名古屋大） 鰺坂恒夫（和歌山大） 高信頼WebWareの生成技術 情報の高信頼蓄積・検索技術の開発（代表　村岡洋一） 喜連川優（東京大） 先進的なストレージ技術およびWeb解析技術 村岡洋一（早稲田大） インターネット上の知識集約を可能にするプラットフォーム構築技術 鹿野清宏（奈良先端大） 河原 達也(京都大）　 猿渡　洋 （奈良先端大学） 武田　一哉 (名古屋大 ) 河原 英紀 （和歌山大学） ユーザ負担のない話者・環境適応性を実現する自然な音声対話処理技術

11 従来の研究プロジェクトとの違い 社会に役立つプロダクトを作り、産業を活性化するようなインパクトを与える 産学連携が必須事項 人材養成
研究プロジェクトとして、論文、特許も

12 「データ収集に基づくソフトウェア開発支援システム」 EASEプロジェクト
エンピリカル環境の提案と構築 エンピリカル環境の配布・実プロジェクトへの適用 エンピリカルデータやその分析による知見の蓄積 適用先の組織の生産性、品質の向上 プロジェクトのホームページ：　

13 プロジェクトの推進方法： ラボ方式による技術移転
実データ 　　　結果の検証 産業界 プロジェクト ラボ 大学 データ収集，フィードバック：　技術移転，　人材育成 ツールの開発，ツールの普及，データの蓄積 テーマの発掘，データの分析・評価，知見の整理・発表 フィードバック モデル、知見

14 プロジェクトの構成 中核大学 奈良先端大 大阪大 プロジェクト・ラボ 中核企業 -専任スタッフ NTTソフトウェア -大学兼任者 日立製作所
協力大学 -国内・国外大学 協力企業 -国内・国外企業 協力組織 -SEC 　… 中核大学 奈良先端大 大阪大 中核企業 NTTソフトウェア 日立製作所 日立公共システム SRA プロジェクト・ラボ 　-専任スタッフ 　-大学兼任者 　-企業出向者

15 エンピリカルSEラボ in千里 産官学の交流の拠点 エンピリカル環境の各種ツールの開発拠点 企業からの出向研究者
大阪・千里中央・千里ライフサイエンスセンター11階 大阪空港、新大阪駅までそれぞれ15分程度 奈良先端大東京オフィス（田町駅前）でも活動

16 国際アドバイザー Prof. Victor R. Basili （米国・メリーランド大学教授， フラウンホーファセンター・メリーランド　センター長） Prof. Dr. Dieter H. Rombach （ドイツ・カイザースロータン大学教授、 フラウンホーファ実験的ソフトウェア工学研究所　所長） Prof. Barry W. Boehm （米国・サザンカリフォルニア大学教授） Prof. Ross Jeffery （オーストラリア・ニューサウスウェールズ大学教授）

17 エンピリカル環境

18 エンピリカルソフトウェア工学 目的に応じた定量的なデータに基づいてソフトウェアの生産性や信頼性向上を行う諸技術
科学的根拠に基づいてプロジェクトの改善を行うには必須

19 エンピリカルソフトウェア工学の ３つのフェーズ
収集 分析 改善

20 エンピリカルソフトウェア工学の規模による分類
　　　　　本プロジェクトのターゲット 巨大 大 既存の技術 小

21 １～何万というプロジェクトを扱うことができるエンピリカルソフトウェア工学支援環境
本プロジェクトのターゲット １～何万というプロジェクトを扱うことができるエンピリカルソフトウェア工学支援環境 エンピリカル環境

22 ターゲット選定理由 （実用化はまだまだだが）個人や組織を対象としたソフトウェア工学の技術は多数ある
多数のプロジェクトまでを対象としたソフトウェア工学技術（Mega　Software Engineering）まだない 組織の利益に直結する結果が得やすい 基礎となる技術の種はいろいろある 計算機のパワーアップ、ネットワークの高速化によって、実現できそうな気配

23 本プロジェクトの目標 エンピリカル環境の構築 エンピリカル環境の配布・実プロジェクトへの適用 エンピリカルデータやその分析による知見の蓄積
適用先の組織の生産性、品質の向上

24 エンピリカル環境の概念 分析 収集 改善 組織内で情報のやりとり 外部に流す必要なし インターネット （パブリックドメインソフト、
ソフトウェア開発会社 関連会社 組織内で情報のやりとり 外部に流す必要なし インターネット （パブリックドメインソフト、 オープンソース開発データ） 収集 改善

25 エンピリカル環境の 実現

26 （１）収集に関する実現方針 目標を決めてから収集するデータを決める （理想的しかし組織によって目標は異なる）
目標を決めてから収集するデータを決める　 　　（理想的しかし組織によって目標は異なる） 　　→　取れるデータ全てを取っておく　（現実的アプローチ） プロダクトデータを中心に収集（プロセスデータはプロダクトデータから計算して得る） できるだけ簡単で、開発作業者の負担なく収集できる仕掛け 人為的な操作の少ない生データを収集 できるだけリアルタイムに収集 既存の開発環境と連携しつつ種々なプロジェクトに対応 小規模 XPなど非ウォーターフォールプロセス 分散開発（外部発注）

27 （２）分析に関する実現方針 段階的実現（簡単なものから順に） 困難 ５． … ４．再利用部品・知識抽出検索 ３．プロジェクト分類、発展解析
５．　… ４．再利用部品・知識抽出検索 ３．プロジェクト分類、発展解析 ２．複数プロジェクトにまたがるメトリクス 容易 １．プロジェクト内のプロセス・プロダクトメトリクス

28 （３）改善に関する実現方針 目的に応じたフィードバック 様々な仕掛けが必要 当面は収集データおよび１，２の分析結果を視覚的に表示するブラウザ

29 Empirical Project Monitor EPM
エンピリカル環境の一部として開発中 プロジェクトの制御に有益な作業情報を収集、分析、表示 データ収集源 構成管理ツールCVS メーリングリスト管理ツールMailman 障害管理ツールGNATS

30 標準エンピリカルSEデータ形式（XML）
EPMのアーキテクチャ 分析Tool群 開発者 管理者 個別プロジェクト、プロジェクト間メトリクス計測 PostgreSQL(Repository) 標準エンピリカルSEデータ形式（XML） 開発者 管理者 CVS, Mailman, GNATS, (WinCVS, CorporateSource) その他: メトリックス予測 他ツールのデータ など 構成管理 履歴 メール 履歴 障害 履歴 既存の開発環境

31 EPMの特長 オープンソース開発に使われているツール利用 → 容易に導入可能 データ収集の負担 → 簡単な規約で可能
オープンソース開発に使われているツール利用　　→　　容易に導入可能 データ収集の負担 　　→　　簡単な規約で可能 プロダクトデータ（例えば1日1回CVSに保存） 連絡はメールで、障害は管理ツールで記録を残す 他のツールから標準エンピリカルSEデータ形式への変換容易　 　　　 →　　他の開発環境との連携可能

32 EPMの適用対象 大規模プロジェクト 小規模プロジェクト 情報の共有がリアルタイムで可能 管理の負荷が低減 人為的なデータ操作が入りにくい
今まで手間等の問題で管理しにくかったプロジェクトにも適用しやすい いろいろなプロセス（XPなど）や組織をまたがる分散開発にも適用可能

33 Empirical Project Monitorの機能

34 EPMの分析ツール 個別分析 関連分析 ソースコード規模 障害解決時間 累積・未解決障害件数/平均障害滞留時間，ほか 更新/参照数
更新・障害報告/メール投稿数 更新と障害件数，ほか

35 個別分析(ソースコードの規模の推移) プロジェクトの進捗状況が把握できる 類似プロジェクトを参考に予実管理もある程度可能になる
詳細見積もりとスケジュールから予定作成も可能

36 ソースコード規模の推移（3ヶ月）

37 ソースコードの規模推移 オープンソース開発プロジェクトnkf

38 累積・未解決障害件数/平均障害滞留時間

39 関連分析(更新と障害件数) 障害件数の推移 CVSの更新時期を線で示し，バージョンごとの障害状況を確認できる

40 関連分析(更新・障害報告とメール投稿数)
メール投稿数とCVSの更新時期、障害発生・解決時期の関連

41 CVS詳細情報 更新一覧 CVSの更新情報を一覧できる

42 メール詳細情報 トップメールトピックス一覧 議論の活発な話題を確認できる トピックはサブジェクトからML名、”Re:”を除いて作成

43 EPMの発展

44 分析や改善に関する機能拡張 より深い分析や解析を行い、組織の知識蓄積する より手軽に知識が取り出せて、有効利用されるようにする

45 . . . エンピリカル環境 EPM（開発中） Code clone detection Component search Metrics
measurement Project categorization Cooperative filtering Product data archive (CVS format) Process data archive (XML format) Format Translator Format Translator Format Translator Format Translator Versioning (CVS) Mailing (Mailman) Issue tracking (GNATS) Other tool data Managers Project x Project y Corporate Source GUI Project z . . . Developers エンピリカル環境

46 拡張機能利用のシナリオ (1) プロジェクトXの進捗予定 実際のプロジェクトXの進捗 Xの類似プロジェクトを探す - プロジェクト分類技術
- 協調フィルタリング 2 X Y A Q T E W C V P

47 拡張機能利用のシナリオ(2) 同類の再利用率 Xの再利用率 ソフトウェアの再利用を促進させる - ソフトウェア部品検索エンジン 3
- コードクローン検出 -　ソフトウェア部品検索エンジン 4 ソフトウェアの再利用を促進させる

48 期待される効果 社内的な再利用やオープンソースの利用でプログラムの生産性が劇的に上がった
管理しきれなかった膨大な社内資産が、見通しよく整理できた 過去の同類のプロジェクト情報を有効利用して、コスト管理が厳密になった 蓄積した欠陥情報を利用して、信頼性を大幅に改善された

49 分析技術（1） コードクローン検出： （ソースコード中に存在する類似したコード片）
分析技術（1） 　　コードクローン検出： 　　（ソースコード中に存在する類似したコード片）

50 分析技術（2） クローンに基づくソフトウェアシステムの類似度
分析技術（2） 　クローンに基づくソフトウェアシステムの類似度

51 分析技術（３） 協調フィルタリングに基づく類似プロジェクトの発見とメトリクス予測 ？
ソースコードA と「テスト済みソースコードB，C，D」 との間で類似度を計算する 「B，C，D のバグ数」と「類似度」から「Ａのバグ数」を予測する． 言語 行数 複雑さ 実装者の スキル バグ数 Java 1000 非常に複雑 ( 9 ) 低い ( 4 ) ？ 予測値 37 ソースコード A Java 1100 複雑 ( 7 ) 低い ( 3 ) 38 類似度：高（0.7） 類似度：高（0.8） 類似度：低（0.2） ソースコード B Java 700 非常に複雑 ( 9 ) 低い ( 4 ) 33 ソースコード C C++ 2000 普通 ( 5 ) 高い ( 7 ) 48 ソースコード D

52 分析技術（４） Javaプログラム検索エンジン

53

54

55 まとめ

56 まとめ EASEプロジェクトの概要 エンピリカル環境の概念の提案
エンピリカル環境の一部としてのEmpirical Project Monitor EPMの紹介 導入の壁が低い いろいろな環境に適応可能 EPMの拡張の方向性 より深い分析と知見の抽出 EPM エンピリカル環境

57 エンピリカル環境導入のメリット（１） まだプロジェクトの計測を行っていない場合
既存の開発環境と連携して手軽にプロジェクトのモニターができる プロジェクトの異常検出 過去や予想との比較 プロジェクトの蓄積が容易 どんなプロジェクトでも将来 に残せる

58 エンピリカル環境導入のメリット（２） すでに計測を行っている場合
全社的に統一的なデータをリアルタイムで揃えられるようになる 個人の目標と比べて 部署やプロジェクトの間の比較 他社と比べて、海外と比べてどうか？ エンピリカルデータの統合により、情報の共有や再利用が（個人の経験や勘に頼らずに）自動的に行えるようになる 似たようなプロジェクト、似たようなソフトウェア開発での知見の発掘、重複作業の排除

59 プロジェクトの今後

60 スケジュール 現在 今月末 2月に一度の頻度で研究会開催中＠田町 SECとの協力、役割分担 EPMα版、数社で適用中
分析ツール（SRGM)の追加 2月に一度の頻度で研究会開催中＠田町 SECとの協力、役割分担 プロジェクトデータ収集（SEC) データの分析方法