JP4688478B2 - ストレージ装置のソフトウェア開発支援システム及びソフトウェア開発支援方法 - Google Patents

Description

本発明は、ストレージ装置のソフトウェア開発支援システムに関する。

ストレージ装置は、例えば、ハードディスク装置や半導体メモリ装置等の記憶デバイスをアレイ状に配設し、RAID（Redundant Array of Independent Disks）に基づいた記憶領域を構築するもので、ディスクアレイ装置とも呼ばれる。各ディスクドライブが有する物理的な記憶領域上には、論理的な記憶領域である論理ボリューム（LU：Logical Unit）が形成され、この論理ボリュームがホストコンピュータ（以下、「ホスト」と略記）に提供される。

ストレージ装置は、例えば、ホストとの間のデータ通信を制御する通信制御基板、記憶デバイスとのデータ授受を制御する通信制御基板、各種のデータを記憶するメモリ基板、記憶デバイス等のように、種々のハードウェア及びソフトウェアを結合させて構成される高度なシステム製品である。各制御基板は、それぞれがマイクロプロセッサ等を内蔵したコンピュータ製品であり、各制御基板がそれぞれの制御プログラムを実行することにより、種々のハードウェアが連携して動作するようになっている。このように、ストレージ装置は、多数のマイクロコンピュータ部品を搭載した大規模なシステム製品であり、多くのハードウェア資源とソフトウェア資源とから構成されている。

ここで、ストレージ装置を新たに開発する場合は、例えば、開発目標に基づいてハードウェア仕様とソフトウェア仕様とをそれぞれ定め、ハードウェアとソフトウェアをそれぞれ別々の開発チームが担当する。両チームは、定期的に又は不定期に連絡を取り合いながら、それぞれの開発を進めていく。そして、最後にハードウェアとソフトウェアとを結合させて、その動作を検証する。

ストレージ装置に用いられるソフトウェア群は、各種制御基板等のハードウェアに組み込まれるものであるため、組込型ソフトウェアとも呼ばれる。このようなハードウェア組込型ソフトウェアでは、例えば、Ｃ言語等の高級言語によってソースプログラムが作成される。このソースプログラムを所定のコンパイラによってコンパイル等することにより、CPU（Central Processing Unit）が直接実行可能な形式のオブジェクトコードを得ることができる。このようにして得られたオブジェクトコードは、制御基板に実装されたROM（Read Only Memory）等に格納される。

なお、ストレージ装置用のソフトウェア開発に使用するものではないが、変更されたコードの動作チェックを自動的に行うことによりソフトウェアの開発を支援するソフトウェア開発支援装置は、知られている（特許文献１）。このほかに、ソフトウェアの静的なまたは動的な解析を行う開発支援ツールも知られている。
特開２００４−２７２８３０号公報

上記特許文献に記載された技術では、ソフトウェアの開発をある程度支援することはできるが、ソフトウェアのみを対象とするため、ハードウェアの仕様変更に対応することができない。ストレージ装置は、多数のソフトウェア群と多数のハードウェア群とが高度に連携する大規模なシステム製品であり、市場要求等によってハードウェア仕様が適宜変更される場合がある。

ハードウェアが変更されると、そのハードウェアを利用するソフトウェア群が影響を受けることになる。例えば、クロック周波数が変更された場合は、そのクロック周波数を直接的または間接的に利用するソフトウェア群に影響が生じる。従って、ハードウェアの仕様が変更された場合は、そのハードウェアを使用するソフトウェアの仕様も変更せざるを得ないことがある。

このように、ハードウェア群とソフトウェア群とが結合したシステム製品では、ハードウェアの仕様変更がソフトウェアの仕様に影響を与え、これによりソフトウェアの手直しや検証が必要となる。従って、ハードウェアの仕様を変更する場合は、その仕様変更の内容がソフトウェア開発者に通知される必要がある。

本発明は、上記問題点に鑑みてなされたもので、その目的の一つは、ハードウェアとソフトウェアとの関係を考慮して、ソフトウェアの開発を支援することができるストレージ装置のソフトウェア開発支援システム及びソフトウェア開発支援方法を提供することにある。本発明の目的の一つは、ハードウェアの仕様変更がソフトウェアに与える影響を予測し、この情報をハードウェア開発者及びソフトウェア開発者の両方にそれぞれ提供することにより、ハードウェア及びソフトウェアを協調させて開発を進めることが可能なストレージ装置のソフトウェア開発支援システム及び開発支援方法を提供することにある。本発明の他の目的は、後述する実施形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明に従うストレージ装置のソフトウェア開発支援システムは、上位装置との間のデータ授受を制御するための情報処理システムを有する上位通信制御部と、記憶領域を提供する記憶デバイス群と、この記憶デバイス群との間のデータ授受を制御するための情報処理システムを有する下位通信制御部と、上位通信制御部及び下位通信制御部により共用されるメモリ部と、上位通信制御部及び下位通信制御部にそれぞれ設けられ、これら各通信制御部の各情報処理システムをそれぞれ制御するソフトウェアと、を備えたストレージ装置の前記ソフトウェアの開発を支援する開発支援システムであって、ソフトウェアに関する仕様情報を取得して、ソフトウェアを構成する所定のソフトウェア要素群の構造を解析するソフトウェア情報解析部と、少なくとも上位通信制御部及び下位通信制御部をそれぞれ構成するハードウェアに関する仕様情報を取得して、ハードウェアを構成する所定のハードウェア要素群の構造を解析するハードウェア情報解析部と、ソフトウェア情報解析部による解析結果とハードウェア情報解析部による解析結果とに基づいて、ハードウェア要素群とソフトウェア要素群との間の依存関係を分析する依存関係分析部と、依存関係分析部による分析結果に基づいて、ハードウェア要素群のいずれか一つまたは複数のハードウェア要素を変更した場合に、その変更がソフトウェア要素群に与える影響度を予測する影響度予測部と、影響度予測部により予測された影響度を外部に提供する情報提供部とを備える。

ソフトウェアに関する仕様情報には少なくともソースプログラムを、ハードウェアに関する仕様情報には少なくともソフトウェアとハードウェアとのインターフェースに関する情報をそれぞれ含めることができる。また、ソフトウェア要素群には少なくともソースプログラムに含まれている関数群を含め、ハードウェア要素群には少なくともインターフェースに関するレジスタ群を含めることができる。そして、（１）ソフトウェア情報解析部は、関数群の各関数間の相互関係を解析し、（２）ハードウェア情報解析部は、レジスタ群をその機能別に分類し、（３）依存関係分析部は、（3A）レジスタ群の各レジスタ毎に、該レジスタを直接的または間接的に利用する関数群の階層構造を分析し、この分析された階層構造に基づいて、各レジスタ毎に、該レジスタと該レジスタを利用する関数との論理的な距離を検出し、（3B）関数群の各関数毎に、レジスタ群の利用状況を分析し、（3C）検出された論理的な距離と分析された利用状況とに基づいて、各関数が各レジスタに依存する依存度合をそれぞれ検出し、（４）影響度予測部は、依存関係分析部により検出された依存度合に基づいて、レジスタ群の各レジスタ毎に、該レジスタに対応するハードウェアを変更した場合の影響度をそれぞれ検出する、ことができる。

影響度予測部は、ソフトウェアの品質管理情報を取得し、この取得した品質管理情報と依存度合とに基づいて、各影響度をそれぞれ検出することもできる。

また、本発明の別の観点に従うストレージ装置のソフトウェア開発支援方法は、ソフトウェアに関する仕様情報を取得して、ソフトウェアを構成する所定のソフトウェア要素群の構造を解析するソフトウェア情報解析ステップと、少なくとも上位通信制御部及び下位通信制御部をそれぞれ構成するハードウェアに関する仕様情報を取得して、ハードウェアを構成する所定のハードウェア要素群の構造を解析するハードウェア情報解析ステップと、ソフトウェア情報解析ステップによる解析結果とハードウェア情報解析ステップによる解析結果とに基づいて、ハードウェア要素群とソフトウェア要素群との間の依存関係を分析する依存関係分析ステップと、を含んでいる。

そして、依存関係分析ステップによる分析結果に基づいて、ハードウェア要素群のいずれか一つまたは複数のハードウェア要素を変更した場合に、その変更がソフトウェア要素群に与える影響度を予測する影響度予測ステップを、さらに含めることもできる。

