推定手法-概要

推定値*は、推定値または近似値を見つけるプロセスです。これは、入力データが不完全、不確実、または不安定な場合でも、何らかの目的に使用できる値です。

見積もりにより、特定のシステムまたは製品を構築するのにどれだけのお金、労力、リソース、時間がかかるかが決まります。推定はに基づいています-

過去のデータ/過去の経験
利用可能なドキュメント/知識
仮定
特定されたリスク

ソフトウェアプロジェクトの推定の4つの基本的な手順は次のとおりです-

開発製品のサイズを見積もります。
労力を人月または人時間で見積もります。
暦月でスケジュールを見積もります。
合意された通貨でプロジェクトの費用を見積もります。

推定に関する観察

見積もりは、プロジェクトで一度だけのタスクである必要はありません。それは中に行うことができます-
プロジェクトの取得。
プロジェクトの計画。
必要に応じたプロジェクトの実行。
見積もりプロセスを開始する前に、プロジェクトの範囲を理解する必要があります。過去のプロジェクトデータがあると便利です。
プロジェクトメトリックは、定量的な推定値を生成するための履歴的な視点と貴重な情報を提供できます。
計画では、責任と説明責任につながるため、技術マネージャーとソフトウェアチームが最初のコミットメントを行う必要があります。
過去の経験は大いに役立ちます。
少なくとも2つの推定手法を使用して、推定値に到達し、結果の値を調整します。推定値の調整については、次のセクションの分解手法を参照してください。
計画は反復的であり、時間の経過や詳細がわかったときに調整できるようにする必要があります。

一般的なプロジェクト推定アプローチ

広く使用されているプロジェクト推定アプローチは、*分解手法*です。分解技術は、分割して征服するアプローチを取ります。プロジェクトを主要な機能または関連するソフトウェアエンジニアリングアクティビティに分解することにより、サイズ、工数、およびコストの見積もりが段階的に実行されます。

ステップ1 *-ビルドするソフトウェアの範囲を理解します。

ステップ2 *-ソフトウェアサイズの推定値を生成します。

スコープのステートメントから始めます。
ソフトウェアを、それぞれ個別に推定できる関数に分解します。
各関数のサイズを計算します。
ベースラインの生産性指標にサイズ値を適用することにより、労力とコストの見積もりを導き出します。
関数の推定値を組み合わせて、プロジェクト全体の全体的な推定値を作成します。

ステップ3 *-労力とコストの見積もりを生成します。プロジェクトを関連するソフトウェアエンジニアリングアクティビティに分解することで、労力とコストの見積もりに到達できます。

プロジェクトを完了するために実行する必要のある一連のアクティビティを特定します。
アクティビティを測定可能なタスクに分割します。
各タスクを完了するのに必要な労力（時間/日単位）を見積もります。
アクティビティのタスクのエフォート推定値を組み合わせて、アクティビティの推定値を作成します。
データベースから各アクティビティのコストユニット（つまり、コスト/ユニットエフォート）を取得します。
各アクティビティの総作業量とコストを計算します。
各アクティビティの労力とコストの見積もりを組み合わせて、プロジェクト全体の全体的な労力とコストの見積もりを作成します。

ステップ4 *-推定値の調整：ステップ3で得られた値とステップ2で得られた値を比較します。両方の推定セットが一致する場合、数値の信頼性は高くなります。それ以外の場合、大きく異なる推定値が発生した場合は、さらに調査を実施します-

プロジェクトの範囲が十分に理解されていないか、誤解されています。
機能やアクティビティの内訳は正確ではありません。
推定手法に使用される履歴データは、アプリケーションにとって不適切であるか、廃止されているか、誤って適用されています。

ステップ5 *-発散の原因を特定し、推定値を調整します。

推定精度

精度は、何かが現実にどれだけ近いかを示します。推定値を生成するたびに、誰もが数値が現実にどれだけ近いかを知りたいと思うでしょう。生成時に得たデータを考慮して、すべての見積もりをできるだけ正確にする必要があります。そしてもちろん、数字に誤った自信を抱かせるような方法で見積もりを提示したくはありません。

推定の精度に影響を与える重要な要因は-

