Newテクノロジー（2）
インパクトスケールによる
アプリケーション保守のリスク評価技術

保守のしやすさに着目した新しいメトリクス「インパクトスケール」

新規にプログラムを作成する開発時と、すでに運用しているプログラムを修正する保守時とでは、品質に影響を与える要因は大きく異なります。図2のように、開発フェーズでは、作成するプログラム自体の複雑さが原因となってロジック誤り等の障害が発生すると考えられます。しかしこれらの障害は単体レベルのテストによってほとんど取り除かれるため、保守時にはもはや大きな影響を及ぼしません。
一方、保守・運用フェーズではすでに動いているプログラムを修正することになります。多くのプログラムを呼出したりデータを参照したりするプログラムを修正する場合、その影響は他のプログラムに広く及ぶため、思わぬ障害を引き起こす可能性が高くなります。つまり、保守時の品質に影響を与えるのは、修正時の影響が波及する範囲の大きさであると考えることができます。

[図2]アプリケーションライフサイクルに応じた主な障害要因

そこで富士通研究所では、保守時の影響波及の範囲の指標となる「インパクトスケール」という新しいメトリクスを開発しました。図3で示すように、あるプログラムから呼出されるプログラムや参照・更新されるデータを辿っていき、関係の強さで重み付けしながらカウントすることで、そのプログラムの影響波及の範囲を表現します。この計算はソースコードの静的解析により自動的に行うことが可能です。
従来のメトリクスはプログラム単体や直接関係するプログラム間で計測するものが一般的でしたが、インパクトスケールはこれらとは異なり、広い範囲にわたる間接的な関係まで含めてメトリクス化したことが画期的です。

[図3]インパクトスケールの仕組み

インパクトスケールによる障害発生率予測の効果

保守品質の尺度として、プログラム1行あたりの障害発生件数を示す障害発生率があります。長期間にわたって保守を続けてきたアプリケーションを対象とした分析によって、インパクトスケールと保守時の障害発生率には強い相関があることが認められました。
図4（a）は、インパクトスケールの高い順にプログラムを並べたときに、それらに含まれる障害の割合を示したものです。カーブが急に上昇するほど、少ない行数を検査するだけで多くの障害を見つけることができることを示しています。インパクトスケールの場合は20％のソースを調べるだけで障害の50％近くを見つけることができることがわかります。
比較のため、同じ対象をプログラム内複雑度の順に並べたものを図4（b）に示しますが、こちらの場合は無作為に調べたのと同程度の障害しか見つけることができず、長期間保守を続けたアプリケーションの品質評価にはあまり有効ではないことがわかります。
アプリケーションの状況によってはプログラム内複雑度等の影響が大きい場合もあるので、インパクトスケールとこれらのメトリクスを組み合わせて分析を行うことで、より精度の高い品質評価が可能になります。

[図4]障害の特定能力の比較

インパクトスケールのビジネス応用と今後の展開

インパクトスケールの利点は、ソースコードの自動解析だけで保守品質を計測可能なことです。これまでのように多くの工数をかけてドキュメントやプログラムを精査しなくても、簡単に、しかも客観的に保守リスクの評価が可能です。また、継続的な診断により、障害が発生する以前から品質の劣化を見つけられるので、予防的な保守や再構築のご提案等、資産の状況に応じたきめ細かいサービスをご提供することができるようになります。
現在、富士通では、基幹系業務アプリケーションを対象にした資産分析サービスにおいてインパクトスケールを用いた評価を実施しています。また、保守の難易度や工数の見積もりへの応用も始まっており、保守サービスの品質向上に効果を上げています。
今後はさらに、事例の蓄積によるモデルの改良や対応言語の拡大により、より多くのアプリケーションの品質評価を可能にする技術を目指しています。