資料１：ODCの分類一覧＋補足説明
DefectRemoval
どこのプロセスで
Activities
発見したか？
：アクティビティ （発見工程）

Triggers：トリガー

1.Design Rev（デザインレビュー）

仕様のレビュー

1.Design
Conformance（仕様適合)

2.CodeInspection
ソースコードのレ（コードインスペ ビュー
クション）

2.Logic/
Flow(論理／フロー)

不具合発生時の操作状況や環境、条件(刺激)修正の対象。どこが悪かったのか？

Qualifer：不具合の属性

どのように間違ったのか？
なぜ欠陥が入り込んだのか、その原因

Impact：影響

どのような影響を及ぼすか？

Target：ターゲット仕様と整合が取れているか

1.
Installability(
インストール)

インストールが完了できない

1.Requirement
顧客の要件
s（要件）

1. Missing(抜
抜け、漏れ
け漏れ)

フローそのものが、論理的におかしい

例えば、エラー番号2.
だけでなく、どんなServiceability( 障害が発生してい保守性)
るか分からない

2.Design（仕
様・設計）

(同左)

2.
Incorrect(不正確（誤り))

不正確、誤り3.Unit test（ユ関数単体テスト
ニットテスト）3.Backward
旧バージョンで動作
Compatibility( していたものが、現旧バージョン互 在のバージョンで動作しなくなった
換性)

3.
業界標準や社内
Standards(標 基準などに準拠
準)しない

3.Code（コー
ディング）

(同左)

3.
Extraneous(
無関係なものが混在)

例えば消し忘れなど、紛れ込んだ異物が原因4.Function
Test（機能テス 結合テスト
ト）4.Lateral
一般的な他のシCompatibility( ステムとのイン
一般的互換
ターフェースを利性)用する際の問題

不注意または悪意
4.
Integrity/Secu のある破壊、改ざん、または漏洩か
rity(完全性／ ら、制御やデータをセキュリティ)保護できない4.Build/Packa(同左)
ge（ビルド）5.System Test
（システムテス システムテスト
ト）

5.Concurrency マルチタスクに
(並行性)
関わる問題

5.
アップグレードな
Migration(マイ どシステム移行
グレーション) できない

5.Information
Development（メッセージ）

ユーザへの情報提供

6.Internal
記述漏れや記述
Document(内 誤りなど、ドキュ
部文書)
メントの問題6.
Reliability(信頼性)

6.National
Language
Support（言語）

マルチ言語対応

AGE：新規性

どの時点で間違ったのか？

安定して期待された役割を果たすことができない

7.Language
Dependency(
言語依存性)

文法や初期値、メ
モリ管理など、プロ
グラミング言語に起因する問題

7.
Performance( 速度など性能がパフォーマン
出ないス)

1. Base(従来)変更などしていない既存のもの8.SideEffect(副作用)

例えば、バグ修正による新たなバグ

8.
Documentation(ドキュメンテーション)

ユーザマニュア
ル・仕様書等に記載がないな
ど、説明がない

2. New(新規)

新規に作成したもの

9.RareSituations(レアケース)

めったに発生しない製品が顧客の明
9.
Requirements 示する期待を満(必要条件)
たしていない3.
Rewritten(書き直した際)

再設計または古い機能の書きなおしを行ったもの

10.Simple
Path(通常使用)

単純な抜け漏れ、通常利用ができない

例えばスパゲッ
10.
ティコードなど、
Maintenance(
修正が容易にで
メンテナンス)きない

1.
Assign/Init(割 変数の値
当/初期値)

11.Complex
Path(複合条
件での使用)

前後条件を考慮
できていない11.
Usability(ユー 使い勝手が悪い
ザビリティ)

