過去ブログ
X-Analysis 過去ブログ

X-Analysis 過去ブログ

  • Vol.90
    IBM i をこのまま使い続けて良いのだろうか？／不安に潜む問題や課題

    1979年にIBMのロチェスター研究所で開発されたSystem/38が原型となり 1988年AS/400としてデビューしたビジネスマシンは現在IBM iの名称で多くのお客様に利用され続けています。
    アプリケーション資産継承性というIBM iが備えるユニークな特徴と、オープンシステムと遜色ないコストパフォーマンス性が、利用され続ける大きな理由ではないでしょうか？
    しかしながら、昨今「このまま使い続けても良いのだろうか？」という、多くのお客様の声を聞くようになってきました。
    このお客様の声に対し様々な理由と解決方法をシリーズでお伝えして参りますので、是非ご参考にして頂ければ幸いです。

    ■お客様からの疑問である「このまま使い続けても良いのであろうか？」は、IBM iシステムの特性が背景にあると考えられるので、まずはそれを整理してみましょう。

    1.後継者不足
    ①IBM i専任者しか開発・メンテナンスを行ってこなかった。
    ②IBM i専任者の業務を理解した管理者がいない。
    ③①②によりIBM i専任者から積極的に若い世代への引き継ぎが行われなかった。
    ④IBM i上の業務システムに変更・追加の必要がなく外部業者に運用を任せてきた。
    ⑤IBM iにレガシーなイメージがあるため、若い世代が定着しない。
    ⑥⑤により市場全体において若い技術者がおらず、後継者候補を採用できない。
    ※システムのライフサイクルが長いことにより、世界的なIBM iの技術者不足の状況や、永年IBM iシステム運用を外部業者に任せて来たことで、たとえ後継者候補の要員が存在していても、体系立てて引き継ぐ事ができず後継者不足に繋がっている。

    2.アプリケーションのブラックボックス化
    ①数十年前の古いアプリケーションリソースをそのまま使用している。
    ②機能追加等を複数のベンダー、あるいは複数の担当者が行ってきた。
    ③個人の頭の中に仕様書がある。
    ④設計書が更新されていない。
    ⑤担当者が退職した。
    ⑥IBM i システム自体への知識不足
    ※永年利用してきたシステムリソースは、開発当初の要員が異動や退職したり、最新の仕様書が無かったり、複数の運用担当者が存在した経緯によりアプリケーションのブラックボックス化が進み、システムの把握が出来ない。

    3.アプリケーションリソースの肥大化
    ①数十年間アプリケーションリソースの棚卸をしていない。
    ②詳細仕様が不明のため、プログラムを丸ごとコピーして部分改修してリリースしてきた。
    ③本社システムをコピーして各拠点に配布し、配布後は各拠点で独自の改変を行ってきた。
    ④担当者やベンダーの変更毎に開発標準が変わり、共通的なルーチンが派生・冗長化している。
    ⑤大きな改変や移行などイベント時の、ユーティリティリソースがそのままになっている。
    ⑥ソースやオブジェクトのバージョン管理を、個人に任せている。
    ※数十年間アプリケーションリソースの棚卸をせず放置した結果、本来シンプルなロジックや構造体が可能なアプリケーションやシステムが、永年利用で複雑化と冗長化が進み、アプリケーションリソースを肥大化させている。

  • 前述をまとめると、次の課題がIBM iを使い続ける不安の背景にあると考えられます。

    • ・要員および後継者不足が、属人化を上昇させている。
    • ・設計書の陳腐化やシステムを把握している管理者不在で、ブラックボックス化している。
    • ・特性であるリソース継承性に頼るあまり、アプリケーションリソースを肥大化させている。

  • Vol.91
    IBM i の課題を解決するには？／システムの可視化が最大効果を発揮

    Vol.90では、お客様より良くお聞きする「IBM iをこのまま使い続けても良いのだろうか？」というお声の理由や背景をお伝えしましたが、本号ではその解答として「IBM iの課題を解決するには？！システムの可視化が最大効果を発揮」を、解説させて頂きます。

    ■前号ではIBM iユーザの課題として、後継者不足、アプリケーションのブラックボックス化、アプリケーションリソースの肥大化について述べさせて頂きましたが、これらの課題を解決するためには、システムを可視化することが、課題解決の近道と考えます。

    1.課題解決の要素
    課題解決のための方策は、以下の様に整理出来ると考えます。
    ①可視化
    最新のシステム状況を何時でも、誰でも簡単に照会可能にする。（次号以降で詳細を解説させて頂きます）
    ②測定
    アプリケーションリソースの様々な分析を、数値化して共通認識を可能とする。（次号以降で詳細を解説させて頂きます）
    ③計画
    ①②の結果と業務的改善事項を基に検討した結果、現行システム改善が必要と判断した場合は、現行システム改善の計画を行う。
    ④実行
    ③の計画に基づき、現行システム改善プロジェクトをスタートする。
    ※①②で可視化の効果を検証し、必要と判断した際に③④を実践して全ての課題解決を行う。

    2.最大効果を発揮するシステム状況の可視化
    課題解決のために、可視化においては次の実現が必須と考えます。
    ①IBM iの最新リソース全てを可視化対象とする
    バージョンの異なるソースファイルやオブジェクト(プログラム、ファイル等)を可視化する。
    ②スキルの異なるメンバーの拠り所になること
    業務知識やIBM iのスキルの差異を越えて、協同作業を可能にする可視化。
    ③日々の運用に影響がない可視化環境であること
    誰でも簡単な操作で、現行の運用作業に影響を与えない可視化環境。
    ※単に最新のシステム状況の可視化ではなく、全てを可視化対象として各メンバーの知見の格差を埋め、現行の運用作業に影響を与えない。

  • 前述をまとめると

    • IBM iシステムの課題解決策は、最新の状況を誰でも簡単な操作で、個人スキルの差を埋める可視化環境を、現行運用作業に影響を与えることなく実現することが、最大効果を発揮すると言えるのではないでしょうか。

  • Vol.92
    IBM iのシステム可視化にはツール利用が最適？／システム可視化についてツール利用の考察

    Vol.91では、IBM iを使用するお客様が抱える課題解決に対しての解として「システムの可視化が最大効果を発揮」することを述べさせて頂きましたが、本号ではシステムの可視化を実現するツール利用について、事例を基に考察させて頂きます。

    ■お客様事例
    〇お客様プロフィール
    業種 ：流通卸会社
    規模約 ：16,000本（CLP、RPG）
    検討内容 ：現時点、IBM iを継続利用しながら オープン系への移行に関して計画中

    ○課題
    ①各拠点に設置された複数台のIBM iに分散され冗長化したシステムの、アプリケーション資産が把握できない。
    ②サーバー統合およびアプリケーションの最適化を実施し、IBM iを1台に集約したい。
    ③上記②の集約・スリム化を実施したリソースに対し、段階的モダナイゼーションの実施。
    〇課題解決の要素
    課題解決には次の把握が必要となりますが、「システムの分析・可視化」により得る事が可能となります。
    ●稼働・非稼動リソースの把握
    ●冗長リソースの把握
    ●類似リソースの把握
    しかし、手作業でこれらの可視化を行った場合、膨大な工数が掛かったり、均一ではない可視化データが出来上がる等の問題点が発生します。

    ■課題解決の問題点を取り除くためには、どうすれば良いのか？
    次の工数やスキルが必要となります。
    ・ソースやオブジェクト間の関連性分析には、手間暇が掛かる（又は人手では不可能）。
    ・RPG、COBOL、CLPといったリソースを、均一に読み下す高いスキルが必要。
    ・読み下しのリソースが多ければ、膨大な工数が必要。
    これでは、開発工程と変わらない作業内容となってしまいます。工数削減と均一化されたデータ作りには「システムの可視化」に特化したツールに、頼る他は無いと考えます。それもIBM iに特化したツール利用がベストと考えます。

    ○ツールの活用範囲と活用方法
    活用範囲：事例課題の①②における調査工程
    活用方法：
    ●稼働・非稼動リソースの把握
    ツールのオブジェクト情報参照機能を用いて最終稼動日時情報を抽出し、閾値を決めて非稼動判断を行い整理する。
    ●冗長リソースの把握
    ツールのリポジトリ比較機能を用いて、各拠点の相違・同一のオブジェクトを把握し、同一のものを対象として整理する。
    ●類似リソースの把握
    ツールのソフトウエアメトリクス機能を用いて、アプリケーションソースコードの類似について評価された数値に基づき、類似分析を実施して最適化を図る。

  • 前述をまとめると

    • 事例の課題解決を人手で行えば、膨大な工数が掛かったり（又は人手では不可能）、均一な調査結果が得られないなどの問題点が発生する。分析・可視化ツールを使用する事でリソースの読み下しは均一となり、分析に掛かる工数は実質ゼロになる。その結果、調査作業が高品質で高効率となり、調査工程の大幅なコスト削減が可能となる。

  • Vol.93
    X-Analysis とは？／IBM i 専用の分析・可視化ツール決定版！！

    Vol.92では、事例を元にIBM i を使用するお客様が抱える課題解決に対してツールを利用することで、効果的に分析・可視化が、行えることを述べさせて頂きました。本号では、弊社が一推しするIBM i に特化したツールである「X-Analysis」をご紹介させて頂きます。

    ■「X-Analysis」の「X」は縦断と横断の意味が込められ「Analysis」と合わせて「全網羅解析」を表しています。その名の通り、System36及び38の時代の資産からFreeform RPGで記述されたソース等、最新の資産まで解析することができます。世代を超えてオブジェクトもソースコードも解析対象となる唯一のツールそれが、「X-Analysis」です。
    「X-Analysis」には「見える化」を行うと共に、助言者・忠告者の役目を果たし 「相手のためになる言葉をかける者」という意味が込められています。リソース内のあらゆる構造や関係性を明らかにし、リソースの問題点やシステムの課題に対する調査という視点でのサポートも行います。

    ・オブジェクト間の関連性
    プログラムの呼び出し関係、プログラムとファイルの関係、ファイルとファイルの関連性など
    ・ソースレベルの横断関係性
    フィールドの変数影響箇所、変数の使用箇所など
    ・品質管理
    リソースの問題及び複雑度分析
    ・統合および分散準備
    分散リソースの比較分析、サブシステム間の関連分析
    ・ビジネスルール抽出
    リソース内の条件分岐などのルールを整理、分散ルールの合致及び類似検索

    ■製品動作環境
    ・サーバー
    IBM i (分析・可視化したいサーバー)
    ・クライアント
    上記のサーバーと接続された、Windows10以降のOSがインストールされたPC
    ●分析・可視化したいサーバーのみを使用する為、他ツール等に見られるWindowsサーバー等は不要です。又、分析・可視化したいサーバーに接続してX-Analysisクライアントモジュールが、インストールされたPCから、いつでも分析・可視化結果がご利用頂けます。
    ●「X-Analysis」ライセンスは、IBM i サーバーのシリアル番号と紐付けられることから複数有る論理区画(LPAR)でも１つの「X-Analysis」ライセンスで済み、他のツールのようなユーザー数縛りはございません。

    ■分析・可視化対象
    ・ソースファイルを含むオブジェクト全てが対象！
    ・ソースコードが存在しないリソースも対象
    DSPxxxコマンド等、オブジェクトから得られる情報全て（パッケージソフトの提供オブジェクト、DFU、QRY、ソースを紛失したPGM等）
    ・過去から現在の継承リソース全て対象
    36、38モードで稼働しているオブジェクトから、Free Format RPGや埋め込みSQL記述などIBM i 上で稼働しているリソース種別や世代で欠落をしない

  • 利用対象者

    • 「X-Analysis」ご利用者は、IBM i の知識やスキルは不要です！
      オープン系のエンジニアでも、抵抗なく利用が出来るインターフェースで操作を行うことが可能で、Rational Developer for i 等の開発ツールとの連携拡張性にも富んでおり、オープンソースの統合開発環境(IDE)であるEclipse上で一つのツールのようにご利用頂けます。

  • Vol.94
    X-Analysis で何が見える化出来る？／業務の見える化は属人化を解消！

    Vol.93では、IBMi専用の可視化・分析ツール「X-Analysis」の動作環境、分析・解析対象、監査機能の概要を紹介させて頂きました。本号では、X-Analysisで何が見える化出来るかを、機能ごとに紹介させて頂きます。

    X-Analysisのストラクチャーチャート機能は、業務システムの仕組みを任意のプログラムを起点として、ツリー構造で詳細に見える化します。
    …例えば、バッチ処理でプログラムが異常終了した場合、X-Analysisのストラクチャーチャート機能を使用すれば、異常終了したプログラムの前後プログラムを瞬時に把握する事が可能で、リランポイント判定や復旧ファイルを特定出来るので、属人化の解消や運用作業効率アップが図れます。

    ■業務システムの見える化
    1.ストラクチャーチャートダイアグラム
    アプリケーション内で、別のプログラムにどのようにパスするかをグラフィカルに表示します。これにより、プログラム・ツリー構造が分かり易く理解出来ます。また、関連ファイルを表示させて、プログラムとファイルの関係を表示する事も可能です。
    一覧形式で表示させる事により、プログラム・ツリー構造の深さ(Depth)を明確化しますので、プログラムやファイルの関係性を調査する際の効率アップが可能となります。
    ★アプリケーション内で、オーバーライドによる上書きがなされているファイルに関しては、上書き構造を明確化します。

    2.逆順ストラクチャーチャート
    グラフィカルに表示する機能はストラクチャーチャートダイアグラムと同じですが、プログラム・ツリー構造を逆順に見える化します。言い換えれば、特定のプログラムがどのように呼び出されているかを逆に辿っていきます。これにより、起点とするプログラムから遡ってプログラムの関係性を調査する際の効率アップが可能となります。

    3.階層型ストラクチャーチャート
    グラフィカルに表示する機能はストラクチャーチャートダイアグラムと同じですが、プログラム・ツリー構造を階層毎に見える化します。結合テスト開始時において、テストケースを検討する際の効率アップが可能となります。

    ■ストラクチャーチャート機能の見える化詳細（抜粋）
    ・中心オブジェクトの任意選択
    あらゆる種類のオブジェクトを中心に指定することができます。
    …例えば、一意のプログラムやファイル等のオブジェクトを選択することにより、そのオブジェクトを中心としたストラクチャーチャートを簡単に見える化できます。
    ・オブジェクト呼び出し関係表示
    プログラムやコマンドオブジェクトを中心に据えることで、その親子関係を表示します。呼び出し時に使用しているパラメータも表示されます。
    …例えば、一意のプログラムやコマンドのオブジェクトを選択することにより、そのオブジェクトの親子関係を簡単に見える化でき、さらに使用パラメータもソースコードを参照すること無く確認できます。
    ・動的呼び出し対応
    変数を使ったプログラム呼び出しに対応しています。
    …プログラム内変数値やプログラム外変数値による動的呼び出しが行われている場合、リポジトリ解析時に動的解析対象として設定することでダイアグラム化し、静的呼び出しと遜色無いストラクチャーチャートを簡単に見える化できます。
    ★ストラクチャーチャート機能の他機能との連動
    ダイアグラム上のオブジェクトを選択し、右クリックすることで機能の殆どを連動して使用することができます。
    また、ダイアグラム上のフィールドやパラメータを選択することで、後の回でご紹介するアクセスパス表示、ファイルアクセス関係表示、フィールドサーチ、変数サーチなどの機能を連動して使用することも可能となります。

  • Vol.95
    X-Analysisでシステム変更時の影響箇所を見える化／多岐にわたる影響箇所を瞬時に確認！！

    システム変更時において、改変作業時間の数倍の調査時間が掛かる場合が少なくありません。ブラックボックス化や属人化の課題を抱えるシステムであれば尚更です。X-Analysisの影響分析は、対象システムの未経験者であっても、短時間で漏れなく影響範囲を特定することを指します。

    ■業務システムの影響分析の基本機能
    1. オブジェクト影響範囲分析
    プログラムなどのオブジェクト利用状況を、瞬時に分かり易く見える化します！
    これにより、システム改修における影響範囲特定が、誰でも簡単に行うことが可能です。

    2. ファイルフィールド（変数含）の影響範囲分析
    対象となるフィールド項目をどのオブジェクトがどの場所で使用しているかについて、瞬時に見える化します。
    この見える化により、フィールド項目やプログラムパラメータ変更などの改変時に、影響箇所の絞り込み作業を大幅に削減し、人手による調査漏れを無くします。

    3. アプリケーショングループ間の影響範囲分析
    業務システムを生産管理や受注管理などのサブシステム単位で括り（仮想的なアプリケーショングループとしても設定可能）、サブシステム間のプログラムやファイルの呼び出し関係数を見える化します。この見える化により、業務システム改修時にサブシステム間の影響範囲を瞬時に把握できます。詳細分析については通常操作方法と変わりありません。

    4. ビジネスルール分析
    アプリケーションの修正時にビジネスルールを変更する場合は、キーワードによるソーススキャンだけでは影響箇所特定が漏れたり、工数が掛かる場合があります。
    例えば、｢顧客区分＝"1" の時、5％割引｣などのプログラム上のビジネスルールが解析されているので、顧客区分の体系が変更になった際の影響範囲を、瞬時に検索が可能です。X-Analysisは、完全にビジネスルールが一致するもの、条件は合致しているがその時の動作が異なるもの双方を検索するので、影響を受けるビジネスルールが明確に把握できます。

    5. ソーススキャン
    PC上で、IBM i のソースファイルの見える化が可能になるだけでなく、キーワードを設定された各ソースファイルで網羅的に検索し確認することが可能です。これにより、IBM i 端末を使用したプログラム開発管理機能 (PDM)ユーティリティーを使用する、操作の煩わしさから解放されます。

    6. データ辞書化
    ソースメンバーで使用される変数やファイル項目を網羅的に変数として扱い、その使用状況や属性を抽出し辞書化することで、コードや区分などが見える化出来ます。
    例えば、モダナイズを検討する際に、現行システムの区分設計書として活用できます。

  • Vol.96
    X-Analysisで忖度なしのシステム問題分析／業務システム丸ごと自動分析！！

    X-Analysisの問題分析は、システムが抱える品質低下となる問題点を、自動的に包み隠さず抽出します。

    ■業務システムの問題分析（代表機能と特徴）
    ①オブジェクトとソースの不備に関する分析
    業務上支障が発生していない問題点は、警告メッセージ的な位置付けとなりますが、改修や移行時に問題となる矛盾点を漏れなく抽出してくれます。抽出された問題点の対応策を事前にとることで、バックログ発生を防ぎます。
    01）装置ファイルが作成された後にその元となるソースメンバーが更新されている。
    02）DDSソースメンバーに対応したFILEオブジェクトが見つからない。
    03）FILEオブジェクトの元となったDDSソースメンバーが存在しない。
    04）ソースメンバーに対応したプログラムオブジェクトが存在しない。
    05）プログラムオブジェクトの元となったソースメンバーが存在しない。
    06）ファイルオブジェクトが作成された後にDDSソースメンバーが更新されている。
    07）ソースメンバーに対応した装置ファイルが見つからない。
    08）装置ファイルの元となったソースメンバーが存在しない。
    09）参照先のデータベースファイルが存在しない。
    10）参照先のプログラムオブジェクトが存在しない。
    11）コピー句のソースメンバーが存在しない。
    12）オブジェクトとソースの更新日付がマッチしない。
    13）コマンドの元となるソースファイルが存在しない。
    14）コマンドソースファイルをコンパイルしたオブジェクトが存在しない。

    ②プログラムの複雑性に関する定性分析
    X-Analysisには、次の「定性」テーマに基づき対象プログラムを抽出する機能があります。定期的に分析結果を確認して対応策をとることで、システムの品質向上に寄与し運用作業工数軽減につながります。
    01）ELSEを含む条件文が２重以上のネストをしている。
    02）GOTO文を用いている。
    03）IF文のネストが５重以上である。
    04）IF/DOブロックのソース行数が４８を超えている。
    05）多重ループがある。
    06）内部サブルーチンのソース行数が８０を超えている。
    07）プログラム内でライブラリ名をハードコーディングしている。
    08）ファイルの先読み無しにファイル更新をかけている。
    09）ファイルの先読み無しにファイルレコードを削除している。
    10）クローズしたファイルに操作しようとしている。
    11）レシーバーが結果データに対して小さい。
    12）ゼロディバイドを行っている。

    ③ファイルのモダナイゼーションに関する分析
    アプリケーションのモダナイゼーションやオープンシステムへの移行を行う場合に、忘れがちな改善点を抽出します。
    ①と同様に、事前対応策をとることでバックログの発生を防ぎます。
    01）SELECT/OMITルールが設定されている。
    02）トリガーが設定されている。
    03）LFでJOINが設定されている。
    04）PFがユニークキーを有していない。
    05）埋め込みSQLから参照されているLFである。
    06）QUERYから参照されているLFである。
    07）内部定義ファイルである。
    08）DDLで既に定義されたテーブルである。
    09）DDLで既に定義されたビューである。
    10）DDLで既に定義されたインデクスである。
    11）キー設定がないLFである。

    ④不要資産及び問題資産の抽出
    使用されていないシステム資産について、オブジェクトの稼働日情報以外の視点から問題点を抽出します。抽出された問題点は、主にシステム資産のスリム化を図る際の根拠となります。
    01）使用されていない内部サブルーチン
    02）コピー句の記載に間違いがあるソースメンバー
    03）2重定義された論理ファイル（別名で定義が同じもの）
    04）使われていない論理ファイル
    ★上記の抽出事項は、将来の製品バージョンアップに伴い追加、変更、廃止されることがあります。

  • Vol.97
    X-Analysisでプログラムを見える化／最新のプログラム仕様を誰でも確認可能！

    X-Analysisのプログラム分析は、 最新のプログラム仕様を自動的に生成し誰でも確認することができます。

    ■プログラムの見える化
    1.データフローダイアグラム
    指定したオブジェクトを中心に、プログラムやファイルといった全てのオブジェクトの見える化は、アプリケーションデータの流れ「Flow」の理解に役立ちます。また、各ファイルの「CRUD」判断も可能となります。

    2.プログラムストラクチャーチャート
    プログラムの内部構造の見える化は、内部構造の理解に役立ちます。プログラムの内部サブルーチンや呼び出し先プログラムをグラフィカルに表示します。これにより、ソースコードを解読しなくてもプログラムの内部構造理解と、プログラム作成者の癖や複雑性も素早く把握することができます。

    3.プログラムフローチャート
    プログラムフローチャートの見える化は、プログラム構造の理解に役立ちます。最新のソースコードを基に、プログラムフローチャートを自動生成します。ソースコード単位にプログラム構造を理解出来るだけでなく、対象プログラムの言語未経験者でも、プログラム構造を理解できます。
    ★Microsoft Visio又はOpenOffice Drawの利用が前提です。
    　(Microsoft、Microsoft Windows はMicrosoft Corporationの登録商標です)

    4.アクセスパスダイヤグラム
    現行の物理ファイルと関連した論理ファイルの関連性を理解するのに役立ちます。これらは、モダナイゼーション時の考慮すべき事項としての資料としても活用できます。プログラムがアクセスするファイルのアクセス関係を、グラフィカルに表示します。また、プログラムのファイルアクセス時に使用されているファイルフィールドも、入出力、更新別に表示しますので、ソースコードを解読しなくてもファイルフィールドが把握できます。

  • Vol.98
    X-Analysisはプログラムを総合的に難易度自動判定／さらばステップ数による難易度判定！！

    X-Analysisのプログラム難易度判定は、最新のソースコードにより自動的に難易度を数値化し誰でも確認することができます。

    ■難易度測定手法の色々
    1.ソフトウエアメトリクス
    プログラム内の経路の数を数値化するもので、Thomas J. McCabeによって1976年に考案され「サイクロマティックコンプレクス（循環的複雑度）」と呼ばれる手法で数値化を行います。例えば、ソースコード内に条件が1つのIFxx文のような決定論理が、1つある場合、IFxx文が、真の場合と偽の場合があり、独立したパスは2つとなります。
    RPG、COBOLにおいて条件判定に処理（独立したパス）に伴う命令コードが、対象となります。
    …このソフトウエアメトリクスによって算出された数値は、例えばシステム再構築の際、プログラム開発工数見積の係数として、使用することにより見積精度が向上します。

    2.ソフトウエアサイエンス
    これは「ハルステッド」手法により、プログラムの持つ情報量と理解の難易度を定量化する理論で、プログラムを命令とオペランドの系列と捉えて数値化を行います。
    …このソフトウエアサイエンスによって算出されたハルステッド値は、例えば大規模な改修において、ソースコードの「読み易さ」の係数として、使用することで見積精度が向上します。

    3.サブシステムメトリクス
    サブシステム間のプログラムの呼び出し数、データベースのアクセス数をリスト化し、サブシステムの独立性や結合度を測る指標とします。
    …このサブシステムメトリクスによって算出された数値は、例えばシステム再構築の際、関連する業務システムの開発工数見積の係数として、使用することにより見積精度が、向上します。

    4.メンテナンスインデクス
    上記1.2.から求めることができる「メンテナンスのしやすさ」の指標数値です。
    これは「設計情報の分析のしやすさ」や「マイグレーションのしやすさ」に読み替えることもできます。
    …このメンテナンスインデクスによって算出された数値は、例えばシステム再構築の際や、日々メンテナンス作業に於ける工数見積の係数として、使用することにより見積精度が、向上します。

  • 難易度測定のまとめ

    • 現在、多くの企業で行われているソースコードステップ数、オブジェクト数などから算出する見積工数では、上述で記述した諸々の「難易度」が考慮されていない為に、作業時の工数と乖離がありました。その結果、PJ開始後に追加工数（費用）が発生したり、スケジュール遅延の原因にもなっていました。これまで「難易度」の見える化は不可能でしたが、X-Analysisを使用することで、上述で記述したような「難易度」を見える化（数値化）することによって、精度の高い見積工数を算出する事が可能となります。

  • Vol.99
    X-Analysisはプログラムを総合的に難易度自動判定／正解！！画面の難易度判定

    X-Analysisのプログラム難易度判定は、最新のソースコードにより自動的に難易度を数値化し誰でも確認することができます。

    ■画面難易度測定手法
    1.スクリーンメトリクスとは
    スクリーン上のフィールドの数とデータベースフィールドとの関係数、ファンクションキーの使用数や標識の使用数などをリスト化したものです。
    …このスクリーンメトリクスによって算出された数値は、例えばシステム再構築の際、画面（プリント含）開発工数見積の係数として、使用することにより見積精度が向上します。
    ●スクリーンメトリクスとは、どのような情報をもっているのでしょうか？以下にその数値化情報を記述します。
    ① ファイルフィールド数
    ② ワークフィールド数
    ③ ①の元ファイル数
    ④ スクリーン定義数
    ⑤ 使用ファンクションキー数
    ⑥ 使用標識数

    2.スクリーンメトリクスの応用性
    保守改修において、DSPFの定義変更に伴う見積の目安数値として利用できます。スクリーンメトリクスは、DSPFのフィールド数、ファンクションキーの使用数、標識の使用数を考慮したものとなりますので、改修工程に於ける見積の判断材料としても利用可能です。

    3.オープン化の目安数値としての追加しておいたほうがよい項目
    オープン化の目安数値としては、X-Analysisはスクリーンメトリクスの他に次の項目も数値化してくれるので、数値を把握しておく事で見積の判断材料として利用が可能です。
    ① ファイル参照・更新・挿入処理別フィールド数
    ② 画面推移数（親、子供画面数）

  • 難易度測定のまとめ

    • 現在、多くの企業で行われているソースコードステップ数、オブジェクト数などから算出する見積工数では、上述で記述したスクリーンメトリクスによる「難易度」が考慮されていない為、作業時の工数と乖離がありました。その結果、PJ開始後に追加工数（費用）が発生したり、スケジュール遅延の原因にもなっていました。これまで「難易度」の見える化は不可能でしたが、X-Analysisを使用することで、上述で記述したような「難易度」を見える化（数値化）することによって、精度の高い見積工数を算出する事が可能となります。

  • Vol.100
    X-Analysisはファイルも総合的に難易度自動判定／忘れがち！！ファイルの難易度判定

    お陰様で100号目を迎えました。ひとえにいつもご愛読頂く皆様のお陰と感謝致します。
    Vol.99に引き続きX-Analysisで何が見える化出来るかの、詳細解説を紹介させて頂きます。X-Analysisのファイル難易度判定は、最新ソースコードにより自動的に難易度を数値化し誰でも確認することができます。

    ■ファイル難易度測定手法
    1.データベースメトリクスとは
    データベースとプログラムのアクセス・操作関係を表現するCRUD情報(Create,Read,Update,Delete)に加えて、フィールド数、アクセスパス数などをリスト化したものです。
    …このデータベースメトリクスによって抽出された数値は、例えばシステム再構築の際、データベース開発工数見積の係数として、使用することで見積精度が向上します。

    ●データベースメトリクスとは、どのような情報をもっているのでしょうか？以下にその数値化情報を記述します。
    ① CRUD(Create,Read,Update,Delete)サマリー情報
    (プログラム本数をサマリーした数値)
    ② フィールド数
    ③ 主キーの有無と数
    ④ 親ファイル、子ファイルの数（親子関係数）
    ⑤ 参照関係数
    ⑥ アクセスパス数
    ⑦ フォーマット数

    2.データベースメトリクスの応用性
    PFの定義、データ変更に伴う影響プログラム数の把握や、DDL化における見積の目安数値として利用することができます。また、定期的に最新化したデータベースメトリクスを取得することにより、影響度の変化を把握し、リソース全体の複雑性を抑止する為の行動への判断材料としても利用可能です。

    3.DDL化の目安数値としての追加しておいたほうがよい項目
    DDL化の目安数値としては、X-Analysisはデータベースメトリクスの他に以下の項目も数値化してくれるので、数値を把握しておく事で見積の判断材料として利用が可能です。
    ① アクセスパスにおける SELECT/OMMIT設定の有無と数
    ② アクセスパスにおける JOIN設定の有無と数
    ③ トリガーの有無と数
    ④ 既にDDLで作成されているファイルの判定と数

  • ファイル難易度測定のまとめ

    • 現在、多くの企業で行われているソースコードステップ数、オブジェクト数などから算出する見積工数では、上述で記述したデータベースメトリクスによる「難易度」が考慮されていない為、作業時の工数と乖離がありました。その結果、PJ開　始後に追加工数（費用）が発生したり、スケジュール遅延の原因にもなっていました。これまで「難易度」の見える化は不可能でしたが、X-Analysisを使用することで、上述で記述したような「難易度」を見える化（数値化）することによって、精度の高い見積工数を算出する事が可能となります。


  • Vol.101
    X-Analysisはサイズ変化を自動的に収集・分析・可視化／空き容量がいつも心配？！

    X-Analysisのデータベース分析機能は、過去から現在までのファイルサイズ変化やファイル変更を自動的に捉え、誰でも確認することができますので使用前にファイルサイズなどを把握でき予防処置を講じることができます。

    ■データベース分析機能
    データベース分析の機能は、２つの機能を提供します。
    以降に２つの機能を述べさせて頂きます。

    1.データベースサイズ統計
    データベースサイズ統計は、データベースに対するサイズ情報を数値データとして履歴しリスト化します。
    …このデータベースサイズ統計によって抽出された数値データは、例えばシステム再構築の際、データベース再設定時のサイズ設定数として利用することで設定精度が向上します。なお、この抽出された数値データを、指定した時間帯のデータベースサイズ統計としてグラフ化することで、曜日別のサイズ変移など数値をより簡単に分析することができ、正確で効果的なデータベース再設定が可能となります。
    ●データベースサイズ統計とは、どのような情報をもっているのでしょうか？
    以下にその数値情報を記述します。
    ① データベース名
    ② 日付（変更日時）
    ③ サイズ
    ④ メンバー数
    ⑤ レコード数
    ⑥ 削除レコード数

    2.データベース変更記録
    データベース変更記録は、データベースに対する変更情報を数値データとして履歴しリスト化します。
    …このデータベース変更記録によって抽出された数値データは、例えば運用保守の際、データベース変更の履歴を利用することによって、変更が集中しているデータベースを要注意のデータベースとして把握でき、システム改修時に改修工数を集中させるといった対策を講じることができます。
    ●データベース変更記録とは、どのような情報をもっているのでしょうか？
    以下にその数値情報を記述します。
    ① データベース名
    ② タイムスタンプ（変更日時）
    ③ フォーマット数
    ④ フォーマット長
    ⑤ フィールド数
    ⑥ キーフィールド数
    ⑦ ユニークキー有無
    ⑧ キー順
    ⑨ ログ出力理由

  • データベース分析のまとめ

    • IBM i を使用する企業において、業務システムのデータベース使用状況を分析することは、実施されていないのが実情と思われます。使用状況からデータベースサイズ見直しや、変更日時およびレコード数変移の分析は、手作業で対応し工数が掛かる割に恩恵が体感できないことが理由と思われます。
      上述で記述したX-Analysisのデータベース自動分析機能を利用することで、将来を見据えたデータベースサイズを算出しディスク装置増減を検討したり、データベース変更に関する工数見積精度向上となります。

  • Vol.102
    X-Analysisは業務システム変更を時系列に可視化／変更日時と変更内容を知りたい！！

    X-AnalysisのPTF分析機能は、業務システムの変更前後の状況を自動的に捉え、誰でも確認することができます。

    ■PTF分析機能
    PTF分析機能は、変更後であるPTFリポジトリーと変更前であるベースリポジトリーとの比較分析および、それぞれの対象ライブラリーについても比較分析を行い変更情報を適確に表示します。
    …例えば、外部委託した業務システムの改修案件の受入れ時に、対象ライブラリーについてのプログラムやファイルの追加を含む変更を全体的に把握できますので、改修案件に対する変更管理資料を確認しても、実際のオブジェクト等の状況と相違している場合が発生することがありますので、実際のオブジェクト等を確認・検査することで、誤改修による本番環境への反映を未然に防ぐことができます。

    ●PTF分析データとは、どのような情報をもっているのでしょうか？ 以下にその項目を記述します。
    1.クラス（状況）
    ★クラス列に表示されるのは以下の項目です。
    ①MODIFIED：
    通常ライブラリーに含まれるオブジェクトがカスタマイズライブラリーにも存在する。
    ②NEW：
    通常ライブラリーにあるオブジェクトは比較元リポジトリーには、無いものです。
    ③APPLY：
    通常ライブラリーにあるオブジェクトが比較元ライブラリーでも見つかりましたが、カスタマイズライブラリーには見つかりま
    せんでした。
    ④REFERS：
    通常ライブラリーのオブジェクトはカスタマイズライブラリーのひとつ以上のオブジェクトをリファレンスしています。
    ⑤REFERENCED：
    通常ライブラリーにあるオブジェクトがカスタマイズライブラリーにあるオブジェクトからリファレンスされている。
    2.種類（オブジェクトタイプ）
    3.名前（オブジェクト）
    4.説明（テキスト記述）
    5.PTF変更日（変更されたオブジェクト変更日）
    6.ベース変更日（オブジェクト変更日）
    7.PTFソースファイル（カスタマイズされたソースファイル）
    8.ベースソースファイル（ソースファイル）
    9.PTFソースライブラリー（カスタマイズされたソースファイルのライブラリー）
    10.ベースライブラリー（ソースファイルのライブラリー）
    11.PTFメンバー（カスタマイズされたソースファイルのメンバー）
    ※通常ライブラリーは開発環境の受入れ先分、カスタマイズライブラリーは開発環境の受入れ元分となります。
    また、比較元リポジトリーは、本番環境を解析した結果となります。

  • PTF分析のまとめ

    • IBM i を使用する企業において、業務システムの改修案件を外部委託することは、往々にして有ることでしょう。この外部委託を行い納品時の受入れをすることへの不安は、いつも付き纏い緊張することと思われます。上述で記述したX-AnalysisのPTF分析機能を利用することで、変更管理が正しく行われているか否かを精査でき、更に本番環境への反映もスムーズに実施できます。

  • Vol.103
    X-Analysisは業務システム変更箇所を瞬時に可視化／拠点毎にある同種業務システムの変更箇所を知りたい！！

    X-Analysisの差異分析機能は、業務システムの差異状況を自動的に捉え、誰でも確認することができます。

    ■PTF分析機能
    PTF分析機能は、変更後であるPTFリポジトリーと変更前であるベースリポジトリーとの比較分析および、それぞれの対象ライブラリーについても比較分析を行い変更情報を適確に表示します。
    …例えば、外部委託した業務システムの改修案件の受入れ時に、対象ライブラリーについてのプログラムやファイルの追加を含む変更を全体的に把握できますので、改修案件に対する変更管理資料を確認しても、実際のオブジェクト等の状況と相違している場合が発生することがありますので、実際のオブジェクト等を確認・検査することで、誤改修による本番環境への反映を未然に防ぐことができます。

    ●PTF分析データとは、どのような情報をもっているのでしょうか？
    以下にその項目を記述します。
    1.クラス（状況）
    ★クラス列に表示されるのは以下の項目です。
    ①MODIFIED：
    通常ライブラリーに含まれるオブジェクトがカスタマイズライブラリーにも存在する。
    ②NEW：
    通常ライブラリーにあるオブジェクトは比較元リポジトリーには、無いものです。
    ③APPLY：
    通常ライブラリーにあるオブジェクトが比較元ライブラリーでも見つかりましたが、カスタマイズライブラリーには見つかりま
    せんでした。
    ④REFERS：
    通常ライブラリーのオブジェクトはカスタマイズライブラリーのひとつ以上のオブジェクトをリファレンスしています。
    ⑤REFERENCED：
    通常ライブラリーにあるオブジェクトがカスタマイズライブラリーにあるオブジェクトからリファレンスされている。
    2.種類（オブジェクトタイプ）
    3.名前（オブジェクト）
    4.説明（テキスト記述）
    5.PTF変更日（変更されたオブジェクト変更日）
    6.ベース変更日（オブジェクト変更日）
    7.PTFソースファイル（カスタマイズされたソースファイル）
    8.ベースソースファイル（ソースファイル）
    9.PTFソースライブラリー（カスタマイズされたソースファイルのライブラリー）
    10.ベースライブラリー（ソースファイルのライブラリー）
    11.PTFメンバー（カスタマイズされたソースファイルのメンバー）
    ※通常ライブラリーは開発環境の受入れ先分、カスタマイズライブラリーは開発環境の受入れ元分となります。
    また、比較元リポジトリーは、本番環境を解析した結果となります。

  • PTF分析のまとめ

    • IBM i を使用する企業において、業務システムの改修案件を外部委託することは、往々にして有ることでしょう。この外部委託を行い納品時の受入れをすることへの不安は、いつも付き纏い緊張することと思われます。上述で記述したX-AnalysisのPTF分析機能を利用することで、変更管理が正しく行われているか否かを精査でき、更に本番環境への反映もスムーズに実施できます。

  • Vol.104
    X-Analysisはプログラム変更履歴を瞬時に可視化／プログラムの変更履歴を知りたい！！

    X-Analysisのソースコード比較機能は、業務システムにおけるソースコード変更履歴（リソース変移）を自動的に捉え、誰でも確認することができます。

    ■ソースコード比較機能
    ソースコード比較機能は、変更履歴のあるソースメンバーが時系列表示されソースコードの変化、変移を、変更履歴情報と共に適確に表示します。
    …例えば、任意の２つのソースメンバーを選択し比較することも可能ですが、X-Analyisは、リポジトリの最新化（リソースの変更・追加内容の反映）を行う度に、その記録を取っていますので、ソースコードにおいても変更メンバーの情報を持っているので、変更の有ったソースコード（リソース）を迅速に把握し、その変更内容を最新ソースと比較して把握することができますので、改修の偏り（要注意プログラム）の把握や誤改修による本番環境への反映を未然に防ぐことができます。
    ●ソースコード比較データには、次の変更履歴情報により当該オブジェクトに紐ついたソースコード変化、変移を適確に表示します。
    ①変更日日付：変更された日付です。
    ②ソースメンバー：変更されたソースメンバーです。
    ③ライブラリー：ソースライブラリーです。
    ④ソースファイル：変更されたソースメンバーのソースファイルです。
    ⑤種類：オブジェクトタイプとなります。（*PGM、*FILEなど）
    ⑥属性：オブジェクト属性となります。（RPGLE,CBLLE,RPG,CBL,PF,LFなど）
    ⑦説明：オブジェクト記述となります。
    ※ソースコード比較機能は、オブジェクトが存在するソースコードが前提条件となりますので、オブジェクトの存在しないソースコードは、ソースコード比較の対象とはなりません。

  • ソースコード比較機能のまとめ

    • ソースコード比較機能は、以下の４つの利用用途がありますので、日々の保守作業円滑化、プロジェクト推進強化、業務システムの品質向上に役立ちます。


      1.不具合の発見:
      ソースコードの変更や変更推移を確認することで、不具合を発見することが容易に実施することができます。これらのバグ、パフォーマンス問題、コードの欠陥を見つけることは、変更されたソースコードをレビューすることの最も重要な要素といえます。
      2.コード品質の向上:
      ソースコードの変更や変更推移を確認することで、保守の容易性や機能統合といった品質を容易に維持させたり向上させることができます。ソースコード単体の不具合を見つけるだけではなく、プロジェクト全体の品質を改善しますし「機能している」からといって、改善する箇所が無い訳ではありません。
      ソースコードの変更や変更推移を確認することによって、リファクタリングが必要な箇所が見つかることもあるでしょう。
      3.学習・ナレッジシェア:
      ソースコードの変更や変更推移を確認することで、ヒューマンスキルなどに頼っていた改修を誰にでも持続可能な作業とさせることができます。新人開発者や品質管理担当者は、ソースコードレビュープロセスであるソースコード比較機能を導入することで、開発者の意図を学ぶことができ、スキルアップにも繋がります。
      また、チームの誰かが何らかの理由で抜けることになっても、他のメンバーがバックアップすることが可能になります。
      4.連帯感の向上:
      ソースコードの変更や変更推移を確認することで、メンバー間の情報連携などがスムーズに実施できますので、チーム全体で情報共有することで、コミュニケーション向上が図れます。
      ソースコードレビューは、チームワーク、責任感、コミュニティの形成に役立ちます。

  • Vol.105
    X-Analysisの変更管理機能のまとめ／コピーした業務システムの個別変更箇所が分からない！

    X-Analysisの持つ強力な変更管理機能は、業務システムにおけるオブジェクトからソースコードまでの変更を自動的に捉え、誰でも確認することができます。今号では、過去３回に渡ってお送り致しました X-Analysisの変更管理機能を改めて、事例等を交えて解説させて頂きます。

    ■変更管理機能における分析の例
    ①ソースコードの比較分析
    X-Analysisは拠点間の同名オブジェクトのソースを比較することができます。
    ②ファイルのデータ容量、レコード数の比較分析
    X-Analysisはリポジトリの最新化における時系列で変更内容を記録している為、拠点毎の差異を迅速に把握することができます。
    ③リソース品質の比較分析
    X-Analysisはプログラムの複雑度を定量化（経路数等）して評価する機能を持っています。これらの品質に関わる評価の値は、リポジトリの最新化における時系列で変化の内容を記録している為、拠点毎の差異を迅速に把握することができます。
    ④リポジトリの比較分析
    X-Analyisisはリソースをリポジトリ化しますが、複数のシステムをそれぞれリポジトリ化することが可能です。それらが例えば本社システムとそのリソースを派生させた独立した海外拠点のリソースであった場合、それぞれをリポジトリ化することで、リポジトリベースで比較することが可能です。あらゆるオブジェクト、ソースの設定の違いや、作成日、更新日の違いなどを抽出し、派生システムとの差異を明確化しアプリケーションリソースの統合などに寄与します。

    ■変更管理機能を利用したお客様のサービス導入効果事例
    目的：複数台のIBM i に分散且つ冗長化したシステム資産棚卸と最適化を実施
    対象：全てのシステム資産
    規模：約36,000のオブジェクト数
    効果：限られた期間（４ヶ月間）で棚卸を完了、大幅なコスト削減 （見込み費用の50％以下）を実現。
    ●前述した4つのX-Analysisの変更管理機能を使用することで、無理なく「システム資産」を解析し、その結果情報を共有しながら、日々の保守作業や将来の新システム作りに役立つ過去から現在までの「システム資産」を知（可視）ることが出来ます。

  • Vol.106
    X-Analysisで業務システム保守の品質と生産性を向上／業務システム保守に活用！

    今回は、X-Analysisのメトリクス分析機能を活用し、日々の業務システム保守をスムーズに実施出来ることを、過去にお送りしたメルマガを再構成して解説致します。

    ■プログラムの数値化で、品質と生産性向上！!
    担当を引き継いだばかりで、システムを熟知できていない。また、設計書が更新されていないなど、見積り根拠が不明確なまま作業を開始して、想定を上回る工数がかかってしまった経験はございませんか。X-Analysisは、以下に記述する複雑さや難易度を自動的に数値化します。この数値を利用する事により、人手による膨大な調査時間を短縮し、経験や感覚に頼らずシステム開発時に根拠のある工数見積もりが可能となります。

    1.複雑度の数値化で、見積根拠を明確に
    サイクロマティックコンプレクス（循環的複雑度）の紹介。
    ①サイクロマティックコンプレクスとは？
    ⇒IF、ELSEなどのプログラム内の経路数を計測することにより、ステップ数だけではなく、複雑さを考慮した見積りが可能です。循環的複雑度は、見積時においてテストパターンや工数算出に利用する事で、工数見積時の根拠が明確になります。
    ②サイクロマティックコンプレクスの改善メリット
    ⇒循環的複雑度の値を下げるプログラム改善を行うことにより、テストパターンが減り、今後の改訂時において工数減となります。

    2.複難易度の数値化で適正工数を算出
    Halstead Volume（プログラムの情報量）の紹介。
    ①Halstead Volumeとは？
    ⇒プログラムの命令と被演算子を分離してカウントし、プログラムの情報量を数値化します。同じステップ数のプログラムを比較すると、数値が高いプログラムの方が、メンテナンスやモダナイズ時に工数が多く必要です。
    この数値を考慮した工数見積により、適正工数を見積もる事が可能となります。
    ②Halstead Volumeの改善メリット
    ⇒難易度を下げるプログラム改善を行うことにより、今後のメンテナンス効率向上やモダナイズ時の工数減となります。

    ■総合的なシステム改善のメリット！！
    サイクロマティックコンプレクスとHalstead Volumeで保全性をプログラム単位に100点満点方式で分かり易く評価し、直ぐにでも改善が必要なものや、今後改善を検討した方が、良いものを判断する指針になります。
    定期的にプログラムの改善を行うことにより、システム全体の保全性を向上させます。

  • Vol.107
    X-AnalysisでIBM i システムのモダナイゼーション準備を効率的に行う／モダナイゼーション準備の為の活用

    今回は、X-Analysisの各機能を活用し「IBM iシステムのモダナイズ」や「IBM iシステムのオープン化」を検討中の皆様に、参考となるバックナンバーを再構成して紹介させて頂きます。

    ■アプリケーションの無駄に関する課題
    IBM iのアプリケーションは規模が大きいだけでなく、20年、30年、改修と追加を行ってきた資産も多く複雑化・肥大化の傾向にあり、永年利用、膨大なシステム資産、複雑で今後も肥大していくとなると、そのこと自体が日々の改修やマイグレーションの妨げになっています。 無駄と判断されるアプリケーションの発生理由を整理すると、以下に集約されると考えます。

    ①動かないロジックやルーティンが残されアプリケーションが肥大化:
    改修時においてロジック構造全てを把握できていない為、「ロジックやルーティンを残して新しいものを加えていく傾向にある」というお客様が多く、肥大化の悪循環を生んでいる。
    ②使用しなくなったオブジェクトの放置:
    オブジェクトの稼働状況を管理していない為、使用しなくなったオブジェクトを放置し蓄積されている。
    ③改修時に発生する古いリソースが残されている:
    改修時において、古いソース、オブジェクトをコピーして新しいものを作る傾向にあるが、バージョン管理を行っていないため、古いリソースが残存・経年蓄積されている。

    ■DCR プロフェッショナルサービスによる解決
    DCRでは、プロフェッショナルサービスの一環として「棚卸サービス」を、数多くのお客様に提供しています。 　このサービスは「アプリケーションの無駄」を除く前段の調査サービスとして利用が可能で、無駄を除く実際の作業はお客様自身、またはDCRへの委託の双方を選択頂くことが可能です。
    　＜DCR システム資産棚卸サービス＞
    https://www.dcr.co.jp/product/x-analysis/

    ■抽出できる「アプリケーションの無駄（可能性を含む）」の例
    ①非稼働及び一定期間非使用オブジェクト情報
    ②コンパイルオブジェクトを持たないソースメンバー情報
    ③使用されていないコピー句メンバー情報
    ④使用されていない内部サブルーチン情報
    ⑤別名で同じ定義の論理ファイル情報
    ⑥条件文が多重ネストしたプログラム情報
    （デフォルトは5重ネストの設定）
    ⑦ステップ数が多い内部サブルーチン情報
    （デフォルトは80ステップの設定、外部オブジェクト化による共通ルーティン化の可能性）

    ■お客様のサービス導入効果事例
    ①効率的且つ安全に不要リソースを除去できた。
    ②肥大化するメンテナンス調査時間の圧縮のため、長年蓄積されたリソースのスリム化と整理を決断、棚卸サービスをベースに不要資産の抽出に特化したレポートにカスタマイズしたサービスをDCRに依頼した。
    ③いままで特定できなかった不要リソースを迅速に把握し、その情報を元にお客様自身で不要リソースを除去を行った。
    ④スリム化により、日々のメンテナンス効率が各段に向上した。
    ⑤マイグレーション対象を絞り込めた。
    ⑥マイグレーションに伴う現状調査において、業務的な移行対象の絞り込みの前にシステムとして必要のないリソースを把握することが棚卸サービスにより可能になった。
    ⑦更に把握した不要リソースを除外したマイグレーションプロジェクト用のリソース作成とそのリソースを解析する
    X-Analysisの導入をDCRに委託し、プロジェクトの現状調査フェーズを順調に進めることができた。
    ＜DCR システム資産棚卸サービス＞
    https://www.dcr.co.jp/product/x-analysis/

  • Vol.108
    X-Analysisを利用した棚卸とは？／棚卸しサービスですっきりシステム！

    今回は、高品質で安定したIBM i 業務システム「保守作業」を実施する為のX-Analysisの各機能を、活用した棚卸し作業を実施して頂く為に、参考となるバックナンバーを再構成して紹介させて頂きます。

    ■段階的モダナイゼーションで利用
    〇顧客プロフィールと課題
    業 種：流通卸会社
    規 模：約16,000本（CLP,RPG)
    移行先：現時点、IBM i を継続利用しながらアプリケーション資産の「保守作業」と共にオープン系への移行に関して計画策定中である。
    課 題：
    ①各拠点に設置された複数台のIBM i に分散且つ冗長化したシステムに於けるアプリケーション資産の棚卸しを行う。
    ②IBM i のサーバー統合とともにアプリケーション資産も最適化し1台に集約完了させる。
    ③上記②の集約・スリム化を実施したアプリケーション資産に対し、段階的にモダナイゼーションを実施・計画する。（最終目標）

    〇活用範囲・内容と効果
    範 囲：課題の①②における調査工程
    活 用：
    ①非稼動リソースの把握
    X-Analysisのオブジェクト情報参照機能を用いて、最終稼動日時情報を抽出し、閾値で非稼動判断を行い整理した。
    ②冗長リソースの把握
    X-Analysisのリポジトリ比較機能を用いて、各拠点の相違・同一のオブジェクトを把握し、同一のものを整理対象として整理した。
    ③類似リソースの把握
    X-Analysisのソフトウエアメトリクス機能により、評価された数値を用いて、類似分析を実施した。
    効 果：限られた期間（4ヶ月間）での集中調査工程において、大幅なコスト削減（見込み費用の50％以下）を実現した。
    ※削減のポイントはX-Analysisによる調査作業の高効率効果により、外注を使わず内部人員のみで調査できたこととなる。

    ■保守作業と部分的モダナイゼーションで利用
    〇顧客プロフィールと課題
    業 種：製造業
    規 模：約12,000本（CLP,RPG)
    移行先：WINDOWS,JAVA,ORACLE
    課 題：
    ①工場基幹システムのモダナイゼーションをターゲットとした現行アプリケーションの設計書リバースを、IBM i を継続利用しながらアプリケーション資産の「保守作業」と共に実施する。
    ②IBM i のエンジニアはオブサーバーのみで実作業はすべてオープン系のエンジニアで実施する。

    〇活用範囲・内容と効果
    範 囲：課題に対する現行リソース調査工程
    活 用：
    ①業務機能毎の構成リソースの整理
    X-Analysisのオブジェクト情報参照機能を用いて、最上位のプログラムを抽出し、その構成オブジェクト群を整理し予め業務機能を整理した情報との関連付けを行った。
    ②アイテム（項目）の名寄せ（意味寄せ）
    X-Analysisのデータ辞書機能を用いて、全フィールド情報をアイテムとして整理しデータベース設計の元情報とした。
    ③業務コード体系の整理
    X-Analysisのビジネスルール機能を用いて、組織や区分コードの値を用いている条件文等をソースからまとめて抽出し現行システムからコード体系表をリバースした。
    ④処理フローの整理
    X-Analysisの各種フロー機能を用いて、オブジェクト関連性レベルから１本１本のプログラムソースレベルのフローを抽出しロジック仕様のリバースを実施した。
    効 果：IBM i プロジェクト要員を準備することなく実現できた為、従来型の方法に対して20％以上の工数削減効果があった。

    ■モダナイゼーションPJ中の現行資産バージョン管理で利用
    〇顧客プロフィールと課題
    業 種：製造業
    規 模：約7,000本（COBOL)
    移行先：.NET C# SQL SERVER
    課 題：
    ①モダナイゼーションプロジェクト中もIBM i の開発凍結を行えない。
    ②①のため、先行開発されたC#のプログラム等のリソースに対し、開発完了時点の最新のIBM i 上のCOBOLの仕様を加えてリリースしなければならない。

    〇活用範囲・内容と効果
    範 囲：リソースバージョン管理とバージョン間リソース比較
    活 用：
    ①リソースバージョン管理
    X-AnalysisのChange History機能を用いて、IBM i 上の変更ソースをバージョン管理した。
    ②バージョン間リソース比較
    X-Analysisのソースコンペア機能を用いて、開発着手時点の COBOLソースとC#プログラム開発完了時の COBOLソースを比較することで差異を抽出し追加仕様を明らかにした。
    ③追加仕様の可視化
    追加仕様箇所は、フローチャートレベルやビジネスルールレベルでX-Analysis上で可視化し追加仕様書の作成の効率化を行った。
    効 果：プログラムの段階リリースを可能とし、業務的なシステム改善要求をとめることなくモダナイゼーションプロジェクトを進めることができた。

  • DCR プロフェッショナルサービスによる解決

    • DCRでは、プロフェッショナルサービスの一環として「棚卸サービス」を、数多くのお客様に提供しています。
      このサービスは「アプリケーションの無駄」を除く前段の調査サービスとして利用が可能で、無駄を除く実際の作業はお客様自身、またはDCRへの委託の双方を選択頂くことが可能です。
      ＜DCR システム資産棚卸サービス＞
      https://www.dcr.co.jp/product/x-analysis/

    • 〇抽出できる「アプリケーションの無駄（可能性を含む）」の例
      ①非稼働及び一定期間非使用オブジェクト情報
      ②コンパイルオブジェクトを持たないソースメンバー情報
      ③使用されていないコピー句メンバー情報
      ④使用されていない内部サブルーチン情報
      ⑤別名で同じ定義の論理ファイル情報
      ⑥条件文が多重ネストしたプログラム情報（デフォルトは5重ネストの設定）
      ⑦ステップ数が多い内部サブルーチン情報（デフォルトは80ステップの設定、外部オブジェクト化による共通ルーティン化の可能性）

  • Vol.109
    X-Analysisを利用した棚卸の先にあるもの！／棚卸しで次のステージへ

    今回は、IBM i を継続利用しながらモダナイゼーションを実施する為に、参考となるバックナンバーを再構成して紹介させて頂きます。

    ■棚卸ししてから、どんな未来を創造して行くのかは、棚卸し結果によるところが大きいです。不要なIT資産(業務中のプログラムやデータ等)の数が、少なくない場合はそれらを整理整頓する必要が有ります。また、IT資産(業務中のプログラムやデータ等)における重複分(ロジックやプログラム等)を統合や統一を行うといった整理整頓も行う必要が有ります。

    前号Vol.108で記述した「棚卸し」で全ての整理整頓を実施した後には、
    ●モダナイゼーションの方針と具体的なパターンを決定する
    ↓
    ●自社システム環境のあるべき姿として将来のアーキテクチャーを策定する
    ↓
    ●将来のアーキテクチャーの実現に向けた移行ロードマップと移行計画を策定する
    といった工程を実施することができ、IBM i を継続利用しながらのモダナイゼーションが実施できます。

    ■IBM i を継続利用しながらモダナイゼーションする。
    ①アプリケーションの可視化環境の整備
    長期間修正を繰り返し使用されてきたアプリケーションは属人化が進み、ブラックボックスとなっています。この解決には、アプリケーションリソースを解析し、誰もがリソースの内容を調査、理解を深められる可視化環境の整備が必要です。
    ②アプリケーション開発環境の近代化
    オープン系において、コーディング、チーム開発、ソース管理、テスト支援などのツール環境は良いものが揃っており、若いエンジニアはそれらを使うことが当たり前になってきています。IBM i(AS/400)も、これらの開発環境の代表的なものに関して対応を行っており、利用可能な状態です。若い世代への技術継承には、開発環境の近代化も必要条件となってきています。SEU、PDMなどに慣れ親しんだベテランには壁があるように見えますが、実はベテランに寄り添った仕組みもこれらの新しい環境に提供されるようになってきています。
    ③アプリケーションインターフェースの近代化
    他の大項目と比較して、IBM i(AS/400)ユーザーの中で一番進んでいる分野となります。その理由として、一部のニーズを除きエンドユーザーに対するアプリケーションインターフェースはGUIが当たり前であるという認識が定着していることが挙げられます。只、これらの実現のための仕組みは様々な方法の提供と進化を続けているため、自社にマッチした選択が必要となってきています。
    ④データベースとアクセス方法の近代化
    DB2 For iはオープン系のRDBMSと全く遜色なく使うことができるため、その恩恵を受けるための整備が必要です。
    ⑤プログラム開発言語の近代化
    言語の選択肢、その実行環境の選択肢は、数多く提供されてきています。旧来のものを生かしつつ、新しい言語に変えていくことは、IBM i(AS/400)の継続利用を更に未来につなげていくことになります。

  • IBM i を継続利用しながらモダナイゼーションするメリット

    • IBM i 上で、オープンな言語で開発を行い、堅牢なサーバーとOSでモジュールとDBを運用管理することで、モダナイゼーションを実現できることは、大きなメリットがあるのではないでしょうか？ また、パッケージの利用でLinuxでしか稼働しないものがあってもPowerSystemを使用する上では、IBM i のOSと同居して、Linuxの仮想マシンが稼働できますので対応が可能です。
      レガシーシステムというとプラットフォームごと古いというイメージを持ちがちですが、IBM i はそれに当てはまらないため、モダナイゼーションをお考えのお客様は是非、それもご検討いただければと思います。
      ＜DCR システム資産棚卸サービス＞
      https://www.dcr.co.jp/product/x-analysis/

  • Vol.110
    X-Analysisの高度影響分析／部分的な本番稼働もスムーズに！

    「IBM i システムのモダナイズ」または「IBM i システムのオープン化」を検討されている皆様にとって、X-Analysisの影響分析機能の有用性を解説したバックナンバーを再構成して紹介させて頂きます。

    ■影響分析機能
    今回テーマとしている影響分析は、ある対象（オブジェクト、ファイルフィールドなど）に変更があった際に影響のある範囲を抽出することを指します。例えば、「この条件が満たされると、こういうアクションを実行する」というようなプログラム上のコード記述を指します。
    X-Analysisでは、サブシステムもしくはオブジェクトのグループ間、オブジェクト、ファイルフィールド、変数、標識、画面フィールド、ビジネスルールなど俯瞰レベルから詳細レベルまで高度な分析及び結果抽出が可能です。

    ■代表機能とその特徴
    ①サブシステム及びオブジェクトグループの影響分析
    アプリケーションエリアという機能でオブジェクトを任意のグループに分けることができ、グループは更にサブグループ、それ以下の層のグループに分けることも可能です。グループ分けすることで、グループ間の関係性が自動的にチャートの形で視覚化されます。
    例えば、サブシステム間のプログラムやファイルの呼び出し関係数の把握が可能。
    また、ストラクチャーチャートやデータフローなど各分析チャートは、グループの外と中のオブジェクトを色分けして表示されるので、その構成オブジェクトがその業務サブシステム内のものか、別業務サブシステムや共通オブジェクトなのかが、ひと目で理解できるようになります。

    ②オブジェクトの影響分析
    任意のオブジェクトがどのオブジェクトから呼ばれているか、アクセスされているか、そのオブジェクトが表示されているチャートやリスト、ソースコード内の記述から右クリックで検索可能。

    ③ファイルフィールドおよびプログラム変数の影響分析
    任意のフィールドが、すべてのソースメンバーの行の中のどこで使われているか検索することができます。
    この検索は直接的な置換、代入先の変数だけでなく、間接的に代入されている構造変数を含む変数やパラメータ、ワークファイルのフィールドなど、そのフィールドの値が通過する影響範囲のすべてを、一度の検索で特定します。
    この機能はフィールドが表示されているチャートやリスト、ソースコード内の記述から右クリックで検索することができます。

    ④標識の影響分析
    あるソースメンバーを分析している際に、そのソースメンバー内の標識記載内容から、そのソースメンバー内で使われている標識と使用箇所を一覧化でき、煩わしい標識定義を簡単に理解することができます。

    ⑤ビジネスルールの影響調査
    例えば顧客区分を数値で定義したフィールドに対し、区分値の数で条件文をコーディングしている場合において、区分コード体系の数値が変わった際に、同じルールを使用しているプログラムが何本あって、どの箇所で使用しているか特定する必要があります。
    ビジネスルール検索機能では、一回の検索で全てを特定することができます。

  • Vol.111
    X-Analysisの拡張資産解析／モダナイゼーションを円滑に！

    「IBM i システムのモダナイズ」または「IBM i システムのオープン化」を検討されている皆様にとって、X-Analysisの影響分析機能の有用性を解説したバックナンバーを再構成して紹介させて頂きます。

    ■解析対象リソース(システム資産)の違い
    X-Analysisと製品カタログベースでは一見似ていると思われるツールは大きく2つのグループに分類することができます。

    グループ①
    プログラム言語解析系（ソースコードのみの解析）：
    メインフレームの言語解析を行ってきたノウハウを生かし、IBM i のRPG、COBOL、CLP のソースコードを解析して、プログラムの構造などを可視化するツールです。ソースコードは主にRPG、RPGLE、COBOL、CBLLE、CLP、DDS が中心となります。他のツールはRPGLE しか解析できない等言語世代によって制限があるものもあります。

    グループ②
    コマンド実行結果可視化系（オブジェクトカタログ情報のみの2次加工）：
    IBM i のコマンドを実行することで得られるプログラムやファイルオブジェクト情報を2次加工し、チャート化や整理されたリストを行うことで可視化するツールです。
    ソースコードを解析しないので、DSPxxxコマンドを実行した結果における俯瞰的な情報しか得ることができません。

    ■X-Analysisと他ツールの違い
    IBM i の誕生と同時期に誕生したIBM i (AS/400)専用の解析ツールであることから、上記の2つの解析対象リソースのグループの全てを解析しますので、豊富なX-Analysisの機能に加えて、リポジトリの活用という恩恵を受けられます。
    また、メインフレームから移行されたリソースなど内部定義になりがちなリソースも解析、可視化できることから、強力な解析結果が期待できます。

    ①解析対象ソースコード：
    (1) RPGソース（Ⅱ、Ⅲ、ILE）
    (2) COBOLソース（CBLLE可）
    (3) CL,CLPソース
    (4) DDSソース
    (5) OCLソース
    (6) CMDソース
    (7) コピーソース
    (8) SQL

    ◇内部定義の解析
    - COBOLソースの内部定義
    PICTURE句を体系立ててリポジトリ内でレコード化しています。
    フィールド情報としてすぐ活用できるようにフィールド長や小数点桁数などの情報は、項目を分けて格納しています。コピー句に記載されたPICTURE句にも対応しています。
    - RPGソースの内部定義
    プログラム内の変数を体系立ててリポジトリ内でレコード化しています。DBフィールド変数だけでなく、装置フィールドやワークフィールドも含まれています。どの種別の変数か仕分けられるリポジトリ項目を持っているため、DBフィールド変数だけに絞り込むことも可能です。更にデータストラクチャにも対応しています。

    ②解析対象オブジェクト：
    (1) *FILE・・・・ファイル(PF,LF,DSPF,PRTF)
    (2) *PGM ・・・・プログラム
    (36,38モード、ILEを含むRPG,CBL,CLPの他、C、C++、PL/I等（※1）も含む）
    (3) *CMD ・・・・コマンド
    (4) *DTAARA・・・データ域
    (5) *MENU・・・・メニュー
    (6) *MODULE・・・モジュール
    (7) *SRVPGM・・・サービス・プログラム
    (8) *MSGF・・・・メッセージ・ファイル
    (9) *QRYDFN・・・QUERY定義
    (10) *QMQRY ・・・QUERY
    ※1・・・C、C++、PL/I等はオブジェクトカタログ情報のみ、ソースコード解析はできない。

  • Vol.112
    X-Analysisのハンドメイド解析／知りたいことを深掘りできます！

    「IBM i システムのモダナイズ」または「IBM i システムのオープン化」を検討されている皆様にとって、X-Analysisの影響分析機能の有用性を解説したバックナンバーを再構成して紹介させて頂きます。

    ■X-Analysisの解析データを使用したハンドメイド解析
    ハンドメイドな解析には、どのようなものがあるのでしょうか？
    代表的なものを以下に挙げます。

    ①ソフトウエアメトリクス
    広義では、「ソフトウェアの品質を数値化して確かめる」こととされ、ソフトウェア開発をさまざまな視点から定量的に評価したものです。本号では、狭義として「サイクロマティックコンプレクス（循環的複雑度）」をご紹介していきたいと思います。

    ②ソフトウエアサイエンス
    本号では、「ハルステッド」を紹介していきます。これはプログラムの持つ情報量と理解の難易度を定量化する理論で、プログラムを命令とオペランドの系列ととらえて数値化をおこなう手法として使えます。

    ③メンテナンスインデクス
    ①②から求めることができる「メンテナンスのしやすさ」の指標数値です。これは「設計情報の分析のしやすさ」や「マイグレーションのしやすさ」に読み替えることもできます。

    ④データベースメトリクス
    データベースとプログラムのアクセス・操作関係を表現するCRUD情報(Create,Read,Update,Delete)に加えて、フィールド数、アクセスパス数などをリスト化したものです。

    ⑤スクリーンメトリクス
    スクリーン上のフィールドの数とデータベースフィールドとの関係数、ファンクションキーの使用数や標識の使用数などをリスト化したものです。

    ⑥サブシステムメトリクス
    サブシステム間のプログラムの呼び出し数、データベースのアクセス数をリスト化し、サブシステムの独立性や結合度を測る指標とします。

    ⑦メトリクスを用いた類似性分析
    上記、メトリクス値を基にプログラムの類似性を測ります。

    ⑧影響分析
    現行システムにおける改善点があれば、その改修に伴う影響箇所数を調査しリスト化することにより、移行時における追加開発工数の見込みなどに利用できます。

    ⑨稼働・非稼働情報
    実際使用されているリソースかどうかを稼働日で判断しリスト化したものです。全ての測定値の基盤となるものとなります。

    【稼働・非稼働情報レポート内容】
    ・資産規模：
    アプリケーション資産規模の母数を抑える。
    ・機能構成：
    アプリケーション機能の規模内訳を把握する。
    ・プログラム間及びルーチン間、他オブジェクトの関係性：
    PGM間の呼び出し関係とファイル、コマンドなどの関係を把握する。
    ・ファイルの関係性：
    ファイル間（物理、論理）の関係性を把握する。
    ・資産品質： 現行資産の問題点を把握する（１５の品質テーマによる判断）
    ・プログラム複雑性：
    プログラムロジックの複雑性を定量情報化する。（プログラム全本に対して実施）
    ・冗長・不使用リソース：
    アプリケーション資産の冗長・不使用箇所を把握する。
    ※①～⑧は稼働リソースに絞ることが理想と言えます。（余分なものは省く）
お問合せ・
お見積りはこちら
  • 中日本営業部
    052-204-1377
    9：00～17：30（土・日・祝日・年末年始・夏季休暇を除く）
  • 東日本営業部
    03-3456-5331
    9：00～17：30（土・日・祝日・年末年始・夏季休暇を除く）
  • 西日本営業部
    06-6271-2877
    9：00～17：30（土・日・祝日・年末年始・夏季休暇を除く）
  • グローバル営業部
    03-3456-5331
    9：00～17：30（土・日・祝日・年末年始・夏季休暇を除く）