2009年のサービス開始以来、60社以上のお客様に対して、ツールの導入及び、サービスを行い実績を積んでまいりました。
以下では、VBMPを御利用頂きましたユーザー様の活用事例および、使用した際のインタビューをご紹介いたします。
▼川崎重工業株式会社 様(ライセンス御購入、自社マイグレーション)▼
▼株式会社NTTデータ四国 様(弊社マイグレーションサービス御利用 1)▼
▼株式会社NTTデータ四国 様(弊社マイグレーションサービス御利用 2)▼
▼株式会社トスコ 様(ライセンス御購入、自社マイグレーション)▼
▼データスタジアム株式会社 様(ライセンス御購入、自社マイグレーション)▼
▼データスタジアム株式会社 様(弊社マイグレーションサービス御利用)▼
▼株式会社ISTソフトウェア 様・明治大学様向け(弊社マイグレーションサービス御利用)▼
▼日本ユニシス株式会社 様・金融系大規模システム(弊社マイグレーションサービス御利用)▼
企業名 | 川崎重工業株式会社 |
---|---|
移行期間 | 6ヶ月 |
システム内容 | 製造ライン向けシステムや技術計算システムなど様々 |
システム構成 | VB6資産:約69万行、画面数763、EXE数141 |
Q.VB MIGRATION PARTNERをどこで知りましたか?
A.インターネット検索
Q.VB MIGRATION PARTNERの利用を決定した理由を教えてください。
A.試用版による検証の結果、変換精度が非常に高く、変換後のコードの可読性も高いことを確認できたため、採用を決めました。サポートライブラリのソースコードを開示していただける点も決め手になりました。
Q.VBMPの変換精度についてはいかがでしたか?
A.非常に高いと感じました。フォームのLoad、Showによるインスタンス生成のタイミングが変わっていたことによる修正、一部の関数で戻り値が変わった(Fileの排他制御)ことによる対応などくらいで、時間がかかった修正はありませんでした。
Q.VBMPには変換ルール(Pragma)を指定することができますが、利用したPragmaがあれば教えてください。
A.AddLibraryPath、InsertStatementを利用しました。配列のインデックスは、Pragmaを使用せずに手修正することを選択しました。
Q.VB6版のActiveXコントロールについては、どのように移行しましたか?
A.AxWrapperGenコマンドを利用して変換しました。
Q.システムの機能追加等で課題はありましたか?
A.機能追加はまだ行っていません。
Q.弊社サポート対応についてはいかがでしたか?
A.常に迅速に対応していただきありがとうございました。VBMPの問い合わせ対応や、Microsoft関連の情報も提供して頂き、変換作業が順調に進める事が出来ました。
Q.弊社HP上で確認できるマニュアル、ナレッジベースは問題の解決に役立ちましたか?
A.役立ちました。修正項目が少なかったですが、ナレッジベースから問題解決できました。
Q.マイグレーションツールの費用感はいかがですか?
A.マイグレーション工数を大きく削減できたので、費用対効果は十分だと感じています。
Q.VBMPを使用した上での良かった点、悪かった点があれば教えてください。
A.良かった点:マイグレーションの工数を大幅に削減できた点。
悪かった点:一部のオブジェクトは変換後もOCXを使用しており、完全に.NET出来ていない点。
お忙しいところ、ご回答有難うございました。
2009年12月、株式会社NTTデータ四国様から、およそ十数年間保守・改修を重ねてきたVB6の資産を.NETに Migrationしたいとのご商談を頂き、4ヶ月の期間をかけて移行作業を行いました。
以下、今回の対象システムについてご紹介させて頂きます。
システム | 酒類卸様向けの販売管理と財務会計 |
---|---|
システム構成 | EXE数365、画面数428、変換対象コード行数55万行 |
特徴 | 外部I/F多数、Key入力を主体とした画面操作、各種帳票 KnVariantBox、KnGrid、という3rdPartyOCXを多数使用 |
運用環境 | Windows2000、Windows2000Server、SQLServer2000 |
この資産を次のような仕様で移行したい、というご要望を頂きました。
運用環境 | Windows7Professional、Windows2008Server、SQLServer2008 |
---|---|
移行期間 | 4ヶ月 |
要求事項 | .NET移行後もVB6と同等レベルの動作を維持したい |
このご要望を実現するため、弊社では次のような移行計画を立てました。
①お客様資産の移行優先順位グループに従い、納品予定日を設定し、開発チームのリソース配分
②『VB Migration Partner』を利用し、.NETSourceに移管→コンパイルエラーの除去 .NET版がないOCXはWrapperDllで.NETに組み込み、または別製品の.NETコンポーネントに適応 .NET版があるOCXはVersionUp 画面のデザイン、レイアウトの微調整
③.NET移行完了EXEにて動作確認(VB6と同様の動作、機能が継承されているか) RunTimeErrorが確認された場合、原因追求とコード修正
④本番環境にて最終動作確認(SEの目線に立って)
⑤お客様へ納品→受入検証対応
この②と③の工程に一番時間が割かれるのですが、『VB Migration Partner』から変換されるコードの可読性が高いため、問題が発生した場合、VB6との動作を比較する際においても、変換された.NETコードが、VB6コードと1対1で照合出来るため、原因究明の時間短縮が可能です。
また、CodeArchitects社のライブラリのコントロールはVB6と同様の動作を実現するために作られており、.NETで失われたコントロールのプロパティやメソッドもライブラリが補完しているため、速やかに動作確認ステップに移行することが可能です。
Code Architects Library (Objectブラウザより)
また、複数人で同時に変換作業を行いながら、日々発生するコンパイルエラーを取り除くための変換ルール(「このコードはこのように変換しなさい」というルール:Pragma)を随時追加し、別のEXEに着手する際に適応していくことにより、自動的に排除され、効率良く作業を進めることが出来ました。
今回のMigration作業において、多くの技術課題がありました。
それらを解決した主な事例を、ご紹介致します。
①.NET版がないOCXを別製品に移行 KnGridに関しても、当初はWrapperを作成することで.NETへの移行を試みました。
検証の過程で、いくつかの問題 (DataBindingが出来ない等)が発生し、その問題を自作のDLLを使用する等の方法を用いることで、何とかXP環境(開発環境)での動作までたどり着くことが出来ました。
しかし、Windows7での検証で、メモリーアクセス違反が発生してしまい、Wrapperでの移行は出来ないという判定に至り、 最終的にまったく異なる別会社の.NET製品に置き換えることになりました。
新しいコントロールに置き換えるといっても、簡単に出来るものではありません。
旧コントロールと比較すると、機能、仕様、イベント等に数多くの相違点が存在しますし、VB6と同等レベルの表現と機能を実現するのは容易ではありません。
更に、およそ100個のデザインが異なるGridコントロールの置き換えに際し、それらに伴うコードの修正、コードの可読性を維持する等、配慮すべき点は多く存在しました。
弊社では、新しいコントロールを直接使用するのではなく、新しいコントロールを継承したUserControlを作成し、それをVB6のOCXに合わせてカスタマイズすることで、機能の再現性を向上させ、かつ、旧コントロールと新しいコントロールの 属性を置換するツールを作成、運用することによって、前述の課題を効率的にクリアすることが出来ました。
UserControlのクラス図
結果として、旧OCXと大差ない機能を実現することが出来ました。
②Focusの仕様の違いによる動作の補完 .NETには、VB6のGotFocusとLostFocusイベントの動作と完全に一致するイベントが存在しません(EnterとLeaveイベントに置き換えるのがMicrosoft社の推奨方法であるため、それに従って移行しましたが、実際、完全一致とはなりませんでした)。
今回の案件はキーボード操作がメインのアプリケーションであったため、Keyイベントが多く、更にその中でFocusの設定が多く、次のような問題が発生しました。
これらの問題を解決するために、VB6のロジック分析と、.NETのイベント実行状況の把握を綿密に行い、それらを踏まえて、イベントの実行をFlagで管理することで、VB6と同様な動作を実装することが出来ました。
③Unicode変換対応.NETのStringはUnicodeのみ対応しているため、.NETで文字コード変換を実装する場合、Byte配列に置き換えて文字コード変換を行う処理をコーディングする必要があります。
『VB Migration Partner』ライブラリでは、これらに対応する関数EncodeStr6、EncodeLeftB6、EncodeRightB6、EncodeMidB6がありますので、実装する手間がなくなりました。
更に、VB6のコードでStrConvとLeftB、RightB、MidB関数を併用している場合、.NETでの実装は、より手間のかかるコーディングが必要となり、コードの可読性も低下してしまいます。
こちらに関しても『VB Migration Partner』ライブラリの対応関数を組み合わせることで、スムーズにVB6と同様の結果を得ることが出来ました。
自作ではないシステムをお預かりして、移行、動作確認をするという難しさがあります。
システム全体の共通仕様は何か? アプリケーション自体がどのようなオペレーションを主体として作られているのか?
この画面にはどのような機能が存在するのか?
最初は確認範囲や視点が狭く、多くの問題に直面しましたが、徐々に理解し、多様な動作確認を行うことによって、移行の精度を高めることが出来ました。
365個のEXEを優先順グループ単位でリリースしていくというスケジュールの中、1週間でおよそ90個のEXEをリリース出来たことも、『VB Migration Partner』を利用した変換効率の高さにあると思います。
主に受託開発を手がけている弊社では、他社様が作ったアプリケーションを拝見する機会はそう多くあるわけではありません。
このようなソリューションサービスを手がけることは、アプリケーション開発におけるスキルや技術知識の向上に確実に結び付くものと思っております。
2010年5月末をもってNTTデータ四国様の受入検証が完了し、本プロジェクトは完了に至りましたが、東京⇔四国という距離を乗り越え、また、NTTデータ四国様の多大なるご協力とお互いに綿密な情報の共有化を心がけてきたことが、このプロジェクトを無事に完了出来た大きな理由だと思っております。
『VB Migration Partner』の変換効率はとても高く、ほとんどコンパイルエラー無しで変換することが出来ました。
しかし、動作確認を行ってみると、VB6との微妙な違いは当初の予想を上回り、それらの主因となったKnVariantBoxとKnGridの対応解析は、私たちにとって良い経験になりました。
変換対象のシステムはKeyイベント処理が多く実装されており、更に.NETFormがKnVariantBoxのKeyイベントをキャッチ出来ないため、実行すべき処理が実行されないという問題が発生していました。
この問題については、KnVariantBoxのWrapperソリューションの各Keyイベントに対して、コントロールが格納されているFormを取得し、Formのイベントを発生させるように修正することによって、解決出来ました。
そして、KnGridはWrapperでの対応に限界があったため、別製品のMultiRowに移行することになりました。
これは、初めての試みであり、また、一つの挑戦でもありました。
作業はデザイン情報の移行と、コードの移行の二つに分けられ、効率的で、かつ、漏れのない作業を考案し、運用しました。
まずは、デザイン情報の移行です。
単純な手作業ではなく、両コントロールの各プロパティをマッピングした上で、移行ツールを作成し、それを使用することでスムーズにデザイン情報を移行することが出来ました。
次に、コードの移行です。本体のソース上に直接個別にコードを加えた場合、作業量が膨大になり、対応漏れが発生する可能性が高く予想されます。
そのような手作業をしない解決策を編み出すことが課題でした。
限られた時間の中で知恵を出し合い、MultiRowを継承するUserControlを作成し、KnGridに合わせてプロパティ、関数などを定義することにより、本体のソースを最低限の修正のみで完了し、効率的にコードの移行を実現しました。
これらの異なる変換アプローチを成功させたことは、今後の案件にも十分活用出来ると思います。
最大のポイントはKnGrid→MultiRowでした。
既存のVB6資産とは異なる別会社のコントロールを導入するため、動作を完全一致させることは非常に難しく、落としどころをどの辺りに設定するかが、テストする上でも重要な要素だったからです。
結果的には、選定したコントロールの性能と、変換チームの努力、そしてNTTデータ四国様のご協力により、ほとんどの部分を現行と同等レベルの動作を維持することが出来ましたが、そこに至るまでの作業は今までのMigration作業には無い、とても貴重な経験となりました。
このような経験は、将来の案件にも大いに役立つものと思います。
この度は、インフォーテック社様の多大なご協力とご尽力により、計画どおりに開発作業を終えることが出来、心より感謝致しております。
Migrationサービスとは言え、総ステップ数55万行ものシステムを、四ヶ月間という短いスケジュールで開発をおこなうこと、ましてインフォーテック様とは始めての取引でもあることから、無事完成するかどうかの不安がありました。
しかしながら、工期と費用面を考慮すると、Migrationサービスしかないだろうとの判断で、開発をスタートさせました。
納品物を一括で受け入れることは、弊社としては過大なリスクとなることから、優先度を付けての段階リリースをお願いし、開発が完了したプログラムから受入試験を開始させました。
受入開始当初は、KnVariantBoxやKnGridという移行経験のないOCXへの 変換対応や、アプリケーション全体の仕様理解伝達など不安が当初ありました。
インフォーテック社様から、前記にありますライブラリへの改修やMultiRowへの方針変更の提案を受け、対応頂くことで問題は徐々に解決され、VB資産とほとんど同じ動きをするようになりました。
今回のプロジェクトが期間内で問題なく完了することが出来たことは、プログラムロジックにはまったく問題が無かった点にあります。
不具合となったのは、見た目上の画面の動きであるとか、カーソルの動きであり、プログラムロジックそのものは、VB資産のものがそのまま保障されたことが大きな要因と思います。
Migrationサービスとインフォーテック社様のレベルの高さのお蔭様により、四ヶ月間という短い開発期間の中でも、高品質でカスタマイズし易いシステム開発をおこなうことが出来ました。
インフォーテック社様の今後益々のご繁栄をお祈り申し上げますとともに、またの機会にご一緒に仕事が出来ることを 祈念致しております。
ありがとうございました。
この度、2009年度にMigrationサービスを御利用頂いた株式会社NTTデータ四国様に、2件目となるMigrationサービスを御利用頂きました。
以下にサービスの概要をご紹介致します。
システム | 販売管理 |
---|---|
システム構成 | EXE数1、画面数37、変換対象コード行数4万行 |
旧運用環境 | WindowsServe2003、WindowsXP、SQLServer2005 |
特徴 | 販売管理情報のExcel保存、帳票印刷がメインのシステム 3rdPartyOCXはSPREAD(7.0J)、VB-Report Ver3.0 (ActiveX版)を使用 |
備考 | SPREADは.NET版に移行。 VB-Reportは現行バージョンをラッパー使用。 |
運用環境 | MicrosoftWindowsServer2008、Windows7、SQLServer2008 |
---|---|
移行期間 | 1.5人月 |
要求事項 | 可能な範囲でVB6と同等レベルの動作を維持したい infortechの標準テストの他に、指定の業務テストを実施する |
本件は、比較的規模の小さいプロジェクトであることと、 NTTデータ四国様のマイグレーションを行うのが今回で2件目ということもあり、移行作業はスムーズに行うことが出来ました。
以下に今回の作業の流れを紹介致します。
1.マイグレーション資産分析 御預かりしたVB6資産を分析し、現行システムで使用されていない画面等の検出を行いました。
分析の結果、使用していないファイルが10ファイル見つかり、NTTデータ四国様の御了承を頂いた上で、マイグレーションの対象外とさせて頂きました。
2.VBMP変換、コンパイルエラー除去 VBMPでの変換の前に、.NET版SPREADのユーザークラスのプロトタイプと、VB-Reportのラッパークラスを作成し、VBMPでの変換時にそれらを参照するように設定します。
以降は、VB6ソースをVBMP変換→コンパイルエラーの確認→変換ルールの調整→VB6ソースをVBMP変換というサイクルを数回行い、コンパイルエラーの除去を行いました。
3.マイグレーション対象画面のデザイン確認とSPREAD対応VB6のデバッグ環境と.NETのデバッグ環境を用意し、マニュアルに沿って全ての画面を表示。
両方の画面を見比べることで、画面の調整を行いました。
調整内容は微調整レベルが大半で、クリティカルな問題は発生しませんでした。
※必要なテストデータ、マニュアルについては、事前にNTTデータ四国様にご準備頂いたため、作業はスムーズに進行致しました。
また、画面の確認と平行して、.NET版SPREADのユーザークラスをブラッシュアップする等、短期間ながら効率的に作業を行いました。
4.旧システムとの動作一致確認 デザイン確認の後、NTTデータ四国様指定のテストケースでのテストを重点的に行い、その他の機能についてもマニュアルベースでの確認を行いました。
データの設定方法や、仕様の確認のため数回問合せをさせて頂いたものの、クリティカルな問題もなく、機能が一致していることを確認できました。
SPREADの.NET対応についても、機能や動作についてVB6と同等の表現を実装することが出来ました。
移行作業中に、初期表示時の選択状態の違いや、ヘッダ上でのクリックイベントの違い等、VB6との動作の違いが発生しましたが、コードの追加により動作を一致させることが出来ております。
※対応の一部は.NET版のマニュアルに記載がないケースがあり、グレープシティ社に問合せを行って、対応方法を入手しました。
※テストは、テストデータの都合等で、クライアントOSをWindows7、サーバOSをWindowsServe2003、DBをSQLServer2005の環境にて確認を行うことで了承を頂きました。
以上のような流れで作業を行い、2011年7月上旬に納品、2011年7月末までにNTTデータ四国様に御確認を頂き、検収完了を不具合報告無しで頂いております。
この度も、インフォーテック社様の多大なご協力とご尽力により、計画どおりに問題なく開発作業を終えることが出来ましたことに対し、心から感謝致しております。
何よりも嬉しかったことは、コストを抑えての開発が出来たことにあります。
これは、Migrationサービスを利用させて頂くことで、短期間で効率よくマイグレーション作業が完了し、以降の改修作業もスムースに完遂することが出来たことです。
Migrationサービスとインフォーテック社様のレベルの高さを痛感致しております。
今回の案件は、約40KStepの販売管理システムのVB資産を、.NETにマイグレーションする小規模なプロジェクトではありましたが、約2ヶ月という短期間でマイグレーション作業および弊社受入作業を、問題なく完了させることが出来ました。
また、SPREADやVB-REPORTのマイグレーションも、今回初めての試みとなりましたが、何の問題もなくVB資産と同等の機能や動作を実装することも出来ました。
インフォーテック社様における、マイグレーション後の動作検証については、弊社よりVB資産のデバック環境や、現行システムでのテストデータおよび試験結果リスト、動作検証用マニュアルを提示させて頂くことで、検証作業を高品質で効率よく、スムースにおこなうことも出来ました。
弊社受入試験においては、ノーバグという高品質での開発を完了することが出来ました。
今後も、マイグレーション案件がありましたら、是非ともお願いしたいと考えております。
インフォーテック社様の今後益々のご繁栄をお祈り申し上げます。
本当にありがとうございました。
企業名 | 株式会社トスコ |
---|---|
VB6資産 | 32万行、画面数153、EXE数120、OLE DLL数33、OLE EXE数1、SPREAD、WingReport、oo4o |
アプリ内容 | 小売業向け仕入売上管理システム |
移行期間 | 4ヶ月 |
Q.VB MIGRATION PARTNERを選択した理由について教えてください。
A.社内にツールを利用したマイグレーション実績がなかったため、インターネットで検索し、HPの事例を参考に選択しました。また、移行対象アプリケーションに実装されていた機能のほとんどがSPREADを利用していましたが、ご来社の際、製品デモに加えてAxWrapperGenを利用して作成したラッパープロジェクトを流用したActiveXコントロールの移行方法をご説明頂けたので移行イメージを掴むことができました。
Q.どのようなプラグマを使用しましたか?
A.標準のコントロールをほとんど使用していなかったため、配列の下限を調整するプラグマのみ使用しました。期間的な余裕がなく、適当なプラグマを調査している時間がなかったためです。
Q.SPREADがアプリケーション機能のほとんどだったとお聞きしましたが、SPREADを含むActiveXコントロールはどのように移行しましたか?
A.SPREADとWingReportを.NET用製品に移行しました。SPREADは数も多く、VB6と同等の動作を実現するのに苦労しました。特に、.NETになって変更された動作について、お客様と調整するのに時間がかかりました。WingReportは.NET Framework 4.0に対応していなかったものの、フォームイメージは流用することができ、フォームイメージ以外はベンダーサポートを利用して移行しました。oo4oについてはODP.NETへ移行したのですが、プーリングを使用する場合、exeごとにコネクションが発生することがわかり、ソリューションを一つにまとめなくてはならなくなり、.NETコードを別のソリューションに移植するのが大変でした。
Q.移行後のアプリケーションの現状について教えてください。
A.本番稼働から1年経ちますが、仕様に起因する不具合や環境に依存する不具合はあったものの、マイグレーションツールに起因する問題は発生していません。
Q.弊社サポートについて率直なご意見を頂けますか?
A.サポートを依頼する際、動作確認用のサンプルプロジェクトを作成する必要があったのですが、作成に手間がかかる場合もありました。
お忙しいところ、ご回答有難うございました。
企業名 | データスタジアム株式会社 |
---|---|
VB6資産 | 30万行、画面数70、EXE数1、MSChart、SPREAD、MSFlexGrid 他多数 |
アプリ内容 | 野球のスコアブック内容を分析するツール |
移行期間 | 6ヶ月(作業要員1名) |
Q.VB Migration Partner(以下VBMP)の利用を決定した理由を教えて下さい。
A.Windows7で対象アプリを動作できなかったので、.NET移行を検討しました。検討過程にてInfortechのVBMPについて問い合わせしました。変換ツール選定過程において、実際のSourceに対しTrial変換をかけた際にコンパイルエラーやコード修正量も少ないことが分かり、またVBMPのツールとしても英語表記ではあるものの難しい操作が必要でなかった為、購入いたしました。
Q.VB Migration Partnerには変換ルール(Pragma)を指定することができますが、利用したPragmaがあったら教えて下さい。
A.エラーが少なかったので特にPragmaを利用せずに、手で修正することで対応しました。
Q.VB6版のActiveXコントロールについては、どのように移行しましたか?
A.まず使用しているコントロールは全てWrapperDLLとして利用することをトライしました。リスト表示という簡単な利用しかしてなかったせいか、SPREADはWrapperで移行できました。Wrapper上のデザインのズレ調整等がありましたが、動作の問題は発生しませんでした。MSChartについては、Wrapperでうまくいかず.NET版の別製品(NetAdvantage)に移行しました。変換作業は1ヶ月程度で完了しましたが、この置き換え作業については非常に時間が掛かりました。
Q.移行期間6ヶ月後、移行されたアプリの現状を教えてください。
A.DB接続について若干遅い結果になりましたが、WindowsXPで安定稼動しており100User以上で利用されております。移行対象のProjectの中で優先的に移行を完了させましたが、未移行のProjectもあります。それらについてはVBMPのライセンス、サポート期間のうちに.NET変換作業だけは終えました。今後順次移行作業していく予定です。
Q.弊社サポート対応について率直な御意見を頂けますか。
A.Trial変換を行ったおかげで、その後の工程で特にサポートを依頼することがありませんでした。
御忙しいところ御回答ありがとうございました。
企業名 | データスタジアム株式会社 |
---|---|
システム構成 | EXE数1、画面数65、変換対象コード行数8万5千行 |
旧運用環境 | WindowsXP、Access2000形式(.mdb) |
特徴 | 球場の表現や、投球コースの表現に描画APIを多用、3rdPartyOCXはSPREAD(6.0J)を使用 |
備考 | VBMPでの変換、コンパイルエラー除去までは完了 |
運用環境 | WindowsXP、WindowsVista、Windows7、Access2000形式(.mdb) |
---|---|
移行期間 | 2人月 |
要求事項 | 可能な範囲でVB6と同等レベルの動作を維持したい SPREADは現行バージョンをラッパーで使用 テストは現行マニュアルにそって行う |
本件は「VBMPによる変換」、「コンパイルエラー除去」というフェーズが、データスタジアム様により完了している状態での御依頼でしたので、マイグレーションサービスのケースとしては、特殊なケースとなりました。
作業内容も、他のマイグレーションサービスとは異なる以下のような流れとなりました。
1.コンパイルエラー除去Sourceの精査、分析、コード調整 御預かり致しました.NETSourceとマニュアルを分析し、現行から使用していない画面またはコントロール等の検出を行いました。
分析の結果、使用していない画面が数画面、未使用のコントロールが1種類見つかり、データスタジアム様の御了承を頂いた上で、マイグレーションの対象外とさせて頂きました。
2.マイグレーション対象画面・デザイン確認 VB6のデバッグ環境と.NETのデバッグ環境を用意し、マニュアルにそって全ての画面を表示。
両方のキャプチャを見比べることで、画面の調整を行いました。
調整が必要な部分は、大部分が簡単な調整(ラベルの表示幅の調整等)でありましたが、一部再現不可能なデザイン仕様等は、データスタジアム様と御相談の上で調整を行いました。
中でもAPIを用いて描画を行っている部分は、既存のAPIをそのまま利用出来なかったため、少し手間取りました。
当初は.NETFrameworkの機能を用いることも検討致しましたが、調査の結果代替のAPIが見つかり、そのAPIを用いることで現行のコードをほとんど修正する必要がないと判明したため、代替のAPIを用いることで機能を実装致しました。
3.旧システムとの動作一致確認 画面の確認後、マニュアルをベースに機能確認を行いました。
こちらも大部分は簡単な調整(コンテナに依存するtab順の調整等)でしたが、SPREADコントロールでKeyUpイベントが発生していないことが判明し、SPREADのラッパーを調整するといった、テクニカルな修正も一部発生致しました。
(VBMPを用いたマイグレーションでは、ラッパーのソリューションを調整するというアプローチが可能です。)
最初はデバッグ環境で動作を一巡し、その後Windows7の本番想定環境にて動作を一巡。
最後にWindowsVista、WindowsXPの本番想定環境で基本機能の確認を行うことで確認とさせて頂きました。
以上のような流れで作業を行い、2010年9月末に納品。
2010年10月にデータスタジアム様に御確認を頂き、全部で5件の不具合報告を頂きました。
そしてinfortechが不具合を修正、2010年11月に検収完了を頂いております。
以前に、弊社側で「VB Migration Partner」でVB.NETに変換し、コンパイルエラーを除去するところまでを行いましたが、その際には、細かな表示ズレや、描画処理の不具合を完全になくすのに結構な時間がかかったり、Windows7やWindowsVistaでの動作確認が不十分であった経験があったので、今回、インフォーテック様のマイグレーションサービスをご利用させていただきました。
結果は良好で、納品後にいくつか見つかった不具合にも即座に対応していただきました。
また上記にもある通り、APIを用いた描画処理のところで、既存のコードをそのまま使えるようにしていただけたので、その後の改修作業をスムーズに行うことができました。
機会がありましたら、またお願いしたいと思います。
ありがとうございました。
2011年4月、株式会社ISTソフトウェア様から明治大学様向け教学関連システムのマイグレーション作業をご用命頂きました。
3ヶ月という短期間ではありましたが、単体テストまで無事に完了/納品することが出来ました。
移行プロジェクトの概要を以下に記します。
企業名 | 株式会社ISTソフトウェア |
---|---|
システム | 教学関連システム |
システム構成 | EXE数4,画面数168,有効コード行数26万行 |
3rdパーティOCX | Spread3.0、InputMan6.5、Active3DPlus |
特徴 | 1.3rdパーティOCXコントロールを大量に利用している。 2.ExcelとのCOM通信、DDE通信を多く利用している。 3.Variant型変数を大量に定義している。 |
旧運用環境 | WindowsXP、Oracle9i、Office2000 |
運用環境 | Windows7 Professional 32bit、Oracle11g、Office2010 |
---|---|
移行期間 | 3人月 |
要求事項 | 3rdパーティOCXは現行バージョンのラッパー版を使用する。 ※ .NET移行後もVB6と同等レベルの動作を維持したい為 |
このシステムを移行する際に、主に以下の課題が発生しました。
1.ExcelとのDDE通信が.NETでサポートされなくなった問題 DDE通信は異なるアプリケーション間において動的にデータ交換を可能にする技術ですが、.NETからはサポートされなくなりました。
VB Migration Partnerは変換したアプリケーション同士のDDE通信はサポートしますが、今回のようにExcelとのDDE通信をサポートすることが出来ません。
幸い、今回のDDE通信は単なるExcelからデータを読み込むだけの処理でしたので、COM通信を利用して、この問題をクリアすることが出来ました。
2.COMインスタンスの使用後に、自動的にオブジェクトが解放されない問題VB6ではCOMインスタンスを使用後は明確に解放しなくても、自動的に解放してくれましたが、.NETでは全てのCOMインスタンスを解放しない限り、タスクマネージャにExcelプロセスが残り、一連処理が終わった後に、タスクマネージャを見ると、Excelプロセスだらけになってしまい、手動で終了させなければなりません。
この問題を回避するために、COMインスタンスの解放が可能なものは解放処理を追加し、COMインスタンスを大量に使用している箇所に対して、処理後にExcelプロセスをチェックし、解放が必要なExcelプロセスを終了する方法で対応しました。
共通関数を作成し、コードの修正方法は単純ではありましたが、広範囲に記述を加える必要があり、確認作業に手間取りました。
3.DBNull型による型変換エラーの問題 .NETではDBから取得したデータがNULLの場合、DBNull型を返します。
しかし、このDBNull型は他のデータ型に変換することが出来ないため、実行時に型変換エラーになってしまいました。
この問題を解決するため、DBNull型を取除く処理を実装し、VB Migration PartnerのPostProcess Pragma(変換ルール)を利用して、DBからデータを取得する箇所を一括変換することが出来ました。
VB6.0からVB.NETへの移行事例が多数あるとのことで、今回の移行プロジェクトにおけるVB変換工程にご協力して頂きました。
VBマイグレーションパートナーは事前に試用版をご提供して頂きました。
事前に変換の効果(変換率の高さ)を実感できたことが協力をお願いした理由の一つでもあります。
実際のVB変換作業においては、弊社社員も変換作業へ参画しており、レクチャして頂きながらの作業をお願いしましたが、計画より2週間早く工程を終わらせることが出来ました。
また、前記の移行課題やお客様からの追加要求(Windows7のセキュリティ、モジュール配布方法の見直し等)に対しても多大なるご協力の上で解決できた次第です。
品質においては、弊社にて受入検査も含めたシステムテスト(約2800項目)を実施させて頂きましたが、変換ミスが要因の問題は一切なくスムーズに作業を進めることが出来ました。
今作業においては3ヶ月と短い期間ではありましたが、VBマイグレーションパートナーの性能の良さ&インフォーテック社様の対応力の高さが、 今回の移行プロジェクトを成功に導いた要因だと実感しております。
機会がありましたら、またご協力をお願いしたいと思います。
ありがとうございました。
整備中
画面数 | 有効コード行数 | 作業期間 | |
---|---|---|---|
金融業 | 700 | 200万 | 1年 |
小売業 | 430 | 60万 | 4ヶ月 |
製造業 | 750 | 70万 | 6ヶ月 |
教育機関 | 150 | 25万 | 3ヶ月 |
情報処理 | 70 | 30万 | 2ヶ月 |