2.
条件文のチェッ
Checking(チェク漏れック）

例えばエラー処
12.Coverage( 理や例外処理なカバレッジ)
ど、想定されるケースがない12.
Accessibility(
アクセシビリティ)

例えば障害のある人に情報を提供できるようになっていない3.
Alg/Method((同左)
アルゴリズム／
実装方法)

例えば同値や境
13.Variation( 界などパラメータ
バリエーション) の組合せによる問題

13.
Capability(ケイパビリティ)例えば、保存ボタンがあるのに保存できないなど、要求を処理する能力がない

4.
Func/Class/Obj
ect(関数/クラス (同左)
/オブジェクト)

14.Sequencin 繰り返し操作にg(連続操作) よる問題
各機能が独立して15.Interaction 実行すると正常に実行されるが、特定(相互作用)の組み合わせで失敗するなど

16.Workload/
負荷状態での問Stress(負荷／題
ストレス)
17.Recovery/
例外処理のリカ
Exception(リカバリ対応に問題
バリー／例外)Defect Type
：欠陥の種類

何を間違ったのか？

4. ReFixed(修 不具合の修正を
正時)
行った物

Source
発生源はどこ：ソース(出所） か？

5.
Timing/Serial(同左)(タイミング/シ
リアライズ)

1. Developed
In-House(自 自社開発
社開発)

6. Interface/OO Messages(インターフェース/オ 呼び出しミスなど
ブジェクト間メッ
セージ)

2. Reused
From Library(ラ ライブラリからのイブラリからの 再利用
再利用)

インスタンス化で
7.
きない、クラス間
Relationship(の継承関係の問
関係性)
題など

3.
Outsourced( アウトソーシング
アウトソーシン (協力会社など)
グ)
4. Ported(ポー
移植元、母体ティング)

18.Startup/R
estart(スタート 初期化や再起動
アップ／リス
時の問題
タート)
特定のハードウェ
19.Hardware
Configuration(ハ アに問題があっードウェア構成) た場合
特定のソフトウェ
20.Software
Configuration(ソ アに問題があっフトウェア構成) た場合
21.Blocked Test
他の要因でテス(previously
Normalト不可状態にMode)(ブロック なった場合されたテスト)［無断転用を禁ず］

引用元：IBM Research（http://www.research.ibm.com/softeng/ODC/DETODC.HTM ）JaSST'11 Kansai実行委員会

演習１の課題：不具合報告書の一例を、ODCで分類せよ。

【分類結果】「話題沸騰ポット」の開発

Defect Removal Activities：アクティビティ

表題

蓋を閉めても、沸騰しない

どこのプロセスで発見したか？（発見工程）

管理No.

システムテストの問題番号：31 （通番：931）

Triggers
：トリガー

検出日時

2011/7/21

不具合発生時の操作状況
や環境、条件(刺激)

検出者

テス太郎

不具合箇所・Ver.

蓋センサ機能どのような影響を及ぼすか？

不具合詳細（現象）

蓋をして、電気コンセントを挿した後に電源を入れたが、沸騰が開始されない。（蓋を開けたら、沸騰開始された）Target：ターゲットプロジェクト名

不具合
内容

検出工程 システムテスト

添付資料（有・無） 無
影響
原因

原因・
影響

修正箇所・Ver.

修正の対象。どこが悪かったのか？

蓋を開けたまま沸騰行為を行ってしまうため、大変危険である。これは、社内の安全基準を満たさない。

Defect Type
：欠陥の種類

蓋センサのON/OFFのロジックを間違っており、逆になっていた。

何を間違ったのか？

ソースコードQualifer：不具合の属性

添付資料（有・無） 無
主な原因分類

自社開発のソフトに作り込まれた不具合である

対応内容

ヘッダファイルの定義を修正する※資料１の「ODCの分類一覧＋補足説明」を参考に、不具合情報を分類してください。
※各人で分類後、分類した結果について、グループ内でディスカッションしてください。
［無断転用を禁ず］

Impact：影響

どのように間違ったのか？
なぜ欠陥が入り込んだの
か？
AGE
：新規性
どの時点で間違ったのか？
Source：ソース(出所）
発生源はどこか？

JaSST'11 Kansai実行委員会

資料２：不具合リストと、ODC分類
問題
番号 不具合内容
原因
1 満水センサの水位がONのとき、水 水位チェック処理時、満位が上限を超えていると判断する 水センサのチェック実装
が、一度上限と判定された後、OFF 漏れ。
にならない。（水量が減っても、満水と判定される）

Activities

Trigger

ImpactTargetDefect Type QualifierAge

Sourceどのように間違ったのか？
なぜ欠陥が入 どの時点で間違ったの 発生源はど
問題
り込んだのか、その原因 か？
こか？
- 番号 欠陥場所

どこのプロセ 不具合発生 どのよう 修正の対スで発見し 時の操作状 な影響を 象。どこが悪たか？（発 況や環境、 及ぼす かったの
何を間違っ対策
- 見工程）
条件(刺激) か？
か？
たのか？
満水センサがOFFになる 5.System
1.Design
6.
3.Code（コー 2.
1. Missing(抜 3.
4.
判定を、水位チェック時
Test（システ Conformanc Reliabilit ディング）
Checking(チ け漏れ)
Rewritten(書 Ported(ポーに追加する。
ムテスト）
e（仕様適合) y(信頼ェック）
き直した際) ティング)
性)2 ポットの水温が、マイナス１２度のと センサーの保証範囲を 温度が異常値の場合
き、温度表示をせずにエラー停止す 超過し、異常値が入力さ は、「ERR」と表示するよる。（ボタンを押しても反応なし状
れ、エラーとなった。
う、仕様変更する。
態）
3 蓋を閉めて３秒以内に給湯を開始
すると、満水センサの水位がONのとき(異常値)でも、給湯できてしまう。

仕様書では、ポンプが作 給湯ボタンを押した時点動できる条件に「水量が で、水位を確認するよう適切であること」とある に修正する。
が、満水センサーの検出は蓋を閉めて３秒経過後であったため。

4 ポットの水温がマイナス温度のとき、温度表示がプラスになっている。（－５→５ と表示）

出力時の形式（フォーマット）の指定誤り

フォーマットを修正する

5.System
9.Rare2.
3.Code（コー 3.
1. Missing(抜 3.
1. Developed
Test（システ Situations(レ Servicea ディング）
Alg/Method( け漏れ)
Rewritten(書 In-House(自
ムテスト）
アケース)
bility(保アルゴリズ
き直した際) 社開発)
守性)
ム／実装方
法)
5.System
11.Complex 9.
2.Design（仕 3.
1. Missing(抜 2. New(新1. Developed
Test（システ Path(複合条 Require 様・設計）
Alg/Method( け漏れ)
規)
In-House(自ムテスト）
件での使用) ments(必
アルゴリズ
社開発)
要条件)
ム／実装方
法)

7 蓋を閉じると、保温中の温度に関わ 仕様書通りに実装した ミルクモードの場合は、らず、毎回沸騰を行ってしまう。ま が、利用時の要求にマッ 蓋を閉じた際のお湯のた、沸騰中は給湯できず、ミルク
チしていなかった。
温度が57度以下の場合
モードの利用時に不便。
に限り沸騰するよう、仕様を変更する。

5.System
9.Rare11.
3.Code（コー 1.
2.
3.
2. Reused
Test（システ Situations(レ Usability( ディング）
Assign/Init( Incorrect(不 Rewritten(書 From
ムテスト）
アケース)
ユーザビ
割当/初期 正確（誤り)) き直した際) Library(ライブラリからのリティ)
値)
再利用)
5.System
9.Rare9.
3.Code（コー 2.
2.
2. New(新1. Developed
Test（システ Situations(レ Require ディング）
Checking(チ Incorrect(不 規)In-House(自
ムテスト）
アケース)
ments(必ェック）
正確（誤り))
社開発)
要条件)
5.System
1.Design
6.
3.Code（コー 3.
1. Missing(抜 1. Base(従 3.
Test（システ Conformanc Reliabilit ディング）
Alg/Method( け漏れ)来)Outsourced(
ムテスト）
e（仕様適合) y(信頼アルゴリズ
アウトソーシ
性)
ム／実装方
ング)
法)
5.System
6.Internal
11.
2.Design（仕 3.
1. Missing(抜 4.
4.
Test（システ Document( Usability( 様・設計）
Alg/Method( け漏れ)
ReFixed(修 Ported(ポームテスト）
内部文書) ユーザビ
アルゴリズ
正時)
ティング)
リティ)
ム／実装方
法)

8 牛乳を入れると…沸騰した後、使い 「ミルクモード」の説明不 取扱説明書の記載内容
物にならなくなる。
足。
に、水以外を入れないよ
うに記載する。

5.System
6.Internal
Test（システ Document(
ムテスト）
内部文書)

5 給湯を続けて水量が減り、空っぽに 水量異常検出の、判定 判定処理を修正する。
なっても、給湯（ポンプ)が停止しな 誤り。
い。
ゼロと1を、逆に判定していた。
6 ミルクモード（保温水量60度）で、給 ヒーター操作量の制御周 指定するパラメタを修正
湯した温度を計測すると、６５度に 期を算出する計算式に する。
なっている。
ついて、指定するパラメ
タの指定誤り。

