sec - ipasec software engineering for mo･no･zu･ku･ri 4 1．背景...

Software Engineering Center Copyright© 2013 Information-technology Promotion Agency, Japan. All rights reserved.

SEC Software Engineering for Mo･No･Zu･Ku･Ri

1 Software Engineering Center Copyright© 2013 Information-technology Promotion Agency, Japan. All rights reserved.


組込みソフトウェアバグ管理手法の紹介

組込みソフトウェア開発における品質向上の勧め

［バグ管理手法編］

２０１３年３月１５日

独立行政法人情報処理推進機構(ＩＰＡ)

技術本部

ソフトウェア・エンジニアリング・センター(ＳＥＣ)

組込み系プロジェクト



2

バグ管理手法解説

２０１３年３月８日発行書籍：Ａ５判、８０ページ定価５００円（税込）ｐｄｆ版：無償提供予定



3

目次

1. 背景

2. 本ガイドの目的

3. バグ管理の目的

4. バグに関連する用語について

5. バグ管理プロセス

6. バグ管理内容と管理項目

7. バグカウントの指針

8. バグの分析

9. 組込みシステムにおけるバグ管理の勘所

10. まとめ



4

１．背景

組込みソフトウェア開発におけるバグ数が増加ソースコード規模や連携する他ソフトウェアの増加で、テスト工程で発

見されるバグ数が増加

品質確保のコストを上げずに、市場出荷後のバグを削減することが社会的要請

バグ管理の重要性の拡大対策漏れの防止、潜在バグの削減と市場流出防止、対策の効率化と

スピードアップ等のためのバグ管理が必要

多人数での組織開発がメインとなっており、バグの発見から修正の割り振り、原因究明、修正、確認、承認など一連のバグ管理プロセスが必要

さらに、バグ管理を組織としての課題の抽出と改善のためのＰＤＣＡに繋ぐことによる開発能力向上が重要



5

組込みシステムの不具合発生状況-１

不具合発生製品率



6

組込みシステムの不具合発生状況-２

運用・保守の不具合 2.0%

その他 6.6%

ソフトウェアの不具合 42.2%

システム設計の不具合 7.6%

取扱説明書・表示等の不具合 2.6%

操作・使用環境等使用者に起因する不具合

3.7%

他製品・他システムとの接続に起因する不具合

4.1%

製品企画・仕様の不具合 8.8%

ハードウェアの不具合 11.2% 製造上の不具合

11.2%

製品ベースでも、不具合原因で最も多いのがソフトウェア不具合

出荷後の不具合原因(製品ベース) 2011年版組込みソフトウェア産業実態把握調査報告書



7

問題意識

バグ管理の重要性にもかかわらず・・・・・

標準的な管理項目、目的、プロセスなどを説明した日本語の標準的なガイドがない新規にバグ管理を実施する場合に、管理項目の検討に時間がかかる

個々のバグ管理項目の目的の理解が不十分で、入力データがばらつく（正しく入力されない）

何をバグとするのか、バグ1件はどのようにカウントするのかなど、基本的なバグの測定方法の指針もない例えば

コーディング規約違反はバグなのか

現象は複数でも原因が１箇所の場合、１件とカウントするか

バグに関連する用語も様々で混乱もみられる



8

海外の参考文献

海外では、ＣＭＵ/ＳＥＩやＩＥＥＥに次のような資料が存在

[CMU/SEI-92-TR-022] Technical Report CMU/SEI-92-TR-022 Software Quality Measurement: - A Framework for Counting Problems and Defects

[IEEE 1044] IEEE Std. 1044.1-1995 IEEE Guide to Classification for Software Anomalies IEEE std. 1044-2009 IEEE Standard Classification for Software Anomalies

※これらに相当する日本語の資料は存在しない

※日本でも企業の中では整理されているが、各企業の中に閉じている



9

２．本ガイドの目的

目的

日本の組込みシステム開発における標準的なバグ管理方法を示し、バグ管理の底上げ、バグデータ測定の平準化を通して組込みソフトウェア（製品）の品質向上を図る

具体的には

バグ管理環境を整備する品質管理推進者、プロジェクトマネージャ、及びバグ情報を入力するテスト実施者、開発者がバグ管理の重要性を認識してバグ管理のプロセスを実行できるようにする



10

（参考）ＥＳｘＲとの関係

Ｈｏｗ

要求定義

アーキテクチャ設計

