JP2013131128A - プログラム構造評価システム、プログラム - Google Patents

Abstract

【課題】プログラム構造を解析・点数化して評価する。
【解決手段】階層定義テーブル１５には、複数の機能が階層構造となっているソフトウェア構造に従って、呼び出し元となる機能と呼び出し先となる任意の機能の関数種別／変数種別との組み合わせ（ペア）毎に、違反の有無が登録されている。点数化タスク部１２は、プログラムソース１９における全ての呼び出し関係（任意の機能からの任意の関数／変数の呼び出し）について、階層定義テーブル１５を参照して、違反か否かを判定して、違反件数をアクセス違反計数ファイル１７上で集計する。更に、この集計結果に基づいて評価点数の算出を行う。
【選択図】図１

Description

本発明は、プログラム構造を解析・評価する装置などに関する。

ソフトウェアの開発では、まず最初にソフトウェア全体の構造を決め、この構造に従ってプログラムの実装を行っている。
新規開発では、ソフトウェア構造に従って作成したものが作られるが、担当者によっては構造を無視して安直に他の機能の変数を書き換えたりすることがある。また、仕様書どおりの構造で作成されたプログラムが、派生開発や障害発生時の緊急対応などにより、担当者が全体構造を理解しないままその場しのぎでプログラムを修正し、その変更内容のレビューすることもなくソフトウェアを提供してしまうことがある。その結果、いわゆるスパゲッティプログラムとなることで、修正の影響範囲が分からなくなり、想定外の機能に不具合が発生し、品質保証のための作業工数の増大が発生する。最悪の場合は、顧客の信用を失墜し大きな損害を与えることがある。

本来は、全体構造を理解した上で修正し、全体構造を理解したレビューアによるレビューが望ましいことは分かっているが、実際には、以下の原因により実施されないことも多い
・開発メンバーの入替りで、全体構造（初期の設計思想）を十分理解できていない
・短納期により、有識者によるレビューをしていない
・レビューアが忙しく、レビューができない
ここで、プログラムを解析管理または点数評価する技術として、例えば特許文献１、２に記載の従来技術が知られている。

特許文献１の従来技術は、プログラム中における共通構造を解析することにより、共通部分を明示したプログラム構造図の生成や、プログラム構造における共通部分の再利用化を容易なものとする。

また、特許文献２の従来技術は、各評価指標を点数評価することにより品質向上が必要とされる順に優先度付けし、精度が高く効率的な品質評価と、効率的且つ効果的な品質向上作業を図ることができる。上記点数評価は、チェックリスト件数密度、不良件数密度、カバレージ率、規模、難易度、不良の重要度や不良分析コード等の各々の評価項目単位に、評価点数算出基準に従い評価点数を算出するものである。

特開２００７−１１５１５５号公報 特開２０００−５６９６１号公報

ここで、従来より、プログラム自体を品質特性に従って点数化するツールは存在する（例えばオージス総研の「Ａｄｑｕａ（アドクア；登録商標）」や、東陽テクニカ等の「ｅＸｑｕｔｏ（登録商標）」等）。例えばＡｄｑｕａ（アドクア）は、組込みソフトウェアの品質を定量的に評価できるツールである。具体的には、ソフトウェアを「信頼性」「効率性」「保守性」「移植性」「再利用性」の５つの品質特性の観点で得点化する。

ここで、上記ソフトウェア構造の規定として、例えば、複数の機能より成るソフトウェアにおける機能間のアクセス（呼び出し等）に係る制限事項が設けられたものがある。これは、例えば関数間のアクセスに係る制限や、関数から変数へのアクセスに係る制限等である。あるいは、上記複数の機能が階層構造になっている場合には、この様な階層に係る制限事項も含まれる。

この様な意味でのソフトウェア構造の規定（制限）に従ってプログラムが作成する場合も、当然、何らかの理由で違反が生じることは有り得る。違反件数の多さは、品質に影響する。また、過去に作成されたプログラムを改造する場合には、少なくとも品質を落とさないようにすることが望まれる。

例えば、オブジェクト指向プログラムの場合、クラス図などを作成して、これに従ってプログラム作成や継承等を行うが、古いソフトウェア等はこの様なモデル化設計思想ではなく旧来の構造化設計思想に基づいて作成されており、また、この様な古いソフトウェア（レガシー資産）を再利用するために改造を行い新規ソフトウェアとして作成する場合もある。この様な過去の古いソフトウェアに対して上記ソフトウェア構造に従った評価を行うと、違反件数が多数となる場合が少なくない。そして、この様な過去の古いソフトウェアから改造版等を作成する場合、違反であることが分かっていても修正することが困難な場合が少なくなく、現状維持（それ以上違反を増やさない）が出来ればよいとする場合がある。

以上のことから、上述した意味でのソフトウェア構造に従ったプログラム作成が行われているか否か（例えば、最低限、現状維持できているか等）の判断を、プログラム全文をチェックして評価するような手間が掛かる作業を行う必要なく、行えるようにすることが望まれる。これは、例えば、上記違反に関して点数化を行うことで、客観的且つ的確な判断が行えるようにすることが望まれる。

一方、上述したＡｄｑｕａ等の既存ツールや、特許文献１，２の従来技術では、上述した意味でのソフトウェア構造の規定、すなわち上記複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限事項や階層に係る制限事項に関して、点数化して評価することは何等考えられていない。

本発明の課題は、複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限があるソフトウェア構造設計に従ったプログラム作成が行われたか否かについて、プログラムを解析・点数化することで容易に評価可能とするプログラム構造評価システム等を提供することである。

本発明のプログラム構造評価システムは、複数の機能より成るソフトウェアの機能間のアクセスに係る制限に従って、呼び出し元となる機能と呼び出し先となる任意の機能の関数種別／変数種別との組み合わせ毎に、違反の有無が登録された違反有無記憶手段と、評価対象のソフトウェアのプログラム文を順次参照して、任意の機能の任意の関数から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、さらに前記違反有無記憶手段を参照して、該呼び出しが違反か否かを判定する違反判定手段と、前記違反判定手段による判定結果に基づいて、前記各機能毎または／及び前記評価対象のソフトウェア全体の違反件数を集計する集計手段と、該集計手段による違反件数の集計結果に基づいて、前記評価対象のソフトウェア全体または／及びその各機能毎の評価点数を算出する評価点数算出手段とを有する。

上記システムによれば、任意の評価対象のプログラムに関して、上記複数の機能より成るソフトウェアの機能間のアクセスに係る制限に係る違反の有無を判定して点数化することによって、客観的な評価の為の数値が得られる。客観的な分かり易い評価基準が示されるので、容易に的確な評価・判断を行うことができることになる。例えば、少なくとも過去の他製品に比べてレベルダウンしていないこと等を確認することができる。

本発明のプログラム構造評価システム等によれば、複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限があるソフトウェア構造設計に従ったプログラム作成が行われたか否かについて、プログラムを解析・点数化することで容易に評価可能とすることができる。

本例のプログラム評価システム全体の構成図である。 ソフトウェア構造（階層と機能）の一例を示す図である。 階層定義テーブル１５の具体例を示す図（その１）である。 階層定義テーブル１５の具体例を示す図（その２）である。 機能２−２による各機能に対するアクセス例を示す図である。 アクセス違反計数ファイルの具体例（その１）である。 （ａ），（ｂ）はアクセス違反計数ファイルの具体例（その２）である。 （ａ），（ｂ）はアクセス違反計数ファイルの具体例（その３）である。 （ａ），（ｂ）は動作情報定義テーブルの具体例である。 （ａ）は重み付け後の集計結果、（ｂ）はアクセス違反点数化ファイルの一例である。 偏差値算出の具体例を示す図である。 サーバメイン処理部の処理フローチャート図である。 定義登録タスク部の処理フローチャート図である。 点数化タスク部の処理フローチャート図である。 プログラム例である。

以下、図面を参照して本発明の実施の形態について説明する。
図１は、本例のプログラム構造評価システム全体の構成図であって、特に管理サーバの機能構成を示す図である。

図示のプログラム構造評価システムは、作業者が操作するための操作端末１と、任意のプログラムに関するソフトウェア構造に係る評価（点数化等）を実行する管理サ−バ１０とが、ネットワーク２に接続された構成となっている。ネットワーク２は、例えばＬＡＮやインターネット等の一般的なネットワークであってよい。ネットワーク２を介して、操作端末１と管理サーバ１０間でデータ／コマンド等を送受信する。

但し、この例に限らない。例えば管理サ−バ１０単体でプログラム構造評価システムを構成するものであってもよい。勿論、この場合、操作端末１の機能も管理サ−バ１０が有することになる。例えば、後述する各種要求は、例えば管理サ−バ１０のキーボード等を開発者等が操作して所望の指示を行うことで、管理サ−バ１０自身がサーバメイン処理部１１に対してこの指示に応じた要求を発行することになる。

操作端末１は、例えば一般的なパソコン等であって、特に図示しないが作業者（ユーザ）に任意のコマンド・ボタンを選択・指定させる為の画面等を表示する機能や、ユーザが選択・指定したコマンド・ボタンに応じた要求（コマンド）を、ネットワーク２を介して管理サーバ１０へと送信する機能等を有する。

上記要求の種類としては、たとえば後述する“点数化要求”や“定義の登録要求”等がある。
管理サーバ１０は、サーバメイン処理部１１、点数化タスク部１２、定義登録タスク部１３の各種機能部を有する。これら各種機能部の処理機能は、不図示のＣＰＵ等が、不図示の記憶装置（ハードディスク、メモリ等）に予め記憶されている所定のアプリケーションプログラムを読出し・実行することにより実現される。これら各種機能部や上記各種要求に応じた処理については、後に各種フローチャート図等を参照して説明するものとする。

