測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み公開用

測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み

早稲田大学グローバルソフトウェアエンジニアリング研究所所長

国立情報学研究所客員准教授

ISO/IEC/JTC1/SC7/WG20 Convenor

IEEE Computer Society Japan Chapter Chair

SEMAT Japan Chapter Chair

鷲崎弘宜

（資料作成協力: 本田澄） http://www.washi.cs.waseda.ac.jp/

わしざきひろのり

日本オペレーションズ・リサーチ学会信頼性研究会 2015年6月19日

http://www.washi.cs.waseda.ac.jp/

目次

• ソフトウェア品質とメトリクスの落とし穴・コツ

• 時間変化と不確定性を考慮した信頼性モデル

• まとめ

2

ソフトウェア品質とメトリクス

• 測定の方法と尺度

• ソフトウェア品質: 使用時に必要性を満たす能力を決定する属性（測定可能な特徴）全体 [ISO25000]

• 成功率 31% → 定量的評価導入 46% [矢口08]

3 [矢口08] 矢口竜太郎, 吉田洋平: 成功率は31.1%, 日経コンピュータ12月1日号, 2008.

要求定義

設計実装テスト

機能仕様書

ファンクションポイント

モジュール設計

凝集度結合度

ソースコード

複雑度コード行数

欠陥票

欠陥密度

テストケース

消化数

工数、期間

落とし穴「ホーソン効果」

4 nicolasdsampson.com, Observe And Learn: The Magic Of Paying Attention http://nicolasdsampson.com/wp-content/uploads/2012/10/2010_12_06_observe-learn-magic-paying-attention.jpg

http://nicolasdsampson.com/wp-content/uploads/2012/10/2010_12_06_observe-learn-magic-paying-attention.jpg











I. 解釈（評価基準）

コツ「ゴール指向のメトリクス定義」

• Goal-Question-Metric（GQM）パラダイム

M. メトリクス

G. 目標

Q. 質問

測定対象（データ）

達成評価

答え

測定値

5 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012.

リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009.

V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994)

コツ「横に広げて多面的に見る」

6

鷲崎弘宜,田邉浩之,小池利和,ソースコード解析による品質評価の仕組み,日経エレクトロニクス 2010/1/25

[Adqua] http://www.ogis-ri.co.jp/product/b-08-000001A6.html

保守性

モジュール性再利用性修正性・・・

コールグラフ階層の深さ

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

関数内の戻り点の数

処理が複雑すぎないか？

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

…… … …… …

…… … …… …

・・・

・・・・・・

G. 目標

対象

M. メトリクス

Q. 質問

http://www.ogis-ri.co.jp/product/b-08-000001A6.html







ヤフーとの共同研究事例: 測定による保守性・機能性評価・改善

7 H. Nakai, et al. Initial Industrial Experience of GQM-based Product-Focused Project Monitoring with Trend Patterns, APSEC'14

落とし穴「有効な組織アクションに繋がっていない」

8

製品の信頼性や使いやすさを改善して、顧客満足度

を10%上げるぞ！

経営層

テスト効率を上げます。保守性も改善させます。

開発部不具合数、さらには、プログラムの複雑度を測定します。

品質保証部

落とし穴「有効な組織アクションに繋がっていない」

9

製品の信頼性や使いやすさを改善して、顧客満足度

を10%上げるぞ！

経営層

テスト効率を上げます。保守性も改善させます。

開発部不具合数、さらには、プログラムの複雑度を測定します。

品質保証部

コツ「縦に、アクションに繋げる」 GQM+Strategies

10

顧客満足度10%向上

製品の信頼性を改善する

製品の使いやすさを改善する

不具合指摘を20%削減

テスト効率を改善する

保守性を改善する

顧客満足度調査

不具合データ

プログラムの複雑さ

OG. 上位組織目標

S. 戦略

S. 戦略

OG. 下位組織目標

M. メトリクス

参考: Jens Heidrich, Adam Trendowicz, “測定を基にした、ソフトウェア戦略とビジネス目標の整合” IPA/SEC資料

M. メトリクス

11

リクルート住まいカンパニーとの共同研究事例: 新規事業の組織目標、根拠、戦略の整合

落とし穴「未来が今の延長とは限らない」

12

コツ「時間変化や不確定性を考慮した予測」

13 K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14 K. Honda, et al., Predicting the Release Time Based on a Generalized Software Reliability Model (GSRM), COMPSAC’14

0

0.2

0.4

