関数ポイント分析 - 真剣に過大評価された手法ですか？

https://stackoverflow.com/questions/2694382

01-10-2019
|

質問

賞金の明確化

私はそれが主観的な質問であることを知っています。私が探している理想的な答えは、ここで引用されたシナリオがとても驚くべきものである理由を説明するものです。

引用されたシナリオが事実だと思うなら いいえ 驚くべきことで、期待するために、このような小さなアプリが1か月以上、数千ドルの開発がどのようにかかるかを証明するための手順を分解してください。私は計算を行うためにかなり遠くまで行きました（たとえば、最低賃金を調べる）ので、理想的な答えが同様のことをすることを期待しています。

引用されたシナリオが実際に過大評価されていると思われる場合は、正確に理由を特定してください。彼の計算でどのような間違いを見つけることができ、そのような単純なアプリケーションにこのような大きなコストにつながりましたか？どうやって違うことをしましたか？（プロセス全体を書く必要はありませんが、一般化された感情の代わりに詳細がいいでしょう）

私はFPAについての質問を何度も尋ねられたことを知っていますが、今回はより分析的な角度を取っています、 データをバックアップしました.

1.最初に、いくつかのデータ

この質問はaに基づいていますチュートリアル. 。彼には「サンプルカウント」セクションがあり、そこで段階的にそれを実証しました。いくつかを見ることができます彼のサンプルアプリケーションのスクリーンショットはこちら.

最終的に、彼調整されていないFPを計算しましたすることが 99.

もう一つの...がある Informitの記事典型的な時間/FPに関する業界データを使用しています。 2時間/fpから27.4時間/fpの範囲です。固執しましょう 2 今のところ（そう読者はおそらくより効率的な群衆であるので：P）。

2.リアリティチェック！？

今すぐチェックしてくださいスクリーンショットまた。

ここで少し数学をしてください

99 * 2 = 198 hours
198 hours / 40 hours per week = 5 weeks

真剣に？そのサンプルアプリケーションは実装に5週間かかりますか？ 1週間以上かかるプログラマーはかかることはないと感じています（週末さえ言っていません）。

それでは、プロジェクトのコストを見積もってみましょう。現在、ニューヨークの最低賃金を使用します（ウィキペディア）、7.25ドルです

198 * 7.25 = $1435.5

スクリーンショットから見ることができるものから、このアプリケーションは小さなExcel改善アプリです。 MS Office Proを200ドルで購入することもできます。

（記録のために、その同じWebサイトには生産性について議論する別の記事があります。通常、4.2時間/FPを使用しているようです。これにより、さらに衝撃的な統計が得られます。

99 * 4.2 = 415 hours = 10 weeks = almost 3 whopping months!
415 hours * $7.25 = $3000 zomg

（それは私たちの貧しいコーダー全員が最低賃金を得るとさえ仮定しています！）

3.ここで何かが足りませんか？

今、私はいくつかの可能な説明を思いつくことができました：

FPAは本当に大きなプロジェクト（1000以上のFPS）にのみ適しているため、小規模で非常に不正確になります。
時間/FPメトリックは変動します突然チームからチーム、プロジェクトへのプロジェクト。このような小さなプロジェクトでは、0.5時間/fpなどを使用することもできました。（今、この種の推定は、私の会社が同じチームで数年間同じタイプのプロジェクトを行っていない限り、実際には一般的ではない場合を除き、推定全体を無意味にします。）

いくつかのソフトウェアメトリックの経験から、機能ポイントは実際には軽量のメトリックではありません。時間/fpのことが非常に変動した場合、ポイントは何ですか。おそらく、手に入れるのがはるかに速く、間違いなくほとんど不確実なユーザーストーリーポイントを使用できたかもしれません。

これに対するFPの専門家の答えは何でしょうか？

解決

約10年前、私の飲酒仲間が私に本当に素晴らしい知恵を与えてくれました。プロジェクト相談では、3つの質問をします。1。私たちが解決しようとしている問題は何ですか？ 2.成果物は何ですか？ 3.いつ完了したかをどのように知ることができますか？彼は、プロジェクトが開始される前に質問のいずれも回答されなかったプロジェクトを引き受けるべきではないと付け加えました。

手元にあるケースでは、さらに別のソフトウェア推定方法ホラーストーリーがあります。私は彼が2番目と3番目の質問に答えを与えていないことを指摘することで彼のホラーストーリーに答えます。彼は「私たちはこのようなものを作るものを作りたい」と言うことを除いて、最初の質問に実際に答えていません。

彼は、推定された合計を含む、または除外されている関数ポイントがどのタスクであるかを明示的に尋ねていないことを指摘することで、それを拡張します。たとえば、ファンクションポイント推定器はドキュメントを許可する余分な労力をどれくらいの余分な労力をかけていますか？彼の見積もりがドキュメントなしでアプリケーションのものであり、関数ポイント推定器の推定が完全なドキュメントを備えたアプリケーション用であった場合、必要な労働総量（および時間）の合計量に不一致の余地があると思います。