また、管理サーバ１０は、上記記憶装置等に、偏差値計数ファイル１４を記憶・保持している。
また、管理サーバ１０は、上記記憶装置等に、各製品毎に対応する各種情報／プログラムを記憶している。すなわち、図示の例では製品Ａと製品Ｂのそれぞれについて、階層定義テーブル１５、動作情報定義テーブル１６、アクセス違反計数ファイル１７、アクセス違反点数化ファイル１８、プログラムソース１９等の各種情報／プログラムを記憶している。尚、図では製品Ａについての各種情報／プログラムのみ示すが、製品Ｂについても略同様に、その製品に対応する各種情報／プログラムが記憶される。

サーバメイン処理部１１は、操作端末１からの何らかの要求を受け付けて、この要求に応じて点数化タスク部１２、定義登録タスク部１３の何れかを呼び出して処理実行させる。

定義登録タスク部１３は、操作端末１からの要求が上記“定義の登録要求”であった場合にサーバメイン処理部１１から呼び出されて、当該登録要求された定義（情報やプログラム等）の登録を実行する。登録対象の定義（情報やプログラム等）は、上記階層定義テーブル１５や動作情報定義テーブル１６に格納すべき情報や、プログラムソース１９等である。尚、プログラムソース１９は、基本的に、複数のプログラムファイルから成る。これら登録対象の情報等は、例えば作業者が操作端末１側で任意に入力／作成したものであるが、この例に限らない。

点数化タスク部１２は、操作端末１からの要求が任意の製品のプログラムソース１９に関する評価（点数化等）であった場合に、サーバメイン処理部１１から呼び出されて、当該プログラムソース１９の評価（点数化等）を行い、場合によっては更に偏差値を作成する。

尚、点数化タスク部１２の上記点数化等の処理に伴って、上記アクセス違反計数ファイル１７、アクセス違反点数化ファイル１８が生成される。詳しくは後述する。
ここで、図２に、ソフトウェア構造（階層と機能）の一例を示す。

図２のソフトウェア構造例は、複数の機能が階層構造となっているソフトウェア構造の一例であり、第一階層（最下層）、第二階層（中間層）、第三階層（上位層）の３階層あり、各階層毎に２つの機能が存在する。すなわち、第一階層には、機能１−１と機能１−２がある。同様に、第二階層には機能２−１と機能２−２があり、第三階層には機能３−１と機能３−２がある。

図２のソフトウェア構造の具体例としては、例えばソフトウェアが何らかの所謂“組込みソフトウェア”である場合が考えられる。尚、よく知られているように、“組込みソフトウェア”とは、家電製品や産業機器に組み込まれた特定の機能を提供するためのコンピュータシステム（組込みシステム）上のソフトウェアである。上記Adqua等は、主に組込みソフトウェアの品質評価に用いられるものである。

ここで、組込み用のプログラムに関するソフトウェア構造の一例として、機能が、例えばアプリケーション、ミドル（ミドルウェア）、ＯＳ（ドライバ）に階層化・分類される場合がある。つまり、階層としては、アプリケーションが上位層、ミドルが中間層、ＯＳ（ドライバ）が最下層（下位層）となっている。そして、基本的には任意の階層の任意の機能が、自己と同じ階層の他の機能または１段下の階層の他の機能を呼び出すことになる。このうち１段下の階層の呼び出しに関しては、上記の例では、アプリケーションがミドルを呼び出し、ミドルがＯＳ（ドライバ）を呼び出すものとなる。

上記のことは、換言すれば、２段下の階層の機能を呼び出すことは違反となる。つまり、アプリケーションがＯＳ（ドライバ）を呼び出すことは違反となる。更に、上位側の機能を呼び出すことも違反となる。すなわち、ミドルがアプリケーションを呼び出すことや、ＯＳ（ドライバ）がミドルやアプリケーションを呼び出すことは、違反となる。

尚、後述するように、任意の機能に係るローカル変数を他の機能が呼ぶ出すことも違反となる。
尚、上記任意の機能から他の機能の呼び出しは、詳細には、例えば任意の機能の関数から他の機能の関数の呼び出しや、任意の機能の関数から他の機能の変数の呼び出し等となる。但し、これに限らず、自機能内での呼び出しも行われる。つまり、任意の機能の関数から同じ機能内の他の関数の呼び出しや、任意の機能の関数から同じ機能内の任意の変数の呼び出し等となる。但し、基本的に自機能内での呼び出しは違反とはならないので、本説明では自機能内での呼び出しに係る説明を省略する場合もあるものとする。

上記各機能は、それぞれ、１以上のプログラムソースファイルから構成される。各プログラムソースファイルのプログラム記述に用いられる関数、変数の種類（種別）は、本例では図２に示すように、ＡＰＩ（関数）、ローカル関数、グローバル変数、ローカル変数等であり、それぞれ下記の特徴と有する。
（１）ＡＰＩ関数；機能外からでもアクセスできる関数
（２）ローカル関数；機能内でのみアクセスできる関数
（３）グローバル変数；機能外からでもアクセスさせることを前提とした変数
（４）ロ−カル変数；機能内でのみ使用する変数
基本的に、任意の機能におけるローカル関数やローカル変数を、他の機能から呼び出すことは、上記階層構造に関係なく、違反となる。

尚、上記ＡＰＩ（Application Program Interface）関数やローカル関数は関数種別の一例、上記グローバル変数やローカル変数は変数種別の一例と言える。
以上、図２を用いて説明したことが、上述した「複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限事項や階層に係る制限事項」の具体例である。本システムでは、評価対象のソフトウェア（プログラムソース１９）に関して、「複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限事項や階層に係る制限事項」に係る評価のための点数化を行うことができる。

後述するように、本例では、上記関数種別／変数種別毎に違反件数の集計や評価点数の算出等を行うものであるが、この例に限らない。尚、本例では全ての関数はＡＰＩ（関数）とローカル関数の何れかに属するものであり、全ての変数はグローバル変数とローカル変数の何れかに属するものとするが、この例に限らない。

例えば開発者等が、事前に、上記図２に示すソフトウェア構造（階層と機能に係る制限事項）に従って、階層定義テーブル１５を作成する。これは、例えば、操作端末１側で作成する（特に図示・説明はしないが、操作端末１には例えば開発者等が所望の階層定義テーブル１５を作成するのを支援する機能等が存在する）。

階層定義テーブル１５は、例えば、複数の機能が階層構造となっているソフトウェア構造に従って、呼び出し元となる任意の機能と、呼び出し先となる任意の機能の関数種別／変数種別との組み合わせ（ペア）毎に、違反の有無が登録されたテーブルである。

図３に、階層定義テーブル１５の具体例を示す図（その１）である。
図示の例では、階層定義テーブル１５には、呼び出し元２５（機能単位）と呼び出し先２４（各機能毎の関数種別／変数種別）のペア（組み合わせ）毎に、“違反なし”または違反内容（ここでは図示のＡ，Ｂ，Ｃ，Ｄの４種類）が、登録される。図示の例では、空白は“違反なし”を意味する（これは例えば‘ＮＵＬＬ’や‘０’などが登録されるものであってもよい）。

呼び出し先２４は、上記各機能（その機能番号２２）毎に、その機能における上記４項目（２種類の関数種別、２種類の変数種別；ＡＰＩ（関数）、ローカル関数、グローバル変数、ローカル変数）に分類されている。尚、上記機能番号とは、上記各機能毎に予め任意に割当てられている機能識別用番号であり、図示の例では図２に示した１−１〜３−２の記号を用いている。

また、各機能毎に、その機能に対して予め任意の機能番号（１−１〜３−２等）や機能コード（ＳＣＩ、ＳＹＳ等）が割当てられており、本例においては機能コードがその機能に係わるプログラムソースファイル名や各関数／変数の名称に用いられることになっているものとする（具体例は後述する）。これより、図３に示すように、上記各機能番号２２毎に、その機能に対応する機能コード２３が登録されており、更にその機能が属する階層２１が登録されている。

尚、各機能は、一例としては例えば各々が複数のプログラムソースファイルから構成されるものであってよく、この例では任意の機能に係わる複数のプログラムソースファイルのファイル名全てに、その機能の機能コードが用いられることになる。詳しくは後に具体例を用いて説明する。

上記違反内容を示す図３に示す記号Ａ，Ｂ，Ｃ，Ｄは、例えば下記の意味を持つ。
尚、図３に示す上記Ａ〜Ｄは、図２に示すソフトウェア構造の規定に従って、開発者等が例えば手作業等により入力・設定したものである。

Ａ：階層を越えてＡＰＩ（外部）関数を呼び出した。
Ｂ：外部に公開されていないローカル関数をアクセスした。
Ｃ：階層を越えてグローバル（外部アクセス用）変数を呼び出した。
Ｄ：外部に公開されていないローカル変数をアクセスした。

尚、上記「階層を越えて」とは、上位側の階層、または下位側であっても２段以上下の階層の機能にアクセスした場合を意味する。

但し、上記記号Ａ〜Ｄの代わりに、数値を設定するようにしてもよい。この数値（設定値）は、例えば‘０’と‘１’であり、‘０’が“違反無し”、‘１’が“違反あり”を意味するものであるが、この例に限らない。例えば、設定値が０，１，２、・・・ｎ（ｎ；任意の整数）であり、これらの設定値は、例えば違反の許容範囲を示しており、例えば下記のように定義されるものであってもよい。