本発明の手段またはステップは、その全部または一部を、コンピュータプログラムによって実現可能な場合がある。このコンピュータプログラムは、例えば、ハードディスク装置、半導体メモリ装置、光ディスク装置等の記録媒体に固定させて流通に置くこともできるし、あるいは、通信ネットワークを介して送信することもできる。

図１に基づいて、本発明の実施形態を説明する。図１は、実施形態の全体概念を模式的に示す説明図である。この全体概念図には、以下の発明が開示される。

即ち、所定のハードウェアに組み込まれ、このハードウェアの作動を制御する所定のソフトウェアの開発を支援するハードウェア組込型ソフトウェアの開発支援システムであって、前記ソフトウェアに関する仕様情報を取得して、前記ソフトウェアを構成する所定のソフトウェア要素群の構造を解析するソフトウェア情報解析部と、前記ハードウェアに関する仕様情報を取得して、前記ハードウェアを構成する所定のハードウェア要素群の構造を解析するハードウェア情報解析部と、前記ソフトウェア情報解析部による解析結果と前記ハードウェア情報解析部による解析結果とに基づいて、前記ハードウェア要素群と前記ソフトウェア要素群との間の依存関係を分析する依存関係分析部と、前記依存関係分析部による分析結果を外部に提供する情報提供部と、を備えたハードウェア組込型ソフトウェアの開発支援システムが開示されている。

さらに、図１では、前記依存関係分析部による分析結果に基づいて、前記ハードウェア要素群のいずれか一つまたは複数のハードウェア要素を変更した場合に、その変更が前記ソフトウェア要素群に与える影響度を予測する影響度予測部を備え、前記情報提供部は、前記依存関係分析部による分析結果に代えて、または、この分析結果と共に、前記影響度予測部により予測された影響度を外部に提供するようになっている。

図１に基づいて、本実施形態を詳細に説明する。ストレージシステム１は、複数のハードウェア要素Ｅｈ１〜Ｅｈｎと、複数のソフトウェア要素Ｅｓ１１〜Ｅｓｍｎとを備えて構成されており、これらハードウェアとソフトウェアとは、複数のインターフェース（以下「Ｉ／Ｆ」）要素を介して接続されている。

ここで、ハードウェア要素としては、例えば、タイマ、バッファ、キャッシュメモリ、通信インターフェース、論理LSI等を挙げることができる。ソフトウェア要素としては、例えば、関数、変数、マクロ、テーブル等を挙げることができる。ハードウェアとソフトウェアとのインターフェース要素としては、例えば、ハードウェア要素を使用するためのレジスタ等を挙げることができる。

開発支援システム２は、ストレージシステム１からハードウェア要素及びソフトウェア要素に関する仕様情報をそれぞれ取得する（Ｓ１）。ここで、ハードウェア仕様情報及びソフトウェア仕様情報は、電子データまたは非電子データのいずれか又は双方の形式で取得することができる。

即ち、ハードウェア仕様情報やソフトウェア仕様情報は、例えば、紙媒体に印刷された仕様書として、または、ハードディスク装置等のデータ記録媒体に固定された電子データとして、それぞれ作成し、保存することができる。開発支援システム２は、これらの電子化または非電子化された仕様情報を取得する。なお、仕様情報が非電子化データである場合、開発支援システム２は、例えば、スキャナ装置やディジタルカメラ等の撮像装置を使用することにより、仕様情報を電子データに変換してから取り込むことができる。また、仕様情報の全部または一部をシステム管理者等が手動で入力する構成でもよい。

開発支援システム２は、ハードウェア仕様情報及びソフトウェア仕様情報をそれぞれ解析し、ハードウェア要素とソフトウェア要素との相互依存関係を解析する（Ｓ２）。この解析された相互依存情報は、データベース２Ａに記録される。相互依存関係情報とは、ハードウェア要素群とソフトウェア要素群との関係、即ち、各ソフトウェア要素が各ハードウェア要素をどの程度利用しているかを示す情報である。例えば、レジスタ等のインターフェース要素に着目することにより、各ハードウェア要素をそれぞれ直接的に使用する各ソフトウェア要素（Ｅｓ１１〜Ｅｓ１ｎ）を特定することができる。そして、各ソフトウェア要素同士の接続関係（階層構造）を解析することにより、どのソフトウェア要素がどのソフトウェア要素を介して特定のハードウェア要素を使用しているか等を把握することができる。

開発支援システム２は、相互依存情報とソフトウェア品質管理情報とに基づいて、ソフトウェアへの影響を示すソフトウェア影響情報を生成する（Ｓ３）。ソフトウェア影響情報は、あるハードウェア要素の変更が各ソフトウェア要素に与える影響の度合を示すものである。このソフトウェア影響情報は、データベース２Ｂに記録され、ハードウェア開発セクション３及びソフトウェア開発セクション４のそれぞれに提供される。ソフトウェア影響情報は、各セクション３，４により共有される。

ハードウェア開発セクション３では、ソフトウェア影響情報を参照することにより（Ｓ４）、現在計画中の仕様変更がソフトウェアに与える影響の範囲や大きさ等を事前に確認することができる。同様に、ソフトウェア開発セクション４でも、ソフトウェア影響情報を参照することにより（Ｓ５）、予定されているハードウェアの変更がソフトウェアに与える影響を事前に把握することができる。

各セクション３，４がそれぞれソフトウェア影響情報を参照することにより、各セクション３，４は共通の認識を有することができる。そして、この共通の認識を基礎として、各セクション３，４は互いに連絡を取り合うことができる（Ｓ６）。

ハードウェア開発セクション３は、その仕様変更がソフトウェアに与える影響を事前に確認した上で設計の手直し等を行うことができる（Ｓ７）。同様に、ソフトウェア開発セクション４は、ハードウェアの仕様変更により影響を受ける全てのソフトウェア要素について、手直し等することができる（Ｓ８）。

ソフトウェアの仕様変更に関する情報は、ソフトウェア品質管理情報としてデータベース２Ｃに記録される（Ｓ９）。ソフトウェア品質管理情報には、ソフトウェア要素の品質の履歴等を含めることができる。即ち、例えば、あるハードウェア要素の挙動に異常が検出された場合、そのハードウェア要素を制御するソフトウェア要素のバグが特定され、このバグに関する情報が記録される。

従って、ソフトウェア品質管理情報を参照することにより、過去に生じた不具合の頻度等を知ることができる。上述のように、開発支援システム２は、ソフトウェア品質管理情報と相互依存情報とに基づいて、ソフトウェア影響情報を生成するようになっている。各セクション３，４による開発の進行は、相互依存情報に反映され、ソフトウェア影響情報が更新される。

このように、本実施形態の開発支援システム２は、ソフトウェア仕様情報及びハードウェア仕様情報に基づいて、ソフトウェア要素群の構造及びハードウェア要素群の構造をそれぞれ解析する。そして、開発支援システム２は、両解析結果に基づいて、ソフトウェア要素群とハードウェア要素群との間の依存関係を示す依存関係情報を得る。さらに、開発支援システム２は、依存関係情報に基づいて、ハードウェア要素群のいずれか一つまたは複数のハードウェア要素を変更した場合に、その変更がソフトウェア要素群に与える影響度を予測するソフトウェア影響情報を生成し、この情報を各セクション３，４にそれぞれ提供する。

従って、本実施形態によれば、ハードウェア開発セクション３及びソフトウェア開発セクション４は、それぞれソフトウェア影響情報を参照して共通の認識を得ることができ、この共通の認識の上に立って相互に連絡を取り合いながら、それぞれの開発を進めることができる。これにより、本実施形態では、ハードウェア開発セクション３及びソフトウェア開発セクション４の両方が協調しながら、ストレージシステム１の開発を連携して進めることができる。このため、本実施形態では、従来技術のように、ソフトウェアへの影響を殆ど考慮していないハードウェアの仕様変更により、ソフトウェアの手直し作業や検証作業が発生してソフトウェア開発工数や開発期間が増加するのを未然に抑制することができる。本実施形態では、ストレージシステム開発の総工数を低減し、コストの増加を防止することができ、さらには、品質改善にも役立たせることができる。

また、既に開発済のストレージシステムのソフトウェア影響情報を参照することにより、新たに開発予定のストレージシステムの設計に活かすこともできる。即ち、例えば、ソフトウェアへの影響度が大きいハードウェア仕様については、より慎重により優先して検討し、ソフトウェアへの影響度の小さいハードウェア仕様については、柔軟に対応する等のように、新機種の開発計画を策定する際にも利用することができる。以下、他の図面を参照しながら、本実施形態をよく詳しく説明する。

