SlideShare una empresa de Scribd logo
1 de 34
Descargar para leer sin conexión
メトリクスを用いたソフトウェア品質定量
評価・改善
早稲田大学
グローバルソフトウェアエンジニアリング研究所

所長・鷲崎 弘宜

TS-#
TS-7

1
鷲崎 弘宜(わしざきひろのり)
http://www.washi.cs.waseda.ac.jp/
再利用と品質保証を中心にソフトウェアエンジニアリングの研究、教育、社会展開
• 早稲田大学グローバルソフトウェアエンジニアリング研究所 所長
• 早稲田大学基幹理工学部情報理工学科准教授
• 国立情報学研究所客員准教授
• 論文: ICSE, ICSR, ASE, ARES, Agile, SPLC, SEKE, PLoP他
対外活動
• ETロボコン本部 審査アドバイザ
• 日本科学技術連盟ソフトウェア品質管理研究会副委員長
• 電子情報通信学会ソフトウェアサイエンス研究会幹事
• ISO/IEC JTC1 SC7 WG20 国内委員会主査
• SEMAT Japan Chapter Chair
• IEEE CS Japan Chapter Secretary
• 運営: ASE, ICST, SEKE, ICMT, XP, PROFES, APSEC, PLoP, AsianPLoP他
執筆など
• 『演習で学ぶソフトウェアメトリクスの基礎』『ソフトウェア品質知識体系
SQuBOK』『ソフトウェアパターン入門 – 基礎から応用へ -』
• 『AspectJによるアスペクト指向プログラミング入門』ほか
TS-#
TS-7

2
本チュートリアルの目標
• メトリクスの基本概念と主要なもの、および落と
し穴を理解する
• GQM(Goal-Question-Metric)法の基礎を理
解し、自分なりの価値観を得る
• 事例を通じてGQM法の適用に基づくゴール指
向のソフトウェア品質の測定評価と改善の流れ
を理解する

TS-#
TS-7

3
目次
•
•
•
•

メトリクスの基本概念
主要なメトリクス: 規模,複雑さ,欠陥
GQMによるゴール指向な測定
GQMを用いた組込みソフトウェア
品質改善事例
• まとめ

TS-#
TS-7

4
メトリクス(Metric / Metrics)
• 測定の方法と尺度
– 方法: 属性(測定可能な特徴)の尺度上の値や分類への
対応付け
– 尺度: 値や分類の集合

• 測定できない事柄は、管理できない(T. DeMarco)
– ソフトウェア工学 = ソフトウェアの開発、運用、および保
守に対する系統的で規律に基づいた定量的アプローチ
[SWEBOK]
– Prj成功率 31% → 定量的評価導入Prj 46% [矢口08]
メトリクス
測定方法
……
……
……

測定尺度

測定プロセス

測定結果
(値、分類)

[SWEBOK] 松本吉弘 監訳: ソフトウェアエンジニアリング基礎知識体系―SWEBOK2004, オーム社, 2005.
[矢口08] 矢口竜太郎, 吉田洋平: 成功率は31.1%, 日経コンピュータ12月1日号, 2008.
TS-#
TS-7

5
測定対象のエンティティ
• プロセス
– 入力を出力に変換するアクティビティ(活動)の集合

• プロダクト
– アクティビティから出力される成果物や文書

• リソース
– アクティビティの実施に必要な人、もの、金などの資源

入力
プロダクト

プロセス

出力
プロダクト

リソース
N.E. Fenton, and S. L. Pfleeger, Software Metrics: A Rigorous and Practical Approach, PWS Publishing
野中誠 , ソフトウェア技術者のためのメトリクス基礎, 2010, TopSEセミナー

TS-#
TS-7

6
主なメトリクス
名称

規模の把握、他のメトリ
クスの正規化

機能量

規模の見積もり

サイクロマティック複
雑度(CC)

制御フローグラフの経路
数

複雑さの把握

凝集度

モジュール内の要素のま
とまり

複雑さの把握

結合度

モジュール間の結合関係 複雑さの把握
の多さ

欠陥密度(DD)

欠陥数 / 新規・変更LOC 品質の把握、開発プロセ
ス全体の有効性把握

欠陥除去率(DRE)

欠陥摘出数 / 当該時点
欠陥数

開発プロセス全体や工
程の有効性把握

消化済みテストケー
ス数
TS-#
TS-7

コードの行数

ファンクションポイン
ト(FP)

プロセス

用途

コード行数(LOC)

プロダクト

定義

当該時点までの消化済
みテストケース数

テストの進捗把握

7
測定方法
• ソフトウェアの抽象的な特定側面を捉える
• 測定方法が異なれば測定結果も変わる
1:/* strncat()は、文字列srcからcount数の文字を文字列destに付加し、さ
2:らに終端にnull文字を付加する。重なるオブジェクト間でコピーしようとする
3:場合、動作は未定義である。*/
4:char *strncat(char *dest, const char *src, size_t count)
5:{
6:
char *temp=dest;
7:
if (count) {
8:
while (*dest)
9:
dest++;
10:
while ((*dest++=*src++)) {
11:
if (--count ==0) {
12:
*dest=‘¥0’; break;
13:
}
14:
}
15:
} return temp;
16:}
TS-#
TS-7

8
例:サイクロマティック複雑度
(Cyclomatic Complexity: CC)
• テキスト
– プログラムの制御フロー上で他とは異なるリンク(エッ
ジ)を持つ経路数

• ダイアグラム
=2

• アルゴリズム
– V(g) = e – n + 2 (ただし e: エッジ数、n: ノード数)
– V(g) = bd + 1 (ただし bd: 二分決定数)
出典: 野中誠 , 鷲崎 弘宜,ソフトウェア技術者のためのメトリクス基礎, 2010, TopSEセミナー
[Linda09] リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエア
の測定と見積もりの正しい作法", 日経BP社 , 2009.

TS-#
TS-7

9
メトリクスの使いどころ
• 実態把握、問題の絞込み
– 複雑さ、欠陥密度など

• 予測、計画
– 工数見積もり、欠陥数の予測など

ファンクション
ポイント

凝集度
結合度

機能仕
様書

モジュール
設計

要求定
義

複雑度
欠陥密度 消化数
コード行数
ソース
コード

設計

実装

欠陥票

テスト
ケース

テスト

工数、期間
TS-#
TS-7

10
実態把握や問題絞込み
例: サイクロマティック複雑度

• ヒストグラム

件数

– 分布状況の把握

• 管理図

測定値

– 平均や範囲のばら
つき
– 異常の特定

TS-#
TS-7

11
予測や計画
• 散布図
– 関係の把握

関数
再利
用率

• 関係性の分析
– 単回帰分析: 1つの説明変
数、1つの目的変数
– 重回帰分析: 2つ以上の説
明変数
– 2値データのロジスティック
回帰分析: 目的変数が0,1

被使用外部ファイル率

実測値

鷲崎弘宜, 小池利和, 波木理恵子, 田邉浩之, "C言語プログラムソースコード
の再利用性測定法とその評価", ソフトウェアテストシンポジウム JaSST'09
TS-#
TS-7

呼出し関数の数

重相関係数
=0.941

予測値
12
メトリクスの落とし穴
• 信頼性: 「1件」「1行」が異なっている(かも)
– 欠陥数、行数・・・
– 客観性の高い測定、自動測定

• 妥当性: 「実世界で測定」できることは「測定し
たい概念」の一部に過ぎない
– 多面的な捉え方、現物確認
– 測定・管理がプロジェクトに最重要とは限らない
[DeMarco09]

• 負のホーソン効果
– 本当に改善したいこと、目的指向
[DeMarco09]T. DeMarco, Software Engineering: An Idea Whose Time Has Come and Gone?, IEEE Software, 2009.
TS-#
TS-7

13
目次
•
•
•
•

メトリクスの基本概念
主要なメトリクス: 規模,複雑さ,欠陥
GQMによるゴール指向な測定
GQMを用いた組込みソフトウェア
品質改善事例
• まとめ

TS-#
TS-7

14
規模: コード行数(LOC)の留意点
• 測定モデルの一貫性
– NLOC, LLOC
– CMU/SEI チェックリスト

• 作成方法、出所
– 25%を超える修正は新規実装と同程度の工数 [Linda09]

• 言語の違い
– ビジュアル言語、オブジェクト指向: 手続き型ほど役立たない
– 言語補正係数表によるファンクションポイントとの関係 [LOC/FP]
(例: アセンブリ 320, Java 53, C 128, 表計算 6)

• コメント比率 = コメント行数 / LOC
– 12.6%を超えると、コメントなしコードの2倍欠陥潜在率 [阿萬12]
[Linda09] リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ", 日経BP社 , 2009.

CMU/SEI-92-TR-022. ESC-TR-92-022. Software Quality Measurement: Framework for Counting Problems and
Defects. http://www.sei.cmu.edu/reports/92tr020.pdf
阿萬, “オープンソースソフトウェアにおけるコメント記述およびコメントアウトと フォールト潜在との関係に関する定量分析”, 情報処理学会論
文誌, 53(2), 2012.

TS-#
TS-7

15
規模: ファンクションポイント法
• 内部の処理や解決策ではなく問題の扱い
– システムの入出力、インタフェース、データファイルといった「代理」
(プロキシ)の数え上げ
– 複雑さや環境などの難易度係数で調整