『 ０：異常として検出しない。
１：違反が１個以上存在する場合、異常として検出する。
２：違反が２個以上存在する場合、異常として検出する。
３：違反が３個以上存在する場合、異常として検出する。
・
・
・
ｎ:違反がｎ個以上存在する場合、異常として検出する。 』

例えば、過去に作成されたプログラム（レガシー資産）に基づいて作成されたプログラムの場合、違反であることが分かっていても修正困難である箇所が存在する場合がある。よって、レガシー資産において任意のペアに関して違反が２個存在すると分かっているならば、違反２件は必ず生じるのでこれは除外して考えるものとして‘３’を設定することになる（つまり、違反が３個以上存在する場合（実質的に新たな違反が１個以上存在する場合に）、新たな違反の分だけをカウントする）。

尚、上記例の場合、設定値が‘０’、‘１’以外の場合（２以上の場合には）、一旦、‘１’と同様にして“違反あり”として違反件数をカウントしておき、後から違反件数を補正するようにしてもよい。すなわち、例えば「補正後の違反件数＝違反件数−設定値＋１」を算出するようにしてもよい。例えば設定値が上記‘３’であるペアが３つ存在し、これら３つのペアについてカウントされた違反件数がそれぞれ３件、４件、５件の場合には、補正後の違反件数は、それぞれ、１件、２件、３件となる。

尚、上記の通り、１つの機能が複数のプログラムソースファイルで構成される場合がある。例えば、一例として、３つのプログラムソースファイル（これらのファイル名を、仮に、“Ｓｃｉ＿ｆｉｆｏ．ｃ”、“Ｓｃｉ＿ｓｅｎｄ．ｃ”、“Ｓｃｉ＿ｒｅｃ．ｃ”とする）によってＲＳ２３２Ｃ通信機能（機能コード＝ＳＣＩ）が実現されるものとする。この例の場合、機能内でのやり取りに使用する関数／変数が存在する場合があり得る。例えば、“Ｓｃｉ＿ｆｉｆｏ．ｃ”内の任意の関数から“Ｓｃｉ＿ｓｅｎｄ．ｃ”内の任意の関数／変数を呼び出す場合があり得る。これは、同一機能内での呼び出しであるので、呼び出し先の関数／変数がローカル関数／ローカル変数であっても問題ないことになる（違反とはならない）。

しかし、上記のことは、任意のプログラムソースファイルの関数から他のプログラムソースファイルの関数／変数を呼び出すことになり、これが可能である以上、他の機能のプログラムソースファイルからもアクセスできてしまうことになる。ここで、任意のプログラムソースファイル内での呼び出しであれば、当該ファイル内でしか使用できない関数や変数の設定（宣言等）ができる。しかしながら、上記のように同一機能内での他のプログラムソースファイルからのアクセスを許可する場合には、この様な宣言が行えないため、結局、同一機能内だけでなく他の機能のプログラムソースファイルからもアクセスできてしまうことになる。しかしながら、上記の通り、本例では、この様なアクセスは、少なくともアクセス先がローカル関数／ローカル変数である場合には違反となり、上記違反内容を示す記号のうちＢとＣは、この様な違反を想定しているものである。

既に述べたように、図２に示すソフトウェア構造の規定は、例えば下記の通りとなる。
尚、逐一述べないが、任意の機能から他の機能の呼び出しは、詳細には既に述べた通り、任意の機能に属する関数から、他の機能に属する関数または変数の呼び出しを意味する。また、これも逐一述べないが、当然、同一機能内での呼び出し（任意の関数から同じ機能内の他の関数や変数を呼び出すこと）は、基本的に全てＯＫである（違反とはならない）。

第一階層の機能は、同一階層（第一階層）の機能または１段上の階層の機能から呼ばれる。換言すれば、第一階層の機能が、上位階層の機能を呼び出すことは違反となる。これより、呼び出し元２５が第一階層の機能（１−１または１−２）であり、呼び出し先が第二階層または第三階層の機能である場合には、図示のように“違反なし”となるペアは１つも存在しないことになる。尚、ローカル関数やローカル変数に関しては、階層等は関係なく、他の機能から呼び出すこと自体が違反となる。

第二階層の機能は、同一階層（第二階層）の機能や１段下の階層である第一階層の機能を呼び出すことはできるが、上位側の階層である第三階層の機能を呼び出すことはできない。これより、違反か否かの判定は、例えば、後に図５、図６で示す例のようになる。すなわち、例えば第二階層の機能２−１は、同一階層の他の機能である機能２−２や、第一階層の機能１−１、１−２を呼び出すことは出来るが（勿論、ローカル関数やローカル変数は呼び出せない）、第三階層の機能３−１、３−２を呼び出すことはできない。

第三階層の機能は、１段下の階層である第二階層の機能を呼び出すことはできるが、２段下の階層である第一階層の機能の呼び出しは、基本的には出来ない。これより、違反か否かの判定は、例えば、後に図５、図６で示す例のようになる。例えば第三階層の機能３−１は、同一階層の他の機能である機能３−２や、第二階層の機能２−１、２−２を呼び出すことは出来るが（勿論、ローカル関数やローカル変数は呼び出せない）、第一階層の機能１−１、１−２を呼び出すことはできない。

但し、特殊な機能のみ呼び出しを許可することもあるので、開発者等の判断によって例外として特別に違反としないようにすることもできる。図３において‘０’で示すものがその一例である。尚、‘０’を設定する代わりに、“違反なし”を意味する空白（ブランク）としてもよい。

図３に示す例では、呼び出し元が「機能３−１」で呼び出し先が「機能１−２のＡＰＩ関数」であるペアに対して、上記例外として‘０’が設定されている。これは、第三階層の機能３−１が、第一階層の機能１−２（そのＡＰＩ関数）を呼び出すものであるので、上記の通り基本的には違反となるが、例外として“違反なし”を意味する設定がされていることになる。

尚、上記階層定義テーブル１５等のような定義ファイルを設けるのは、上記のように柔軟性を設け例外を認めることを目的としており、既存製品への適合や文字列変換などの階層を越えた共通ライブラリなどを想定している。

尚、既存製品への適合とは、レガシー資産で構造評価を行うと多くのエラーが検出され、エラーを減らすことは困難なので、これ以上階層が壊れないようにすること(現状維持)を目的として、「“既存製品の違反件数”＋１」を設定することにより（上記設定値；違反の許容範囲）、既存製品よりも違反件数が増えた場合に評価点数が１００点未満となるように定義ファイルを設定することで、簡単に判断（評価）できるようにすることを考慮している。

ここで、図４に、階層定義テーブル１５の具体例（その２）を示す。
既に述べたように、上記図３のＡ，Ｂ，Ｃ，Ｄの代わりに、違反の有無や上記許容範囲等を示す数値が、設定されるものであってもよく、図４にはその一例を示している。

一例としては、違反か否かだけを登録するようにしてもよい。すなわち、違反である場合には‘１’、違反なしの場合には‘０’を登録するようにしてもよい。
但し、この例に限らず、本来であれば‘１’を設定すべきところを例外的に‘０’が登録されるようにしてもよい。図４に示す例では、呼び出し元が「機能３−１」で呼び出し先が「機能１−２のＡＰＩ関数」であるペアに対して、上記例外として‘０’が設定されている。

更に、この例に限らず、図４に示すように、‘０’、‘１’以外の数値が例外的に登録されるようにしてもよい（その意味の一例は既に説明した上記許容範囲等である）。図示の例では呼び出し元が「機能３−１」で呼び出し先が「機能１−１のＡＰＩ関数」であるペアに対して、‘３’が設定されている。

尚、図４が図３と異なる点は、基本的には図３に示す上記Ａ，Ｂ，Ｃ，Ｄが全て‘１’になっており、図３に示す空白が全て‘０’になっていることであるので（但し、上記例外としての‘０’や後述する例外‘３’が存在する）、図３と略同様な部分についてはここでは特に説明しないものとする。

ここで、上記例外的な設定値（図４の例では‘３’）について説明する。
既に述べたように、この様な‘０’、‘１’以外の数値は、‘１’と同様に“違反である”ことを示すと共に、更に「違反の許容範囲」を示すものとする。これより、後に一例を示すように、上記‘３’が設定されているペアに関する違反件数が例えば‘５’であった場合、上記設定値‘３’を用いて、違反件数を補正する。詳しくは後述する。

上記点数化タスク部１２は、評価対象のプログラムソース１９と上記階層定義テーブル１５を用いて、違反の判定や違反件数の集計を行う。この処理例やプログラムの具体例については後に示すが、基本的にはプログラムソース１９を解析して、どの機能からどの機能のどの関数／変数を呼び出しているのかを認識して、これに基づいて階層定義テーブル１５を参照して、その呼び出し（アクセス）が違反か否か等を判定し、違反件数をカウントしていくことになる。

これに基づいて、点数化タスク部１２は、更に、違反件数を集計し、この集計結果に基づいて評価点数を算出し、更に場合によってはこの評価点数と過去の他製品の評価点数に基づいて、評価対象のプログラムソース１９の偏差値を算出する。

違反件数のカウント・集計結果はアクセス違反計数ファイル１７に登録され、評価点数はアクセス違反点数化ファイル１８に登録され、偏差値は偏差値計数ファイル１４に登録される。