図２は、ストレージ装置のソフトウェア開発支援システム１００の全体像を示す構成説明図である。この開発支援システム１００は、例えば、ソフトウェア仕様情報解析部１１０と、ハードウェア仕様情報解析部１２０と、品質管理情報解析部１３０と、ハードウェア依存度分析部１４０と、ソース影響度分析部１５０と、情報提供部１６０等を備えて構成することができる。

また、開発支援システム１００は、ソース構造解析データ１１１と、ソフトウェア−ハードウェア間インターフェース解析データ（以下、「インターフェース解析データ」とも呼ぶ）１２１と、プログラム変更管理情報１３１と、ハードウェア依存度情報１４１と、ソフトウェア影響度情報１５１とをそれぞれ管理することができる。

開発支援システム１００は、例えば、サーバマシン等のコンピュータ装置上に実現することができ、ソフトウェア開発セクションの端末３１０及びハードウェア開発セクションの端末３２０とそれぞれ通信可能に接続されている。開発支援システム１００は、各端末３１０，３２０に対して、それぞれ情報を提供することができる。各セクションでは、開発支援システム１００から得た情報に基づいて、ソフトウェア及びハードウェアの仕様を変更することができる。

開発支援システム１００の各機能をそれぞれ簡単に説明する。各機能の詳細は、別図と共に後述する。まず、開発支援システム１００には、少なくとも３種類の情報Ｄｓ，Ｄｈ，Ｄｑをそれぞれ入力することができる。ソフトウェア仕様情報Ｄｓは、ソースファイル（ソースプログラム）の構成、即ち、ソースコード、関数やマクロ等の定義等を示す情報である。ハードウェア仕様情報Ｄｈは、ストレージ装置を構成するハードウェア要素、特に、コンピュータ制御される要素の仕様を示す情報である。品質管理情報Ｄｑは、ソースファイルの品質（障害対策の履歴等）を示す情報である。

これらの情報Ｄｓ，Ｄｈ，Ｄｑは、文書ファイル等の電子データとして作成されている場合もあるし、紙媒体に印刷された非電子データの場合もある。また、一部が電子化され、他の一部が紙媒体に印刷されている場合もある。電子化されていないデータの場合、例えば、スキャナ装置やディジタルカメラ等を用いて電子化し、開発支援システム１００に入力することができる。

ソフトウェア仕様情報解析部１１０は、ソフトウェア仕様情報Ｄｓに基づいて、ストレージ装置のソフトウェア構造を解析するものである。ソフトウェア仕様情報解析部１１０による解析結果は、ソース構造解析データ１１１として管理される。ソース構造解析データ１１１には、例えば、ソースファイルに含まれている関数、変数、マクロ、テーブル等の各エンティティと、これら各エンティティ間の相互参照状態等の情報を含めることができる。

ハードウェア仕様情報解析部１２０は、ハードウェア仕様情報Ｄｈに基づいて、ストレージ装置のハードウェア構造を解析するものである。ハードウェア仕様情報解析部１２０は、例えば、ハードウェアとソフトウェアとを繋ぐ外部レジスタについて調査することにより、ハードウェアの構造を解析する。この解析結果は、インターフェース解析データ１２１として管理される。インターフェース解析データ１２１には、例えば、各外部レジスタの番号、その名称（用途）、各制御ビットの定義、種別等を含めることができる。

品質管理情報解析部１３０は、品質管理情報Ｄｑに基づいて、ソフトウェアの品質、即ち例えば、プログラムの変更履歴を解析する。この解析結果は、プログラム変更管理情報１３１として管理される。プログラム変更管理情報１３１には、例えば、そのプログラムに生じた過去の問題点、その問題点解決のために修正された箇所及びその内容、そのプログラムが関係するハードウェア名等を含めることができる。

ハードウェア依存度分析部１４０は、ソース構造解析データ１１１及びインターフェース解析データ１２１に基づいて、ソフトウェアとハードウェアとの依存関係を分析するものである。即ち、ソフトウェアとハードウェアとのインターフェースに関する構造と、ソフトウェアの内部構造とを互いに突き合わせて検討することにより、どのソフトウェア要素（関数、マクロ、変数等）がどのハードウェア要素を利用しているか等を把握することができる。この分析結果は、ハードウェア依存度情報１４１として管理される。ハードウェア依存度情報１４１には、例えば、各ハードウェア要素に関連する一つまたは複数のソフトウェア要素の依存度合を数値化して含めることができる。

ソース影響度分析部１５０は、ソース構造解析データ１１１と、ハードウェア依存度情報１４１と、プログラム変更管理情報１３１とに基づいて、ハードウェア要素の仕様変更がソースファイルに与える影響度を分析するものである。この分析結果は、ソフトウェア影響度情報１５１として管理される。

情報提供部１６０は、ソフトウェア影響度情報１５１を各端末３１０，３２０にそれぞれ提供するためのものである。情報提供部１６０は、例えば、ウェブサーバ機能を備えて構成することができる。この場合、各端末３１０，３２０は、ウェブヴラウザを用いてソフトウェア影響度情報１５１を参照することができる。なお、ソフトウェア影響度情報１５１を提供する場合に限らず、ソフトウェア影響度情報１５１を生成するために用いられたハードウェア依存度情報１４１や他の解析データ１１１，１２１，１３１を各端末３１０，３２０にそれぞれ提供可能な構成でもよい。

ハードウェア開発セクション及びソフトウェア開発セクションは、ソフトウェア影響度情報１５１を参照して、ハードウェアの仕様変更がソフトウェアに与える影響を事前に把握し、そのハードウェアの仕様変更について事前に協議することができる。そして、ハードウェア開発セクションでは、例えば、ソフトウェアの開発も含めた全体の開発工数や期間及びコストを考慮して、ハードウェアの仕様変更を決定することができる。また、ソフトウェア開発セクションでは、そのハードウェアの仕様変更によって影響を受ける全てのソースファイルを事前に把握することができ、これらのソースファイルの修正作業を漏れなく行うことができる。

開発支援システム１００によって開発が支援されるシステム製品としては、ストレージ装置１０を挙げることができる。図３，図４を参照して、ストレージ装置１０の構成を説明する。

図３は、ストレージ装置１０の外観構成の一例を示す概略斜視図である。ストレージ装置１０は、例えば、基本筐体１１と複数の増設筐体１２とから構成可能である。基本筐体１１は、ストレージ装置１０の最小構成単位であり、記憶機能及び制御機能の両方を備えている。増設筐体１２は、ストレージ装置１０のオプションであり、基本筐体１１の有する制御機能により制御される。例えば、最大４個の増設筐体１２を基本筐体１１に接続可能である。

基本筐体１１には、複数の制御パッケージ１３と、複数の電源ユニット１４と、複数のバッテリユニット１５と、複数のディスクドライブ２６とがそれぞれ着脱可能に設けられている。増設筐体１２には、複数のディスクドライブ２６と、複数の電源ユニット１４及び複数のバッテリユニット１５が着脱可能に設けられている。また、基本筐体１１及び各増設筐体１２には、複数の冷却ファン１６もそれぞれ設けられている。

制御パッケージ１３は、後述するチャネルアダプタ（以下、CHA）２１、ディスクアダプタ（以下、DKA）２２及びキャッシュメモリ２３等をそれぞれ実現するためのモジュールである。即ち、基本筐体１１には、複数のCHAパッケージ、複数のDKAパッケージ及び１つ以上のメモリパッケージがそれぞれ着脱可能に設けられ、パッケージ単位で交換可能となっている。

図４は、ストレージ装置１０の全体概要を示すブロック図である。ストレージ装置１０は、通信ネットワークＣＮ１を介して、複数のホストコンピュータ（以下、「ホスト」）３０と双方向通信可能にそれぞれ接続可能である。

通信ネットワークＣＮ１としては、例えば、LAN（Local Area Network）、SAN（Storage Area Network）、インターネットあるいは専用回線等を挙げることができる。LANを用いる場合、ホスト３０とストレージ装置１０との間のデータ転送は、TCP/IPに従って行われる。SANを用いる場合、ホスト３０とストレージ装置１０とは、ファイバチャネルプロトコルに従ってデータ転送を行う。ホスト３０がメインフレームの場合、例えば、FICON（Fibre Connection：登録商標）、ESCON（Enterprise System Connection：登録商標）、ACONARC（Advanced Connection Architecture：登録商標）、FIBARC（Fibre Connection Architecture：登録商標）等の通信プロトコルに従ってデータ転送が行われる。

