見積もり手法-クイックガイド

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手法は、正確で偏りのない見積もりを作成することを目的として、人々のグループを使用して見積もりを収集および議論するために使用できます。

  • プロジェクトのライフサイクル全体で、プロジェクトを数回再見積もりします。

A Function Point(FP)は、(製品としての)情報システムがユーザーに提供するビジネス機能の量を表す測定単位です。FPはソフトウェアのサイズを測定します。これらは、機能サイジングの業界標準として広く受け入れられています。

FPに基づくソフトウェアのサイジングについては、いくつかの認められた標準や公開仕様が存在します。2013年現在、これらは-

ISO規格

  • COSMIC− ISO / IEC 19761:2011ソフトウェアエンジニアリング。機能的なサイズの測定方法。

  • FiSMA − ISO / IEC 29881:2008情報技術-ソフトウェアおよびシステムエンジニアリング-FiSMA1.1機能サイズ測定方法。

  • IFPUG − ISO / IEC 20926:2009ソフトウェアおよびシステムエンジニアリング-ソフトウェア測定-IFPUG機能サイズ測定方法。

  • Mark-II − ISO / IEC 20968:2002ソフトウェアエンジニアリング-MlIIファンクションポイント分析-カウント実践マニュアル。

  • NESMA − ISO / IEC 24570:2005ソフトウェアエンジニアリング-NESMA関数サイズ測定方法バージョン2.1-ファンクションポイント分析のアプリケーションの定義とカウントガイドライン。

自動ファンクションポイントのオブジェクト管理グループ仕様

オープンメンバーシップで非営利のコンピューター業界標準コンソーシアムであるObjectManagement Group(OMG)は、ITソフトウェア品質コンソーシアムが主導する自動ファンクションポイント(AFP)仕様を採用しています。これは、International Function Point User Group(IFPUG)のガイドラインに従ってFPカウントを自動化するための標準を提供します。

Function Point Analysis (FPA) techniqueソフトウェアユーザーにとって意味のある用語でソフトウェアに含まれる機能を定量化します。FPは、要件仕様に基づいて開発中の機能の数を考慮します。

Function Points (FP) CountingInternational Function Point Users Group(IFPUG)によって定義された、標準のルール、プロセス、およびガイドラインのセットによって管理されます。これらは、Counting Practices Manual(CPM)で公開されています。

ファンクションポイント分析の歴史

ファンクションポイントの概念は、1979年にIBMのAlan Albrechtによって導入されました。1984年に、Albrechtはメソッドを改良しました。最初のファンクションポイントガイドラインは1984年に発行されました。国際ファンクションポイントユーザーグループ(IFPUG)は、米国を拠点とするファンクションポイント分析メトリックソフトウェアユーザーの世界的な組織です。ザ・International Function Point Users Group (IFPUG)は、1986年に設立された非営利の会員制組織です。IFPUGは、ISO標準20296:2009で定義されているファンクションポイント分析(FPA)を所有しており、IFPUGの機能サイズ測定(FSM)メソッドを適用するための定義、ルール、および手順を指定しています。IFPUGは、ファンクションポイントカウント実践マニュアル(CPM)を維持しています。CPM 2.0は1987年にリリースされ、それ以来、何度か繰り返されてきました。CPMリリース4.3は2010年のものでした。

ISO編集改訂が組み込まれたCPMリリース4.3.1は2010年のものでした。ISO標準(IFPUG FSM)-CPM 4.3.1の一部である機能サイズ測定は、ソフトウェアが提供する機能の観点からソフトウェアを測定するための手法です。CPMは、ISO / IEC 14143-1情報技術–ソフトウェア測定の下で国際的に承認された規格です。

エレメンタリープロセス(EP)

Elementary Processは、機能的なユーザー要件の最小単位です。

  • ユーザーにとって意味があります。
  • 完全なトランザクションを構成します。
  • 自己完結型であり、アプリケーションのビジネスは一貫した状態でカウントされます。

関数

関数には2つのタイプがあります-

  • データ関数
  • トランザクション関数

データ関数

データ関数には2つのタイプがあります-

  • 内部論理ファイル
  • 外部インターフェースファイル

データ関数は、システムに影響を与える内部リソースと外部リソースで構成されています。

Internal Logical Files

内部論理ファイル(ILF)は、完全にアプリケーション境界内に存在する、論理的に関連するデータまたは制御情報のユーザー識別可能なグループです。ILFの主な目的は、カウントされるアプリケーションの1つ以上の基本プロセスを通じて維持されるデータを保持することです。ILFには、内部的に維持され、論理構造があり、ファイルに格納されるという固有の意味があります。(図1を参照)

External Interface Files

外部インターフェイスファイル(EIF)は、論理的に関連するデータまたは制御情報のユーザー識別可能なグループであり、参照目的でのみアプリケーションによって使用されます。データは完全にアプリケーションの境界の外側にあり、別のアプリケーションによってILFに保持されます。EIFには、外部で維持されるという固有の意味があります。ファイルからデータを取得するには、インターフェイスを開発する必要があります。(図1を参照)

トランザクション関数

トランザクション関数には3つのタイプがあります。

  • 外部入力
  • 外部出力
  • 外部からのお問い合わせ

トランザクション機能は、ユーザー、外部アプリケーション、および測定対象のアプリケーションの間で交換されるプロセスで構成されます。

External Inputs

外部入力(EI)は、データが境界の外側から内側に向​​かってアプリケーションに「入る」トランザクション関数です。このデータはアプリケーションの外部に送られます。

  • データは、データ入力画面または別のアプリケーションから取得される場合があります。
  • EIは、アプリケーションが情報を取得する方法です。
  • データは、制御情報またはビジネス情報のいずれかです。
  • データは、1つ以上の内部論理ファイルを維持するために使用できます。
  • データが制御情報である場合、内部論理ファイルを更新する必要はありません。(図1を参照)

External Outputs

外部出力(EO)は、データがシステムから「出力」されるトランザクション機能です。さらに、EOはILFを更新する場合があります。データは、他のアプリケーションに送信されるレポートまたは出力ファイルを作成します。(図1を参照)

External Inquiries

外部照会(EQ)は、データの取得をもたらす入力コンポーネントと出力コンポーネントの両方を備えたトランザクション関数です。(図1を参照)

RET、DET、FTRの定義

レコード要素タイプ

レコード要素タイプ(RET)は、ILFまたはEIF内の要素の最大のユーザー識別可能なサブグループです。データの論理的なグループ化を調べて、それらを識別しやすくするのが最善です。

データ要素タイプ

データ要素タイプ(DET)は、FTR内のデータサブグループです。それらは一意であり、ユーザーを識別できます。

参照されるファイルタイプ

参照されるファイルタイプ(FTR)は、参照されるEI、EO、またはEQ内の最大のユーザー識別可能なサブグループです。

トランザクション関数EI、EO、EQは、以下のカウントルールに含まれるFTRとDETをカウントすることによって測定されます。同様に、データ関数ILFおよびEIFは、以下のカウント規則に含まれるDETおよびRETをカウントすることによって測定されます。トランザクション関数とデータ関数の測定値は、FPカウントで使用され、関数サイズまたはファンクションポイントになります。

FPカウントプロセスには、次の手順が含まれます-

  • Step 1 −カウントのタイプを決定します。

  • Step 2 −カウントの境界を決定します。

  • Step 3 −ユーザーが必要とする各基本プロセス(EP)を特定します。

  • Step 4 −一意のEPを決定します。

  • Step 5 −データ関数を測定します。

  • Step 6 −トランザクション機能を測定します。

  • Step 7 −機能サイズ(未調整の機能ポイント数)を計算します。

  • Step 8 −値調整係数(VAF)を決定します。

  • Step 9 −調整されたファンクションポイントカウントを計算します。

Note−一般的なシステム特性(GSC)は、CPM 4.3.1でオプションになり、付録に移動しました。したがって、ステップ8とステップ9はスキップできます。

ステップ1:カウントのタイプを決定する

ファンクションポイントカウントには3つのタイプがあります-

  • 開発ファンクションポイントカウント
  • アプリケーションファンクションポイントカウント
  • エンハンスメントファンクションポイントカウント

開発ファンクションポイントカウント

ファンクションポイントは、要件から実装段階までの開発プロジェクトのすべてのフェーズでカウントできます。このタイプのカウントは、新しい開発作業に関連付けられており、変換作業をサポートする一時的なソリューションとして必要とされた可能性のあるプロトタイプが含まれる場合があります。このタイプのカウントは、ベースラインファンクションポイントカウントと呼ばれます。

アプリケーションファンクションポイントカウント

アプリケーション数は、提供されたファンクションポイントとして計算され、変換作業(プロトタイプまたは一時的なソリューション)および存在した可能性のある既存の機能は除外されます。

エンハンスメントファンクションポイントカウント

製造後にソフトウェアに変更が加えられた場合、それらは拡張機能と見なされます。このような拡張プロジェクトのサイズを決定するために、ファンクションポイントカウントはアプリケーションで追加、変更、または削除されます。

ステップ2:カウントの境界を決定する