尚、特に図示等しないが、上記点数化タスク部１２は、例えば以下に記述する各処理部を有するものと見做すこともできる。
すなわち、点数化タスク部１２は、下記の違反判定処理部、集計処理部、評価点数算出処理部、偏差値算出処理部の各処理部を有するものということもできる。尚、これら各処理部は、管理サーバ１０の不図示のＣＰＵ等が、不図示の記憶装置（ハードディスク、メモリ等）に予め記憶されている所定のアプリケーションプログラムを読出し・実行することにより実現される。

違反判定処理部は、評価対象のソフトウェア（プログラムソース１９）のプログラムソース文を順次参照して、任意の機能の任意の関数から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、これに基づいて上記階層定義テーブル１５を参照して該呼び出し（アクセス）が違反か否かを判定する。

集計処理部は、上記違反判定処理部による判定結果に基づいて、（呼び出し元の）各機能毎の違反件数を集計し、または／及び、評価対象のソフトウェア全体の違反件数を集計する。

評価点数算出処理部は、該集計処理部による違反件数の集計結果に基づいて、上記評価対象のソフトウェア全体、または／及び、その（呼び出し元の）各機能毎の評価点数を算出する。

また、偏差値算出処理部は、他の複数のソフトウェアについてそれぞれ評価点数が算出済みである場合に、上記評価対象のソフトウェアの評価点数も含む該複数の評価点数に基づいて、上記評価対象のソフトウェアの評価点数について偏差値を算出する。

ここで、図５に、一例として、機能２−２からの各機能に対するアクセス例を示している（プログラム全体で機能２−２内のローカル変数から他の関数／変数に対するアクセスしたものを抽出した例を示している）。

図５に示す８本の矢印が、それぞれ、機能２−２内のローカル変数からの他の関数あるいは変数に対するアクセスを意味している。つまり、呼び出し元が機能２−２（そのローカル変数）であり、呼び出し先が各矢印の先に示す関数／変数である例を示している。これは、例えば機能２−２内には８個のローカル変数があり、これら各ローカル変数が、それぞれ、任意の他の関数あるいは変数に対するアクセス（呼び出し）を行っている場合が考えられるが、この例に限らない。

図５に示す８本の矢印には、それぞれ、（ａ）〜（ｈ）の記号が付してあり、この記号を用いて各矢印を区別して説明するものとする。
図５に示す８本の矢印には、図示のように、太い矢印と細い矢印がある。図３や図４に示す例の階層定義テーブル１５を用いた場合、太い矢印で示す（ｂ）、（ｃ）、（ｇ）、（ｈ）の矢印が示すアクセスが、違反となる。一方、細い矢印で示す（ａ）、（ｄ），（ｅ），（ｆ）の矢印が示すアクセスは、違反ではないと判定されることになる。

そして、上記判定結果に応じて「アクセス違反計数ファイル」１７の内容を更新する。そして、最後に集計結果を求める。
これについて、図６〜図８を参照して説明する。

図６〜図８は、アクセス違反計数ファイル１７の具体例（その１）、（その２）、（その３）である。また、図７、図８には、集計結果の具体例も併せて示している。
まず、図６を参照して説明する。

図６に示すように、アクセス違反計数ファイル１７のデータ構造自体は、上記図３や図４に示す階層定義テーブル１５のデータ構造と略同様である。すなわち、アクセス違反計数ファイル１７は、階層３１、機能番号３２、機能コード３３、呼び出し先３４、呼び出し元３５から成る。これらは階層定義テーブル１５の階層２１、機能番号２２、機能コード２３、呼び出し先２４、呼び出し元２５と略同様であり、ここでは特に説明しないが、各呼び出し先３４（機能単位）と各呼び出し元３５（関数種別／変数種別単位）のペアに応じた計数欄が設定されている。

初期状態では、全ての計数欄（図では２４×６＝１４４個の計数欄）には、カウント値の初期値＝‘０’が設定されている。
各計数欄のうち、上記図５に示す８つのアクセス（８本の矢印（ａ）〜（ｈ））の何れかに該当する計数欄には、図示のように、（ａ）〜（ｈ）の何れかを記述し、これを用いて説明するものとする。

尚、以下の説明では、呼び出し先に関しては、例えば呼び出し先が、機能番号３２が“機能１−１”で呼び出し先３４が“ＡＰＩ関数”であることを、「呼び出し先が“機能１−１のＡＰＩ関数”である」等と表現するものとする。

例えば、図５に示す矢印（ａ）を例にすると、この矢印（ａ）は機能２−２のローカル関数から機能１−１のＡＰＩ（関数）へのアクセスであるので、図６のアクセス違反計数ファイル１７においては「呼び出し元３５が“機能２−２”であり、呼び出し先が“機能１−１のＡＰＩ関数”」である計数欄が、矢印（ａ）のアクセスに該当する計数欄となる。上記の通り、矢印（ａ）のアクセスは違反ではないので、該当計数欄のカウント値は現在値のままとする（例えば初期値＝‘０’のままとなる）。

一方、例えば矢印（ｂ）に関しては、図６のアクセス違反計数ファイル１７においては、呼び出し元３５が“機能２−２”であり、呼び出し先が“機能１−１のローカル関数”である計数欄が、矢印（ｂ）のアクセスに該当する計数欄となる。そして、上記の通り、矢印（ｂ）のアクセスは違反であるので、該当計数欄のカウント値を更新する。これは、例えば該当計数欄の現在のカウント値に対して＋１インクリメントとする（例えば現在のカウント値が初期値＝‘０’である場合には、０＋１＝１が新たなカウント値となる）。

このようにして、上述した例では、図６において（ｂ）、（ｃ）、（ｇ）、（ｈ）が記述された計数欄について、それぞれ、例えば現在のカウント値に対して＋１インクリメントとする更新処理が行われることになる。

例えば評価対象のプログラムソース１９の各プログラムソースファイル毎に、そのファイルに記述されているプログラム文について先頭行から最終行まで順次参照しながら、任意の関数が他の関数あるいは変数を呼び出す箇所を見つける毎に、そのアクセスが違反か否かを階層定義テーブル１５を参照して判定し、違反である場合には上記のようにアクセス違反計数ファイル１７の該当計数欄の値を更新する。

尚、上記の通り、階層定義テーブル１５において‘０’以外の数値は全て“違反である”ことを意味しているので、図４に示す‘３’が格納された「呼び出し元２５が機能３−１で呼び出し先が機能１−１のＡＰＩ関数」であるアクセスも“違反である”と判定されて該当計数欄のカウント値が更新されることになる。

そして、上記処理を評価対象のプログラムソース１９に係わる全てのプログラムソースファイルについて実行した結果、最終的にはアクセス違反計数ファイル１７の内容が、図７（ａ）に示すものとなったとする。以下、この例を用いて説明する。

図７（ａ）において、空白となっている計数欄は、初期値＝‘０’のままであること（違反が１件もなかったこと）を意味するものとする。
そして、図７（ｂ）には、図７（ａ）に示すアクセス違反計数ファイル１７に基づいて所定の集計を行った結果を示す。尚、この様な集計結果もアクセス違反計数ファイル１７の一部であると見做してよい。

図示のように、この集計結果は、呼び出し元３５の各機能毎に、それぞれ、上記４項目（（２種類の関数、２種類の変数；ＡＰＩ（関数）、ローカル関数、グローバル変数、ローカル変数）それぞれについての集計を行ったものである。

ここで、特に呼び出し元３５が“機能３−１”である場合の集計結果に関しては、上記例外があることから、特に図４に示す例の場合には、一旦、図７（ａ）の内容により図７（ｂ）に示す集計結果が得られるが、その後、図８（ａ）の内容に更新させることによって図８（ｂ）に示す集計結果が得られることになる。

これについては、まず、呼び出し元３５が“機能３−１”で、呼び出し先が“機能１−２のＡＰＩ関数”のペアに対応する計数欄は、図７（ａ）に示すように空白（違反ゼロ）となっている。これは、図３や図４に示すように、このペアのアクセスは基本的には違反となるが、例外的に違反ではないものとしている（‘０’としている）ためである。

また、呼び出し元３５が“機能３−１”で、呼び出し先が“機能１−１のＡＰＩ関数”のペアに対応する計数欄のカウント値は、図７（ａ）に示す通り‘５’となっている。つまり、このペアに係わる記述が、プログラム全体で５件あったことになる。呼び出し元３５が“機能３−１”で、呼び出し先が“ＡＰＩ関数”である他のペアは、全て空白となっている。これより、図７（ｂ）に示すように、呼び出し元が機能３−１で呼び出し先がＡＰＩ関数である場合に関する違反件数は、全体で５件となっている。

この後、点数化タスク部１２は、図４の階層定義テーブル１５を参照して、設定値が‘０’でも‘１’でもないものを全て抽出する。図４に示す例では、該当するものは１つであり、呼び出し元２５が“機能３−１”で、呼び出し先が“機能１−１のＡＰＩ関数”のペアに対して‘３’が設定されている。これよりこの設定値‘３’を取得すると共に、上記アクセス違反計数ファイル１７において該当する違反件数（上記の例では‘５’）を取得する。

ここで、上述したように本例では‘０’と‘１’以外の設定値は、違反ありの意味に加えて「違反の許容範囲」の意味も兼ねるものとしており、既に述べたように「補正後の違反件数＝違反件数−設定値＋１」を算出するようにしてもよい。これより、上記の例では、補正後の違反件数＝５−３＋１＝３が算出されることになる。よって、この例では違反件数‘５’が図８（ａ）に示すように‘３’に置き換わることになる。これより、呼び出し元が機能３−１で呼び出し先がＡＰＩ関数である場合に関する違反件数は、補正後は図８（ｂ）に示すように全体で３件となっている。