他のヒント

1週間以上かかるプログラマーはかかることはないと感じています（週末さえ言っていません）。

開発者は常に、実際に何かを終えるのにどれくらいの時間がかかるかを過小評価する傾向があります。彼らは、バグも要件に変化もなく、今までになかったことも何もないと考えており、把握するのに何日も費やさなければならないと考えています。

スクリーンショットから見ることができるものから、このアプリケーションは小さなExcel改善アプリです。 MS Office Proを200ドルで購入することもできます。

完全にカスタムのソフトウェアの価格を数百万コピーを販売しているソフトウェアと比較していますか？真剣に？

現実には、ソフトウェアの推定のほとんどの方法は実際には過小評価されていますが、最初は赤面しても直感に反するようです。私はかつて、月ごとに300行のコードが高い見積もりと見なされていた会社で働いていましたが、ほとんどの月は200-250のように入ってきました。しかし、200を使用してみましょう。これは、1日あたり10行のコードです。就業日に10行のコードを書くことができないのは誰ですか？来て！良い日に50から100以上のコードを書くことができました！それでも、このような数字を使用している企業は、スケジュールと予算を超えてプロジェクトを繰り返し完了します。何故ですか？まあ、マイケル・ボルグワードが示唆するように、スコープクリープは大きなものです。しかし、それを1分間写真から引き出し、顧客とクライアントが初めてそれを正しくしたと仮定しましょう。なぜ企業は1日あたり10行のコードしか見積もっていないのですか？

要件の分析
要件に基づくソフトウェア設計
チームメイトとインターフェイスとアーキテクチャを調整するミーティング。
オーバーヘッドコスト（管理、病気の時間、休暇などとのステータスミーティング...）
ユニットテストの書き込み
Applicaiton全体のテスト計画を作成します
アプリケーションレベルのテスト

これは、3分で頭の上部を引き出すことができる日々のソフトウェアエンジニアリングです。もう少し逃したと確信していますが、それらの見積もりがどこから来ているのかをより完全に把握するのに役立ちますか？

FPの専門家ではありません。ただし、現時点ではFPを検討しています。特に、努力 /コストなどの指標があるという古いプロジェクトに対してFP分析を実行しています。その後、推定 /サイジングプロジェクトでのその有用性を評価できます。

この時点での私の見解は、それがボトムアップの推定を補うために有用なトップダウン「桁数」の推定になるだろうということです。「ホールドアップ」に到達している数値を検証するために、複数の推定手法を適用できる場合は常に良いことです。

さらなる考え方 - 関数ポイントあたりのコスト /努力（つまり、機能的要件）は、システムに必要な非機能要件に依存します。セキュリティ、アクセシビリティ、パフォーマンス、ロギング（および警告）、保守性、携帯性、規制コンプライアンスなどを考慮して、FPあたりのコスト/努力が大幅に増加します。現在、これらは見積もられた単一のユーザーサンプルアプリの考慮事項ではない可能性があります。しかし、このアプリケーションが企業または潜在的に顧客または一般の人々の幅広い割合にとって重要である場合、これらの非機能的要件を考慮する必要性は確かに増加します。

個人的には、FPAが誤解を招くことがわかりました...最初は。

以前のプロジェクトの履歴FPAデータがない限り、FPAは業界標準を使用して、間違いなく全体を過剰に過大評価することになります。

VAFは、FPAを扱う際に使用するのに適したポインターであることがわかりました。 FPカウントで35％のバリエーション範囲が得られますが、アナリスト/プロジェクトマネージャーがこれを50％のバリエーションに変えるのを止めています。

優れたチームリーダーは、推定する前に常にチームの能力を評価します。 FPAについても同じことが言えば、業界標準の数値は履歴データに基づいて到達し、このデータは会社、チーム、チーム、開発者までさまざまです。

ですから、調整されていないカウントで-35％のベストケースシナリオを使用すると、調整されたFPカウントが〜64に達すると思います。約3週間半の見積もりを提供します。経験から、この種の適用はそれよりも早く行うことができると思いますが、徹底的なテスト、デバッグ、ドキュメント、その他のペーパーワークはさらに拡大し、FPはそれを考慮します。チームが1 fp/hrを実行している可能性は非常に高いです。通常の基準では、FPカウントの25％をコーディングとテストするため、この場合、99 FPSの数値を取得しても、コーディングとテストの部分は25 fpsになります。

私が実際に見たのは、一部の企業が独自の複雑さのテーブルを考案したため、3回のRETと10のDETが1つの会社の平均複雑さを平均的に平均的にする場合、別の企業がそれを低いと評価することです。これは、最終的なFPカウントに大きく影響します。

したがって、FPツールをガイドとして使用し、実際にFPAに頼ってコストと時間の見積もりを設定する前に、以前のプロジェクトのデータをできるだけ多くのデータを収集します。

