スライド 1

Size: px

Start display at page:

Download "スライド 1"

もえりこやぎ
5 years ago
Views:

1 品質評価フレームワーク奈良先端科学技術大学院大学情報科学研究科松本健一 1

2 代表的なフレームワーク JISX ソフトウェア製品の品質第 1 部 : 品質モデル ( ISO/IEC :2001, Software engineering Product quality Part 1: Quality model) Goal/Question/Metrics(GQM) モデル JIS X0141:2004 ソフトウェア測定プロセス ( ISO/IEC 15939:2002, Software engineering Software measurement process.) 2 2

3 JISX ソフトウェア製品の品質第 1 部 : 品質モデルソフトウェアの持つ品質特性を 3 つの観点内部品質, 外部品質, 利用時品質で整理し, 個々の特性の定義を与えている. 参考 URL 26.pdf 3 3

4 品質評価モデル利用結果への期待利用時品質要求利用及び反映利用時品質利用時メトリクスシステムの振る舞い外部品質要求妥当性確認外部品質外部メトリクスソフトウェア属性内部品質要求検証内部品質内部メトリクス 4 4

5 利用時品質特性有効性 (Effectiveness) 利用者が指定された利用の状況で, 正確かつ完全に, 指定された目標を達成できるソフトウェア製品の能力. 生産性 (Productivity) 利用者が指定された利用の状況で, 達成すべき有効性に対応して, 適切な量の資源を使うことができるソフトウェア製品の能力. 安全性 (Safety) 満足性 (Satisfaction) 利用者が指定された利用の状況で, 人, 事業, ソフトウェア, 財産又は環境への害に対して, 容認できるリスクの水準を達成するためのソフトウェア製品の能力. 指定された利用の状況で, 利用者を満足させるソフトウェア製品の能力. 5 5

6 外部内部品質特性機能性 (Functionality) 指定された条件の下で利用されるときに, 明示的及び暗示的必要性に合致する機能を提供するソフトウェア製品の能力. 信頼性 (Reliability) 指定された条件下で利用するとき, 指定された達成水準を維持するソフトウェア製品の能力. 使用性 (Usability) 指定された条件の下で利用するとき, 理解, 習得, 利用でき, 利用者にとって魅力的であるソフトウェア製品の能力. 効率性 (Efficiency) 明示的な条件の下で, 使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力. 保守性 (Maintainability) 修正のしやすさに関するソフトウェア製品の能力. 移植性 (Portability) ある環境から他の環境へ移すためのソフトウェア製品の能力. 6 6

7 外部内部品質副特性機能性 (Functionality) 合目的性正確性相互運用性セキュリティ機能性標準適合性信頼性 (Reliability) 成熟性障害許容性回復性信頼性標準適合性使用性 (Usability) 理解性習得性運用性魅力性使用性標準適合性効率性 (Efficiency) 時間効率性資源効率性効率性標準適合性保守性 (Maintainability) 解析性変更性安定性試験性保守性標準適合性移植性 (Portability) 環境適応性設置性共存性置換性移植性標準適合性 7 7

8 品質特性間の関係機能性 (Functionality) 信頼性 (Reliability) 有効性 (Effectiveness) 使用性 (Usability) 生産性 (Productivity) 効率性 (Efficiency) 安全性 (Safety) 保守性 (Maintainability) 満足性 (Satisfaction) 移植性 (Portability) 8 8

9 Goal/Question/Metric(GQM) モデル V. R. Basili らによって提案された総合的なソフトウェア測定の枠組み測定目的とメトリクスの対応関係を明確にする. 測定原理測定はトップダウンで行われるべきである.( まず測定の目標があって, その目標を遂行するために尺度が定義され, 測定が行われなければならない.) データ分析は何らかの目的や仮説に基づいて行われるべきである. 参考文献 V. R. Basili and D. M. Weiss: A methodology for collecting valid software engineering data, IEEE Transactions on Software Engineering, Vol.SE-10, No.6, pp ,

10 3 層構造測定の目標 Goal Goal Goal を評価, あるいは, 達成する方法 Question Question Question Question Question Question に定量的に答えるためのデータ集合 Metric Metric Metric Metric Metric Metric 10 10

11 Goal( 目標 : 概念レベル ) 計測の目標を計測対象計測理由品質モデル視点環境に基づいて明確にしたもの

12 Question( 質問 : 操作レベル ) 特定のGoalを評価, あるいは, 達成する方法を明確にしたもの. 計測対象 ( プロダクト, プロセス, 資源 ) の特性を品質の観点から明らかにすることができる