また、上記図７（ｂ）や図８（ｂ）に示す集計結果を、そのまま、最終的な集計結果としてもよいが、何らかの補正を行って最終的な集計結果としても良い。その為の情報が、上記動作情報定義テーブル１６に予め設定される。これは、例えば開発者等が任意に決めて設定してよい。

図９（ａ）、（ｂ）に、動作情報定義テーブル１６に設定される情報の一例を示す。
図９（ａ）は重み付けに係わる情報であり、図９（ｂ）は足きりの閾値である。
尚、必ずしも図９（ａ）、（ｂ）の両方が必要なわけではなく、どちらか片方のみであってもよい。当然、後述する処理も、それに応じた処理となる。

（１）重み付けに関して
図９（ａ）に示す重み係数は、上記アクセス対象（呼び出し先）に係わる４つの評価項目（各関数種別／各変数種別；本例ではＡＰＩ（関数）、ローカル関数、グローバル変数、ローカル変数）それぞれについて、任意の重み係数（重み値）が登録されたものである。これは、例えば開発者等が任意に決定・設定するものである。

図８（ｂ）等に示す、各関数種別／各変数種別（上記４つの評価項目；ＡＰＩ（関数）、ローカル関数、グローバル変数、ローカル変数）毎の違反件数の集計結果に対して、これら重み係数をそれぞれ乗算することで、集計結果を補正する。当然、ＡＰＩ（関数）に係る集計結果に対しては、ＡＰＩ（関数）に対する重み係数（図示の例では‘１’）を乗算することになる。他の評価項目についても略同様であり、例えばローカル変数に係る集計結果に対しては、ローカル変数に対する重み係数（図示の例では‘４’）を乗算することになる。

図８（ｂ）に示す集計結果例に対して、上記図９（ａ）に示す４つの評価項目毎の重み係数によって重み付け処理を行った場合、図１０（ａ）に示す重み付け後の集計結果が得られることになる。

そして、最後に、図１０（ａ）に示すように、呼び出し元の各機能毎に、それぞれ、上記４つの評価項目それぞれの違反件数（重み付け後）の合計値を算出・登録する。例えば、機能２−１に関しては、１＋０＋４＋１２＝１７が、違反件数（重み付け後）の合計値となる。尚、このなかの‘１２’は、元々は‘３’であったが上記ローカル変数に対する重み係数（図示の例では‘４’）を乗算したことで、違反件数（重み付け後）＝３×４＝１２となったものである。同様に、‘４’は、元々は‘２’であったがグローバル変数に対する重み係数（＝２）を乗算したことで、違反件数（重み付け後）＝２×２＝４となったものである。

更に、これら各機能毎の違反件数（重み付け後）の合計値同士を加算して全体の総計値を求める（図示の例では、９＋０＋１７＋１４＋２５＋２７＝９２）。尚、更に図示のように４つの評価項目毎（各関数種別／変数種別毎）の違反件数（重み付け後）の合計値（１１，９，１２，６０）を求めるようにしてもよい。

尚、上記各重み係数は、４つの評価項目に対し、アクセス違反の重要度を示している。これは、４つの評価項目間での相対的な重要度を示すものと言える。本例では、重き係数の値が大きいほど重要度が高いものとなっている。従って、図示の例では、ローカル変数が最も重要度が高く、ＡＰＩ関数が最も重要度が低い。これは、換言するならば、呼び出し先がＡＰＩ関数であるアクセス違反が多くても後述する評価点数にはそれほど影響しない（さほど下がらない）が、呼び出し先がローカル変数であるアクセス違反が多いと、後述する評価点数に大きく影響する（点数が非常に低くなる）ことを意味する。

尚、重み係数の数値は、図９（ａ）に示す例に限るものではなく、例えば４つの評価項目の重み係数の合計が、１００％となるような重み付けでも良い。
また、重み付けを細かく行う場合には、「階層定義テーブル」に対応した機能間で個別に設定ファイルを設けても良い。

（２）足きりの閾値に関して
評価単位当たりの（例えば呼び出し元の各機能毎の）違反件数の上限として“足きりの閾値”を設定するようにしてもよい。この足きりの設定値は、開発者等が任意に決定してよく、図９（ｂ）に示す例では“足きりの閾値”＝１０．０となっている。以下の説明では、この一例を用いるものとするが、当然、この例に限るわけではない。

違反項目は、システム（製品）によって数が異なることが予想されるため上限が分からない。そのため、点数に差が開きすぎて、違反が多い機能があると他の機能が相対的に点数が良くなり、見過ごしやすくなるので、上限を決める“足きりの閾値”を設定できるようにしている。

点数化タスク部１２は、上記図１０（ａ）に示す重み付け後の集計結果と、これに基づく上記呼び出し元の各機能毎の違反件数（重み付け後）の合計値（以下、合計点数と言う場合もある）を求めたら、この合計値と各機能毎のプログラムステップ数とを用いて、アクセス違反点数化ファイル１８を生成する。

図１０（ｂ）に、アクセス違反点数化ファイル１８の一例を示す。
図示の例では、アクセス違反点数化ファイル１８には以下の項目があり、呼び出し元の各機能毎またはプログラムソース１９全体に対して、以下の各項目に応じた数値が算出・登録される。

（１）ステップ数［ＬＯＣ］
機能単位のプログラムのステップ数である。図示のように、基本的には各機能１−１〜機能３−２のプログラムステップ数は、それぞれ、異なるものであり、場合によっては大きく異なることになる。よって、上記違反件数が多いからといって単純に悪いものとは言えない（プログラムステップ数が非常に多いために、その分、違反件数も多いのかもしれない）。

（２）単位当りの点数
ＫＬＯＣ（１０００ステップ）当たりの違反検出数である。
上記のように機能毎にステップ数が異なるため、図１０（ａ）に示す重み付け後の合計点（合計点数）を、プログラムのステップ数で除算し、単位（１０００ＬＯＣ）当りの点数を算出する。

すなわち、上記合計点数と上記ステップ数［ＬＯＣ］とを用いて、下記の式により算出されるものである。
単位当りの点数＝合計点数÷（ステップ数［ＬＯＣ］／１０００）
＝{合計点数／ステップ数［ＬＯＣ］}×１０００

（３）足きり後の点数
単位当りの点数が足きりの閾値を越える場合に、足きりの閾値を単位当たりの点数とする。よって、図示の例では、機能３−２に関する単位当りの点数（１７．７３）のみが足きりの閾値（１０．０）を越えているので、１７．７３を１０．０に補正する。他の機能についてはそのままとする。

そして、単位当りの点数を、「０〜閾値⇒０〜１００」に正規化することで足きり後の点数とする。換言すれば、上記単位当りの点数を、上記足きりの閾値（１０．０）を１００点とする点数に置き換える。尚、これは、本例では閾値が１０．０であることから、単純に、上記単位当りの点数を１０倍することで（１０．０を乗算することで）、足きり後の点数が算出できる。また、尚、機能３−２に関しては、上記足きりを行っているので、１７７．３点とはならずに、図示の通り１００点となっている。

（４）評価点数
（３）の足きり後の点数のままでは、点数が０点の場合が、違反が無く、最も良い点数となるので、１００点を最も良い点数とするように換算したものが、評価点数である。
すなわち、評価点数＝１００−“足きり後の点数”
によって評価点数を算出する。
例えば、機能１−１の場合、足きり後の点数が３８．６点であるので、
機能１−１の評価点数＝１００−３８．６＝６１．４点
となる。

但し、この例に限るものではなく、足きり後の点数を、そのまま、評価点数としてもよい（評価の仕方が変わるだけである。すなわち、０点を最も良い点数とし、０点に近いほど評価が高いものとすることになる）。

また、全体としての評価点数を求めてよい。これは、例えば、上記プログラム全体の総違反件数（＝９２）と、プログラム全体の総ステップ数（＝３０１２１）とを用いて、上記機能毎の場合と略同様にして、まず、単位当りの点数を求め、必要に応じて足きりを行った後、評価点数へと換算する。図示の例では、単位当りの点数は３．０５であり、足きりを行う必要なく、そのまま１００点満点の点数系へと換算した後に（１０倍した後に）評価点数へと換算した結果、全体の評価点数は‘６９．５’となる。

但し、この例に限るものではなく、例えば、機能１−１から機能３−２までの６つの各機能の評価点数を加算して合計値を求め、この合計値を機能数（＝６）で除算することで、全体としての評価点数を求めるようにしてもよい。

以上のコンピュータ処理結果を用いて、例えば一例としては、上記各評価点数や全体の評価点数によって、開発者等が評価対象のプログラムの評価を行うようにしてもよい。しかしながら、例えば組込み用のプログラムの場合、図２のソフトウェア構造（階層と機能）の規定に（分かっていても）違反せざるを得ないケースが頻繁に発生するケースも有り得るので、評価点数が低いから悪いと言い切れない場合がある。

一方、プログラムを改良したりバージョンアップしたり流用する場合がある。また、この場合、最初の（ベースとなる）プログラムが古い場合も有り得る。この様な古いプログラムの場合、図２のソフトウェア構造（階層と機能）の規定など意識することなく作りこんでいる場合も少なくない。この様なプログラムに係るバージョンアップ版等のプログラムの場合、評価点数が高いことは期待できず、評価点数が少なくとも以前よりも低くならなければそれでよいと言うことが（最低でも現状維持とすることが）、現実的な評価基準となる場合が少なくない。

