6

20 ~ 30 個のモジュールを含む非常に巨大なプロジェクトがありますが、ほとんど完了しています。メンテナンス段階にあります (主にバグ修正で、新機能はほとんどありません)。私は、製品を維持するために必要となる多くの開発者を見つけようとしています。

この数を測定する良い方法はありますか?

このプロジェクトは主に WinForm ベースの C# アプリケーション (.net 1.1 と 2.0 の混合) で、vb6 アプリが散りばめられています。

4

6 に答える 6

19

これは、コードの品質、変更の頻度、およびテストのレベルに完全に依存します。

たとえば、数千行のコードを含むシステムで、変更の頻度は非常に低く、ユニット/統合テストの完全なライブラリは、頻繁に変更され、テストのない小さなシステムよりも開発者が少なくて済みます。

もう 1 つの重要な要素は、関係する開発者の経験です。これは、一般的なことだけでなく、具体的には特定のプロジェクトについての理解です。

結局のところ、これは推定するのが非常に難しい統計であり、現在プロジェクトに参加している開発者のワークロードを見て、必要に応じてゆっくりと人々をプロジェクトに出入りさせたほうがよいでしょう。

于 2009-02-18T18:28:48.160 に答える
2

プロジェクトの規模よりも、修正が必要なバグの量と難易度に大きく依存します。はじめに:

  • 毎週、修正が必要なバグはいくつありますか?
  • これらのバグはどれほど複雑ですか?
  • コードベースの品質はどの程度ですか? バグ修正の「難しさ」に大きな違いをもたらします。
  • プログラマーは言語/フレームワークでどのくらいの経験を持っていますか?
  • プログラマーは、この特定のアプリケーションでどのくらいの経験を持っていますか?
于 2009-02-18T18:30:26.110 に答える
1

プロジェクトの存続期間にわたって問題追跡システムを使用した場合は、1か月あたりの平均問題数と修正までの平均時間を示すレポートを実行できます。これにより、過去のメンテナンス要件が得られます。

次に、これを将来に外挿することができます。

于 2009-02-18T18:48:56.317 に答える
1

それは、採用する開発者の質、コードの習熟度、コードの質、初心者に使用する言語など、多くの変数に依存すると思います。うまくいく方程式はないと思います。

于 2009-02-18T18:28:09.783 に答える
1

これを選択する良い方法はないと思います。それはいくつかの要因に依存します:

  • コードベースの状態
  • それに取り組むエンジニアの経験・才能レベル
  • 予想されるバグ修正/機能のタイムライン

小さなチームから始めて、作業がどのように進行するかを確認し、必要に応じて後でメンバーを追加することもできます。

于 2009-02-18T18:29:55.783 に答える