各ホスト３０は、例えば、サーバ、パーソナルコンピュータ、ワークステーション、メインフレーム等として実現されるものである。例えば、各ホスト３０は、図外に位置する複数のクライアント端末と別の通信ネットワークを介して接続されている。各ホスト３０は、例えば、各クライアント端末からの要求に応じて、ストレージ装置１０にデータの読み書きを行うことにより、各クライアント端末へのサービスを提供する。

各CHA２１は、各ホスト３０との間のデータ転送を制御するもので、複数の通信ポート２１Ａを備えている。CHA２１は、例えば、オープン系用CHA、メインフレーム系用CHA等のように、ホスト３０の種類に応じて用意することができる。各CHA２１は、それぞれに接続されたホスト３０から、データの読み書きを要求するコマンド及びデータを受信し、ホスト３０から受信したコマンドに従って動作する。各CHA２１は、複数のホスト３０からのI/O要求をそれぞれ個別に制御することができる。

DKA２２の動作も含めて先に説明すると、CHA２１は、ホスト３０からリードコマンドを受信すると、このリードコマンドを共有メモリ２４に記憶させる。DKA２２は、共有メモリ２４を随時参照しており、未処理のリードコマンドを発見すると、ディスクドライブ２６からデータを読み出して、キャッシュメモリ２３に記憶させる。CHA２１は、キャッシュメモリ２３に移されたデータを読み出し、ホスト３０に送信する。

一方、CHA２１は、ホスト３０からライトコマンドを受信すると、このライトコマンドを共有メモリ２４に記憶させる。また、CHA２１は、受信したデータをキャッシュメモリ２３に記憶させる。CHA２１は、キャッシュメモリ２３にデータを記憶させた後、ホスト３０に書込み完了を報告する。DKA２２は、共有メモリ２４に記憶されたライトコマンドに従って、キャッシュメモリ２３に記憶されたデータを読出し、所定のディスクドライブ２６に記憶させる。

各DKA２２は、ストレージ装置１０内に複数設けることができる。各DKA２２は、各ディスクドライブ２６との間のデータ通信をそれぞれ制御する。各DKA２２と各ディスクドライブ２６とは、例えば、SAN等の通信ネットワークＣＮ４を介して接続されており、ファイバチャネルプロトコルに従ってブロック単位のデータ転送を行う。各DKA２２は、ディスクドライブ２６の状態を随時監視しており、この監視結果は、内部ネットワークＣＮ３を介して、SVP２８に送信される。

各CHA２１及び各DKA２２は、例えば、プロセッサやメモリ等が実装されたプリント基板と、メモリに格納された制御プログラムとをそれぞれ備えており、これらのハードウェアとソフトウェアとの協働作業によって、それぞれ所定の機能を実現するようになっている。各CHA２１，各DKA２２にそれぞれ設けられる制御プログラムは、ストレージ装置１０の全体動作を制御するものである。なお、CHA２１とDKA２２の詳細は、さらに後述する。

キャッシュメモリ２３は、例えば、データ等を記憶するものである。キャッシュメモリ２３は、例えば不揮発メモリから構成される。共有メモリ（あるいは制御メモリ）２４は、例えば不揮発メモリから構成される。共有メモリ２４には、例えば、制御情報や管理情報等が記憶される。これらの制御情報等の情報は、複数の共有メモリ２４により多重管理することができる。共有メモリ２４及びキャッシュメモリ２３は、それぞれ複数個設けることができる。また、同一のメモリ基板にキャッシュメモリ２３と共有メモリ２４とを混在させて実装することもできる。あるいは、メモリの一部をキャッシュ領域として使用し、他の一部を制御領域として使用することもできる。

スイッチ部２５は、各CHA２１と、各DKA２２と、キャッシュメモリ２３と、共有メモリ２４とをそれぞれ接続するものである。これにより、全てのCHA２１，DKA２２は、キャッシュメモリ２３及び共有メモリ２４にそれぞれアクセス可能である。スイッチ部２５は、例えば超高速クロスバスイッチ等として構成することができる。

ストレージ装置１０は、複数のディスクドライブ２６を実装することができる。各ディスクドライブ２６は、例えば、ハードディスクドライブ（HDD）、半導体メモリ装置、光ディスク装置、光磁気ディスク装置及びこれらの均等物として実現可能である。なお、ディスクドライブ２６にHDDを使用する場合、例えば、FC（Fibre Channel）ディスク、SATA（Serial AT Attachment）ディスク、SCSI（Small Computer System Interface）ディスク等のHDDを使用することができる。また、複数種類のHDDをそれぞれ使用することもできる。

ディスクドライブ２６は、物理的な記憶デバイスである。RAID構成等によっても相違するが、例えば、４個１組のディスクドライブ２６が提供する物理的な記憶領域上には、仮想的な論理領域であるRAIDグループ（パリティグループとも呼ばれる）２７が構築される。さらに、RAIDグループ２７上には、論理デバイス（論理ボリュームとも呼ばれる）を１つ以上設定可能である。この論理デバイスをLUN (Logical Unit Number) に対応付けることにより、オープン系のホスト３０により認識される。メインフレーム系ホストの場合は、論理デバイスを直接認識する。

なお、ストレージ装置１０により使用される記憶資源は、全てストレージ装置１０内に設けられている必要はない。ストレージ装置１０は、ストレージ装置１０の外部に存在する記憶資源を、あたかも自己の記憶資源であるかのように取り込んで、利用することもできる。

サービスプロセッサ（SVP）２８は、LAN等の内部ネットワークＣＮ３を介して、各CHA２１及び各DKA２２とそれぞれ接続されている。また、SVP２８は、LAN等の通信ネットワークＣＮ２を介して、複数の管理端末３１に接続可能である。SVP２８は、ストレージ装置１０内部の各種状態を収集し、管理端末３１に提供する。

次に、図５は、CHA２１及びDKA２２の要部を概略的に示すブロック図である。CHA２１について先に説明する。CHA２１は、例えば、ポート制御部２１１と、メインプロセッサ２１２と、ローカルメモリ２１３と、データ転送アダプタ（DTA）２１４と、マイクロプログラムアダプタ（MPA）２１５とを備えて構成することができる。

ポート制御部２１１は、プロセッサ２１６を備えており、所定の通信プロトコルに従って、ホスト３０とのデータ通信を行うものである。メインプロセッサ２１２は、CHA２１の作動を制御するもので、複数のハードウェアレジスタ２１７を備えている。メインプロセッサ２１２には、ローカルメモリ２１３が接続されている。ローカルメモリ２１３には、例えば、共有メモリ２４に格納されている制御用情報のうち、そのCHA２１で使用する制御用情報等がコピーされている。

DTA２１４は、キャッシュメモリ２３との間のデータ転送を行う。MPA２１５は、共有メモリ２４との間のデータ転送を行う。メインプロセッサ２１２は、MPA２１５を介して、ホスト３０から受信したコマンドを共有メモリ２４に格納させる。メインプロセッサ２１２は、DTA２１４を介して、ホスト３０から受信したライトデータをキャッシュメモリ２３に格納させる。また、メインプロセッサ２１２は、DTA２１４を介してキャッシュメモリ２３からデータを読出す。この読み出されたデータは、ポート制御部２１１を介して、ホスト３０に送信される。

CHA２１と同様に、DKA２２も、例えば、ポート制御部２２１と、メインプロセッサ２２２と、ローカルメモリ２２３と、DTA２２４と、MPA２２５とを備えて構成することができる。

ポート制御部２２１は、ディスクドライブ２６との間のデータ転送を制御するもので、プロセッサ２２６を備えることができる。メインプロセッサ２２２は、DKA２２の作動を制御するもので、複数のハードウェアレジスタ２２７を備えることができる。ローカルメモリ２２３には、例えば、DKA２２の作動を制御するために必要な制御用情報等を記憶させることができる。また、DTA２２４は、キャッシュメモリ２３との間のデータ転送を行う。MPA２２５は、共有メモリ２４との間のデータ転送を行う。