この様な観点から、上記評価点数を更に偏差値によって評価することが考えられる。
図１１に、その一例を示す。
図１１は、偏差値算出の具体例を示す図である。

図１１において、製品Ａが、今回の評価対象のプログラムであるものとし、よって図示のように点数（全体の評価点数）は６９．５点となっている。
一方、製品Ｂ〜製品Ｅは、製品Ａに関連するプログラムであって過去に作成されていたプログラム等である。これらの製品Ｂ〜製品Ｅについても、それぞれ、上記製品Ａと同様の処理によって点数（全体の評価点数）が求められている。

以上の５つの製品の点数（全体の評価点数）の平均値（図示の例では３８．７）を算出し、この平均値に基づいて図示のように各製品Ａ〜製品Ｅそれぞれの偏差値を求める。偏差値の求め方は、よく知られているので、ここでは特に説明しないが、まず上記平均値と求め、これに基づいて標準偏差を求め、以って偏差値を求まることになる。

そして、今回の評価対象の製品Ａの偏差値によって、製品Ａの評価を行う。
図示の例では製品Ａの偏差値は‘６１．９’となり、過去の製品と比べて改善していることが分かる。

以下、フローチャートを参照して、上記各種機能部の処理機能について説明する。
図１２は、上記サーバメイン処理部１１の処理フローチャート図である。
サーバメイン処理部１１は、例えば随時、操作端末１からの任意の要求の受信待ち状態となっており（ステップＳ１１）、ネットワーク２経由で操作端末１から何らかの要求が送られてくると、まず、この要求が点数化要求であるか、定義の登録要求であるか、それともこれら以外の要求であるかを判定する（ステップＳ１２，Ｓ１５）。

そして、操作端末１からの要求が点数化要求であれば（ステップＳ１２，ＹＥＳ）、点数化タスク部１２を呼び出し（ステップＳ１３）、点数化タスク部１２に処理実行させて、実行完了を待ちその結果を操作端末１に通知する（ステップＳ１４）。尚、点数化タスク部１２の処理フローは図１４に示し後に説明する。

一方、操作端末１からの要求が“定義の登録要求”であれば（ステップＳ１２がＮＯでステップＳ１５がＹＥＳ）、定義登録タスク部１３を呼び出し（ステップＳ１６）、要求があった定義（情報やプログラム等）の登録処理を実行させて、実行完了を待ちその結果を操作端末に通知する（ステップＳ１７）。

尚、上記何れの要求でもない場合には（ステップＳ１５，ＮＯ）、何も処理せずに終了する。
図１３は、定義登録タスク部１３の処理フローチャート図である。

ここで、操作端末１は、上記“定義の登録要求”を送信する場合には、登録対象の情報を付加して送信する。登録対象の情報は、例えば上記階層定義テーブル１５、動作情報定義テーブル１６、プログラムソース１９等である。

上記サーバメイン処理部１１は、上記ステップＳ１６の呼び出し処理の際に、上記“定義の登録要求”と共にこの要求に付加されている上記登録対象の情報を、定義登録タスク部１３に渡す。

これより、定義登録タスク部１３は、設定対象の情報の種類を判定し（ステップＳ２１）、その情報を該当するテーブル・ファイルに書き込む処理を行う。
すなわち、設定対象の情報が、階層定義テーブル、動作情報定義テーブル、プログラムソースファイル等の何れであるか、これら以外であるかを判定し、これら以外である場合には要求エラーと判定して（ステップＳ２５）、処理結果をエラーとする。

設定対象の情報が何らかの製品に係る階層定義テーブルである場合には、この情報を該当製品に係る上記階層定義テーブル１５として登録する（ステップＳ２２）。
設定対象の情報が何らかの製品に係る上記“重み計数”や“足きりの閾値”等である場合には、この情報を該当製品に係る上記動作情報定義テーブル１６に登録する（ステップＳ２３）。

設定対象の情報が何らかの製品に係るプログラムソースファイルである場合には、この情報を該当製品に係る上記プログラムソース１９として登録する（ステップＳ２４）。
そして、上記ステップＳ２２〜Ｓ２５の何れかの処理を実行完了したら、その処理結果をサーバメイン処理部１１に返して（ステップＳ２６）、本処理を終了する。

図１４は、点数化タスク部１２の処理フローチャート図である。
尚、ここでは、上記点数化要求には、点数化対象の製品を指定する情報が含まれているものとし、図１４の処理に係る各種情報／プログラムは、この指定製品に関する各種情報／プログラムであるものとする。

図１４（ａ）はメインフロー、図１４（ｂ）はステップＳ３３の詳細フローを示す。
（１）処理実行可能か否かの確認
点数化タスク部１２は、まず、点数化に必要な情報があるか否かを判定する（ステップＳ３１）。これは、例えば以下の２点を判定し、２点ともＯＫであれば点数化に必要な情報があると判定する
・“階層定義テーブル１５”、“動作情報定義テーブル１６”に定義が設定されている（但し、動作情報定義テーブル１６は必ずしも必要なものではない；必須ではない）。
・プログラムソース１９が登録済みである。

点数化タスク部１２は、点数化に必要な情報が無いと判定した場合には（ステップＳ３１，ＮＯ）エラーとしてエラー内容をサーバメイン処理部１１に返して（ステップＳ３９）、本処理を終了する。一方、点数化に必要な情報があると判定した場合には（ステップＳ３１，ＹＥＳ）、ステップＳ３２へ進み、点数化処理を実行する。

（２）機能毎にプログラムステップ数を計数・登録する。
まず、プログラムソース１９のプログラムステップ数を計数して（例えば各機能毎に計数して）、その結果を“アクセス違反点数化ファイル１８”に登録する（ステップＳ３２）。既に図１０（ｂ）を参照して説明したように、“アクセス違反点数化ファイル１８”には少なくとも評価点数算出処理の実行前には、各機能毎のステップ数（ＬＯＣ）が記憶されている必要がある。

ここで、プログラムソース１９は、複数のプログラムソースファイルより構成される。各プログラムソースファイルのファイル名は、例えば開発者等が予め決められた所定のルールに従って付与している。これは、例えば、ファイル名を参照すれば、どの機能に対応するプログラムソースファイルであるのかを判別できるようになっている。

すなわち、プログラムソース１９を構成する各プログラムソースファイルと各機能との対応関係は、本例では下記のａ）の方法を想定して“階層定義テーブル”等に機能コードを登録している。但し、この例に限らず、他の方法（例えば下記の、ｂ）,c）の方法）を行っても良い。

a)ファイル名に機能コードをつける。更に階層を示す情報も付加してもよい。
一例としては例えば、“xxxx_yyyy_abcdef.c”（xxxx:階層、yyyy:機能コード）のように、プログラムの命名規約を決定しておき、プログラムソース１９を構成する各プログラムソースファイルのファイル名は、この命名規約に従って付与させるようにする。尚、規約に反するプログラムはエラーとするチェック機能を別途備えるようにしてもよい。

これより、例えばプログラムソース１９を構成する各プログラムソースファイル毎に、そのファイルのプログラムのステップ数（行数等）をカウントすると共に、そのファイルのファイル名から上記機能コードを取得して、これらに基づいて図１０（ｂ）に示すアクセス違反点数化ファイル１８に各機能毎（機能コード毎）のステップ数を登録することができる。

尚、１つの機能に対して複数のプログラムソースファイルが存在する場合には、上記ファイル名に含まれる機能コードが同一である複数のプログラムソースファイルについてまとめて上記プログラム・ステップ数のカウント処理を行って、これらの合計値をアクセス違反点数化ファイル１８に登録することになる。

また、階層定義テーブル１５を参照する際や、アクセス違反計数ファイル１７の該当計数欄を見つける際にも、上記ファイル名を参照してその階層や機能コードを取得することになる。

b)ディレクトリ指定
ディレクトリ構造をソフトウェア階層と同じにして、その中に各プログラムソースファイルを格納する（例えばＳＣＩというディレクトリに、機能コードがＳＣＩである機能に係る全てのプログラムソースファイルを格納する。

c)定義ファイルに登録
階層と機能とプログラムソースファイル名との対応関係を、定義ファイル（不図示の定義マクロ、又は、定義テーブル等）に登録する。すなわち、この定義ファイルを参照すれば、どのプログラムソースファイルが、どの階層のどの機能に対応するものであるか判別できるようにする。

（３）アクセス違反を計数する。
評価対象の製品のプログラムソース１９について、階層定義テーブル１５を参照してアクセス違反を判定して、アクセス違反の数をアクセス違反計数ファイル１７上で計数する（ステップＳ３３）。これは、例えば上記４つの評価項目を対象とするものであるが、この例に限らない。

これは、上記の通り、階層定義テーブル１５には予め、呼び出し元２５（機能単位）と呼び出し先２４（各機能毎の関数種別／変数種別単位）のペア毎に、“違反なし”か“違反あり”が登録されている。一方、プログラムソース１９に係わる機能コードや関数／変数の種類（種別）は、例えば後述する方法によって識別可能である。これより、プログラムソース１９に関して呼び出し元の機能と呼び出し先の機能及び関数種別／変数種別とを認識し、階層定義テーブル１５を参照することで、違反の有無を判別できる。尚、ステップＳ３３の処理の詳細については、後に図１４（ｂ）に示す詳細フローを参照して説明するものとする。