13 Metric( 尺度 : 量的レベル ) Questionに定量的に答えるためのデータの集合. データは, 客観的データと主観的データに分かれる. 客観的データ : 計測対象のみに依存し, 計測の観点には依存しないデータ. 例 : ドキュメントのバージョン数, 作業工数, プログラムサイズ, 主観的データ : 計測対象と視点の両方に依存するデータ. 例 : テキストの信頼性, 顧客満足度のレベル, 13 13

14 GQM 適用プロセス 1. Goalの設定 2. Questionの生成 3. Metricの明確化 4. データ収集法の開発 5. データの収集, 妥当性確認, 分析 6. データの事後分析 14 14

15 Goal 作成用テンプレート ( タイプ A) 目的 : 計測対象( プロダクト, プロセス, 資源 ): 設計ドキュメント, テスト工程, 保守担当者, の理由: 特徴付け, 評価, 予測, 動機付け, 改善, を行うために, 観点 : その焦点 : コスト, 正しさ, バグ率, 変更回数, 信頼性, 使いやすさ, 適時性, を視点: ユーザ, 管理者, 開発担当者, 開発組織, の立場から, 環境 : コンテキスト: パイロットプロジェクト, 実プロジェクト, 開発現場, 実験室, において分析する

16 タイプ A テンプレートによる Goal 作成例目的 : 設計ドキュメントの特徴付けを行うために, 観点 : その正しさ ( ユーザ要求を正確にもれなく実現しているかどうか ) をユーザ, 開発者, およびテスト実施者の立場から, 環境 : 我々の開発環境において分析する

17 Goal 設定に必要な情報組織の方針や戦略論点や目的プロダクト, プロセス, 組織の定義対象組織のモデル視点 17 17

18 Question の主要パターン対象( プロダクト, プロセス, 資源 ) そのものを目的から見て明確にするための質問. ソフトウェアの修正依頼に対する現在の処理速度は? 対象の属性を観点( 視点 ) から見て明確にするための質問修正依頼の実際の処理時間は, 予想とどれくらい食い違っていますか? 対象の特徴を観点 ( 視点 ) から見て評価するための質問修正依頼の処理能力はプロジェクトマネージャから見て満足のいくものですか? 18 18

19 Metric 設定上の注意点既存データの量と質信頼できる既存データが存在する場合には, できるだけ利用する. 計測対象の成熟度形式的に定義でき計測方法もある程度確立されている対象に対しては客観的尺度を用いる. 形式的な定義が現段階では難しく, 計測方法も確立されていない対象に対しては, 主観的尺度を用いる. 学習 GQM モデルは常に洗練し, さまざまな場合に適応させていく必要がある. 特定の Question に答えるためだけの尺度でなく,GQM モデルの信頼性評価にも役立つ尺度を用いる

20 GQM 構築例 with Prof. Basili Goal あるプロジェクトにおいて, プロジェクトマネージャの視点から, 不安定な要求不完全な設計劣悪なコード品質について評価する

