私たちは、非常に便利で堅牢なソフトウェアのコレクションを備えた、小規模で非常に専門的な福利厚生管理会社です。一部はCOBOLで書かれていますが、ほとんどはBASICです。2人の専任コンサルタントがこのシステムを30年以上にわたって適切に維持および改善してきました。言うまでもなく、彼らはすぐに引退します。（そのうちの1人は数年引退することを切望していましたが、過失に忠実であり、夫がゴルフを優先するべきだと主張しているにもかかわらず、固執しています。）

私たちは、使用している種類のソフトウェアを提供している国内の3社のみのうちの1社によって開発されたシステムへの転換の道を歩み始めました。この会社は理論的には変換プロセスを完了することができますが、タイムリーにそれを行うためのリソースがなく、実行する必要のある種類のサービスを提供できないと信じるようになりました。私たちのビジネス。（自分の優先順位を設定でき、適切と思われるリソースを割り当てる権限を持っていることほど素晴らしいことはありません。）

ハードウェアは問題ではありません。最新のサーバーで非常に効果的にエミュレートできます。COBOLとBASICが最新の言語である場合、現在のコンサルタントの代替品が今後見つかる可能性があるというリスクを負うことになります。

このようなレガシープラットフォームに集中し、私たちのようなシステムをサポートするためのプログラミングおよびソフトウェア開発の才能を提供し、適切なプログラミングの才能を見つけるリスクを背部から排除するITサポート会社のビジネスモデルがあるはずです若いプログラマーに生産的でやりがいのあるキャリアを持たせることを納得させる仕事。一部にはBASICのような古くてセクシーではない言語で。

要するに、非IT管理者として、この移行をどのように最適に管理できるでしょうか。

「このようなレガシープラットフォームに集中するITサポート企業のビジネスモデルがあるべきだ」と思われるかもしれませんが、個人的には、あなたが直面する課題を「解決」するので、それはあなたの側の希望的観測にすぎないと思います急降下しました。

古い環境で立ち往生することは、前進する方法ではありません。そして、私は、今のところ、あなたが明らかにできないことを喜んで行う会社を見つけることによって、立ち往生しようとする会社の人生を賭けないでしょう。

したがって、あなたが尋ねた実際の質問への答えではなく、移行のリスクを最小限に抑えながら前進する方法についての誠実なアドバイスです。

「正気を失うことなく、ゼロから書き直して生き残る方法」を読んでください

長い移行プロジェクトでエラーが発生しないようにしてください。長い間、実際の結果は得られません。「正気を失うことなく、ゼロから書き直して生き残る方法」を読んでください

そのようなプロジェクトを「古い」方法でやった後、その記事のアドバイスが、同様の問題への取り組み/アプローチにどのように役立ったかを十分に強調することはできません。

自動テストを設定する

まだ準備していない場合（なぜですか？）、現在のプログラマーにアプリケーション用の自動テストハーネスを作成してもらいます。

自動テストスイートは、アプリケーションのすべての機能領域をカバーする必要があります。個々のテストケースの「when_X_then_Y」ルールで現在の作業仕様を文書化するか、文書化します。これは、現在のコードの変更が既存の機能を壊さないようにすると同時に、新しい環境への移行をサポートするのに役立ちます。

COBOLおよびBASICを扱っているため、テストスイートはおそらく統合テストのレベルにある必要があります。入力ファイル/データベースの「固定」セットを処理し、特定のプログラム（COBOL）の出力ファイル/変更されたデータベースの内容を確認し、 /またはアプリケーション。ソフトウェアのBASICパーツでは、コマンドラインパラメーターを追加して、（G）UIの介入なしで特定の機能を実行したり、（G）UIベースの自動テストツールを取得したりすることを意味する場合があります。

計算と他のアルゴリズムを分離する

Cobolでさえ、メインプログラムから呼び出し可能なサブプログラムの概念をサポートしています。すべてのインポート計算と他のアルゴリズムを個別のプログラムまたはモジュールに分離します。目標は、入力を収集して出力を作成するすべてのものから隔離された、うんざりする作業を行うプログラム/モジュール/その他のライブラリを作成することです。

テストハーネスを調整して、古いアプリケーションと単独でテストします。これにより、新しい環境への移行を容易にするために「古い」コードで行っている作業で、エラーが最小限に抑えられます。

「現在の」環境でアプリケーションの新しいセットを開始します

現在のコードを変換しないでください。ある言語を別の言語に変換するということは、古い環境の制約を新しい環境に課すことを意味します。結果はしばしば望ましくない場合があります（結果：ひどい結果になり、維持するのに苦労します）。移行します。その環境のベストプラクティスと考えられる方法で、新しい環境にアプリケーションをセットアップする時間をかけてください。