（４）違反の計数結果に対して重み付けを行う。
動作情報定義テーブル１６に含まれる上記４つの評価項目に対する重み係数を用いて、上記ステップＳ３３によって得られた違反件数集計結果を補正することで、重み付け後の集計結果を求める（ステップＳ３４）。つまり、例えば、アクセス違反計数ファイル１７の集計値に、動作情報定義テーブル１６の重み計数値を乗算した結果を、不図示の重み付け後の集計結果ファイルに登録する。

（５）アクセス違反を点数化する。
例えば上述した評価点数を算出する（ステップＳ３５）。
評価点数の算出方法については、既に一例を用いて説明済みであるので、ここでは以下に簡単に説明するのみとする。

すなわち、上記“重み付け後の集計結果”を、プログラムステップ数（ＫＬＯＣ）で除算して更に所定単位（例えば１０００）を乗算することで、上記”単位当たりの点数“を求め、これを動作情報定義テーブル１６の上記“足きりの閾値”で必要に応じて足きりした後に“足きりの閾値”を１００点満点とする点数系に換算することで上記“足きり後の点数”を求め、「１００−“足きり後の点数”」を上記“評価点数”とする。

上記“評価点数”としては、（呼び出し元となる）各機能毎の評価点数や、プログラムソース１９全体としての評価点数等を求めることになる。

（６）偏差値を算出する
上記算出した評価点数を記憶すると共に、過去に他の製品等に関して上記“評価点数”が算出されて記憶されていた場合には、当該評価点数が記憶（登録）されている製品数が、予め任意に設定されている所定値以上（本例では５以上）であれば（ステップＳ３６，ＹＥＳ）、偏差値を算出する（ステップＳ３７）。

尚、偏差値の算出処理については、既に説明済みであるので、ここでは説明しない。
尚、評価点数算出・登録済みの製品数が所定値未満（５未満）である場合には（ステップＳ３６，ＮＯ）、そのままステップＳ３８の処理へ移行する。

（７）処理結果をサーバメイン処理に返す。
上記算出結果すなわち評価点数や偏差値等を、サーバメイン処理部１１に返す（ステップＳ３８）。
プログラム開発担当者等は、任意のプログラムを作成すると、上記管理サーバ１０によってそのプログラム構造を解析・点数化させることで、その評価点数、偏差値等によって、プログラムがソフトウェア構造設計通りに作成できたか、あるいは少なくとも過去の他製品に比べてレベルダウンしていないこと等を確認することができる。これは、数値化・点数化が行われたことで、客観的な分かり易い評価基準が示されるので、容易に的確な評価・判断を行うことができることになる。そして、たとえば、もし、レベルダウンしていると判断されるならば、開発担当者等は、プログラムの見直しを行うことになる。

尚、上記ソフトウェア構造設計とは、既に述べた通り、例えば、複数の機能より成るソフトウェアにおける機能間のアクセスに係る制限があるソフトウェア構造設計である。これに、更に、階層構造に係る制限も加わってもよい。階層構造に係る制限については、例えば一例を図２等で説明したように、複数の機能が階層化されたソフトウェア構造において、少なくとも相対的に下位側の機能から上位側の機能を呼び出すことは違反である、等の制限がある。これに加えて更に、上位側の機能から下位側の機能を呼び出す場合であっても、２段以上下層の機能を呼び出すことは違反となるようにしてもよい。

また、管理者は評価点数が基準値（過去の製品（変更前の製品等）の評価点数）以上であることを確認するだけで、開発初期の構造が維持できる。さらに、偏差値を算出することにより、過去の製品と比較して向上を図れるようにする。点数化することで客観的に品質を評価できる。

別の側面から言えば、本システムにより、以下の効果が得られるものといえる。
・プログラムそのものを見なくても、ソフトウェア構造を確認できる（開発効率化）。
・ソフトウェア構造が変わらないので、メンテナンス性を維持できる（保守性維持）。

過去の製品の評価点数と比べて、点数が下がらない場合には、ソフトウェア構造が変わらない（維持できている）（品質が下がらない）と判断できる。
尚、上記のようなソフトウェア構造設計の制限は、完全に守らなくても（多少違反があっても）、直ちにソフトウェアが正常に動作しないものとなるというものではない。例えば、一応は正常に動作するが、上記制限がある程度以上守られている（少なくとも過去よりは悪くなっていない）ことを確認したい場合（品質が下がらないことを確認したい場合）等に、本システムが有効利用できることになる。

以下、図１４、図１５を参照して、上記ステップＳ３３の処理の詳細例について説明する。尚、この例では、機能や関数種別／変数種別（４つの評価項目等）を、名称（プログラムソースファイル名、関数名、変数名）によって識別可能とした場合を示すが、この例に限らない。

ここでは、一例として、機能やプログラムソースファイル名や関数／変数の名称が、以下のルールに従って決められているものとする。また、このルールに基づくプログラム例を図１５に示す。

尚、ここでは機能コードが“ＳＣＩ”である機能の例を示すが、勿論、この例に限らない。
＊機能コードの判別
各プログラムソースファイルのファイル名の一部に、それが関係する機能の機能コードが含まれるようにしている。すなわち、例えば、予め決めたルールに従って、各プログラムソースファイル名の先頭が「機能コードを示す大文字＋“_”（アンダースコア）」となっている。尚、ここでは、更に、機能コードは３文字であるという規定もあるものとする。
具体例： プログラムソースファイル名＝SCI_Driver.c

よって、上記の例では、機能コード（機能名と見做してもよい）は“ＳＣＩ”であると判定する。尚、必ずしも１つの機能に１つのプログラムソースファイルのみが対応するとは限らない。１つの機能に複数のプログラムソースファイルが対応しても構わない。換言すれば、機能コードは、複数のプログラムソースファイルをグループ化するもの（複数のプログラムソースファイルから構成される機能に対して割当てられるもの）であってもよい。上記の例で言えば上記“SCI_Driver.c”以外にもファイル名の先頭３文字が“ＳＣＩ”であるプログラムソースファイルが存在するかもしれないことになる。

＊ＡＰＩ関数の判別
ＡＰＩ関数である関数は、全て、その関数名の先頭が「機能コードの大文字＋“_”（アンダースコア）」となっている。
具体例： SCI_Initial(void)；
尚、図１５には上記具体例を用いたプログラム例が示してある。

＊ローカル関数の判別
ローカル関数である関数は、全て、その関数名の先頭が「機能コードの先頭１文字が大文字で残りが小文字＋“_”（アンダースコア）」となっている。
具体例： Sci_FifoSet(void);
尚、図１５には上記具体例を用いたプログラム例が示してある。

＊グローバル変数の判別
グローバル変数である変数は、全て、その変数名の先頭が「“g_”+ 機能コードの先頭１文字が大文字で残りが小文字」となっている。
具体例： g_SciSendState;
尚、図１５には上記具体例を用いたプログラム例が示してある。

＊ローカル変数の判別
ローカル変数である変数は、全て、その変数名の先頭が「“g”+ 機能コードの先頭１文字が大文字で残りが小文字」となっている。
具体例： gSciExpcntlUS;

尚、図１５には上記具体例を用いたプログラム例が示してある。
尚、上記の例では、機能コードに関するルールとして「先頭にはｇは使わない」を追加することが望ましい。

上記のように、本手法では、プログラムソース文における関数／変数の名称には、その関数／変数の属する機能を示す情報と、その関数／変数の関数種別／変数種別を示す情報とが含まれている。これらの情報は、例えば上記一例のような所定のルールに従ったものである。このように、本手法では、関数／変数の名称を参照することで、その関数／変数の属する機能や、その関数／変数の関数種別／変数種別等を判別できる。

このように、本例では、名称によって機能及び関数種別／変数種別等を区別できるため、static変数等のようなソース内でのみ区別可能なものとは異なり、例えばある機能のグローバル変数と他の機能のグローバル変数とを区別することや、ある機能の変数と、これと同一の変数名の他の機能の変数とを区別できる。

以下、上記一例を用いながら、図１４（ｂ）に示す詳細フローチャート図について説明する。
図１４（ｂ）において、評価対象のプログラムソース１９を構成する全てのプログラムソースファイルを、順次、解析対象として（ステップＳ４１）、解析対象のプログラムソースファイルについてステップＳ４２〜Ｓ４６の解析処理を行うことを繰り返す。そして、全プログラムソースファイルについて解析処理が完了したら、ステップＳ４７の処理を行って、本処理は終了する。

以下、まず、ステップＳ４２〜Ｓ４６の処理について説明する。
まず、解析対象のプログラムソースファイルのファイル名に基づいて、その機能コード（機能名）を判定する（ステップＳ４２）。上記一例の場合、プログラムソースファイル名＝SCI_Driver.cであることから、機能コード（機能名）は“ＳＣＩ”であると判定する。また、図３に示す例では、機能コード２３が“ＳＣＩ”の機能の機能番号２２は、「機能１−１」となっている。つまり、これが、上記階層定義テーブル１５における呼び出し元２５の機能番号となる。

そして、解析対象のプログラムソースファイルについて、例えば１行目〜最終行までを順次参照して、任意の関数が任意の他の関数または変数の呼び出しを行う箇所を見つける毎に、当該呼び出し先の関数または変数の名称に基づいて、その関数種別／変数種別と呼び出し先の機能とを判別する。

すなわち、例えば、名称の先頭部分が、ｇで始まり、且つ、ｇの次が“_”（アンダースコア）である場合には、グローバル変数であると判定し、ｇの次が“_”ではない場合にはローカル変数と判定する。更に、“_”またはｇに続く３文字を抽出して、これを全て大文字にしたものを呼び出し先の機能の機能コードと認識する。