0.6

0.8

1

1.2

0 0.2 0.4 0.6 0.8 1

発見した欠陥の割合

時間

Model 1-1

Model 2-1

Model 3-1

コツ「仮定の明示とシステム改善」

14

計画

測定

評価

改善

N. Tsuda, et al. Iterative Process to Improve GQM Models with Metrics Thresholds to Detect High-risk Files, SANER'15 Doctoral

M. 呼び出し先モジュール数

G. 変更されやすい箇所を特定できている

Q. モジュールの依存関係はどの程度か？

M. 呼び出し元モジュール数

A. あちこちと依存するモジュールは変更されやすい

コマツとの共同研究事例: 機械学習によるメトリクス・システム改善

15

10 25

300

150

M. 関数の数

M. 実

行行

数

OK

NG

71

M. 関数の数

M. 実

行行

数

OK

NG

△ OK, ○ NG

N. Tsuda, et al. Iterative Process to Improve GQM Models with Metrics Thresholds to Detect High-risk Files, SANER'15 Doctoral

目次



• まとめ

16

0

5

10

15

20

25

0 0.2 0.4 0.6 0.8 1

欠陥数

時間

予測

実際

信頼性

信頼性モデル

③全欠陥数の95%の欠陥が発見されれば信頼性を保証するとする．

①発見した欠陥を累積として日ごと，または週ごとで測定

②実データを基に欠陥数を予測する

おおよそ，95%の欠陥が発見できる．

例: ロジスティックモデル

17 K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14 K. Honda, et al., Predicting the Release Time Based on a Generalized Software Reliability Model (GSRM), COMPSAC’14

• 仮定 1. 欠陥の発見に割ける時間は一定ではなく，時間変化を持つ． 2. 単位時間当たりに発見できる欠陥の数は，不確定な要素を持つ．

一般化信頼性モデル GSRM

ロジスティック

ホワイトガウシアンノイズ

18

統計的解析モデル確率過程

不確定な項時間に関する項

確率過程

統計的解析モデル

K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14 K. Honda, et al., Predicting the Release Time Based on a Generalized Software Reliability Model (GSRM), COMPSAC’14

時間変化

0

0.5

1

1.5

2

0 0.5 1

α①

0

0.5

1

1.5

2

α③

0

0.5

1

1.5

2

0 0.5 1

α②

単位時間当たりに発見できる欠陥の数が一定

単位時間当たりに発見できる欠陥の数がある時間で変化する

単位時間当たりに発見できる欠陥の数が徐々に増加する


不確定性

初期段階で不確定要素が強く影響を与える

状況にかかわらず常に影響を与える

終期段階で不確定要素が強く影響を与える．

-0.3

-0.2

-0.1

0

0.1

0.2

-15

-10

-5

0

5

10

15

0 0.2 0.4 0.6 0.8 1

-0.5

-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3


単位時間当たりに発見できる欠陥数が一定であり，発見された欠陥の累積数が増えれば不確定な影響が大きくなる．(Model 1-1)

単位時間当たりに発見できる欠陥数が一定であり，不確定な影響が常に一定．(Model1-2)

単位時間当たりに発見できる欠陥数が一定であり，発見された欠陥の累積数が増えれば不確定な影響が小さくなる．(e.g. 開発チームが成熟する)(Model 1-3)

単位時間当たりに発見できる欠陥数がt1 で変化し，発見された欠陥の累積数が増えれば不確定な影響が大きくなる．(e.g. 新しいメンバーがt1 で加わる)(Model 2-1)

単位時間当たりに発見できる欠陥数がt1 で変化し，不確定な影響が常に一定．(Model2-2)

単位時間当たりに発見できる欠陥数がt1 で変化し，発見された欠陥の累積数が増えれば不確定な影響が小さくなる．(Model 2-3)

単位時間当たりに発見できる欠陥数と，不確定性の影響が発見された欠陥の累積数が増えれば大きくなる．(e.g. 時間とともに開発メンバーが増える)(Model 3-1)

単位時間当たりに発見できる欠陥数が時間とともに増加し，不確定な影響が常に一定．(Model 3-2)

単位時間当たりに発見できる欠陥数が時間とともに増加し，発見された欠陥の累積数が増えれば不確定な影響が小さくなる．(Model3-3)

-0.3

-0.2

-0.1

0

0.1

0.2

-15

-10

-5

0

5

10

15

0 0.2 0.4 0.6 0.8 1

-0.5

