ソフトウェアプロジェクトのコストの定量化
免責事項：私はこの質問をどこに置くか正確に知りませんでした。この質問がプログラマ@ StackExchangeに適していないと思われる場合は、遠慮なく移行してください。
背景：拡大 私の最後の質問 、オープンなソフトウェアシステムへの入札のリクエストがあり、私は採用することにしましたそれで。私はソフトウェア開発者であり、技術者でもあります。この入札プロセスでは、入札価格を設定する必要があります。機能要件と非機能要件のみからなるドキュメントが提供されました。
私はプロジェクトマネージャーの上限を設けて、すべての側面を考える必要があります。プロジェクトの実施費用、必要なリソースなど.
私の質問は次のとおりです。私が従うことができるプロジェクトフレームワークは、プロジェクトサイクルをステップおよび対応するコストの側面に分割しますか、またはプロジェクトのコストを計算/概算するにはどうすればよいですか？
私はあなたの質問に答えるよりもあなたの問題を解決するのを助けるように努めます。
ソフトウェアのコストを事前に見積もるためのシステムは多数あります。なぜ1つだけではないのですか？実際に機能するものがないからです。コメントにはCOCOMO-IIが含まれています。これは、どちらの方法でも7回の係数内で正確であると主張しています。 （それは記憶からです、私は参照を見つけることができないので、それを塩の粒でとってください）。
乗算/除算係数7の見積もりをクライアントに提供することはできません。
それで、人々は本当に何をしますか？
- 保守的に入札し、通常は契約を失います。
- 積極的に入札し、ほとんどの場合お金を失います。
- 固定価格の入札を行わないようにクライアントに説明します。
- 積極的に入札し、後でお金を補います。
項目4に説明があります。最も一般的な戦術は次のとおりです。
- 要件には何もしないでください。たとえば、コードの品質が要件になることはほとんどありません。多くの場合、トレーニングは必須ではありません。完全に完成させるには、仕様は実用的なプログラムなので、仕様にない重要なものはほとんど常に見つけることができます。
- 要件に当てはまらないものを実行するように求められた場合、通常は高額で1時間ごとに請求されます。
- 通常、バグは修正する必要があります。したがって、すべてのバグは「設計上」に分類されます。
これが、多くの固定価格プロジェクトが当事者間の終わらない戦いである理由です。それがどれほどひどくなるかは、請負業者がどれだけのお金を失っているか、請負業者がどれだけ貪欲であるか、顧客がどれほど貪欲であるか、そしてプロジェクトの見積もりがどれだけ遅れているかに基づいている傾向があります。
プロセスがうまくいくと（そのように聞こえなくても起こる可能性があります）、実装するのが難しいスペック内のアイテムは、忘れられていたアイテムの最終価格（初期固定価格スペックプラス誰も考えなかったすべてのものは公平で、誰もが幸せです。
プロセスがうまくいかない場合、実際に実装されるのは、元の仕様に基づくものと、金銭をめぐる政治的戦いの結果に基づいており、誰かが（おそらく誰もが）損失します。
プロジェクトの管理において、価格、時間、または機能にこだわらないが、品質を制御できない場合、通常何が問題になると思いますか？固定価格の入札プロセスでは、価格や機能に曲がる可能性が最初から排除されており、通常は時間どおりに曲がることに強く反対しています。あなたは公平で良い仕事をしたいと思っているように聞こえますが、それを実行するのは難しいモデルであることを理解してください。
要件を数時間に、次に数時間を$に変換するように求められます。これを行うための魔法の杖はありません。競合他社はすべて同じ計算をしようとします。経験が多いほど、見積もりは良くなります。
各要件は、設計、コーディング、テストに時間がかかります。さらに、プロジェクトの他のすべての部分の時間。
要件の行をコードの行に変換し、その後数時間に変換する簡単な方法はありません。
リスクは、お客様が数週間にわたって小さな変更を承認したり、30分間の会議でプロジェクト全体が破棄されたりする可能性があることです（言語Xは未来の波であり、ファイル名を変更するだけだと聞きました...） 。契約の構造に応じて、すべてのお金のリスクはあなたにあります。入札不足であなたは勝ちますが、結局は壊れます。入札しすぎると、契約を結ぶことができません。
見積もりの最初のルールは、固定価格のプロジェクトで常にお金を失うことです。
見積もりの2番目のルールは、顧客が許容できるエラーの範囲内で包括的な見積もりを提供することはできません。これは、顧客が要件を誤って解釈し、コストがかかると常に主張するためです。
ソフトウェアには、柔軟な要件、顧客からの流動的な期待、予測できないリスクがあります。
ソフトウェアを構築するためにアジャイル手法が非常に一般的になるのはこのためです。
彼らはあなたが変更とリスクを計画し、それに予算を組むことを可能にします。
彼らはあなたの顧客が優先順位と方向性を担当することを可能にします。
これにより、顧客は何が何にコストをかけているのかを、善と悪のために透過的に見ることができます。最初の数回のイテレーションを予定通りに納品すると、顧客は信頼と親密さを急速に獲得し、それをチームの努力であると感じ、お金を請求するのではありません。
顧客が見ることを期待でき、チームが対応できる短期的な期待を設定することで、あなたを保護します。
いくつかの方法論を研究すると、他にも多くの利点があります。
要件を取り、それらを可能な限り最小のタスクに分解します。各タスクを実行する時間を見積もります。タスクが小さいほど、正確な見積もりになります。次に、バスルームの休憩、昼休み、病気の時間（あなた、妻、子供、犬など）や、仕事を妨げるその他の要因を考慮に入れます。
タスクリストを作業明細として使用します。リストにないものは追加料金がかかります。
私は個人的に保険として最初の見積もりに30-50％を追加します。