また、例えば、名称の先頭部分がｇ以外で始まる場合には、“_”（アンダースコア）を見つけて“_”より前の文字列を抽出し、抽出した文字全てが大文字である場合には、ＡＰＩ関数であると判定する。また、抽出した文字列のうち先頭の文字のみが大文字である場合には、ローカル関数であると判定する。また、何れに場合でも、抽出した文字列を全て大文字にしたものを呼び出し先の機能の機能コードと認識する。

以上の処理により、呼び出し元２５の機能番号と、呼び出し先の機能コード２３及び種別（呼び出し先２４に示す４つの評価項目の何れか；関数種別／変数種別）のペアを判別できるので、このペアに基づいて上記階層定義テーブル１５を参照して違反の有無を判定でき、更に違反であればアクセス違反係数ファイル１７の該当計数欄に計数することができる（ステップＳ４３，Ｓ４４，Ｓ４５，Ｓ４６）。尚、その際、呼び出し先が自機能である場合には、階層定義テーブル１５を参照することなく、違反なしと判定するようにしてもよい（図３で説明した通り）。

これより、例えば、呼び出し先が他機能のグローバル変数であれば、階層定義テーブル１５を参照して違反の有無を判定し、違反であればアクセス違反係数ファイル１７の該当計数欄に計数する（ステップＳ４３）。

同様に、呼び出し先が他機能のローカル変数であれば、階層定義テーブル１５を参照して違反の有無を判定し、違反であればアクセス違反係数ファイル１７の該当計数欄に計数する（ステップＳ４４）。

呼び出し先が他機能のＡＰＩ関数であれば、階層定義テーブル１５を参照して違反の有無を判定し、違反であればアクセス違反係数ファイル１７の該当計数欄に計数する（ステップＳ４５）。

呼び出し先が他機能のローカル関数であれば、階層定義テーブル１５を参照して違反の有無を判定し、違反であればアクセス違反係数ファイル１７の該当計数欄に計数する（ステップＳ４６）。

以上の処理を解析対象のプログラムファイルの全呼び出し処理に関して実行したら、未解析のプログラムファイルがある場合にはそれを次の解析対象として同様の処理を実行し、全てのプログラムファイルについて処理実行完了したらループを抜けてステップＳ４７の処理へと移行する。

ステップＳ４７では、階層定義テーブル１５の設定に従って、場合によっては、上記計数済みのアクセス違反係数ファイル１７の内容を補正する。これは既に述べたように例えば図４の例において‘０’、‘１’以外の値（例えば‘３’）が設定されている場合には、これを許容範囲等とする上述した補正を行う。既に述べた例では図７（ａ）に示す内容が図８（ａ）に示す内容へと補正されて、結果、図８（ｂ）に示す補正後の集計結果が得られることになる。

ステップＳ３４では、この様な補正後の集計結果を用いて、例えば上述した重み付けを行うことになる。
尚、上記図１２、図１３、図１４に示すフローチャートの処理は、既に述べたように、管理サーバ１０の不図示のＣＰＵ等が、不図示の記憶装置（ハードディスク、メモリ等）に予め記憶されている所定のアプリケーションプログラムを読出し・実行することにより実現される。

１ 操作端末
２ ネットワーク
１０ 管理サーバ
１１ サーバメイン処理部
１２ 点数化タスク部
１３ 定義登録タスク部
１４ 偏差値計数ファイル
１５ 階層定義テーブル
１６ 動作情報定義テーブル
１７ アクセス違反計数ファイル
１８ アクセス違反点数化ファイル
１９ プログラムソース
２１ 階層
２２ 機能番号
２３ 機能コード
２４ 呼び出し先
２５ 呼び出し元
３１ 階層
３２ 機能番号
３３ 機能コード
３４ 呼び出し先
３５ 呼び出し元

Claims (11)

1. 任意のソフトウェアのプログラムソースについて所定の評価を行うためのコンピュータシステムにおいて、
   複数の機能より成るソフトウェアの機能間のアクセスに係る制限に従って、呼び出し元となる機能と呼び出し先となる任意の機能の関数種別／変数種別との組み合わせ毎に、違反の有無が登録された違反有無記憶手段と、
   評価対象のソフトウェアのプログラムソース文を順次参照して、任意の機能の任意の関数から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、さらに前記違反有無記憶手段を参照して、該呼び出しが違反か否かを判定する違反判定手段と、
   前記違反判定手段による判定結果に基づいて、前記各機能毎または／及び前記評価対象のソフトウェア全体の違反件数を集計する集計手段と、
   該集計手段による違反件数の集計結果に基づいて、前記評価対象のソフトウェア全体または／及びその各機能毎の評価点数を算出する評価点数算出手段と、
   を有することを特徴とするプログラム構造評価システム。
2. 他の複数のソフトウェアについてそれぞれ前記評価点数が算出済みである場合に、前記評価対象のソフトウェアの評価点数も含む該複数の評価点数に基づいて、前記評価対象のソフトウェアの評価点数について偏差値を算出する偏差値算出手段を更に有することを特徴とする請求項１記載のプログラム構造評価システム。
3. 予め前記関数種別／変数種別毎に所定の重み値が登録された重み値記憶手段を更に有し、
   前記集計手段は、前記違反件数の集計の際に前記各関数種別／各変数種別毎の集計結果に対してそれぞれ該当する重み値を乗算して補正し、
   前記評価点数算出手段は、該補正後の集計結果に基づいて前記評価点数の算出を行うことを特徴とする請求項１または２記載のプログラム構造評価システム。
4. 前記評価点数算出手段は、前記各機能毎の評価点数を算出する際に、前記各関数種別／各変数種別毎の違反件数の集計結果に基づいて、単位ステップ数当りの違反件数を求め、該単位ステップ数当りの違反件数に基づいて前記評価点数を求めることを特徴とする請求項１〜３の何れかに記載のプログラム構造評価システム。
5. 前記評価点数算出手段は、前記単位ステップ数当りの違反件数に対して予め設定される足きりの閾値を用いて足きりを行った後の値を用いて前記評価点数を求めることを特徴とする請求項４記載のプログラム構造評価システム。
6. 前記各機能は、それぞれ、１または複数のプログラムソースファイルによって実現され、
   前記各関数種別は、ＡＰＩ関数、ローカル関数であり、
   前記各変数種別は、グローバル変数、ローカル変数であることを特徴とする請求項１〜５の何れかに記載のプログラム構造評価システム。
7. 前記プログラムソース文における前記関数／変数の名称には、その関数／変数の属する機能を示す情報と、その関数／変数の関数種別／変数種別を示す情報とが含まれていることを特徴とする請求項１〜６の何れかに記載のプログラム構造評価システム。
8. 前記複数の機能より成るソフトウェアは、該複数の機能が階層化されたソフトウェア構造となっており、
   該ソフトウェアに係る前記機能間のアクセスに係る制限事項は、少なくとも相対的に下位側の機能から上位側の機能を呼び出すことは違反であること、及び、任意の機能から他の機能の前記ローカル関数／ローカル変数を呼び出すことであることを特徴とする請求項６記載のプログラム構造評価システム。
9. 前記評価対象のソフトウェアは、組込みソフトウェアであり、
   前記階層化されたソフトウェア構造は、上位層がアプリケーション、中間層がミドルウェア、下位層がドライバであることを特徴とする請求項８記載のプログラム構造評価システム。
10. 任意のソフトウェアのプログラムソースについて所定の評価を行うためのコンピュータシステムにおいて、
    端末とサーバ装置とがネットワークに接続されたシステムであって、
    前記サーバ装置は、
    複数の機能より成るソフトウェアの機能間のアクセスに係る制限に従って、呼び出し元となる機能と呼び出し先となる任意の機能の関数種別／変数種別との組み合わせ毎に、違反の有無が登録された違反有無記憶手段と、
    前記端末から前記ネットワークを介して所定の点数化要求があると、評価対象のソフトウェアのプログラムソース文を順次参照して、任意の機能の任意の関数から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、さらに前記違反有無記憶手段を参照して、該呼び出しが違反か否かを判定する違反判定手段と、
    前記違反判定手段による判定結果に基づいて、前記各機能毎または／及び前記評価対象のソフトウェア全体の違反件数を集計する集計手段と、
    該集計手段による違反件数の集計結果に基づいて、前記評価対象のソフトウェア全体または／及びその各機能毎の評価点数を算出する評価点数算出手段と、
    を有することを特徴とするプログラム構造評価システム。
11. コンピュータを、
    複数の機能より成るソフトウェアの機能間のアクセスに係る制限に従って、呼び出し元となる機能と呼び出し先となる任意の機能の関数種別／変数種別との組み合わせ毎に、違反の有無が登録された違反有無記憶手段と、
    評価対象のソフトウェアのプログラムソース文を順次参照して、任意の機能の任意の関数から他の機能の任意の関数／変数を呼び出す処理を検出する毎に、該呼び出し先の関数／変数の関数種別／変数種別を判別して、さらに前記違反有無記憶手段を参照して、該呼び出しが違反か否かを判定する違反判定手段と、
    前記違反判定手段による判定結果に基づいて、前記各機能毎または／及び前記評価対象のソフトウェア全体の違反件数を集計する集計手段と、
    該集計手段による違反件数の集計結果に基づいて、前記評価対象のソフトウェア全体または／及びその各機能毎の評価点数を算出する評価点数算出手段、
    として機能させるためのプログラム。
    

Images