9 ミルクモード（保温水量60度）で、給 保温設定ボタンで、保温 保温モードに対応する温
湯した温度を計測すると、97度に モード切替時に、目的の 度になるまで給湯ボタン
なっている。
保温温度になるまで給 を押しても給湯されない
湯禁止にしていなかった ようにする
10 3種類あるランプの点灯・消灯の論 I/Oポート（またはランプ ヘッダファイルの定義を理が逆になっている。
を制御するレジスタ）へ 修正するの書き込みの論理が1/0
逆になっていた
11 競合商品と比較して常温の水を沸 温度制御方式のロジック 温度制御方式のロジック
騰させるまでの時間が2倍かかる （式、パラメータ）に誤り （式、パラメータ）を修正があった
する
12 給湯ボタンを押しても給湯されない 組合せ条件で発生する。 条件判定の修正場合がある。
保温状態でもヒーターがonの場合は、沸騰行為と判断され給湯ボタンを押しても給湯出来なかった。
13 給湯ボタンを押しても給湯されない センサー情報を正しく入 入力値を修正場合がある。
力していない。ボタンを押す力が弱い場合は、回路構成上給湯ボタンの信号がon/offを繰りかえし、結果としてポンプがうまく作動せず、給湯出来なかった。
14 沸騰行為が十分(沸騰前に保温に PID制御のゲイン設定(増 ゲイン設定の見直し。
遷移したり、3分間の持続がない)に 幅率設定)が不適切で行われない。
あったため何らかのエラーが発生していた。
(このため、温度が上がらずエラー)
15 蓋を開けても沸騰行為が中断され 蓋が開いてもoff判定さ
ない
れなかった