境界は、測定対象のアプリケーションと外部アプリケーションまたはユーザードメインとの間の境界を示します。(図1を参照)

境界を決定するには、以下を理解してください。

  • ファンクションポイントカウントの目的
  • 測定されるアプリケーションの範囲
  • どのアプリケーションがどのデータをどのように維持するか
  • アプリケーションをサポートする事業領域

ステップ3:ユーザーが必要とする各基本プロセスを特定する

機能的なユーザー要件を、次のすべての基準を満たす最小のアクティビティ単位に構成および/または分解します。

  • ユーザーにとって意味があります。
  • 完全なトランザクションを構成します。
  • 自己完結型です。
  • カウントされているアプリケーションのビジネスを一貫した状態のままにします。

たとえば、機能ユーザー要件-「従業員情報の保守」は、従業員の追加、従業員の変更、従業員の削除、従業員の照会などの小さなアクティビティに分解できます。

このように識別されたアクティビティの各ユニットは、エレメンタリープロセス(EP)です。

ステップ4:独自の基本プロセスを決定する

すでに識別されている2つのEPを比較し、次の場合は1つのEP(同じEP)としてカウントします。

  • 同じDETのセットが必要です。
  • 同じFTRのセットが必要です。
  • EPを完了するには、同じ一連の処理ロジックが必要です。

複数の形式の処理ロジックを持つEPを複数のEpに分割しないでください。

たとえば、「従業員の追加」をEPとして識別した場合、従業員に扶養家族がいる場合といない場合があるという事実を説明するために、2つのEPに分割しないでください。EPはまだ「従業員の追加」であり、依存関係を説明するために処理ロジックとDETにバリエーションがあります。

ステップ5:データ関数を測定する

各データ関数をILFまたはEIFとして分類します。

データ関数は次のように分類されます。

  • 内部論理ファイル(ILF)(測定対象のアプリケーションによって維持されている場合)。

  • 外部インターフェースファイル(EIF)が参照されているが、測定対象のアプリケーションによって維持されていない場合。

ILFおよびEIFには、ビジネスデータ、制御データ、およびルールベースのデータを含めることができます。たとえば、電話交換機は、ビジネスデータ、ルールデータ、制御データの3つのタイプすべてで構成されています。ビジネスデータは実際の呼び出しです。ルールデータは、コールをネットワーク経由でルーティングする方法であり、制御データは、スイッチが相互に通信する方法です。

ILFとEIFのカウントについては、次のドキュメントを検討してください。

  • 提案されたシステムの目的と制約。
  • 現在のシステムに関するドキュメント(そのようなシステムが存在する場合)。
  • ユーザーが認識している目的、問題、およびニーズの文書化。
  • データモデル。

ステップ5.1:各データ関数のDETを数える

次のルールを適用して、ILF / EIFのDETをカウントします-

  • EPの実行を通じてILFまたはEIFで維持されている、またはILFまたはEIFから取得されている、一意のユーザーを識別できる繰り返しのないフィールドごとにDETをカウントします。

  • 2つ以上のアプリケーションが同じデータ関数を維持および/または参照するときに測定される、アプリケーションによって使用されているDETのみをカウントします。

  • 別のILFまたはEIFとの関係を確立するために、ユーザーが必要とする属性ごとにDETをカウントします。

  • 関連する属性を確認して、それらがグループ化されて単一のDETとしてカウントされているかどうか、または複数のDETとしてカウントされているかどうかを判別します。グループ化は、EPがアプリケーション内で属性をどのように使用するかによって異なります。

ステップ5.2:各データ関数のRETを数える

次のルールを適用して、ILF / EIFのRETをカウントします。

  • データ関数ごとに1つのRETをカウントします。
  • DETの次の追加の論理サブグループごとに1つの追加のRETをカウントします。
    • キー以外の属性を持つ関連付けエンティティ。
    • サブタイプ(最初のサブタイプを除く)。
    • 必須の1:1以外の関係にある帰属エンティティ。

ステップ5.3:各データ関数の機能の複雑さを決定する

RETS データ要素タイプ(DET)
1-19 20-50 >50
1 L L A
2から5 L A H
> 5 A H H

機能の複雑さ: L =低; A =平均; H =高

ステップ5.4:各データ関数の関数サイズを測定する

機能の複雑さ ILFのFPカウント EIFのFPカウント
7 5
平均 10 7
高い 15 10

ステップ6:トランザクション関数を測定する

トランザクション機能を測定するには、次の手順が必要です。

ステップ6.1:各トランザクション関数を分類する

トランザクション機能は、外部入力、外部出力、または外部照会として分類する必要があります。

外部入力

外部入力(EI)は、境界の外側から来るデータまたは制御情報を処理する基本プロセスです。EIの主な目的は、1つ以上のILFを維持すること、および/またはシステムの動作を変更することです。

次のすべてのルールを適用する必要があります-

  • データまたは制御情報は、アプリケーションの境界の外側から受信されます。

  • 境界に入るデータがシステムの動作を変更する制御情報でない場合、少なくとも1つのILFが維持されます。

  • 識別されたEPについては、3つのステートメントのいずれかを適用する必要があります-

    • 処理ロジックは、アプリケーションの他のEIによって実行される処理ロジックとは異なります。

    • 識別されたデータ要素のセットは、アプリケーション内の他のEIに対して識別されたセットとは異なります。

    • 参照されるILFまたはEIFは、アプリケーション内の他のEIによって参照されるファイルとは異なります。

外部出力

外部出力(EO)は、アプリケーションの境界外にデータまたは制御情報を送信する基本プロセスです。EOには、外部からの問い合わせ以外の追加の処理が含まれます。

EOの主な目的は、データまたは制御情報の取得以外の、またはそれらに加えて、処理ロジックを介してユーザーに情報を提示することです。

処理ロジックは-でなければなりません

  • 少なくとも1つの数式または計算が含まれています。
  • 派生データを作成します。
  • 1つ以上のILFを維持します。
  • システムの動作を変更します。

次のすべてのルールを適用する必要があります-

  • アプリケーションの境界の外部にデータまたは制御情報を送信します。
  • 識別されたEPについては、3つのステートメントのいずれかを適用する必要があります-
    • 処理ロジックは、アプリケーションの他のEOによって実行される処理ロジックとは異なります。
    • 識別されたデータ要素のセットは、アプリケーション内の他のEOとは異なります。
    • 参照されるILFまたはEIFは、アプリケーション内の他のEOによって参照されるファイルとは異なります。

さらに、次のいずれかのルールを適用する必要があります-

  • 処理ロジックには、少なくとも1つの数式または計算が含まれています。
  • 処理ロジックは、少なくとも1つのILFを維持します。
  • 処理ロジックは、システムの動作を変更します。

外部からのお問い合わせ

外部照会(EQ)は、境界の外側にデータまたは制御情報を送信する基本プロセスです。EQの主な目的は、データまたは制御情報の取得を通じてユーザーに情報を提示することです。

処理ロジックには数式や計算が含まれておらず、派生データも作成されません。処理中にILFが維持されることも、システムの動作が変更されることもありません。

次のすべてのルールを適用する必要があります-

  • アプリケーションの境界の外部にデータまたは制御情報を送信します。
  • 識別されたEPについては、3つのステートメントのいずれかを適用する必要があります-
    • 処理ロジックは、アプリケーションの他のEQによって実行される処理ロジックとは異なります。
    • 識別されたデータ要素のセットは、アプリケーションの他のEQとは異なります。
    • 参照されるILFまたはEIFは、アプリケーション内の他のEQによって参照されるファイルとは異なります。

さらに、次のすべてのルールを適用する必要があります-

  • 処理ロジックは、ILFまたはEIFからデータまたは制御情報を取得します。
  • 処理ロジックには、数式や計算は含まれていません。
  • 処理ロジックは、システムの動作を変更しません。
  • 処理ロジックはILFを維持しません。

ステップ6.2:各トランザクション関数のDETをカウントする

次のルールを適用して、EIのDETをカウントします-

  • 境界を越える(入るおよび/または出る)すべてを確認します。

  • トランザクション関数の処理中に境界を越える(入るおよび/または出る)一意のユーザー識別可能で繰り返されない属性ごとに1つのDETをカウントします。

  • 複数のメッセージがある場合でも、アプリケーション応答メッセージを送信する機能については、トランザクション関数ごとに1つのDETのみをカウントしてください。

  • 複数の手段がある場合でも、アクションを開始する機能については、トランザクション関数ごとに1つのDETのみをカウントしてください。

  • 以下の項目をDETとしてカウントしないでください-

    • トランザクション関数によって境界内で生成され、境界を出ることなくILFに保存された属性。

    • レポートのタイトル、画面またはパネルの識別子、列見出し、属性のタイトルなどのリテラル。

    • 日付や時刻の属性など、アプリケーションで生成されたスタンプ。

    • ページング変数、ページ番号、および位置情報。たとえば、「211の行37から54」。

    • 「前へ」、「次へ」、「最初」、「最後」およびそれらのグラフィカルな同等物を使用してリスト内をナビゲートする機能などのナビゲーション支援。

