JaSST’11 Hokkaido

品質エンジニアの思考回路－コードインスペクション編－

日本アイ・ビー・エム株式会社
グローバル・ビジネス・サービス
原 佑貴子© 2011 IBM Corporation

JaSST DO IT

はじめに

2

当発表の概要コードレビューの効率と効果を高めるためにメトリクス測定を併用するレビュー手法「IBM-QI法」について解説します

今回の対象

業界：
業務：
言語：
システム特性： 企業内部向けWebアプリケーション
コード本数： 500本

Takeaways

コードレビューの重要性と「大変だからやらない」という思い込みを排除すること

適用時の注意点

1. 当該コードレビュー技法のみで品質を断定しないこと
2. フォーマル・インスペクション等正式な手法と併用すること

想定利用者

品質エンジニア・テストエンジニア
開発プロジェクトPM・アーキテクト© 2011 IBM Corporation

JaSST DO IT

テーマ

闇雲にレビューしない戦略をもってレビューする3© 2011 IBM Corporation

JaSST DO IT

本日紹介するレビュー技法「IBM-QI法」とは？
 社外では以下のように紹介されています。
–2000年に日本アイ・ビー・エムのＱＡ組織で開発された、プロジェクト外部の第三者による目視の品質検証サービス。「QI:Quality Inspection」は、欠陥検出効率はほぼ従来のまま、品質検査工数を９０％削減しプロジェクト全フェーズ中での頻繁な検査が可能となる。成果物の早期欠陥除去、品質状況可視化、品質のばらつき抑止を実現し、安定したプロジェクト進捗とコスト超過予防を実現する。

4© 2011 IBM Corporation

JaSST DO ITQI効果) 実施速度スピード： コンペとの比較
Workload ( effort-days )A) 所要工数
160140・他社A

150 人日・IBM-QI

9 人日

Effort-days

120100B) 検出した欠陥の種類

80・フォーマル検査技法

6064 種類

40・IBM-QI

200562 種類
IBM J-QI

Other Competitor© 2011 IBM Corporation

JaSST DO IT

Quality Inspection activity : IBM-J QI (Later phase)４） 実修正

CommentRate
100.0%

 問題管理DB 変更管理DB 誤修正管理

90.0%
80.0%

LOC vs NCSS
70.0%

CommentRate

6000

5000

60.0%
50.0%
40.0%

プログラム作成本数推移

30.0%

1400

4000

120.00%

Lines

20.0%

1200

10.0%
0.0%
0500

1000

1000

2004/3Q, 1145

LOC
NCSS

3000
1500

2000

2500

3000

3500

4000

100.00%4500

ProgramID

80.00%

2000
作成本数

800

1000

2000/3Q, 688

2004/1Q, 911

60.00%
600
1996/1Q, 377
1992/3Q, 420

400

0

0

20.00%

0.00%

以DR1, □DR2, □DR3, □I0, □I1, □I2, □I3, □IT1, □IT2，□IDR1, □IDR2 ,□II1, □II2,

プロジェクト名：

モデレーター：システム／サブシステム名：

点検資料作成者：

対象仕様書／資料名：

インスペクター：プロジェクト名：

モデレーター：

システム／サブシステム名：

点検資料作成者：

対象仕様書／資料名：

Ｎo．

実施日： 年 月 日

作成年月日

所要時間:

場所：

書記：

実施日： 年 月 日

所要時間:

場所：

書記：
インスペクター

検出問題点

分類

解決策および備考

担当者

191Q
1984/

□RD,□ED,□ID,□IP,□ITa,□ITb,□ST□

ｲﾝｽﾍﾟｸｼｮﾝ種別：□ 新規／□再ｲﾝｽﾍﾟｸｼｮﾝ( 回目)

12 23 34 45 56 67 78 89 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298 309 320 331
ProgramID
200１）コード実測

実施局面：(Inspection Problem Log)

