• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ODC入門(論文)
 

ODC入門(論文)

on

  • 2,639 views

 

Statistics

Views

Total Views
2,639
Views on SlideShare
2,639
Embed Views
0

Actions

Likes
1
Downloads
43
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ODC入門(論文) ODC入門(論文) Document Transcript

    • 「ODC 入門」 森 龍二こんにちは。私は業務系 SIer で Quality Insp e ction(QI) というレビュー活動をしています。今回はレビューの話ではなく、ODC(Orthogonal Defe ct Cla s sifcation: 直交欠陥分類) という欠陥の分類法をご紹介します。1.ODC を始めようと思ったきっかけレビューアという職業柄、毎日沢山の欠陥を目にします。その欠陥は随時現場にフィードバックしていますが、修正した後は基本的にはそのまま捨てられてしまうのが実際です。最初は ODC 自体をレビューになにかしら利用できないかというのが調査の動機でしたが、後述するトリガーがレビューの観点として使えるということ以外はあまり成果が出ませんでした。QI 活動の開始以来蓄積した数千に渡る欠陥リストから、何らかの知見を得て未来に生かそうというのが ODC を始めようと思ったきっかけです。2.ODC とはOrthogonal Defe ct Cla s sifcation の略です。日本語では「直交欠陥分類」や「交差欠陥分類」と訳されます。8つの属性があり、それぞれが重ならないように定義されているので「直交」という性質が付いています。厳密な意味での直交ではないので「交差」でも意味としては同じです。バグ票によくある「影響度」「重大度」などのよく似た項目は一切ありません。また、8つの各属性が取り得る値にも重なりはありません。属性をテスト設計でいう「因子」とするとその取り得る値「水準」の方も直交しているのが ODC です。それによって曖昧な分類を排除しています(現実には難しいですが)。3.ODC 略歴1 9 9 0 年代に米国 IBM 研究所で生まれました。開発リーダーは Ram Chillare g e 氏(先日来日されました)。誕生以降 IBM 内のプロジェクトに適用され、改良を重ねて現在は V 5 . 1 1 が最新版の模様です。4.ODC の特徴互いに重ならない属性に分類するということは、同じ性質の欠陥を集めて数えやすくするということです。同じ欠陥の性質とその数から次のアクションを考えるための技法ということになります。「同じ性質」という特徴と、「計測」のための手法であるということから、定量的・定性的手法の両方の性質を持っています。例えば定量的な分析方法の一つとして「信頼度成長曲線」を考えてみましょう。これは横軸に「時間」や「工数」、縦軸に「欠陥数」をプロットしたものですが、次のような欠点を持っています。・欠陥一件あたりの粒度や重大度は見えなくなってしまう・テストプロセス後半ではテストしないことによって収束したように見えてしまう・曲線が収束しかかった頃には時すでに遅しで改善プロセスが回せないまた今度は定量的分析方法を考えてみましょう。いろいろありますが「根本原因分析(Root Cau s eAnaly sis (RCA)) 」を考えてみると、次のような欠点を持っています。・原因を一つ一つ洗い出すことはできるが、その一つがどれほどの重みか不明・分析に時間がかかる・現場やアプリを知る専門家が必要
    • ODC は、ちょうどきちんと整理された昆虫標本や釣り道具の箱のようなものです。それぞれの区画は何らかの特性を表しており、重ならないように定義・分類されているので容易に数えることができます。どこが集中して多いかによって次のアクションを考えることが容易になります。 図1:ODC のイメージ5.ODC 詳細それでは ODC の8つの属性について見てみましょう。大きく分けて欠陥の発見時に決まる属性を Open erS e ction 、欠陥修正後確定する属性を Clo s er S e ction と呼びます。Open er に属するものが3つ、Clo s er に属するものが残りの5つです。 時期 属性 Attribute 概要 Defect 欠陥除去作業 Removal 欠陥を発見したフェーズ 検出 Activities Opener トリガー Trigger 欠陥を発見する観点 インパクト Impact お客様に与える影響 ターゲット Target 修正対象の成果物 Defect 欠陥種類 修正した欠陥の種類 修正 Type Closer 状態 Qualifier 欠陥種類の状態 履歴 Age いつ作りこまれたか ソース Source 成果物の出所 表1:属性一覧・欠陥除去作業(Defect Removal Activity)欠陥を発見したフェーズです。除去(R e moval) となっていますが、発見時の属性なので発見したフェーズです。フェーズごとに後述するトリガーが決まります。ここは組織で定義されているフェーズを当てはめてください。・トリガー(Trigger)ODC に取り組んで最初につまづくのがトリガーです。Clo s er の方に「欠陥種類(D efe ct Type) 」というのもあり、これが混乱の原因になっています。
    • 先日来日した Ram 氏の講演でわかりやすい説明を聞けたのでここにまとめます。最初は「誤り」「欠陥」「故障」の違いです。人間は基本的に誤る動物です。人間の頭の中にある勘違い、記憶違いを「誤り」と定義します。誤った状態の頭で設計書やソースコードを実装したものが「欠陥」になります。ここまでは実害はでていません。いわゆる「潜在」していると言われている状態です。次に「欠陥」が何らかの形で実行されると「故障」という状態に至ります。この「何らかの形」がトリガーです。 図2:トリガー一つの例で考えてみましょう。「テレビがつかない」という「故障」が起きたとします。この時点ではまだ原因は判明していません。私なら例えば「単にリモコンの電池がないだけでは?」「電源コンセントにつながっているか?」「そもそも電気が来ているか?」などと考えると思います。この「~ではないか?」という情報を元に実際に原因をチェックしていきます。チェックの結果、原因が突き止められたときに「~ではないか?」はトリガーとして確定します。上記のように考えると、「欠陥」が実行されて「故障」につながる過程は、レビューやテストなどの欠陥除去活動によって異なることは容易に理解できると思います。つまり「欠陥除去活動」に対して 1 対多で「トリガー」が存在することになります。それではそれらを一つ一つ見ていきましょう。a)設計レビュー・コードレビューのトリガーレビュー時のトリガーは次の9つです。 トリガー # Trigger 内容 Design 設計書やコードが前後の工程の成果物・開発標準と矛盾を起こして 1 設計との整合性 Conformance いる、要件が漏れている・曖昧である 2 ロジックフロー Logic/Flow 言語知識から論理・データの流れに矛盾がある Backward 3 後方互換性 過去のバージョンの機能が損なわれている Compatibility Lateral 検査対象のシステムとやりとりする他システム、サービス、コン 4 並行互換性 Compatibility ポーネントとの間に矛盾がある 5 同時実行性 Concurrency 共有リソースをアクセスする仕組みがない Internal 内部ドキュメント(目次と内容、コメントとソースコードなど) 6 内部ドキュメント Documents が不正、不整合、不完全である Language 言語固有のコーディング標準や効率的な実装方法に準拠していな 7 言語依存性 Dependency い 8 副作用 Side Effect レビュー対象の設計書やコードが対象外へ及ぼす影響がある Rare 9 特殊な状況 想定外または言及されていないシステムの振る舞い Situations 表2:設計レビュー・コードレビューのトリガー
    • これだけだとわかりにくいので視覚化してみました。 図3:レビューのトリガーこの9つのトリガーはレビュー観点の基本的なものです。もしレビュー観点が何もない状態でレビューを始めなければならない時、または現状のチェックリストを強化したいときにこれらの観点が入っているか確認してみてはいかがでしょうか?ここでご紹介した 9 つのトリガーは設計書レビューとコードレビューが混ざった状態ですので、これらをまず分離し、自組織に合わせた観点を追加すれば芯のしっかりしたチェックリストになると考えられます。実際弊社のレビュー社内教育でも若干変形して教えています。b) その他のトリガー単体テスト、機能テスト、システムテストに対してそれぞれトリガーが定義されています。以下の表を参考にしてください。 トリガー Trigger 内容 いわゆるホワイトボックステストによって見つかる欠陥。市場に出たバ グを含まないが、顧客がビジネスパートナーやベンダーでコードに明る 単純パス Simple Path い場合はここに分類される。 (例)case文のdefaultを通そうと思ったがdefaultがそもそも存在して いなかった ホワイトボックス・グレーボックステストで見つかるバグ。いくつかの分 Complex 岐やテスト条件が組み合わさって起こった者。Simple Pathに含まれ 複合パス Path ない通常の市場バグはこれ。 (例)ある箇所で使うはずのメモリーを別の場所で解放してしまった
    • 表3:単体テストのトリガー トリガー Trigger 内容 ブラックボックステストで、一つの機能をパラメータなし カバレッジ Coverage または単一のパラメータで呼び出した場合の欠陥 ブラックボックステストで、一つの機能を入力やパラメー 組み合わせ Variation タの組み合わせで呼び出した場合の欠陥 ブラックボックステストで、複数の機能を一連の流れに 連続処理 Sequence 従って呼び出した場合の欠陥 ブラックボックステストで、コードの2つ以上の塊の間で 相互作用 Interaction やりとりをしたときの欠陥。一つの機能を独立に実行する と正常終了するが組み合わせると失敗するときだけに使う 表4:機能テストのトリガー トリガー Trigger 内容 システムをリソースの限界またはその前後の環境下で 負荷・ストレス Workload/Stress 使ったときの欠陥 例外を発生させるコードやリカバリコードが正常に 回復・例外 Recovery/Exception 動作しない。失敗(Failure)そのものではなく回復 力 シャットダウンやシステムの失敗から回復した後に起 起動・再起動 Startup/Restart 動・再起動する時の欠陥 Hardware ハードウェア設定 特定のハードウェア設定下で正常動作しない Configuration Software ソフトウェア設定 特定のソフトウェア設定下で正常動作しない Configuration 負荷テスト中、限界以下の負荷でシナリオテストを実 ブロックテスト Blocked Test 行できない。ただし顧客が報告するバグは含まない 表5:システムテストのトリガー・影響(Impact)この欠陥がお客様に及ぼす影響です。ISO 9 1 2 6 の品質特性に非常に似ています。 影響 Impact 内容 設置性 Installability ソフトウェアを使える状態にするまでのしやすさ 完全性/セキュリ システム、プログラム、データなどの悪意のある破壊・置き換 Integrity/Security ティ え・公開 顧客または顧客のエンドユーザが想定するソフトウェアの処 パフォーマンス Performance 理スピード ソフトウェアの保守しやすさ。予防保守と是正保守の両方を 保守性 Maintenance 含む 有用性 Serviceability 失敗(Failure)の診断のしやすさ
    • 新しいリリースへの移行しやすさ。例えば互換性が失われる 移行性 Migration 場合など ソフトウェアの構造や意図する使い方がきちんと文書化され 文書化の度合い Documentation ているか ソフトウェアや文書が理解しやすく正しく目的を遂げられる ユーザビリティ Usability か 標準適合性 Standards 関連する標準に適合しているか。業界標準、プロトコルなど ソフトウェアが意図しない中断をしないで目的を遂げられる 信頼性 Reliability か 製品に対する顧客の要求が抜け漏れていたり、期待と違って 要件適合性 Requirements いる アクセシビリティ Accessibility 障害のある人が情報に継続的に情報にアクセス・利用できるか ソフトウェアが既知の要件を満たしながら意図した目的を果 可能性 Capability たすか 表6:影響ISO9 1 2 6 にマップしてみたところ全部当てはまったので、ざっくりと ISO 9 1 2 6 で分類しておき副属性として Impa ct で定義した内容を書いておくのがわかりやすいかもしれません。・修正対象(Target)欠陥を発見した成果物です。これは本質的に組織によって異なるので、カスタマイズがやむを得ない部分だと考えます。 修正対象 Target 内容 要件定義書 Requirements 要件定義書を直した場合 設計書 Design (基本・詳細、外部・内部)設計書を直した場合 コード Code コードを直した場合 ビルドスクリプト、ライブラリ、変更管理・バージョン管理シス ビルド/パッケージ Build/Package テムなどを直した場合 Information ユーザーガイド、インストールマニュアル、オンラインヘルプを ドキュメント Development 直した場合 表7:修正対象・欠陥種類(Defect Type)調査の結果、欠陥は実際にはどういう種類であったかを示す属性です。 欠陥種類 Defect Type 内容 変数の代入ミス・初期化漏れ 代入/初期化 Assignment/Initialization 複数の変数への代入ミスはアルゴリズムへ パラメータや条件文のデータミス。条件文はif文や 検証 Checking for/whileループの出口判定を含む アルゴリズム/ 設計変更なしでアルゴリズムやデータ構造の変更だけ Algorithm/Method メソッド で修正できる効率の悪いコード、または欠陥 関数/クラス/ 正式な設計変更が必要な欠陥。重要な機能、UI、イン Function/Class/Object オブジェクト ターフェイス、グローバルデータ構造の変更 タイミング/直 Timing/Serialization 共有リソースを直列化していない、直列化対象の間違
    • 列化 い、直列化の技術を間違えた インターフェイ Interface/O-O モジュール・オブジェクト間などのコミュニケーション ス/O-Oメッ Messages ミス(動的やりとり) セージ プロシージャ間・データ構造・オブジェクトの関連ミス 関連 Relationship (静的な関連) 表8:欠陥種類もう一度トリガーについて振り返ってみましょう。トリガーは「欠陥」が「故障」に変わるきっかけでした。このトリガーを使ってレビュー・テストを行えば未然に欠陥を防ぐことができます。つまりトリガーはテスト・レビュープロセスの善し悪しを示すものになります。一方「欠陥種類」は欠陥の「発見」よりも、欠陥の「作り込み」に重点を置いた属性であると考えられます。関数、クラスなどのモジュールの概念や、それらのつながりの概念が入っているのが顕著な例です。欠陥は設計・コーディングの作り込みの過程で混入するものです。作り込みのやり方を変えれば欠陥の混入を防ぐことができます。トリガーがテスト・レビューなどの検証側の観点だとすると、こちらは開発プロセスの観点ということになります。開発プロセスの改善は「欠陥種類」をベースに話をするとよいでしょう。・状態(Qualifier) 状態 Qualifier 内容 ある状態が「ない」ことによる欠陥 漏れ Missing 例:代入文がない ある状態が「誤っている」ことによる欠陥 誤り Incorrect 例:判断文の値が間違っていた ドキュメントやソースと関係がない何かによる欠陥 無関係 Extraneous 例:設計書に現在の製品と関係がない章があり、削除対象である 表9:状態前述の欠陥種類が実際にどういう状態であったのか、を示す属性です。欠陥種類と状態は主語と述語のような関係で表します。例えば例外処理がごっそり抜けていたような場合は、「検証」の「漏れ」と分類されます。状態のうち、「漏れ」「誤り」は比較的理解しやすいですが、「無関係」は分類しにくいものの一つです。私は「無関係」な何かが混入することで他のものが妨げられてしまうような場合に「無関係」に分類するようにしています。・履歴(Age) 履歴 Age 内容 現在のプロジェクトによる修正部分になく、標準ライブラリでもな 本体 Base い潜在欠陥 新規 New 新規作成部分にある欠陥 書き直し Rewritten 古い機能を設計・実装し直した部分に混入された欠陥 再修正 Refixed 欠陥を改修しようとした部分に持ち込まれた欠陥 表10:履歴欠陥が新規開発部分にあるか、既存の成果物の中にあるかは、ODC に限らず一般的によく分類の対象になると思います。ここで紛らわしいのが「書き直し」と「再修正」です。直交性がかなり怪しい部分ではありますが、修正による欠陥
    • 混入、いわゆるデグレードを「再修正」とする以外は「書き直し」とするのがわかりやすいと考えています。・ソース(Source) ソース Source 内容 Developed 内製 組織の開発チームによって開発された部分にある欠陥 In-House Reused 既存のライブラリを使った部分にある欠陥。ライブラリの使い方が誤っ 再利用 From ていたか、ライブラリ自身の欠陥 Library アウトソース Outsourced ベンダー開発部分にある欠陥 転用 Ported 異なる環境で有効だったソースを転用した部分にある欠陥 表11:ソースソースといってもソースコードのことではありません。成果物の出所と解釈してください。内製部分にあるか、ライブラリにあるか、外注部分にあるか、コピー&ペーストにあるか、ということです。「再利用」と「転用」の違いは単に呼び出しているかインライン化してしまっているかの違いと考えればすっきり理解できるでしょう。6.何がわかるの?ODC による分析例を 3 つに絞って解説します。・欠陥収束判定 図4:欠陥収束判定信頼度成長曲線上で収束に向かっていると判定される例(図 3 の左)でも、ODC で分析して「欠陥種類」を調べてみると機能バグが収束していないという結果(図 3 の右)です。これは割合ですので、全体の残バグ数は減っている中で機能バグが取れていないので増大しているように見えます。この傾向が見えた段階(ここでは P eriod 2 )に
    • 機能バグの対策を取れば回避できた問題です。・テスト工数増大の原因 図5:テスト工数と ODC トリガーこの図で T 0 は設計・コードレビュー、T 1 が単体・結合テスト、T 2 がシステムテストを表します。R elea s e1 では T 2 で収束していたテスト工数が、R elea s e 2 ではコストが増大している様子がわかります。ODCのトリガーの増減と実際のバグ検出数を比較(図4の右)すると、T 1 でつぶすべきバグを取り逃し、それが T 2で発見されテストコストが増大していることがわかります。トリガーはテスト・レビューの質を表す属性ですのでこのようなことが言えるわけです。・設計・実装の完成度 図6:欠陥種類と状態図5を見るとアルゴリズム・メソッドに関しては「誤り」が多いです。これは詳細設計の完成度が低く、きちんと実装まで落とし込めるレベルにないことを示しています。次に機能(Fun ction) を見ると「漏れ」と「誤り」がほぼ半々になっています。これは要件定義の漏れと、うまく設計まで落とし込めていないのがほぼ均衡して起こっていることを示しています。これは「欠陥種類」が設計・実装の質を表すこ
    • とから見ても妥当な判断であると言えます。大事なことは、これらの分析が根本原因分析(R CA) などに比べて非常に早くでき、かつ数値データを伴うので客観的である(少なくともそう見える)ということです。慣れると 1 ケースあたり 2 ~ 5分で分類可能だそうですが、筆者は初心者なのでもう少しかかっています。7.実際にやってみました詳細は大人の事情でお話できませんが、とあるプロジェクトのバグ票約550件について分類してみました。そのうち重なりを排除して分類まで終えられたのは約350件でした。欠陥の「状態」については「漏れ」と「誤り」がほぼ同数で大半を占めており、「無関係」はごく少量でした。「無関係」なものが主の機能を邪魔するケースはごく少なかったということになります。「欠陥種類」は多い物順に(1)アルゴリズム(2)検証(3)インターフェイスでした。設計段階で処理の詳細に関する考慮が甘かった、というような診断結果になると考えられます。以下は実際に分類してみての感想です。・分類自体の難しさ最初は属性とその取り得る値が頭に入っていませんので、どれに該当するかの区別が難しいと思います。ただこれは本質的な問題ではないので慣れで回避できると思っています。先述の Ram さんが「多少間違っていたとしてもとにかく分類せよ」と言っていたのが印象的です。間違いが統計的に意味がなくなるほど件数をこなせ、と言っているように感じました。ただ現状ではテストケースやテストデータなどの誤りを扱う属性値がないのが気になっています。・バグ 1 件の定義これは本質的に難しい問題です。そもそもバグ票は気がついた人が上げてくるので、もともと重なりがあります。複数を一つに絞るのはそれほど難しくないのですが、複数の欠陥を一つのバグ票に詰め込んでしまっているような場合にはその分解はかなり難しい作業になります。バグ票 1 件の定義としては、2 0 1 0 年の S QiP チュートリアルで野中誠先生が提案されていた内容が参考になります。a) 成果物に含まれる問題の原因部分について 1 件とカウントb) 原因が成果物にある場合→原因部分についてだけ 1 件とカウントc ) 原因がプロセスにある場合→修正箇所ごとに 1 件とカウント以上のような内容をバグ票起票前に一度プロジェクトメンバーで合意しておく必要があるでしょう。・効率のよい分類のためにはこれは既存のバグ票に対して ODC を適用する場合の話です。実際のバグ票は「欠陥の原因」として同じような項目が重なり合って定義されていることが多いです。これらについて、ODC のトリガー・欠陥種類・状態とどう対応するかについて対応表を作っておくと機械的に分類でき、非常に効率が上がります。
    • 図7:バグ票とのマッピング8.まとめ以上 ODC (直交欠陥分類)について解説しました。8つの属性と取り得る値の両方が重ならないように定義されており、分類後はそれらの件数をカウントすることで「欠陥発生の真の原因」「テストコスト見積もり」などに使えるということがご理解いただけたかと思います。今回は入門編ということで ODC の簡単なご紹介だけになりますが、複数の属性間のデータを使って分析を深掘りしていくやり方を「Deep Dive 」といいます。これはまた別の機会にまとめてみたいと思っています。今後の活動予定としては、Trac や R e dmine のような欠陥分類ツールに対して ODC の入力テンプレートを用意し、そもそも分類が自動的に行われるようにしたり、そうした欠陥の分類から何が現場にフィードバックできるかを考えていきたいと思っています。そのような活動を通じて、過去の苦い経験にしっかりと裏打ちされた実践的な開発手法を模索していきたいと考えています。9.参考文献[ 1 ]IBM R e s e ar ch, C ent er for S oftwar e Engine eringhttp://www.research.ibm.com/softeng/ODC/ODC.HTM[2]Ram Chillarege, et. al., Orthogonal Defect Classifcation - A Concept for In-ProcessMeasurements, IEEE Transactions on Software Engineering, Vol 18, No. 11, Nov 1992[ 3野中誠, ] 「ソフトウェア品質データ分析の作法:知識を発掘し、施策に活かす」, ソフトウェア品質シンポジウム併設チュートリアル3, 2 0 1 0