推定手法-概要
Estimation は、推定値または近似値を見つけるプロセスです。これは、入力データが不完全、不確実、または不安定な場合でも、何らかの目的で使用できる値です。
見積もりによって、特定のシステムまたは製品を構築するのにかかる費用、労力、リソース、および時間が決まります。見積もりは以下に基づいています-
- 過去のデータ/過去の経験
- 利用可能なドキュメント/知識
- Assumptions
- 特定されたリスク
ソフトウェアプロジェクト見積もりの4つの基本的なステップは次のとおりです。
- 開発製品のサイズを見積もります。
- 作業量を工数または工数で見積もります。
- 暦月でスケジュールを見積もります。
- 合意された通貨でプロジェクトのコストを見積もります。
推定に関する観察
見積もりは、プロジェクトで1回限りのタスクである必要はありません。それは-の間に起こることができます
- プロジェクトの取得。
- プロジェクトの計画。
- 必要に応じてプロジェクトを実行します。
見積もりプロセスを開始する前に、プロジェクトの範囲を理解する必要があります。過去のプロジェクトデータがあると便利です。
プロジェクトメトリクスは、定量的な見積もりを生成するための歴史的な視点と貴重な情報を提供できます。
計画では、責任と説明責任につながるため、技術マネージャーとソフトウェアチームが最初のコミットメントを行う必要があります。
過去の経験は大いに役立ちます。
少なくとも2つの見積もり手法を使用して見積もりに到達し、結果の値を調整します。推定値の調整については、次のセクションの分解手法を参照してください。
計画は反復的であり、時間の経過や詳細がわかったときに調整できるようにする必要があります。
一般的なプロジェクト見積もりアプローチ
広く使用されているプロジェクト見積もりアプローチは Decomposition Technique。分解技術は分割統治法を採用しています。サイズ、労力、およびコストの見積もりは、プロジェクトを主要な機能または関連するソフトウェアエンジニアリングアクティビティに分割することにより、段階的に実行されます。
Step 1 −構築するソフトウェアの範囲を理解します。
Step 2 −ソフトウェアサイズの見積もりを生成します。
スコープのステートメントから始めます。
ソフトウェアを、それぞれ個別に推定できる関数に分解します。
各関数のサイズを計算します。
サイズ値をベースラインの生産性メトリックに適用して、労力とコストの見積もりを導き出します。
関数の見積もりを組み合わせて、プロジェクト全体の全体的な見積もりを作成します。
Step 3−労力とコストの見積もりを生成します。プロジェクトを関連するソフトウェアエンジニアリングアクティビティに分割することで、労力とコストの見積もりに到達できます。
プロジェクトを完了するために実行する必要のある一連のアクティビティを特定します。
アクティビティを測定可能なタスクに分割します。
各タスクを完了するために必要な労力（工数/日）を見積もります。
アクティビティのタスクの作業見積もりを組み合わせて、アクティビティの見積もりを作成します。
データベースから各アクティビティのコスト単位（つまり、コスト/単位努力）を取得します。
各アクティビティの総労力とコストを計算します。
各アクティビティの労力とコストの見積もりを組み合わせて、プロジェクト全体の全体的な労力とコストの見積もりを作成します。
Step 4−推定値の調整：ステップ3で得られた値をステップ2で得られた値と比較します。両方の推定値のセットが一致する場合、数値の信頼性は高くなります。それ以外の場合、大きく異なる推定値が発生した場合は、次のことについてさらに調査を行います。
プロジェクトの範囲が十分に理解されていないか、誤解されています。
機能および/または活動の内訳は正確ではありません。
推定手法に使用される履歴データは、アプリケーションに不適切であるか、廃止されているか、または誤って適用されています。
Step 5 −発散の原因を特定してから、見積もりを調整します。
推定精度
精度は、何かが現実にどれだけ近いかを示します。見積もりを作成するときはいつでも、誰もが数値が現実にどれだけ近いかを知りたがっています。生成時に持っているデータを考慮して、すべての見積もりをできるだけ正確にする必要があります。そしてもちろん、あなたは数字に対する誤った自信を刺激するような方法で見積もりを提示したくありません。
見積もりの精度に影響を与える重要な要素は次のとおりです。
すべての推定値の入力データの精度。
見積もり計算の精度。
モデルの調整に使用された履歴データまたは業界データが、推定しているプロジェクトとどの程度一致しているか。
組織のソフトウェア開発プロセスの予測可能性。
製品要件とソフトウェアエンジニアリングの取り組みをサポートする環境の両方の安定性。
実際のプロジェクトが慎重に計画、監視、および制御されているかどうか、および予期しない遅延を引き起こすような大きな驚きは発生していません。
以下は、信頼できる見積もりを達成するためのいくつかのガイドラインです-
- すでに完了している同様のプロジェクトに基づいて見積もります。
- 比較的単純な分解手法を使用して、プロジェクトのコストと労力の見積もりを生成します。
- ソフトウェアのコストと労力の見積もりには、1つ以上の経験的見積もりモデルを使用します。
この章の見積もりガイドラインのセクションを参照してください。
精度を確保するために、少なくとも2つの手法を使用して推定し、結果を比較することを常にお勧めします。
見積もりの問題
多くの場合、プロジェクトマネージャーは、サイズの見積もりをスキップしてスケジュールの見積もりに頼ります。これは、トップマネジメントまたはマーケティングチームによって設定されたタイムラインが原因である可能性があります。ただし、理由が何であれ、これを行うと、後の段階でスコープの変更に対応するためのスケジュールを見積もることが困難になります。
見積もりを行う際に、特定の仮定が行われる場合があります。一部の人はまだ見積もりシートに仮定を文書化していないため、見積もりシートにこれらすべての仮定に注意することが重要です。
適切な見積もりでさえ、固有の仮定、リスク、および不確実性がありますが、それでも、それらは正確であるかのように扱われることがよくあります。
見積もりを表現する最良の方法は、たとえば、プロジェクトが特定の日に完了する、または固定番号で完了すると述べるのではなく、5〜7か月かかると言うことによって、考えられる結果の範囲としてです。月の。範囲が狭すぎる場合は、特定の日付にコミットするのと同じであるため、注意してください。
付随する確率値として不確実性を含めることもできます。たとえば、プロジェクトが特定の日付またはそれ以前に完了する確率は90％です。
組織は正確なプロジェクトデータを収集しません。推定の精度は履歴データに依存するため、問題になります。
どのプロジェクトでも、必要な機能を含めて高品質の出力を生成できる最短のスケジュールがあります。管理者やクライアントによるスケジュールの制約がある場合は、提供する範囲と機能について交渉することができます。
スケジュールの超過を回避するために、スコープクリープの処理についてクライアントに同意します。
最終的な見積もりで不測の事態に対応できないと、問題が発生します。たとえば、会議、組織のイベント。
リソース使用率は80％未満と見なす必要があります。これは、リソースの生産性が時間の80％にすぎないためです。80％を超える使用率でリソースを割り当てると、スリッページが発生する可能性があります。
見積もりガイドライン
プロジェクトを見積もる際には、次のガイドラインに留意する必要があります。
見積もりの際には、他の人の経験を聞いてください。また、あなた自身の経験を任務に置いてください。
リソースの生産性は、その時間の80％にすぎないと想定します。したがって、見積もりでは、リソース使用率を80％未満と見なします。
複数のプロジェクトで作業しているリソースは、タスク間の切り替えに時間がかかるため、タスクの完了に時間がかかります。
見積もりには管理時間を含めます。
問題解決、会議、その他の予期しないイベントに備えて、常に不測の事態に備えてください。
適切なプロジェクト見積もりを行うために十分な時間をとってください。急いで見積もりを行うと、不正確でリスクの高い見積もりになります。大規模な開発プロジェクトの場合、見積もりステップは実際にはミニプロジェクトと見なす必要があります。
可能であれば、組織の同様の過去のプロジェクトからの文書化されたデータを使用してください。これにより、最も正確な見積もりが得られます。組織が履歴データを保持していない場合は、今がデータの収集を開始する良い機会です。
作業を行う人以外の人が作成した見積もりは精度が低くなるため、開発者ベースの見積もりを使用してください。
いくつかの異なる人を使用して、いくつかの異なる推定手法を推定して使用します。
見積もりを調整します。推定値間の収束または広がりを観察します。収束とは、適切な見積もりが得られたことを意味します。Wideband-Delphi手法は、正確で偏りのない見積もりを作成することを目的として、人々のグループを使用して見積もりを収集および議論するために使用できます。
プロジェクトのライフサイクル全体で、プロジェクトを数回再見積もりします。