マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

本ページでは、主にプログラム / ソース コードの移行・コンバージョンの作業範囲を扱います。

内部リンク

アプリケーションの移行

ネイティブ・アプリケーション

.NET・アプリケーション

Office VBAアプリケーション

VBA移行

データプロバイダ

移行に関連のある、データプロバイダ

使用しているデータプロバイダとサポート状況を確認してください。

プラットフォーム・サーバ

プラットフォーム

サーバ

.NET関連

VB6.0からVB(.NET)へのコンバージョン

.NETバージョンアップ

ASP.NET の Modernization

.NETのクロスプラットフォーム対応

データプロバイダ

その他、移行

仮想化

プロダクト

テスト

保守、延命

移行・コンバージョン方式の種別について

ここでは移行・コンバージョン方式の種別として、便宜上以下の用語を使用します。

環境移行

本ページでは、環境移行を、

「プログラムはそのまま利用できるが、プラットフォーム、ミドルなどが変更される場合」

とする。

プログラム / ソース コードの修正作業は発生しないが、
サーバなどの構築作業が発生するので、DBMSの移行(データ移行、再構築)などは比較的作業量が多くなる。

ポーティング移行

本ページでは、ポーティング移行を、

「いくらか手修正が必要になるプラットフォーム移植」

とする。

条件付コンパイルやツール / ライブラリソース互換性サブシステムを使用することで移植性を向上させることもあるが、
プラットフォーム間でAPIのI/Fや挙動に差異がある場合は、ポーティング(移植)が必要になる。

  • 例:
    • Win16 → Win32
    • x86 → x64
    • UNIX / Linux → Windows
    • .NET framework → .NET Standard、.NET Core

コンバージョン移行

本ページでは、コンバージョン移行を

「コンバージョン ツールを使ってソース コードをコンバージョンする場合」

とする。

手修正無しのコンバージョン移行

本ページでは、手修正無しのコンバージョン移行を、

「コンバージョン ツールを使用してソース コードをコンバージョンし、そのままビルド、リリースできる場合」

とする(ただしテストは必要)。

開発ツール(ランタイム)のアップグレード(バージョンアップ)をする場合などに多い。

ただし、

  • バージョンアップに伴う後方互換の打ち切り(予告)によるエラー(ワーニング)落とし
  • 変数スコープ変更への対応
    • (関数単位から、コード ブロック単位のスコープへ変更)
    • (修正量は少なくても、修正の際に必要な母体理解作業に工数がかかることがあるので注意が必要)

などにより、若干のプログラム修正が必要になることもある。

手修正有りのコンバージョン移行

本ページでは、手修正有りのコンバージョン移行を、

「コンバージョン ツールだけでは対応しきれない部分があり、その部分の手修正が必要になる場合」

とする。

開発ツール(ランタイム)の

  • アップグレード、
  • バージョンアップ、
  • コード コンバージョン

などの内、

使用する3rdパーティ製ライブラリの

  • 「サポート期間切れ」や、
  • 「当該プラットフォーム上でのサポート無し」

による代替品の利用により、ライブラリのI/O、I/F変更が発生するため、
修正の範囲が非常に大きくなることがあるので注意が必要。

開発ツール(ランタイム)のアップグレード、バージョンアップ

上記のコンバージョン移行と同等に考える。
ライブラリの変更のみの場合など、手修正のみの(コンバージョンを伴わない)場合もある。

マイクロソフト製品のサポートの提供については、下記を参照下さい。

再構築

本ページでは、再構築を、

「母体システムの仕様を基にしてシステムを作り直す場合」

とする(本ページでは扱わない)。

移行見積もりの概要

以下、 環境移行 、 ポーティング移行 、 コンバージョン移行 の見積もり(移行見積もり)の概要について説明します。

説明の前提条件として以下のデータを使用します。

  • 工程別の工数比率を、
    「設計 : 開発 : テスト = 3 : 4 : 3」

と仮定する。

  • 開発工程の工数比率を、
    • 「プログラミング : 単体・結合テスト = 3 : 1」
    • または、「プログラミング : 単体・結合テスト = 2 : 2」

と仮定する。

テスト工程の工数

  • 上記の前提条件下に於ける移行のテスト工数( ≒ 手修正無しコンバージョン移行に必要な工数)は、
    新規の50~40%であるので、移行案件の生産性は、最大で新規開発時の2.5倍程度と仮定できます
    (最大=手修正無しのコンバージョン移行の場合)。
  • また、既存のCLがある場合は、更に工数を削減できます。
    仮に、既存のCLを全て流用可能でCL作成工数がテスト工数の1/2であった場合、
    更に倍(最大で新規開発時の2.5 × 2 = 5倍)の生産性が出ると仮定することもできますが、
    実際は引継ぎなどの関係で、それ程高い生産性は出ないと考えます
    (新規開発時のメンバがそのまま集められる場合は、この限りで無い可能性はあります)。
  • リプレース案件等で「テスト工数を単体テスト工数を除いた結合テスト工数から」とした場合、
    生産効率は、新規の3/10の逆数倍(=3.3倍)となりますが、単体テストを端折る場合の
    リスク(仕様を理解させる工数確保も別途必要になってくる)があります。

以下、移行に於けるテスト工程(CLの作成と消化)の工数について言及します。

CL作成工数

新規開発時にCLを起す作業は、設計 / PGの工程で、作業者が母体の仕様を理解しているため高い生産性で遂行できる。

移行時にCLを再作成するのは、作業者が母体の仕様を理解しながらになるので、生産性は、新規開発時より低くなる。

上記の理由により、移行時のテスト工程は、新規開発時のテスト工程の工数より多くかかると考えます。

CL消化工数

  • 新規開発時にCLを消化する作業は、設計 / PGの工程で、作業者が母体の仕様を理解しているため高い生産性で遂行できる。

  • 移行時にCLを流用する場合、CL消化作業の作業者は、ある程度母体の仕様を理解しながらテストを遂行する必要があるため、生産性は、新規開発時より低くなる。

上記の理由により、移行時、既存のCLを全て流用可能でも、それ程生産性は高くならないと考えます。

その他の工数

また、実際には、テスト以外の作業も発生するため、更に工数を積む必要があるので注意が必要です。

移行見積もりの際は、これらの工数も忘れずに積み上げてください。以下に、それらの作業の一例を列挙します。

環境移行

  • 工数見積(環境の移行性評価作業)
  • 環境構築作業(設計と実装)

手修正作業

手修正作業は、環境移行に留まらない、ポーティング、手修正有りのコンバージョン移行が必要となる案件の場合に必要になる。

また、手修正作業の際、母体理解(リバースエンジニアリング)的な作業工数が追加で必要になることもある。

これらの作業工数の算出のため、前述のプログラムの移行性評価作業が重要になる。

  • 工数見積(プログラムの移行性評価作業)
  • 手修正作業
    • ポーティング
    • 手修正有りのコンバージョン移行
    • 母体理解(リバースエンジニアリング)

異種環境への移行時のテスト・ポリシー

参考


Tags: :移行


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-07-24 (火) 18:36:48 (120d)