次のルールを適用して、EO / EQのDETをカウントします-

  • 境界を越える(入るおよび/または出る)すべてを確認します。

  • トランザクション関数の処理中に境界を越える(入るおよび/または出る)一意のユーザー識別可能で繰り返されない属性ごとに1つのDETをカウントします。

  • 複数のメッセージがある場合でも、アプリケーション応答メッセージを送信する機能については、トランザクション関数ごとに1つのDETのみをカウントしてください。

  • 複数の手段がある場合でも、アクションを開始する機能については、トランザクション関数ごとに1つのDETのみをカウントしてください。

  • 以下の項目をDETとしてカウントしないでください-

    • 境界を越えずに境界内で生成された属性。

    • レポートのタイトル、画面またはパネルの識別子、列見出し、属性のタイトルなどのリテラル。

    • 日付や時刻の属性など、アプリケーションで生成されたスタンプ。

    • ページング変数、ページ番号、および位置情報。たとえば、「211の行37から54」。

    • 「前へ」、「次へ」、「最初」、「最後」およびそれらのグラフィカルな同等物を使用してリスト内をナビゲートする機能などのナビゲーション支援。

ステップ6.3:各トランザクション関数のFTRをカウントする

次のルールを適用して、EIのFTRをカウントします-

  • 維持されている各ILFのFTRをカウントします。
  • EIの処理中に読み取られたILFまたはEIFごとにFTRをカウントします。
  • 維持および読み取りの両方であるILFごとに1つのFTRのみをカウントします。

次のルールを適用して、EO / EQのFTRをカウントします-

  • EPの処理中に読み取られたILFまたはEIFごとにFTRをカウントします。

さらに、次のルールを適用して、EOのFTRをカウントします-

  • EPの処理中に維持される各ILFのFTRをカウントします。
  • EPによって維持および読み取りされるILFごとに1つのFTRのみをカウントします。

ステップ6.4:各トランザクション機能の機能の複雑さを判断する

FTR データ要素タイプ(DET)
1-4 5-15 >=16
0-1 L L A
2 L A H
> = 3 A H H

機能の複雑さ: L =低; A =平均; H =高

EQが最低1FTRを持っている必要があることを除いて、各EO / EQの機能の複雑さを決定します-

EQには最低1つのFTRが必要です

FTR

データ要素タイプ(DET)
1-4 5-15 > = 16
0-1 L L A
2 L A H
> = 3 A H H

機能の複雑さ: L =低; A =平均; H =高

ステップ6.5:各トランザクション関数の関数サイズを測定する

機能の複雑さから各EIの機能サイズを測定します。

複雑 FPカウント
3
平均 4
高い 6

機能の複雑さから各EO / EQの機能サイズを測定します。

複雑 EOのFPカウント EQのFPカウント
4 3
平均 5 4
高い 6 6

ステップ7:機能サイズを計算する(未調整の機能ポイント数)

機能サイズを計算するには、以下の手順に従う必要があります-

ステップ7.1

手順1で見つけたものを思い出してください。カウントのタイプを決定します。

ステップ7.2

タイプに基づいて機能サイズまたは機能ポイント数を計算します。

  • 開発ファンクションポイントカウントについては、ステップ7.3に進んでください。
  • アプリケーションファンクションポイントカウントについては、ステップ7.4に進んでください。
  • 拡張ファンクションポイントカウントについては、ステップ7.5に進んでください。

ステップ7.3

開発ファンクションポイントカウントは、機能の2つのコンポーネントで構成されています-

  • プロジェクトのユーザー要件に含まれるアプリケーション機能。

  • プロジェクトのユーザー要件に含まれる変換機能。変換機能は、データを変換したり、特別な変換レポートなど、他のユーザー指定の変換要件を提供したりするために、インストール時にのみ提供される機能で構成されます。たとえば、既存のアプリケーションを新しいシステムに置き換えることができます。

DFP = ADD + CFP

どこ、

DFP =開発ファンクションポイントカウント

ADD =開発プロジェクトによってユーザーに提供される機能のサイズ

CFP =変換機能のサイズ

ADD = FPカウント(ILF)+ FPカウント(EIF)+ FPカウント(EI)+ FPカウント(EO)+ FPカウント(EQ)

CFP = FPカウント(ILF)+ FPカウント(EIF)+ FPカウント(EI)+ FPカウント(EO)+ FPカウント(EQ)

ステップ7.4

アプリケーションファンクションポイントカウントを計算する

AFP = ADD

どこ、

AFP =アプリケーションファンクションポイントカウント

ADD =開発プロジェクトによってユーザーに提供される関数のサイズ(変換機能のサイズを除く)、またはアプリケーションがカウントされるたびに存在する機能。

ADD = FPカウント(ILF)+ FPカウント(EIF)+ FPカウント(EI)+ FPカウント(EO)+ FPカウント(EQ)

ステップ7.5

拡張ファンクションポイントカウントは、機能の次の4つのコンポーネントを考慮します-

  • アプリケーションに追加される機能。
  • アプリケーションで変更される機能。
  • 変換機能。
  • アプリケーションから削除される機能。

EFP = ADD + CHGA + CFP + DEL

どこ、

EFP =拡張ファンクションポイントカウント

ADD =拡張プロジェクトによって追加される機能のサイズ

CHGA =拡張プロジェクトによって変更される関数のサイズ

CFP =変換機能のサイズ

DEL =拡張プロジェクトによって削除される関数のサイズ

ADD = FPカウント(ILF)+ FPカウント(EIF)+ FPカウント(EI)+ FPカウント(EO)+ FPカウント(EQ)

CHGA = FPカウント(ILF)+ FPカウント(EIF)+ FPカウント(EI)+ FPカウント(EO)+ FPカウント(EQ)

CFP = FPカウント(ILF)+ FPカウント(EIF)+ FPカウント(EI)+ FPカウント(EO)+ FPカウント(EQ)

DEL = FPカウント(ILF)+ FPカウント(EIF)+ FPカウント(EI)+ FPカウント(EO)+ FPカウント(EQ)

ステップ8:値調整係数を決定する

GSCはCPM4.3.1でオプションになり、付録に移動しました。したがって、ステップ8とステップ9はスキップできます。

値調整係数(VAF)は、カウントされるアプリケーションの一般的な機能を評価する14のGSCに基づいています。GSCは、テクノロジーに依存しないユーザーのビジネス上の制約です。各特性には、影響の程度を決定するための説明が関連付けられています。

一般的なシステム特性 簡単な説明
データ通信 アプリケーションまたはシステムとの情報の転送または交換を支援するための通信設備はいくつありますか?
分散データ処理 分散データと処理機能はどのように処理されますか?
パフォーマンス ユーザーは応答時間またはスループットを必要としましたか?
頻繁に使用される構成 アプリケーションが実行される現在のハードウェアプラットフォームはどの程度使用されていますか?
取引率 トランザクションは毎日、毎週、毎月などどのくらいの頻度で実行されますか?
オンラインデータ入力 情報の何パーセントがオンラインで入力されていますか?
エンドユーザーの効率 アプリケーションはエンドユーザーの効率を考慮して設計されましたか?
オンラインアップデート オンライントランザクションによって更新されるILFはいくつですか?
複雑な処理 アプリケーションには広範な論理的または数学的処理がありますか?
再利用性 アプリケーションは、1つまたは複数のユーザーのニーズを満たすように開発されましたか?
インストールの容易さ 変換とインストールはどのくらい難しいですか?
操作のしやすさ 起動、バックアップ、および回復の手順はどの程度効果的および/または自動化されていますか?
複数のサイト アプリケーションは、複数の組織の複数のサイトにインストールするように特別に設計、開発、およびサポートされていましたか?
変更を促進する アプリケーションは、変更を容易にするために特別に設計、開発、およびサポートされましたか?

影響の程度の範囲は、影響なしから強い影響まで、0から5のスケールです。

評価 影響力の程度
0 存在しない、または影響なし
1 偶発的な影響
2 中程度の影響
3 平均的な影響
4 有意義な影響
5 全体に強い影響力

14のGSCのそれぞれの影響の程度を決定します。

このようにして得られた14個のGSCの値の合計は、総影響度(TDI)と呼ばれます。

TDI = ∑14 Degrees of Influence

次に、値調整係数(VAF)を次のように計算します。

VAF = (TDI × 0.01) + 0.65

各GSCは0から5まで変化し、TDIは(0×14)から(5×14)、つまり0(すべてのGSCが低い場合)から70(すべてのGSCが高い場合)、つまり0≤TDI≤70まで変化します。したがって、VAFは0.65(すべてのGSCが低い場合)から1.35(すべてのGSCが高い場合)の範囲で変化する可能性があります。つまり、0.65≤VAF≤1.35です。

ステップ9:調整されたファンクションポイント数を計算する

VAF(V4.3.1より前のCPMバージョン)を使用するFPAアプローチに従って、これは次のように決定されます。

Adjusted FP Count = Unadjusted FP Count × VAF

ここで、未調整のFPカウントは、ステップ7で計算した機能サイズです。