次に、開発支援システム１００の各機能の詳細を説明する。図６は、図２中のソフトウェア仕様情報解析部１１０により実行されるソースプログラム解析処理（図中では、ソースプログラムまたはソースファイルを「ソース」と略記する場合がある）の概略を示すフローチャートである。

開発支援システム１００（以下、「システム１００」とも呼ぶ）は、所定の制御または所定のプロジェクトに含まれる一連のソースファイル群のうち、解析対象のソースファイルを一つ選んでオープンする（Ｓ１１）。システム１００は、選択されたソースファイルのプリプロセッシングを実行する（Ｓ１２）。このプリプロセッシングでは、例えば、デバッグコードをコンパイルするか否か等のコンパイルオプションを反映させ、また、マクロを解決等する。図７を参照する。ソフトウェア仕様情報Ｄｓとしてのソースファイルをプリプロセッシングすることにより、情報がインクルードされ、ソースコードが展開され、マクロが解決等される。これにより、コンパイル前の中間ファイルが生成される。

図６に戻る。次に、システム１００は、このプリプロセッシングされたコード（展開系と呼ぶ）が、前回の解析時と比較して変化しているか否かを判定する（Ｓ１３）。展開系に差分があるときは（S13：YES）、ソースファイルが修正されている場合なので、ソースファイルの内部解析を行う（Ｓ１４）。この内部解析では、例えば、そのソースファイルに含まれている関数エンティティの抽出、各関数の内部で使用されている変数の抽出、そのソースファイルで使用されている各テーブルの抽出、そのソースファイルに含まれているマクロエンティティの抽出等を行う。一方、プリプロセッシング後のコードが前回と変化していない場合（S13：NO）、Ｓ１４をスキップする。

次に、システム１００は、ソースファイル間の解析を行う（Ｓ１５）。このソース間解析処理では、例えば、各エンティティ間における相互参照の状況を把握する。即ち、Ｓ１５では、どの関数がどの関数を参照し、または参照されているかを示す関数間のクロスリファレンス情報を検出する。また、Ｓ１５では、変数（マクロ）と関数との間のクロスリファレンス情報を検出する。さらに、Ｓ１５では、マクロ間のクロスリファレンス情報を検出する。

次に、システム１００は、メトリックス情報の解析を行う（Ｓ１６）。このメトリックス情報解析では、例えば、親関数（Fan-IN）の数、子関数（Fan-OUT）の数、プログラムの複雑度情報等を解析する。プログラムの複雑度情報を得る場合、例えば、McCabe's metrics/Halstead's metrics等の手法を用いることができる。図８には、親関数と子関数との関係が示されている。ある関数Ｆ４に着目する。この関数Ｆ４には、関数Ｆ２と関数Ｆ３の演算結果がそれぞれ直接入力される（Fan-IN）。関数Ｆ１の演算結果は、関数Ｆ２を介して間接的に関数Ｆ４に入力される（Transitive Fan-IN）。関数４の演算結果は、関数Ｆ５に直接出力される（Fan-OUT）。また、関数Ｆ４の演算結果は、関数Ｆ５を介して間接的に関数Ｆ６に出力される（Transitive Fan-OUT）。このように、Ｓ１６では、各関数間の親子関係を把握する。

図６に戻る。システム１００は、解析結果をソースメトリックス情報テーブル１１１Ａにエントリさせる（Ｓ１７）。なお、Ｓ１７では、上記の解析結果を、ソースファイル単位や関数単位で集計し、登録する。

そして、システム１００は、未解析のソースファイルが存在するか否かを判定する（Ｓ１８）。未解析のソースファイルが存在する場合（S18：YES）、システム１００は、次のソースファイルに移動し（Ｓ１９）、上述したＳ１１〜Ｓ１７の処理を繰り返す。解析すべき全てのソースファイルを解析した場合（S18：NO）、システム１００は、ソースメトリックス情報テーブル１１１Ｂに、制御単位またはプロジェクト単位で集計し、登録させる（Ｓ２０）。

図９は、Ｓ１７で生成されるソースメトリックス情報テーブル１１１Ａの一例を示す説明図である。図９は、各関数単位の集計結果を示す。このソースメトリックス情報テーブル１１１Ａは、例えば、各レコードのインデックス番号と、関数名と、その関数のステップ数と、親関数の数（Fan-IN）と、子関数の数（Fan-OUT）と、間接的な親関数の数（Transitive Fan-IN）と、間接的な子関数の数（Transitive Fan-OUT）と、経路の複雑度情報とを、それぞれ対応づけることにより構成可能である。

図１０は、Ｓ２０で生成されるソースメトリックス情報テーブル１１１Ｂの一例を示す説明図である。図１０は、制御単位での集計結果を示す。従って、テーブル１１１Ｂでは、制御名単位でそれぞれの解析結果が集計されている。

図１１は、図２に示すハードウェア仕様情報解析部１２０により実行されるハードウェアドキュメント情報解析処理の概要を示すフローチャートである。ハードウェア仕様情報Ｄｈとして、ハードウェア仕様を記述したハードウェアドキュメントが用いられる。

先に図１２を参照する。図１２は、ハードウェア仕様情報Ｄｈの一例を示す説明図であって、ハードウェア仕様情報は各ハードウェア毎にそれぞれ用意されている。そして、これら各ハードウェア毎の仕様情報は、例えば、そのハードウェアに属する各レジスタのアドレスと、各レジスタの名称と、各レジスタの機能名称と、各レジスタの各制御ビットの定義情報と、各レジスタのセット条件及びリセット条件とをそれぞれ対応付けることにより構成される。

図１１に戻る。システム１００は、このハードウェアドキュメントからハードウェア仕様情報を取得する（Ｓ３１）。即ち、ハードウェアドキュメントに記述された全ての情報を取得する必要はなく、例えば、ハードウェアとソフトウェアとのインターフェースとなる外部レジスタ群についての情報を取得すれば足りる。但し、外部レジスタに関する情報に限らず、他のハードウェア情報を利用してもよい。

システム１００は、取得したハードウェア仕様情報に基づいて、インターフェース仕様情報を抽出する（Ｓ３２）。インターフェース仕様情報としては、例えば、レジスタ番号（アドレス）、レジスタ名（ニーモニック）、レジスタの機能名称、レジスタの各制御ビットの定義、レジスタのセット条件及びリセット条件等を挙げることができる。レジスタの機能名称としては、例えば、「データ送受信転送状態レジスタ」、「チャネル側送信バッファ」、「内部クロックレジスタ」等を挙げることができる。

システム１００は、レジスタ群を分類する（Ｓ３３）。即ち、システム１００は、レジスタの機能名称に基づいて、レジスタ群を複数のグループに分類する。即ち、例えば、各グループ毎にキーワードを一つまたは複数予め定義しておき、このキーワードに一致または類似する機能名称を有するレジスタを発見した場合、そのレジスタをそのグループに分類する。

例えば、第１グループK01は、「対リソース データ転送系」と定義される。この第１グループには、キャッシュメモリ２３や共有メモリ２４等の各リソース別に、それぞれのリソースへのデータ送信に使用するレジスタと、各リソースからのデータ受信に使用するレジスタとが所属する。第２グループK02は、「対リソース データ転送制御系」と定義される。この第２グループには、送受信別に、データ転送の制御に用いるレジスタや、データ転送のステータスを示すレジスタ、転送エラーを示すレジスタ等が所属する。

同様に、第３グループK03は「データバッファ系(送受信別)」、第４グループK04は「データバッファ制御系」、第５グループK05は「内部データ転送路(path/bus)制御系」、第６グループK06は「外部I/F状態監視系」、第７グループK07は「デバイス監視系」、第８グループK08は「エラー系（データパリティエラーや電気信号エラー等）」、第９グループK09は「タイマ監視系」、第１０グループK10は「システムタイマ系」として、それぞれ定義される。なお、以上のレジスタ分類は一例であって、本発明はこれに限定されない。

システム１００は、各レジスタの分類を完了すると、この分類結果をハードウェアＩ／Ｆ情報テーブル（ソフトウェア−ハードウェア間Ｉ／Ｆ解析データ）１２１にエントリさせる（Ｓ３４）。そして、システム１００は、未解析のハードウェア仕様情報が存在するか否かを判定する（Ｓ３５）。未解析のハードウェア仕様情報が存在する場合（S35：YES）、システム１００は、次のハードウェア仕様情報に移動して（Ｓ３６）、上述したＳ３１〜３４の処理を繰り返す。そして、解析すべき全てのハードウェア仕様情報の解析が完了した場合（S35：NO）、システム１００は、本処理を終了する。