判定処理の修正

16 保温設定ボタンを押して「ミルク保温モードと温度設定の 判定処理の修正モード」に変更しても水温が変わら 不一致
ない
17 水温表示が1の位はすべて0表示

pot-310-12の四捨五入 仕様を小数点第1位で四の桁数指定が書かれて 捨五入するように修正す
いないる

18 給湯中に沸騰ボタンを押すと、給湯 ソフト内部の沸騰開始要 沸騰開始要求フラグ(仮後に沸騰行為に遷移する。
求フラグ(仮称)が保温状 称)も、給湯中の沸騰ボタ
態で給湯中の沸騰ボタ ン操作ではoffのままとしン押下でonとなり、"給湯 た。
中は沸騰ボタンが無効"という仕様を誤解釈していた。
19 保温行為中で給湯中でない場合
沸騰ボタンの押下時間を 押下開始後100msec経に、沸騰ボタンを押し続けると、沸 押下開始時間と終了時 過で押下されたと判断す騰ボタンを押し終わるまで沸騰行為 間の差から求めている る処理としたに遷移しない。
処理となっていた。
20 保温設定ボタンを押し続けると、約 モード遷移要求フラグ(仮 保温設定ボタン一回の200ms毎に高温→節約→ミルク→ 称)は保温設定ボタンの 押下でモード遷移は一回高温とモードが切り替わり続ける。 押下でonされ、モード遷 とする。
移処理(押下判定100msとブザー鳴動100ms)完了でoffされる。しかし、offになった時点で保温設定ボタンが押下状態であるために、モード遷移要求フラグ(仮称)は再度onされてしまう。

［無断転用を禁ず］

8.
5.Information 4.
2.
1. Base(従 1. Developed
Docume Developmen Func/Class/ Incorrect(不 来)In-House(自ntation( t（メッセー
Object(関数 正確（誤り))社開発)
ドキュメ ジ）/クラス/オブ
ンテー
ジェクト)
ション)
1.Design
6.
1.Requireme 3.
2.
1. Base(従 3.
5.SystemTest（システ Conformanc Reliabilit nts（要件） Alg/Method( Incorrect(不 来)Outsourced(
ムテスト）
e（仕様適合) y(信頼アルゴリズ 正確（誤り))
アウトソーシ
性)
ム／実装方
ング)
法)
5.System
2.Logic/9.
3.Code（コー 1.
2.
3.
2. Reused
Test（システ Flow(論理／ Require ディング）
Assign/Init( Incorrect(不 Rewritten(書 From
ムテスト）
フロー)
ments(必割当/初期 正確（誤り)) き直した際) Library(ライ要条件)値)
ブラリからの再利用)
5.System
2.Logic/
7.
3.Code（コー 3.
2.
1. Base(従 3.
Test（システ Flow(論理／ Performa ディング）
Alg/Method( Incorrect(不 来)Outsourced(
ムテスト）
フロー)
nce(パ
アルゴリズ 正確（誤り))
アウトソーシ
フォーマ
ム／実装方
ング)
ンス)
法)
5.System
11.Complex 13.
3.Code（コー 5.
2.
2. New(新1. Developed
Test（システ Path(複合条 Capabilit ディング）
Timing/Seria Incorrect(不 規)In-House(自ムテスト）
件での使用) y(ケイパl(タイミング/ 正確（誤り))
社開発)
ビリティ)
シリアライ
ズ)
2. New(新5.System
19.Hardware 13.
3.Code（コー 6.
2.
Test（システ Configuratio Capabilit ディング）
Interface/O Incorrect(不 規)
正確（誤り))
ムテスト）
n(ハードウェ y(ケイパ
-O
ア構成)
ビリティ)
Messages(インターフェース/オブジェ
クト間メッ
セージ)
5.System
2.Logic/
6.
3.Code（コー 3.
3.
1. Base(従Test（システ Flow(論理／ Reliabilit ディング）
Alg/Method( Extraneous( 来)
ムテスト）
フロー)
y(信頼
アルゴリズ 無関係なも性)
ム／実装方 のが混在)
法)