VAFは0.65から1.35まで変化する可能性があるため、VAFは最終的に調整されたFPカウントに±35%の影響を及ぼします。

ファンクションポイントの利点

ファンクションポイントは便利です-

  • 問題のサイズではなく、ソリューションのサイズを測定する場合。

  • 要件はファンクションポイントカウントに必要な唯一のものです。

  • それは技術から独立しているので。

  • プログラミング言語に依存しないため。

  • テストプロジェクトの見積もり。

  • プロジェクト全体のコスト、スケジュール、および労力を見積もる際に。

  • ビジネスグループとのコミュニケーションを容易にする方法を提供するため、契約交渉において。

  • ソフトウェアの機能の実際の使用法、インターフェース、および目的に値を定量化して割り当てるとき。

  • 時間、コスト、人員、期間、その他のアプリケーション指標などの他の指標との比率を作成する場合。

FPリポジトリ

International Software Benchmarking Standards Group(ISBSG)は、ITデータ用の2つのリポジトリを拡張および維持しています。

  • 開発および強化プロジェクト
  • メンテナンスおよびサポートアプリケーション

開発および拡張プロジェクトリポジトリには、6,000を超えるプロジェクトがあります。

データはMicrosoftExcel形式で提供されるため、データを使用してさらに分析したり、他の目的に使用したりすることもできます。

ISBSGリポジトリライセンスは、次の場所から購入できます。 http://www.isbsg.com/

ISBSGは、割引コード「IFPUGMembers」が使用されている場合、オンライン購入のIFPUGメンバーに10%の割引を提供します。

ISBSGソフトウェアプロジェクトデータリリースの更新は、次の場所にあります。 http://www.ifpug.org/isbsg/

COSMICとIFPUGは協力して、ソフトウェアの非機能要件とプロジェクト要件に関する用語集を作成しました。−cosmic-sizing.orgからダウンロードできます。

A Use-Case は、ユーザーとシステムの間の一連の関連する相互作用であり、ユーザーが目標を達成できるようにします。

ユースケースは、システムの機能要件を把握する方法です。システムのユーザーは「アクター」と呼ばれます。ユースケースは基本的にテキスト形式です。

ユースケースポイント–定義

Use-Case Points (UCP)は、ユースケースでソフトウェアサイズを測定するために使用されるソフトウェア推定手法です。UCPの概念はFPに似ています。

プロジェクト内のUCPの数は、以下に基づいています。

  • システムのユースケースの数と複雑さ。
  • システム上のアクターの数と複雑さ。
    • ユースケースとして記述されていないさまざまな非機能要件(移植性、パフォーマンス、保守性など)。

    • プロジェクトが開発される環境(言語、チームの動機など)

UCPを使用した見積もりでは、すべてのユースケースを目標を持ってほぼ同じレベルで記述し、同じ量の詳細を提供する必要があります。したがって、見積もりの​​前に、プロジェクトチームは、定義された目標を使用して詳細なレベルでユースケースを作成したことを確認する必要があります。ユースケースは通常、単一のセッション内で完了し、目標が達成された後、ユーザーは他のアクティビティに進むことができます。

使用履歴-ケースポイント

ユースケースポイントの推定方法は、1993年にGustav Karnerによって導入されました。この作業は、後にIBMに統合されたRationalSoftwareによってライセンス供与されました。

ユースケースポイントカウントプロセス

ユースケースポイントのカウントプロセスには、次の手順があります。

  • 未調整のUCPを計算する
  • 技術的な複雑さを調整する
  • 環境の複雑さを調整する
  • 調整されたUCPを計算する

ステップ1:未調整のユースケースポイントを計算します。

次の手順で、最初に未調整のユースケースポイントを計算します-

  • 未調整のユースケースの重みを決定する
  • 未調整のアクターの重みを決定する
  • 未調整のユースケースポイントを計算する

Step 1.1 −未調整のユースケースの重みを決定します。

Step 1.1.1 −各ユースケースのトランザクション数を見つけます。

ユースケースがユーザー目標レベルで記述されている場合、トランザクションはユースケースのステップと同等です。ユースケースのステップを数えて、トランザクションの数を見つけます。

Step 1.1.2−ユースケース内のトランザクション数に基づいて、各ユースケースを単純、平均、または複雑に分類します。また、次の表に示すように、ユースケースの重みを割り当てます-

ユースケースの複雑さ トランザクション数 ユースケースの重み
シンプル ≤3 5
平均 4から7 10
繁雑 > 7 15

Step 1.1.3−ユースケースごとに繰り返し、すべてのユースケースの重みを取得します。未調整のユースケースの重み(UUCW)は、すべてのユースケースの重みの合計です。

Step 1.1.4 −次の表を使用して、未調整のユースケースの重み(UUCW)を見つけます−

ユースケースの複雑さ ユースケースの重み ユースケースの数 製品
シンプル 5 NSUC 5×NSUC
平均 10 NAUC 10×NAUC
繁雑 15 NCUC 15×NCUC
Unadjusted Use-Case Weight (UUCW) 5×NSUC + 10×NAUC + 15×NCUC

どこ、

NSUCはありません。簡単な使用例-ケース。

NAUCはノーです。平均ユースケースの割合。

NCUCはありません。複雑なユースケースの例。

Step 1.2 −未調整のアクターの重みを決定します。

ユースケースのアクターは、人、別のプログラムなどです。APIが定義されたシステムなど、一部のアクターは非常に単純なニーズを持ち、ユースケースの複雑さをわずかに増加させます。

プロトコルを介して相互作用するシステムなどの一部のアクターは、より多くのニーズを持ち、ユースケースの複雑さをある程度増加させます。

GUIを介して対話するユーザーなど、他のアクターは、ユースケースの複雑さに大きな影響を与えます。これらの違いに基づいて、アクターを単純、平均、および複雑に分類できます。

Step 1.2.1 −次の表に示すように、アクターを単純、平均、および複雑に分類し、アクターの重みを割り当てます。

俳優の複雑さ 俳優の体重
シンプル APIが定義されたシステム 1
平均 プロトコルを介して相互作用するシステム 2
繁雑 GUIを介して対話するユーザー 3

Step 1.2.2−アクターごとに繰り返し、すべてのアクターの重みを取得します。未調整のアクターの重み(UAW)は、すべてのアクターの重みの合計です。

Step 1.2.3 −次の表を使用して未調整のアクターの重み(UAW)を見つけます−

俳優の複雑さ 俳優の体重 俳優の数 製品
シンプル 1 NSA 1×NSA
平均 2 NAA 2×NAA
繁雑 3 NCA 3×NCA
Unadjusted Actor Weight (UAW) 1×NSA + 2×NAA + 3×NCA

どこ、

NSAはノーです。単純な俳優の。

NAAはノーです。平均的な俳優の。

NCAはノーです。複雑な俳優の。

Step 1.3 −未調整のユースケースポイントを計算します。

未調整のユースケースの重み(UUCW)と未調整のアクターの重み(UAW)を合わせると、システムの未調整のサイズが得られます。これは、未調整のユースケースポイントと呼ばれます。

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

次のステップは、技術的な複雑さと環境の複雑さのために未調整のユースケースポイント(UUCP)を調整することです。

ステップ2:技術的な複雑さを調整する

Step 2.1 −次の表に示すように、プロジェクトの技術的な複雑さがユースケースポイントに与える影響に寄与する13の要因とそれに対応する重みを考慮してください。

因子 説明 重量
T1 分散システム 2.0
T2 応答時間またはスループットパフォーマンスの目標 1.0
T3 エンドユーザーの効率 1.0
T4 複雑な内部処理 1.0
T5 コードは再利用可能でなければなりません 1.0
T6 インストールが簡単 .5
T7 使いやすい .5
T8 ポータブル 2.0
T9 変更が簡単 1.0
T10 同時 1.0
T11 特別なセキュリティ目標が含まれています 1.0
T12 サードパーティに直接アクセスを提供します 1.0
T13 特別なユーザートレーニング施設が必要です 1.0

これらの要因の多くは、プロジェクトの非機能要件を表しています。

Step 2.2 − 13の要素のそれぞれについて、プロジェクトを評価し、0(無関係)から5(非常に重要)まで評価します。

Step 2.3 −要因の影響の重みとプロジェクトの評価値から、要因の影響を次のように計算します。

Impact of the Factor = Impact Weight × Rated Value

Step (2.4)−すべての要因の影響の合計を計算します。これにより、以下の表に示すように、総技術係数(TFactor)が得られます。

因子 説明 重量(W) 定格値(0〜5)(RV) 影響(I = W×RV)
T1 分散システム 2.0
T2 応答時間またはスループットパフォーマンスの目標 1.0
T3 エンドユーザーの効率 1.0
T4 複雑な内部処理 1.0
T5 コードは再利用可能でなければなりません 1.0
T6 インストールが簡単 .5
T7 使いやすい .5
T8 ポータブル 2.0
T9 変更が簡単 1.0
T10 同時 1.0
T11 特別なセキュリティ目標が含まれています 1.0
T12 サードパーティに直接アクセスを提供します 1.0
T13 特別なユーザートレーニング施設が必要です 1.0
Total Technical Factor (TFactor)