• 機能規模測定(Functional Size Measurement)
– ファンクションポイント法(FP法): 1979 オールブレクト
– IFPUG(International Function Point Users Group
http://www.ifpug.org )結成、標準化
– 技術独立・初期段階で利用可 ⇔ 経験の必要性、主観性・属人性
入力

ユーザ

測定対象アプリケーション

照会
データファイル

外部アプリ
ケーション

インタ
フェース

出力

TS-#
TS-7

16
複雑さ: サイクロマティック複雑度など
• 欠陥、保守やテストの困難さの検討
– レビュー・テスト必要箇所の特定、工数見積もり

• 関数内: サイクロマティック複雑度
– 20が欠陥含まれやすさ閾値
– [鷲崎10] 1 推奨、2~9 許容

• モジュール内: 凝集度

=2

– 単一機能 ← データ中心 ← 機能中心 ← 無関係
– LCOM(Lack of Cohesion in Methods) < 2~5
[Chidamber94]: 参照変数が共通しないメソッド組み合わせ
数 - 共通ありの組み合わせ数

• モジュール間: 結合度
– データ渡し ← 制御フラグ渡し ← グローバルデータ
– ファンアウト≦ 7±2 [SESSAME]
[SESSAME07] SESSAME WG2, 組込みソフトウェア開発のためのリバースモデリング, 翔泳社, 2007.
[Chidamber94] S.R.Chidamber and C.F.Kemerer, “A Metrics Suite for Object-Oriented Design”, IEEE Trans.
Software Eng., vol. 20, no. 6, pp.476-493, June 1994
[鷲崎10]鷲崎弘宜,田邉浩之, 小池利和,”ソースコード解析による品質評価の仕組み“, 日経エレクトロニクス, 2010年1月25日号

TS-#
TS-7

17
欠陥: DD, DRE
• 欠陥数、欠陥発見・摘出数
– 実測、動的・静的予測
– 時間あたりの場合は単位に注意

• 欠陥密度 (Defect Density: DD)
= 欠陥数 / 新規・変更LOC
– 品質把握、プロセス全体のパフォーマンス把握
– ドメインや稼働時間の相違の考慮が必要

• 欠陥除去率(Defect Removal Efficiency: DRE)
= 当該工程欠陥除去数 / 当該工程で存在した欠陥数
– 各欠陥摘出工程の欠陥摘出能力把握、改善
– 各欠陥の作り込み・原因工程の記録必要あり
[Linda09] リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエア
メトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法", 日経BP社 , 2009.

TS-#
TS-7

18
目次
•
•
•
•

メトリクスの基本概念
主要なメトリクス: 規模,複雑さ,欠陥
GQMによるゴール指向な測定
GQMを用いた組込みソフトウェア
品質改善事例
• まとめ

TS-#
TS-7

19
Goal-Question-Metric (GQM) パラダイム
• 明確に目標を据えて、目標に対して必要なメトリクスを対応
付けるゴール指向(目標指向)な枠組み
• 目標(Goal): 測定上の目標
• 質問(Question): 目標の達成を評価するための質問
• メトリクス(Metric): 質問に回答するために必要な定量的デ
ータを得るための主観的・客観的メトリクス
目標達成評価

G. 目標
Q. 質問

測定する事柄
の決定

答え
M. メトリクス

測定値

測定結果の
解釈

収集データ
R. van Solingen, E. Berghout, “The Goal/Question/Metric Method” McGraw-Hill Education, 1999; ISBN 0-07709-553-7.

TS-#
TS-7

20
GQMモデル(グラフ)の例

G
Q2

Q1

• 目標

M1

M2

M3

– G. コードクローン含有の観点から保守性の低いコードを
特定できている。

• 質問
– Q1: コードクローンは存在するか? → M1, M2
– Q2: 発見されたコードクローンは保守上有害か? → M3

• メトリクス
– M1: ソースコードの全体的な重複度
– M2: モジュール単位のコードクローン含有率
– M3: コードクローンに対するマネージャの主観的評価
リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009.
V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994)
楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012.

TS-#
TS-7

21
GQMの拡張
• 上位/ビジネスゴール (参考: GQM+Strategies)
– 測定上のGoalの上位ゴール

• 仮定(Hypothesis, Assumption)
– Question導出にあたり仮定している事柄
– A. 要求が不安定であれば設計は頻繁に変更される。

• 解釈(Interpretation)
– もし「条件式」ならば「Goalはこのように達成・未達成」
– I. もしLOCが少なすぎず、かつ、設計変更回数が一定
以上ならば、要求が不安定な可能性がある。

• メカニズム(Mechanism)
– 収集・報告責任者、収集・報告頻度、必要なインフラ
– 例: マネージャが毎週レポートを参照して・・・
リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と
見積もりの正しい作法", 日経BP社 , 2009.
Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012.

TS-#
TS-7

22
仮説や解釈を伴う例
G. 特定プロジェクトにおける要求の不安定さを把握できている

A. 要求が不安定であれば
コードは頻繁に削除を
伴って変更される
I. FCt が極端に大きくなく、かつ、
FCdが以前よりも大きいのであれ
ば、要求が不安定な可能性あり

A. 要求が不安定であれば
コードは大きく変更される

I. FLa が極端に大きくなく、かつ、
FLdが以前よりも大きいのであれ
ば、要求が不安定な可能性あり

Q. ソースファイルの
変更頻度はいくらか?
FCt. 一週間以内の
ファイル更新回数

・・・

FCd. 一週間以内の削除
を伴うファイル更新回数

Q. ファイルの変更
規模はいくらか?
FLa. 一週間以
内の追加行数

FLd. 一週間以
内の削除行数

Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012.

TS-#
TS-7

23
GQM+Strategies: 組織目標・戦略・測定上の目標
• 事実(Context)や仮定
(Assumption)を明示
して戦略結びつけ
• 組織上位から下位まで
連鎖
• 測定上の目標を掲げた
GQMグラフを紐づけ定
量評価
• IESEによる開発、ツー
ルあり
• 早稲田大学ゴール指
向経営研究会、ITC 研
究会 開始(’13~)
Basili, V.R., et al. “Linking Software Development
and Business Strategy Through Measurement,”
IEEE Computer, Vol.43, No.4, pp.57-65, 2010.
新谷勝利、平林大典: “企業・組織の目標達成とIT
導入計画の整合化を実現するための手法推進”、
SEC Journal、2012.

TS-#
TS-7

GQMグラフ

目標ツリー

Q

M

Q

組織上位の目標

M

G

事実・仮定

組織上位の戦略

組織中位の目標

Q

M

Q

M

G

・・・

組織中位の戦略

組織下位の目標

Q

Q

M

M

Q

M

G

G
Q

M

24
目標
ビジネス
レベル

顧客満足度を向上
できている

GQM+Strategies
グリッドの例

製品の品質が
高ければ・・・

製品の品質を改善
戦略
する
ソリューション
事業部
(ソフトウェア
レベル)

鷲崎弘宜、”ゴール指向の測定評価と留意 – GQMパラダイムと拡
張 -”、メトリクス公団、Vol.1、TEF東海メトリクス勉強会、2013.

顧客からの不具合
報告を削減できて
いる

テスト効率を改善
する

ソフトウェアの保守
性を改善する

品質保証
チーム
テストプロセスを
改善する
TS-#

開発チーム

開発時にコードの
保守性評価を20%
改善できている

G: コードの
保守性を定量
評価できている

Q1

M1

Q2

M2
25
目次
•
•
•
•

メトリクスの基本概念
主要なメトリクス: 規模,複雑さ,欠陥
GQMによるゴール指向な測定
GQMを用いた組込みソフトウェア
品質改善事例
• まとめ

TS-#
TS-7

26
規模や複雑さから品質診断へ
G. 信頼性
目標

G. 保守性

G. 効率性

G. 移植性

G. 再利用性

再利用性

G. 解析性 G. 変更性 G. 安定性 G. 試験性

移植性

言語 独立

言語 依存
副質問

Q. 処理が複雑
すぎないか?

Q. 処理が構造
化されているか?

・・・

各種ツール
M. コールグラフ M. サイクロ ・・・
で測定
階層の深さ マティック複雑度
メトリクス

プログラム
ソースコード

…… …
…… …

効率性
保守性

Q. 複雑な文を記
述していない
か?

Q. 制御構造が ・・・
複雑すぎない
か?

質問

信頼性

・・・

M. 関数内の ・・・
戻り点の数

…… …
…… …

[Adqua] http://www.ogis-ri.co.jp/product/b-08-000001A6.html
鷲崎弘宜,田邉浩之,小池利和,ソースコード解析による品質評価の仕組み,日経エレクトロニクス 2010/1/25
TS-#
TS-7

27
対象例: ETロボコン・コード改善
• 規模: 1481 ELOC, 18クラス, 121関数
• サイクロマティック複雑度の大きい関数をリストアップ
• しかし「数」だけでは問題は分からない → 対象の詳細調査へ
品質副特性
得点

79.3

偏差値

38.7

得点
偏差値

46.2

得点

84.3

偏差値

61.5

偏差値

35.8

サイクロマ
ティック複雑度

関数の
物理行数

50.0

得点

関数名

89.3

解析性

品質特性

ファイル名

12

55

Tactics.cpp

getDriver(DriveStatus::eDifficultKind)

12

51

StepDriver.cpp

drive(bool)

11

119

SeesawDriver.cpp

drive(bool)

8

100

GarageDriver.cpp

driveIn(void)

8

73

TASK(TaskDrive)
40.9

7

91

Magi.cpp

46.8
getDriveStatus()

7

37

PositionDecision.cpp

updateLocation()
69.3

6

81

自クラスを使用する他クラスの種類数
Tactics.cpp

70.4
~Tactics(void)

5

15

34.5

クラスの実行コード行数

35.6

変更性

78.6

偏差値

decideSynthetic()