前84
19 /3Q85
19 /2Q86
19 /1Q86
19 /4Q87
19 /3Q88
19 /2Q89
19 /1Q89
19 /4Q90
19 /3Q91
19 /2Q92
19 /1Q92
19 /4Q93
19 /3Q94
19 /2Q95
19 /1Q95
19 /4Q96
19 /3Q97
19 /2Q98
19 /1Q98
19 /4Q99
20 /3Q00
20 /2Q01
20 /1Q01
20 /4Q02
20 /3Q03
20 /2Q04
20 /1Q04
20 /4Q05/3
Q

1

インスペクション問題記録票（兼追跡票）

40.00%

1985/2Q, 372

解決予定

完了日

：

修正作業量

潜入局面

確認日
0

お客様名
プロジェクト名

0

点検項目
項番

局面

A ： 約10分程度で点検可能(存在有無レベル)
B ： 約30分程度で点検可能
C : 点検には30分以上必要

1.

外部
設
計
局
面の作業計画2.

3.

２）インスペクション対象特定

1.

2.

定量分析・可視化
はずれ値（Outlier ）分析

3.

4.

目標設定
再点検日

38958
3.05E+08

Priority

点検対象

目標AB
B
B
CCA
B
B
B
B
A

0000000000000000000
00000

品質レベル
点検時 改善後

000000000000

B
B
B
A

111
155551
121B
B
B
B

1
11155555555C
CCCCC
B
B

111111115555555511511111BCCCCCCCCC

5555500050555555555000555555000040CCCCCCCCCCCC
C

1111
1000
10
1
1111
11
1
1000
1
1C
B
B
CC

100
1
1

500
555

点検結果コメント（レベル判定事由）

5:完璧（必須）, 4:ほぼ良（作成すべき）, 3:修正要_ケアレスミス ,2:修正要_品質の問題,
1:資料なしor確認できない , 0:(作成不要)*()内は目標値の場合。また目標は、5, 4, 0 のみで記入。

対象：1
対象外：0