図１３は、ハードウェアＩ／Ｆ情報テーブル１２１の一例を示す説明図である。このハードウェアＩ／Ｆ情報テーブル１２１は、図２中では、ソフトウェア−ハードウェア間Ｉ／Ｆ解析データ１２１として示されている。

ハードウェアＩ／Ｆ情報テーブル１２１は、例えば、インデックス番号と、そのレジスタが所属するハードウェアの名称と、レジスタＩＤまたはアドレスと、そのレジスタ名と、そのレジスタの機能名称または簡単な説明と、そのレジスタの属するグループ名とを、それぞれ対応付けることにより構成することができる。

図１４は、図２中の品質管理情報解析部１３０により実行される品質管理情報解析処理の概要を示すフローチャートである。システム１００は、品質管理情報Ｄｑとして、問題点管理票Ｄｑ１を取得する（Ｓ４１）。そして、システム１００は、取得した問題点管理票Ｄｑ１に関連付けられているプログラム変更管理票Ｄｑ２を探索する（Ｓ４２）。

ここで、図１５を参照する。図１５には、問題点管理票Ｄｑ１及びプログラム変更管理票Ｄｑ２の一例が示されている。ストレージ装置１０に何らかの不具合が発生すると、問題点管理票Ｄｑ１が生成される。この問題点管理票Ｄｑ１は、例えば、問題点毎に与えられる問題点管理番号と、その問題点の名称と、その問題点の発生日と、その問題点の重要度と、その問題点の対応区分と、その問題点に対応するプログラム変更管理票Ｄｑ２の番号とを、それぞれ対応付けることにより構成することができる。「対応区分」としては、例えば、「仕様違反」や「ハードウェア対応」等が挙げられる。「ハードウェア対応」とは、主として、ハードウェア不良や仕様変更に伴い、ソフトウェア（特に、ハードウェア制御プログラム）側で対応し修正したことを示す。

プログラム変更管理票Ｄｑ２は、問題点を解消するためにソースプログラムを修正した場合に生成され、問題点管理票Ｄｑ１に関連付けられて管理される。プログラム変更管理票Ｄｑ２には、例えば、件名と、不具合の生じた製品のバージョン番号と、修正後のバージョン番号と、発生した不具合の内容（不具合発生時の構成、不具合の発生条件、不具合の結果等）と、不具合を検索するために関連付けられるキーワードと、不具合の原因と、原因を検索するために関連付けられるキーワードと、不具合を解消するために実施された対策と、その対策を検索するために関連付けられるキーワードとが含まれている。

さらに、例えば、プログラム変更管理票Ｄｑ２には、その下側に示すように、不具合を解消するために変更されたソースファイルの名称と、変更された関数の名称と、変更されたテーブルの名称と、変更されたマクロの名称とが含まれている。

なお、プログラム変更管理票Ｄｑ２には、そのプログラム変更に係る制御名とそのプログラム変更に係るハードウェア名とが含められる。例えば、プログラム変更管理票Ｄｑ２に与えられる名称の中に、制御名とハードウェア名とを特定するための情報を含ませておくことにより、そのプログラム変更管理票がどの制御やどのハードウェアに関するものであるかを容易に管理することができる。

図１４に戻る。システム１００は、Ｓ４１で取得した問題点管理票に関連付けられているプログラム変更管理票が存在するか否かを判定する（Ｓ４３）。そして、その問題点管理票にプログラム変更管理票が関連付けられている場合（S43：YES）、システム１００は、その問題点管理票の「対応区分」が「ハードウェア対応」であるか否かを判定する（Ｓ４４）。

「ハードウェア対応」に関する問題点管理票である場合（S44：YES）、システム１００は、この問題点管理票から「重要度」を抽出する（Ｓ４５）。また、システム１００は、この問題点管理票に対応付けられている一つまたは複数のプログラム変更管理票から、修正されたプログラム制御名や、修正されたソースファイル名、修正された関数名、修正されたテーブル名、修正されたマクロ名及びこれらの修正が施されたハードウェアの名称をそれぞれ取得する（Ｓ４６）。システム１００は、これらの取得した各情報を、ハードウェア対応プログラム変更案件テーブル１３１Ａにエントリさせる。

ここで、図１６を参照する。図１６は、ハードウェア対応プログラム変更案件テーブル（以下、「変更案件テーブル」とも呼ぶ）１３１Ａの一例を示す説明図である。この変更案件テーブル１３１Ａは、例えば、インデックス番号と、修正に係るハードウェアのプログラム変更管理票番号（Ｐ番）と、問題点管理票番号（Ｍ番）と、その修正の原因となった不具合の重要度と、修正されたプログラム制御名と、修正されたファイル名と、修正された関数名と、その修正の対象となるハードウェア名とを対応付けることにより構成される。なお、このほかに、修正されたマクロ名やテーブル名を追加することもできる。

このように、システム１００は、その問題点管理票がハードウェアに関連する場合、その問題点管理票に対応付けられている全てのプログラム変更管理票から、修正されたソースファイルや関数等の情報を抽出し、変更案件テーブル１３１Ａに登録する。その問題点管理票にプログラム変更管理票が一つも対応付けられていない場合（S43：NO）、システム１００は、Ｓ４４〜Ｓ４７をスキップする。

そして、システム１００は、未解析の問題点管理票が残っているか否かを判定し（Ｓ４８）、未解析の問題点管理票が存在する場合（S48：YES）、次の問題点管理票に移動して（Ｓ４９）、上述したＳ４１〜Ｓ４７の処理を繰り返す。

解析すべき全ての問題点管理票を解析した場合（S48：NO）、システム１００は、ハードウェア対応案件統計テーブル（以下、「案件統計テーブル」とも呼ぶ）１３１Ｂを生成し（Ｓ５０）、本処理を終了する。

図１７は、ハードウェア対応案件統計テーブル１３１Ｂの一例を示す説明図である。この案件統計テーブル１３１Ｂは、例えば、インデックス番号と、関数名と、その関数に関連する不具合の重要度別の発生件数とを対応付けることにより構成可能である。

図１８は、図２中のハードウェア依存度分析部１４０により実行されるハードウェア依存度分析処理の概要を示すフローチャートである。システム１００は、外部レジスタを起点とする各関数及び各マクロ間のクロスリファレンス階層を検出する（Ｓ６１）。次に、システム１００は、クロスリファレンス階層に基づいて、外部レジスタと各関数及び各マクロとの論理的な距離（Depth）をそれぞれ求める（Ｓ６２）。

ここで、図１９に基づいて、クロスリファレンス階層と距離（Depth）との関係を説明する。図１９の上部左側に示すように、外部レジスタを起点とし、その外部レジスタを使用する関数やマクロ（マクロ内の関数。以下両者をまとめて「関数」と呼ぶ場合がある）の繋がり方を示すものが、クロスリファレンス階層図である。例えば、図に示す例では、外部レジスタは関数１によって直接的に使用されており、これらの外部レジスタ及び関数１は、マクロ内に存在している。

そして、関数１の演算結果は関数２によって使用され、関数２の演算結果は関数３及び関数４によってそれぞれ使用されている。また、関数３の演算結果は関数５によって使用されている。

ここで、本実施例では、外部レジスタと各関数との間の論理的な距離、換言すれば、外部レジスタとの親密度をDepthという単位で考える。外部レジスタから遠ざかるほど、Depthの値が大きくなるように、設定されている。例えば、関数１は、外部レジスタを直接使用するため、そのDepthは「１」となる。関数２は、関数１を介して外部レジスタを使用するため、そのDepthは「２」となる。以下同様に、外部レジスタからの論理的な距離が１段階ずつ遠ざかるに従って、Depthの値も１つずつ増加する。

図１９の下側に示すように、Depthの値とハードウェアへの依存度とは、逆比例の関係に立つ。Depthの値が小さければ小さいほど、外部レジスタへの親密度、接近度合が高まり、その結果、その外部レジスタに関連するハードウェアへの依存度が増大する。逆に、Depthの値が大きくなると、その外部レジスタを間接的に使用することとなり、ハードウェアへの依存度が低下する。外部レジスタからの論理的な距離が遠くなればなるほど、その外部レジスタに関連するハードウェアの仕様が変更された場合でも、その変更による影響が途中で吸収されてしまい、影響を受けにくくなる。

