Weitere ähnliche Inhalte Ähnlich wie WACATE09冬_線・Maniax_発表版 (20) Mehr von 久仁朗 山本(旧姓 村上) (11) WACATE09冬_線・Maniax_発表版1. Copyright (C) 2009 WACATE All rights reserved
線・Maniax♪
村上 くにお(WACATE実⾏委員)
2009年12⽉12⽇
於 マホロバ・マインズ
2. Copyright (C) 2009 WACATE All rights reserved
はじめに
•皆さんもご存知のように、ソフト
ウェアテストには様々な「線」が
関わっています。
•その「線」について数式をまじえ
て簡単にお話させていただきます。
•業務で⾒慣れているたくさんの
「線」について、もう⼀度⾒直し
てみましょう♪
3. Copyright (C) 2009 WACATE All rights reserved 3
セッションの流れ
• とりあえず・・・基礎の「キ」
• いつも⾒ている「線」について
• これまでの「線」を踏まえて
5. Copyright (C) 2009 WACATE All rights reserved
a linear function(一次関数)
• 式 :
-10
-9
-8
-7
-6
-5
-4
-3
-2
-1
0
1
2
3
4
5
6
7
8
9
10
-10 -9 -8 -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10
a=1/2,
b=+1
a=1/2,
b=-1
a=2,
b=+1
6. Copyright (C) 2009 WACATE All rights reserved
quadratic function(二次関数)
• 式 :
-20
0
20
40
60
80
100
-20 -18 -16 -14 -12 -10 -8 -6 -4 -2 0 2 4 6 8 10 12 14 16 18 20
a=1/2,
b=0,
C=-10
a=1,
b=0,
C=0
a=-2,
b=0,
C=60
a=1,
b=-10,
C=100
7. Copyright (C) 2009 WACATE All rights reserved
a parabola(放物線)
• 式 :
-20
-10
0
10
20
30
40
50
60
70
80
-20 -18 -16 -14 -12 -10 -8 -6 -4 -2 0 2 4 6 8 10 12 14 16 18 20
8. Copyright (C) 2009 WACATE All rights reserved
a trigonometrical function(三角関数)
-1.5
-1
-0.5
0
0.5
1
1.5
-2.0p -1.5p -1.0p -0.5p 0.0p 0.5p 1.0p 1.5p 2.0p
Sin
Cos
• 式 :
11. Copyright (C) 2009 WACATE All rights reserved
テスト実施予定消化件数
• 式 :総テスト件数/(人数×平均実施件数(件/人日))
• 時期:テスト実施開始 ~ テスト実施終了
テスト開始時を基点とする
0
5000
10000
15000
20000
25000
累計件数
予定消化
件数
12. Copyright (C) 2009 WACATE All rights reserved
テスト実施予定工数
• 式 :総テスト実施工数/(人数×平均実施工数(時間/人日))
• 時期:テスト実施開始 ~ テスト実施終了
テスト開始時を基点とする
0.0
200.0
400.0
600.0
800.0
1000.0
1200.0
1400.0
累計
工数
予定消化
工数
13. Copyright (C) 2009 WACATE All rights reserved
残テスト予定件数
• 式 :残テスト件数/(人数×平均実施件数(件/人日))
• 時期:テスト実施開始 ~ テスト実施終了
テスト終了予定日を基点とする
0
5000
10000
15000
20000
25000
残テスト
件数
実施可能
テスト件数
14. Copyright (C) 2009 WACATE All rights reserved
残テスト予定工数
• 式 :残テスト実施工数/(人数×平均実施工数(時間/人日))
• 時期:テスト実施開始 ~ テスト実施終了
テスト終了予定日を基点とする
0.0
200.0
400.0
600.0
800.0
1000.0
1200.0
1400.0
必要工数
投入可能
工数
15. Copyright (C) 2009 WACATE All rights reserved
Learning Curve(学習曲線)
• 学習曲線(がくしゅうきょくせん)とは練習量と反応時間の関係を
表す曲線である。
RTを反応時間、Nを練習量、a、bを課題によって変わる変数とす
るとき次の式が成り立つ。ピロリとアンダーソンはa、bの実測値をそ
れぞれ1.40、0.24と求めた。この式はかなり普遍的に成り立つ。
「ウィキペディア」から抜粋
16. Copyright (C) 2009 WACATE All rights reserved
Learning Curve(学習曲線)
• 式 :
(ピロリとアンダーソンの実測値(a=1.4、b=0.24))
• 時期:トレーニング ~ テスト実施終了
18. Copyright (C) 2009 WACATE All rights reserved
Bug found to date(バグ発生グラフ)
0
100
200
300
400
500
600
解決済み
修正済み
未処理
• 時期:テスト実施開始 ~ テスト実施終了
テスト開始時を基点とする
19. Copyright (C) 2009 WACATE All rights reserved
Bug found to date(バグ発生グラフ)
• 時期:テスト実施開始 ~ テスト実施終了
テスト開始時を基点とする
0
100
200
300
400
500
600
未処理
修正済み
解決済み
全体
20. Copyright (C) 2009 WACATE All rights reserved
バグ確認対応工数
• 式 : 人数×平均修正確認件数(件/人日)
• 時期:テスト実施開始 ~ テスト実施終了
テスト終了予定日を基点とする
0
100
200
300
400
500
600
未処理
修正済み
バグ修正
対応数
バグ確認
対応数
21. Copyright (C) 2009 WACATE All rights reserved
Software Reliability Growth Curve(信頼度成長曲線)
• Software Reliability Growth Curve(信頼度成長曲線:しんらい
どせいちょうきょくせん )とは、横軸に日付、テスト時間、またはテス
トケース数、縦軸に累積バグ発見数をとったグラフ。S字の成長曲
線を描くことが多い。プロジェクトの進捗状態の確認などに用いる。
決定論的モデルとして、最小二乗法でゴンペルツ曲線やロジス
ティック曲線に近似したり、確率モデルとして、非同次ポアソン過
程モデルなどで表したりすることにより、現在の状況から今後の予
想を立て、テスト進捗管理、バグ収束率の予測、残バグ数の予
測などに用いることもある。
※収束を見る場合に、横軸に日付を使った場合、テストをしてい
ないからバグが 出ないのか、テストをしてもバグが出ないのかの区
別がつかないという問題がある。
「ウィキペディア」から抜粋
22. Copyright (C) 2009 WACATE All rights reserved
Sigmoid curve(S字曲線)
• 式 :
• 時期:テスト実施開始 ~ テスト実施終了
23. Copyright (C) 2009 WACATE All rights reserved
Least squares method(最小二乗法)
• 式 :
• 時期:テスト実施開始 ~ テスト実施終了
0
100
200
300
400
500
600
未処理
修正済み
解決済み
全体
多項式 (全体)
24. Copyright (C) 2009 WACATE All rights reserved
Gompertz curve(ゴンペルツ曲線)
• 式 :
• 時期:テスト実施開始 ~ テスト実施終了
25. Copyright (C) 2009 WACATE All rights reserved
Logistic curve(ロジスティック式)
• 式 :
• 時期:テスト実施開始 ~ テスト実施終了
27. Copyright (C) 2009 WACATE All rights reserved
コード実装予定行数
• 式 :総コード実装予定行数/
(人数×平均コード実装行数(行/人日))
• 時期:コード実装(コーディング)開始
~ ファンクションフィックス(基本実装終了)
0
50000
100000
150000
200000
250000
300000
実装
予定消化
28. Copyright (C) 2009 WACATE All rights reserved
コード実装予定工数
• 式 :総コード実装予定工数/
(人数×平均コード実装工数(時間/人日))
• 時期:コード実装(コーディング)開始
~ ファンクションフィックス(基本実装終了)
0.0
500.0
1000.0
1500.0
2000.0
2500.0
3000.0
実装工数
予定消化
工数
29. Copyright (C) 2009 WACATE All rights reserved
残コード実装予定行数
• 式 :残コード実装予定行数/
(人数×平均コード実装行数(行/人日))
• 時期:コード実装(コーディング)開始
~ ファンクションフィックス(基本実装終了)
0
5000
10000
15000
20000
25000
残ケース数
実施可能
ケース数
30. Copyright (C) 2009 WACATE All rights reserved
残コード実装予定工数
• 式 :残コード実装予定工数/
(人数×平均コード実装工数(時間/人日))
• 時期:コード実装(コーディング)開始
~ ファンクションフィックス(基本実装終了)
0.0
200.0
400.0
600.0
800.0
1000.0
1200.0
1400.0
必要工数
投入可能工数
31. Copyright (C) 2009 WACATE All rights reserved
コード変更行数
• 式 :総実装行数×(バグ検出率+ベースライン以降の変更係数)
• 時期:ベースライン確定後、テスト開始後(バグ修正時)
~ RC(コードフィックス)
0.0
1000.0
2000.0
3000.0
4000.0
5000.0
6000.0
7000.0
8000.0
9000.0
変更行数
変更予定
消化行数
32. Copyright (C) 2009 WACATE All rights reserved
コード実装+変更(バグ対応)行数
• 時期:コード実装(コーディング)開始 ~ RC(コードフィックス)
0
50000
100000
150000
200000
250000
300000
実装行数
予定消化
行数
34. Copyright (C) 2009 WACATE All rights reserved
ARON法
• 式 : (納品プログラムの命令数÷月あたり開発命令数)×
(サポート人員+1)×余裕率(定数:1.25)
(規模)
(人月)
35. Copyright (C) 2009 WACATE All rights reserved
Myers法
• 式 : (開発ステップ数÷月あたり開発ステップ数)×
(サポート人員+1)
(規模)
(人月)
36. Copyright (C) 2009 WACATE All rights reserved
COCOMO (’81) (constructive cost model)
• ソフトウェア開発の工数・期間の見積もり手法。1981年にバリー・
ベーム(Barry Boehm)博士が提唱した。
具体的には開発するソフトウェアの予想されるコード行数に、エン
ジニアの能力や要求の信頼性といった補正係数を掛け合わせて
(名目工数×努力係 数)、開発に必要な工数、期間、要員、
生産性を算出する。実装言語の違いに左右されず、客観的な
数値を算出できるといわれている。また基本の数式モデルに つい
ても、実際のプロジェクトにおける適用結果をフィードバックし、精
緻化を重ねている。
※ COCOMOでは分析・設計工程の見積もりが不可能なことに加え、組織全体
の開発能力の成熟度や、開発・テスト・検証を重ねる「繰り返し型開発プロ
ジェクト」に適していないという問題があった。そこで従来のCOCOMOを拡張し、
ファンクションポイント法やCMMの概念を取り入れ、より正確な工数算出を実
現したCOCOMO IIが提唱されている。
「@IT情報マネジメント用語事典」から抜粋
37. Copyright (C) 2009 WACATE All rights reserved
COCOMOの拡張形
名称 内容
COCOMOⅡ
(.2000)
EasrlyDesignやPostArchitectureといった見積時期をサポート(テストエンジニアは
PostArchitectureモデルを利用・拡張可能な点が優れている)
COCOTS いわゆる市販部品(Commercial-off-the-Shelf (COTS) Software Components)のイ
ンテグレーションを考慮したコストモデル
COPSEMO ウォーターフォールモデル以外のRUP(Rational Unified Process)といった、近年のライフサ
イクルモデルにも対応可能なコスト調整方法
CORADMO RAD(Rapid Application Development)の工数と開発期間の調整方法を示したモデル
COQUALMO 欠陥密度や結果としての品質予測まで含めた品質要因での工数調整モデル。1975年
にCapers Jones氏が発表したソフトウェア欠陥混入/除去モデルの概念から影響を受
けることで、品質面(と主に技術リスク面)での工数/コストの調整方法えお提案している
COPROMO 開発生産性向上に主眼を置いた見積り調整モデル。プロセス改善やエンジニアリング技
術の投入によってシステム投資効果を検証する場合に非常に有効
COSYSMO システムエンジニアリングコストモデルと呼ばれる。特にサービスシステム全体へのモデル適
用を可能とした点はほかに類を見ない
「ソフトウェアテスト Vol.7 ソフトウェアテストの見積技術[入門編] 」から抜粋
38. Copyright (C) 2009 WACATE All rights reserved
COCOMO
• 式 :
– MM :開発工数(人月)
– KDSI :開発規模(KLOC)
0.00
2000.00
4000.00
6000.00
8000.00
10000.00
12000.00
14000.00
16000.00
18000.00
20000.00
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
開発工数(人月)
MM
(PM)
「え~、全部テストするんですか!」から抜粋
39. Copyright (C) 2009 WACATE All rights reserved
COCOMO
• 式 :
– MM :開発工数(人月)
– TDEV :開発期間(月)
0.00
20.00
40.00
60.00
80.00
100.00
120.00
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
開発期間(月)
TDEV
(M)
「え~、全部テストするんですか!」から抜粋
40. Copyright (C) 2009 WACATE All rights reserved
COCOMO
• 式 :
– MM :開発工数(人月)
– TDEV :開発期間(月)
– FSP :開発人員(人)
0.00
20.00
40.00
60.00
80.00
100.00
120.00
140.00
160.00
180.00
200.00
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
開発人員(人)
FSP
(P)
「え~、全部テストするんですか!」から抜粋
41. Copyright (C) 2009 WACATE All rights reserved
COCOMO
• 式 :
– MM :開発工数(人月)
– KDSI :開発規模(KLOC)
– Prod :生産性(KLOC/人月)
0.00
0.05
0.10
0.15
0.20
0.25
0.30
0.35
0.40
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
生産性(KLOC/人月)
Pord
(K LOC/PM)
「え~、全部テストするんですか!」から抜粋
42. Copyright (C) 2009 WACATE All rights reserved
Function point method(ファンクションポイント法)
• ソフトウェアの機能規模を測定する手法の1つ。開発工数の見積
もりに利用 される。ソフトウェアの“機能”を基本にして、その処理
内容の複雑さなどからファンクションポイントという点数を付けてい
き、ソフトウェアのすべての機能 のポイントを合計して規模や工数
を導き出すもの。
「@IT情報マネジメント用語事典」から抜粋
• ファンクションポイント法 拡張形
• IBM法(1979)
• DeMarcoのBang法(1982)
• IBM法改訂版(1984)
• SPR法(1985)
• SPR逆算法(1986)
「ソフトウェア開発の定量化手法」から抜粋
• SPRフィーチャーポイント法(1986)
• Reifer法(1987)
• Mark Ⅱ法(1988)
• IFPUG法(1990・1994)
• Boeing 3D法(1994)
43. Copyright (C) 2009 WACATE All rights reserved
Function point method(ファンクションポイント法)
• 計算方法①
1. 機能などを数える際のタイプとどこまで数えるかを明確にする
2. 次に、評価の対象となるシステムについて、ユーザーファンクションタイプと
呼ばれる「外部入力」「外部出力」「外部照合」「内部論理ファイル」「外
部インターフェイス」の数をファンクション数としてカウントする
3. その機能がどのファイルをどれく らい参照するのか、やりとりを行うかのかを
数えるもので、プログラムを作る前の段階のDFDやERDなどから見積もる
ことができる
4. そして、それぞれの難易度を3段階(容易・普通・複雑)で評価して点数
化(ポイント化)して、そのポイントに次の係数を掛けて合算した値を基準
値とする
「@IT情報マネジメント用語事典」から抜粋
容易 普通 複雑
外部入力
外部出力
外部照合
内部論理ファイル
外部インターフェイス
44. Copyright (C) 2009 WACATE All rights reserved
Function point method(ファンクションポイント法)
• 計算方法②
5. 次に、システム特性に関して以下の項目でその複雑さを 0~5の6段階で
評価し、それを合計して調整値を算出する
・処理の複雑性 ・複数サイトでの使用 ・変更の容易性
・データ通信 ・トランザクション量 ・システム運用性
・オンライン更新 ・性能条件 ・再利用性 ・オンライン更新
・高負荷構成 ・インストール容易性 ・分散データ処理
・エンドユーザーの効率性
6. 導き出した基準値と調整値を基に、以下の式でファンクションポイントを算
出する
ファンクションポイント=基準値×(0.65+調整値/100)
「@IT情報マネジメント用語事典」から抜粋
45. Copyright (C) 2009 WACATE All rights reserved
Function point method(ファンクションポイント法)
• 式 :機能的規模(ファンクション)×複雑度×影響要因
「ソフトウェア開発の定量化手法」から抜粋
46. Copyright (C) 2009 WACATE All rights reserved
COSMIC-FPP法
• COSMIC-FFP(The Common Software Measurement
International Consortium - Full Function Point)は、ファンク
ションポイント法(機能規模測定法)の一つ。組込み系・リアルタ
イム系を問わず、ソフトウェアの規模や開発工数を、プログラミング
言語などに依存せず定量的に見積もる方法の国際規格で、
ISO/IEC 19761として2003年に制定され、日本では2006年に
JIS X 0143としてJIS規格化された。
「ウィキペディア」から抜粋
47. Copyright (C) 2009 WACATE All rights reserved
Putnam model(Putnam法)
• 式 :
– Effort:ライフサイクル総工数
– Size:コード行数
– Time:開発期間
– Productivity:生産性
– B:補正係数(1978年当時、12000)
「Wikipedia」から抜粋
49. Copyright (C) 2009 WACATE All rights reserved
注意!
• いろいろな「線」をご紹介しましたが、
「線」を書くことが重要ではありません。
• 「線」から今後の予想をし、どのような
アクションを⾏うかが重要です。
• 「線」の基礎を踏まえてどのように仕事
に利⽤するかを考えて⾒ましょう♪
50. Copyright (C) 2009 WACATE All rights reserved
バグ発生グラフ vs リリース
• とるべき対応・処理
– 異常要因分析(前回との差分、テスト対象機能、環境)
– テスト計画(スケジュール)の変更(テストタスクの入れ替え、対象ビルドの変更)
0
100
200
300
400
500
600
解決済み
修正済み
未処理
FF1 FF2 FF3 FF4 FF5 FF6 FF7 FF8 FF9 FF10
リリース後、急に
バグ発生頻度が
上がった場合
51. Copyright (C) 2009 WACATE All rights reserved
バグ発生(不良摘出)状況管理図
• とるべき対応・処理
① 異常要因分析、デバック強化
② 異常要因分析、目標値再検討
0
50
100
150
200
250
300
350
400
450
500
全体
管理上限
管理下限
累乗 (全体)
多項式 (管理上限)
多項式 (管理下限)
②不良多発見込
みまたは、デバック
進度良好
①目標達成困難
「ソフトウェア品質保証の考え方と実際」から抜粋
52. Copyright (C) 2009 WACATE All rights reserved
例①:テスト実施
• テストケースの優先度
(流用度(新規性)+複雑度/規模+機能重要度(システム視点・ユーザー視点))
• テストフェーズ毎の優先度
(ユニット・結合:技術要件が高、システム・受入:ビジネス要件が高)
• 機能のクリティカルパスによる、実施順
• 複雑度 vs バグ発生率
• 機能毎 vs バグ発生率
• 変更量 vs バグ発生率
53. Copyright (C) 2009 WACATE All rights reserved
例②:テスト設計
• 機能数 vs テストケース数
• 複雑度* vs テストケース数
• 新規性 vs テストケース数
• フェーズ毎 vs テストケース数
*循環的複雑度(Cyclomatic complexity)( McCabe数)
– M = E − N + 2P
• M = 循環的複雑度、 E = グラフのエッジ数、 N = グラフのノード数、 P = 連結されたコンポーネントの数
ウィキペディアから抜粋
54. Copyright (C) 2009 WACATE All rights reserved
おまけ
• バグのダメージレベルについて・・・
皆さん、どのように設定されていますか?
① 出荷停止・高・中・低(Hi・Mid・Low)
② 重要度×出現頻度
③ FMEA(Failure Mode and Effect Analysis)
影響度×出現頻度×(検出・探索難易度+対策・修正難易度)
68. Copyright (C) 2009 WACATE All rights reserved
ESQR(EmbeddedSystem development Quality Reference)①
• 2-5 品質目標値設定表
「組込みソフトウェア開発向け品質作り込みガイド」から抜粋
当該タイプの
参考値
補正ベース値 設定目標値
作業充当率
仕様レビュー 4
設計レビュー 4
コードレビュー 1.5
テストレビュー 1.5
テスト 5
レビュー 4
作業実施率
仕様レビュー 2.4
設計レビュー 2.4
コードレビュー 1.2
テストレビュー 2
テスト 17
レビュー 8
プロセス品質評価指標
69. Copyright (C) 2009 WACATE All rights reserved
ESQR(EmbeddedSystem development Quality Reference)②
• 2-5 品質目標値設定表
「組込みソフトウェア開発向け品質作り込みガイド」から抜粋
プロダクト品質評価指標 当該タイプの
参考値
補正ベース値 設定目標値
ドキュメント
ドキュメントボリューム
要求仕様書 4
設計書 10
テスト仕様書 10
ドキュメントバランス
要求仕様書 -
設計書 -
テスト仕様書 -
コード
コードボリューム
ファイル行数
2
KLOC
この値以下で
あること
関数の行数
160
LOC
この値以下で
あること
コード特性
制御文記述率 5
コメント行記述率 5
コーディングルール逸脱率 100
テスト
テスト十分性
テスト密度 25
不具合収束率 0.01
動作完全性
不具合除去率 3
70. Copyright (C) 2009 WACATE All rights reserved
ESQR(EmbeddedSystem development Quality Reference)③
• 2-5 ドキュメントバランスメトリクス
「組込みソフトウェア開発向け品質作り込みガイド」から抜粋
ドキュメントバランスメトリクス
項目No 内容 参考値 設定目標値
要求仕様書 R1. 全体の記述量 100
R2. 対象ユーザとその使い方に関する記述 5
R3. 動作環境条件に関する記述量 10
R4. 主な機能に関する記述量 40
R5. 安全に関する記述、並びに非機能に関する記述量 30
R6. システム全体構成に関する記述量 10
R7. 例外処理に関する記述量 5
設計書 D1. 全体の記述量 R1×3
D2. システム全体構成に関する記述量 5
D3. 機能ブロックの構成に関する記述量 5
D4. 機能ブロックの詳細に関する記述量 50
D5. インタフェース・データに関する記述量 20
D6. 例外処理に関する記述量 20
テスト仕様書 T1. 全体の記述量 R1×3
T2. テスト環境に関する記述 5
T3. テストの手順・条件に関する記述 10
T4. 正常系に関する記述 35
T5. 異常系・例外処理に関する記述 45
T6. テスト完了基準に関する記述 5
71. Copyright (C) 2009 WACATE All rights reserved
ESQR(EmbeddedSystem development Quality Reference)④
• 3-2 品質指標一覧
「組込みソフトウェア開発向け品質作り込みガイド」から抜粋
ID 略称 名称 計測方法または計算式
PR10 RSRE 仕様レビュー作業充当率 仕様レビュー工数/仕様作成工数
PR11 RDRE 設計レビュー作業充当率 設計レビュー工数/設計作成工数
PR12 RCRE コードレビュー作業充当率 コードレビュー工数/コード作成工数
PR13 RTRE テストレビュー作業充当率 テストレビュー工数/テスト準備・確認工数
PR14 RTWE テスト作業充当率 テスト工数/開発全工数
PR15 RORE レビュー作業充当率 全レビュー工数/開発全工数
PR20 ERSR 仕様レビュー作業実施率 仕様レビュー工数/ソースコード全行数
PR21 ERDR 設計レビュー作業実施率 設計レビュー工数/ソースコード全行数
PR22 ERCR コードレビュー作業実施率 コードレビュー工数/ソースコード全行数
PR23 ERTR テストレビュー作業実施率 テストレビュー工数/ソースコード全行数
PR24 ERTW テスト作業実施率 テスト工数/ソースコード全行数
PR25 EROR レビュー作業実施率 全レビュー工数/ソースコード全行数
PD10 RSDV 要求仕様書ボリューム率 要求仕様書ボリューム/ソースコード全行数
PD11 RDDV 設計書ボリューム率 設計書ボリューム/ソースコード全行数
PD12 RTDV テスト仕様書ボリューム率 テスト仕様書ボリューム/ソースコード全行数
PD20 BSDD 要求仕様書バランス 要求仕様書内の各パートのページ数/要求仕様書ページ数の総和
PD21 BDDD 設計書バランス 設計書内の各パートのページ数/設計書全体ページ数の総和
PD22 BTDD テスト仕様書バランス テスト仕様書内の各パートのページ数/テスト仕様書ページ数の総和
ドキュメントバランス品質評価指標
品質指標(Evaluation Metrics)
プロセス品質評価指標:作業充当率
プロセス品質評価指標:作業実施率
プロダクト品質評価指標:ドキュメント品質評価指標
ドキュメントボリューム品質評価指標
72. Copyright (C) 2009 WACATE All rights reserved
ESQR(EmbeddedSystem development Quality Reference)⑤
• 3-2 品質指標一覧
「組込みソフトウェア開発向け品質作り込みガイド」から抜粋
ID 略称 名称 計測方法または計算式
PD30 FLOC ファイル行数 基礎指標のファイル行数と同じ
PD31 MLOC 関数の行数 基礎指標の関数の行数と同じ
PD32 ROCS 制御文記述率 制御文数/ソースコード全行数
PD33 ROCL コメント行記述率 コメント行数/ソースコード全行数
PD34 RDCR コーディングルール逸脱率 コーディングルール逸脱数/ソースコード全行数
PD40 DOTI テスト密度 テスト項目数/ソースコード全行数
PD41 ROFC 不具合収束率 最終10%のテスト期間の不具合発見率/当初90%のテスト期間の不具合発見率
PD42 ROFE 不具合修正率 修正済み不具合数/検出不具合数
プロダクト品質評価指標:コード品質評価指標
品質指標(Evaluation Metrics)
コードボリューム品質評価指標
コード特性品質評価指標
プロダクト品質評価指標:テスト品質評価指標
テスト十分性品質評価指標
動作完全性品質評価指標
73. Copyright (C) 2009 WACATE All rights reserved
ESQR(EmbeddedSystem development Quality Reference)⑥
• 3-2 基礎指標
「組込みソフトウェア開発向け品質作り込みガイド」から抜粋
ID 略称 名称 計測方法または計算式
B10 TLOC ソースコード全行数 ファイル毎の行数の総和
B11 FLOC ファイル行数 各ソースファイルに記述されたソースコードの規模
B12 MLOC 関数の行数 ソースコードを構成する関数一つあたりのソースコードの規模
B13 NOCS 制御文数 ファイル毎の制御文数
B14 CLOC コメント行数 ファイル毎のコメント行数
B15 NDCR コーディングルール逸脱数 コーディングルールを逸脱した延べ数
B20 VOSD 要求仕様書ボリューム 仕様に関するドキュメントのページ数の総和
B21 VODD 設計書ボリューム 設計に関するドキュメントのページ数の総和
B22 VOTD テスト仕様書ボリューム テストに関するドキュメントのページ数の総和
B30 RETO 全レビュー工数 レビュー工数の総和
B31 RESP 仕様レビュー工数 仕様レビューにかかった工数の総和
B32 REDE 設計レビュー工数 設計レビューにかかった工数の総和
B33 RECO コードレビュー工数 コードレビューにかかった工数の総和
B34 RETP テストレビュー工数 テストに関するレビューにかかった工数の総和
B35 PETO 開発全工数 開発にかかった工数の総和
B36 PESP 仕様作成工数 仕様作成にかかった工数の総和
B37 PEDE 設計作成工数 設計にかかった工数の総和
B38 PECO コード作成工数 コード作成にかかった工数の総和
B39 PETP テスト準備・確認工数 テストの準備・確認作業にかかった工数の総和
B3A PETE テスト工数 テストにかかった工数の総和
工数ボリューム基礎指標
ドキュメントボリューム基礎指標
ソースコードボリューム基礎指標
基礎指標(Basic Metrics)
74. Copyright (C) 2009 WACATE All rights reserved
ESQR(EmbeddedSystem development Quality Reference)⑦
• 3-2 基礎指標
「組込みソフトウェア開発向け品質作り込みガイド」から抜粋
ID 略称 名称 計測方法または計算式
B40 NOTI テスト項目数 テスト項目数の総和(ただし、実施していること)
B41 NOET テスト実施項目数 実施したテスト項目数の総和(重複を含む)
B42 NODF 検出不具合数 単体テスト後に検出した不具合の総和
B43 NOEF 修正済み不具合数 検出した不具合の内、修正した不具合の総和
B44 ROFD 不具合発見率 検出不具合数/テスト実施項目数
テストボリューム基礎指標
基礎指標(Basic Metrics)
76. Copyright (C) 2009 WACATE All rights reserved
まとめ
• ベテランの⽅々は、ご紹介した
「線」の基礎を考慮して⽇々の仕事
をしています。
• 若⼿の皆さんも、いろいろな「線」
を使ってテストをしてみませんか?
• 「線」の基礎(成り⽴ち・利⽤⽅
法)を踏まえて、もっと「線」を活
⽤しましょう!!