ソフトウェア品質の第三者評価のための基盤技術 -ソフトウェア … ·...
TRANSCRIPT
Copyright © 2014 Nara Institute of Science and Technology
ソフトウェア品質の第三者評価のための基盤技術-ソフトウェアプロジェクトトモグラフィの開発-
奈良先端科学技術大学院大学情報科学研究科
ソフトウェア工学研究室
松本健一
Copyright © 2014 Nara Institute of Science and Technology
2
自己紹介
奈良先端科学技術大学院大学情報科学研究科,ソフトウェア工学研究室教授 HP: http://se-naist.jp/
研究分野:ソフトウェア工学 ソフトウェア解析,ソフトウェアメトリクス
ソフトウェア開発の定量的管理
ソフトウェア計測環境
最近の主な共同研究先,学生交流先 大阪大,九州大,和歌山大,近畿大,奈良高専,…タイ・カセサート大,フィンランド・オウル大,米国・ハワイ大,カナダ・クィーンズ大,中国・香港城市大,…
日立製作所,NTT西日本,東芝,経済調査会,JAXA,…
Copyright © 2014 Nara Institute of Science and Technology
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).
Copyright © 2014 Nara Institute of Science and Technology
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) x 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)
Copyright © 2014 Nara Institute of Science and Technology
5
背景ソフトウェア開発における「情報の非対称性」
ソフトウェア品質そのものや品質に大きな影響を与える開発過程の情報の多くはベンダのみが知り得る.(ユーザとベンダで,知り得る情報量に大きな差がある.)
引き起こされる問題 逆選択:ユーザは低品質なソフトウェアしか選べなくなる.
モラル・ハザード:ベンダは手抜きや虚偽報告をしがちになる.
対策 シグナリング:ベンダがユーザに積極的に情報を発信する.
スクリーニング:ベンダの自発的行動を読み取って選別する.
制度と組織:認証制度や監視制度を整備する.
「情報の非対称性」については 【IT経済基礎講座】篠崎彰彦教授のインフォメーション・エコノミー,ソフトバンク ビジネス+IT http://www.sbbit.jp/article/cont1/18480 を参考にしました.
Copyright © 2014 Nara Institute of Science and Technology
6
技術開発の目的
ソフトウェア品質の第三者評価のための技術基盤をソフトウェアユーザ・ベンダに提供する.(ソフトウェア開発における「情報の非対称性」を解決するための「シグナリング」技術基盤をベンダに提供する.)
ソフトウェア開発データを第三者評価に適した形態に再構成するための枠組みの構築.
再構成されたデータを解析する「技術・ツール」の開発
技術・ツールの利用方法を明示する「シナリオ」の提供
Copyright © 2014 Nara Institute of Science and Technology
7
ソフトウェア開発データの再構成がなぜ必要か.
今日,多くのソフトウェア開発プロジェクトでは,開発管理システム(構成管理システム,工程管理システム,不具合管理システム,…)が導入されており,それらシステムには,開発状況を表す定量データ(開発データ)が蓄積されている.
Copyright © 2014 Nara Institute of Science and Technology
8
ソフトウェア開発データの再構成がなぜ必要か.
しかし,開発データを解析しようとすると,データの取得と整形に多くの工数を要する. 解析工数の95%は,プロジェクトデータの取得と整形に費やされる.
2010年に米国で発生したトヨタ車の急加速問題では,ソフトウェアとその開発過程の検証に10ヶ月を要した.
A. Mockus, “How to run empirical studies using project
repositories”, Proc. of 4th International Advanced School of
Empirical Software Engineering (IASESE 2006), Sep. 2006.
Copyright © 2014 Nara Institute of Science and Technology
9
データの取得・整形に多くの工数がなぜ必要か.
開発データは,(第三者による)ソフトウェアとその開発過程の評価のために蓄積されているわけではない.
開発管理システムでは,コスト超過,スケジュール遅延,品質低下といった,開発リスクを検知し,対処するため開発データが用いられる.
開発リスクが解決・回避されれば,開発データは不要となる.
ソフトウェアとその開発過程の評価の目的は,開発リスクの原因究明と再発防止である.
原因究明と再発防止には,要素技術として
プロジェクト全体の俯瞰
プロジェクト構成要素(間)の傾向や関係性の顕在化・評価
仮説の生成・検証
が不可欠で,データの一貫性,完全性,信頼性等の確認も必要となる.
Copyright © 2014 Nara Institute of Science and Technology
10
「ソフトウェア品質の第三者評価」のスコープ
プロセス実施の妥当性 (開発)プロセスは規定通りに実施されているか.
プロセスを構成するタスクやアクティビティは確実に実施されているか.
採用規格・技術の妥当性 (開発に際して)採用した規格や技術は適切か.
採用した技術は適切に利用されているか.
従事者の妥当性 (開発)従事者のスキルや適性は適切か.
利用者・利用状況との妥当性 利用者や利用状況の情報は適切に収集・利用されているか.
利用者に対してそれら情報は適切に提供されているか.
情報処理推進機構,“ソフトウェアの品質説明力強化のための制度フレームワークに関する提案(中間報告)”,平成23年9月.【一部加筆修正】
Copyright © 2014 Nara Institute of Science and Technology
11
ソフトウェアプロジェクトトモグラフィ技術Software Project Tomography (SPT)
医療におけるコンピュータ断層撮影CTを,ソフトウェア品質の第三者評価に適したデータ構造を考える上でのモデルとする.
ソフトウェア開発プロジェクトをからだに見立て,プロジェクト開始から終了(あるいは,現時点)までのいくつかの時点において,プロジェクトの状況を定量的に表すスナップショットを断面画像のように作成する.
断面画像の系列から身体の3次元モデルを再構成するように,スナップショットの系列によって,プロジェクトの全体像,および,ソフトウェアやその品質が実現される過程(プロセス)を表す.
Copyright © 2014 Nara Institute of Science and Technology
12
ソフトウェアプロジェクトトモグラフィ技術
ソフトウェア開発プロジェクトを「スナップショットの系列」で表現する. スナップショット= ソフトウェア開発データ
+解析結果+ソフトウェアプロダクト断片
開発データ(リポジトリ)
ソフトウェアプロジェクト
要件 作業 組織 プロダクト 課題
構成管理システム 工程管理システム 不具合管理システム
構成管理データ 工程管理データ 不具合管理データ
・・・
・・・
スナップショットの系列
プロジェクトの実体
マネージド・データとして表現されたプロジェクト
スナップショットの集合体として表現されたプロジェクト
時間の進行
Copyright © 2014 Nara Institute of Science and Technology
13
開発データ(リポジトリ)
ソフトウェアプロジェクト
要件 作業 組織 プロダクト 課題
構成管理システム 工程管理システム 不具合管理システム
構成管理データ 工程管理データ 不具合管理データ
・・・
・・・
スナップショットの系列
プロジェクトの実体
マネージド・データとして表現されたプロジェクト
スナップショットの集合体として表現されたプロジェクト
時間の進行
スナップショットプロトタイプ
Copyright © 2014 Nara Institute of Science and Technology
14
3つの基本機能
スナップショット生成 解析
Project DB
•Redmine
•Trac
•MS Project
•EPM,…
Product DB
•CVS
•SVN
•git …
Ma
pp
er
(半自動)
Re
triev
er
(スクリプト)
プロジェクト構造モデル
要件
作業
組織
プロダクト
課題
プロダクト断片
要件項目
ソースコード
不具合票
作業記録
プロジェクト定義書
テストデータ
・・・
・・・
一次解析結果
一次解析ツールライブラリ
スナップショット
クラウド型開発管理環境
総合解析ツールライブラリ
可視化
可視化統合プラットフォーム(リプレイヤ拡張)
可視化ツールライブラリ
(スタンドアロン)
要素モデル
ビューコレクション
推移
分布
特長抽出
相関解析
・・・
要素モデル
要素モデル
・・・
スナップショット生成 スナップショット解析
スナップショット可視化
Copyright © 2014 Nara Institute of Science and Technology
15
ペイン
要素技術要件 作業 組織 プロダクト 課題
全体の俯瞰
傾向・関係性の顕在化・評価
仮説の生成・検証
ケーススタディ
階層的可視化分析ツールHCEを用いた仮説生成
非機能要件
キーワード自己組織化マップ
特性レーダーチャート
低品質モジュール予測
ソースコード修正Treemap
開発行動記録システムTaskpit
作業時間サマリー
作業時間フィードバック
ソースコードメトリクスTreemap
UCIソースコード
データセットに基づく基準値
コミュニケーション分析に基づく
組織構造グラフ
中心性メトリクス
Copyright © 2014 Nara Institute of Science and Technology
16
スナップショットに基づく「全体の俯瞰」
ある時点の俯瞰 RFP上の非機能要件
ある期間を対象とした俯瞰 ソースコード修正
プロジェクトを通しての俯瞰 コミュニケーション分析に基づく組織構造グラフ
Copyright © 2014 Nara Institute of Science and Technology
17
ケーススタディ:ある時点における俯瞰例
RFP上の非機能要件
非機能要件にマッピングされたキーワード間の類似性を自己組織化マップにより示す.
テキストマイニングのためのフリーソフトKH Coderを使用
Copyright © 2014 Nara Institute of Science and Technology
18
ケーススタディ:ある期間を対象とした俯瞰例
ソースコード修正
ある期間内に行われたソースコード修正作業量をTreemap
により示す. Step 1:ソースコードをコンポーネントごとに
色分け表示.面積は,修正作業量に比例.
Step 2:あるコンポーネントを担当者ごとに色分け表示.面積は,修正作業量に比例.明度は,担当作業量に比例.(担当チケット数で算出.暗いほど「いそがしい」)
Ben Fryが公開しているTreemapライブラリを使用
Copyright © 2014 Nara Institute of Science and Technology
19
ケーススタディ:プロジェクトを通しての俯瞰例
コミュニケーション分析に基づく組織構造グラフ
Apacheプロジェクト, 1ヶ月毎
Copyright © 2014 Nara Institute of Science and Technology
20
ケーススタディと第三者評価との関係
評価対象
要素技術
第三者評価に求められるスコープ*品質
プロセス実施 採用規格・技術 従事者
傾向・関係性の顕在化・評価
内的妥当性Internal
Validity
外的妥当性External
Validity
仮説の生成・検証
非機能要件特性レーダーチャート
コミュニケーション中心性メトリクス
ソースコードメトリクス基準値作成
低品質モジュール予測
Taskpit
作業時間フィードバック
* 情報処理推進機構,“ソフトウェアの品質説明力強化のための制度フレームワークに関する提案(中間報告)”,平成23年9月.【一部加筆修正】
階層的可視化分析ツールHCE
を用いた仮説生成
Copyright © 2014 Nara Institute of Science and Technology
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ヶ月前
Eclipse platform ver.3.2 開発プロジェクト
予測モデル構築
Copyright © 2014 Nara Institute of Science and Technology
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)
ケーススタディ:傾向・関係性の顕在化・評価
コミュニケーション中心性メトリクス
組織構造グラフによる俯瞰だけでは「プロジェクト理解」は難しいので,2つの中心性メトリクスで評価する.
メトリクス計測
次数中心性組織内コミュニケーションの活発さを表す.
媒介中心性メンバーが扱う情報・リソース量を表す.
開発者
ユーザ
コーディネータ
コーディネータ
ユーザ開発者
組織内でのコミュニケーションが活発になると,コーディネータの負担がそれに比例して増大する傾向にあることが分かる.(開発者の負担はそれほど増えない.)
組織内でのコミュニケーションが活発になると,コーディネータの負担がそれに比例して増大する傾向にあることが分かる.(開発者の負担はそれほど増えない.)
Copyright © 2014 Nara Institute of Science and Technology
23
ケーススタディ:傾向・関係性の顕在化・評価
低品質モジュール予測
2004/08から1年間のデータでランダムフォレスト法で予測モデルを構築
2005/08から1年間のデータに対して,開発終了の9ヶ月,6ヶ月,3ヶ月前の時点で予測
学習用(モデル構築用)プロジェクト(1年間) 予測対象(モデル適用)プロジェクト(1年間)
Eclipse platform ver.3.1 開発プロジェクト
予測に基づくスナップショット(低品質モジュール群)
終了時9/6/3ヶ月前予測モデル
終了時9/6/3ヶ月前
Eclipse platform ver.3.2 開発プロジェクト
予測モデル構築
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ヶ月前 開発終了時
Copyright © 2014 Nara Institute of Science and Technology
24
内的妥当性 コミュニケーション中心性メトリクス
Taskpit作業時間フィードバック
低品質モジュール予測
外的妥当性 ソースコードメトリクス基準値作成
非機能要件特性レーダーチャート
スナップショットに基づく「傾向・関係性の顕在化・評価」
UCI ソースコードデータセット
計測値
基準値
メトリクス計測
基準値作成
比較Treemap化
基準値作成
基準値
評価対象ソフトウェア開発プロジェクトRFP(非機能要件)で高評価が得られたプロジェクト
0
0.5
1
1.5
2
2.5
3
3.5
4運用テスト
運用開始条件の明確化
運用容易性
稼働率目標
稼働品質性能
異常検知条件
セキュリティ対策
異常中断時の処理機能
冗長化障害予防
災害対策
問題点把握及び修正分析
保守容易性
サービス提供時間
ライセンス保守
障害対応
導入教育
基準値 プロジェクトD
Copyright © 2014 Nara Institute of Science and Technology
25
ケーススタディ:傾向・関係性の顕在化・評価
ソースコードメトリクス基準値作成
UCIソースコードデータセット:利用プロジェクト数 12,191
コードクローン以外の計測では,LOCが1,000未満のプロジェクトを除外したので,利用プロジェクト数は10,087
計測メトリクス数 45
基準値例 上限値:第三四分位+1.5×(第三四分位-第一四分位)下限値:第一四分位+1.5×(第三四分位-第一四分位)
UCI
ソースコードデータセット
計測値
基準値
メトリクス計測
基準値作成
比較Treemap化
基準値作成用プロジェクト 評価対象プロジェクト OSS 5プロジェクト
Copyright © 2014 Nara Institute of Science and Technology
26
ケーススタディ:傾向・関係性の顕在化・評価
ソースコードメトリクス基準値作成
評価対象プロジェクト JHotDraw (16バージョン) サイクロマティック複雑度の最大値がVersion 7.0.9で上限値を超過.
同値が急上昇したファイルをTreemap
で確認.
Ver.7.08 Ver.7.09
Copyright © 2014 Nara Institute of Science and Technology
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点
Copyright © 2014 Nara Institute of Science and Technology
28
ケーススタディ:傾向・関係性の顕在化・評価
非機能要件特性レーダーチャート
非機能要件評価シートの作成 ベースとした3つのガイドライン
開発段階
JUAS「非機能要求仕様定義ガイドライン」
保守・運用・サービスレベルアグリーメント
IPA「情報システム調達のための技術参照モデル(TRM)」
日経ソリューションビジネス編 「システム構築のトラブルを回避するためのITシステム契約締結の手順とポイント」
ユーザにとって重要な非機能要件の抽出
IPA「プロダクト品質メトリクスWG 実施内容 ―ソフトウェアメトリクス高度化プロジェクト」
非機能要件の構造化
IPA-SEC 「共通フレーム2007」
JUAS 「ソフトウェア開発管理基準に関する調査報告書」
Copyright © 2014 Nara Institute of Science and Technology
29
ケーススタディ:傾向・関係性の顕在化・評価
非機能要件特性レーダーチャート
ケーススタディ 対象プロジェクト
大学,病院,官公庁,地方自治体,独立行政法人など.ベンダ候補企業向けの入札情報としてWWW上で公開している29件.
特性評価者
システム発注・開発に10年以上携わってきたエキスパート1名.
基準値作成
基準値
評価対象ソフトウェア開発プロジェクトRFP(非機能要件)で高評価が得られたプロジェクト
0
0.5
1
1.5
2
2.5
3
3.5
4運用テスト
運用開始条件の明確化
運用容易性
稼働率目標
稼働品質性能
異常検知条件
セキュリティ対策
異常中断時の処理機能
冗長化障害予防
災害対策
問題点把握及び修正分析
保守容易性
サービス提供時間
ライセンス保守
障害対応
導入教育
基準値 プロジェクトD
Copyright © 2014 Nara Institute of Science and Technology
30
ケーススタディ:傾向・関係性の顕在化・評価
非機能要件特性レーダーチャート
総合評価が60点以上(100点満点)となったのは2プロジェクトのみ.
総合評価トップ3の各特性の平均評価点を基準値として,レーダチャートを作成. 改善が必要な特性がより明確に.
0
0.5
1
1.5
2
2.5
3
3.5
4運用テスト
運用開始条件の明確化
運用容易性
稼働率目標
稼働品質性能
異常検知条件
セキュリティ対策
異常中断時の処理機能
冗長化障害予防
災害対策
問題点把握及び修正分析
保守容易性
サービス提供時間
ライセンス保守
障害対応
導入教育
基準値 プロジェクトD
10
20
30
40
50
60
自治体基幹情報システム
政府機関情報システム
大学情報システム
病院情報システム
図書情報システム
0
Copyright © 2014 Nara Institute of Science and Technology
31
階層的可視化分析ツールHCEを用いた仮説生成
スナップショットに基づく「仮説の生成・検証」
課題(不具合)データ約7,000件
11項目
比較HCE
知識あり・なし被験者による仮説生成
仮説
学術論文
法則関係性
Eclipse Platform開発プロジェクト
Copyright © 2014 Nara Institute of Science and Technology
32
ケーススタディ:仮説の生成・検証
階層的可視化分析ツールHCEを用いた仮説生成
HCE: Hierarchical Clustering Explorer
可視化方式:Ranked-by-feature framework
ヒストグラム
階層的クラスタリング
散布図
Copyright © 2014 Nara Institute of Science and Technology
33
ケーススタディ:仮説の生成・検証
階層的可視化分析ツールHCEを用いた仮説生成
仮説生成実験 対象データ(HCEへの入力データ)
Eclipse Platformの不具合報告データ:約7000件,11項目(変数)
方法
OSS開発についての知識を持つ被験者と,持たない被験者の2グループが生成した仮説の量と質を比較.
主要学術論文誌・国際会議で既出の法則・関係性に合致する仮説を有用とする.
被験者持ち時間:1時間
被験者
知識あり:学生3名,知識なし:学生3名
項目(変数) 詳細
AssignTime 修正者が決定するまでの時間
Fixtime 修正されるまでの時間
Priority 優先度
Severity 重要度
CCCount メーリングリストの登録者数
Comment コメントの総文字数
Attachcount 添付ファイルの数
Descriptionword 記述情報の文字数
reporter 報告者の名前
fixer 修正者の名前
component 不具合が発生したコンポーネント名
Copyright © 2014 Nara Institute of Science and Technology
34
ケーススタディ:仮説の生成・検証
階層的可視化分析ツールHCEを用いた仮説生成
生成された仮説数 知識なし被験者:計8件.うち,有用な仮説 2件.
知識あり被験者:計18件.うち,有用な仮説 4件.
生成された仮説例
「課題が報告されてから担当者に割り当てられるまでの時間」と「課題が割り当てられてから解決されるまでの時間」は反比例する.
(課題対応プロセスの実施・適用技術の妥当性評価につながる)
対象ソフトウェアの知識が十分でない場合でも,有用な仮説を生成することが可能.
Copyright © 2014 Nara Institute of Science and Technology
35
まとめ:ソフトウェアプロジェクトトモグラフィ技術
ソフトウェア品質の第三者評価のための技術基盤
(「情報の非対称性」を解決するための「シグナリング」技術)
ソフトウェア開発データを第三者評価に適した形態に再構成するための枠組みの構築
スナップショット:プロジェクトの状況を定量的に表す断面画像
ソフトウェア開発データ+解析結果+ソフトウェアプロダクト断片
再構成されたデータを解析する技術・ツールの開発
ケーススタディ:俯瞰,傾向・関係性の顕在化・評価,仮説の生成・検証
技術・ツールの利用方法を明示するシナリオの提供
(現在,開発中)
Copyright © 2014 Nara Institute of Science and Technology
36
謝辞
本発表は,独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター(現,ソフトウェア高信頼化センター)が実施した「2012年度ソフトウェア工学分野の先導的研究支援事業」の公募による採択を受けて奈良先端科学技術大学院大学情報科学研究科(研究責任者 松本健一)が実施した研究の成果の一部を取りまとめたものです.
同研究の成果報告書は,
http://www.ipa.go.jp/files/000026806.pdf
からダウンロード可能です.