Document

エンピリカルソフトウェア工
学と
ソフトウェアタグ
大阪大学
井上克郎
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
講演の概要
• エンピリカルソフトウェア工学
• ソフトウェアタグ
• 近年のソフトウェア工学研究雑感
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
ソフトウェア開発の現状と問題点
• ソフトウェアの信頼性
– 多数のバグを含んだソフトの流通
– 一度ダウンすると多大な社会的損失
• ソフトウェアの生産性
– 開発期間の短縮要請
– 人海戦術による限界
• 経験的なノウハウや非科学的な手法、ツールを
使っている
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
44
科学的評価に基づくソフトウェア開発
• 多くの他の科学、工学分野では、計測して定量
化し、評価を行い、それをフィードバックして
改善を行うのが普通（フィードバックループ）
• ソフトウェア開発の分野では？
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
5
Zelkowitz-Wallaceによる評価法分類
• 観測型(Observational)
実際に行われているプロジェクトを横から観測して
評価
• 履歴型(Historical)
過去に行われたプロジェクトのデータや発表された
論文に基づいて評価
• 制御型(Controlled)
目的とするデータを得るために環境を整えてプロ
ジェクトを行い評価する
V. Zelkowitz, D. R.Wallace, "Experimental Models for Validating
Technology", IEEE Computer, pp.23-31, May 1998.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
観測型評価
• プロジェクトモニタ
– 対象を漠然と観察。目標不明確な場合も。簡単
• 事例研究
– 対象をより深く解析。まだ、変動要素の制御が不
十分だが、比較的簡便
• アサーション
– 主張がなりたつことを簡単なプロジェクトで実
証。厳密な評価としては不十分。
• 野外調査(Field Study)
– いろいろなプロジェクトを見て回る。条件を揃え
るのが困難だが追証しやすい。
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
7
履歴型
• 文献調査
– 過去発表された論文を探す。条件や視点の統一不可能。簡
単
• 事例調査
– 過去のプロジェクトデータをひっくりかえす。条件不統一
でデータ限られている
• 経験
– 過去のプロジェクトの定性的なデータを調べる。定量的な
議論できない。やりやすくて簡単に傾向がわかる
• (静的解析)
– 作ったプロダクトの解析をする。方法論には適用できない。
8
評価の自動化できるかもしれない。
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
制御型
• 繰返し
– 条件を揃えていくつものプロジェクトで繰り返す。高価。
• 実験室
– 条件を揃えて実験室で繰り返す。スケーラビリティ。条
件を制御しやすく比較的安価。
• (動的解析)
– プロダクトの効率を実行させて計測。方法論には適用で
きない。
• (シミュレーション)
– 仮想データで実行。
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
9
発表された論文の分類（他の科
学）
方法＼論文種類
デバイス
物理
臨床医学
人類学
評価なし
プロジェクトモニタ
事例評価
アサーション
野外調査
16%
58%
6%
31%
40%
8%
16%
4%
6%
8%
8%
文献調査
事例調査
経験
静的解析
4%
繰返し
実験室
動的解析
シミュレーション
18%
11%
24%
6%
5%
5%
32%
23%
23%
8%
12%
29%
5%
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
10
ソフトウェア工学の論文が使っている評価法
実験なし
プロジェクトモニタ
事例研究
アサーション
評価法
野外調査
文献調査
1985
1990
1995
事例調査
経験
-ICSE
-TSE
-IEEE
Software
静的解析
繰返し
実験室
動的解析
シミュレーション
論文の割合
0%
5%
10%
15%
20%
25%
30%
35%
40%
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
45%
11
エンピリカルソフトウェア工学
• Empirical Software Engineering、実証的・実験的SE
• 目的に応じた定量的・定性的な評価に基づいて
ソフトウェアの生産性や信頼性向上を行う諸技
術
• 科学的根拠に基づいてプロジェクトの改善を行
うには必須
• 国際会議、論文誌、研究所等
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
12
学会での発展
International Symposium on
Empirical Software Engineering (& Measurement)
第1回：2002年、日本（奈良）
第2回：2003年、イタリア（ローマ）
第3回：2004年、米国（ロサンジェルス）
第4回：2005年、オーストラリア（ノーザヘッド）
第5回：2006年、ブラジル（リオデジャネイロ）
第6回：2007年、スペイン（マドリッド）
第7回：2008年、ドイツ（カイザーズラウテン）
Empirical Software
Engineering
•Springer社
•1996年に創刊
•年に4回出版
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
13
Fraunhofer Institute for Experimental Software Engineering
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
14
EASEプロジェクト
• Empirical Approach to Software Engineering
• 文部科学省リーディングプロジェクト
実データ
– ｅ－Ｓｏｃｉｅｔｙ基盤ソフトウェアの総合開発
• データ収集に基づくソフトウェア開発支援産業界
システム
• 主要組織
結果の検証
EASE
プロジェクト
フィードバック
大学
モデル、知見
– 奈良先端科学技術大学院大学、大阪大学
– ＮＴＴソフトウェア、日立製作所、日立公共システム、
ＳＲＡ先端技術研究所
• 平成15年度から19年度実施
– 社会に役立つプロダクトを作り、産業を
活性化させる
– 大阪（千里中央）にラボ
– 東京（田町）で定期的研究会開催
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
15
実証データに基づく開発支援
• 自動データ収集
– 構成管理履歴
– 障害履歴
– メール履歴
• データ分析
–
–
–
–
メトリクス
プロジェクト分類
協調フィルタリング
ソフトウェア部品検索
Data
Collection
Data
Analysis
Feedback
エンピリカル環境
• 生産性、信頼性改善のためのフィードバック
– 一部リアルタイムに
– 観察と規則化
– 過去のプロジェクトの具体的な事例
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
16
出力例１：
収集データの統合表示
コードチェックイン
時刻（CVS)
問題発生時刻
（GNATS)
開発者間でやり取りされたメイル
総数（Mailman）
問題解決時刻
（GNATS)
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
17
出力例２：
ＳＲＧＭによる残存バグ数推
定
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
18
ＥＰＭ適用企業
• ＮＴＴソフトウェア
• ソフトウェアエンジニア
リング技術研究組合
• ＳＲＡ先端技術研究所
（COSE)
• 日立システムアンドサー
– 日本電気、トヨタ自動車、
ビス
デンソー、日立製作所、富
• 日立公共システムエンジ
士通、松下電器産業、ＮＴ
Ｔデータ
ニアリング
• 日本電子計算
• 住商情報システム
• 三菱スペース・ソフト
ウェア
• ＪＦＥシステムズ
• サイバー創研
• 横河電機
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
19
障害対応の進捗グラフ
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
20
コンポーネント規模推移グラフ
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
21
コンポーネント毎の更新回数の遷
移
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
22
EASEアプローチの効果
• EPMにより、プロジェクトの進捗状況がリアル
タイムに可視化できるようになった
– 今までは、数週間のタイムラグ
– 異常事態の早期発見が可能
– 委託先での状況を知ることができるようになった
• 状況把握のための手間が減少し、正確に分かる
ようになった
– 紙やエクセルベースの入力の手間が不要
– 間違いや不正が入り込む余地が少なくなった
• より深いデータの分析に踏み込めるようになっ
た
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
23
EASEは科学的か？
• 科学的とは？
– 科学的のちゃんとした定義は？
– 反証主義（科学哲学）
Data
Collection
Data
Analysis
Feedback
エンピリカル環境
エンピリカル環境
• 反証可能性があり、反証されていない仮説を「科
学的仮説」
– 疑似科学（オカルト）との違い
可能
→
区別不
• 人間によって合理性が認められる理論を
「正しい」、それ以外を「正しくない」
Wikipedia 「疑似科学」
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
24
経験論/経験主義 Empiricism
• 人間の全ての知識は我々の経験の結果
• 理論は、直観や信仰より、観察に基礎に
置くべき
• その方法：実験による調査研究、帰納的
推論、演繹的論証
Wikipedia 「経験論」
アリストテレス
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
25
定量的アプローチ
• 経験論に基づく科学的アプローチ
– 観察に基礎を置いている
• しかし
– ソフトウェア開発に関しては、実験環境の統一不可
能?
– 実験計画法的なやり方で、ソフトウェア開発の変動
要素をカバーできるか？比較実験ができるか？
– 現状を数値化し、評価したからといって、向上でき
るとは限らない
• だが、他の反証に耐えうるアプローチは？
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
26
定量的アプローチ？
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
27
岡田斗司夫のアプローチ
• 食べ物メモ
• 体重グラフ
• 最初フィードバックは自律的にかかるこ
と期待
• やがて数字に着目したカロリー制御
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
28
EASEのアプローチも同様か？
• メモする、記録する
• グラフにする
• 自律的なフィードバックを期待
• やがて、ちゃんとした目標値に収斂させ
るプロセス制御
• 岡田氏のアプローチはPSP(Personal Software
Process)的発想
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
ソフトウェアの重要性と開発の複
雑化
• ソフトウェア品質に起因する問題の重大化と大
規模化
– 重大な社会インフラが停止する
• 銀行や通信システム
– ユーザ・ベンダに莫大な経済的損失を与える
– 人命に関る危険を引き起こす
• 航空管制システム、自動車安全制御システム
• ソフトウェアの大規模化と開発期間の短縮
– コストの低減や生産性の向上が要求される
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
31
開発情報の不透明化
• 開発体制の複雑化
– 受注ベンダから2次請け、3次請けという多重下請け
構造
– オフショア開発(海外へのアウトソース)の拡大
• ソフトウェア部品の流用・再利用の拡大
– COTS(Commercial off-the-shelf)、OSS(Open Source Software)な
ど
発注
発注
一次請け
一次請け
発注
発注者
発注者
二次請け
二次請け
二次請け
二次請け
（海外）
（海外）
元請会社
元請会社
一次請け
一次請け
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
ソフトウェアタグ
• ユーザが納品された、あるいは購入・流用したソフト
ウェアを安心して安全に用いるために、ソフトウェアの
開発プロセスや成果物に関する情報を共有する仕組み
– 開発時に得られる種々の実証データをユーザに提供
– 二者間の取引で発注者のみに開示(一般公開なし）
– 目標タグ、途中タグ、最終タグ
• 期待される効果
10
9
8
7
–
–
–
–
発注者によるソフトウェアの品質の検証
ユーザによる適正なソフトウェア製品の選択の促進
問題発生時の対応の迅速化
透明性の拡大による法的問題の発生の予防と
早期の公正な解決の促進
6
5
系列1
4
3
2
1
0
1
2
3
4
5
6
7
<23.5, 35.2, 50.7, 68.2>
7
6
5
4
系列1
3
2
1
0
20
40
60
80
1
2
3
4
5
6
7
<0, 2.5, 0, -0.8, 0 >
80
70
60
50
40
系列1
30
20
10
0
0
2
4
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
8
10
34
開発現場におけるデータ計測
• 実証データの収集
– 品質管理、進捗管理、リスク管理、コスト管理
発注
開発データ
録
納品
記
ソフトウェア開発者
ソフトウェア発注者
ソフトウェア
プロダクト
分析
フィードバック
データ収集
実証
データ
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
35
ソフトウェアタグと開発プロセス
• 実証データを選択、抽象化してタグにする
発注
開発データ記録
納品
ソフトウェア開発者
ソフトウェア発注者
ソフトウェア
プロダクト
分析
フィードバック
データ収集
添付
実証
抽出
タグ
データ
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
36
タグ項目
• プロジェクト情報(12項目）
開発プロジェクト及びシステムの基本情報
• 進捗情報（29項目）
開発プロセスの履歴や進捗に関する情報
プロジェクト情報
(12種)
進捗情報
(29種)
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
37
プロジェクト情報の構成
• 基本情報 (4)
– プロジェクト名、開発組織の情報、開発プロジェク
ト情報、顧客情報
• システム情報 (2)
– システム構成、システム規模
• 開発情報 (3)
– 開発手法、開発体制、プロジェクト期間
• プロジェクトの階層構造情報 (2)
– 親プロジェクト情報、子プロジェクト情報
• その他 (1)
– 特記事項
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
38
プロジェクト情報の例
分類
項番項目名
1
2
基本情報
3
説明
具体化例
プロジェクト名プロジェクトを一意に決定する
ための識別名
開発組織の情当該プロジェクトの開発を担当開発組織名
報
する組織の情報．一般には， ISO15504(SPICE)，CMMIなどのアセスメ
受注者となる組織情報となる．ントモデルによる認証レベル
対象業種の経験
．．．．
開発プロジェク開発プロジェクトの特徴や当開発プロジェクト種別：新規・改造・保
ト情報
該タグデータの対象とするプロ守・運用・流用など
ジェクトの種類を示す情報．タ開発プロジェクト形態：商用パッケージ，
グデータの解釈や分析時に必受託開発など
要なデータ．
利用パッケージ
設計書再利用率・ソースコード再利用
率・コンポーネント再利用率など
顧客情報
4
システム構成
5
システム情
報
システム規模
6
......
．．．．
当該システムのユーザ，もしく顧客名
は第1発注者となる組織の情新規顧客か否か
報．
．．．．
実証データ例
プロジェクト計
画書など
プロジェクト計
発注仕様書
CMMI認定情報
体制表
キャリアシート
など
要件定義書
プロジェクト計
画書
品質計画書
設計ドキュメン
ト
ソースコード
テスト計画書
など
顧客との議事
録
プロジェクト計
画書など
開発システム構成の特徴や当利用したサブシステムの安定度：利用基本設計書
該タグデータの対象とするシハードウェア、ライブラリ、OS等、調達しプロジェクト計
ステムの種類を示す情報．タたサブシステムの安定度合い（初回、不画書
グデータの解釈や分析時に必安定等）
工程管理表
要なデータ．
サブシステムの検証期間/工数：利用を勤務実績デー
検討したサブシステムの検証期間と工タ
など
数
開発システムの規模．計画値
と最終実績値とする．進捗情
報に同じ情報が含まれる場合
は，省略可．
．．．．
受注者側の想定する顧客要件の数，実基本設計書
装した要件数など
ソースコード
要件定義書
工程終了時のソースコード行数,機
能,FP,処理データ量,処理データ数などなど
．．．．
39
進捗情報の構成
•
要件定義 (3)
– ユーザヒアリング情報、規模、変更
•
設計 (3)
– 規模、変更、要件の網羅率
•
プログラミング (3)
– 規模、変更、複雑度
•
テスト (4)
– 規模、変更、密度、消化
•
品質 (8)
– レビュー状況、レビュー作業密度、レビュー指摘率、欠陥件数、欠陥対応件
数、欠陥密度、欠陥指摘率、静的チェックの結果
•
工数 (2)
– 作業工数、生産性
•
計画・管理 (4)
– プロセス管理情報、会議実施状況、累積リスク項目数、リスク項目滞留時間
•
その他の成果物 (2)
– 規模、変更
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
40
進捗情報の例
分類
項番項目名
要件定義
ユーザヒアリング情報
1
2
規模[推移]
変更[推移]
説明
具体化例
実証データ例
要件に関してユーザに行ったヒアユーザヒアリング実施件数(回)
ユーザヒアリング項目数(件)
リングに関する情報
ユーザヒアリング回答率：ユーザヒアリング回
答数÷ユーザヒアリング項目数
．．．．．
開発側で作成した要件数
画面、機能項目、ユースケース、アクター，顧
客要件，機能，FPなど
変更された要件数
規模の計測単位に依存
ユーザヒアリン
グ議事録
ユーザヒアリン
グ質問票
など
要件定義書
など
要件定義書
要件定義書の
変更履歴
など
設計成果物の規模
※新規・改造・再利用(流用)毎に
計測する
基本設計書
機能設計書
構造設計書
詳細設計書
など
3
設計
規模[推移]
4
変更[推移]
機能設計：ページ数・帳票数・画面数・ファイル
数・項目数・UML図の数、クラス数、バッチプロ
グラム数，重要な機能数など
構造設計：データ項目数，DFDデータ数，DFD
プロセス数，DBテーブル数など
．．．．．
変更された設計成果物の数，もし規模の計測単位に依存
くは変更量
5
要件の網羅率
6
......
要件定義で作成された要件の実
装率
設計に取り入れられた要件数÷要件数
基本設計書
機能設計書
構造設計書
詳細設計書
各設計書の変
更履歴
など
要件定義書
基本設計書
機能設計書
構造設計書
詳細設計書
など
41
タグの規格の策定方法
• ソフトウェアタグ規格技術委員会及びWGでの
議論
– 第1回（2007年7月9日）～
第11回（2008年7月
28日）
– タグ項目洗練のためのWG（2008年5月1日）
– 構成員１４組織 27人
• SWEBOK、CMMI、ISO/IEC15939、 SECデータ白書
等を調査
• プロセス
1. メンバーからの必要なメトリクスの提案
2. プロジェクト、プロセスの大分類とその下の中分類
の導入
3. 種々の規格との整合性チェック
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
42
ソフトウェアタグ規格技術委員会
•
•
•
•
•
•
•
•
•
•
•
•
•
富士通研究所 (Fujitsu Lab)
日立製作所 (Hitachi)
NEC
ベンダー
シャープ (SHARP)
SRA先端技術研究所 (SRA Key-Tech Lab)
東芝 (Toshiba)
NTTデータ(NTT Data)
東京証券取引所 (Tokyo Stock Exchange)
JAXA (Japan Aerospace Exploration Agency)
ユーザー
デンソー(DENSO)
IPA (Information Technology Promotion Agency, Ministry of Economy, Trade and Industry,
Japan)
政府
奈良先端科学技術大学院大学 (NAIST)
大学
大阪大学 (Osaka University)
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
43
利用モデル
タグの利用モデル
ソフトウェアの開発形態、利用形態、ユーザなどに依
存
典型例
1. 委託開発時、ユーザが開発状況を知るため
2. 重大問題発生時の原因究明や法的紛争時に、第
三者による評価を行うため
3. ソフトウェア部品等の評価を行うため
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
44
1.委託開発時の利用モデル
• 納品物の品質について検証する
発注
開発データ
記録
納品
ソフトウェア開発者
ソフトウェア発注者
ソフトウェア
プロダクト
分析
フィードバック
データ収集
添付
エンピリカル
抽出
タグ
データ
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
45
2.法的紛争時の利用モデル
• 問題の原因や責任の所在を精査する
発注
開発データ
記録
納品
ソフトウェア発注者
ソフトウェア
製品
添付
ソフトウェア開発者
分析
フィードバック
抽出
データ収集
エンピリカ
ル
タグ
データ
検査
検査
ソフトウェアライアビリティ
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
調停・仲裁人
46
3.ソフトウェア部品等の評価の利用モデル
• 再利用プロダクトの品質を検査し、選定したり、
リスクやコストを見積ったりする
再利用可能なソフトウェア
再利用プロダク
トの検索
プロダクトリポジトリ
ソフトウェア
プロダクト
ソフトウェア開発者
ソフトウェア
システム
ソフトウェア
プロダクト
ソフトウェア
プロダクト
信頼性の高い
プロダクト選定
信頼性検査
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
47
実証(エンピリカル)データ
• タグの証拠となるデータ
– 対象ソフトウェアに関する成果物や開発中に付随的
に発生する種々の生のデータ
• ソースコード、設計書、議事録、障害票、進捗表などの
データ
7,000
6,000
5,000
4,000
– 二者間で実証データの扱い協議して決める
3,000
2,000
1,000
2006/6/6
2006/6/2
2006/5/29
2006/5/25
2006/5/9
2006/5/21
2006/5/5
2006/5/17
2006/5/1
いろいろなやり方考えられよう
1. 実証データは不要
2. そのまま実証データをタグに添付する（一部のみ、全部、
…）
3. 実証データはベンダーで保管。必要に応じてユーザが見る
4. 暗号化してタグに添付。キーはベンダー保管。重大な不具
合や問題が生じたとき等の原因調査、法的紛争時に復号化
Software Engineering
Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
して開示
2006/5/13
2006/4/27
2006/4/23
2006/4/7
2006/4/19
2006/4/3
2006/4/15
2006/4/11
2006/3/30
2006/3/26
2006/3/22
2006/3/6
2006/3/18
2006/3/14
2006/3/10
0
48
タグの運用方法
• すべての項目を網羅的にタグ化されることを求
めない
• 収集データの対象物、対象範囲、粒度、収集期
間（工程）受発注者間で取り決める
• 他の項目から算出可能な数値は、項目から除外
• 収集データのタグ化のタイミング、もしくは受
注者への開示タイミングは、受発注者間の協議
により決定される
納品時、工程毎、一定時間ごと(週次、日次）など
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
49
タグのライフサイクル例
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
50
階層的なタグの定義
•
•
プロジェクトの構造 ≡ 木
（親子関係）
親プロジェクトは子プロジェクトへのリンク情報を持つ（その逆も）
メイン(親)タグ
プロジェクトID
親がない場合
は，空白(Null)
親プロジェクトID
サブ(子)タグ
サブ(子)プロジェクト数(n)
プロジェクトID
サブ(子)プロジェクト1_ID
．．．．
親プロジェクトID
サブ(子)プロジェクトn_ID
サブ(子)プロジェクト数(n)
サブ(子)プロジェクト1_ID
．．．．
サブ(子)プロジェクトn_ID
サブ(孫)タグ
プロジェクトID
親プロジェクトID
サブ(子)プロジェクト数(n)
サブ(子)プロジェクト1_ID
．．．．
サブ(子)プロジェクトn_ID51
51
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
タグフォーマットの標準化
• 多様なユーザへの開示・流通を目的として、タ
グ情報の標準フォーマット化をXMLベースで実現
SEDEX*：Software Engineering Data Exchange language
する
エンピリカル
データ
SEDEX*へ
変換
SEDEX化された
ソフトウェアタグ
タグの可視化、
評価ツール
タグの評価
受注側
発注側
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
52
今後の課題
• タグ利用シナリオの構築
– タグの具体化例の充実
• 紛争解決のためのタグ規格の実例
• タグ活用技術の研究・開発
– タグデータの収集、分析、可視化の手法とツール等
の開発
• いろいろな方面への展開
– 国内規格
– 海外規格
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
53
FAQ1: 進捗報告会議でやってることと同
じ
ほぼ同じようなことを定期的に打ち合わせで発注者に情報
開示している。ソフトウェアタグとの違いは？
• 発注者と開発者できちんと情報交換して品質を担保しよ
うとしている組織にとってはタグ項目はあたりまえ
• あたりまえでない開発が現状、多々ある。タグはそれを
防ぐための最低基準
• 各社バラバラではない、統一の基準があると普及させや
すい
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
54
FAQ2:
もっとデータが必要では？
41項目のデータだけでは十分品質を担保できないのでは？
品質改善の現場では、もっと詳細なデータ収集・分析して
いる
•当然たくさんのデータがあれば、より詳細な可視化が可
能だが、収集コスト、実現可能性などのバランスを考えて
決定
•プロジェクト規模
– 大：最低限のデータセット
– 中：標準的なデータセット
– 小：十分なデータセット
•不十分な場合は、合意の上、別途、余分なデータを追加
しても良い
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
55
FAQ3:
本当に品質向上するか？
ソフトウェアタグによってどれだけ品質向上するか、定量
的なデータあるか？上司を説得できるケーススタディーあ
るか？
• 定量的に示すことは困難
– 食品のトレーサビリティの効果は？
– CMMIの効果は？
– 地道なデータの蓄積必要
• 品質向上に寄与することは間違いない
– データ開示による開発者の緊張感
– 発注者側も責任感
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
56
FAQ4:
コスト増大にならないか？
趣旨はわかるが、実証データの収集、分析、開示のための
コストが大きく、利益を大幅に削ってしまうのではない
か？
• タグの項目の多くは、環境設定さえきちんとすれば、ほ
ぼ自動的に収集できるもの
• タグ用のデータ収集、パッケージング化ツールを使え
ば、大きなオーバーヘッドにならない
– すでに組織内のプロセス改善活動用のデータ収集とオーバー
ラップしている
– EASEプロジェクト／IPAで開発したEPM(Empirical Project Monitor)、
EASE創研
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
57
FAQ5: タグ項目の詳細がよくわからな
い
タグ項目の例は書いてあるが、いくつかの選択があるよう
で、どれを選ぶか、また、どのようなツールを使うかよく
わからない
• 規格として詳細なレベルまで規定は困難
– メトリクスの定義も論文によりけり種々ある現状
• 発注者、開発者間で、これで行きましょう、等の合意形
成が必要
• ある程度ツールが普及してくればデファクトスタンダー
ドが決まる
• ケーススタディを積極的に開示していく
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
58
FAQ6:
各種規格との関連は？
最近ソフトウェア開発や取引の透明性がいろいろ言われて
いるが、どう関連するか。
•工事進行基準等の会計基準
– ソフトウェアタグは見積の根拠となるデータになりうる
•経産省のガイドライン
情報システムの信頼性向上に関するガイドライン
情報システムの信頼性向上のための取引慣行・契約に関する研究
会～情報システム・モデル取引・契約書～
– ソフトウェアタグとは相互補完の関係
• ソフトウェアタグのようなベンダとユーザ間で情報をやり取りする
ためのメディアがあると、ガイドラインや契約書の恩恵がより明確
になる
• ガイドラインや契約書にしたがった開発が主流になれば、タグ項目
の統一が容易になるなど、ソフトウェアタグの普及が促進される
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
59
FAQ7:
世界の状況、反応は？
StagEプロジェクトと同じようことをやっているのはあるの
か？
海外での反応は？
• 同じようなことをやっているのはない
– 実証データの収集、分析に関しては多くの研究あり（ISERN、IESE
等）
– 実証データの発注者へのフィードバックに関しては、Basiliのグ
ループが試み
– 近々に実証ソフトウェア工学の研究者や実務家が参入（？）
• オフショア関係者との懇談（主に中国）
– 非常に興味を持って動向注視
– 他社との差別化の手段
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
60
StagEプロジェクト
• 文部科学省
次世代ＩＴ基盤構築のための研究開発
ソフトウェア構築状況の可視化技術の普及
２００７年８月～２０１２年３月
• 研究代表者：奈良先端科学技術大学院大学
松本健一
• 研究分担者：大阪大学井上克郎、楠本真二
奈良先端科学技術大学院大学
保浩三
飯田元、久
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
61
プロジェクト概要
背景：ソフトウェアに対する漠然とした不安
目的
現代社会はソフトウェアに多くを頼っているが，それらがどのように作
られどれだけ信頼できるか中身が見えない．
ソフトウェアの品質や由来（どのような手順
を踏んで開発されたかなど）を手軽に，正確
に示すための技術を社会に提供する．
利用するソフトが信頼で
きる作り手によってきち
んと開発され，十分な品
質を持っていることを知
りたい
一般ユーザ
注文したソフトウェアがき
ちんと管理された方法で
要求通りの品質を持って
開発されていることを確
認したい
ソフト発注者
優れた技術で高い品質
のソフトを開発している
ことを正しく評価してほ
しい
＝
ソフトウェア・トレーサビリティの実現
ソフト開発者
アプローチ：食品におけるトレーサビリティと同様の概念をソフトウェアの開発過程で実現す
る
ソフトウェアタグとは？
ソフトウェア
開発データ
収集
要約
特徴抽出
ソフトウェア
タグ
プロファイル
開発者
コ
ー
テ
設
デ
ス
ィ
計
ト
ン
グ
ソフトウェア開発過程（プロセス）
要
求
分
析
ソフトウェア
製品
発注者
ソフトウェア開発組織の
プロファイルや開発プロ
ジェクトから収集した様々
なデータを一定の形式で
整理し，ソフトウェア製品
に添付できるようにした
もの．
<23.5, 35.2, 50.7, 68.2>
<0, 2.5, 0, -0.8, 0 >
Project Information
(12 elements)
10
9
8
7
6
5
系列1
4
3
2
1
0
1
2
3
4
5
76
7
6
5
4
系列1
3
Project Information
(29 elements)
2
1
0
20
40
60
80
1
2
3
4
5
6
7
80
70
60
50
40
系列1
30
ユーザ
20
10
0
0
2
4
6
8
10
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
62
達成目標
• ソフトウェアタグの規格化と普及
• ソフトウェアトレーサビリティセンター
の開設
• アジアーオーストラリア圏研究開発共同
体の形成
• 高度ソフトウェア技術者の育成
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
63
実施体制／支援・連携体制
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
64
近年のソフトウェア工学研究雑
感
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
近年のソフトウェア工学研究雑感
SES2008のプログラムを見て、SECのある
幹部のつぶやき
プログラムはフォローしているが、重箱の隅
をつついているようで、参加する気がしない
…
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
66
重箱化
• 本当？
– 定量的に評価しようがない…
• 実務家にとって魅力が薄かった
– これは事実だろう
– しかし、ソフトウェア工学４０年の歴史で、
いつも言われ続けてきたこと
– ICSEにも同様の文句が多数の実務家からある
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
67
ソフトウェア工学魅力倍増計画
• 新しい分野への挑戦
– 大規模計算（のための｜を使った）ソフト
ウェア工学
• 並列、分散、超大規模データ収集、分析
–
…
• 打って出るソフトウェア工学技術
– 他の技術の下請け脱出を！
– SE技術を基にした新たな手法、基準、規格な
どを創出する
• 産学連携をもっと活発に！
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
68
産学連携の重要性
• ソフトウェア工学は、所詮、経済原則の
上での科学？
– 高いプロダクト品質、高いシステム性能、高
い開発効率…
• 経済感覚がないと研究の目標が定まらな
い
• 産学連携を実施することで、感覚を磨く
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
69
大学病院モデル
大学と社会との連携モデル
人的資源、シーズ
大学
研究費、
実データ、
実践知識
患者・研修医、お金、ニーズ
治療、知識やエキスパート普及
大学病院
社会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
70
実践的ソフトウェア工学ラボ
人的資源、
アイディア
実践的評価、
資金、
ニーズ
大学
実問題、
お金
問題解決
知見
人材
実践的ソフトウェア工学ラボ産業界
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
71
産学連携は難しい
• 年単位のプロセス
–
–
–
–
きっかけつかみ
お互いのメリット見つける
契約
目標、成果の達成、取り扱い
• 手間がかかる
– 論文にならない研究、実践で役立たない研究
– 科研費より効率悪い？
– いろいろな考えの産業人。一枚岩でない。振り回さ
れる
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
72
産学連携のコツ
• 営業が大事
– 持っている技術をわかりやすく説明
– 使えるかどうかは向こうの判断。こっちには予測不
可能
• 対等なパートナーシップ
– Give and take の関係、お互いの目標、利益を尊重
– 打ち合わせに出向くのも交互
• 日本流の礼節、付き合い
– あいさつ
– 年度末報告
…
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
73
産学連携のメリット
• 少々の手間を超えるメリット
– 研究のネタ（ニーズ）の発見
– 産業界の動き把握
– 実践的な研究評価ができる
• 論文の時の強みになる
SEは、世の中の役にたってこそ存在価値あり
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
74

Download Report