関数の実行コード行数

得点

Magi.cpp

36.1

保守性

安定性

試験性

Question
処理が複雑すぎないか
処理が構造化されているか

要素間の結合度は低くなって
いるか

要素の規模は適切か

得点
44.5
99.5

偏差値
37.7
46.5

メトリック

Main.cpp
制御フローグラフの最大ネスト数
サイクロマティック複雑度
break等のないswitch文の数

使用する他クラスの種類数
75.9

59.1

48.1

43.7

ファイル内の関数の数
クラス内のメソッド数

TS-#
TS-7

得点

91.0

85.6
鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能:
78.1
第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日

28
//=============================================================================
// 難所走行状態の更新
void Magi::decideSynthetic()
{
// 次に目指す難所を取得
ChangePoint p = mStrategy.getChangePoint();
// 事前に登録した判定クラスから難所を取得
int decideCount = 0;
for (SINT i = 0; i < mNumOfJudge; i++) {
if (mJudgeAddressTable[i]->decideHard(p)) {
decideCount++;
}
}
if (decideCount >= 1) {
switch (p.getPointKind()) {
case ChangePoint::SEESAW_IN:
mDifficultKindBuf = DriveStatus::SEESAW;
mCangeCount = 0;
break;
case ChangePoint::SEESAW_OUT:
mDifficultKindBuf = DriveStatus::LINETRACE;
mCangeCount = 0;
break;
case ChangePoint::STEPS_IN:
mDifficultKindBuf = DriveStatus::STEPS;
mCangeCount = 0;
break;
case ChangePoint::STEPS_OUT:
mDifficultKindBuf = DriveStatus::LINETRACE;
mCangeCount = 0;
break;
case ChangePoint::OUTCOURSE_GARAGE:
mDifficultKindBuf = DriveStatus::OUTCOURSE_GARAGE;
mCangeCount = 0;
break;
case ChangePoint::INCOURSE_GARAGE:
mDifficultKindBuf = DriveStatus::INCOURSE_GARAGE;
mCangeCount = 0;
break;
default:
break;
}
// 目指す難所を更新する
mStrategy.next();
}
// 難所判定後、時間差で走行を切替えるケースに備える
if (mCangeCount > 0) {
mCangeCount--;
} else if (mCangeCount == 0) {
mCangeCount--;
// 走行切替
mStatus.setDifficultKind(mDifficultKindBuf);
}

//=============================================================================
// 走行ステータスに応じて走行クラスを返却
Driver* Tactics::getDriver(DriveStatus::eDifficultKind kind)
{
Driver* drive;
drive = 0;
switch(kind)
{
case DriveStatus::LINETRACE:
if(mLineTraceDriver == 0)
{
mLineTraceDriver = new LineTraceDriver(mMaimai, mPid);
}
drive = mLineTraceDriver;
break;
case DriveStatus::SEESAW:
if(mSeesawDriver == 0)
{
mSeesawDriver = new SeesawDriver(mrGyro, mMaimai, mPid);
}
drive = mSeesawDriver;
break;
case DriveStatus::STEPS:
if(mStepDriver == 0)
{
mStepDriver = new StepDriver(mrGyro, mMaimai, mPid);
}
drive = mStepDriver;
break;
case DriveStatus::OUTCOURSE_GARAGE:
if(mGarageDriver == 0)
{
mGarageDriver = new GarageDriver(mPositionDecision);
}
drive = mGarageDriver;
break;
case DriveStatus::INCOURSE_GARAGE:
if(mGarageDriver == 0)
{
mGarageDriver = new GarageDriver(mPositionDecision);
}
drive = mGarageDriver;
break;
default:
if(mLineTraceDriver == 0)
{
mLineTraceDriver = new LineTraceDriver(mMaimai, mPid);
}
drive = mLineTraceDriver;
break;
}
return drive;
}

鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日
}

TS-#
TS-7

29
「数」から問題・原因の特定へ
• 散らばり or もつれあい
• 「難所に関する処理・責務(関心事)」のパッケージ横断な散らばり
判定処理系
走行系
切替ポイントを
取得する

戦略
+

3重多数決
+
+
+

目標切替ポイント取得() : 切替ポイント
1

走行ステータス更新() : 走行ステータス
開始判定() : boolean
総合判定() : void

1

+
+

初期化() : void
走行開始() : void

1

*

1

1 +

走行クラス取得(走行ステータス) : 走行

走る

生成する

走行ステ ー タ ス

審判
+
+

走行

1

3

灰色検知フラグ
座標
推定時間

戦術
-

難所を判定する

切替ポ イン ト
-

走行クラスを
取得する

Ma in

走行ステータスを取得する

-

4

IN/OUTフラグ

+
+

難所判定(切替ポイント) : boolean
フェイルセーフ判定(走行ステータス) : boolean

getter() : void
setter() : void

走行
+

位置判定

<<enum>>
走行種別

色判定

-

現在時間

-

現在位置

-

現在色

+
-

時間判定(推定時間) : void
時間更新() : void

+
-

ロケーション判定(座標) : void
現在位置更新() : void

+
-

灰色検知(灰色検知フラグ) : void
現在色更新() : void

1
コ ン ポ ー ネン ト

現在座標を
取得する

1

ライトセンサ値を
取得する

+

<<enum>>
難所種別

キャリブレーション
走行
停止

-

ライントレース
階段
シーソー通過
ガレージイン

1

1

ライトセンサ値を
取得する

1

補正ライトセンサ値

+

1
定周期ライトON() : void
定周期ライトOFF() : void
補正ライトセンサ値取得() : void

1
イン テ リジ ェン トモ ー タ ー

PID制御
1

+

-

補正係数

+
+

PID算出() : void
進行方向取得() : 進行方向

モーター出力補正() : void
モーター出力設定(右出力, 左出力) : void
1

1
センサ値を
取得する

E C ROBOT API

回転数を取得する
センサ値を
取得する

1

1

タ ッチセン サ
+

センサ値取得() : boolean

1

タ イマー
+

時間取得() : 時間

センサ値取得() : ジャイロセンサ値

モーター値を設定する

1

2

ライトセン サ

ジ ャイロ セン サ
+

モーター値を
設定する

進行方向を
取得する

1

-

現在座標取得() : void

+
+

シ ー ソー 通過走行

ガレ ー ジ イン 走行

ま いま い式

ロ ケー シ ョン
時間を取得
する

1

1

1

センサ値を
取得する

-

階段走行

走る() : void
1

時間判定

ライン トレ ー ス走行

センサ値取得() : ライトセンサ値
ランプ設定(ON/OFF) : void

2

モー タ ー
+
+

モーター出力設定(出力) : void
回転数取得() : 回転数

鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日

TS-#
TS-7

30
<<enum>>
走行種別

改善結果

-

走行ステー タ ス
-

キャリブレーション 1
走行
停止

1

Ma in

IN/OUTフラグ

+
+

getter() : void
setter() : void

1

1

+
+

走行を開始する

初期化() : void
1
走行開始() : void

判定処理系

走行系
1
戦術

3重多数決
難所を判定する
難所判定(切替ポイント) : boolean

1

走行

+

• 関心事の局
所化
• 保守性改善

+

-

走行開始() : void

1

1
1
難所を判定する

ライン トレ ー ス 走 行

3

1..* {ordered}
審判

+
+

+構成要素
階段走行

走行

難所判定(切替ポイント) : boolean
フェイルセーフ判定(走行ステータス) : boolean

+
+

走る() : void
切替ポイント取得(IN/OUT) : 切替ポイント
1

シ ー ソー 通 過 走 行

1

0..1 +入時 0..1 +出時
時間判定

位置判定

-

現在時間

-

現在位置

-

現在色

+
-

時間判定(推定時間) : void
時間更新() : void

+
-

ロケーション判定(座標) : void
現在位置更新() : void

+
-

灰色検知(灰色検知フラグ) : void
現在色更新() : void

Question

得点

偏差値

ガレ ー ジ イン 走 行

色判定

メトリック

切 替 ポ イン ト
-

灰色検知フラグ
座標
推定時間

得点

処理が構造化されているか

要素間の結合度は低くなって
いるか

要素の規模は適切か

制御フローグラフの最大ネスト数

98.7

42.7
7 .5
UP

75.6

46.1

47.9

62.7

47.4

サイクロマティック複雑度

55.2

break等のないswitch文の数

90.8

使用する他クラスの種類数

52.0

48.0

68.8

自クラスを使用する他クラスの種類数

67.7

関数の実行コード行数

処理が複雑すぎないか

37.6

クラスの実行コード行数

39.6

ファイル内の関数の数

7 .1
UP

87.6

8 .4
UP

3 .1
UP

3 .6
鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 81.1
2011年9月5日
クラス内のメソッド数
UP

TS-#
TS-7

31
目次
•
•
•
•

メトリクスの基本概念
主要なメトリクス: 規模,複雑さ,欠陥
GQMによるゴール指向な測定
GQMを用いた組込みソフトウェア
品質改善事例
• まとめ

TS-#
TS-7

32
まとめ
• ソフトウェア開発の厳しさとメトリクスの重要性
– 開発の管理、品質把握と改善

• メトリクスの限界を知り意思決定に役立てる
– 測定方法、信頼性、妥当性、負のホーソン効果
– 基本的なメトリクス: 規模、複雑性、欠陥

• GQMによる目標指向の測定
– 測定と改善のプロセス
– GQM+Strategiesによる組織目標へのひもづけ

TS-#
TS-7

33
• メトリクス全般
– リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳
, "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と見
積もりの正しい作法", 日経BP社 , 2009.