作業手順／体制の妥当性と実現可能性
1.
マスタースケジュールが作成されている
2.
マスタースケジュール作成の根拠が明確で妥当である
3.
ＷＢＳが適切なレベルまで展開されている
4.
成果物の名称が詳細かつ具体的に定義されている
5.
成果物を作成する作業手順が明確で妥当である
6.
成果物の品質保証の仕組みが確立されている
7.
成果物の早期のインスペクション／ウォークスルーが計画されている
8.
各作業の成果物／中間成果物が明確である
9.
プロジェクトの体制が妥当であり実現可能である
10. 各作業単位で作業担当者・責任者が明確である（プロジェクト内部）
11. お客様との間の作業分担が明確であり合意されている
12. 人員の時期ごとの投入計画が妥当である
標準化
1.
作業手順のガイドの整備されている
2.
ツールの使用ガイドおよび表記や記述のレベルが明確なガイドがある3.
ネーミング、標準フォームを含む、ドキュメントの標準化がなされている
4.
標準化の責任者が明確となっている
プラットフォーム要件
1.
システム構成が明確である
2.
使用S/W（OS,Middleware,DBMS,TPMonitor,Language)が明確になっている
3.
開発用S/W(DevTool,Package,Parts,Framework)が明確になっている
4.
Application Architecture(Ｎ層モデル,C/Sアーキテクチャ・タイプ,HTTP,Socket,DCOM,CORBAなど ）が明確になっている
サブシステム分割
1.
インターフェースが極小化されている(ＤＦＤあるいはＥＲＤから判断できる）
2.
開発組織／チームを意識した分割がなされている
3.
物理条件(プラットフォーム,アプリケーション･アーキテクチャ,DBの配置)の反映が適切である
4.
サブシステムをひとつのプロセスとした上位ＮＰＭが作成されている
5.
サブシステム間のインターフェースが明確になっている
6.
サブシステム間で共有されるデータストアが明確である
7.
サブシステム間インターフェース一覧が作成されている
8.
外部エンティティとのインターフェース一覧が作成されている機能の適切な分割（トランザクション，コンポーネント，プログラムの識別）1.
リアル処理,バッチ処理が明確になっている
2.
使用するＳ／Ｗ，アーキテクチャを意識したコンポーネントが定義されている
3.
トランザクション（ＡＣＩＤ属性が保証される単位）が明確になっている
4.
クライアント機能とサーバー機能を意識した分割になっている
5.
コンポーネント間のインターフェースが明確になっている
6.
３層(n層)の場合は層間のプロトコルとインターフェースが定義されている
7.
コンポーネント間のインターフェースが極小化されるように分割されている
8.
開発チーム分担を考慮したコンポーネント分割となっている
9.
共通機能が定義され、ＡＰＩが明確になっている
10. 設計モデル表記(DFD、フェンスチャート、状態遷移図など)上でもAPIが明確になっている
機能記述
1.
処理のタイミングを意識した記述となっている
2.
すべてのイベントやプロセスに対応した記述が存在する
3.
Ｉｎｐｕｔデータ構造のＯｕｔｐｕｔデータ構造への変換として処理が記述されている
4.
データ・チェックの仕様が明確になっている
5.
if-then-else,switch,do-whileなど構造化ステートメントを用いて記述している
6.
コードの値による処理の違いがすべて表現されている
7.
elseに対する処理（その他の場合の処理、例外処理）が明確になっている
8.
処理の順序(Sequence)に意味のある記述となっている
9.
デッドロックが極力発生しないよう，処理の順序が考慮されている
10. DBの関連（１：Mなど）を意識した処理記述となっている
11. SQLが明確になっている
12. エラーへの対応が記述されている（エラーメッセージ含む）
13. 共通機能（共通コンポーネント）や部品を意識した記述となっている
ウィンドゥ仕様の明確化
1.
イベントごとのウィンドゥ遷移図が作成されている2.
イベント一覧（引数付き;ｏｋ,ｃａｎｃｅｌ,ｈｅｌｐなど含めたすべてのイベント)が作成されている
3.
ウィンドゥ・メニュー一覧が作成されている
4.
ウィンドゥ･レイアウトが作成されている
5.
ウィンドゥ上のデータ項目/ＤＢ対応表が作成されている

点検日
プロジェクトＩＤ

3
3
44
43
3
400044

協力会社毎に記載レベルにバラツキがある。

サブシステム構成が不明のため確認できない。
協力会社毎の役割分担を確認できない。
サブシステムの単位を確認できる資料がない。
同上
同上
同上
同上

記載レベルにバラツキがある。
網羅的な記載となっていない箇所がある。

記載が漏れている箇所がある。
記載が漏れている箇所がある。

53

外部設計３） インスペクション実施局面

6© 2011 IBM Corporation

JaSST DO IT

今日実施する手順：
本日は以下の手順でレビュー作業を実施します
1）受領 ： プロジェクトQCD状況確認
２）測定 ： 定量データ測定

３）仮説立案 ： 品質状況予測４）検証＆欠陥検出 ： 目視
５）可視化 ： 定量＆定性データ集計
６）対策立案 ： Projectへフィードバック

7© 2011 IBM Corporation

JaSST DO IT

8© 2011 IBM Corporation

JaSST DO IT

ツールの出力から得られる仮説：目視レビュー対象の選定
 サイズが大きく、複雑度が高いもの(IFの多いもの）
 サイズが大きく、コメント率が高いもの
 Try-Catch周辺（Try-CatchがあってFinallyがないもの他）
・・・など

9

© 2011 IBM Corporation

JaSST DO ITまとめ
 コードレビュー実施前に、必ずメトリクス測定を行うこと
 メトリクスデータから欠陥の仮説を立案してからレビューを行うこと
 欠陥の位置と種類を予測してサンプルを抽出すること

 レビューで得られた欠陥・傾向を全て記録すること
 矛盾する傾向があったらすぐにセカンドオピニオンを得ること
 ユーザーがほしいのは欠陥リストではなく「アクションプラン」

 短期間のレビューを繰り返し／継続して実施することが重要

10© 2011 IBM Corporation

JaSST DO IT

11© 2011 IBM Corporation