Step 2.5 −技術的複雑度係数(TCF)を次のように計算します−

TCF = 0.6 + (0.01 × TFactor)

ステップ3:環境の複雑さを調整する

Step 3.1 −次の表に示すように、プロジェクトの実行に影響を与える可能性のある8つの環境要因とそれに対応する重みを考慮してください。

因子 説明 重量
F1 使用されるプロジェクトモデルに精通している 1.5
F2 アプリケーションの経験 .5
F3 オブジェクト指向の経験 1.0
F4 リードアナリストの能力 .5
F5 動機 1.0
F6 安定した要件 2.0
F7 非常勤スタッフ -1.0
F8 難しいプログラミング言語 -1.0

Step 3.2 − 8つの要素のそれぞれについて、プロジェクトを評価し、0(無関係)から5(非常に重要)まで評価します。

Step 3.3 −要因の影響の重みとプロジェクトの評価値から、要因の影響を次のように計算します。

Impact of the Factor = Impact Weight × Rated Value

Step 3.4−すべての要因の影響の合計を計算します。これにより、次の表に示すように、総環境係数(EFactor)が得られます。

因子 説明 重量(W) 定格値(0〜5)(RV) 影響(I = W×RV)
F1 使用されるプロジェクトモデルに精通している 1.5
F2 アプリケーションの経験 .5
F3 オブジェクト指向の経験 1.0
F4 リードアナリストの能力 .5
F5 動機 1.0
F6 安定した要件 2.0
F7 非常勤スタッフ -1.0
F8 難しいプログラミング言語 -1.0
Total Environment Factor (EFactor)

Step 3.5 −環境要因(EF)を次のように計算します−

1.4 + (-0.03 × EFactor)

ステップ4:調整されたユースケースポイント(UCP)を計算する

調整されたユースケースポイント(UCP)を次のように計算します-

UCP = UUCP × TCF × EF

ユースケースの長所と短所

ユースケースポイントの利点

  • UCPはユースケースに基づいており、プロジェクトのライフサイクルの非常に早い段階で測定できます。

  • UCP(サイズ見積もり)は、プロジェクトを実装するチームのサイズ、スキル、および経験とは無関係です。

  • 経験豊富な人が見積もりを行うと、UCPベースの見積もりは実際に近いことがわかります。

  • UCPは使いやすく、追加の分析を必要としません。

  • ユースケースは、要件を説明するための選択方法として広く使用されています。このような場合、UCPが最適な推定手法です。

ユースケースのデメリット

  • UCPは、要件がユースケースの形式で記述されている場合にのみ使用できます。

  • 目標指向の、よく書かれたユースケースに依存します。ユースケースが適切にまたは均一に構造化されていない場合、結果のUCPは正確でない可能性があります。

  • 技術的および環境的要因はUCPに大きな影響を及ぼします。技術的および環境的要因に値を割り当てる際には注意が必要です。

  • UCPは、プロジェクト全体のサイズの初期見積もりには役立ちますが、チームの反復から反復への作業を推進するのにはあまり役立ちません。

Delphi Methodは構造化されたコミュニケーション手法であり、元々は専門家のパネルに依存する体系的でインタラクティブな予測方法として開発されました。専門家は2回以上のラウンドで質問票に回答します。各ラウンドの後、ファシリテーターは、前のラウンドからの専門家の予測の匿名の要約と、彼らの判断の理由を提供します。その後、専門家は、パネルの他のメンバーの回答に照らして、以前の回答を修正することが奨励されます。

このプロセスの間、回答の範囲は減少し、グループは「正しい」回答に向かって収束すると考えられています。最後に、事前定義された停止基準(ラウンド数、コンセンサスの達成、結果の安定性など)の後でプロセスが停止され、最終ラウンドの平均スコアまたは中央値が結果を決定します。

デルファイ法は、1950〜1960年代にランド研究所で開発されました。

ワイドバンドデルファイテクニック

1970年代に、バリーベームとジョンA.ファークハールは、デルファイ法のワイドバンドバリアントを考案しました。「ワイドバンド」という用語が使用されるのは、デルファイ法と比較して、ワイドバンドデルファイ法が参加者間のより多くの相互作用とより多くのコミュニケーションを伴うためです。

ワイドバンドデルファイ法では、見積もりチームはプロジェクトマネージャー、モデレーター、専門家、および開発チームの代表者で構成され、3〜7人のメンバーチームを構成します。2つの会議があります-

  • キックオフミーティング
  • 見積り会議

広帯域デルファイ法–手順

Step 1 −見積もりチームとモデレーターを選択します。

Step 2−モデレーターはキックオフミーティングを実施します。このミーティングでは、チームに問題の仕様と高レベルのタスクリスト、前提条件、またはプロジェクトの制約が提示されます。チームは、問題と見積もりの​​問題がある場合はそれについて話し合います。彼らはまた、見積もりの​​単位を決定します。モデレーターは、ディスカッション全体をガイドし、時間を監視し、キックオフミーティングの後、問題の仕様、高レベルのタスクリスト、仮定、および決定された見積もりの​​単位を含む構造化されたドキュメントを準備します。次に、このドキュメントのコピーを次のステップに転送します。

Step 3 −次に、各見積もりチームメンバーは、詳細なWBSを個別に生成し、WBS内の各タスクを見積もり、行われた仮定を文書化します。

Step 4−モデレーターは、見積もり会議のために見積もりチームを呼び出します。見積もりチームのメンバーのいずれかが見積もりの​​準備ができていないと応答した場合、モデレーターはより多くの時間を与え、会議の招待を再送信します。

Step 5 −見積もりチーム全体が見積もり会議に集まります。

Step 5.1 −見積もり会議の開始時に、モデレーターは各チームメンバーから初期見積もりを収集します。

Step 5.2−次に、ホワイトボードにチャートをプロットします。彼は、対応する名前を開示せずに、各メンバーのプロジェクトの合計見積もりをラウンド1の行にXとしてプロットします。見積もりチームは、見積もりの​​範囲を把握しますが、最初は大きくなる可能性があります。

Step 5.3−各チームメンバーは、自分が作成した詳細なタスクリストを声に出して読み、行われた仮定を特定し、質問や問題を提起します。タスクの見積もりは開示されていません。

個々の詳細なタスクリストを組み合わせると、より完全なタスクリストになります。

Step 5.4 −次に、チームは、到達したタスク、行われた仮定、および見積もりの​​問題について疑問/問題について話し合います。

Step 5.5−次に、各チームメンバーは自分のタスクリストと前提条件を再検討し、必要に応じて変更を加えます。タスクの見積もりには、+ NHrsとして示されるディスカッションに基づいた調整が必要になる場合もあります。より多くの努力と–NHrsのために。少ない労力で。

次に、チームメンバーは、タスク見積もりの​​変更を組み合わせて、プロジェクト全体の見積もりに到達します。

Step 5.6 −モデレーターは、変更された見積もりをすべてのチームメンバーから収集し、ラウンド2の線にプロットします。

このラウンドでは、コンセンサスに基づいているため、範囲は以前のラウンドと比較して狭くなります。

Step 5.7 −次に、チームは、行ったタスクの変更と前提条件について話し合います。

Step 5.8−次に、各チームメンバーは自分のタスクリストと前提条件を再検討し、必要に応じて変更を加えます。タスクの見積もりには、ディスカッションに基づいた調整が必要になる場合もあります。

次に、チームメンバーは、タスク見積もりの​​変更をもう一度組み合わせて、プロジェクト全体の見積もりに到達します。

Step 5.9 −モデレーターは、変更された見積もりをすべてのメンバーから再度収集し、ラウンド3の線にプロットします。

繰り返しになりますが、このラウンドでは、範囲は以前のものと比較して狭くなります。

Step 5.10 −以下の基準のいずれかが満たされるまで、ステップ5.7、5.8、5.9が繰り返されます。

  • 結果は許容できる狭い範囲に収束します。
  • すべてのチームメンバーは、最新の見積もりを変更することを望んでいません。
  • 割り当てられた見積もり会議時間が終了しました。

Step 6 −次に、プロジェクトマネージャーは、見積もり会議の結果を収集します。

Step 6.1 −彼は、個々のタスクリストと対応する見積もりを単一のマスタータスクリストにまとめます。

Step 6.2 −彼はまた、仮定の個々のリストを組み合わせます。

Step 6.3 −次に、見積もりチームと最終的なタスクリストを確認します。

ワイドバンドDelphiテクニックの長所と短所

利点

  • 広帯域デルファイ法は、労力を見積もるためのコンセンサスベースの見積り手法です。
  • タスクを実行する時間を見積もるときに役立ちます。
  • 経験豊富な人の参加と彼らが個別に見積もることは信頼できる結果につながるでしょう。
  • 仕事をする人は見積もりをしているので、有効な見積もりをしています。
  • 匿名性が維持されているため、誰もが自信を持って結果を表現できます。
  • 非常に簡単なテクニック。
  • 仮定は文書化され、議論され、合意されています。

短所

  • 管理サポートが必要です。
  • 見積りの結果は、経営陣が聞きたいものではない可能性があります。