本来発見さ
れるべき工
程
1 水位センサ 2.Code
処理
Inspection（ｺｰﾄﾞｲﾝｽﾍﾟｸｼｮﾝ）

2 エラー処理2.CodeInspection（ｺｰﾄﾞｲﾝｽﾍﾟ
ｸｼｮﾝ）

3 給湯処理3.Unit test
（ユニットテスト）

4 表示処理5 給湯処理6 ヒーター処理

7 沸騰処理8 マニュアル9 ヒーター処理

10 表示処理11 ヒーター処理

12 給湯処理1. Developed
In-House(自社開発)

13 給湯処理3.
Outsourced(
アウトソーシング)

14 ヒーター処理

5.System
1.Design
6.
3.Code（コー 2.
1. Missing(抜 3.
4.
Test（システ Conformanc Reliabilit ディング）
Checking(チ け漏れ)
Rewritten(書 Ported(ポームテスト）
e（仕様適合) y(信頼ェック）
き直した際) ティング)
性)5.System
1.Design
13.
3.Code（コー 3.
2.
1. Base(従 3.
Test（システ Conformanc Capabilit ディング）
Alg/Method( Incorrect(不 来)Outsourced(
ムテスト）
e（仕様適合) y(ケイパ
アルゴリズ 正確（誤り))
アウトソーシ
ビリティ)
ム／実装方
ング)
5.System
6.Internal
8.
2.Design（仕 1.
1. Missing(抜 3.
2. Reused
Test（システ Document( Docume 様・設計）
Assign/Init( け漏れ)
Rewritten(書 From
ムテスト）内部文書) ntation(
割当/初期
き直した際) Library(ライドキュメ
値)
ブラリからの
ンテー
再利用)
ション)
10.Simple
11.
3.Code（コー 5.
2.
3.
4.
5.SystemTiming/Seria Incorrect(不 Rewritten(書 Ported(ポーTest（システ Path(通常使 Usability( ディング）
ムテスト）
用)
ユーザビ
l(タイミング/ 正確（誤り)) き直した際) ティング)
リティ)
シリアライ
ズ)

15 沸騰処理5.System
20.Software 11.
3.Code（コー 3.
2.
3.
4.
Test（システ Configuratio Usability( ディング）
Alg/Method( Incorrect(不 Rewritten(書 Ported(ポームテスト）
n(ソフトウェ ユーザビ
アルゴリズ 正確（誤り)) き直した際) ティング)
ア構成)
リティ)
ム／実装方
法)
5.System
20.Software 9.
3.Code（コー 3.
2.
3.
1. Developed
Test（システ Configuratio Require ディング）
Alg/Method( Incorrect(不 Rewritten(書 In-House(自ムテスト）
n(ソフトウェ ments(必アルゴリズ 正確（誤り)) き直した際) 社開発)
ア構成)
要条件)
ム／実装方
法)

16 ヒーター処理
17 表示処理18 沸騰処理19 沸騰処理20 ボタン処理

JaSST'11 Kansai実行委員会

資料２：不具合リストと、ODC分類

Activities

Trigger

ImpactTargetDefect Type QualifierAge

Sourceどのように間違ったのか？
なぜ欠陥が入 どの時点で間違ったの 発生源はど
問題
り込んだのか、その原因 か？
こか？
- 番号 欠陥場所

