 |
|
|
| 前のページ 1 2 3 4
|
|
説明の中で、(I1)や(S2)などの記号が出てきますが、これは第1回で使ったプロジェクト管理状況チェック表のNo.と対応しています。チェック表で明らかになった問題点に対応する部分は、特に注意して読んでみてください。
|
|
| 品質保証とテスト
|
品質保証の実作業はレビューとテストです。テストは、「テスト仕様書」に基づいて行い、「テスト報告書」にテスト結果をまとめます（Q4、Q5）。これらのドキュメントも単体テスト、結合テスト、総合テストの各工程それぞれにテンプレート化されています。ただし、第1回図2「プロジェクト管理手法（PYRAMID）」と「開発ドキュメント標準（DUNJEON）」に示したように、PYRAMIDではなくDUNGEONのテンプレートなので、ここでは割愛します。
代わりに、図3、図4のようなテストスケジュール表をPYRAMIDのテンプレートとして用意しています。なお、ここでは複数のプログラム単体を結合して、プログラム間のつながりに不整合がないことを確認することを結合テストとしています。また、実際の稼動環境で実データを使って運用などの問題がないことを確認することを総合テストとしています。総合テストにおけるユーザーとの役割分担は、第3回表3の「スケジュール表」で示すほか、「総合テスト仕様書」できちんと示しておく必要があります（Q6）。
企業によっては、プログラム単体ごとでなく、サブシステム単位の結合を確認することを結合テストとしている場合もあります。また、総合テストと運用テストを別個のものとしてきちんと定義しているケースもありますので、それぞれの方針に合わせて適用してください。
|
図3：結合テストスケジュール表
（画像をクリックするとEXCELファイルをダウンロードできます。/27.5KB）
|
図4：総合テストスケジュール表
（画像をクリックするとEXCELファイルをダウンロードできます。/26.5KB）
|
| 品質管理と障害管理ツール
|
プロジェクトを管理する上で、システムが全体としてどの程度の品質かということを把握しておくことは重要です。もちろん設計バグも含むいわゆる障害を完全に取りきるべきでしょうが、システム規模が大きい場合には結合テスト段階ではある程度のバグは残ります。残りわずかな障害を取りきるためには膨大な時間とコストがかかりますので、ユーザーの力を借りて総合テストで障害をなくします。場合によっては運用の中で品質を完全なものとする方が現実的なケースもあるでしょう。そのため、どこでOKを出すかの判断基準を持つ必要があるのです。
テスト工程においてバグがでないのは、品質が本当に良いのか、テストのやり方が悪いのかのどちらかです。それを見極める1つの手段がバグ曲線です。テストの際に報告される障害の数を管理し、それをグラフにプロットするのです。一般に、1日当たりの障害発生数はテストの初期段階から急激に増えて行き、ピークを迎えてから徐々に少なくなっていきます。その曲線をプロットして、発生数が十分小さくなった段階で品質が良くなったと認識するのです。障害が最初から少なく、ピークを迎えない場合は、テスト方法やテスト者の技量不足が考えられます。また、まだまだ障害発生数が収束していないのにテスト完了としてしまうと、後工程に障害が持ち越されます。
品質状態の把握には、障害発生数だけでなく障害の発生原因や重大度も管理するとより効果的です。障害の発生原因に"単純ミス"が多いうちは、まだまだ品質は悪い状態です。品質が向上するにつれ、"複合原因"などのように複雑な要因でしか発生しない障害が中心になってくるので、それをもう1つの判断材料とするのです。
また、発生している障害の重大度も1つの判断基準になります。大きな障害が発生している状態では、おいそれとテスト完了にはできません。あったとしても軽微なバグしかあり得ないと確信できて、初めて次の工程に託すという現実路線が許されるのです。
テストなどで発生する障害をドキュメントで管理するには、「障害報告書」というようなテンプレートを使うことになるでしょう。ただし、PYRAMIDでは「障害管理システム」というWeb-DBシステムで作りこんでいますので、ドキュメントベースのテンプレートはありません。これは画面1のように、障害の報告や処置などの管理をシステム化したもので、バグ曲線も出力できるようにしています。
|
画面1：障害管理システムの画面例
（画像をクリックすると別ウィンドウに拡大図を表示します）
|
| まとめ
|
第5回は、品質管理についてQCとPMBOKの2面から考えて見ました。PMBOKをベースにした品質管理体系を取りつつ、日本の製造業躍進の原動力となったQCの長所も取り入れるという発想で、世界に通用する品質を実現させてください。プロジェクト管理手法PYRAMIDで用意しているテンプレートもいくつか紹介したので、よろしければ使ってみてください。最後にポイントを整理しましょう。
|
品質管理
- QCDという結果だけでなく、その結果を得るための各種プロセスを管理するのが現代的である。
- IT業界ではQCやTQC的発想があまりないが、このような品質改善活動も取り入れることを検討しよう。
- 現代の考え方は、品質＝ユーザー満足度である。当たり前品質だけでなく、前向き品質を維持しなければならないことをメンバーで共通認識しよう。
- 品質は相対的なものでもあるので、計画段階で「品質基準書」を作成し、求める品質基準をユーザーと共有しよう。
- 品質向上のための重要な作業がレビューである。3段階のレビューがきちんと行われるように、その管理・フォロー体制も確立しておこう。
- 全体の品質状況を把握するために、バグ曲線をプロットするのも効果的である。
|
|
前のページ 1 2 3 4
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。
常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。
国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。
|
|
|
|
|
|