• GQM
– 鷲崎弘宜、”ゴール指向の測定評価と留意 – GQMパラダイムと拡
張 -”、メトリクス公団、Vol.1、TEF東海メトリクス勉強会、2013.
– 楠本真二、肥後芳樹: “GQMパラダイムを用いたソフトウェアメトリ
クスの活用”、コンピュータソフトウェア、29(3)、pp.29-38、2012.
– Basili, V., Caldiera, C., and Rombach, D.: “Goal, Question,
Metric Paradigm, Encyclopedia of Software Engineering,”
Vol.1, pp. 528–532, 1994.

• GQM+Strategies
– Basili, V.R., Lindvall, M., Regardie, M., Seaman, C., Heidrich,
J., Munch, J., Rombach, D., Trendowicz, A.: “Linking Software
Development and Business Strategy Through Measurement,”
IEEE Computer, Vol.43, No.4, pp.57-65, 2010.
– 新谷勝利、平林大典: “企業・組織の目標達成とIT導入計画の整
合化を実現するための手法推進”、SEC Journal、2012.

• 事例
– 鷲崎弘宜, 田邉浩之, 小池利和, “ソースコード解析による品質評価
の仕組み”, 日経エレクトロニクス, 2010年1月25日号, 2010.
– 鷲崎弘宜, 阿左美勝, 田邉浩之, “モデル活用の効能: 第1回 モデ
ルを書く意味”~ “モデル活用の効能: 第4回 参加チームの事例
3″,日経エレクトロニクス, 日経BP社, 2011年8月8日号~11月号
TS-#
TS-7

34

Más contenido relacionado

La actualidad más candente

QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証Yasuharu Nishi
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術Takuto Wada
 
画像をテキストで検索したい!(OpenAI CLIP) - VRC-LT #15
画像をテキストで検索したい!(OpenAI CLIP) - VRC-LT #15画像をテキストで検索したい!(OpenAI CLIP) - VRC-LT #15
画像をテキストで検索したい!(OpenAI CLIP) - VRC-LT #15Shuyo Nakatani
 
自然言語処理に基づく商品情報の整理および構造化
自然言語処理に基づく商品情報の整理および構造化自然言語処理に基づく商品情報の整理および構造化
自然言語処理に基づく商品情報の整理および構造化Rakuten Group, Inc.
 
What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?Yasuharu Nishi
 
先端技術とメディア表現1 #FTMA15
先端技術とメディア表現1 #FTMA15先端技術とメディア表現1 #FTMA15
先端技術とメディア表現1 #FTMA15Yoichi Ochiai
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。toshihiro ichitani
 
それでも私が研究を続ける理由
それでも私が研究を続ける理由それでも私が研究を続ける理由
それでも私が研究を続ける理由Hitomi Yanaka
 
心理的安全性の高いチームを作ってみた
心理的安全性の高いチームを作ってみた心理的安全性の高いチームを作ってみた
心理的安全性の高いチームを作ってみたYusuke Hisatsu
 
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからYasuharu Nishi
 
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOKKotaro Ogino
 
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Hironori Washizaki
 
あじゃいる時代の品質保証 ~DevSQAの提案~
あじゃいる時代の品質保証 ~DevSQAの提案~あじゃいる時代の品質保証 ~DevSQAの提案~
あじゃいる時代の品質保証 ~DevSQAの提案~Hiroaki Matsunaga
 
ChatGPT 人間のフィードバックから強化学習した対話AI
ChatGPT 人間のフィードバックから強化学習した対話AIChatGPT 人間のフィードバックから強化学習した対話AI
ChatGPT 人間のフィードバックから強化学習した対話AIShota Imai
 
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -Hironori Washizaki
 
ChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くないChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くないCarnot Inc.
 
画像認識の初歩、SIFT,SURF特徴量
画像認識の初歩、SIFT,SURF特徴量画像認識の初歩、SIFT,SURF特徴量
画像認識の初歩、SIFT,SURF特徴量takaya imai
 
SSII2022 [SS1] ニューラル3D表現の最新動向〜 ニューラルネットでなんでも表せる?? 〜​
SSII2022 [SS1] ニューラル3D表現の最新動向〜 ニューラルネットでなんでも表せる?? 〜​SSII2022 [SS1] ニューラル3D表現の最新動向〜 ニューラルネットでなんでも表せる?? 〜​
SSII2022 [SS1] ニューラル3D表現の最新動向〜 ニューラルネットでなんでも表せる?? 〜​SSII
 

La actualidad más candente (20)

QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
 
研究効率化Tips Ver.2
研究効率化Tips Ver.2研究効率化Tips Ver.2
研究効率化Tips Ver.2
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
 
画像をテキストで検索したい!(OpenAI CLIP) - VRC-LT #15
画像をテキストで検索したい!(OpenAI CLIP) - VRC-LT #15画像をテキストで検索したい!(OpenAI CLIP) - VRC-LT #15
画像をテキストで検索したい!(OpenAI CLIP) - VRC-LT #15
 
自然言語処理に基づく商品情報の整理および構造化
自然言語処理に基づく商品情報の整理および構造化自然言語処理に基づく商品情報の整理および構造化
自然言語処理に基づく商品情報の整理および構造化
 
What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?
 
Lean coffee
Lean coffeeLean coffee
Lean coffee
 
先端技術とメディア表現1 #FTMA15
先端技術とメディア表現1 #FTMA15先端技術とメディア表現1 #FTMA15
先端技術とメディア表現1 #FTMA15
 
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
 
それでも私が研究を続ける理由
それでも私が研究を続ける理由それでも私が研究を続ける理由
それでも私が研究を続ける理由
 
心理的安全性の高いチームを作ってみた
心理的安全性の高いチームを作ってみた心理的安全性の高いチームを作ってみた
心理的安全性の高いチームを作ってみた
 
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
 
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
 
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
 
あじゃいる時代の品質保証 ~DevSQAの提案~
あじゃいる時代の品質保証 ~DevSQAの提案~あじゃいる時代の品質保証 ~DevSQAの提案~
あじゃいる時代の品質保証 ~DevSQAの提案~
 
ChatGPT 人間のフィードバックから強化学習した対話AI
ChatGPT 人間のフィードバックから強化学習した対話AIChatGPT 人間のフィードバックから強化学習した対話AI
ChatGPT 人間のフィードバックから強化学習した対話AI
 
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
メトリクスによるソフトウェア品質把握と改善- 演習を交えた品質測定評価の落とし穴とコツの習得 -
 
ChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くないChatGPTは思ったほど賢くない
ChatGPTは思ったほど賢くない
 
画像認識の初歩、SIFT,SURF特徴量
画像認識の初歩、SIFT,SURF特徴量画像認識の初歩、SIFT,SURF特徴量
画像認識の初歩、SIFT,SURF特徴量
 
SSII2022 [SS1] ニューラル3D表現の最新動向〜 ニューラルネットでなんでも表せる?? 〜​
SSII2022 [SS1] ニューラル3D表現の最新動向〜 ニューラルネットでなんでも表せる?? 〜​SSII2022 [SS1] ニューラル3D表現の最新動向〜 ニューラルネットでなんでも表せる?? 〜​
SSII2022 [SS1] ニューラル3D表現の最新動向〜 ニューラルネットでなんでも表せる?? 〜​
 

Similar a メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)

早稲田・鷲崎-ゴール指向の測定によるソフトウェア 品質評価と改善の実践的取組み (三つのコツ、三つの事例)-2015年2月19日
早稲田・鷲崎-ゴール指向の測定によるソフトウェア品質評価と改善の実践的取組み(三つのコツ、三つの事例)-2015年2月19日早稲田・鷲崎-ゴール指向の測定によるソフトウェア品質評価と改善の実践的取組み(三つのコツ、三つの事例)-2015年2月19日
早稲田・鷲崎-ゴール指向の測定によるソフトウェア 品質評価と改善の実践的取組み (三つのコツ、三つの事例)-2015年2月19日Hironori Washizaki
 
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善Hironori Washizaki
 
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-Hironori Washizaki
 
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912Hironori Washizaki
 
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011Yusuke Suzuki
 
How to organize data science project (データサイエンスプロジェクトの始め方101)
How to organize data science project (データサイエンスプロジェクトの始め方101)How to organize data science project (データサイエンスプロジェクトの始め方101)
How to organize data science project (データサイエンスプロジェクトの始め方101)Yasuyuki Kataoka
 
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質 SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質 Hironori Washizaki
 
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」Yusuke Suzuki
 
ベンチマーク勉強会#01
ベンチマーク勉強会#01ベンチマーク勉強会#01
ベンチマーク勉強会#01milk hanakara
 
S qu bok特別講演2015年2月-開発領域
S qu bok特別講演2015年2月-開発領域S qu bok特別講演2015年2月-開発領域
S qu bok特別講演2015年2月-開発領域Hironori Washizaki
 
SQuBOK特別講演2015年2月「SQuBOK V2設計開発領域について」
SQuBOK特別講演2015年2月「SQuBOK V2設計開発領域について」SQuBOK特別講演2015年2月「SQuBOK V2設計開発領域について」
SQuBOK特別講演2015年2月「SQuBOK V2設計開発領域について」Hironori Washizaki
 
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423Yusuke Suzuki
 
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかYusuke Suzuki
 
レガシーコードとの付き合い方とテストでの話
レガシーコードとの付き合い方とテストでの話レガシーコードとの付き合い方とテストでの話
レガシーコードとの付き合い方とテストでの話H Iseri
 
測定によるソフトウェア品質への挑戦 公開用
測定によるソフトウェア品質への挑戦 公開用測定によるソフトウェア品質への挑戦 公開用
測定によるソフトウェア品質への挑戦 公開用Hironori Washizaki
 