図１８に戻る。システム１００は、ある外部レジスタについて、そのクロスリファレンス階層及びDepthをそれぞれ求めた後（Ｓ６１，Ｓ６２）、次に解析すべき外部レジスタが存在するか否かを判定する（Ｓ６３）。システム１００は、全ての外部レジスタについてクロスリファレンス階層及びDepthをそれぞれ求めるまで、Ｓ６１及びＳ６２の処理を繰り返す（S63：YES）。全ての外部レジスタについて解析を終了した場合（S63：NO）、システム１００は、各関数がその外部レジスタにアクセスする回数をそれぞれ算出する（Ｓ６４）。

システム１００は、Depthに基づいて、各関数毎にそれぞれ第１ハードウェア依存度指標HD１を算出する（Ｓ６５）。図１９に示したように、Depthの値とハードウェアへの依存度とは逆比例の関係にある。そこで、システム１００は、Depthの値が小さくなるほど第１ハードウェア依存度指標HD１の値が大きくなるように、第１ハードウェア依存度指標HD１を算出する。例えば、Depth＝１の場合はHD１＝１０、Depth＝２の場合はHD１＝９、Depth＝３の場合はHD１＝８等のように、システム１００は、０〜１０の自然数の範囲内で第１ハードウェア依存度指標HD１を設定することができる。

次に、システム１００は、各関数が外部レジスタにアクセスする回数に基づいて、第２ハードウェア依存度指標HD２をそれぞれ算出する（Ｓ６６）。この第２ハードウェア依存度指標HD２は、例えば、その関数の総ステップ数に占める外部レジスタへのアクセス行数（HD２＝外部レジスタにアクセスする行の総数／その関数の総ステップ数）によって算出することができる。

図２０は、第２ハードウェア依存度指標HD２を算出する様子を模式的に示す説明図である。各関数は、それぞれ複数の行（ステップ）から構成されており、必要な箇所で必要な外部レジスタを呼び出している。

そこで、その関数内において、外部レジスタにアクセスする行の数（アクセス回数）を各外部レジスタ毎にそれぞれ算出すると共に、その関数の総ステップ数を求める。そして、各外部レジスタへアクセスする行数を総ステップ数でそれぞれ除算した値を第２ハードウェア依存度指標HD２として用いる。割り切れない場合は、四捨五入や丸めによって整数とすることができる。このように、その関数内で外部レジスタを呼び出す頻度が大きければ大きいほど、その外部レジスタに関連するハードウェアへの依存度が高いと考えることができる。

図１８に戻る。システム１００は、各ハードウェア依存度指標HD１，HD２をそれぞれ求めた後（Ｓ６５，Ｓ６６）、これら各ハードウェア依存度指標HD１，HD２に基づいて、第３ハードウェア依存度指標HD３を算出する（Ｓ６７）。この第３ハードウェア依存度指標HD３は、例えば、各ハードウェア依存度指標HD1とHD２とを乗算することにより求めることができる（HD３＝HD1×HD２）。なお、HD１，HD２のいずれかを重視する場合は、重み付けすることもできる。

そして、システム１００は、第３ハードウェア依存度指標HD３をハードウェア依存度統計テーブル１４１にエントリさせる（Ｓ６８）。このハードウェア依存度統計テーブル１４１は、図２中では、「ハードウェア依存度情報」として示されている。

図２１は、ハードウェア依存度統計テーブル１４１の一例を示す説明図である。このテーブル１４１は、例えば、関数名と、ハードウェア種別と、ハードウェア分類と、ハードウェア依存度（HD３）とをそれぞれ対応付けることにより構成可能である。ハードウェア種別とは、その関数が外部レジスタを介して使用するハードウェアの種別を意味し、ハードウェア分類とは、その外部レジスタの分類先グループ名を示す。このようにして、各関数毎に、どのハードウェアにどの程度依存しているかを一覧形式で把握できる。

図２２は、図２中のソース影響度分析部１５０により実行されるソフトウェア影響度分析処理の概要を示すフローチャートである。まず、システム１００は、ソフトウェア影響度ESの値を初期化する（Ｓ７１）。

次に、システム１００は、以下に述べるように、複数種類の影響度ファクタをそれぞれ求め（Ｓ７２〜Ｓ７４）、各影響度ファクタの値を重み付けして（Ｓ７５）、ソフトウェア影響度ESを算出する（Ｓ７６）。

第１の影響度ファクタとして、システム１００は、各ハードウェアに関連する関数をそれぞれ抽出し、抽出された各関数のハードウェア依存度指標（HD３）を０〜１０の値に正規化する（Ｓ７２）。

第２の影響度ファクタとして、システム１００は、各関数の追跡複雑度を０〜１０の値にランク付けする（Ｓ７３）。

第３の影響度ファクタとして、システム１００は、各関数のハードウェア対応案件量（図１７参照）を０〜１０の値にランク付けする（Ｓ７４）。

そして、システム１００は、各影響度ファクタで得られたランクを重み付けして総和を求め、この総和を０〜１０の値で正規化する（Ｓ７５）。この総和を正規化して得られた総合ランクは、そのハードウェアがその関数に与える影響度を示す。

システム１００は、ソフトウェア影響度ESにＳ７５で得られた影響度を加算する（Ｓ７６）。そして、システム１００は、現在分析中のハードウェアについてソフトウェア影響度ESを未算出の関数が存在するか否かを判定する（Ｓ７７）。ソフトウェア影響度ESを未だ算出していない関数が存在する場合（S77：YES）、システム１００は、Ｓ７２〜Ｓ７６の処理を繰り返す。

そのハードウェアに関する全ての関数についてソフトウェア影響度ESをそれぞれ算出した場合（S77：NO）、システム１００は、算出された各ソフトウェア影響度ESをソフトウェア影響度統計テーブル２３にエントリさせる（Ｓ７８）。システム１００は、分析すべき他のハードウェアが存在するか否かを判定し（Ｓ７９）、未だ分析していないハードウェアが存在する場合（S79：YES）、Ｓ７１〜Ｓ７８の処理を繰り返す。

図２３は、ソフトウェア影響度統計テーブル１５１の一例を示す説明図である。この統計テーブル１５１は、図２中では「ソフトウェア影響度情報」として示されている。この統計テーブル１５１は、例えば、各ハードウェア毎に、そのハードウェアに属するレジスタの分類と、そのレジスタのソフトウェアに対する影響度（ES）と、そのソフトウェアへの影響を修正するために必要な推定工数（人×月）とを、それぞれ対応付けることにより構成することができる。なお、レジスタ分類の「ALL」とは、そのハードウェアに属する全てのグループのレジスタを意味する。つまり、レジスタ分類が「ALL」のソフトウェア影響度は、そのハードウェアに関する各グループ毎のソフトウェア影響度を集計した値となる。また、推定工数は、ソフトウェア影響度の単位値毎に必要な工数を予め定義しておくことにより求めることができる。

なお、ソフトウェア影響度ESを求めるための基礎指標として第１影響度ファクタ〜第３影響度ファクタの３種類を挙げたが、本発明はこれに限らず、他のファクタを考慮することもできるし、３種類の影響度ファクタうちいずれか一つまたは二つの影響度ファクタを除くこともできる。また、ハードウェアの種類毎に、ソフトウェア影響度を求めるための影響度ファクタを違える構成でもよい。さらに、追跡複雑度情報としては、以下のような定量情報を利用することもできる。例えば、親関数と子関数の第１合計値 (Fan-IN+Fan-OUT)を用いることができる。または、親関数と子関数の第２合計値(Trans Fan-IN+Trans Fan-OUT)を用いることができる。この第２合計値は、直接的ないし間接的に親子関係としてつながっている関数の数の合計である。さらには、Halstead's metricsのMental EffortやComplexity等のメトリックス情報を用いることもできる。

本実施例は上述のように構成されるので、以下の効果を奏する。本実施例では、ハードウェア要素とソフトウェア要素との相互依存関係を把握し、ハードウェア要素の変更がソフトウェア要素に与える影響の範囲及び大小を予測する。従って、ソフトウェアとハードウェアとが連携したシステム製品であるストレージ装置１０の開発をより適切に支援することができる。即ち、ハードウェアとソフトウェアとの高度な連携を意識して、システム製品の開発を行うことができ、開発作業の作業効率が向上する。

