Open棟梁Project - マイクロソフト系技術情報 Wiki
VB6→VB.NET 移行のFAQを纏めています。
ストレート・コンバージョンの場合、
一般的な工程別・工数比率からテスト工数のみを積んだ
この数字は、実績からも合っていると思います。
問題は、
VB6→VB.NET移行の総工数に、新規時の工数の
0.4 - 0.5倍 ~ 1.0倍 ~ 1.x倍の幅があることです。
そのような問題を事前に検知するための変換率の調査ですが、
ポーティング作業工数については正確なことが言えないので、
正確な見積もりを出すためには、幾つかサンプリングして移行性評価を実施する必要があります。
準委任作業とすることで、顧客予算内に収まるサービスとすることは可能です。
一般的な工程別・工数比率からテスト工数のみを積んだ見積工数が新規開発の0.4 - 0.5倍
という慣例に従うのは、通常、品質保証(稼働までの責任を負う)のためです。
#標準契約書の(検査)・(瑕疵担保責任)・(責任の範囲)の項を参照。
ポーティング作業(作業支援)のサービスと割り切り、検収頂けるなら
上記の工数を圧縮し、顧客予算内に収まるサービスを提供することは可能です。
#注意:変換率によりポーティング工数は変わる。検収条件等は別途検討が必要になる。
一般的にはどのくらいの変換率だと再構築したほうが良い等の指標はあるのでしょうか?
ポーティング工数次第だと思います。ただ、変換率に比例しないケースが多いので、
低めの変換率でも簡単な類似を修正していくことで対応出来るようなケースもある。
実際には、ポーティング工数がどの程度になるかの
移行性評価作業をしてもらって見積もって貰うのが良いと思います。
私が知るかぎりの移行完了例で変換率 75%-70% 程度の例があります。
上記、「簡単な類似を修正」部分を単純変換できるケースは
アップグレードウィザードを書けた後のコードに対して
自作ツールで変換して変換率を上げることもあるようです。
65%を下回ると少々難しくなってくるように思います。
また、ActiveXを多く使用しているため変換率が低くなるという話を聞きました。
ActiveXは.NETに変換できないのですか?
相互運用機能を提供するラッパークラスがあれば利用可能で、
このラッパークラスは自動生成されるという記事を見かけたのですが...。
ActiveXで変換率が落ちるというのは、
「移行先に同じAPIセットを持つサードパーティ製のUIコンポーネントが存在しない」
と考えられるためです。
持っていく先の環境で、
「ActiveX Control(OCX)がサポートされるか?」
なども移行パスを検討する上で必要かと思います。
古い製品を新しいOSにインストールできないケース等もあるようなので。
自作のActiveXや、サードパーティ製のUIコンポーネントを
無理やり持っていくなら、以下の仕組みである程度変換されるようです。
再構築を行うかどうかの決め手は、最終的には工数だと思っています。
(3)、(4)で対応した場合の変換率が悪いと、
プログラム製造、単体テストには再構築に近い工数がかかると思いますが、
大きな違いは詳細設計をやり直さなければならないという点でしょうか。
詳細設計(イベント仕様書相当)をやり直すパターンは、
リエンジと言うよりは新規開発の一部作業を欠いたものに近いかもしれません。