私は現在インターンシップ中の学生です。既存のWindows専用C#ソフトウェアパッケージをMonoに移行する可能性を判断するように依頼されました。
移植またはマネージコードへの置き換えが必要なネイティブライブラリを特定するための分析をすでに実施し、Linux/OSXで同等のものを見つける必要があるWindowsのみのAPI呼び出しを特定しました。このことから、各アセンブリの何パーセントを書き直す必要があるかについて、いくつかの(非常に大まかな)見積もりを作成しました。
ここで、これらの変更を実装するための時間の見積もりを作成したいと思います。この種のタスクには COCOMO II が好きなようです。
ただし、SLOC(コードのソース行)入力の番号を決定するのに問題があります。 USCの nified Code Count ツールを使用して、プロジェクト全体および特定の対象アセンブリの論理コード行(LLOC)を決定しました。
ある戦略では、165k LLOCプロジェクトの約10%を書き直す必要があり、残りの約5%が大幅に変更されると予測しています。これらの数値を使用すると、COCOMOIIは30人月のような労力を私に与えてくれます。これは私には高いようです-実際ですか?確かに知っている経験はないと思います。
LLOC入力にひねり係数を適用する必要があるかどうか疑問に思っています-LOCを使用するときに、一部の言語でこのようなことを行う人がいることを知っています(例:Python LOCを6の係数で除算) 。C#でこれを行う必要がありますか?もしそうなら、どのような要因ですか?
最後に、COCOMO-IIを使用することは、これを行うための合理的な方法でさえありますか?私が欲しいのは、桁違いの近似です。フェルミスケールの不正確さはここでは問題ありません。より良い方法はありますか?
COCOMOIIが適切なツールのようです。使用しているツールはわかりませんが、 COCOMO Suite of Construction Cost Models および Expert COCOMO II(現在/一時的?オフライン) で幸運を祈りました。 = USC CSSEWebサイトで提示されるツール。設定をCOCOMOに変更する必要がある場合があります。
このツールは、前例、必要な信頼性、プロセスの成熟度、経験、機能、複雑さなど、言及しなかった入力を受け取ります。また、作業のフェーズの内訳を確認することもできます。これは翻訳作業であるため、新しい機能を追加する場合やリバースエンジニアリング仕様でない限り、このプロジェクトでの開始と精緻化の作業のほとんどはすでに完了しています。
要因を確認し、すでに行っている活動の労力を取り除けば、桁違いになっていると思います。