どこのプロセ 不具合発生 どのよう 修正の対スで発見し 時の操作状 な影響を 象。どこが悪問題たか？（発 況や環境、 及ぼす かったの何を間違っ
番号 不具合内容
原因
対策- 見工程）
条件(刺激) か？
か？
たのか？
21 実際の水位と水位センサが逆に表 I/Oポートへの接続が逆 ヘッダファイルの定義を
5.System
19.Hardware 9.
3.Code（コー 1.
2.
3.
4.
示される。
の順番になっていた
修正する
Test（システ Configuratio Require ディング）
Assign/Init( Incorrect(不 Rewritten(書 Ported(ポー実際の水位 水位センサ
ムテスト）
n(ハードウェ ments(必割当/初期 正確（誤り)) き直した際) ティング)
第1水位→第4水位
ア構成)
要条件)
値)
第2水位→第3水位
第3水位→第2水位
第4水位→第4水位
22 温度が実際の温度と異なる(一定温 サーミスタ電圧から温度 変換式を修正する
度の場合)への変換式間違い23 温度が実際の温度と異なる(温度が 温度の平均化フィルタの 変換式を修正する
変化する場合)。実際の水温の変化 時定数大き過ぎに対して計測した水温が分単位で遅れる。
24 タイマをリセットした時のブザー音 仕様誤認識によりが、タイムアップした時のブザー音 0min0secでのブザー音(100msec間隔で100msecを3回鳴ら を同じにしていたす)になっていた。
25 取っ手がとっても熱くなる

ブザー音を修正する

蓋センサoff時の処理が 蓋センサoff時の処理を入っていなかったため、 追加した。
蓋が開いたままでも沸騰行為を行っていた。

26 容量の小さいシリーズは、急激に熱 容量の小さいシリーズで 温度上昇率を規定した。
くなりすぎるも、従来の容量の大きいシリーズと同じ熱量のヒーターを採用したた
め、温度上昇が急激になった。
27 異臭がする
ドレッシングを入れて沸 エラー検知機能の修正
騰させた際に、110℃でエラー検知せず、沸騰するまで温度上昇し、熱くなってゴム部分が溶けた
28 モノによって沸騰するまでの時間に ロットごとの部品のバラ
バラつきがあるつきによる部品をバラつきの小さいものにした

29 給湯中に蓋を開けても給湯が止ま 仕様の給湯を停止させ 仕様を修正らない。
る条件に蓋を開けるという項目が抜けていた。
30 給湯ロック機能の初期状態がロック 仕様書上、給湯ロック機 仕様を修正解除となっている
能の初期状態がロック解除となっていた。
31 蓋をして、電気コンセントを挿した後 蓋センサのON/OFFのロ ヘッダファイルの定義をに電源を入れたが、沸騰が開始さ ジックを間違っており、逆 修正するれない。（蓋を開けたら、沸騰開始 になっていた。
された）32 蓋を閉じた後は、ロック解除となり 仕様書上、給湯ロック機 仕様を修正
給湯ボタン押下のみで給湯が可能 能の蓋を閉じた状態がとなっている。
ロック解除となっていた。

［無断転用を禁ず］

5.System
1.Design
6.
3.Code（コー 3.
2.
1. Base(従Test（システ Conformanc Reliabilit ディング）
Alg/Method( Incorrect(不 来)ムテスト）e（仕様適合) y(信頼アルゴリズ 正確（誤り))性)
ム／実装方
5.System
20.Software 7.
3.Code（コー 4.
2.
1. Base(従Test（システ Configuratio Performa ディング）
Func/Class/ Incorrect(不 来)ムテスト）n(ソフトウェ nce(パObject(関数 正確（誤り))
ア構成)
フォーマ
/クラス/オブンス)
ジェクト)
5.System
8.Side9.
3.Code（コー 2.
3.
4.
Test（システ Effect(副作 Require ディング）
Checking(チ Extraneous( ReFixed(修ムテスト）
用)ments(必ェック）
無関係なも 正時)
要条件)
のが混在)

3.
Outsourced(
アウトソーシング)
3.
Outsourced(
アウトソーシ
ング)

本来発見さ
れるべき工
程

21 水位センサ
処理

22 ヒーター処理
23 ヒーター処理

1. Developed
In-House(自社開発)

24 ブザー処理

1. Missing(抜 1. Base(従5.System
1.Design
6.
3.Code（コー 3.
Alg/Method( け漏れ)来)
Test（システ Conformanc Reliabilit ディング）
アルゴリズ
ムテスト）
e（仕様適合) y(信頼
ム／実装方
性)
法)
5.System
3.Backward 6.
2.Design（仕 1.
2.
1. Base(従Test（システ Compatibility Reliabilit 様・設計）
Assign/Init( Incorrect(不 来)ムテスト）(旧バージョ y(信頼割当/初期 正確（誤り))
ン互換性)
性)
値)