-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3

0

0.5

1

1.5

2

0 0.5 1

α①

0

0.5

1

1.5

2

0 0.5 1

α②

0

0.5

1

1.5

2

α③


リリース可能時期の幅をもった予測

0

10

20

30

40

50

60

70

80

90

0 2 4 6 8 10 12 14

#D

efe

cts

Time

ActualData

Our model

-

+

22

95%の欠陥の発見 K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14 K. Honda, et al., Predicting the Release Time Based on a Generalized Software Reliability Model (GSRM), COMPSAC’14

ヤフーとの共同研究事例: 開発後の欠陥数予測

23

欠陥数予測の精度（RSS）開発中盤で予測した

リリース可能時期の幅 [日数] モジュール NHPP S字 GSRM NHPP GSRM messaging 50626 31510 12240 1309 58 storage 409 592 232 219 87

UI 47250 8160 2416 3308 17 common 357852 6824 7124 58162 - consumer 13168 622 514 - - control-api 1913 1500 784 421 15 data-api 9560 3359 1001 444 72


ヤフーとの共同研究事例: 開発中の（動的な）欠陥予測

予測欠陥数の変動欠陥数と予測モデル

不確定性

K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14

時間変化

25

0.25

-0.2

0.15

-0.1

0.05

0

0.05

0.1

0.15

0.2

-15

-10

-5

0

5

10

15

0 0.5 1

-0.5

-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3

K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14

ヤフーとの共同研究事例: 意思決定への応用

26

abyss_data-api abyss_data-api abyss_data-api

モジュール現在・欠陥数

予測・総欠陥数

予測・現欠陥数

予測・リリース可能日

M1 147 144 134 156日目

ほぼ全ての欠陥を検出できたようだ。ここからはテストよりもデバッグに注力しよう。

欠陥数総欠陥数の予測予測の誤り


• 予測、実績の自動可視化と共有 • 3モデル併用: GSRM、ロジスティック、ゴンペルツ

住友電工との共同研究

住友電工との共同研究

富士通グループとの共同研究工程・種類別欠陥数

0

50

100

150

200

250

300

350

400

450

500

0

8

16

24

32

40

48

56

64

72

80

88

96

10

4

11

2

12

0

12

8

13

6

14

4

15

2

16

0

16

8

17

6

18

4

19

2

20

0

20

8

21

6

22

4

23

2

24

0

24

8

25

6

26

4

27

2

28

0

28

8

29

6

30

4

31

2

32

0

32

8

33

6

34

4

Bu

g数

日数

Component Integration Test Unit Test Other HW-SW Integration Test PreFIT FIT Regression Test A1_ST1 B_ST1 A1_ST2

終期に見つかる種類

日数

欠陥数

※全欠陥の85%を網羅する主要な10の工程・欠陥種類を選択

中期に見つかる種類

開発初期に見つかる種類

富士通グループとの共同研究工程・種類別 ⇔ 全体のGSRM適用比較

0

100

200

300

400

500

600

0 100 200 300 400

Bu

g数

日数

工程・種類別の適用

Selected Data Separate GSRM

0

100

200

300

400

500

600

0 100 200 300 400

Bu

g数

日数

全体への単純適用

Selected Data All GSRM

OK

OK

外れ

外れ

種類別全体

残差平方和(RSS) 49900 90177 種類別が45%小さい

日数日数

欠陥数欠陥数

目次



• まとめ

31

まとめ • 品質把握と改善上のメトリクスの落とし穴へのコツ

– GQM ゴール指向と横の広がり

– GQM+Strategies 縦の整合とアクションへの繋がり

– 仮定の明示と改善

• 時間変化と不確定性を考慮した予測

– ツール化、実開発における意思決定の支援へ

– 時間変化、不確定性の有用性検証はこれから

IPA/SECセミナー 7月29日 http://sec.ipa.go.jp/seminar/ 『ゴール指向経営』で的を射たIT投資、利益を生む組織に

「GQM+Strategies」の活用で組織内の整合性確保と定量的管理を実現

早稲田大学・Fraunhofer IESE ほか 9月4日（予定）

「ソフトウェア品質とゴール指向測定・改善」セミナー（仮）

http://sec.ipa.go.jp/seminar/

http://sec.ipa.go.jp/seminar/

測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み 公開用

Software

Transcript of 測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み 公開用

測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み公開用

Transcript of 測定と予測を通じたソフトウェア品質評価と改善の実践的取り組み公開用