すべての推定値の入力データの精度。
推定計算の精度。
モデルのキャリブレーションに使用される履歴データまたは業界データが、推定しているプロジェクトとどの程度一致しているか。
組織のソフトウェア開発プロセスの予測可能性。
製品要件とソフトウェアエンジニアリングの取り組みをサポートする環境の両方の安定性。
実際のプロジェクトが慎重に計画、監視、および制御されたかどうか、予期しない遅延を引き起こす大きな驚きは発生しなかったかどうか。

以下は、信頼できる推定値を達成するためのガイドラインです-

既に完了している同様のプロジェクトに基づいて見積もりを行います。
比較的単純な分解手法を使用して、プロジェクトのコストと労力の見積もりを生成します。
ソフトウェアのコストと労力の見積もりには、1つ以上の経験的見積もりモデルを使用します。

この章の推定ガイドラインのセクションを参照してください。

正確性を確保するために、少なくとも2つの手法を使用して推定し、結果を比較することを常にお勧めします。

推定の問題

多くの場合、プロジェクトマネージャーは、スケジュールの見積もりに頼ってサイズを見積もります。これは、トップマネジメントまたはマーケティングチームによって設定されたタイムラインが原因である可能性があります。ただし、理由が何であれ、これが行われた場合、後の段階で、スコープの変更に対応するためのスケジュールを見積もることは困難です。

推定中に、特定の仮定が行われる場合があります。推定シートに前提条件をまだ記載していないものもあるため、これらの前提条件をすべて見積シートに記載することが重要です。

優れた推定値にも固有の仮定、リスク、不確実性がありますが、多くの場合、それらは正確であるかのように扱われます。

見積もりを表現する最良の方法は、例えば、プロジェクトが特定の日付に完了するか、固定番号で完了すると述べるのではなく、プロジェクトが5〜7か月かかると言うことによる、可能な結果の範囲です。月の。特定の日付にコミットするのと同等であるため、狭すぎる範囲にコミットすることに注意してください。

付随する確率値として不確実性を含めることもできます。たとえば、プロジェクトが一定の日付またはそれ以前に完了する確率は90％です。
組織は正確なプロジェクトデータを収集しません。推定の精度は履歴データに依存するため、問題になります。
どのプロジェクトでも、必要な機能を組み込み、高品質の出力を生成できる最短のスケジュールがあります。管理者やクライアントによってスケジュールの制約がある場合、配信する範囲と機能について交渉することができます。
スケジュールのオーバーランを避けるために、クリープの処理についてクライアントに同意します。
最終的な見積もりで不測事態への対応に失敗すると、問題が発生します。例：ミーティング、組織イベント。
リソース使用率は80％未満と見なされる必要があります。これは、リソースの生産性が時間の80％だけになるためです。 80％を超える使用率でリソースを割り当てると、スリッページが発生します。

推定ガイドライン

プロジェクトを見積もる際には、次のガイドラインに留意する必要があります-

推定中に、他の人の経験を聞いてください。また、タスクであなた自身の経験を置きます。
リソースの生産性は時間の80パーセントに過ぎないと想定します。したがって、推定中にリソース使用率を80％未満としてください。
複数のプロジェクトで作業するリソースは、プロジェクト間の切り替えに時間がかかるため、タスクの完了に時間がかかります。
見積もりに管理時間を含めます。
問題解決、会議、その他の予期しないイベントに備えて、常に不測の事態に備えてください。
適切なプロジェクト見積もりを行うのに十分な時間を確保してください。急ぎの見積もりは、不正確でリスクの高い見積もりです。大規模な開発プロジェクトの場合、推定ステップは実際にはミニプロジェクトと見なされる必要があります。
可能であれば、組織の同様の過去のプロジェクトから文書化されたデータを使用します。その結果、最も正確な推定値が得られます。組織が履歴データを保持していない場合は、今から収集を開始する良い機会です。
開発者ベースの見積もりを使用してください。作業を行う人以外の人が作成した見積もりの精度が低下するためです。
複数の異なる人を使用して、複数の異なる推定手法を推定および使用します。
見積もりを調整します。推定値間の収束または広がりを観察します。収束とは、適切な推定値を得たことを意味します。 Wideband-Delphi手法を使用して、正確で公平な推定値を生成することを目的として、人々のグループを使用して推定値を収集し、議論することができます。
ライフサイクルを通じてプロジェクトを数回再見積もりします。

Estimation-techniques-overview

目次