選択する環境に精通している新しいプログラマを取得してください。重要な計算とアルゴリズムをすべて個別のクラスやパッケージに分離し、それらをインターフェースの背後に隠すことを、初日から優先事項にします。依存関係注入（DIY依存関係注入の最も安価な種類）を使用して、計算を行うためにインスタンス化/使用するクラスを新しいアプリケーションに伝えます。

これはとにかく物事を行うための良い方法であり、あなたのケースでは、ケースごとにそれらの重要な部分を移行することができます。また、新しい環境の呼び出し関数から基本プログラムやcobolプログラムを呼び出す複雑さを隠します。

アプリケーションをセットアップし、おそらくCOBOL / BASICの「ライブラリ」からの計算を使用する単一の最も重要な入力/出力関数をセットアップすることを、さらに進めないでください。

COBOL / BASIC「ライブラリ」を統合する

新しい環境からCOBOL / BASICの「ライブラリ」を呼び出す方法を見つけます。これには、パラメータファイルまたはデータベーステーブルの設定、以前に設定したCOBOL / BASICライブラリをラップするCOBOL / BASICプログラムの実行が含まれます。運がよければ、BASICのバージョンにより、直接呼び出すことができるDLLの作成が許可される場合があります。

COBOL / BASICの「ライブラリ」を呼び出すクラスを新しい環境に実装し、古い環境のテストハーネスにあるのと同じテストを使用して、その環境をテストしますが、新しい環境では単体テストの形式になります。

はい、これはテストを「複製」することを意味しますが、それはあなたがなしでやりたくない安全策です。これらの単体テストが後で新しい環境に移行されたときに計算とアルゴリズムの実装をチェックするテストとして機能するためだけの場合。

ただし、繰り返しますが、前の手順で最も重要な1つの計算で使用される計算に単体テストを追加すること以上に進めないでください。

反復で新しいアプリケーションを具体化する

古いアプリケーションのすべての機能について、前の2つの手順を繰り返して、新しいアプリケーションを具体化します。計算を確認する単体テストを新しいアプリケーションのテストハーネスに追加し続けます。統合テストスイートを使用して、移行された機能が古いアプリケーションと同じように機能することを確認します。

反復でコアライブラリを移行する

最後に、COBOL / BASIC「ライブラリ」の計算とアルゴリズムを移行し、新しい環境に再実装します。繰り返しますが、あなたの正気を保つ方法として（ユニット）テストを繰り返し使用してこれを行います。

このアプリケーションはあなたのビジネスの「中核」のようです。システムまたはプロセスがあなたのビジネスである場合、それはあなた自身のカスタムソリューションを持っている場合です。

あなたはこれをほのめかしました。残念ながら、テクノロジーの更新から長い時間が経過していることを考えると、これは非常に困難な作業です。

2つのルートのいずれかをお勧めします。

1. 上記のやや技術的な回答にあるように、開発者/プロジェクトマネージャー/ QE /オペレーションのITグループにスタッフを配置し、システムを段階的に構築します。ただし、これは非常に高価です。
2. 市販のプロバイダーではなく、資格のあるカスタム開発者コンサルタントを探してください。このグループは、すべてのリソースを処理して新しいシステムを構築します。その後、オプション1よりも少ないスタッフで社内に持ち込み、続行できます。このオプションにはさまざまなリスクがありますが、非技術者にとって適切なプロバイダーを選択することは非常に困難です。また、コスト超過などのリスクが非常に高くなる可能性があります。このルートを軽減するには、既存のスタッフを使用して、入札に関する非常に詳細な要件セット（ユーザーの観点から）を作成します。次に、固定価格の入札も依頼します。

幸運なことに、あなたは約20年間の克服すべき遺産を持っています。安くもなく、簡単でも、きれいでもありません。

レガシーソフトウェアを保守する会社を探したり、レガシーソフトウェアを書き直したりする会社を探すのではなく、継続的な福利管理システムサービスを提供する会社を探してください。ソフトウェアを書き換えるかどうか、設定するスケジュール、使用する言語またはツールを決定する問題を外部委託します。

はい、このアプローチの明らかなコストは、新しいプログラマーを雇うことの明白なコストを超える可能性がありますが、あなた自身の承認により、あなたは非IT管理者であり、最終的にあなたの会社のコストを上回る決定を下すシナリオを予測することは簡単ですアウトソーシングの明らかなコスト。