![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>VB6.0からVB（.NET）へのコンバージョン]] * 目次 [#p0fc548b] #contents *概要 [#v622034b] VB6→VB.NET 移行のFAQを纏めています。 *前提となる見積方法 [#leb2f61a] **標準（一括） [#ve2528a4] ストレート・コンバージョンの場合、~ 一般的な工程別・工数比率からテスト工数のみを積んだ -見積工数が新規開発の0.4 - 0.5倍になります。 -＃逆数を取ると生産性は2.0 - 2.5倍となります。~ この数字は、実績からも合っていると思います。 問題は、 -VB6 → VB.NETの変換率であり、この変換率が低くなると、~ 上記のテスト工数に加えポーティング作業工数が増加することです。 -変換率が低くなるにつれ、テスト工数・ポーティング作業工数が増加し、~ 新規開発に近い工数、場合によっては、それ以上の工数になる可能性があります。 VB6→VB.NET移行の総工数に、新規時の工数の~ 0.4 - 0.5倍 ～ 1.0倍 ～ 1.x倍の幅があることです。 そのような問題を事前に検知するための変換率の調査ですが、~ ポーティング作業工数については正確なことが言えないので、~ 正確な見積もりを出すためには、幾つかサンプリングして移行性評価を実施する必要があります。~ -まず、変換率調査の段階で、~ お客様の予算に合うかどうか？があり、 -プロジェクトを進めることができる場合は、~ さらに移行性評価を実施し、見積もり精度を上げる必要があります。 **準委任 [#a997dbc1] 準委任作業とすることで、顧客予算内に収まるサービスとすることは可能です。 >一般的な工程別・工数比率からテスト工数のみを積んだ見積工数が新規開発の0.4 - 0.5倍 という慣例に従うのは、通常、品質保証（稼働までの責任を負う）のためです。~ ＃標準契約書の（検査）・（瑕疵担保責任）・（責任の範囲）の項を参照。~ ポーティング作業（作業支援）のサービスと割り切り、検収頂けるなら~ 上記の工数を圧縮し、顧客予算内に収まるサービスを提供することは可能です。~ ＃注意：変換率によりポーティング工数は変わる。検収条件等は別途検討が必要になる。 *Q&A [#n4771d71] **再構築したほうが良い等の変換率の指標はあるのでしょうか？ [#a34decb2] ***Q [#wa8df9bf] 一般的にはどのくらいの変換率だと再構築したほうが良い等の指標はあるのでしょうか？ ***A [#e8fcd85a] ポーティング工数次第だと思います。ただ、変換率に比例しないケースが多いので、 低めの変換率でも簡単な類似を修正していくことで対応出来るようなケースもある。 実際には、ポーティング工数がどの程度になるかの~ 移行性評価作業をしてもらって見積もって貰うのが良いと思います。 私が知るかぎりの移行完了例で変換率 75%-70% 程度の例があります。 上記、「簡単な類似を修正」部分を単純変換できるケースは~ アップグレードウィザードを書けた後のコードに対して~ 自作ツールで変換して変換率を上げることもあるようです。 65％を下回ると少々難しくなってくるように思います。 **ActiveXは.NETに変換できないのですか？ [#gf177e83] ***Q [#l77ca7df] また、ActiveXを多く使用しているため変換率が低くなるという話を聞きました。 ActiveXは.NETに変換できないのですか？~ 相互運用機能を提供するラッパークラスがあれば利用可能で、~ このラッパークラスは自動生成されるという記事を見かけたのですが...。 -VB 6.0 ユーザーのための VB .NET 移行ガイド - ActiveX コントロール~ http://msdn.microsoft.com/ja-jp/library/dd297724.aspx ***A [#p6d8d787] ActiveXで変換率が落ちるというのは、 >「移行先に同じAPIセットを持つサードパーティ製のUIコンポーネントが存在しない」 と考えられるためです。 持っていく先の環境で、 >「ActiveX Control（OCX）がサポートされるか？」 なども移行パスを検討する上で必要かと思います。 古い製品を新しいOSにインストールできないケース等もあるようなので。~ 自作のActiveXや、サードパーティ製のUIコンポーネントを~ 無理やり持っていくなら、以下の仕組みである程度変換されるようです。 -COM --Runtime Callable Wrapper （COM APIのラッパー生成）~ COMを参照設定すれば生成される。例えば、ADO (Interop.ADODB） -ActiveX --UserControlモジュールにActiveX Control（OCX）をD&Dすれば生成される。~ --ActiveX コントロール インポータ（ActiveX Control（OCX）のラッパー生成）~ ---http://d.hatena.ne.jp/punidama/20080224~ ---http://msdn.microsoft.com/ja-jp/library/system.windows.forms.axhost.aspx **見積もりの仕方 [#l763dfdf] ***Q [#k89d3bd7] 再構築を行うかどうかの決め手は、最終的には工数だと思っています。 (3)、(4)で対応した場合の変換率が悪いと、~ プログラム製造、単体テストには再構築に近い工数がかかると思いますが、~ 大きな違いは詳細設計をやり直さなければならないという点でしょうか。 ***A [#j9265b54] 詳細設計（イベント仕様書相当）をやり直すパターンは、~ リエンジと言うよりは新規開発の一部作業を欠いたものに近いかもしれません。 *参考 [#rac25729] **[[VB6の保守]] [#i79cf9ef] ---- Tags: [[:移行]], [[:.NET開発]], [[:Visual Basic]]
