Curveによる「プロジェクトの問題点解析」について詳しく解説。});前回のコラム「最もタチの悪いバグが潜むテストフェイズとは?」では、7つの「基本的な出荷基準」を挙げ、「5.長時間耐久テスト、過負荷テストを実施した」について解説しました。今回はその続きとして、「6.バグの発生が頭打ちになった」を紹介します。7つの基本的な出荷基準について再掲します。ブラックボックス/ホワイトボックス・テストで同値分割を実施した。ブラックボックス/ホワイトボックス・テストの境界値分析を実施した。ホワイトボックス・テストのC0パス網羅を満足した。バグを想定し、それを摘出するためのテスト項目を設計・実施した。48時間の連続運転や、過負荷状態での稼働テストを実施した。いわゆる「バグ摘出曲線」がフラットになった。摘出したバグは全件修正した。Curve(ゴンペルツ曲線)」というS字曲線に近くなると述べました。Curveをソフトウェア開発の現場でどのように使用しているのかを中心に、「6.バグの発生が頭打ちになった」の詳細を解説します。Curveを使って、ソフトウェアの品質制御やスケジュール管理を実施しているプロジェクトは非常に多いと思います。Curveの使い方は次のようなものでしょう。Curveにうまく乗るように、テスト項目を消化する曲線を描きます(図1)。図1を見ると、線を引くのが大変そうですが、実際の開発現場では、「テスト項目の総数」と「テストに割り当てた日数」から適当に曲線を引いている場合がほとんどです。S字に曲げた針金の端を「テスト開始日+テスト項目総数」に置き、もう一方の端を「テスト終了日+テスト項目が0件」に置いて、針金を伸ばして決めるマネージャもいます。Curveでの品質制御では、正確性や厳密性を求めませんので(すなわち、きちんと曲線を引いても意味がないので)、テキトーで構いません。Curveに沿うよう、バグの発生曲線を引きます(同じく図1参照)。上記のテスト項目消化目標の曲線は、テスト項目の総数が分かっていますので簡単に描けますが、バグ摘出予測の曲線は摘出バグの累計が分からないため、少し苦労します。この場合も、以下のような方法でテキトーに描いてください。1.同じ構成メンバで過去に開発実績がある場合、そのときのバグ・データ(例えば、ソース・コード1000行当たりの発生バグ密度)を適用します。前回のバグ密度が6.37件/KLOCとし、今回の開発ステップ数が152KLOCとしますと、152×6.37=968.24で約968件となります。2.過去の開発のデータを収集していない場合や、新メンバによるまったく新しい分野のソフトウェア開発の場合、標準的な値として、5〜6件/KLOCの範囲でテキトーにバグ密度を設定します(これも、適当で構いません。こんなところで時間を食うべきではありません)。(3)消化したテスト項目と摘出したバグの件数を図にプロットするテストを開始したら、毎日、消化したテスト項目数と摘出したバグの数を図にプロットしていきます(図2)。消化したテスト項目数と摘出したバグ数をプロットここで注意すべきことは、「消化したテスト項目」は実行したテスト項目ではなく、“合格になったテスト項目”だということです。従って、バグを見つけたテスト項目は、バグを修正して正しい結果が出るまで、「消化したテスト項目」にはカウントしません。図2で1月5〜12日まで「未実施のテスト項目数(実際)」が水平になっていますが、これは摘出したバグを修正できていないため、テスト項目の消化が進んでいないことを示しています(そのバグにより「パイプが詰まった」状態です)。(4)品質を予測する図2の「テスト項目消化の実際の数」と「摘出したバグの数」をベースにして、品質の予測(特にリリース予定日)や、プロジェクトの問題点を分析します。Curveを表す数式は、極めて厳密で難解です。数式の詳細は前回のコラムに記しましたので、そちらを参照していただきたいのですが、ソフトウェアの品質制御で、この数式をそのまま使うことはまずありません。これには3つの理由があります。第1の理由は、ソフトウェア開発の分野は「数学が嫌いな理科系の吹きだまり」であり、ソフトウェア技術者はこんな複雑怪奇な数式を見ると即死するためです(ちょっと極端かもしれませんが、ソフトウェア開発に必要な数学は、加減乗除と集合論が主でしょう)。Curveを処理するツールが市販されているためです。Curveの式を求めてくれます。数学嫌いのプログラマにはぴったりのツールといえます。最後にして最大の理由は、図に「バグの摘出数」や「テスト項目の消化数」を正規化して、プロットすることが非常に難しいためです。常識的に考えると、1日に1人のプログラマが30分しかテストを実施しない日と、8人全員で18時間も必死にテストを実施する日を同じ「1日」として図の上にプロットするのでは、正確な予測はできません。2時間単位で消化したテスト項目、摘出したバグ数を集計してプロットすると、正確性、厳密性は飛躍的に向上します。テスト項目を必死につぶそうとしているプログラマに対し、「2時間ごとに、実行したテスト項目と見つけたバグの数を教えて」とお願いしても、きちんとカウントしてくれないでしょうし、面倒なのでイイかげんな数値を報告されてしまう可能性が大です。Curveにプロットしているプロジェクトは、ほとんどないと思われます。主な使用法は「プロジェクトの問題点解析」と「リリース予定日の予測」の2つです。Curveを使う場合、曲線のパターンや傾向を大ざっぱに分析して適用する場合がほとんどです。「消化したテスト項目数」と「摘出したバグの数」の曲線をチェックすると、いろいろなことが分かります。医者が体温と血圧を測って、患者の基本的な体調を予測するようなものです。図3-1が「理想のパターン」です。「消化したテスト項目数」と「摘出したバグの数」の実測値が予定の曲線におおむね合っています。「理想」と「現実」には大きな差があります。Curveどおりにはいきません。「理想」と「現実」には差があり、以下に挙げる6つのパターンのいずれかになる可能性が大です。各パターンを示したプロジェクトで、何が起きているのかを分析してみましょう。図3-2を見ると、テスト項目の消化が遅々として進まず、また、バグの摘出も芳しくありません。このような「停滞型」のパターンになる最大の原因は、テスト担当者の経験や能力不足です。開発部門に配属されて1週間の新人にテストを丸投げすると(新人にテストをさせるのは、50年前からのソフトウェア業界での「習慣」です)、テストの勝手が分からず、このようなパターンになります。テスト仕様書に実行手順がすべて明記してあるといっても、最低限の常識や経験がないと、効率の良いテストはできません。包丁を握ったこともない人が、レシピ本を横目で見ながら、「ブルゴーニュ風ビーフ・ストロガノフ」を作るようなものです。図3-2の問題は、それほど深刻ではありません。テスト担当の新人に、ベテラン技術者を2、3日張り付けると、テスト実行のコツをつかみ、図3-1の「理想のパターン」に戻ります。図3-3のパターンでは、テスト項目を快調に消化し、バグもあまり出ていません。これには、2つの理由が考えられます。「テスト項目の品質が悪い」と「プログラムの品質が良い」です。バグを摘出する能力の低いテスト項目が多いと、テスト項目を大量に実行してもバグにヒットしないので、バグは見つかりません。いわゆる「低打率のテスト項目」であり、テスト項目の再設計や追加が必要になります。テスト項目の品質が悪くない場合、プログラムの品質が良いことになります。このどちらに該当するかを見極めねばなりませんが、筆者の経験上、このパターンになった場合、「プログラムの品質が良い」ことは1回もありませんでした。このパターンは、まず「低打率」と見てよいでしょう。「低打率テスト項目」と「低品質プログラム」の両方が当てはまる場合もありますので、注意が必要です。図3-4では、テスト項目を予定以上のペースで消化している一方、バグの摘出数は予測値以下です。プログラムの品質が良い場合に見られる典型的なパターンであり、図3-3の違いに注意してください。これは、プロジェクト・マネージャには理想のパターンといえます。このパターンになると、プロジェクト・マネージャは、「今回は、大きなトラブルもなく順調に開発が進みそうだ。土日も出てこなくて済むし、うまくいけば毎日17時に帰れるかも......」と胸をなで下ろしながら、最善を夢見ますが、こんなパターンになる幸運は、まずあり得ません。安心し切っていると、途中でバグが大量に見つかり、「いつもの道」へ逆戻りする場合がほとんどです。図3-5のパターンは、ちょっと変わった形をしています。テスト項目はスケジュールより早く消化できていて、バグは予定を上回って見つかっています。この派手な「お祭り状態」のパターンは、テスト項目の打率が高く、プログラムの品質が低いことを示しています。いえ、テスト項目が順調以上に消化できていることから、バグは単純なものがほとんどで、修正に時間はかかっていないと推測できます。熟練プログラマが急いで作ると、このパターンになります。現在、マシン上でテストしているのなら、一度机上テストへ戻って、単純なバグを効率よく摘出するのが解決の近道です。バグの傾向をチェックし、類似バグをたたき出すことも重要です。いずれにせよ、それほど深刻な状態ではありません。図3-6では、テスト項目の消化は予定どおりですが、バグは予測をはるかに超えて大量摘出されています。この「バグだらけ型」のパターンでは、デバッグ項目の品質は普通であり、プログラムの品質が悪いと考えられます。ソフトウェア開発で、最もよく見掛けるパターンがこれです。このパターンになると、プロジェクト・マネージャは「最悪の事態にはならないようだ。いつもどおり、しっかり残業すれば乗り切れるだろう」と考え、ホッとすることが多いと思います。この型が起きた場合、このままのテスト項目でテストを終了させ、その後に、バグの傾向や類似性を分析して、「バグの巣」を見つけるようなテスト項目を追加するとよいでしょう。「いつものパターン」なので、深刻さはありません。深刻型の2パターン図3-7に示した2つは、テストフェイズで最も悪いパターンです。テスト項目の消化が難航しているのに、バグは順調に大量に出ています。このパターンの良くないところは、テスト項目の実施で非常に苦労していることです。重要度の高いバグ、修正による影響が広範囲に及ぶバグ、仕様漏れ、根本的な処理方式の不良など、深刻なバグが多発し、バグ修正に時間がかかっています。要求仕様定義フェイズ、設計フェイズ、コーディング・フェイズという「前フェイズ」での品質が低いことが、このパターンになる最大の理由です。この状態になると、プロジェクト・マネージャの取るべき手段は2つしかありません。「品質の悪いソース・コードをだましだまし使う」と「すべてのソース・コードを捨て、設計し直す」の2つです。普通は、作ったものを捨てるのはもったいないと、いまはやりの「エコ感覚」で低品質プログラムからバグをたたき出して、高品質ソフトウェアを作りたくなります。これではガラクタを寄せ集めた「廃物利用」であり、高品質プログラムは望むべくもありません。プログラムの保守性は極端に悪くなり、バグ修正時に新たなバグを作り込む可能性が極端に高くなります。out(ゴミを入れると、ゴミが出る:品質の悪いものからは品質の悪いものしかできない)」の状態です。こんなプロジェクトは、必ず泥沼状態になります。この「深刻型」になった場合は、潔くバグだらけのソース・コードを捨て、設計し直すのが、長期的な展望に立ったプロジェクト・マネージャとしての正しい戦略です。遅れても、数カ月です。設計し直しても「低品質プログラムをだましだまし使って完成させる」より、はるかに早く製品をリリースできます。Curveによる「プロジェクトの問題点解析」です。次回は、バグ摘出曲線のパターンをベースにして、残存バグ数やリリース日を推定する方法を述べます。Curveを分析することにより、「6.バグの発生が頭打ちになった」の状態を摘出する方法を解説します。55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」(以上、日経BP社、翻訳)。SNSfacebooktwitterITmediaはアイティメディア株式会社の登録商標です。