DX 時代の新たなソフトウェア工学に向けて: SWEBOK と SE4BS の挑戦
DX 時代の新たなソフトウェア工学に向けて: SWEBOK と SE4BS の挑戦DX 時代の新たなソフトウェア工学に向けて: SWEBOK と SE4BS の挑戦
DX 時代の新たなソフトウェア工学に向けて: SWEBOK と SE4BS の挑戦Hironori Washizaki
 
ソフトウェア工学からコンピューターサイエンスへ (デブサミ2014)
ソフトウェア工学からコンピューターサイエンスへ (デブサミ2014)ソフトウェア工学からコンピューターサイエンスへ (デブサミ2014)
ソフトウェア工学からコンピューターサイエンスへ (デブサミ2014)Masayoshi Hagiwara
 
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~Yasuharu Nishi
 

Similar a メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013) (20)

早稲田・鷲崎-ゴール指向の測定によるソフトウェア 品質評価と改善の実践的取組み (三つのコツ、三つの事例)-2015年2月19日
早稲田・鷲崎-ゴール指向の測定によるソフトウェア品質評価と改善の実践的取組み(三つのコツ、三つの事例)-2015年2月19日早稲田・鷲崎-ゴール指向の測定によるソフトウェア品質評価と改善の実践的取組み(三つのコツ、三つの事例)-2015年2月19日
早稲田・鷲崎-ゴール指向の測定によるソフトウェア 品質評価と改善の実践的取組み (三つのコツ、三つの事例)-2015年2月19日
 
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
 
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
ヒンシツ大学セミナー ゴール指向の測定と品質保証活動 -メトリクス解説およびGqm法のワークショップ-
 
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
鷲崎 メトリクスとGQMチュートリアル-公開版-20130912
 
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
 
How to organize data science project (データサイエンスプロジェクトの始め方101)
How to organize data science project (データサイエンスプロジェクトの始め方101)How to organize data science project (データサイエンスプロジェクトの始め方101)
How to organize data science project (データサイエンスプロジェクトの始め方101)
 
組込みSW開発技術研究会キックオフミーティング
組込みSW開発技術研究会キックオフミーティング組込みSW開発技術研究会キックオフミーティング
組込みSW開発技術研究会キックオフミーティング
 
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質 SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
 
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
 
ベンチマーク勉強会#01
ベンチマーク勉強会#01ベンチマーク勉強会#01
ベンチマーク勉強会#01
 
S qu bok特別講演2015年2月-開発領域
S qu bok特別講演2015年2月-開発領域S qu bok特別講演2015年2月-開発領域
S qu bok特別講演2015年2月-開発領域
 
SQuBOK特別講演2015年2月「SQuBOK V2設計開発領域について」
SQuBOK特別講演2015年2月「SQuBOK V2設計開発領域について」SQuBOK特別講演2015年2月「SQuBOK V2設計開発領域について」
SQuBOK特別講演2015年2月「SQuBOK V2設計開発領域について」
 
品質基礎知識
品質基礎知識品質基礎知識
品質基礎知識
 
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
 
Devlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのかDevlove2012 どうしたら良いシステムが作れるのか
Devlove2012 どうしたら良いシステムが作れるのか
 
レガシーコードとの付き合い方とテストでの話
レガシーコードとの付き合い方とテストでの話レガシーコードとの付き合い方とテストでの話
レガシーコードとの付き合い方とテストでの話
 
測定によるソフトウェア品質への挑戦 公開用
測定によるソフトウェア品質への挑戦 公開用測定によるソフトウェア品質への挑戦 公開用
測定によるソフトウェア品質への挑戦 公開用
 
DX 時代の新たなソフトウェア工学に向けて: SWEBOK と SE4BS の挑戦
DX 時代の新たなソフトウェア工学に向けて: SWEBOK と SE4BS の挑戦DX 時代の新たなソフトウェア工学に向けて: SWEBOK と SE4BS の挑戦
DX 時代の新たなソフトウェア工学に向けて: SWEBOK と SE4BS の挑戦
 
ソフトウェア工学からコンピューターサイエンスへ (デブサミ2014)
ソフトウェア工学からコンピューターサイエンスへ (デブサミ2014)ソフトウェア工学からコンピューターサイエンスへ (デブサミ2014)
ソフトウェア工学からコンピューターサイエンスへ (デブサミ2014)
 
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
 

Más de Hironori Washizaki

Machine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their EngineeringMachine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their EngineeringHironori Washizaki
 
IEEE Computer Society 2024 Technology Predictions Update
IEEE Computer Society 2024 Technology Predictions UpdateIEEE Computer Society 2024 Technology Predictions Update
IEEE Computer Society 2024 Technology Predictions UpdateHironori Washizaki
 
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会Hironori Washizaki
 
IEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
IEEE Computer Society’s Strategic Activities and Products including SWEBOK GuideIEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
IEEE Computer Society’s Strategic Activities and Products including SWEBOK GuideHironori Washizaki
 
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用Hironori Washizaki
 
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225Hironori Washizaki
 
Joseph Yoder : Being Agile about Architecture
Joseph Yoder : Being Agile about ArchitectureJoseph Yoder : Being Agile about Architecture
Joseph Yoder : Being Agile about ArchitectureHironori Washizaki
 
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデートHironori Washizaki
 
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...Hironori Washizaki
 
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向Hironori Washizaki
 
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~Hironori Washizaki
 
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集Hironori Washizaki
 
スマートエスイーコンソーシアムの概要と2021年度成果紹介
スマートエスイーコンソーシアムの概要と2021年度成果紹介スマートエスイーコンソーシアムの概要と2021年度成果紹介
スマートエスイーコンソーシアムの概要と2021年度成果紹介Hironori Washizaki
 
DXの推進において企業内に求められる人材やデジタル人材の育て方
DXの推進において企業内に求められる人材やデジタル人材の育て方DXの推進において企業内に求められる人材やデジタル人材の育て方
DXの推進において企業内に求められる人材やデジタル人材の育て方Hironori Washizaki
 
対応性のある運用のパターン
対応性のある運用のパターン対応性のある運用のパターン
対応性のある運用のパターンHironori Washizaki
 
モデル訓練のパターン
モデル訓練のパターンモデル訓練のパターン
モデル訓練のパターンHironori Washizaki
 
パターンのつながりとAI活用成熟度
パターンのつながりとAI活用成熟度パターンのつながりとAI活用成熟度
パターンのつながりとAI活用成熟度Hironori Washizaki
 
データ表現のパターン
データ表現のパターンデータ表現のパターン
データ表現のパターンHironori Washizaki
 
機械学習デザインパターンの必要性と機械学習ライフサイクル
機械学習デザインパターンの必要性と機械学習ライフサイクル機械学習デザインパターンの必要性と機械学習ライフサイクル
機械学習デザインパターンの必要性と機械学習ライフサイクルHironori Washizaki
 
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)Hironori Washizaki
 

Más de Hironori Washizaki (20)

Machine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their EngineeringMachine Learning Software Engineering Patterns and Their Engineering
Machine Learning Software Engineering Patterns and Their Engineering
 
IEEE Computer Society 2024 Technology Predictions Update
IEEE Computer Society 2024 Technology Predictions UpdateIEEE Computer Society 2024 Technology Predictions Update
IEEE Computer Society 2024 Technology Predictions Update
 
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
鷲崎弘宜, "国際規格ISO/IEC 24773とその意義", 情報処理学会 第86回全国大会
 
IEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
IEEE Computer Society’s Strategic Activities and Products including SWEBOK GuideIEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
IEEE Computer Society’s Strategic Activities and Products including SWEBOK Guide
 
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
TISO/IEC JTC1におけるソフトウェア工学知識体系、技術者認証および品質の標準化と研究・教育他への活用
 
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
アジャイル品質のパターンとメトリクス Agile Quality Patterns and Metrics (QA2AQ) 20240225
 
Joseph Yoder : Being Agile about Architecture
Joseph Yoder : Being Agile about ArchitectureJoseph Yoder : Being Agile about Architecture
Joseph Yoder : Being Agile about Architecture
 
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
世界標準のソフトウェア工学知識体系SWEBOK Guide最新第4版を通じた開発アップデート
 
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
SWEBOK Guide Evolution and Its Emerging Areas including Machine Learning Patt...
 
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
デジタルトランスフォーメーション(DX)におけるソフトウェアの側面とダイバーシティ・インクルーシブに関する研究実践動向
 
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
 
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
人生100年・60年カリキュラム時代のDX人材育成: スマートエスイー 2021年度成果および2022年度募集
 
スマートエスイーコンソーシアムの概要と2021年度成果紹介
スマートエスイーコンソーシアムの概要と2021年度成果紹介スマートエスイーコンソーシアムの概要と2021年度成果紹介
スマートエスイーコンソーシアムの概要と2021年度成果紹介
 
DXの推進において企業内に求められる人材やデジタル人材の育て方
DXの推進において企業内に求められる人材やデジタル人材の育て方DXの推進において企業内に求められる人材やデジタル人材の育て方
DXの推進において企業内に求められる人材やデジタル人材の育て方
 
対応性のある運用のパターン
対応性のある運用のパターン対応性のある運用のパターン
対応性のある運用のパターン
 
モデル訓練のパターン
モデル訓練のパターンモデル訓練のパターン
モデル訓練のパターン
 
パターンのつながりとAI活用成熟度
パターンのつながりとAI活用成熟度パターンのつながりとAI活用成熟度
パターンのつながりとAI活用成熟度
 
データ表現のパターン
データ表現のパターンデータ表現のパターン
データ表現のパターン
 
機械学習デザインパターンの必要性と機械学習ライフサイクル
機械学習デザインパターンの必要性と機械学習ライフサイクル機械学習デザインパターンの必要性と機械学習ライフサイクル
機械学習デザインパターンの必要性と機械学習ライフサイクル
 
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
青山幹雄先生を偲んで(開拓、理論、実践、コミュニティ&国際)
 

メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)

  • 2. 鷲崎 弘宜(わしざきひろのり) http://www.washi.cs.waseda.ac.jp/ 再利用と品質保証を中心にソフトウェアエンジニアリングの研究、教育、社会展開 • 早稲田大学グローバルソフトウェアエンジニアリング研究所 所長 • 早稲田大学基幹理工学部情報理工学科准教授 • 国立情報学研究所客員准教授 • 論文: ICSE, ICSR, ASE, ARES, Agile, SPLC, SEKE, PLoP他 対外活動 • ETロボコン本部 審査アドバイザ • 日本科学技術連盟ソフトウェア品質管理研究会副委員長 • 電子情報通信学会ソフトウェアサイエンス研究会幹事 • ISO/IEC JTC1 SC7 WG20 国内委員会主査 • SEMAT Japan Chapter Chair • IEEE CS Japan Chapter Secretary • 運営: ASE, ICST, SEKE, ICMT, XP, PROFES, APSEC, PLoP, AsianPLoP他 執筆など • 『演習で学ぶソフトウェアメトリクスの基礎』『ソフトウェア品質知識体系 SQuBOK』『ソフトウェアパターン入門 – 基礎から応用へ -』 • 『AspectJによるアスペクト指向プログラミング入門』ほか TS-# TS-7 2
  • 3. 本チュートリアルの目標 • メトリクスの基本概念と主要なもの、および落と し穴を理解する • GQM(Goal-Question-Metric)法の基礎を理 解し、自分なりの価値観を得る • 事例を通じてGQM法の適用に基づくゴール指 向のソフトウェア品質の測定評価と改善の流れ を理解する TS-# TS-7 3
  • 5. メトリクス(Metric / Metrics) • 測定の方法と尺度 – 方法: 属性(測定可能な特徴)の尺度上の値や分類への 対応付け – 尺度: 値や分類の集合 • 測定できない事柄は、管理できない(T. DeMarco) – ソフトウェア工学 = ソフトウェアの開発、運用、および保 守に対する系統的で規律に基づいた定量的アプローチ [SWEBOK] – Prj成功率 31% → 定量的評価導入Prj 46% [矢口08] メトリクス 測定方法 …… …… …… 測定尺度 測定プロセス 測定結果 (値、分類) [SWEBOK] 松本吉弘 監訳: ソフトウェアエンジニアリング基礎知識体系―SWEBOK2004, オーム社, 2005. [矢口08] 矢口竜太郎, 吉田洋平: 成功率は31.1%, 日経コンピュータ12月1日号, 2008. TS-# TS-7 5
  • 6. 測定対象のエンティティ • プロセス – 入力を出力に変換するアクティビティ(活動)の集合 • プロダクト – アクティビティから出力される成果物や文書 • リソース – アクティビティの実施に必要な人、もの、金などの資源 入力 プロダクト プロセス 出力 プロダクト リソース N.E. Fenton, and S. L. Pfleeger, Software Metrics: A Rigorous and Practical Approach, PWS Publishing 野中誠 , ソフトウェア技術者のためのメトリクス基礎, 2010, TopSEセミナー TS-# TS-7 6
  • 7. 主なメトリクス 名称 規模の把握、他のメトリ クスの正規化 機能量 規模の見積もり サイクロマティック複 雑度(CC) 制御フローグラフの経路 数 複雑さの把握 凝集度 モジュール内の要素のま とまり 複雑さの把握 結合度 モジュール間の結合関係 複雑さの把握 の多さ 欠陥密度(DD) 欠陥数 / 新規・変更LOC 品質の把握、開発プロセ ス全体の有効性把握 欠陥除去率(DRE) 欠陥摘出数 / 当該時点 欠陥数 開発プロセス全体や工 程の有効性把握 消化済みテストケー ス数 TS-# TS-7 コードの行数 ファンクションポイン ト(FP) プロセス 用途 コード行数(LOC) プロダクト 定義 当該時点までの消化済 みテストケース数 テストの進捗把握 7
  • 8. 測定方法 • ソフトウェアの抽象的な特定側面を捉える • 測定方法が異なれば測定結果も変わる 1:/* strncat()は、文字列srcからcount数の文字を文字列destに付加し、さ 2:らに終端にnull文字を付加する。重なるオブジェクト間でコピーしようとする 3:場合、動作は未定義である。*/ 4:char *strncat(char *dest, const char *src, size_t count) 5:{ 6: char *temp=dest; 7: if (count) { 8: while (*dest) 9: dest++; 10: while ((*dest++=*src++)) { 11: if (--count ==0) { 12: *dest=‘¥0’; break; 13: } 14: } 15: } return temp; 16:} TS-# TS-7 8
  • 9. 例:サイクロマティック複雑度 (Cyclomatic Complexity: CC) • テキスト – プログラムの制御フロー上で他とは異なるリンク(エッ ジ)を持つ経路数 • ダイアグラム =2 • アルゴリズム – V(g) = e – n + 2 (ただし e: エッジ数、n: ノード数) – V(g) = bd + 1 (ただし bd: 二分決定数) 出典: 野中誠 , 鷲崎 弘宜,ソフトウェア技術者のためのメトリクス基礎, 2010, TopSEセミナー [Linda09] リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエア の測定と見積もりの正しい作法", 日経BP社 , 2009. TS-# TS-7 9
  • 10. メトリクスの使いどころ • 実態把握、問題の絞込み – 複雑さ、欠陥密度など • 予測、計画 – 工数見積もり、欠陥数の予測など ファンクション ポイント 凝集度 結合度 機能仕 様書 モジュール 設計 要求定 義 複雑度 欠陥密度 消化数 コード行数 ソース コード 設計 実装 欠陥票 テスト ケース テスト 工数、期間 TS-# TS-7 10
  • 11. 実態把握や問題絞込み 例: サイクロマティック複雑度 • ヒストグラム 件数 – 分布状況の把握 • 管理図 測定値 – 平均や範囲のばら つき – 異常の特定 TS-# TS-7 11
  • 12. 予測や計画 • 散布図 – 関係の把握 関数 再利 用率 • 関係性の分析 – 単回帰分析: 1つの説明変 数、1つの目的変数 – 重回帰分析: 2つ以上の説 明変数 – 2値データのロジスティック 回帰分析: 目的変数が0,1 被使用外部ファイル率 実測値 鷲崎弘宜, 小池利和, 波木理恵子, 田邉浩之, "C言語プログラムソースコード の再利用性測定法とその評価", ソフトウェアテストシンポジウム JaSST'09 TS-# TS-7 呼出し関数の数 重相関係数 =0.941 予測値 12
  • 13. メトリクスの落とし穴 • 信頼性: 「1件」「1行」が異なっている(かも) – 欠陥数、行数・・・ – 客観性の高い測定、自動測定 • 妥当性: 「実世界で測定」できることは「測定し たい概念」の一部に過ぎない – 多面的な捉え方、現物確認 – 測定・管理がプロジェクトに最重要とは限らない [DeMarco09] • 負のホーソン効果 – 本当に改善したいこと、目的指向 [DeMarco09]T. DeMarco, Software Engineering: An Idea Whose Time Has Come and Gone?, IEEE Software, 2009. TS-# TS-7 13
  • 15. 規模: コード行数(LOC)の留意点 • 測定モデルの一貫性 – NLOC, LLOC – CMU/SEI チェックリスト • 作成方法、出所 – 25%を超える修正は新規実装と同程度の工数 [Linda09] • 言語の違い – ビジュアル言語、オブジェクト指向: 手続き型ほど役立たない – 言語補正係数表によるファンクションポイントとの関係 [LOC/FP] (例: アセンブリ 320, Java 53, C 128, 表計算 6) • コメント比率 = コメント行数 / LOC – 12.6%を超えると、コメントなしコードの2倍欠陥潜在率 [阿萬12] [Linda09] リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ", 日経BP社 , 2009. CMU/SEI-92-TR-022. ESC-TR-92-022. Software Quality Measurement: Framework for Counting Problems and Defects. http://www.sei.cmu.edu/reports/92tr020.pdf 阿萬, “オープンソースソフトウェアにおけるコメント記述およびコメントアウトと フォールト潜在との関係に関する定量分析”, 情報処理学会論 文誌, 53(2), 2012. TS-# TS-7 15
  • 16. 規模: ファンクションポイント法 • 内部の処理や解決策ではなく問題の扱い – システムの入出力、インタフェース、データファイルといった「代理」 (プロキシ)の数え上げ – 複雑さや環境などの難易度係数で調整 • 機能規模測定(Functional Size Measurement) – ファンクションポイント法(FP法): 1979 オールブレクト – IFPUG(International Function Point Users Group http://www.ifpug.org )結成、標準化 – 技術独立・初期段階で利用可 ⇔ 経験の必要性、主観性・属人性 入力 ユーザ 測定対象アプリケーション 照会 データファイル 外部アプリ ケーション インタ フェース 出力 TS-# TS-7 16
  • 17. 複雑さ: サイクロマティック複雑度など • 欠陥、保守やテストの困難さの検討 – レビュー・テスト必要箇所の特定、工数見積もり • 関数内: サイクロマティック複雑度 – 20が欠陥含まれやすさ閾値 – [鷲崎10] 1 推奨、2~9 許容 • モジュール内: 凝集度 =2 – 単一機能 ← データ中心 ← 機能中心 ← 無関係 – LCOM(Lack of Cohesion in Methods) < 2~5 [Chidamber94]: 参照変数が共通しないメソッド組み合わせ 数 - 共通ありの組み合わせ数 • モジュール間: 結合度 – データ渡し ← 制御フラグ渡し ← グローバルデータ – ファンアウト≦ 7±2 [SESSAME] [SESSAME07] SESSAME WG2, 組込みソフトウェア開発のためのリバースモデリング, 翔泳社, 2007. [Chidamber94] S.R.Chidamber and C.F.Kemerer, “A Metrics Suite for Object-Oriented Design”, IEEE Trans. Software Eng., vol. 20, no. 6, pp.476-493, June 1994 [鷲崎10]鷲崎弘宜,田邉浩之, 小池利和,”ソースコード解析による品質評価の仕組み“, 日経エレクトロニクス, 2010年1月25日号 TS-# TS-7 17
  • 18. 欠陥: DD, DRE • 欠陥数、欠陥発見・摘出数 – 実測、動的・静的予測 – 時間あたりの場合は単位に注意 • 欠陥密度 (Defect Density: DD) = 欠陥数 / 新規・変更LOC – 品質把握、プロセス全体のパフォーマンス把握 – ドメインや稼働時間の相違の考慮が必要 • 欠陥除去率(Defect Removal Efficiency: DRE) = 当該工程欠陥除去数 / 当該工程で存在した欠陥数 – 各欠陥摘出工程の欠陥摘出能力把握、改善 – 各欠陥の作り込み・原因工程の記録必要あり [Linda09] リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエア メトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法", 日経BP社 , 2009. TS-# TS-7 18
  • 20. Goal-Question-Metric (GQM) パラダイム • 明確に目標を据えて、目標に対して必要なメトリクスを対応 付けるゴール指向(目標指向)な枠組み • 目標(Goal): 測定上の目標 • 質問(Question): 目標の達成を評価するための質問 • メトリクス(Metric): 質問に回答するために必要な定量的デ ータを得るための主観的・客観的メトリクス 目標達成評価 G. 目標 Q. 質問 測定する事柄 の決定 答え M. メトリクス 測定値 測定結果の 解釈 収集データ R. van Solingen, E. Berghout, “The Goal/Question/Metric Method” McGraw-Hill Education, 1999; ISBN 0-07709-553-7. TS-# TS-7 20
  • 21. GQMモデル(グラフ)の例 G Q2 Q1 • 目標 M1 M2 M3 – G. コードクローン含有の観点から保守性の低いコードを 特定できている。 • 質問 – Q1: コードクローンは存在するか? → M1, M2 – Q2: 発見されたコードクローンは保守上有害か? → M3 • メトリクス – M1: ソースコードの全体的な重複度 – M2: モジュール単位のコードクローン含有率 – M3: コードクローンに対するマネージャの主観的評価 リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009. V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994) 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012. TS-# TS-7 21
  • 22. GQMの拡張 • 上位/ビジネスゴール (参考: GQM+Strategies) – 測定上のGoalの上位ゴール • 仮定(Hypothesis, Assumption) – Question導出にあたり仮定している事柄 – A. 要求が不安定であれば設計は頻繁に変更される。 • 解釈(Interpretation) – もし「条件式」ならば「Goalはこのように達成・未達成」 – I. もしLOCが少なすぎず、かつ、設計変更回数が一定 以上ならば、要求が不安定な可能性がある。 • メカニズム(Mechanism) – 収集・報告責任者、収集・報告頻度、必要なインフラ – 例: マネージャが毎週レポートを参照して・・・ リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と 見積もりの正しい作法", 日経BP社 , 2009. Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012. TS-# TS-7 22
  • 23. 仮説や解釈を伴う例 G. 特定プロジェクトにおける要求の不安定さを把握できている A. 要求が不安定であれば コードは頻繁に削除を 伴って変更される I. FCt が極端に大きくなく、かつ、 FCdが以前よりも大きいのであれ ば、要求が不安定な可能性あり A. 要求が不安定であれば コードは大きく変更される I. FLa が極端に大きくなく、かつ、 FLdが以前よりも大きいのであれ ば、要求が不安定な可能性あり Q. ソースファイルの 変更頻度はいくらか? FCt. 一週間以内の ファイル更新回数 ・・・ FCd. 一週間以内の削除 を伴うファイル更新回数 Q. ファイルの変更 規模はいくらか? FLa. 一週間以 内の追加行数 FLd. 一週間以 内の削除行数 Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012. TS-# TS-7 23
  • 24. GQM+Strategies: 組織目標・戦略・測定上の目標 • 事実(Context)や仮定 (Assumption)を明示 して戦略結びつけ • 組織上位から下位まで 連鎖 • 測定上の目標を掲げた GQMグラフを紐づけ定 量評価 • IESEによる開発、ツー ルあり • 早稲田大学ゴール指 向経営研究会、ITC 研 究会 開始(’13~) Basili, V.R., et al. “Linking Software Development and Business Strategy Through Measurement,” IEEE Computer, Vol.43, No.4, pp.57-65, 2010. 新谷勝利、平林大典: “企業・組織の目標達成とIT 導入計画の整合化を実現するための手法推進”、 SEC Journal、2012. TS-# TS-7 GQMグラフ 目標ツリー Q M Q 組織上位の目標 M G 事実・仮定 組織上位の戦略 組織中位の目標 Q M Q M G ・・・ 組織中位の戦略 組織下位の目標 Q Q M M Q M G G Q M 24
  • 25. 目標 ビジネス レベル 顧客満足度を向上 できている GQM+Strategies グリッドの例 製品の品質が 高ければ・・・ 製品の品質を改善 戦略 する ソリューション 事業部 (ソフトウェア レベル) 鷲崎弘宜、”ゴール指向の測定評価と留意 – GQMパラダイムと拡 張 -”、メトリクス公団、Vol.1、TEF東海メトリクス勉強会、2013. 顧客からの不具合 報告を削減できて いる テスト効率を改善 する ソフトウェアの保守 性を改善する 品質保証 チーム テストプロセスを 改善する TS-# 開発チーム 開発時にコードの 保守性評価を20% 改善できている G: コードの 保守性を定量 評価できている Q1 M1 Q2 M2 25
  • 27. 規模や複雑さから品質診断へ G. 信頼性 目標 G. 保守性 G. 効率性 G. 移植性 G. 再利用性 再利用性 G. 解析性 G. 変更性 G. 安定性 G. 試験性 移植性 言語 独立 言語 依存 副質問 Q. 処理が複雑 すぎないか? Q. 処理が構造 化されているか? ・・・ 各種ツール M. コールグラフ M. サイクロ ・・・ で測定 階層の深さ マティック複雑度 メトリクス プログラム ソースコード …… … …… … 効率性 保守性 Q. 複雑な文を記 述していない か? Q. 制御構造が ・・・ 複雑すぎない か? 質問 信頼性 ・・・ M. 関数内の ・・・ 戻り点の数 …… … …… … [Adqua] http://www.ogis-ri.co.jp/product/b-08-000001A6.html 鷲崎弘宜,田邉浩之,小池利和,ソースコード解析による品質評価の仕組み,日経エレクトロニクス 2010/1/25 TS-# TS-7 27
  • 28. 対象例: ETロボコン・コード改善 • 規模: 1481 ELOC, 18クラス, 121関数 • サイクロマティック複雑度の大きい関数をリストアップ • しかし「数」だけでは問題は分からない → 対象の詳細調査へ 品質副特性 得点 79.3 偏差値 38.7 得点 偏差値 46.2 得点 84.3 偏差値 61.5 偏差値 35.8 サイクロマ ティック複雑度 関数の 物理行数 50.0 得点 関数名 89.3 解析性 品質特性 ファイル名 12 55 Tactics.cpp getDriver(DriveStatus::eDifficultKind) 12 51 StepDriver.cpp drive(bool) 11 119 SeesawDriver.cpp drive(bool) 8 100 GarageDriver.cpp driveIn(void) 8 73 TASK(TaskDrive) 40.9 7 91 Magi.cpp 46.8 getDriveStatus() 7 37 PositionDecision.cpp updateLocation() 69.3 6 81 自クラスを使用する他クラスの種類数 Tactics.cpp 70.4 ~Tactics(void) 5 15 34.5 クラスの実行コード行数 35.6 変更性 78.6 偏差値 decideSynthetic() 関数の実行コード行数 得点 Magi.cpp 36.1 保守性 安定性 試験性 Question 処理が複雑すぎないか 処理が構造化されているか 要素間の結合度は低くなって いるか 要素の規模は適切か 得点 44.5 99.5 偏差値 37.7 46.5 メトリック Main.cpp 制御フローグラフの最大ネスト数 サイクロマティック複雑度 break等のないswitch文の数 使用する他クラスの種類数 75.9 59.1 48.1 43.7 ファイル内の関数の数 クラス内のメソッド数 TS-# TS-7 得点 91.0 85.6 鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 78.1 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日 28
  • 29. //============================================================================= // 難所走行状態の更新 void Magi::decideSynthetic() { // 次に目指す難所を取得 ChangePoint p = mStrategy.getChangePoint(); // 事前に登録した判定クラスから難所を取得 int decideCount = 0; for (SINT i = 0; i < mNumOfJudge; i++) { if (mJudgeAddressTable[i]->decideHard(p)) { decideCount++; } } if (decideCount >= 1) { switch (p.getPointKind()) { case ChangePoint::SEESAW_IN: mDifficultKindBuf = DriveStatus::SEESAW; mCangeCount = 0; break; case ChangePoint::SEESAW_OUT: mDifficultKindBuf = DriveStatus::LINETRACE; mCangeCount = 0; break; case ChangePoint::STEPS_IN: mDifficultKindBuf = DriveStatus::STEPS; mCangeCount = 0; break; case ChangePoint::STEPS_OUT: mDifficultKindBuf = DriveStatus::LINETRACE; mCangeCount = 0; break; case ChangePoint::OUTCOURSE_GARAGE: mDifficultKindBuf = DriveStatus::OUTCOURSE_GARAGE; mCangeCount = 0; break; case ChangePoint::INCOURSE_GARAGE: mDifficultKindBuf = DriveStatus::INCOURSE_GARAGE; mCangeCount = 0; break; default: break; } // 目指す難所を更新する mStrategy.next(); } // 難所判定後、時間差で走行を切替えるケースに備える if (mCangeCount > 0) { mCangeCount--; } else if (mCangeCount == 0) { mCangeCount--; // 走行切替 mStatus.setDifficultKind(mDifficultKindBuf); } //============================================================================= // 走行ステータスに応じて走行クラスを返却 Driver* Tactics::getDriver(DriveStatus::eDifficultKind kind) { Driver* drive; drive = 0; switch(kind) { case DriveStatus::LINETRACE: if(mLineTraceDriver == 0) { mLineTraceDriver = new LineTraceDriver(mMaimai, mPid); } drive = mLineTraceDriver; break; case DriveStatus::SEESAW: if(mSeesawDriver == 0) { mSeesawDriver = new SeesawDriver(mrGyro, mMaimai, mPid); } drive = mSeesawDriver; break; case DriveStatus::STEPS: if(mStepDriver == 0) { mStepDriver = new StepDriver(mrGyro, mMaimai, mPid); } drive = mStepDriver; break; case DriveStatus::OUTCOURSE_GARAGE: if(mGarageDriver == 0) { mGarageDriver = new GarageDriver(mPositionDecision); } drive = mGarageDriver; break; case DriveStatus::INCOURSE_GARAGE: if(mGarageDriver == 0) { mGarageDriver = new GarageDriver(mPositionDecision); } drive = mGarageDriver; break; default: if(mLineTraceDriver == 0) { mLineTraceDriver = new LineTraceDriver(mMaimai, mPid); } drive = mLineTraceDriver; break; } return drive; } 鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日 } TS-# TS-7 29
  • 30. 「数」から問題・原因の特定へ • 散らばり or もつれあい • 「難所に関する処理・責務(関心事)」のパッケージ横断な散らばり 判定処理系 走行系 切替ポイントを 取得する 戦略 + 3重多数決 + + + 目標切替ポイント取得() : 切替ポイント 1 走行ステータス更新() : 走行ステータス 開始判定() : boolean 総合判定() : void 1 + + 初期化() : void 走行開始() : void 1 * 1 1 + 走行クラス取得(走行ステータス) : 走行 走る 生成する 走行ステ ー タ ス 審判 + + 走行 1 3 灰色検知フラグ 座標 推定時間 戦術 - 難所を判定する 切替ポ イン ト - 走行クラスを 取得する Ma in 走行ステータスを取得する - 4 IN/OUTフラグ + + 難所判定(切替ポイント) : boolean フェイルセーフ判定(走行ステータス) : boolean getter() : void setter() : void 走行 + 位置判定 <<enum>> 走行種別 色判定 - 現在時間 - 現在位置 - 現在色 + - 時間判定(推定時間) : void 時間更新() : void + - ロケーション判定(座標) : void 現在位置更新() : void + - 灰色検知(灰色検知フラグ) : void 現在色更新() : void 1 コ ン ポ ー ネン ト 現在座標を 取得する 1 ライトセンサ値を 取得する + <<enum>> 難所種別 キャリブレーション 走行 停止 - ライントレース 階段 シーソー通過 ガレージイン 1 1 ライトセンサ値を 取得する 1 補正ライトセンサ値 + 1 定周期ライトON() : void 定周期ライトOFF() : void 補正ライトセンサ値取得() : void 1 イン テ リジ ェン トモ ー タ ー PID制御 1 + - 補正係数 + + PID算出() : void 進行方向取得() : 進行方向 モーター出力補正() : void モーター出力設定(右出力, 左出力) : void 1 1 センサ値を 取得する E C ROBOT API 回転数を取得する センサ値を 取得する 1 1 タ ッチセン サ + センサ値取得() : boolean 1 タ イマー + 時間取得() : 時間 センサ値取得() : ジャイロセンサ値 モーター値を設定する 1 2 ライトセン サ ジ ャイロ セン サ + モーター値を 設定する 進行方向を 取得する 1 - 現在座標取得() : void + + シ ー ソー 通過走行 ガレ ー ジ イン 走行 ま いま い式 ロ ケー シ ョン 時間を取得 する 1 1 1 センサ値を 取得する - 階段走行 走る() : void 1 時間判定 ライン トレ ー ス走行 センサ値取得() : ライトセンサ値 ランプ設定(ON/OFF) : void 2 モー タ ー + + モーター出力設定(出力) : void 回転数取得() : 回転数 鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 2011年9月5日 TS-# TS-7 30
  • 31. <<enum>> 走行種別 改善結果 - 走行ステー タ ス - キャリブレーション 1 走行 停止 1 Ma in IN/OUTフラグ + + getter() : void setter() : void 1 1 + + 走行を開始する 初期化() : void 1 走行開始() : void 判定処理系 走行系 1 戦術 3重多数決 難所を判定する 難所判定(切替ポイント) : boolean 1 走行 + • 関心事の局 所化 • 保守性改善 + - 走行開始() : void 1 1 1 難所を判定する ライン トレ ー ス 走 行 3 1..* {ordered} 審判 + + +構成要素 階段走行 走行 難所判定(切替ポイント) : boolean フェイルセーフ判定(走行ステータス) : boolean + + 走る() : void 切替ポイント取得(IN/OUT) : 切替ポイント 1 シ ー ソー 通 過 走 行 1 0..1 +入時 0..1 +出時 時間判定 位置判定 - 現在時間 - 現在位置 - 現在色 + - 時間判定(推定時間) : void 時間更新() : void + - ロケーション判定(座標) : void 現在位置更新() : void + - 灰色検知(灰色検知フラグ) : void 現在色更新() : void Question 得点 偏差値 ガレ ー ジ イン 走 行 色判定 メトリック 切 替 ポ イン ト - 灰色検知フラグ 座標 推定時間 得点 処理が構造化されているか 要素間の結合度は低くなって いるか 要素の規模は適切か 制御フローグラフの最大ネスト数 98.7 42.7 7 .5 UP 75.6 46.1 47.9 62.7 47.4 サイクロマティック複雑度 55.2 break等のないswitch文の数 90.8 使用する他クラスの種類数 52.0 48.0 68.8 自クラスを使用する他クラスの種類数 67.7 関数の実行コード行数 処理が複雑すぎないか 37.6 クラスの実行コード行数 39.6 ファイル内の関数の数 7 .1 UP 87.6 8 .4 UP 3 .1 UP 3 .6 鷲崎, 阿佐美, 田邉, ETロボコンの事例で学ぶモデル活用の効能: 第2回参加チームの事例,日経エレクトロニクス, 81.1 2011年9月5日 クラス内のメソッド数 UP TS-# TS-7 31
  • 33. まとめ • ソフトウェア開発の厳しさとメトリクスの重要性 – 開発の管理、品質把握と改善 • メトリクスの限界を知り意思決定に役立てる – 測定方法、信頼性、妥当性、負のホーソン効果 – 基本的なメトリクス: 規模、複雑性、欠陥 • GQMによる目標指向の測定 – 測定と改善のプロセス – GQM+Strategiesによる組織目標へのひもづけ TS-# TS-7 33
  • 34. • メトリクス全般 – リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と見 積もりの正しい作法", 日経BP社 , 2009. • GQM – 鷲崎弘宜、”ゴール指向の測定評価と留意 – GQMパラダイムと拡 張 -”、メトリクス公団、Vol.1、TEF東海メトリクス勉強会、2013. – 楠本真二、肥後芳樹: “GQMパラダイムを用いたソフトウェアメトリ クスの活用”、コンピュータソフトウェア、29(3)、pp.29-38、2012. – Basili, V., Caldiera, C., and Rombach, D.: “Goal, Question, Metric Paradigm, Encyclopedia of Software Engineering,” Vol.1, pp. 528–532, 1994. • GQM+Strategies – Basili, V.R., Lindvall, M., Regardie, M., Seaman, C., Heidrich, J., Munch, J., Rombach, D., Trendowicz, A.: “Linking Software Development and Business Strategy Through Measurement,” IEEE Computer, Vol.43, No.4, pp.57-65, 2010. – 新谷勝利、平林大典: “企業・組織の目標達成とIT導入計画の整 合化を実現するための手法推進”、SEC Journal、2012. • 事例 – 鷲崎弘宜, 田邉浩之, 小池利和, “ソースコード解析による品質評価 の仕組み”, 日経エレクトロニクス, 2010年1月25日号, 2010. – 鷲崎弘宜, 阿左美勝, 田邉浩之, “モデル活用の効能: 第1回 モデ ルを書く意味”~ “モデル活用の効能: 第4回 参加チームの事例 3″,日経エレクトロニクス, 日経BP社, 2011年8月8日号~11月号 TS-# TS-7 34