3点推定は3つの値を調べます-

  • 最も楽観的な見積もり(O)、
  • 最も可能性の高い推定値(M)、および
  • 悲観的な見積もり(最も可能性の低い見積もり(L))。

業界では、3点推定とPERTに関していくつかの混乱がありました。ただし、手法は異なります。2つのテクニックを学ぶと、違いがわかります。また、PERT手法の最後に、違いが照合されて表示されます。最初にそれらを見たい場合は、できます。

3点推定(E)は単純平均に基づいており、三角分布に従います。

E = (O + M + L) / 3

標準偏差

三角分布では、

平均=(O + M + L)/ 3

標準偏差=√[((O − E)2 +(M − E)2 +(L − E)2)/ 2]

3点推定ステップ

Step 1 −WBSに到着します。

Step 2 −各タスクについて、3つの値を見つけます-最も楽観的な推定値(O)、最も可能性の高い推定値(M)、および悲観的な推定値(L)。

Step 3 −3つの値の平均を計算します。

Mean = (O + M + L) / 3

Step 4−タスクの3点推定を計算します。3点推定は平均です。したがって、

E = Mean = (O + M + L) / 3

Step 5 −タスクの標準偏差を計算します。

Standard Deviation (SD) = √ [((O − E)2 + (M − E)2 + (L - E)2)/2]

Step 6 − WBS内のすべてのタスクについて、手順2、3、4を繰り返します。

Step 7 −プロジェクトの3点推定を計算します。

E (Project) = ∑ E (Task)

Step 8 −プロジェクトの標準偏差を計算します。

SD (Project) = √ (∑SD (Task)2)

プロジェクトの見積もりを信頼水準に変換する

このように計算された3点推定値(E)と標準偏差(SD)は、プロジェクトの推定値を「信頼水準」に変換するために使用されます。

変換は次のように基づいています-

  • E +/– SDの信頼水準は約68%です。
  • E値の信頼水準+/- 1.645×SDは約90%です。
  • E値の信頼水準+/- 2×SDは約95%です。
  • E値+/- 3×SDの信頼水準は約99.7%です。

一般に、95%の信頼水準、つまりE値+ 2×SDは、すべてのプロジェクトとタスクの見積もりに使用されます。

プロジェクト評価とレビュー手法(PERT)の見積もりでは、最も楽観的な見積もり(O)、最も可能性の高い見積もり(M)、および悲観的な見積もり(最も可能性の低い見積もり(L))の3つの値が考慮されます。業界では、3点推定とPERTに関していくつかの混乱がありました。ただし、手法は異なります。2つのテクニックを学ぶと、違いがわかります。また、この章の最後に、違いを照合して示します。

PERTは、最も楽観的な推定値(O)、最も可能性の高い推定値(M)、および悲観的な推定値(最も可能性の低い推定値(L))の3つの値に基づいています。最も可能性の高い推定値は、他の2つの推定値(楽観的および悲観的)の4倍の重みが付けられています。

PERT推定(E)は加重平均に基づいており、ベータ分布に従います。

E = (O + 4 × M + L)/6

PERTは、クリティカルパス法(CPM)とともに頻繁に使用されます。CPMは、プロジェクトで重要なタスクについて説明します。これらのタスクに遅延があると、プロジェクトは遅延します。

標準偏差

標準偏差(SD)は、推定値の変動性または不確実性を測定します。

ベータ分布では、

平均=(O + 4×M + L)/ 6

標準偏差(SD)=(L − O)/ 6

PERT推定手順

Step (1) −WBSに到着します。

Step (2) −各タスクについて、最も楽観的な推定値(O)、最も可能性の高い推定値(M)、および悲観的な推定値(L)の3つの値を見つけます。

Step (3) − PERT平均=(O + 4×M + L)/ 6

PERT平均=(O + 4×M + L)/ 3

Step (4) −タスクの標準偏差を計算します。

標準偏差(SD)=(L − O)/ 6

Step (6) − WBSのすべてのタスクについて、手順2、3、4を繰り返します。

Step (7) −プロジェクトのPERT見積もりを計算します。

E(プロジェクト)= ∑ E(タスク)

Step (8) −プロジェクトの標準偏差を計算します。

