カスタム検索
|
|
カスタム検索
|
|
プロジェクト全般 商談フェーズ 要件定義フェーズ 開発準備フェーズ 設計フェーズ 開発フェーズ 試験フェーズ 運用準備フェーズ 運用フェーズ メンテナンスフェーズ |
2007/06/25 No.013 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ★ 実践プロマネのメールマガジン ★ （プロマネ経験からの実践的なアドバイス） ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ━━目次━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ［テスト件数、障害件数の予実管理］ ★☆ 差異分析の重要性 ☆★ ★☆ テスト件数の分析 ☆★ ★☆ 障害件数の分析 ☆★ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ テスト件数、障害件数とプログラム品質には相関関係があります。どの程度 のテスト件数をこなせばテストケースを網羅できるのか、何件の障害を発見で きれば品質確保ができるのか、プロマネにとって悩ましい問題です。テスト件 数、障害件数の予測と実績について考察します。 ★☆ 差異分析の重要性 ☆★ 《品質の確保》 ＩＴシステム開発の開発フェーズでは、プログラムテスト（ＰＴ）、結合テ スト（ＩＴ）、システムテスト（ＳＴ）を得てプログラム品質を高める。 《テスト件数の差異》 それぞれの工程に先立ち、開発規模からテスト件数を想定する。実際にテス ト計画、テスト仕様書を作成して件数を集計する。想定したテスト件数とテス ト仕様書から集計した件数を比較して考察する。差異がなければテストケース の網羅性はある程度確保できたものと判断できる。差異があれば、その要因を 考えて是正しなければならない。 《障害件数の差異》 各テスト工程で発生する障害件数についても事前に予測する。予測した障害 件数と実際に発生した障害件数の差をもとめ、２０％以上もの差異があれば、 その原因を追求する。ある程度の品質が確保できたと判断できる場合もあれば、 テスト環境、テスト条件でバグが顕在化していないと判断できる場合もある。 《予実管理の重要性》 プロジェクト推進は計画立案（ＰＬＡＮ）、実施と実績収集（ＤＯ）、差異 把握（ＣＨＥＣＫ）と対策（ＡＣＴＩＯＮ）の繰り返しである。テスト件数、 障害件数の予実管理もＰＤＣＡサイクルの実行である。計画と実績に差異があ れば何らかのアクションが必要である。 ★☆ テスト件数の分析 ☆★ 《旧開発手法のＰＴ件数》 １０数年程前の＜アルゴリズム／データ分離モデル開発手法＞では、プログ ラムのステップ数からＰＴ件数を想定することができた。１５〜２０ステップ 程度でひとつの動作を記述し、正常系、異常系のテスト項目をそれぞれ１件程 度と予測した。１０Ｋステップで１０００件程度のＰＴ件数を計画した。 《ＯＯＰ開発手法でのＰＴ件数》 オブジェクト指向開発手法では、単純にステップ数からＰＴテスト件数を割 り出すことはできない。画面、帳票機能の難易度を３段階などに分類し、ラン クＡ（簡易）ではテスト件数３０件、ランクＢ（中難易）では５０件、ランク Ｃ（高難易）では８０件などと過去のプロジェクトから件数を想定することが 好ましい。 画面、帳票機能がトータルで１００機能あり、ランクＡが５０機能、ランク Ｂが３０機能、ランクＣが２０機能あれば、全体のＰＴ件数が５，０００件程 度となる。 《ＩＴ、ＳＴ件数》 結合テスト、システムテストでも同様にテスト件数を想定する。画面、帳票 機能がトータルで１００機能あれば、ＩＴで１，０００〜１，５００件、ＳＴ で５００〜１，０００件程度を想定できる。これも過去の類似プロジェクトと 比較するとよい。 《差異分析と是正》 ＰＴ、ＩＴ、ＳＴ件数を想定し、実際にテスト仕様書を作成して件数をカウ ントする。想定件数に２０％以上満たなければ、以下の原因が考えられる。 １）テスト仕様の深堀が不足している ２）テストケースが十分網羅されていない ３）想定したテストとテスト仕様のカウントレベルが異なる テスト仕様書をプロマネを含む数人でレビューすると、１）、２）に起因して いるか否か判断できる。このケースではテスト仕様全体を再度見直し、テスト の深さ、網羅性をもう一度見直す必要がある。３）はテスト件数のカウントの 相違であり、あまり問題にはならない。 ★☆ 障害件数の分析 ☆★ 《ＰＴ障害発生件数》 画面、帳票機能がトータルで１００機能あり、５，０００件のテストを実施 すれば、５００件〜８００件程度の不具合の発生を予想できる。障害発生件数 と比較してプログラム品質を推し量る。指標値は過去の類似プロジェクトと比 較する。 《ＩＴ、ＳＴ障害発生件数》 ＩＴ、ＳＴ工程で発生した障害件数をカウントする。ＩＴで１，０００件あ れば２００〜３００件、ＳＴで５００件あれば１００〜２００件の障害発生が 予想される。指標値より不具合発生件数が多ければ、プログラム品質は悪いと 判断できる。反対に少なければ十分なテスト行われていないことがわかる。指 標値は過去のプロジェクト実績値の平均から求める。 《発生要因別分析》 ＩＴ、ＳＴ障害件数をカウントすると共に発生要因別に分類する。例えば、 ・仕様定義ミス ・前工程レベルの障害（ＳＴ工程ならＩＴレベル、ＰＴレベルの障害） ・テスト環境の不具合 ・テストデータの不具合 ・テスト仕様の誤り ・オペレーションミス などに分類する。各発生要因を棒グラフにし、障害要因の傾向を分析する。極 端に＜前工程レベルの障害＞の発生頻度が高ければ、テストの中断、前工程に 立ち戻って再テストする必要もでてくる。 《分析の意義》 テスト件数、障害件数の指標値との比較分析、障害発生要因分類後の分析は プログラム品質を短期に高める効果がある。次のプロジェクトの参考指標にす ることもできるので、多くのプロジェクトの実績を蓄積し、プロジェクト管理 レベルの向上に貢献したい。 ご意見ご質問のメールはこちらからお願いします。 ＩＴシステム開発の実践プロマネホームに戻る |
|
|
Copyright (c) 2007-2009 "ＩＴシステム開発の実践プロマネ" All Rights Reserved. |
||