早稲田大学 &IESE&IPA/SEC 共催セミナー 2015 年 2 月 19 日 ( 早稲田大学 ) データに裏付けられた IT 経営とソフトウェア品質 ~ ゴール指向の測定改善および GQM+Strategies の実践 ~ ゴール指向の測定によるソフトウェア品質評価と改善の実践的取組み

(1)

ゴール指向の測定によるソフトウェア

品質評価と改善の実践的取組み

（三つのコツ、三つの事例）

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

鷲崎弘宜

Twitter: @Hiro_Washi

washizaki@waseda.jp

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

わしざきひろのり

早稲田大学&IESE&IPA/SEC共催セミナー 2015年2月19日（早稲田大学）データに裏付けられたIT経営とソフトウェア品質

(2)

• 早稲田大学グローバルソフトウェアエ

ンジニアリング研究所所長・准教授

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

• 情報規格調査会ISO/IEC SC7/WG20

主査

• IEEE CS Japan Chapter Chair

• SEMAT Japan Chapter Chair

• ACM-ICPC 2014 Tokyo Director

• IPSJ SamurAI Coding Director

• 運営: ASE, SEKE, SPLC, APSEC,

AsianPLoP…

• プログラム委員: ASE, ICST, …

• 論文: ICSE, ASE, CAiSE, ICST, …

2

(3)

早稲田大学グローバルソフトウェア

エンジニアリング研究所

• グローバル開発時代

のソフトウェアエンジ

ニアリング研究

• 鷲崎（所長）

• 東基衞（顧問）、筧、

深澤、岸、本田（所員

）

• 招聘研究員17 名

• 学生25名 (留学生5名

、中国、ノルウェー、メ

キシコ、インドネシア)

HITACHI

YAHOO!

Google

FUJITSU

NEC

TOSHIBA

OGIS-RI

Afrel

RECRUIT

Florida Atlantic University

Benesse

信州大学

東京大学

KOMATSU

(4)

FUJITSU Google FUJITSU

如何にソフトウェアを効率よく効果的に開発できるか?

如何に堅固な理論の上にプラクティスを構築できるか?

4

要求定義

コード解析

単体テスト

受入テスト

マネジメント

_教育

実装

Abstraction Modulari zation Auto mation _Reuse Visuali zation Formali zation

Software

基本設計

統合テスト

保守

品質管理

詳細設計

テスト環境と

検証

HITACHI YAHOO! NEC TOSHIBA OGIS-RI Afrel KOMATSU Florida Atlantic University Benesse 信州大学 NII

品質測定とマネジメント

アジャイル開発、パターン、教育に

おける実証研究

RECRUIT QUNIE

再利用と

開発環境

(5)

測定と品質マネジメント

Industrial Experience of GQM-based Product-Focused Project Monitoring (APSEC’14) Predicting Time Range Based on Generalized Software Reliability Model (APSEC’14) Iterative Process to Improve GQM Models with Metrics Thresholds (SANER’15 Doctoral)

再利用と開発環境

Stakeholder relationship analysis to refine GQM+Strategies models (PROFES’14) RefactoringScript: A Script for Composite Refactoring (SEKE’14)

A Tool to Suggest Similar Program Element Modifications (APSEC’14) Interactive Recovery of Requirements Traceability Links (CAiSE’15)

テスト環境と検証

Bug Localization for Re-engineered Industrial Software (ICST’14)

Validating Ajax Applications Using a Delay-Based Mutation Technique (ASE’14) Do open source software projects conduct tests enough? (PROFES’14)

Security and Privacy Behavior Definition for BDD (PROFES’14) Verification of Implementing Security Design Patterns (ARES’14)

Validating Security Design Pattern Applications (Int. J. Secure Soft. Eng. ‘15)

アジャイル開発、パターン、教育における実証研究

Network Analysis for Software Patterns (AGEIL’14)

Impacts of Personal Characteristic on Educational Effectiveness (CSEET’14) Programmable Robots as Programming Educational Tools (ACE’15)

(6)

品質とは

• 品質: あるものの特性または属性 [American

Heritage Dictionary]

• ソフトウェア品質: ソフトウェアの使用時に必

要性を満たす能力を決定する属性全体

[ISO9126-1][ISO25000][JIS0129-1]

– 属性: ソフトウェアの定性的/定量的に

測定

可能

な特徴

(8)

メトリクス（Metric / Metrics）

• 測定の方法と尺度

– 方法: 属性（測定可能な特徴）の尺度上の値や分類への

対応付け

– 尺度: 値や分類の集合

• 測定できない事柄は、管理できない（T. DeMarco）

– ソフトウェア工学 = ソフトウェアの開発、運用、および保

守に対する系統的で規律に基づいた定量的アプローチ

[SWEBOK]

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

…… …… …… 測定方法測定尺度

測定プロセス

メトリクス

測定結果

（値、分類）

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

(9)

メトリクスの使いどころ

• 現在: 把握、評価

• 未来: 予測、計画

要求

定義

設計

実装

テスト

機能

仕様書

ファンクション

ポイント

モジュール

設計

凝集度

結合度

ソース

コード

複雑度

コード行数

欠陥票

欠陥密度

テスト

ケース

消化数

工数、期間

(10)

12 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012. リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009. V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994)

(13)

コツ「多面的に測り、最後は現物」

G. 信頼性 G. 効率性 G. 保守性 G. 移植性 G. 再利用性 G. 解析性 G. 変更性 G. 試験性目標メトリクス M. コールグラフ階層の深さマティック複雑度 M. サイクロ M. 関数内の戻り点の数 G. 安定性・・・・・・ Q. 制御構造が複雑すぎないか ? 質問副質問 Q. 処理が複雑すぎないか？ Q. 処理が構造化されているか？ Q. 複雑な文を記述していないか？・・・・・・・・・ …… … …… … …… … …… … プログラムソースコード

(14)

落とし穴「値を信頼できるとは限らない」

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

(15)

I. 解釈

ダッシュボード

コツ「ツールで客観的に、組織で一貫」

M. メトリクス

G. 目標

Q. 質問

対象（データ）

評価

答え

測定値

モニタ

ツール

メトリクスシステム

(16)

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

(17)

コツ「不確実性を考慮した測定と予測」

• 予測における幅と種別

0 10 20 30 40 50 60 70 80 90 0 5 10 15

• 経験に基づく仮定明示

M. 呼び出し先

モジュール数

G. 変更されやすい

箇所を特定できている

Q. モジュールの依存

関係はどの程度か？

M. 呼び出し元

モジュール数

A. あちこちと依存するモ

ジュールは変更されやすい

(18)

コツ「メトリクスシステムの改善」

(19)

O

₁

O

₁₂

O

₂

O

₁₃

O

₁₂₃

O

₂₃

O

₃

O: Origin（由来）

Apache Foundation (1)

Oracle (2)

Sun (3)

OpenOfficeの場合

(24)

事例2（つづき）: メトリクスや由来から将来予測

25

コードの規模・

複雑さメトリクス

開発主体

変更回数

変更規模

欠陥

M. ファイル規模

M. 他ファイルとの呼び出し関係

・・・

(25)

事例3: コマツとの取り組み

保守性評価メトリクスシステム改善

I

A

Q

M

G

機械学習＋

人手精査

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

M

(27)

事例3（つづき）: 責務過多なファイル特定

10 25 300 150

M. 関数の数

M. 実行行数

OK

NG

71