SD(プロジェクト)=√(ΣSD(タスク)2

プロジェクトの見積もりを信頼水準に変換する

このように計算されたPERT推定(E)と標準偏差(SD)は、プロジェクトの推定を信頼水準に変換するために使用されます。

変換は次のように基づいています

  • E +/– SDの信頼水準は約68%です。
  • E値の信頼水準+/- 1.645×SDは約90%です。
  • E値+/- 2×SDの信頼水準は約95%です。
  • E値+/- 3×SDの信頼水準は約99.7%です。

一般に、95%の信頼水準、つまりE値+ 2×SDが、すべてのプロジェクトとタスクの見積もりに使用されます。

3点推定とPERTの違い

以下は、3点推定とPERTの違いです。

3点推定 PERT
単純平均 加重平均
三角分布に従う ベータ分布に従う
小さな反復プロジェクトに使用されます 大規模な非反復プロジェクト、通常はR&Dプロジェクトに使用されます。クリティカルパス法(CPM)とともに使用

E =平均=(O + M + L)/ 3

これは単純な平均です

E =平均=(O + 4×M + L)/ 6

これは加重平均です

SD =√[((O − E)2 +(M − E)2 +(L − E)2)/ 2] SD =(L − O)/ 6

Analogous Estimation同様の過去のプロジェクト情報を使用して、現在のプロジェクトの期間またはコストを見積もります。したがって、「アナロジー」という言葉が使用されます。現在のプロジェクトに関する情報が限られている場合は、類似の見積もりを使用できます。

経営幹部がプロジェクトを実行する価値があるかどうかを判断するための意思決定データを必要とするため、プロジェクトマネージャーが新しいプロジェクトのコストと期間の見積もりを提示するように求められることがよくあります。通常、プロジェクトマネージャーも組織内の他の誰も、新しいプロジェクトのようなプロジェクトを行ったことがありませんが、経営幹部は依然として正確なコストと期間の見積もりを望んでいます。

このような場合、類似の推定が最善の解決策です。完璧ではないかもしれませんが、過去のデータに基づいているため正確です。類似推定は、実装が簡単な手法です。プロジェクトの成功率は、当初の見積もりと比較して最大60%になる可能性があります。

類似の見積もり–定義

類似推定は、将来の活動のために同様のパラメータを推定するための基礎として、履歴データからのパラメータの値を使用する手法です。パラメータの例:スコープ、コスト、および期間。尺度の例の尺度-サイズ、重量、および複雑さ。

プロジェクトマネージャー、場合によってはチームの経験と判断が見積もりプロセスに適用されるため、履歴情報と専門家の判断の組み合わせと見なされます。

類似の推定要件

類似の見積もりの​​場合、以下が要件です。

  • 以前および進行中のプロジェクトからのデータ
    • 各チームメンバーの週あたりの労働時間
    • プロジェクトを完了するために必要な費用
  • 現在のプロジェクトに近いプロジェクト
  • 現在のプロジェクトが新しく、過去のプロジェクトが類似していない場合
    • 現在のプロジェクトと同様の過去のプロジェクトのモジュール
    • 現在のプロジェクトと同様の過去のプロジェクトからの活動
    • これらの選択されたものからのデータ
  • プロジェクトマネージャーと見積もりチームの参加により、見積もりに関する経験豊富な判断を確実にします。

類似の推定ステップ

プロジェクトマネージャーとチームは、類似した見積もりをまとめて行う必要があります。

  • Step 1 −現在のプロジェクトのドメインを特定します。

  • Step 2 −現在のプロジェクトのテクノロジーを特定します。

  • Step 3−同様のプロジェクトデータが利用できる場合は、組織データベースを調べます。可能な場合は、ステップ(4)に進みます。それ以外の場合は、手順(6)に進みます。

  • Step 4 −現在のプロジェクトを特定された過去のプロジェクトデータと比較します。

  • Step 5−現在のプロジェクトの期間とコストの見積もりに到着します。これで、プロジェクトの類似した見積もりは終了です。

  • Step 6 −過去のプロジェクトに現在のプロジェクトと同様のモジュールがある場合は、組織データベースを調べます。

  • Step 7 −過去のプロジェクトに現在のプロジェクトと同様の活動があるかどうかを組織データベースで調べます。

  • Step 8 −それらをすべて収集し、専門家の判断を使用して、現在のプロジェクトの期間とコストの見積もりに到達します。

類似推定の利点

  • 詳細がほとんどわからないプロジェクトの初期段階では、類似の見積もりがより良い見積もり方法です。

  • 手法は単純で、見積もりにかかる時間は非常に短くなります。

  • この手法は組織の過去のプロジェクトデータに基づいているため、組織の成功率は高いと予想されます。

  • 類似の見積もりを使用して、個々のタスクの労力と期間を見積もることもできます。したがって、WBSでは、タスクを見積もるときにアナロジーを使用できます。

プロジェクト管理およびシステムエンジニアリングのWBS(Work Breakdown Structure)は、プロジェクトをより小さなコンポーネントに成果物指向で分解したものです。WBSは、チームの作業を管理可能なセクションに編成する重要なプロジェクト成果物です。プロジェクトマネジメント知識体系(PMBOK)は、WBSを「プロジェクトチームによって実行される作業の成果物指向の階層的分解」と定義しています。

WBS要素は、製品、データ、サービス、またはそれらの任意の組み合わせである可能性があります。WBSは、スケジュールの作成と管理のガイダンスを提供するとともに、詳細なコスト見積もりと管理に必要なフレームワークも提供します。

WBSの表現

WBSは、プロジェクトの作業活動の階層リストとして表されます。WBSには2つの形式があります-

  • アウトラインビュー(インデント形式)
  • ツリー構造ビュー(組織図)

まず、WBSを準備するためにアウトラインビューを使用する方法について説明します。

外形図

アウトラインビューは非常にユーザーフレンドリーなレイアウトです。プロジェクト全体がよく見え、簡単に変更することもできます。プロジェクトのさまざまな段階を記録するために数字を使用します。次のようになります-

  • Software Development

    • Scope

      • プロジェクトの範囲を決定する
      • 安全なプロジェクトスポンサーシップ
      • 予備的なリソースを定義する
      • 安全なコアリソース
      • スコープが完了しました
    • Analysis/Software Requirements

      • ニーズ分析を実施する
      • 予備的なソフトウェア仕様のドラフト
      • 予備予算を作成する
      • チームでソフトウェアの仕様/予算を確認する
      • ソフトウェア仕様に関するフィードバックを組み込む
      • 納期を作成する
      • 続行するための承認を取得します(概念、タイムライン、および予算)
      • 必要なリソースを確保する
      • 分析が完了しました
    • Design

      • 予備的なソフトウェア仕様を確認する
      • 機能仕様を作成する
      • 続行するための承認を取得します
      • 設計完了
    • Development

      • 機能仕様を確認する
      • モジュール式/階層型の設計パラメータを特定する
      • コードを開発する
      • 開発者テスト(一次デバッグ)
      • 開発完了
    • Testing

      • 製品仕様を使用して単体テスト計画を作成します
      • 製品仕様を使用して統合テスト計画を作成します
    • Training

      • エンドユーザー向けのトレーニング仕様を作成する
      • トレーニングの提供方法を​​特定する(オンライン、教室など)
      • トレーニング資料を作成する
      • トレーニング資料を完成させる
      • トレーニング提供メカニズムを開発する
      • トレーニング資料の完成
    • Deployment

      • 最終的な展開戦略を決定する
      • 展開方法を開発する
      • 安全な導入リソース
      • 電車サポートスタッフ
      • ソフトウェアを展開する
      • 展開が完了しました

次に、ツリー構造ビューを見てみましょう。

ツリー構造ビュー

ツリー構造ビューは、プロジェクト全体の非常にわかりやすいビューを表示します。次の図は、ツリー構造ビューがどのように見えるかを示しています。このタイプの組織図構造は、MS-Wordで利用可能な機能を使用して簡単に描画できます。

WBSの種類

WBSには2つのタイプがあります-

  • Functional WBS−機能WBSでは、開発するアプリケーションの機能に基づいてシステムが壊れています。これは、システムのサイズを見積もるのに役立ちます。

  • Activity WBS−アクティビティWBSでは、システム内のアクティビティに基づいてシステムが中断されます。アクティビティはさらにタスクに分割されます。これは、システムの労力とスケジュールを見積もるのに役立ちます。

サイズの見積もり

Step 1 −機能的なWBSから始めます。

Step 2 −リーフノードを検討します。

Step 3 −アナロジーまたはワイドバンドデルファイのいずれかを使用して、サイズの見積もりに到達します。

労力の見積もり

Step 1−ワイドバンドDelphiテクニックを使用してWBSを構築します。タスクは8時間を超えないようにすることをお勧めします。タスクの期間が長い場合は、タスクを分割します。

Step 2 −ワイドバンドDelphi手法または3点見積もりを使用して、タスクの労力見積もりに到達します。

スケジューリング

WBSの準備が整い、サイズと労力の見積もりがわかったら、タスクをスケジュールする準備が整います。

タスクをスケジュールする際には、特定のことを考慮に入れる必要があります-

  • Precedence −他のタスクの前に発生しなければならないタスクは、他のタスクよりも優先されると言われます。

  • Concurrence −並行タスクとは、同時に(並行して)発生する可能性のあるタスクです。

  • Critical Path −プロジェクトの完了日が依存する特定の一連の順次タスク。

    • すべてのプロジェクトにはクリティカルパスがあります。
    • 重要でないタスクを加速しても、スケジュールが直接短縮されることはありません。

クリティカルパス法

クリティカルパス法(CPM)は、クリティカルパスを決定および最適化するためのプロセスです。クリティカルパス以外のタスクは、完了日に影響を与えることなく、早くまたは遅く開始できます。

現在のパスを短くすると、クリティカルパスが別のパスに変わる可能性があることに注意してください。たとえば、前の図のWBSの場合、クリティカルパスは次のようになります。

プロジェクトの完了日は一連の連続したタスクに基づいているため、これらのタスクはクリティカルタスクと呼ばれます。

プロジェクトの完了日は、トレーニング、ドキュメント、および展開に基づいていません。このようなタスクは、重要ではないタスクと呼ばれます。

タスクの依存関係

スケジュールを立てるときに、タスクの依存関係を考慮する必要がある場合があります。重要なタスクの依存関係は次のとおりです。

  • フィニッシュツースタート(FS)
  • フィニッシュツーフィニッシュ(FF)

フィニッシュツースタート(FS)

Finish-to-Start(FS)タスクの依存関係では、タスクAが完了するまでタスクBを開始できません。

フィニッシュツーフィニッシュ(FF)

終了から終了(FF)のタスク依存関係では、タスクAが完了するまでタスクBを終了できません。

ガントチャート

ガントチャートは、1896年にKarol Adamieckiによって、1910年代にHenry Ganttによって独立して採用された棒グラフの一種であり、プロジェクトのスケジュールを示しています。ガントチャートは、プロジェクトの終了要素と要約要素の開始日と終了日を示します。

図2のアウトライン形式をMicrosoftProjectに取り込んで、ガントチャートビューを取得できます。

マイルストーン

マイルストーンは、スケジュールの重要な段階です。それらの期間はゼロであり、特定の一連のタスクを完了したことを示すために使用されます。マイルストーンは通常、ひし形で表示されます。

たとえば、上記のガントチャートでは、設計完了と開発完了がマイルストーンとして表示され、ひし形で表されています。

マイルストーンは契約条件に関連付けることができます。

WBSを使用した推定の利点

WBSは、プロジェクト見積もりの​​プロセスを大幅に簡素化します。他の推定手法に比べて、次の利点があります。

  • WBSでは、プロジェクトによって実行されるすべての作業が識別されます。したがって、プロジェクトの利害関係者と一緒にWBSを確認することで、目的のプロジェクト成果物を提供するために必要な作業を省略する可能性が低くなります。

  • WBSにより、より正確なコストとスケジュールの見積もりが得られます。

  • プロジェクトマネージャーは、WBSを完成させるためにチームの参加を得ます。チームのこの関与は、プロジェクトへの熱意と責任を生み出します。

  • WBSは、タスク割り当ての基礎を提供します。正確なタスクは、その達成に責任を持つ特定のチームメンバーに割り当てられます。

  • WBSにより、タスクレベルでの監視と制御が可能になります。これにより、進捗状況を測定し、プロジェクトが時間どおりに提供されることを確認できます。

プランニングポーカーの見積もり

プランニングポーカーは、コンセンサスベースの見積もり手法であり、主にスクラムのユーザーストーリーの労力や相対的なサイズを見積もるために使用されます。

プランニングポーカーは、広帯域Delphi手法、類似推定、およびWBSを使用した推定の3つの推定手法を組み合わせたものです。

プランニングポーカーは、2002年にジェームズグレニングによって最初に定義され、名前が付けられました。その後、マイクコーンによって、彼の著書「アジャイルな見積りと計画」で普及しました。

プランニングポーカーの見積もり手法

プランニングポーカー推定手法では、ユーザーストーリーの推定値は、プランニングポーカーをプレイすることによって導き出されます。スクラムチーム全体が関与しており、迅速で信頼性の高い見積もりが得られます。

  • プランニングポーカーはカードのデッキでプレイされます。フィボナッチ数列が使用されているため、カードには1、2、3、5、8、13、21、34などの番号が付いています。これらの番号は「ストーリーポイント」を表しています。各推定量には、カードのデッキがあります。カードの数字は、チームメンバーの1人がカードを持っているときに、すべてのチームメンバーに見えるように十分に大きくする必要があります。

  • チームメンバーの1人がモデレーターとして選ばれます。モデレーターは、見積もりが行われているユーザーストーリーの説明を読みます。見積もり担当者に質問がある場合は、製品の所有者が回答します。

  • 各見積もり担当者は、自分の見積もりを表すカードを個人的に選択します。すべての推定者が選択を行うまで、カードは表示されません。その際、すべてのチームメンバーがそれぞれの見積もりを確認できるように、すべてのカードが同時に裏返され、保持されます。

  • 最初のラウンドでは、見積もりが異なる可能性が非常に高くなります。高推定量と低推定量は、推定の理由を説明します。すべての議論は理解のみを目的としており、個人的には何も行われないように注意する必要があります。モデレーターは同じことを確認する必要があります。

  • チームは、ストーリーとその見積もりについて、さらに数分間話し合うことができます。

  • モデレーターは、特定のストーリーが作成されるときに役立つディスカッションについてメモを取ることができます。話し合いの後、各推定者はカードを再度選択して再推定します。カードは、全員が推定するまで再び非公開にされ、推定されると同時に裏返されます。

見積もりがストーリーに使用できる単一の見積もりに収束するまで、このプロセスを繰り返します。見積もりの​​ラウンド数は、ユーザーストーリーごとに異なる場合があります。

プランニングポーカー見積もりの​​利点

プランニングポーカーは、3つの見積もり方法を組み合わせたものです。

Expert Opinion−専門家の意見に基づく推定アプローチでは、専門家は何かにかかる時間または大きさを尋ねられます。専門家は、彼または彼女の経験または直感または直感に基づいて見積もりを提供します。専門家の意見の見積もりは、通常、それほど時間はかからず、いくつかの分析方法と比較してより正確です。

Analogy−類推は、ユーザーストーリーの比較を使用します。推定中のユーザーストーリーは、以前に実装された同様のユーザーストーリーと比較され、推定は実証済みのデータに基づいているため、正確な結果が得られます。

Disaggregation−分解の推定は、ユーザーストーリーをより小さく、推定しやすいユーザーストーリーに分割することによって行われます。スプリントに含まれるユーザーストーリーは、通常、開発に2〜5日の範囲です。したがって、より長い時間がかかる可能性のあるユーザーストーリーは、より小さなユースケースに分割する必要があります。このアプローチはまた、比較可能な多くのストーリーがあることを保証します。

テストの取り組みは、明確な時間枠に基づいていません。テストの完了に関係なく、事前に決定されたタイムラインが設定されるまで、取り組みは継続されます。

これは主に、従来、 test effort estimation の一部です development estimation。Wideband Delphi、Three-point Evaluation、PERT、WBSなどのWBSを使用する推定手法の場合にのみ、テストアクティビティの推定値を取得できます。

ファンクションポイント(FP)として見積もりを取得した場合は、CaperJonesに従って次のようになります。

Number of Test Cases = (Number of Function Points) × 1.2

テストケースの数が決まったら、組織のデータベースから生産性データを取得して、テストに必要な作業に取り掛かることができます。

開発努力法の割合

必要なテスト作業は、開発作業の直接的な割合または割合です。開発作業は、コード行(LOC)またはファンクションポイント(FP)を使用して見積もることができます。次に、テストの労力の割合が組織データベースから取得されます。そのようにして得られたパーセンテージは、テストの作業量の見積もりに到達するために使用されます。

テストプロジェクトの見積もり

現在、いくつかの組織がクライアントに独立した検証および妥当性確認サービスを提供しています。これは、プロジェクト活動が完全にテスト活動になることを意味します。

テストプロジェクトを見積もるには、ソフトウェアテストライフサイクルのさまざまなプロジェクトでの経験が必要です。テストプロジェクトを見積もるときは、次のことを考慮してください。

  • チームスキル
  • 領域知識
  • アプリケーションの複雑さ
  • 歴史的なデータ
  • プロジェクトのバグサイクル
  • リソースの可用性
  • 生産性の変動
  • システム環境とダウンタイム

推定手法のテスト

以下のテスト推定手法は正確であることが証明されており、広く使用されています。

  • PERTソフトウェアテスト推定手法
  • UCPメソッド
  • WBS
  • 広帯域デルファイ技術
  • ファンクションポイント/テストポイント分析
  • パーセンテージ分布
  • 経験に基づくテスト推定手法

PERTソフトウェアテストの見積もり手法

PERTソフトウェアテスト推定手法は、各テストタスクをサブタスクに分割し、各サブタスクで3種類の推定を行う統計手法に基づいています。

この手法で使用される式は次のとおりです。

Test Estimate = (O + (4 × M) + E)/6

どこ、

O =楽観的な見積もり(何も問題がなく、すべての条件が最適である最良のシナリオ)。

M =最も可能性の高い見積もり(最も可能性の高い期間であり、問​​題がある可能性がありますが、ほとんどのことがうまくいきます)。

L =悲観的な見積もり(すべてがうまくいかない最悪のシナリオ)。

手法の標準偏差は次のように計算されます-

Standard Deviation (SD) = (E − O)/6

ユースケースポイント法

UCPメソッドは、未調整のアクターの重みと未調整のユースケースの重みを計算してソフトウェアテストの見積もりを決定するユースケースに基づいています。

ユースケースは、関連するアプリケーションと対話するさまざまなユーザー、システム、またはその他の利害関係者を指定するドキュメントです。彼らは「俳優」と名付けられています。相互作用は、シナリオと呼ばれるさまざまな動作またはフローを通じて、すべての利害関係者の利益を保護するいくつかの定義された目標を達成します。

Step 1−番号を数えます。俳優の。アクターには、ポジティブ、ネガティブ、例外が含まれます。

Step 2 −未調整のアクターの重みを次のように計算します

Unadjusted Actor Weights = Total no. of Actors

Step 3 −ユースケースの数を数えます。

Step 4 −未調整のユースケースの重みを次のように計算します

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 −未調整のユースケースポイントを次のように計算します

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6−技術的/環境的要因(TEF)を決定します。利用できない場合は、0.50とします。

Step 7 −調整されたユースケースポイントを次のように計算します

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 −総労力を次のように計算します

Total Effort = Adjusted Use-Case Point × 2

作業分解図

Step 1 −テストプロジェクトを細かく分割してWBSを作成します。

Step 2 −モジュールをサブモジュールに分割します。

Step 3 サブモジュールをさらに機能に分割します。

Step 4 −機能をサブ機能に分割します。

Step 5 −すべてのテスト要件を確認して、それらがWBSに追加されていることを確認します。

Step 6 −チームが完了する必要のあるタスクの数を把握します。

Step 7 −各タスクの労力を見積もります。

Step 8 −各タスクの期間を見積もります。

ワイドバンドデルファイテクニック

ワイドバンドデルファイ方式では、WBSは、タスクを再推定するために3〜7人のメンバーで構成されるチームに配布されます。最終的な見積もりは、チームのコンセンサスに基づいて要約された見積もりの​​結果です。

この方法は、統計式ではなく、経験について詳しく説明します。この方法は、チームがテストの労力を見積もりながら問題のさまざまな側面を視覚化するコンセンサスに到達するためのグループ反復を強調するために、BarryBoehmによって普及しました。

ファンクションポイント/テストポイント分析

FPは、ユーザーの視点からソフトウェアアプリケーションの機能を示し、ソフトウェアプロジェクトのサイズを見積もる手法として使用されます。

テストでは、見積もりは要件仕様書、または以前に作成されたアプリケーションのプロトタイプに基づいています。プロジェクトのFPを計算するには、いくつかの主要なコンポーネントが必要です。彼らは-

  • Unadjusted Data Function Points − i)内部ファイル、ii)外部インターフェース

  • Unadjusted Transaction Function Points − i)ユーザー入力、ii)ユーザー出力、iii)ユーザーからの問い合わせ

  • Capers Jones basic formula

    テストケースの数=(ファンクションポイントの数)×1.2

  • Total Actual Effort (TAE)

    (テストケース数)×(開発努力率/ 100)