3.
Outsourced(
アウトソーシング)

25 ヒーター処理

3.
Outsourced(
アウトソーシング)

26 ヒーター処理

5.System
17.Recovery 6.
3.Code（コー 1.
1. Missing(抜 1. Base(従Test（システ /Exception( Reliabilit ディング）
Assign/Init( け漏れ)
来)ムテスト）
リカバリー／ y(信頼
割当/初期
例外)
性)
値)

3.
Outsourced(
アウトソーシング)

27 ヒーター処理

5.System
19.Hardware 6.
1.Requireme 1.
2.
1. Base(従Test（システ Configuratio Reliabilit nts（要件） Assign/Init( Incorrect(不 来)ムテスト）
n(ハードウェ y(信頼割当/初期 正確（誤り))
ア構成)
性)
値)
5.System
10.Simple
9.
1.Requireme 2.
1. Missing(抜 2. New(新Test（システ Path(通常使 Require nts（要件） Checking(チ け漏れ)
規)
ムテスト）
用)
ments(必ェック）
要条件)
10.Simple
9.
1.Requireme 2.
1. Missing(抜 2. New(新5.SystemTest（システ Path(通常使 Require nts（要件） Checking(チ け漏れ)
規)
ムテスト）
用)
ments(必ェック）
要条件)
5.System
10.Simple
6.
3.Code（コー 3.
2.
1. Base(従Test（システ Path(通常使 Reliabilit ディング）
Alg/Method( Incorrect(不 来)
ムテスト）
用)
y(信頼
アルゴリズ 正確（誤り))性)
ム／実装方
5.System
4.Lateral9.
1.Requireme 2.
1. Missing(抜 2. New(新Test（システ Compatibility Require nts（要件） Checking(チ け漏れ)規)
ムテスト）
(一般的互換 ments(必
ェック）
性)
要条件)

3.
Outsourced(
アウトソーシング)
1. Developed
In-House(自社開発)

28 ヒーター処理
29 給湯処理1. Developed
In-House(自社開発)

30 給湯処理1. Developed
In-House(自社開発)

31 センサ処理

1. Developed
In-House(自社開発)

32 給湯処理

JaSST'11 Kansai実行委員会

演習２-①：プロダクトの問題傾向を考察分類される問題番号を、記載する。

記載例１
記載例２
記載例３

＃２、＃４、＃５(なし)＃１、＃３、＃６、＃７、＃８

件数評価(ワーストに×）

３件
０件
５件 ×(悪)1. Installability(インストール)
2. Serviceability
(保守性)

コ

ド
番
号
を
読
み
上
げ
る
人
と

、

3. Standards(標準)ー

影響度：Impact

問
題
番
号
を
記
載
す
る
人
を
分
担
す
れ
ば

4. Integrity/Security(完全性／セキュリティ)5. Migration(マイグレーション)
6. Reliability(信頼性)
7. Performance(パフォーマンス)
8. Documentation(ドキュメンテーション)
9. Requirements(必要条件)、

10. Maintenance(メンテナンス)ス
ム

12. Accessibility(アクセシビリティ)

ズ
か
も

ー

11. Usability(ユーザビリティ)。

13. Capability(ケイパビリティ)
評価が「×(最も悪い)」分類項目に対して、さらに他の分類と組み合わせて傾向を把握します。
他の分類の内訳を集計する際、別の集計用紙を利用してください。
分類
Triggers：
どのような状況で発生するか？
Target：
どこが悪かったのか？
Defect Type：
何を間違ったのか？
Qualifer：
どのように間違ったのか？
Age：
どの時点で間違ったのか？
Source：
誰の物が間違ったのか？

左記の中で、最も件数の多い分類項目

件数

メモ例) 1.Design Conformance（仕様適合)

プロダクトの問題傾向について、考察した結果を記載する。

考察例)XXXがXXX件(XXX%)と、最も多い傾向にある。XXXXを重点とした見直しが必要。

※結果をグループ発表いただきます。どんな傾向を発見したのか、教えてくださーい！

［無断転用を禁ず］

JaSST'11 Kansai実行委員会

演習２-②：集計用紙
演習２-①で、評価が×(ワースト)の分類項目を対象に、他の分類についても集計ください
Target
評価(ワースト件数分類される問題番号を、記載する。
Triggers：トリガー 分類される問題番号を、記載する。
に×）：ターゲット1.仕様適合

1.要件

2.論理／フロー2.仕様・設計

3.旧バージョン互換性

3.コーディング

4.一般的互換性

4.ビルド

5.並行性

5.メッセージ

6.内部文書

6.言語

件数

評価(ワーストに×）分類される問題番号を、記載する。

件数評価(ワーストに×）分類される問題番号を、記載する。

件数評価(ワーストに×）分類される問題番号を、記載する。

件数評価(ワーストに×）

7.言語依存性8.副作用
9.レアケース

Qualifer：不具合の属性

10.通常使用

1. 抜け漏れ11.複合条件での使用

2. 不正確（誤り)12.カバレッジ

3. 無関係なものが混在

13.バリエーション
14.連続操作
15.相互作用Source：ソース(出所）

16.負荷／ストレス

1. 自社開発

17.リカバリー／例外

2. ライブラリからの再利用

18.スタートアップ／
リスタート

3. アウトソーシング

19.ハードウェア構成

4. ポーティング

20.ソフトウェア構成
21.ブロックされたテ
スト
AGE
：新規性
Defect Type
：欠陥の種類分類される問題番号を、記載する。

件数評価(ワーストに×）

1. Base(従来)1. 割当/初期値

2. New(新規)

2. チェック

3. Rewritten(書き直した際)3.アルゴリズム／実
装方法

4. ReFixed(修正時)

4.関数/クラス/オブジェクト
5.タイミング/シリアライズ
6. インターフェース/オ
ブジェクト間メッセージ

7. 関係性［無断転用を禁ず］

JaSST'11 Kansai実行委員会

資料３：アクティビティと、トリガーのマッピングの一例
アクティビティトリガー

1.Design Rev（ﾃﾞｻﾞｲﾝﾚﾋﾞｭｰ）

2.Code Inspection 3.Unit test
（ｺｰﾄﾞｲﾝｽﾍﾟｸｼｮﾝ） （ユニットテスト）

4.Function Test
（機能テスト）

5.System Test
（システムテスト）

1.Design Conformance（仕様適合)
2.Logic/ Flow(論理／フロー)
3.Backward Compatibility(旧バージョン互換性)4.Lateral Compatibility(一般的互
換性)
5.Concurrency(並行性)6.Internal Document(内部文書)
7.Language Dependency(言語依存性)8.Side Effect(副作用)9.Rare Situations(レアケース)
10.Simple Path(通常使用)
11.Complex Path(複合条件での使用)12 Coverage(カバレッジ)
12.Coverage(カバレッジ)
13.Variation(バリエーション)
14.Sequencing(連続操作)
15.Interaction (相互作用)
16.Workload/Stress(負荷／ストレス)
17.Recovery/Exception(リカバリー／例外)
18.Startup/Restart(スタートアップ／リスタート)19.Hardware Configuration(ハードウェア構成)
20.Software Configuration(ソフトウェア構成)
21.Blocked Test (previously
Normal Mode)(ブロックされたテスト)※ヒント：ターゲット(修正対象)を参考にすると、対応するアクティビティが明確になるかも。

参考：IBM Research（http://www.research.ibm.com/softeng/ODC/DETODC.HTM ）［無断転用を禁ず］

JaSST'11 Kansai実行委員会

演習３－２：不具合を早い段階で低減させる施策を考察
見逃し工程分類される問題番号を、記載する。

件数評価(ワーストに×）

1.Design Rev（デザインレビュー）
2.Code Inspection（コードインスペクション）
3.Unit test（ユニットテス
ト）
4.Function Test
（機能テスト）
5.System Test
（システムテスト）
評価が「×(最も悪い)」分類に対して、
さらに絞り込む分類を検討して、集計を実施。
分類される問題番号を、記載する。

件数評価（ワース
トに×）

１．
２．
３．
４．
５．
６．
７．
８．
９．
１０．
１１．
１２．
１３．
１４．
１５．
１６．
１７．
１８．
１９．
２０．
２１．
現場の改善を目的として、具体的に実施すべき課題についてグループで検討した考察結果を、記載する。

考察分類される問題番号を、記載する。

①主張：言いたいこ XXXには、XXXの傾向があり、特に問題が集中している。
との要点。
②根拠：事実に基づ 例）XXXとXXXで集計の結果、XXX件(XX%)と、最も比率が高い。
いたもの。（仮定とは、識別すること）③提案：改善に向けて実施すべき課題例)XXXXについて、より詳細を確認し、重点的な見直し実施要。

※結果をグループ発表いただきます。なぜ、その分類を選んだのかも、発表してくださーい［無断転用を禁ず］

JaSST'11 Kansai実行委員会