21 GQM 構築例 with Prof. Basili Model (Question) if ( FCM > 1 and (LCC/LOC > 5%) and (60% of bug reports have Change Request class ) then 要求が不安定である. if ( FCM > 1 and ((LCC/LOC > 5%) or (ONR for 25% of files is >1)) then 設計が不完全である. if ( FCM > 1 and (# of bug)/kloc > 10 ) then コード品質が悪い. Metric FCM: ファイル変更回数 LCC: ファイル変更行数 ( 追加行数 + 削除行数 0.1) LOC: ファイル行数 ONR: ファイル変更者数 21 21

22 JIS X0141:2004 ソフトウェア測定プロセスプロジェクト固有の情報モデル ( 測定情報モデル ) を明らかにし, それに基づく一連の測定プロセスの遂行を通して, プロジェクトの意思決定者の情報ニーズを定義し, 優先順位付けする. 参考文献 JIS X0141:2004, ソフトウェア測定プロセス. ( ISO/IEC 15939:2002, Software engineering Software measurement process.) J. McGarry, D. Card, C. Jones, B. Layman, E. Clark, J. Dean, F. Hall, Practical Software Measurement: Objective Information for Decision Makers, Addison-Wesley, 古山恒夫富野壽監訳, 実践的ソフトウェア測定, 共立出版,

23 測定情報モデルの 5 つのレベル情報ニーズ ( プロジェクト管理, 品質保証, ) 情報成果物情報ニーズを満足する測定結果指標分析結果を表す値が割り当てられる変数導出測定量 ( 尺度 ) ( 複数の ) 基本測定量から導出される値が割り当てられる変数基本測定量 ( 尺度 ) 単一の属性を表す値が割り当てられる変数実体 ( ソフトウェアやその開発過程 ) 属性情報ニーズに関連する, ソフトウェアやその開発過程の特性 23 23

24 詳細構造情報成果物解釈モデル判断基準指標分析モデル導出測定量測定関数導出測定量基本測定量測定方法基本測定量測定方法属性属性 24 24

25 構築例情報成果物コーディングの進捗状況に問題はないか解釈モデル if 0.9 コーディング完了率 1.1 then OK else NG 現状が予定の ±10% 内なら異常なし判断基準指標分析モデルコーディング完了率完成モジュール数 / 完了予定モジュール数完了予定モジュール数導出測定量導出測定量完成モジュール数完了予定日の過ぎたモジュール数の算出測定関数測定関数全モジュールの完成度を単純合計モジュール毎の完了予定日 ( 計画上 ) 基本測定量基本測定量測定方法モジュール完成度 (0.0~1.0) モジュール毎に完成度を担当者が主観評価属性コーディング状況 25 25

データ収集分析の分担明確化への応用判断基準情報成果物解釈モデル導出測定量測定関数指標分析モデル発注組織 X の担当受注組織 A の担当導出測定量インターフェースポイント各組織の技術力, コスト, 信頼度などに基づいて決定する. ( 受注組織の技術力が高く信頼できるのなら, より上位に設定できる.

26 データ収集分析の分担明確化への応用判断基準情報成果物解釈モデル導出測定量測定関数指標分析モデル発注組織 X の担当受注組織 A の担当導出測定量インターフェースポイント各組織の技術力, コスト, 信頼度などに基づいて決定する. ( 受注組織の技術力が高く信頼できるのなら, より上位に設定できる.) 基本測定量測定方法属性基本測定量測定方法属性受注組織 B の担当 M. Katahira, K. Matsumoto: Valuebased software measurement in safety-critical system, Proc. Australian Conference on Software Measurement 2005,

27 応用例情報成果物コーディングの進捗状況に問題はないか現状が予定の ±10% 内なら異常なし判断基準完了予定モジュール数完了予定日の過ぎたモジュール数の算出モジュール毎の完了予定日 ( 計画上 ) 解釈モデル if 0.9 コーディング完了率 1.1 then OK else NG 指標コーディング完了率例えば分析モデル, 受発注を伴うソフトウェア開発において完成モジュール数 / 完了予定モジュール数, 受注側のデータ収集分析が高い場合, コーディング導出測定量完了率の算出に必要なデータの収集は任せる導出測定量完成モジュール数. 全モジュールの完成度を測定関数発注側のメリット測定関数 : コスト削減単純合計受注側のメリット : 開発ノウハウ保護基本測定量基本測定量モジュール完成度 (0.0~1.0) 測定方法モジュール毎に完成度を担当者が主観評価属性コーディング状況 27 27

28 メトリクス, マイニング技術との統合 Data-driven 分類基準, 推定値, ルール, 尺度アソシエーション分析マハラノビスタグチシステム多次元尺度構成法類似度可視化事例ベース推定 ( 協調フィルタリング ) 多変量解析法統合分析属性値, 評価値,... 分析モデルコンポーネントランク (SPARS-J) ロジカルカップリングコードクローン直交欠陥分類法 ISO 測定情報モデル GQM モデル Goal-driven 28 28

29 GQM 上での統合例 Model(Question) if ( FCM > 1 and (LCC/LOC > 5%) and (60% of bug reports have Change Request class ) then 要求が不安定である. if ( FCM > 1 and ((LCC/LOC > 5%) or (ONR for 25% of files is >1)) then 設計が不完全である. if ( FCM > 1 and (# of bug)/kloc > 10 ) then コード品質が悪い. アソシエーション分析で抽出したルールを利用 Metric FCM: ファイル変更回数 LCC: ファイル変更行数 ( 追加行数 + 削除行数 0.1) LOC: ファイル行数 ONR: ファイル変更者数 MTシステムで構築した尺度, 事例ベース推定値を利用 29 29

30 ISO 測定情報モデル上での統合例情報成果物解釈モデルアソシエーション分析で抽出した判断基準ルールを利用指標分析モデル導出測定量 MTシステムで構築した尺度を利用導出測定量測定関数基本測定量事例ベース推定を利用基本測定量測定方法測定方法収集データやメトリクス値を利用属性属性 30 30

COSEにおける上流工程分析の提案と事例報告

COSEにおける上流工程分析の提案と事例報告 COSEEASE STAGE GQM NAIST-IS-TR2007005, March 2007 1 2 etc. etc. () etc. 3 CVS Ver0.1 Ver0.N Ver1.0 N Ver0.1 Excel Ver0.N 4 DiffDoc) = = = 5 (DiffDoc) 6 Ver1,1 Ver1.2 Ver1.1Ver1.2 7 () etc. etc. () 8 B