サイドノートとして、アウトソーシングとフリーランスが最適なものであるような単純なソフトウェアの原価計算の見積もりは、今日はばかげているように思えると思います。このビジネスに携わっている大企業は、ソフトウェア開発のためにまだ途方もなく高い料金を請求しています。たとえば、レベル3のサポートエンジニアに優れたホスティング会社のサーバーを支援したい場合は、1時間あたり250ドルを請求しますが、世界の他の場所に拠点を置く人から25ドルまたは2.5ドルで同じアドバイスを得ることができます。

私の2セントがあなたに慣れていることを願っています。

私の前の会社では、そのように計算したでしょう - 特に誰かの場合欲求それを支払うために;）

私はいくつかのプロジェクトでFPを練習しましたが、それがかなり正確な見積もりを提供することを発見しました。アプリケーションのタイプに応じて過大評価し、時には過小評価する場合があります。通常、科学的アプリケーションの場合、FPは過小評価される可能性があります。 FPは、コードを作成する時間だけでなく、プロジェクト開発時間全体を提供します。もちろん、テスト環境のセットアップなどの開発活動はありません。これらは別々に推定する必要があります。私はFPの大きな支持者ではありませんが、その使用に感謝しています。正確な推定ではない場合、適切に実践されている場合（ファイルと記録要素の識別）、少なくとも要件の完全性を検証します。

ある意味では、FPは中程度から大規模なプロジェクトに適しており、350〜400 fpsを超える拡張に適していると言う必要があります。

時間ベースの支払いは、間接的にパフォーマンスの低下につながります。プロジェクトベースの支払い方法があれば、プロジェクトの各側面について多くの調査を行ったという時間ベースの支払いのプロジェクトを覚えています。それは倫理ではなく無意識の心です。ベストプラクティスは、「プロジェクト」の定義（限られた時間と予算内）を参照し、制限に基づいて決定を下すことです。それは仕事そのものに関するものではありません。つまり、雨の日には普通に購入するよりもはるかに傘の費用を支払います。何ができたのか、どれだけの価値があるかについて気にしないでください。顧客に対する仕事の価値と彼の選択に焦点を当てます。

この便利なオンライン関数ポイント計算機に引用した例から値を差し込むhttp://developergeeks.com/functionpoint.aspx）、調整されたFPSを計算し、他のさまざまな重み付け係数を考慮して、例のシステムが非常に簡単であるため、1時間あたり2 fpsの生産性率を想定して、次の結果が得られます。

調整FPS：42.9
推定者数ヶ月：0.54

1人の開発者にとって、約86.4時間、または約2週間で作業するために、就業月に160時間を想定しています。ステップ2で結論付けたように5週間ではありません。顧客を支払うためのシステムを開発するには、あなた自身の娯楽のために夜遅くにコードを叩くよりも少し注意と労力を費やす必要があることを考えると、それは不当な見積もりではないと思いますすべて。

つまり、誤解しないでください、間違った手でのFP分析はおそらくひどい考えです。しかし、開発者の背景を持っている場合、FPSをカウントし、さまざまな重み付け要因をチェックすることに適用できます。、完全に文書化された要件または詳細なタスクレベルのプロジェクト計画から作業する。しかし、あなたはそれをあなたのために機能させるためにいくつかの常識を使わなければなりません。

いくつかのソフトウェアメトリックの経験から、機能ポイントは実際には軽量のメトリックではありません。時間/fpのことが非常に変動した場合、ポイントは何ですか。おそらく、手に入れるのがはるかに速く、間違いなくほとんど不確実なユーザーストーリーポイントを使用できたかもしれません。

関数ポイント分析を行うことのポイントは、（特定のマージン内で）必要になるように、客観的で標準的なルール/ガイドラインを持っていることです。ルールが一貫して正しく適用されている場合、どの専門家がそれをカウントしましたか。発見したように、ファンクションポイントごとの生産性は、チームエクスペリエンス、ツール、プログラミング言語、プラットフォームなどなどの多くの要因に非常に信頼できます。）。繰り返しカウントの主な価値は、あなた自身のチームの生産性履歴に基づいて、独自の「Benchnmark」を構築することです。これは、トレンドを見て、将来の変更に必要な時間を計画および予測するのに役立ちます。速度を探している場合は、詳細なカウントの代わりにグローバルカウントを適用するだけです。いくつかの例を実行する場合（試験の準備をするときなど）、詳細なカウントとグローバルカウントの違いが睡眠を失うほど大きくないことに気付くでしょう（％）。

この議論は、FPAが努力の推定手法であるとすでに想定しているため、この議論は絶対に誤解を招くものです。 そうではない.

関数サイズ（関数ポイントで表される）は、推定モデル（ココモなど）の多くの入力因子の1つです。それ以上ではありませんが、機能的要件の「量」がソフトウェアプロジェクトの努力ドライバーであることに同意した場合、それ以上ではありません。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow