17

報奨金の説明

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

引用されたシナリオが事実であり、予想されることであると思われる場合は、このような小さなアプリの開発に 1 か月以上と数千ドルかかることを証明する手順を詳しく説明してください。私は計算をかなり行ったので (たとえば、最低賃金を調べるなど)、理想的な答えは同様のことを期待しています。

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

FPA に関する質問はこれまでに何度も出されていることは承知していますが、今回はデータに裏付けられたより分析的な角度から取り上げます。

1. まず、いくつかのデータ

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

最終的に、彼は未調整の FPを と計算しました99。

典型的な時間/FP に関する業界データを含む InformIT に関する別の記事があります。2 時間/FP から 27.4 時間/FP の範囲です。2しばらくの間、固執しようとしましょう(SO の読者はおそらくより効率的な群衆なので:p)。

2. 実態調査!?

もう一度スクリーンショットをチェックしてください。

ここで少し計算してみましょう

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

真剣に？そのサンプル アプリケーションの実装には 5 週間かかりますか? まともなプログラマーであれば、完成までに 1 週​​間 (週末とは言っていない) もかからないだろうというのは、私の感覚でしょうか?

それでは、プロジェクトのコストを見積もってみましょう。現時点でのニューヨークの最低賃金 ( Wikipedia ) を使用します。これは $7.25 です。

198 * 7.25 = $1435.5

スクリーンショットからわかることから、このアプリケーションは小さな Excel 改善アプリです。MS Office Pro を 200 ドルで購入できたので、相互運用性 (.xls ファイル) と柔軟性 (スプレッドシート) が向上しました。

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

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

(これは、私たちの貧弱なプログラマー全員が最低賃金を得ているとさえ仮定しています!)

3. 何か足りないものはありますか?

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

  1. FPA は実際には大規模なプロジェクト (1000 以上の FP) にのみ適しているため、小規模では非常に不正確になります。
  2. 時間/FP メトリックは、チームごと、プロジェクトごとに急激に変動します。このような小さなプロジェクトの場合、0.5 時間/FP などを使用できます。(私の会社が同じチームで同じ種類のプロジェクトを数年間行うのでなければ、この種の見積もりは無意味になります。これはあまり一般的ではありません。)

いくつかのソフトウェア メトリクスに関する私の経験から、Function Point は実際には軽量のメトリクスではありません。時間/FP が大きく変動する場合、何がポイントなのかというと、ユーザー ストーリー ポイントを使用する方がはるかに高速であり、間違いなくほとんど不確実である可能性があります。

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

4

11 に答える 11

12

約 10 年前、私の飲み仲間は私に本当に素晴らしい知恵を教えてくれました。プロジェクトのコンサルテーションでは、次の 3 つの質問をしてください。 1. 解決しようとしている問題は何ですか? 2. 成果物は何ですか? 3. 完了したことをどのように知ることができますか? 彼は、プロジェクトが始まる前に質問のいずれにも答えられなかったプロジェクトを引き受けるべきではないと付け加えました.

目の前のケースでは、見積もりがとてつもなく高いように見える、さらに別のソフトウェア見積もり方法のホラー ストーリーがあります。私は、彼が 2 番目と 3 番目の質問に答えていないことを指摘して、彼のホラー ストーリーに答えます。

ファンクションポイントの見積もりが見積もりの​​合計にどのタスクを含め、または除外しているのかを彼が明確に尋ねていないことを指摘することで、それをさらに拡張します. たとえば、ファンクション ポイント エスティメータは、ドキュメントを作成するためにどれだけの労力を割くことができるでしょうか? 彼の見積もりがドキュメントのないアプリケーションの見積もりであり、ファンクション ポイント見積もり担当者の見積もりが完全なドキュメントを含むアプリケーションの見積もりである場合、必要な作業の総量 (および時間) について意見の相違の余地があると思います。

于 2010-06-09T21:05:28.427 に答える
9

まともなプログラマーであれば、完成までに 1 週​​間 (週末とは言っていない) もかからないだろうというのは、私の感覚でしょうか?

開発者は常に、実際に何かを完了するのにかかる時間を過小評価する傾向があります。彼らは、バグや要件の変更はなく、これまで行ったことのないことはないと考えており、その解決に何日も費やす必要があります。

スクリーンショットからわかることから、このアプリケーションは小さな Excel 改善アプリです。MS Office Pro を 200 ドルで購入できたので、相互運用性 (.xls ファイル) と柔軟性 (スプレッドシート) が向上しました。

完全にカスタム化されたソフトウェアの価格と、何百万部も売れているソフトウェアの価格を比較しているのですか? 真剣に？

于 2010-04-23T06:17:55.267 に答える
4

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

  • 要件の分析
  • 要件に基づくソフトウェア設計
  • チームメイトとのインターフェースとアーキテクチャを調整するための会議。
  • 諸経費（経営陣とのステータスミーティング、病欠、休暇など）
  • ユニットテストの作成
  • アプリケーション全体のテスト計画を作成する
  • アプリケーションレベルのテスト

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

于 2010-06-08T13:09:46.943 に答える
2

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

この時点での私の見解は、ボトムアップの見積もりを補足するのに役立つトップダウンの「桁違いの」見積もりになるということです。複数の推定手法を適用して、到達している数値が「ホールドアップ」していることを検証できる場合は、常に良いことです。

さらに考えてみると、ファンクションポイントあたりのコスト/労力（つまり、機能要件）は、システムに必要な非機能要件によって異なります。セキュリティ、アクセシビリティ、パフォーマンス、ロギング（およびアラート）、保守性、移植性、規制コンプライアンスなどを考慮し始めると、FPあたりのコスト/労力が大幅に増加します。現在、これらは引用されたシングルユーザーサンプルアプリの考慮事項ではない可能性があります。しかし、このアプリケーションが企業または潜在的にその顧客、あるいは一般大衆の大部分にとって重要である場合、それらの非機能要件を考慮する必要性は確実に増加します。

于 2010-06-09T20:54:51.663 に答える
2

個人的に私はFPAが誤解を招くと感じました...最初は。

以前のプロジェクトの過去の FPA データがない限り、FPA は業界標準を使用して全体を過大評価することになる可能性があります。

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

優れたチーム リーダーは、見積もりを行う前に常にチームの能力を評価します。FPA についても同様で、過去のデータに基づいて業界標準の数値に達しており、このデータは企業ごと、チームごと、開発者ごとに異なります。

したがって、未調整のカウントで -35% という最良のシナリオを使用すると、調整後の FP カウントは ~64 になります。おおよそ3週間半程度のお見積もりとなります。経験上、この種のアプリケーションはそれよりもはるかに早く実行できると思いますが、徹底的なテスト、デバッグ、文書化、およびその他の紙の作業はそれをさらに拡大し、FP はそれを考慮に入れます。チームが 1 FP/hr を実行している可能性は非常に高いです。通常の基準では、コーディングとテストは FP 数の 25% を占めるため、この場合、99 FP の数値を取得しても、コーディングとテストの部分は 25 FP にまで減少し、状況を考えるとより理解が深まります。

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

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

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

私の2セントがあなたの役に立てば幸いです。

于 2010-06-12T12:58:53.423 に答える
1

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

于 2010-06-12T09:20:22.870 に答える
1

私の前の会社では、そのように計算していたでしょう-特に誰かがそれを払いたい場合;)

于 2010-04-22T21:00:24.707 に答える
1

私はいくつかのプロジェクトで FP を実践してきましたが、かなり正確な見積もりが得られることがわかりました。アプリケーションの種類によっては、過大評価したり、過小評価したりする場合があります。通常、科学的なアプリケーションの場合、FP は過小評価される可能性があります。FP は、コードを記述する時間だけでなく、プロジェクトの開発時間全体を提供します。もちろん、テスト環境のセットアップなどの開発作業はありません。これらは個別に見積もる必要があります。私は FP の大きな支持者ではありませんが、その使用法に感謝しています。正確な見積もりではない場合でも、適切に実践すれば (ファイルとレコード要素を特定する)、少なくとも要件の完全性を検証できます。

ある意味で、FP は中規模から大規模のプロジェクトに適しており、350 ～ 400 FP を超えるスケーリングを行うことができます。

于 2010-06-10T12:40:51.310 に答える
0

いくつかのソフトウェア メトリクスに関する私の経験から、Function Point は実際には軽量のメトリクスではありません。時間/FP が大きく変動する場合、何がポイントなのかというと、ユーザー ストーリー ポイントを使用する方がはるかに高速であり、間違いなくほとんど不確実である可能性があります。

ファンクション ポイント分析を行うポイントは、客観的かつ標準的なある種のルール/ガイドラインを用意することです。これにより、(一定のマージン内で) アプリケーションやプロジェクトで同じ量のファンクション ポイントが得られるようになります。ルールが一貫して正しく適用されている場合、どの専門家がそれをカウントしたか。あなたが発見したように、機能ポイントごとの生産性は、チームの経験、ツール、プログラミング言語、プラットフォームなどの多くの要因に大きく依存します。したがって、業界標準を知っておくと便利ですが、ほとんどの場合、まったく役に立ちません (私の謙虚な意見では) ）。反復カウントの主な価値は、チームの生産性履歴に基づいて独自の「ベンチマーク」を構築することです。これは、傾向を確認するのに役立ち、将来の変更に必要な時間を計画および予測するのにも役立ちます。もし、あんたが' 速度を求める場合は、詳細なカウントの代わりにグローバル カウントを適用してください。いくつかのサンプル カウント (試験の準備など) を実行すると、詳細なカウントとグローバル カウントの違いが (% で) スリープ オーバーするほど大きくないことに気付くでしょう。

于 2014-04-29T09:12:38.427 に答える
0

引用した例の値をこの便利なオンライン ファンクション ポイント計算機 ( http://developergeeks.com/functionpoint.aspx ) に差し込むと、調整された FP が計算され、他のさまざまな重み係数が考慮され、次の結果が得られます。この例のシステムは非常に単純であるため、生産性は 1 時間あたり 2 FP です。

  1. 調整済み FP: 42.9
  2. 推定人月: 0.54

1 か月の労働時間を 160 時間と仮定すると、約 86.4 時間、つまり 1 人の開発者の労働時間は約 2 週間になります。ステップ 2 で結論付けたように、5 週間ではありません。料金を支払う顧客向けのシステムを開発するには、自分の娯楽のために深夜にコードを叩くだけでなく、もう少し注意と労力が必要であることを考えると、それは不当な見積もりではないと思います全て。

つまり、誤解しないでほしいのですが、FP 分析を悪用するというのは、おそらくひどい考えです。しかし、開発者のバックグラウンドがあれば、FP を数えてさまざまな重み係数を直感的にチェックすることができます。詳細な設計仕様がない場合に、純粋な空想に基づいていない合理的な見積もりを取得するのは悪い方法ではありません。 、完全に文書化された要件、または作業に使用する詳細なタスク レベルのプロジェクト計画。しかし、それを機能させるには、ある程度の常識を働かせる必要があります。

于 2013-01-31T20:43:48.270 に答える