ソフトウェア詳細設計

コーディング

単体テスト

結合・統合テスト

システムテスト

Ｗｈａｔ

ＥＳＱＲ(品質作り込みガイド)

ＥＳＰＲ(開発プロセスガイド)

ＥＳＣＲ(コーディング作法ガイド)

ＥＳＭＲ(プロジェクトマネジメントガイド)

【プロセス定義】【品質指標】

要求仕様書の評価指標

設計書の評価指標

システムの品質評価指標

テスト作業の評価指標

ソースコードの品質評価

経営者

開発担当

マネージャ

本ガイドの対象範囲

ESDR（設計ガイド［事例編］） ESTR（テスト事例集）

マネジメント指針



11

ＥＳｘＲとの関係（続き）

ＥＳＱＲとの関係

ＥＳＱＲの指標の一つの「バグ数」のカウント方法を示す

品質評価指標としての使い方と関連付ける

ＥＳＣＲとの関係

バグの管理により、「よくあるバグ」が明らかになり、それを防ぐためのコーディング規約が検討される

ＥＳＰＲとの関係

品質保証（ＳＵＰ２）アクティビティ詳細化の参考情報

システム・テスト（ＳＹＰ３、ＳＹＰ４）、ソフトウェア・テスト（ＳＷＰ４、ＳＷＰ５、ＳＷＰ６）における準備・確認

プロセス全体の改善への入力



12

ＥＳｘＲとの関係（続き）

記録・参照

ソフトウェア設計・開発

レビュー &テスト

開発計画・管理

ＥＳＰＲＥＳＤＲＥＳＭＲテスト編ＥＳＱＲ

バグ管理情報

ＥＳＣＲ

バグ管理手法

プロセス改善品質制御

設計・実装手法改善方針の連携

傾向分析修正作業原因分析



13

３．バグ管理の目的

目的

バグの修正

製品リリース時の残存バグの有無の把握

バグの検出状況によるソフトウェアの品質

バグの分析によるソフトウェア開発のカイゼン

効果管理項目をデータベース化し統一して扱うことで、バグの追跡が自動化

され、正確な分析が可能になる

開発者は、プロジェクトや顧客の夫々にとって重要な観点から修正を進めることが可能になる

発見から解決まで、全てのライフサイクルを通したバグ管理ができ、対応の抜け漏れの防止が可能になる



14

４．バグに関連する用語について

広辞苑（第六版）によると【バグ】（虫の意）コンピューターのプログラムの誤り・欠陥【不具合】製品などの、具合が良くないこと多く、製造者の側から、「欠陥」の語を避けて

いう【欠陥】かけて足りないもの。不足、不備、欠点【障害】 ①さわり、さまたげ、じゃま【故障】 ①事物の正常な働きがそこなわれることさしさわり、さしつかえ【エラー】 ①誤り、過失、③誤差

研究社新英和大辞典（第六版）によると【bug】 3. 《口語》（機械の）故障、（計画などの思いがけない）欠陥（defect）、

（コンピュータープログラムの）誤り、バグ【defect】 1. 欠陥、欠乏、不足 2. 欠点、短所、弱点【fault】 3. 誤り、過失、過誤 5. 《電気》（回路の）障害、漏電【failure】 4. 不足、欠乏、不十分 6. 機能［運転］停止

【error】 1. 誤り、間違い 2a. 誤信、思い違い、心得違い 4. 《数学・統計》（計算・観測などの）誤り、誤差、バグ、エラー、故障、障害、欠陥、不具合



15

バグに関連する用語について（続き）



16


※備考３．に「ソフトウェアアイテムの場合、コンピュータシステムではプログラミング、論理構成、プログラムプロセス、データ定義などの間違いを意味する」として、ソフトウェアの場合の考え方が示されている。



17


ＪＩＳ Z 8115の解説

前略～

バグには以下のような３種類の意味が込められているとする意見もある。すなわち “人間の思考過程における人の誤りに代表される不完全性又は過失”、または “そのような過失の結果として設計に表現されてしまった記述上の不十分性、不統一性、不完全性、矛盾性のような欠陥” と “そのような記述上の欠陥が原因となって、ソフトウェアが稼動している時に外部から観測される機能、性能、使い易さ、保守のし易さなどの不具合” である。

～後略

バグの定義：

ソフトウェアで設計者の認識有無にかかわらず、すべての成果物において要件定義の誤り、仕様設計の誤り、プログラミングの誤り、システム構築の誤りなどにより「期待される結果」と乖離があるために、何かしらの対策・対応が必要と考えられる現象またはその原因。

特に現象と原因を区別する場合は、現象を示す時は「バグ現象」と呼び、原因を示す時は「バグ原因」と呼ぶ。

* IEEE982.1-2005の “defect” （欠陥）に対応している



18

５．バグ管理プロセス

バグ管理プロセス：

バグが発見されてから、分析や処置が行われ、対応が完了したことが確認されるまでの一連の活動のこと

※ バグに着目した表現として、発見から問題解決まで、バグの処置状態の変遷を、バグのライフサイクルともいう

⇒ バグ管理プロセスは、バグ管理の基本であり、バグ管理を始めるまでに定義する



19

バグ管理の基本フロー

（１）バグの発見・起票発見されると、バグ管理システムや帳票などに報告。報告の完了時にバグ票の状態は「起票済」となり、管理者などの関係者に通知

（２）担当者の割り当て起票された情報から適切な修正担当者を割り当て、バグ票の状態は「担当者割当済」となり、調査・修正担当者に通知される

（３）バグ原因の調査担当者は再現性の確認、バグの原因調査、修正方法の検討などを行い、解決方法などの情報を合わせて記録し、バグ票の状態を「調査済」とする。この調査でバグではないと判断された場合、バグ票に問題がないことを明記し、調査記録などを残し、「バグ票のクローズ処理」に移る

（４）バグの修正担当者は実際に修正作業を行い、バグ票の状態を「処置済」とする。確認担当者に通知される

（５）バグ修正内容の確認確認担当者は再テストを行い、修正が完了していることを確認した上で、バグ票の状態を「検証済」とする

（６）バグ票のクローズ管理者は「検証済」となっているバグに対して内容を確認し、バグ票の状態を「完了」に変更する

１つのバグが報告され、対応が完了するまでの、基本的な流れ



20

バグ管理システムにおける管理状態の遷移



21

バグ管理状態の遷移（状態の説明）

チケット（バグ票）の状態



22

バグ管理状態の遷移（イベントの内容） -1



23

バグ管理状態の遷移（イベントの内容） -2



24

６．バグ管理内容と管理項目

バグの管理のための標準的な項目の一覧を提示

特徴は次の通り

項目選定では、ＣＭＵ/ＳＥＩ-92-ＴＲ-022やＩＥＥＥ1044などのグローバル標準との整合性を考慮

項目の説明では、バグ情報入力者が目的を理解できるように、各項目ごとに目的の説明を提示

項目名は英語も併記（グローバルな開発体制を考慮）

利用方法

組織として必須管理項目を定める

プロジェクトに合せて管理項目を選択する



25

バグ管理項目 -1



26

バグ管理項目 -2



27

バグ管理項目（担当者、日付） -1



28




29




30




31

バグ管理項目（内容） -1



32




33




34

バグ管理項目（調査結果） -1



35

バグ管理項目（調査結果） -2



36

バグ管理項目（解決内容）



37

バグ管理項目（分析のための項目）



38

７．バグカウントの指針

バグの数は、様々な指標に利用されるが、何をバグとしてカウントするかが定まっていないと、指標値が信用できなくなる

何をバグとしてカウントするかは、開発組織やプロジェクトチーム内で揃えることが重要



39

動作不良以外でバグとする可能性のある例

プロジェクトで定めた規約への違反

例えば、コーディング規約違反などについて、バグとしてカウ

ントしないことも多い。しかし、プロジェクトで遵守が必須の

規約としている場合にはバグとしてカウントする

コメント中の説明の誤り

コメント中の説明の誤りは、修正すべきであるが、バグとは

カウントしないことが多い。ただし、プロジェクトでバグにカウ

ントすると定めることもある

冗長なコード

冗長なコードも動作不良ではないので、バグとしてカウントし

ないことが多い。ただし、バグにつながることもあり、修正可

能な時期であれば修正すべきであり、バグとカウントする場

合もある



40

バグ１件のカウント方法

バグ１件のカウント方法の原則

「設計仕様書やソースコード等のソフトウェア成果物に含まれるバグの原因部分について１件とする」

（参考資料：ＳＱｉＰシンポジウム２０１０併設チュートリアルソフトウエア品質データ分析の作法野中誠）

バグの数は、様々な指標に利用されるが、バグ１件のカウント方法が定まっていないと、指標値が信用できなくなるバグ１件のカウント方法は、開発組織やプロジェクトチーム内で揃えることが重要本ガイドで推奨する数え方の原則は次の通り



41

事例１：原則

あるソフトウェアの単体テストで発生したバグ現象１件の調査

で設計仕様書の誤りを発見し、当該箇所１箇所を修正した後、

これに伴って関連するソースコードの２箇所を修正した。

→ 修正箇所の数に関わらず、この事例はバグ1件とカウント

（バグ票の発行数がバグの数を表す）

バグ数＝バグ管理票の数 ⇒ バグ１件

バグ現象１バグ原因１設計仕様書修正１

ソースコード修正１

ソースコード修正２



42

事例２：重複バグ

あるソフトウェアシステムの結合テストで発生した３件のバグ現

象を調査したところ、２つのサブシステムで設計誤りが見つか

り、その相互作用が直接の共通原因となっていることが判明

した。このために該当する設計仕様書とソースコードの４箇所

を修正した。

→ バグ管理票の起票時点では３件。

その後、それらは重複バグとなり、最終的に１件となる。

バグ数＝バグ管理票の数－重複バグの数 ⇒ バグ１件

バグ修正１

バグ修正２

バグ修正３

バグ修正４

相互作用

バグ現象１

バグ現象２

バグ現象３

バグ原因１

バグ原因２



43

（補足）カウントで注意すべきポイント

計数から漏れてしまうバグを無くす。単純なバグで原因も修正方法も明白なために設計担当者が一存で修

正を行なってしまい、バグ情報が管理担当者に報告されないケース等

開発プロジェクトの運用規約等を定めてこのような漏れを防止する。

再現しないバグを取り消す。長期間経過しても再現しないときには、期限を区切って「再現せず」等

に変更してバグとしての扱いを取り消さないと、いつまでもバグ数に未

確定要素が残る。

本当にバグであることを確認する。仕様の理解不足による誤判定やテスト実行環境の設定ミス、テスト用

データの不良等により、仕様通りの正しい結果であったものがバグとし

て報告される場合がある。これらも「仕様通り」等の属性指定をして、

バグとしての扱いを取り消す必要がある。



44

８．バグの分析

バグの分析の目的、及び、分析例を管理項目と関連

させて示す

管理項目の分析における利用方法を理解することで、

入力が正確になる、また、入力のモチベーションの向

上にもつなげる



45

バグ分析の目的

バグの分析は、主に次の目的で行なう。

現ソフトウェア品質の推定、後工程・最終品質の予測

バグの分析結果から、後工程や稼働時の最終品質を予測する。

それにより後工程の作業内容や作業スケジュールの調整を行い、最終品質が要求レベルに達するようにする。

開発プロセスのカイゼン

振り返りによる問題の特定と対策を実施する。

バグの作り込み要因や前工程で発見出来なかった要因を分析し、ソフトウェア開発プロセスの問題を特定し、カイゼンにつなげる。



46

分析手順

バグのメトリクスだけでの分析メトリクス組み合わせ分析



47

分析方法の例（１）

バグ発生件数・未解決件数の分析

使用するバグ管理項目：発見日、処置日、機能名/サブシステム名

バグの発生件数・未解決件数の推移をシステム全体で分析また、サブシステムごとの傾向も分析

マイルストーンを考慮することで、例えば「テスト工程の終了間際で多くのバグが発生している」や「テスト工程の終了間際にも関わらず、未解決のバグが残っている」などの問題を見付けやすくなる。



48

分析例

赤い丸印の変化点に注目して調べる



49

分析方法の例（２）

バグ内容の分析

使用するバグ管理項目：重要度、バグ区分、発見工程、作り込み工程、発見すべき工程、発見すべきアクティビティなど

どんなバグ、いつ発見、いつ混入、なぜ発見できなかった、なぜ作り込んだなどをパレート図やクロス分析を利用して分析

このような分析を実施することで、残存バグの状況把握の参考情報となる。また、次回以降の開発のプロセス改善につなげることもできる



50

分析例（重大度）

後半のバグ数は多いが重大バグが少ないため、品質は安定してきていると考えられる。



51

分析例（混入工程と発見工程）



52

９．組込みシステムにおけるバグ管理の勘所

実例に基づく、いくつかの勘所をコラムとして提示

– どこからバグと呼ぶか

– 未解決バグの棚卸

– ブロッキングバグの扱い

– 担当振り分け方法

– Ｄｕｐｌｉｃａｔｅバグ発生の抑制

– 類似バグの一掃

– なぜなぜ分析

– バグ収束とバグ曲線

また、大規模開発の場合のバグ管理の参考として、エンタープライズ系のバグ管理をコラムとして提示



53

コラム：どこからバグと呼ぶか



54

コラム：エンタプライズ系からのヒント

○体制 • テスト担当チーム • テスト管理者 • 修正審議グループ ※メンバは開発責任者、運用責任者、お客様 • 構成管理チーム • テスト支援チーム（バグ票管理ツールの運用チーム）

○バグ対応手順 1. バグ票の起票［テスト担当チーム／開発担当者］

バグ票を起票し、バグ修正案・影響範囲を記載する 2. バグ票の確認［テスト管理者］

バグ票のバグ修正案・影響範囲をチェックし、審議提出可否を判断する 3. バグ修正案の審議［修正審議グループ］

影響範囲の正当性の確認、修正の妥当性の判断、リリース時期の調整を行う 4. バグ修正［テスト担当チーム／開発担当者］

上記③で確定した修正案に従いソースコードを修正し、確認テストを実施する 5. クローズ確認［テスト管理者］

修正確認エビデンスをチェックし、バグ票をクローズする 6. リリース［構成管理チーム］

修正プログラムのリリース（システム再ビルド）を行う



55

コラム：エンタプライズ系からのヒント(続き)

○主なバグ票記載項目と補足資料

「バグ対応手順３：バグ修正案の審議」のため以下の資料を作成

• テスト仕様書（テストケース、テストデータ、操作手順説明、テスト結果期待値）

• テスト結果（不具合を示すメッセージ、ログ、DBデータ、画面）

• バグ修正説明書（プログラム・設計書の修正案詳細、影響範囲説明）

• 修正確認テスト説明書（修正結果・影響範囲の正当性確認の方法を説明）

○ツールによるバグ対応手順の管理

資産管理ツールを用いて、「バグ対応手順１～６」の各作業で作成・更新する資料に

アクセスできるメンバを限定する。



56

コラム：未解決バグの棚卸

1. 現行のシステムのバージョン（構成）とバグが発見されたときのバージョン

（構成）が異なっており、現象を再現することが困難

2. 現行のソフトウェアがすでに仕様変更、修正により原因究明が困難

3. 発見時のソフトウェアで原因が推定されたとしても、既に当該ソフトウェア

の仕様が変化していたり、別の修正が入っていたりすることがあるので対

策が困難

4. 原因が推定されて修正した場合、他の部分への影響を確認が困難

5. 原因が推定されて修正した場合、確認のためのテストが困難

一旦クローズする！！



57

コラム：類似バグの一掃

バグ原因分析

原因特定

類似パターン調査

修正

• 閾値の誤り • 不等式の誤り • 設定値の誤り • アルゴリズムや計算式 • 計算順序の誤り



58

コラム：重複バグ発生の抑制

複合機能テスト（製品全体のテスト）は、各機能のテストの結果、品質が熟成したと判断できるまで開始しない

ランダムテストや耐久テスト、実用テストなどは、並行度合いをむやみに上げて行わない

重複バグ：原因が同じであるバグ (Ｄｕｐｌｉｃａｔｅ) 複合機能テストや性能テスト、ランダムテスト、耐久テスト、実用テストなどを集中して実施すると必ずといっていいほど発生



59

１０．まとめ

Ｈｏｗ

要求定義

アーキテクチャ設計

ソフトウェア詳細設計

コーディング

単体テスト

結合・統合テスト

システムテスト

Ｗｈａｔ

ＥＳＱＲ(品質作り込みガイド)

ＥＳＰＲ(開発プロセスガイド)

ＥＳＣＲ(コーディング作法ガイド)

ＥＳＭＲ(プロジェクトマネジメントガイド)

【プロセス定義】【品質指標】

要求仕様書の評価指標

設計書の評価指標

システムの品質評価指標

テスト作業の評価指標

ソースコードの品質評価

経営者

開発担当

マネージャ

ESBR（バグ管理ガイド）

マネジメント指針

ESDR（設計ガイド［事例編］） ESTR（テスト事例集）



60

ご清聴、ありがとうございました

sec - ipasec software engineering for mo･no･zu･ku･ri 4 1．背景...

Documents