また、本実施例では、例えば、ソフトウェアへの影響が広範囲かつ深刻なハードウェアの変更を防止することも可能となる。従って、ソフトウェアの手直し作業や検証作業の発生を抑えることができ、ソフトウェアを効率的に開発することができ、開発コストを低減させることができる。

さらに、本実施例では、ソフトウェア影響度情報をハードウェア開発セクション及びソフトウェア開発セクションの両方がそれぞれ参照可能としている。従って、ハードウェア開発者は、ハードウェアがソフトウェアに与える影響を考慮しながら、そのハードウェアの設計を行うことができ、一方、ソフトウェア開発者は、ソースファイルがどのハードウェアにどの程度依存しているのかを把握しながら、そのソースファイルを作成することができる。ハードウェア開発者とソフトウェア開発者との間に共通の認識を持たせることができ、協調して開発作業を進めることが可能となる。

また、新機種のストレージ装置を開発する場合に、旧機種のストレージ装置に関するソフトウェア影響度を参照することにより、開発に必要な工数、期間、コスト等を予測することができる。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。本発明は、システム製品であるストレージ装置に用いた場合に特に有用であるが、ストレージ装置に限らず、他の種々のシステム製品にも広く適用可能である。そのようなシステム製品としては、例えば、携帯電話、携帯情報端末、インテリジェント化された各種家電製品、航空機や船舶等を挙げることができる。

本発明の実施形態の全体概要を示す説明図である。 本発明の実施例に係る開発支援システムの全体を示すブロック図である。 開発支援システムが用いられるストレージ装置の外観図である。 ストレージ装置のブロック図である。 CHAとDKAの関係及び両者の概略構造を示す説明図である。 ソース解析処理を示すフローチャートである。 ソースファイルをプリプロセッシングする様子を模式的に示す説明図である。 関数間の親子関係を模式的に示す説明図である。 関数単位で集計したソースメトリックス情報テーブルを示す説明図である。 制御単位で集計したソースメトリックス情報テーブルを示す説明図である。 ハードウェアドキュメント情報解析処理を示すフローチャートである。 ハードウェア仕様情報の説明図である。 ハードウェアＩ／Ｆ情報テーブルの説明図である。 品質管理情報解析処理のフローチャートである。 問題点管理票及びプログラム変更管理票をそれぞれ示す説明図である。 ハードウェア対応プログラム変更案件テーブルの説明図である。 ハードウェア対応案件統計テーブルの説明図である。 ハードウェア依存度分析処理を示すフローチャートである。 外部レジスタを起点とする各関数間のクロスリファレンス状態及び外部レジスタとの論理的な距離（Depth）とハードウェア依存度との関係をそれぞれ示す説明図である。 外部レジスタへアクセスする行数と総ステップ数との比率からハードウェア依存度指標を求める様子を示す説明図である。 ハードウェア依存度統計テーブルの説明図である。 ソフトウェア影響度分析処理を示すフローチャートである。 ソフトウェア影響度統計テーブルの説明図である。

符号の説明

１…ストレージシステム、２…開発支援システム、２Ａ〜２Ｃ…データベース、３…ハードウェア開発セクション、４…ソフトウェア開発セクション、１０…ストレージ装置、１１…基本筐体、１２…増設筐体、１３…制御パッケージ、１４…電源ユニット、１５…バッテリユニット、１６…冷却ファン、２１…チャネルアダプタ（CHA）、２１Ａ…通信ポート、２２…ディスクアダプタ、２３…キャッシュメモリ、２４…共有メモリ、 ２５…スイッチ部、２６…ディスクドライブ、２７…RAIDグループ、２８…サービスプロセッサ（SVP）、３０…ホスト、３１…管理端末、１００…ソフトウェア開発支援システム、１１０…ソフトウェア仕様情報解析部、１１１…ソース構造解析データ、１１１Ａ，１１１Ｂ…ソースメトリックス情報テーブル、１２０…ハードウェア仕様情報解析部、１２１…インターフェース解析データ、１３０…品質管理情報解析部、１３１…プログラム変更管理情報、１３１Ａ…ハードウェア対応プログラム変更案件テーブル、１３１Ｂ…ハードウェア対応案件統計テーブル、１４０…ハードウェア依存度分析部、１４１…ハードウェア依存度情報、１５０…ソース影響度分析部、１５１…ソフトウェア影響度情報、１６０…情報提供部、２１１、２２１…ポート制御部、２１２，２２２…メインプロセッサ、２１３，２２３…ローカルメモリ、２１６，２２６…プロセッサ、２１７，２２７…ハードウェアレジスタ、３１０，３２０…端末、ＣＮ１〜ＣＮ４…通信ネットワーク、Ｄｈ…ハードウェア仕様情報、Ｄｑ…品質管理情報、Ｄｑ１…問題点管理票、Ｄｑ２…プログラム変更管理票、Ｄｓ…ソフトウェア仕様情報、ＥＳ１１〜ＥＳｍｎ…ソフトウェア要素、Ｅｈ１〜Ｅｈｎ…ハードウェア要素

Claims (2)

1. 上位装置との間のデータ授受を制御するための情報処理システムを有する上位通信制御部と、記憶領域を提供する記憶デバイス群と、この記憶デバイス群との間のデータ授受を制御するための情報処理システムを有する下位通信制御部と、
   前記上位通信制御部及び前記下位通信制御部により共用されるメモリ部と、
   前記上位通信制御部及び前記下位通信制御部にそれぞれ設けられ、これら各通信制御部の前記各情報処理システムをそれぞれ制御するソフトウェアと、を備えたストレージ装置の前記ソフトウェアの開発を支援する開発支援システムであって、
   前記ソフトウェアに関する仕様情報を取得して、前記ソフトウェアを構成する所定のソフトウェア要素群の構造を解析するソフトウェア情報解析部と、
   少なくとも前記上位通信制御部及び前記下位通信制御部をそれぞれ構成するハードウェアに関する仕様情報を取得して、前記ハードウェアを構成する所定のハードウェア要素群の構造を解析するハードウェア情報解析部と、
   前記ソフトウェア情報解析部による解析結果と前記ハードウェア情報解析部による解析結果とに基づいて、前記ハードウェア要素群と前記ソフトウェア要素群との間の依存関係を分析する依存関係分析部と、
   前記依存関係分析部による分析結果に基づいて、前記ハードウェア要素群のいずれか一つまたは複数のハードウェア要素を変更した場合に、その変更が前記ソフトウェア要素群に与える影響度を予測する影響度予測部と、
   前記影響度予測部により予測された影響度を外部に提供する情報提供部とを備え、
   前記ソフトウェアに関する仕様情報には、少なくともソースプログラムが含まれ、
   前記ハードウェアに関する仕様情報には、少なくとも前記ソフトウェアと前記ハードウェアとのインターフェースに関する情報が含まれ、
   前記ソフトウェア要素群には、少なくとも前記ソースプログラムに含まれている関数群が含まれ、
   前記ハードウェア要素群には、少なくとも前記インターフェースに関するレジスタ群が含まれ、
   （１）前記ソフトウェア情報解析部は、前記関数群の各関数間の相互関係を解析し、
   （２）前記ハードウェア情報解析部は、前記レジスタ群をその機能別に分類し、
   （３）前記依存関係分析部は、
   （3A）前記レジスタ群の各レジスタ毎に、該レジスタを直接的または間接的に利用する前記関数群の階層構造を分析し、この分析された階層構造に基づいて、前記各レジスタ毎に、該レジスタと該レジスタを利用する関数との論理的な距離を検出し、
   （3B）前記関数群の各関数毎に、前記レジスタ群の利用状況を分析し、
   （3C）前記検出された論理的な距離と前記分析された利用状況とに基づいて、前記各関数が前記各レジスタに依存する依存度合をそれぞれ検出し、
   （４）前記影響度予測部は、前記依存関係分析部により検出された前記依存度合に基づいて、前記レジスタ群の各レジスタ毎に、該レジスタに対応する前記ハードウェアを変更した場合の影響度をそれぞれ検出する、ようになっているストレージ装置のソフトウェア開発支援システム。
2. 前記影響度予測部は、前記ソフトウェアの品質管理情報を取得し、この取得した品質管理情報と前記依存度合とに基づいて、前記各影響度をそれぞれ検出するものである請求項１に記載のストレージ装置のソフトウェア開発支援システム。

Images