言語Aから言語Bへのコードの移植に関連するコストを見積もる最良の方法は？

プロジェクトを言語Aから言語Bに移植するコストを見積もることをクライアントに考えさせます。これを行うための提案の要求をまとめる最良の方法は何ですか？

目的が単に1つのアプリケーションを新しい言語に正確に再現することである場合、そのことについてクライアントに説明することをお勧めします。言語Aで実装されたために生じたこれらすべての癖はエンドユーザーに依存している可能性があり、突然言語Bで再作成する必要があるため、移植は実行できる最も危険なことの1つです。嫌なもの。ポーティングは完全に埋没しており、回復を望めないことは言うまでもありません。

プロジェクトを他のプロジェクトと同様に扱い、要件を収集して、オリジナルが存在しないかのように見積もることをお勧めします。エンドユーザーは、製品を使用して以来、製品に新しい視点を持っていることに気付くでしょう。あなたがそれを書き直すつもりなら、それもより良くするかもしれません。

すでにPerlコードベースがある場合は、コード行数（LOC）がわかっています。Perlと言語Bの表現力の比較を見つけることができるかどうかを確認してください。以下に例を示します。

言語BはJavaだとしましょう。その場合、ポートの推定LOCは元のLOCの約4倍になります（表現力6対1.5）。

次に、Construx EstimateソフトウェアのようなものをLOCモードで使用して、所要時間（および所要人数）を推定します。

これにより、概算のコストと時間の見積もり、およびオーバーシュートする可能性がどの程度あるかがわかります。

言語Bにすでに精通していて、その中でいくつかの測定プロジェクトを実行したことがある場合は、Construx Estimateソフトウェアを使用して、チームの調整を行うことができます。

Joelsの最も人気のある記事、「すべきでないこと」はそれを最もよく述べています。

彼らはコードを一から書き直すことにしました。

書き直してしまった場合は、正しく書き直してください。移植するだけではありません。

• プログラムのどの部分が使用されなくなりましたか？これらの部分はスキップしてください。
• プログラムのどの部分が最も重要ですか？これらを最初に移植します。
• 新しいプログラム、GUIを更新し、使いやすく、より「セクシー」にする時間。
• 古いコードに機能を追加するだけでは、莫大な時間を費やした方がいいのではないでしょうか。

かなりの時間がかかると思います。あなたはそれがそれの価値があることを確かめるべきです。コードの一部を取り、移植してみてください。かかった時間に、移植したコードの行数とコードの合計行数の比率を掛けます。それはあなたに大まかな数字を与えます、本当の数はおそらくいくつかの複数の人によって高くなります。

事実上、最初からアプリを再度作成しているが、要件が別の言語で指定されている場合、それは簡単ではありません。

私は何よりもまず、これが良い選択であるかどうかを本当に考慮すべきです。言語Aの代わりに言語Bを使用する利点は何ですか？

IBMが調査したところ、プログラマーは平均して1時間に100LOCを書き込むとのことです。それよりもまだ開発が進んでいますが、古いアーキテクチャはまだ計画されています。それ以外の点ではプログラムはまだかなり計画されているので、50％がコードを書くとしましょう。（構造化されたプログラムがあり、オブジェクト指向のプログラムが必要な場合や、より大きなタスクになる可能性があります）。

しかし、100LOC /時と書く場合、システム内の現在のLOCの量を割り、プログラマーの平均売上高で乗算し、それに2を掛けます。これは、大まかな見積もりを与える可能性があります。取得した数値を真剣に受け止めないでください。（さらに、真剣に受け止めないでください）。あなたが何をしたいかは、次のような単純に測定する多くの事柄への道に依存します：

• 新しい言語でのプログラマーの能力
• 古いプロジェクトはどれほど文書化されているか
• どの言語から変換され、どの言語に変換されますか？

それはあなたが利用できる時間に依存します。いくつかのオプション：

• まったく時間はありません、それを成し遂げるだけです -ナプキンの裏を取り、それに行きます。それは、そもそもそれを作成するのに要した時間よりも少なく、単に別の構文でそれを再入力するだけではないようなものです。
• 1〜3日 -どのアーキテクチャの再設計が必要になるかを把握し、見積もりを試してください。どれだけのロジックを移植する必要があるかを考え、何らかの比率を考えます。プロセスのセキュリティを強化したことを期待できる、セキュリティ関連のタスクのための時間を追加します。作業の複雑さとアーキテクチャの単純さに基づいて、統合テストの時間を追加します。
• 1か月間 -いくつか試してください-テストアーキテクチャをステージングし、何かを移植してみてください。移植したコードの割合を把握し、さらに見積もります。新しい言語ではまったく不可能だったいくつかのことも理解できる可能性が高く、移行を行うために必要な実際の作業のより良い基礎を提供します。

理想的な世界では、クライアントに、1か月の作業をカバーするための調査タスクに費用をかけて、自分がしたいことだけをプロトタイプ化できるようにすることを提案します。これにより、コストが高すぎる場合に停止して続行しないという選択肢が与えられます。そして、あなたはまだあなたがやった仕事の報酬を受け取ります。

ソフトウェアタスクの適切な見積もりを取得する方法は1つだけです。タスクの小さな、しかしテスト可能な部分を完全に実行するために、利用可能なスタッフを割り当てて、どのくらい時間がかかるかを確認してください。残りの作業をできるだけ多くのユースケースに分割し、同じスタッフが、すでに行われた作業と比較して各反復を推定するようにします。時間を見積もるように依頼するのではなく、最初の反復との比較を説明するように依頼してください。これにより、プロジェクトの残りの部分について可能な限りの最適な見積もりが得られます。