パーセンテージ分布

この手法では、ソフトウェア開発ライフサイクル(SDLC)のすべてのフェーズに%単位の作業が割り当てられます。これは、同様のプロジェクトの過去のデータに基づくことができます。例-

段階 努力の%
プロジェクト管理 7%
要件 9%
設計 16%
コーディング 26%
テスト(すべてのテストフェーズ) 27%
ドキュメンテーション 9%
インストールとトレーニング 6%

次に、テストの労力の割合(すべてのテストフェーズ)がすべてのテストフェーズにさらに分散されます-

すべてのテストフェーズ 努力の%
コンポーネントテスト 16
独立したテスト 84
Total 100
独立したテスト 努力の%
統合テスト 24
システムテスト 52
受け入れ試験 24
Total 100
システムテスト 努力の%
機能システムテスト 65
非機能的なシステムテスト 35
Total 100
テスト計画と設計アーキテクチャ 50%
レビューフェーズ 50%

経験に基づくテスト推定手法

この手法は、類推と専門家に基づいています。この手法は、以前のプロジェクトで同様のアプリケーションをすでにテストし、それらのプロジェクトからメトリックを収集したことを前提としています。また、以前のテストからメトリックを収集しました。アプリケーション(およびテスト)をよく知っている対象分野の専門家から入力を受け取り、収集したメトリックを使用して、テスト作業に到達します。