JP3703076B2 - 構造化文書により定義された品質管理及び品質評価ルールによるソフトウェア品質管理・評価方法、ならびにそのプログラムを記録した記録媒体 - Google Patents
構造化文書により定義された品質管理及び品質評価ルールによるソフトウェア品質管理・評価方法、ならびにそのプログラムを記録した記録媒体 Download PDFInfo
- Publication number
- JP3703076B2 JP3703076B2 JP2000087426A JP2000087426A JP3703076B2 JP 3703076 B2 JP3703076 B2 JP 3703076B2 JP 2000087426 A JP2000087426 A JP 2000087426A JP 2000087426 A JP2000087426 A JP 2000087426A JP 3703076 B2 JP3703076 B2 JP 3703076B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- evaluation
- quality
- value
- evaluation rule
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Stored Programmes (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ソフトウェア開発下流工程における品質管理・品質評価に関する処理方法に係り、特に、その品質管理・品質評価方法に柔軟性と発展性を持たせるのに好適な品質管理・評価方法、およびその処理プログラムを記録した記録媒体に関する。
【０００２】
【従来の技術】
ソフトウェア開発下流工程においては一般に、その開発対象ソフトウェアの品質管理・品質評価のために、設定したテスト件数などの静的なデータや、消し込み済みテスト件数、検出されたバグ数、解決されたバグ数あるいはテストカバレージ率などの動的なデータがそれぞれの工程のレベルに応じた区分で蓄積・管理される。そして、こうしたデータを所定の目標値と比較すること、または蓄積されたデータの経時的な変動の状況を分析することで、テスト十分性や信頼性の推定を行い、そのソフトウェアの品質が所定の水準に達しているか否かなどの評価を実施する。
【０００３】
また、例えば特開平５−３１３８８１号公報に記載の評価処理方法では、上記のような品質管理データに、過去の経験に基く知識情報を加味して総合的な残存欠陥数の推定を行うことができる処理方法が提案されている。
このうよな方法では、「目標値」や「信頼性成長モデル」の策定が重要になってくる。多くの場合、それは過去のプロジェクト事例の実績値やソフトウェア組織の方針に基づいて決定される。
【０００４】
従来の技術では、実績値と目標値に基く客観的な評価が可能になっている。
しかし、現実のソフトウェア開発では、このような「外形的な」数値比較だけでは不十分である。また、システム開発技法や実装技術の進歩、あるいは新しい管理技法などにより、過去の実績に基く指標だけでは対応できないこともありうる。異なる指標、場合によっては異なる考え方に基づいた評価方法が必要になってくる。そうした意味では、特開平５−３１３８８１号公報に記載の技術において、経験則から導出された知識情報による結果の補正は可能であるものの、それも特定の方法内のものでしかなく不十分である。
また、これらの技術では品質管理・評価を機械的に行うことを前提としている。しかし、どれほど「客観的」に管理・評価を行おうとしても、すべてを完全に機械化することは不可能で、いずれかの管理レベルで「主観的」な判断が介在する余地がある。すなわち、ソフトウェア品質管理を適正に実施するには、管理者の判断を支援し、さらにスキルの向上を促すような仕組みが存在することが望ましいが、従来の技術にはシステムとしてそれを支援する機能は存在しない。
【０００５】
【発明が解決しようとする課題】
前述のように、従来の技術では、品質管理・評価方法が定型的な特定の手法に限定されがちで、新しい品質管理・評価方法を開発あるいは導入することが難しい点、及び品質管理者の判断を支援し、スキルの向上を促進する仕組みが存在しない点がそれぞれ問題であった。
【０００６】
そこで、本発明の目的は、これら従来の問題点を解決し、従来からの品質管理・評価方法のみならず、新しい品質管理・評価方法を開発あるいは導入し、運用することが容易な品質管理・評価方法及びその処理プログラムを記録した記憶媒体を提供することにある。
【０００７】
【課題を解決するための手段】
上記目的を達成するため、本発明の構造化文書により定義された品質管理及び品質評価ルールによる品質管理・評価方法では、特定の方法による品質管理・評価用のデータの収集や、収集されたデータに対して特定のルールを適用して品質評価を行うことなく、特定の形式で品質管理・評価データがデータベースに蓄積されていることを前提に、該データベース（以下、品質データベースと呼ぶ）内のデータの参照方法、参照したデータの解釈方法、参照及び解釈を行った結果を提示する方法を記述した品質管理・評価ルール（以下、評価ルールと呼ぶ）を定義し、その評価ルールを品質データベースに対して適用することで品質管理・評価を実施する。
また、上記評価ルールを構造化文書、特にＸＭＬ（Extensible Markup Language）の形式で定義すること、及びその内容についての説明記述部を設けることで、評価ルールの流通（共有）を支援する。この評価ルールを記述したファイルを、評価ルール定義ファイルと呼ぶ。
【０００８】
【発明の実施の形態】
以下、本発明の実施例を、図面により詳細に説明する。
まず、その概要を説明する。
図１は、本発明が適用するプログラムとファイル、データリポジトリ等の関連を示すシステム構成図である。
図１において、１は評価ルールを保持するデータリポジトリ（ファイル保存部）である。典型的には、ＸＭＬデータを保持できるデータベースシステムや、ＸＭＬファイルを保存しているディスク装置の領域を指す。評価ルールファイル保存部１内部におけるデータの蓄積方法、形式は問わないが、利用にあたって評価ルールが外部に読み出される際には、ＸＭＬファイル形式あるいはＸＭＬとして解釈できるデータストリームとして読み出し可能でなければならない。もちろん、評価ルールファイル保存部１が通常のディスク装置上に評価ルールファイルを保存しているだけであれば、特別な読み出しの機構は必要ない。
【０００９】
２は本発明を利用する組織等における情報共有のための装置あるいはシステム（情報共有機能）である。典型的にはWorld Wide Webサイトである。これは必須のものではないが、評価ルールファイル保存部１の内容を読み取り、評価ルールファイル３として実装システムに表示することにより、組織等における情報共有を支援する。従って、もし情報共有機能２が配置されていない場合には、評価ルールファイル保存部１から直接、評価ルール読み込み部４に入力される。
３は、評価ルールを内容として含むＸＭＬファイルである。典型的には、ファイルの形態で、評価ルールファイル保存部１から直接、あるいは情報共有機能２を経由して読み出される。また、ファイルでなくＸＭＬデータとして解釈可能なデータストリームとして読み出されることもありうる。これは、次の項目で説明するように、一般には評価ルール読み込み部４が直接評価ルールファイル保存部１または情報共有機能２にアクセスして読み込みを行う場合に発生する。
４は、本発明に基く品質評価を実施する実装システム８（アプリケーションプログラム）の評価ルール読み込み部である。指定された評価ルールを保持するＸＭＬファイルを読み込むか、あるいは評価ルールファイル保存部１あるいは情報共有機能２に直接アクセスしてデータストリームの形態で読み込むことにより、評価ルールを実装システム８で利用可能な形態に展開する。
読み込み部４の実装方法は問わないが、典型的にはＸＭＬデータを構文的に解釈する部分（ＸＭＬパーサと呼ばれる部分）と、次に説明する評価ルール演算部５への業務的なインタフェースを提供する部分の２階層で構成される。
【００１０】
５は、実際に品質評価のための演算を行う演算部である。評価ルール演算部５は評価ルール読み込み部４で読み込まれた評価ルールに基づき、後述の評価ルール評価結果提示部７が指示する時点で指定の演算を行い、その結果を指定の方法であり、評価ルール評価結果提示部７に渡し、利用者に提示させる機能をもつ。
演算を実施するにあたっては、品質データベース６から指定の方法でデータを参照する。
６は、実装システム８による品質評価の対象となるソフトウェアプロジェクトにかかる品質データを蓄積している品質データベースである。この内容や構成については制限する必要はないが、一般的な方法でアクセス可能なデータリポジトリでなければならない。典型的には、ＳＱＬ（Structured Query Language）文による操作が可能なインタフェースを装備したリレーショナルデータベースである。
７は、品質評価の結果を利用者に提示する機能を提供する評価結果提示部である。
評価ルール読み込み部４で読み込まれた評価ルールに指定された時点で評価ルール評価結果提示部７が動作し、必要に応じて評価ルール演算部５で演算処理を行わせ、その結果に基づき、所定の提示を行うか否かなどを決定する。その提示方法は実装に依存するが、典型的には警告メッセージの表示、ログファイルへの書き込み、結果レポート（ファイル）の作成などが考えられる。
【００１１】
図２及び図２９は、品質評価ルールマークアップ言語ＱＥＭＬ（Quality Evaluation rule Markup Language ） Version 1.0 の概要を示したものである。評価ルール定義ファイルは、この形式に基づいて記述する。図２は、ＱＥＭＬの文書型定義（DTD）である。
図３は、図２の内容を図式的に表現したものであって、各要素の関係が階層構造を有していることが分かる。
図２９は、要素を一覧表示したものであって、図２の各要素番号に対応して、図２９の同じ要素番号の欄に名称、内容、属性の名称、属性の内容が表示されている。ＱＥＭＬは、ＸＭＬ規格に準拠したアプリケーションであり、そのため、評価ルール定義ファイルは、一般のテキストエディタやＸＭＬエディタを利用して容易に編集することができる。また、World Wide WebブラウザなどのＸＭＬ対応製品を利用すれば、その内容を容易に参照、表示することができる。さらに、内容のプログラム上の解析には、ＸＭＬを解析するためのアルゴリズムを流用できるので、本発明の実装も容易である。なお、これらの規定は改良のため仕様変更されることもありうる。
【００１２】
以下に、本発明におけるＱＥＭＬの規定の詳細を示す。なお、図２,図３および図２９中の要素番号は、互いに対応している。
【００１３】
qeml要素（００１）は、評価ルール定義ファイルの最上位要素である。
この下には、一つ以上のqeRule要素（００３）が存在する。
【００１４】
qeRule要素（００３）は論理的に関連する一連の品質評価ルールの定義を収容する要素である。qeRule要素同士は互いに独立し、自己完結的であることが望ましいが他のqeRule要素内の定義を参照してもよい。
qeRule要素は四つのセクションを示す四つの要素を収容する。すなわち、explain要素（００４）、dataAddress要素（００５）、rules要素（００６）、messages要素（００７）である。
【００１５】
explain要素（００４）は、それが属するqeRule要素の意味的な説明を記述する部分である。この要素内の情報は通常、利用者に情報を提供する目的で利用される。
典型的には、実装システムの評価手段選択画面での評価ルールリスト表示、ＷＷＷサーバ上での品質評価ルール一覧表示ページへのリスト表示のために用いられる。
explain要素は、title要素（００８）、category要素（００９）、description要素（０１０）、association要素（０１１）を含む。
【００１６】
title要素（００８）は属する品質評価ルールの名前を示す文字列を値としてもつ。
【００１７】
category要素（００９）はそれが属する品質評価ルールを分類するための文字列を値としてもつ。複数の視点からの分類を可能とするため、一つの品質評価ルールに一つ以上のcategory要素をもつことができる。
例えば、二つのcategory要素が、それぞれ「バグ消化曲線」及び「ＣＳシステム用」という値を持っているとすれば、その品質評価ルールは「帳票種別（あるいは評価方法）」及び「適用対象システム区分」という二つの視点からの分類が可能となる。また、こうした分類の種別を示すtype属性をもつことができる。この属性の値の許容値は実装依存で決定される。
【００１８】
description要素（０１０）は、それが属する品質評価ルールを詳細に説明する文章を値としてもつ。
典型的には、適用対象システムの前提条件、開発環境、プロジェクト要員のスキルなど、適用対象システムの特性を特定するための情報を記述する。利用者はその記述内容を参考にして、その品質評価ルールの適用可否を判断する。
【００１９】
association要素（０１１）は、description要素の内容を補強するために、関連情報を記述する。type属性で関連情報の内容の種類を特定する。許容値は実装依存する。
例えば、type属性が「URL」とされていれば、association要素の内容は参考とするURLとなり、「qeId」と記述されていれば関連する他の品質評価ルールとなる。
【００２０】
dataAddress要素（００５）は、属する品質評価ルールで使用される各種データの取得方法または取得先についての定義を行う。dataAddress要素はデータの種類（取得方法）毎に定義されるので、qeRule要素内に一つ以上存在する。
dataAddress要素は、datasource要素（０１２）、viewDefinition（０１３）を含む。
【００２１】
datasource要素（０１２）は、属するdataAddress要素のデータ取得元を識別するための情報を設定する。type属性でデータソースの種類を指定し、要素の値としてはデータソースへアクセスするための情報をもつ。これらの値は実装依存である。
典型的には、type属性値「RDB」で要素値はリレーショナルデータベース名、type属性値「XML」で要素値はＸＭＬファイルフルパス名、type属性値「SYS」で要素値は省略（システム情報を取得する）、type属性値「user」で要素値は省略（実装依存のデータ取得機能から取得する）、type属性値「manual」で要素値は省略（実装システムを経由して手入力の値を取得する）、などが考えられる。
【００２２】
viewDefinition要素（０１３）は、属するdataAddress要素のデータソースに対する一回のデータ取得操作ごとに、そのデータ取得操作の方法及びそれにより取得できるデータ項目の定義を記述する。
viewDefinition要素は、command要素（０１６）とvalue要素（０１７）を含む。
【００２３】
command要素（０１６）は、属するviewDefinition要素における、データ取得操作をデータソースに対して行う際のコマンド文字列の定義を記述する。内容は実装やデータソースの種類によって異なる。データソースがコマンド文字列などを必要としないような種類のものであれば、この要素は省略できる。
典型的には、データソースがリレーショナルデータベースであれば、データを取得するためのSQL文（SELECT文）、データソースがXMLファイルであれば、要素を指定するためのデータアドレッシング記述（例えば、XPath文字列など）、データソースがシステム情報であれば、その情報種別（例えば、システム日付など）を指定するための文字列が記述される。
この文字列にはparam要素（０２２）を含むことができるので、動的にコマンド文字列を変更することもできる。
command要素には二つの属性があるが、これらはいずれもリレーショナルデータベースのように複数のレコードが結果として返され得るデータソースに属するcommand要素での使用を前提としている。
type属性は、データ取得操作によって返される結果セットが本質的に単一(single)であるか複数(multiple)であるかを示す。デフォルトは「single」である。この値が「multiple」をとる場合、その結果セット（及びその参照）は結果セット内の特定レコードを明示的に指定しない限りは、常に集合的に扱われる。
key属性は、複数行が返されるデータ取得操作において、その結果セット内の行を一意に特定するために使用するキー項目を指定する。具体的な使用方法は実装に依存する。
これは、次に説明するvalue要素のposition属性の指定方法に影響を与える。
【００２４】
value要素（０１７）はcommand要素で指定されるデータ取得操作の結果として返されるデータ項目またはデータ項目の一部分を特定し、それに識別子を付与して、品質評価ルールのほかの部分から参照可能にするために使用される。この要素は属性のみを持ち、要素としての値は持たない。
varId属性は、そのデータ項目の一意識別子である。position属性は、関連するデータ取得操作結果セットのどの項目を指しているかを指定する文字列である。これは実装依存であるが、典型的には以下のようになる。
データソースがリレーショナルデータベースの場合、コマンドの選択リストの先頭項目を指すには、「@1」とする。この結果セットに複数行が含まれる場合は、全行の第１項目を指していることになる。複数行中の特定行の項目を指すには「$」を用いる。例えば、第三行の第二項目を指定するには、「@2$3」のように記述する。特定のキー値を持つ行の項目を指定する場合、例えば、command要素のkey属性が「keyA」と指定されていれば、「@3[5]」と記述することにより、keyA=5である結果セット中の行の第三項目を指定していることになる。
【００２５】
rules要素（００６）は、属する品質評価ルール中で用いる数式のコレクションである。
【００２６】
rule要素（0１４）は、rules要素に少なくとも一つ含まれる数式の定義である。ruId属性はrule要素の一意識別子である。
rule要素はmath要素（００２）とpath要素（０１８）を含む。
【００２７】
math要素（００２）は、数式を指定する。数式の指定にはWorld Wide Web consortiumで標準化された数式記述言語MathML(TM)を取り込んで使用する。図２では、便宜上MathML(TM)のDTDの所在位置を「mmlents\mathml.dtd」としているが、現実のシステムでは実際の所在位置が記述される。
MathML(TM)の要素のうちどの要素がどのようにサポートされるのかは実装に依存する。
【００２８】
path要素（０１８）は、math要素で指定される数式の特定の要素にパラメタを与えるために用いる。パラメタの指定が不要であれば省略可能である。要素の値として、math要素の特定の下位要素を指し示すための文字列を持つ。この文字列の書式は、World Wide Web consortiumで標準化された標準のXML文書部品指示言語であるXPathである。例えば、math要素とその子孫要素が
<math > <apply><plus/> <ci>a</ci><cn>5</cn></apply></math>
のように定義されている場合に、最初のci要素を指定する場合、「apply/ci」とする。
associatedData属性は、埋め込む値を示す識別子を指定する。これはvalue属性のvarId属性の値か、他rule要素のruId属性の値である。これらの値は循環参照を避けるように指定しなければならない。（循環参照を避ける方法は実装に依存する。）また、値が評価されるのは、数式が評価される時点である。さらに、この値は数値として評価される。
もし、associatedData属性が参照するデータ項目が集合的であった場合、math要素の評価はそのデータ項目のそれぞれについて実行される。また、同一のmath要素に設定する複数のpath要素が参照するデータ項目が同一のviewDefinition要素に属し、かつそれらが集合的であった場合、それらの値を個別に参照して評価するのではなく、同期を取って評価する。例えば、あるmath要素に関連する上記の条件を満たすpath要素が二つあり、そのデータ集合に三つのデータが含まれる場合、math要素の評価回数は九回ではなく、三回になる。
type属性及びindex属性は[００３４]で後述するparam属性（０２２）のtype属性及びindex属性と同様の内容を持つ。
【００２９】
messages要素（００７）は品質評価の実行時期、評価方法、評価結果の提示方法を定義したmessage要素（０１５）をまとめるコレクション要素である。
【００３０】
message要素（０１５）は、個別の品質評価の実行時期、評価方法、評価結果の提示方法を定義する。こうした一組の定義をメッセージと呼び、このメッセージを処理することをメッセージ処理と称する。
message要素はpointOfTime要素（０１９）、criteria要素（０２０）、msgDescription要素（０２１）を含む。
msgId属性は当該message要素の一意識別子である。
【００３１】
pointOfTime要素（０１９）は、属するmessage要素の評価がいつ実行されるかを定義する。その値は実装に依存するが，典型的には、「REQUIRED」（利用者が明示的に要求したとき）、「LOADED」（評価ルール定義ファイルが実装システムに読み込まれたとき）、「CHANID=nnnn」（msgId属性の値がnnnnの別のmessage要素が評価されたときに連鎖して実行）などとなる。複数の時点で評価される可能性があるため、一つのmessage要素に一つ以上のpointOfTime要素を定義できる。
【００３２】
criteria要素（０２０）は、属するmessage要素の評価が成立する条件を定義する。
要素の値は、比較演算子（＜、＜＝、＝、＞＝、＞）、論理演算子（AND,OR,NOT）、括弧、及びパラメタによる条件式である。パラメタは固定文字列を直接記述する場合と、param要素（０２２）によって数式やデータ項目の値を参照する場合がある。条件式の評価結果が真であれば、そのmessage要素の評価が成立したことになる。criteria要素が省略された場合、そのmessage要素は常に成立することになる。
【００３３】
msgDescription要素（０２１）は、criteria要素の条件式が成立し、message要素の評価が成立したときに利用者に提示される情報を定義する。
msgDescription要素は、属するmessage要素が別のmessage要素に従属する、すなわち、別message要素内のcriteria要素内のparam要素で参照されるためだけに記述されている場合は省略される。また、同時に複数の手段で利用者に提示される場合は必要な数だけ定義される。
type属性の値は、実装に依存するがmsgDescription要素の内容を利用者に提示する手段を指定する。典型的には、「MSGBOX」（ポップアップダイアログボックスによるメッセージ表示）、「LOGFILE」（所定のログファイルへの書き込み）、「MAIL」（所定の管理者宛ての電子メール送信）などがある。
要素の値は、type属性で指定された提示方法と実装に依存する。
【００３４】
param要素（０２２）は、データ項目、数式、メッセージを参照する為に用いる。
command要素（０１６）に埋め込まれた場合は、主にそのコマンド文字列の変数として埋め込むデータ項目や数式（の計算結果）を参照する。
criteria要素（０２０）に埋め込まれた場合は、その条件式の変数として埋め込むデータ項目や数式（の計算結果）や別メッセージの（criteria要素の）評価結果を参照する。
msgDescription要素（０２１）に埋め込まれた場合は、そのメッセージ内に埋め込むデータ項目や数式（の計算結果）や別メッセージの（criteria要素の）評価結果を参照する。
param要素は要素としての値をもたない。
from属性で埋め込むデータの識別子を参照することで埋め込みデータを指定する。埋め込むデータが、データ項目の場合は、当該データ項目（value要素）のvarId属性値、数式の演算結果の場合は当該数式（rule要素）のruId属性値、メッセージの評価結果の場合は、当該メッセージ（message要素）のmsgId属性値を設定する。
【００３５】
type属性はfrom属性で参照されるデータの種類を示す値を設定する。参照データ項目が、データであれば「V」、数式であれば「R」、メッセージであれば「M」である。デフォルトは「V」である。
index属性は集合的なデータの中から特定のデータのみを指定する場合に用いる。集合的でないデータに設定した場合は無視される。値の指定方法は三種類ある。符号無しの数値を指定した場合、そのデータ集合の先頭のデータを1とした絶対出現順でデータが指定される。符号付の数値を指定した場合、プラス記号がつく場合はデータ集合の先頭からの相対位置、マイナス記号がつく場合はデータ集合の末尾からの相対位置でデータが指定される。上記のいずれでもない場合、データ項目の識別子（varId）と見做し，そのデータ内容を参照する。そのデータ項目が集合的である場合や、数値以外のものを返す場合、あるいは該当する識別子が存在しない場合はindex属性の指定はなかったものとする。結果の値は絶対位置の指定として処理される。いずれの指定方法でも、データ集合の範囲外が指定された場合は、もっとも近い正当なデータ項目を指すように補正される。この属性が指定されている場合は、その参照元を集合的ではないものとして扱う。
例えば、あるデータ集合（1,5,2,4,7,10）があったとすると、index属性の値が、「1」または「+0」または「-5」の場合は1、「6」または「-0」または「+5」の場合は10、「3」または「+2」または「-3」の場合2を指す。「7」の場合は「6」に補正されて10を指し、「-10」の場合は「-5」に補正されて1を指す。
【００３６】
次に、評価ルール定義ファイルの定義例と実装システム例を元に本発明の適用方法を説明する。説明に使用する実装システム例のシステム名はＱＳ１と呼ぶ。
以下の文中で「ＱＳ１では・・」等と記載された場合、それはＱＳ１における実装例であり、別の実装ではまた異なる実装方法をとることも可能であることを意味する。また、「データ「nnn」」という表現があった場合、それはデータ識別子（varId属性）で値「nnn」を指定され、その識別子で参照されるデータを意味する。数式やメッセージについても同様である。
図４〜図８は、評価ルール定義ファイルの一例を示した図である。
このファイルには一つの品質評価ルール（行００５〜２３９）が含まれる。これは、ＣＯＢＯＬ言語で書かれたプログラムのソースコード行をベースとした単体テスト品質評価を行うためのものある。
機能は、プログラムチェックリスト消し込み予測及びバグ摘出累積件数予測グラフ、及びそれらの実績グラフの表示と、評価実行時におけるバグ摘出累積件数の実績／予測の乖離率を算出し、それが上下20％を越えた場合に警告を発するというものである。
【００３７】
ＱＳ１においては、所定のディレクトリに格納されている評価ルール定義ファイルを一括して読み込み、利用者に適用する品質評価ルールを選択させる仕様になっている。この処理には、定義ファイル内のexplain要素の内容を用いる。図４であれば、行００６〜行０１４が該当する。
【００３８】
図９は、ＱＳ１における評価ルール選択画面の表示例図である。
この画面においては、画面部品２０１でカテゴリタイプ（分類の視点）を画面部品２０２でそのカテゴリタイプに含まれるカテゴリを選択することで、それに該当する品質評価ルールの名称が画面部品２０３に一覧表示される。
この例においては、「プログラム言語」の視点から「ＣＯＢＯＬ」言語に関する品質評価ルールを一覧しているが、図４の評価ルール定義ファイルは行００８において、type属性の値が「PrgL」（ＱＳ１の表現では「プログラム言語」）で、要素値が「COBOL」（ＱＳ１の表現では「ＣＯＢＯＬ」）であるcategory要素を記述しているため、画面部品２０３の評価ルール一覧に、title要素（行００７）の要素値を表示している。
図１０は、図９とは異なる視点で分類した評価ルール選択画面の表示例図である。
この例においては、「基準指標」（画面部品３０１）の視点から「ソース行数」（画面部品３０２）を基準とした品質評価ルールを一覧（画面部品３０３）している。図４の評価ルール定義ファイルは行００９において、type属性の値が「Base」（ＱＳ１の表現では「基準指標」）で、要素値が「LOC」（ＱＳ１の表現では「ソース行数」）であるcategory要素を記述しているため、この画面でも一覧表示されている。
【００３９】
図１１は、ＱＳ１における評価ルール詳細画面の表示例図である。
この画面は、図９または図１０の画面部品４０３で評価ルールを選択し、画面部品４０４を押下することで表示され、選択した評価ルールのexplain要素の内容を参照できる。
この例においては、図４の評価ルール定義ファイルの評価ルール「B001」（行００５）を示している。画面部品４０１にはtitle要素値が表示される。ここでは行００７のtitle要素の値が表示されている。画面部品４０２にはcategory要素の内容が表示される。ここでは、行００８〜行０１１の内容が反映されている。なお、カテゴリタイプ（type属性）の値はＱＳ１においては、「PrgL」は「プログラム言語」、「Base」は「基準指標」、「Proc」は「適用工程」、「Doc」は「文書種別」とマップされ、カテゴリ（category要素値）の値はＱＳ１においては、「COBOL」は「ＣＯＢＯＬ」、「LOC」は「ソース行数」、「UT」は「単体テスト（ＵＴ）」、「BugExtractionCurve」は「ＰＣＬ／バグ摘出曲線」とマップされ表示されている。
【００４０】
ＱＳ１においては、評価ルール選択画面で評価ルールを選択して実行することで、その評価ルールが有効になり、定義された手順で品質評価が実行される。この操作は、図９あるいは図１０の画面部品２０３，３０３から評価ルールを選択し、画面部品２０５，３０５を押下することである。
ここでは、評価ルール「B001」が実行されたものとして、以下その処理の流れを説明する。
【００４１】
まず、評価ルール「B001」で使用するデータについて説明する。
図３０は、評価ルール「B001」で使用するデータの概要を一覧表にまとめた図である。
これらのデータの定義は、図４，図５の行０１５〜行０９２に記述されているdataAddress要素から導かれる。
【００４２】
図３０の行１は図４の行０１８〜行０２１のviewDefinition要素に対応する。
図４の行０１５〜行０２２のdataAddress要素が定義するデータのデータソースのタイプは、図４の行０１７のdatasource要素の定義により、ＱＳ１においては手入力（type="MANUAL"）である。その中で、このviewDefinition要素は要素値をTargetModuleとするcommand要素（図４の行０１９）を持つ。これは、ＱＳ１においてTargetModuleという名前で識別される値を要求することを意味する。
この値は、ＱＳ１が表示するダイアログボックスを用いて利用者から入力される。こうして取得された値は、評価ルール内で、データ識別子「B001VM01」で参照される（図４の行０１８）。
command要素がもつデータ値は一つだけなので、position属性の指定は不要である。
【００４３】
図２０の行２は、図４の行０２６〜行０３０のviewDefinition要素に対応する。
図４の行０２３〜行０３１のdataAddress要素が定義するデータのデータソースのタイプは、図４の行０２５のdatasource要素の定義により、ＱＳ１においてはシステム情報（type="SYSTEM"）である。その中で、このviewDefinition要素は要素値をSYSDATEとするcommand要素（図４の行０２８）を持つ。これは、QS１においてはシステム日付を参照することを意味する。この値は、評価ルール内で、データ識別子「B001VS01」で参照される（図４の行０２９）。command要素がもつデータ値は一つだけなので、position属性の指定は不要である。
【００４４】
図３０の行３〜行６は、図４の行０３２〜行０５８のdataAddress要素に対応する。このdataAddress要素が定義するデータのデータソースのタイプは、図４行０３４のdatasource要素の定義により、ＱＳ１においてはユーザ定義関数（type="USERS"）である。ユーザ定義関数とは、ここでは、実装系が独自に提供する関数を指す。
図３０の行３は、図４の行０３５〜行０４０のviewDefinition要素に対応する。
ユーザ定義関数のcommand要素値の書式は、ＱＳ１では、関数名と引数群の列挙である。引数は、param要素またはカンマ区切りの定数で記述する。
図４の行０３７のcommand要素は、CalcCalendar1という名称のユーザ定義関数をデータ「B001VD04」と、データ「B001VD02」を引数として実行することを意味する。
「B001VD04」「B001VD02」については、詳細は後述するが、それぞれ「テスト予定日数」「テスト開始日」を意味する。ＱＳ１のCalcCalendar1関数は指定した日付を含め、その日から指定した日数分の日付を返却する関数なので、このcommand要素の内容を実行すれば、予定どおりにテストが進捗した場合のすべての日付が取得できる。このcommand要素の実行結果は複数の結果を返すので、「type="MULTIPLE"」を指定する。この値はデータ識別子「B001VF01」で参照される（図４の行０３９）。
ＱＳ１においては、複数の結果を返す場合、それが内部的な計算に利用される場合は集合的に処理され（計算をデータ数分繰り返す）、外部出力される場合はカンマ区切りの文字列に変換して渡される。
【００４５】
図３０の行４は、図４の行０４１〜行０４６のviewDefinition要素に対応する。
図４の行０４３のcommand要素は、CalcCalendar2という名称のユーザ定義関数をデータ「B001VD04」と、データ「B001VS01」を引数として実行することを意味する。ＱＳ１のCalcCalendar2関数は指定した日付を両端とする期間に含まれる日付すべてを列挙する関数なので、ここでは、テストの開始日から現在までのすべての日付が返される（「B001VD04」は「テスト開始日」、「B001VS01」は「システム日付」を意味するため）。このcommand要素の実行結果は複数の結果を返すので、「type="MULTIPLE"」を指定する。この値はデータ識別子「B001VF02」で参照される（図４の行０４５）。
【００４６】
図３０の行５は、図４の行０４７〜行０５２のviewDefinition要素に対応する。
図４の行０４９のcommand要素は、CalcCalendar3という名称のユーザ定義関数をデータ「B001VD04」と、データ「B001VS01」を引数として実行することを意味する。ＱＳ１のCalcCalendar3関数は指定した日付間の日数を計算する関数なので、ここでは、テストの開始日から現在までの日数が返される（「B001VD04」は「テスト開始日」、「B001VS01」は「システム日付」を意味するため）。この値はデータ識別子「B001VF03」で参照される（図４の行０５１）。
【００４７】
図３０行６は、図４の行０５３〜行０５７のviewDefinition要素に対応する。
図４の行０５５のcommand要素は、Rangeという名称のユーザ定義関数を固定値「1」とデータ「B001VD02」を引数として実行することを意味する。QS１のRange関数は指定した数値を両端とする範囲に含まれる整数をすべて列挙する関数なので、ここではテスト開始日からテストの予定終了日までの各日におけるテスト開始日からの経過日数すべてが返される（「B001VD02」は「テスト予定日数」を意味するため）。このcommand要素の実行結果は複数の結果を返すので、「type="MULTIPLE"」を指定する。この値はデータ識別子「B001VF04」で参照される（図４の行０５６）。
【００４８】
図３０の行７〜行９は、図５の行０５９〜行０８４のdataAddress要素に対応する。
このdataAddress要素が定義するデータのデータソースタイプは、図５の行０６１のdatasource要素の指定により、ＱＳ１ではリレーショナルデータベースである（type="RDB"）。このdatasource要素は要素値「QE0001」を持っているが、これはＱＳ１では、データベース名「QE0001」のデータベースを利用することの指定である。
図３０に、データベース「QE0001」のテーブル定義の一部（単体テストに関連する部分）を示す。
モジュール別単体テスト工程管理表では、システムに含まれるすべてのモジュールの単体テスト工程に関する基本情報を保持する。
「モジュールＩＤ」は、モジュールの一意識別子である。
「実績ステップ数」は、モジュールの実際のステップ数である。
「単体テスト予定日数」は、単体テストの所要日数の見積もりである。
「単体テストチェック件数」は、単体テスト用プログラムチェックリストに設定されたチェック件数である。
「単体テスト実績開始日」は、実際に単体テストが開始された日付である。
「単体テスト実績終了日」は、単体テストが終了した時に、その日付を設定する。
モジュール別チェック項目管理表は、単体テスト用プログラムチェックリストに設定されたチェック項目の基本情報と、その消し込み状況を保持する。
「モジュールＩＤ」は、モジュールの一意識別子である。
「チェックＩＤ」は、チェック項目の一意識別子である。「モジュールＩＤ」と「チェックＩＤ」の組み合わせでレコードを一意に識別する。
「チェック種別」は、そのチェック項目の種類のものであるかを示す文字を設定する。
例えば、通常処理をチェックする項目であれば「N」、異常処理をチェックする項目であれば「E」などである。
「消し込み日」は、そのチェック項目のチェックが完了した日を設定する。
モジュール別バグ管理表は、摘出されたバグを履歴的に一覧管理する表である。
「バグ通番」は、バグの一意識別子である。
「モジュールＩＤ」は、モジュールの一意識別子である。
「チェックＩＤ」は、チェック項目の一意識別子である。「モジュールＩＤ」と「チェックＩＤ」はモジュール別チェック項目管理表を参照する外部キーである。
「発生日」は、そのバグが発生した日である。
「解決日」は、そのバグが解決した日である。
【００４９】
図３０の行７は、図５の行０６３〜行０７０のviewDefinition要素に対応する。
データソースタイプがリレーショナルデータベースの場合、command要素の要素値は発行するＳＱＬ文など、そのデータベースが受け入れるコマンド文字列になる。
そのため、図５の行０６４のcommand要素の要素値は、param要素で参照するデータ「B001VM01」が仮に「AX001D05」であったとすると、ＳＱＬ文「SELECT MDST,MDPC,MDCC,MDAB FROM MUTS WHERE MDID='AX001D05'」であると解釈される（'はＸＭＬ文書においては単一引用符を意味する）。このＳＱＬ文を実行すると、モジュール別単体テスト工程管理表（MUTS）から、指定のモジュールＩＤ（MDID）のモジュールの、実績ステップ数（MDST）、単体テスト予定日数（MDPC）、単体テストチェック件数（MDCC）、単体テスト実績開始日（MDAB）を取得できる。モジュールＩＤは一意であるので返される結果は単一である。
図５の行０６６のvalue要素の定義により、結果の第１カラム（position="@1"）、すなわち実績ステップ数は「B001VD01」で参照される（varId="B001VD01"）。
図５の行０６７のvalue要素の定義により、結果の第２カラム（position="@2"）、すなわち単体テスト予定日数は「B001VD02」で参照される（varId="B001VD02"）。
図５の行０６８のvalue要素の定義により、結果の第３カラム（position="@3"）、すなわち単体テストチェック件数は「B001VD03」で参照される（varId="B001VD03"）。図４の行０６９のvalue要素の定義により、結果の第４カラム（position="@4"）、すなわち単体テスト実績開始日は「B001VD04」で参照される（varId="B001VD04"）。
【００５０】
図３０の行８は、図５の行０７２〜行０７７のviewDefinition要素に対応する。
図５の行０７３のcommand要素の要素値は、param要素で参照するデータ「B001VD03」が仮に「112」で、データ「B001VM01」が仮に「AX001D05」で、データ「B001VF02」が仮に「2000/2/1,200/2/2,2000/2/3,2000/2/4」の複数の値であるとすると、ＳＱＬ文「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND MCEL<=TO_DATE('2000/2/1')」「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND MCEL<=TO_DATE('2000/2/2')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL<=TO_DATE('2000/2/3')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL<=TO_DATE('2000/2/4')」
であると解釈される（<はＸＭＬ文書においては「<」を意味する）。
これらのＳＱＬ文を実行すると、モジュール別チェック項目管理表（MUTC）を集計し、指定のモジュールＩＤ（MDID）のモジュールの、指定日以前の消し込み日（MCEL）を持つレコードの総件数をチェック項目総数から差し引いた値が返される。すなわち、この例では、2000/2/1〜2000/2/4までの各日におけるチェックリスト残件数が取得できる。このＳＱＬ文自体は単一の結果しか返さないが、指定のパラメタが複数の値をとりうるため、結果として複数の結果を持つことになる。
図５の行０７６のvalue要素の定義により、結果の第1カラム（position="@1"）、すなわちチェックリスト残件数は、「B001VD06」で参照される（varId="B001VD06"）。
【００５１】
図３０の行９は、図５の行０７９〜行０８４のviewDefinition要素に対応する。
図５の行０８０のcommand要素の要素値は、param要素で参照するデータ「B001VM01」が仮に「AX001D05」で、データ「B001VF02」が仮に「2000/2/1,200/2/2,2000/2/3,2000/2/4」の複数の値であるとすると、ＳＱＬ文「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND MBOD<=TO_DATE('2000/2/1')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND
MBOD<=TO_DATE('2000/2/2')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND
MBOD<=TO_DATE('2000/2/3')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND
MBOD<=TO_DATE('2000/2/4')」
であると解釈される。
これらのＳＱＬ文を実行すると、モジュール別バグ管理表（MUTB）を集計し、指定のモジュールＩＤ（MDID）のモジュールの、指定日以前の発生日（MBOD）を持つレコードの総件数を返す。すなわち、この例では2000/2/1〜2000/2/4までの各日におけるバグ摘出累積件数が取得できる。このＳＱＬ文自体は単一の結果しか返さないが、指定のパラメタが複数の値をとりうるため、結果として複数の結果を持つことになる。
図５の行０８２のvalue要素の定義により、結果の第1カラム（position="@1"）、すなわちバグ摘出累積件数は、「B001VD07」で参照される（varId="B001VD07"）。
【００５２】
図３０の行１０は、図５の行０８８〜行０９１のviewDefinition要素に対応する。
このviewDefinition要素が属するdataAddress要素（図５の行０８５〜行０９２）が定義するデータのデータソースタイプは、図５の行０８７のdatasource要素の定義により、ＱＳ１ではＸＭＬ文書である（type="XML"）。このdatasource要素は要素値として「standards.xml」を持っているが、これはＱＳ１では、「standards.xml」というファイル名のXML文書を参照することを意味する。
データソースタイプがXML文書である場合、ＱＳ１ではcommand要素の要素値は、XPathの構文となり、その構文で指定されるＸＭＬ文書要素または属性の値が、command要素の実行結果の値となる。
図５の行０８９のcommand要素は、standards.xmlファイルのstandards文書要素の子要素utの子要素bugDensityKLOC要素の値（ここでは1Kステップ行当りのバグ件数を示す）を参照している。
この値は、図５の行０９０のvalue要素の定義により、データ識別子「B001VX01」で参照される（varId="B001VX01"）。
図３１（ａ）（ｂ）（ｃ）は、図１における品質データベース６の構成例を示す図である。
【００５３】
次に、評価ルール「B001」で使用する数式について説明する。
図３２は、評価ルール「B001」で使用する数式の概要を一覧表にまとめた図である。
これらのデータの定義は、図５〜図７の行０９４〜行２０９に記述されているrules要素から導かれる。
【００５４】
図３２の行１は、図５の行０９５〜行１１６のrule要素に対応する。
この要素で定義する数式の識別子は「B001R01」である（ruId="B001R01"）。
数式自体の定義は、MathML(TM)にしたがって記述する。このrule要素の数式は、図５の行０９７〜行１１０のmath要素で定義されている。
MathML(TM)では演算の最小単位をapply要素で表現する。基本的には、apply要素の最初の子要素に、その演算方法（加算、減算など）を示す要素を設定し、それに続いてオペランドを指定する子要素を設定する。オペランドが数字であればcn要素で定義し、そうでないならci要素で定義する。また他のapply要素を子要素にすることもできる。
例えば、「a+1」をMathML(TM)で表現すると、
<apply><plus /><ci>a</ci><cn>1</cn></apply>
のようになる。
従って、図５の行１０２〜行１０５のapply要素は「k+1」を示し、図５の行１００〜行１０６のapply要素は「k/(k+1)」を示し、図５の行０９９〜行１０７のapply要素は「log0.04236(k/(k+1))」を示し、図５の行１０８のapply要素は「1/t」を示し、図５の行０９８〜行１０９のapply要素は、「(log0.04236(k/(k+1)))^(1/t)」を示す（＾は累乗を表す）。
こうして表現された数式を実際に計算するには、変数の部分に値を設定する必要があるが、これはmath要素に続くpath要素で行う。
path要素では設定するデータの指定をassociatedData属性で、設定先を要素値のXPath構文で指定する。
図５の行１１２のpath要素ではデータ「B001VD03」をmath要素の子のapply要素の最初の子apply要素の子のapply要素の子のci要素（図５の行１０１）に設定することを示している。
図５の行１１３のpath要素ではデータ「B001VD03」をmath要素の子のapply要素の最初の子apply要素の子のapply要素の子のapply要素の子のci要素（図５の行１０３）に設定することを示している。
図５の行１１５のpath要素では、データ「B001VD02」をmath要素の子のapply要素の２番目の子apply要素の子のci要素（図５の行１０８）に設定することを示している。
この数式を計算すると、予定の日数で単体テストが終了する（収束する）場合のチェック項目残件数予測グラフを描画するためのゴンペルツ曲線の傾きを決定する値を計算することができる。
【００５５】
図３２の行２は、図６の行１１７〜行１３８のrule要素に対応する。
この要素で定義する数式の識別子は「B001R02」である（ruId="B001R02"）。
数式自体（図６の行１１９〜行１３２）は「B001R01」の数式と同様であるが、変数に設定する値が一部異なっている。
数式「B001R01」でデータ「B001VD03」を埋め込むところには、数式「B001R03」の演算結果を埋め込む（図６の行１３４及び行１３５）。「type="R"」とは数式の演算結果を参照していることを明示する（type属性省略時には値「V」がデフォルトとなる。これはデータを参照していることを示す）。
この数式を計算すると、予定の日数で単体テストが終了する（収束する）場合のバグ摘出累積件数予測グラフを描画するためのゴンペルツ曲線の傾きを決定する値を計算することができる。
【００５６】
図３２の行３は、図６の行１３９〜行１５１のrule要素に対応する。
この要素で定義する数式の識別子は「B001R03」である（ruId="B001R03"）。
このrule要素の数式は、図６の行１４１〜行１４６のmath要素に記述されている。
図６の行１４４のapply要素は「d/1000」を示し、図６の行１４２〜行１４５のapply要素は「k*(d/1000)」を示している。
図６の行１４８のpath要素ではデータ「B001VD01」をmath要素の子のapply要素の子のci要素（図６の行１４３）に設定することを示している。
図６の行１５０のpath要素ではデータ「B001VX01」をmath要素の子のapply要素の子のapply要素の子のci要素（図６行の１４４）に設定することを示している。
この数式を計算すると、現在のモジュールの規模で摘出しなければならないバグの目標数を計算することができる。
【００５７】
図３２の行４は、図６の行１５２〜行１７２のrule要素に対応する。
この要素で定義する数式の識別子は「B001R04」である（ruId="B001R04"）。
このrule要素の数式は、図６の行１５４〜行１６５のmath要素に記述されている。
図６の行１５９〜行１６２のapply要素は「b^t」を示し、図６の行１５７〜行１６３のapply要素は「0.04236^(b^t)」を示し、図６の行１５５〜行１６４のapply要素は「K*(0.04236^(b^t))」を示している。
図６の行１６７のpath要素では数式「B001R03」の演算結果をmath要素の子のapply要素の子のci要素（図６の行１５６）に設定することを示している。
図６の行１６９のpath要素では数式「B001R02」の演算結果をmath要素の子のapply要素の子のapply要素の子のapply要素の最初の子ci要素（図６の行１６０）に設定することを示している。
図６の行１７１のpath要素ではデータ「B001VF04」をmath要素の子のapply要素の子のapply要素の子のapply要素の２番目の子ci要素（図４の行１６１）に設定することを示している。
なお、データ「B001VF04」は複数の値を持つため、この数式の演算結果も同様に集合的に扱われる。
この数式を計算すると、単体テスト期間内の各日におけるバグ摘出累積予測件数を取得できる。
【００５８】
図３２の行５は、図７の行１７３〜行１９８のrule要素に対応する。
この要素で定義する数式の識別子は「B001R05」である（ruId="B001R05"）。
このrule要素の数式は、図７の行１７５〜行１９０のmath要素に記述されている。
図７の行１８３〜行１８６のapply要素は「b^t」を示し、図７の行１８１〜行１８７のapply要素は「0.04236^(b^t)」を示し、図７の行１７８〜行１８８のapply要素は「-1*K*(0.04236^(b^t))」を示し、図７の行１７６〜行１８９のapply要素は「K+(-1*K*(0.04236^(b^t)))」を示す。
図７の行１９２のpath要素はデータ「B001VD03」をmath要素の子のapply要素の子のci要素（図７の行１７７）に設定することを示している。
図７の行１９３のpath要素はデータ「B001VD03」をmath要素の子のapply要素の子のapply要素の子のci要素（図７の行１８０）に設定することを示している。
図７の行１９５のpath要素は数式「B001R01」の演算結果をmath要素の子のapply要素の子のapply要素の子のapply要素の子のapply要素の先頭の子ci要素（図７の行１８４）に設定することを示している。
図７の行１９７のpath要素はデータ「B001R01」をmath要素の子のapply要素の子のapply要素の子のapply要素の子のapply要素の２番目の子ci要素（図７の行１８５）に設定することを示している。
なお、データ「B001VF04」は複数の値を持つため、この数式の演算結果も同様に集合的に扱われる。
この数式を計算すると、単体テスト期間内の各日におけるチェックリスト残件数予測を取得できる。
【００５９】
図３２の行６は、図７の行１９９〜行２０８のrule要素に対応する。
この要素で定義する数式の識別子は「B001R06」である（ruId="B001R06"）。
このrule要素の数式は、図７の行２０１〜行２０３のmath要素に記述されている。
図７の行２０２のapply要素は「a/b」を示す。
図７の行２０５のpath要素は複数の結果を返すデータ「B001VD07」の末尾（index="-0"）のデータをmath要素の子のapply要素の最初の子ci要素に設定することを示している。
図７の行２０７のpah要素は複数の結果を返す数式「B001R04」の、データ「B001VF03」で示される位置の演算結果（例えば、「B001R04」が「0 5 7 9」の結果を持ち、「B001VF03」が「2」を返すなら、「5」がとるべき値となる）をmath要素の子のapply要素の２番目の子ci要素に設定することを示している。
この数式を計算すると、評価実行日におけるバグ摘出累積予測件数と実際の値の乖離率を取得できる。
【００６０】
前記の段落番号〔００４１〕〜〔００５９〕で説明したデータ及び数式は、メッセージ処理の開始をトリガーとして、参照・評価される。
【００６１】
評価ルール「B001」のメッセージ処理は、図７の行２１１〜行２３８のmessages要素で定義される。このmessages要素には、メッセージ識別子「B001M01」のmessage要素（図７の行２１３〜行２２６）と、メッセージ識別子「B001M011」のmessage要素（図８の行２２７〜行２３７）が含まれる。
【００６２】
メッセージ「B001M01」は、図７の行２１４のpointOfTime要素の要素値が「REQUIRED」であるため、ＱＳ１においては、評価ルール実行時に即座に処理される。
メッセージ「B001M011」は、図８の行２２９のpointOfTime要素の要素値が「CHAINED:B001M01」であるため、ＱＳ１においては、メッセージ「B001M01」が処理された時点で連鎖して実行される。
以上より、評価ルール「B001」のメッセージ処理はすべて、評価ルール適用時に一括して処理される。
【００６３】
メッセージ「B001M01」には、criteria要素が含まれていないので、そのmsgDescription要素（図７の行２１５〜行２２５）は、メッセージ処理時には常に提示される。このmsgDesciption要素は、「type="GRAPH"」の指定により、ＱＳ１においては、ＱＳ１のグラフ作成機能を利用することを意味する。ＱＳ１のグラフ作成機能では、描画に必要なデータは、XML形式で設定することになっているため、msgDescription要素の要素値は、そのXML形式データのテンプレート文字列である。
このテンプレートにデータを埋め込む場所とその内容はparam要素で指定されている（図７の行２１７、行２１８、行２１９、行２２１、行２２２、行２２４）。
図３３は、これらのparam要素で参照されているデータ及び数式を一覧表にまとめた図である。
【００６４】
メッセージ処理が開始され、msgDescription要素の内容が評価される時点で、これらの値がその定義された方法に従って評価され、その最終的な結果がmsgDescription要素内容に埋め込まれ、そのmsgDescription要素のタイプに適切な処理部に渡される。
図１５は、これらのparam要素の評価方法を示した図である。
例えば、データ「B001VD06」（図１５の００４）を参照するparam要素を評価するには、データ「B001VD03」（図１５の００５）、データ「B001VM01」（図１５の００８）、データ「B001VF02」（図１５の００９）を必要とする。このうち、データ「B001VF02」は複数の結果を返すので、データ「B001VD06」も複数の結果を返す。データ「B001VD03」を取得するには、データ「B001VM01」（図１５の０１０）が必要で、データ「B001VF02」を取得するには、データ「B001VD04」（図１５の０１１）とデータ「B001VS01」（図１５の０１２）を必要とする。データ「B001VD04」を取得するにはデータ「B001VM01」（図１５の０１３）を必要とする。
他のparam要素も同様に評価する。なお、ここに示したのは意味的なデータ間の依存関係であり、実際の演算方法は実装に依存する。
【００６５】
ここで、品質データベースが図３４，図３５で示す内容を保持していたとする。
ＱＳ１では、msgDescription要素内の出現順でparam要素を評価するため、まず、データ「B001VF01」のparam要素（図１５の００１）が評価される。
このときまず、依存関係の終端にある、データ「B001VM01」の解決が試みられる。データ「B001VM01」は、「TargetModule」パラメタを手入力するデータ項目であるため、ＱＳ１では、入力ダイアログボックスを開いて利用者に入力を促す。ここでは、値「AX001D05」を入力したものとする。
図１２はその画面表示イメージ図である。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図１６のようになっている。
【００６６】
次に、データ「B001VD04」及びデータ「B001VD02」を解決するために、これらのデータ項目定義が属するviewDefinition要素のcommand要素によって示されるＳＱＬ文「SELECT MDST,MDPC,MDCC,MDAB FROM MUTS WHERE MDID='AX001D05'」がデータベース「QE0001」に対して実行される。このviewDefinition要素には、データ「B001VD01」及びデータ「B001VD03」のデータ項目定義も含まれるため、これらのデータ項目も同時に解決される。表６のモジュール別単体テスト工程管理表テーブルの内容から、上記ＳＱＬ文の実行結果は「1232,10,112,2000/2/1」となるため、データ「B001VD01」、データ「B001VD02」、データ「B001VD03」、データ「B001VD04」はそれぞれ、「1232」、「10」、「112」、「2000/2/1」と解決される。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図１７のようになっている。
【００６７】
次に、データ「B001VF01」を解決するために、値「2000/2/1」及び「10」を引数としてユーザ定義関数「CalcCalendar1」を実行する。結果は、
「2000/2/1,2000/2/2,2000/2/3,2000/2/4,2000/2/5,2000/2/6,2000/2/7,2000/2/8,2000/2/9,2000/2/10」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図１８のようになっている。
【００６８】
次に、データ「B001VF02」のparam要素（図１５の００２）を解決する。
データ「B001VD04」はすでに評価済みであるので参照のみを行い、データ「B001VS01」の評価を行う。データ「B001VS01」はシステム日付の取得を行うものであり、ここではシステム日付を「2000/2/4」と仮定するので、評価結果は「2000/2/4」となる。
次にデータ「B001VF02」を解決するために、値「2000/2/1」及び「2000/2/4」を引数としてユーザ定義関数「CalcCalendar2」を実行する。結果は、
「2000/2/1,2000/2/2,2000/2/3,2000/2/4」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図１９のようになっている。
【００６９】
次に、データ「B001R05」のparam要素（図１５の００３）を解決する。
これに必要な、データ「B001VD03」、数式「B001R01」、データ「B001VF04」のうち、データ「B001VD03」は評価済みであるので、まず数式「B001R01」を評価する。
数式「B001R01」の評価に必要な変数はすでに評価済みであるので、それを数式に当てはめて計算する。すなわち、式「(log0.04236(112/(112+1)))^(1/10)」の計算結果「0.55577」が評価結果となる。
次に、データ「B001VF04」を評価する。このとき、引数として固定値「1」とデータ「B001VD02」の評価結果「10」を引数としてユーザ定義関数「Range」を実行する。
結果は、「1,2,3,4,5,6,7,8,9,10」となる。
よって、数式「B001R05」の評価結果は、式「112+(-1*112*(0.04236^(0.55577^t)))」の変数tに、データ「B001VF04」の評価結果の値を一つづつ設定して計算した値の集合「92.057,69.075,46.274,28.715,17.001,9.793,5.553,3.121,1.745,0.973」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図２０のようになっている。
【００７０】
次に、データ「B001VD06」のparam要素（図１５の００４）を解決する。
ここで必要なパラメタはすでに解決済みであるので、データ「B001VD06」の評価結果は、ＳＱＬ文「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND MCEL <=TO_DATE('2000/2/1')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL <=TO_DATE('2000/2/2')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL <=TO_DATE('2000/2/3')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL <=TO_DATE('2000/2/4')」
の実行結果「98,82,68,66」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図２１のようになっている。
【００７１】
次に、数式「B001R04」のparam要素（図１５の００５）を解決する。
ここで、データ「B001VX01」として参照されるstandards.xmlファイルの「standards/ut/bugDensityKLOC」要素の要素値が、「10」であったとすると、数式「B001R03」の値は、式「1232*(10/1000)」の評価結果、すなわち「12.32」であるため、数式「B001R02」の値は、式「(log0.04236(12.32/(12.32+1)))^(1/10)」の計算結果「0.690626」である。
よって、数式「B001R04」の評価結果は、式「12.32*(0.04236^(0.690626^t))」」の変数tに、データ「B001VF04」の評価結果の値を一つづつ設定して計算した値の集合「1.443,2.802,4.43,6.079,7.564,8.796,9.763,10.491,11.026,11.411」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図２２のようになっている。
【００７２】
最後に、データ「B001VD07」のparam要素（図１５の００６）を解決する。
ここで必要なパラメタはすでに解決済みであるので、データ「B001VD07」の評価結果は、ＳＱＬ文「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' ANDMCEL <=TO_DATE('2000/2/1')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND MCEL
<=TO_DATE('2000/2/2')」「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND MCEL <=TO_DATE('2000/2/3')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND MCEL
<=TO_DATE('2000/2/4')」の実行結果「1,2,4,8」となる。こうして、メッセージ「B001M01」のmsgDescription要素の評価は最終的に図２３のようになる。
【００７３】
よって、メッセージ「B001M01」のmsgDescription要素（図７の行２１５〜行２２５）の内容は最終的に、「<gp><template>Curve1</template><axis type="y" id="X" min="0" max="120" /><axis type="y" id="Y" min="0" max="15" /><axis id="A" type="x" 2000/2/1,2000/2/2,2000/2/3,2000/2/4,2000/2/5,2000/2/6,2000/2/7,2000/2/8,2000/2/9,2000/2/10</axis><axis id="B" type="x" >2000/2/1,2000/2/2,2000/2/3,2000/2/4</axis><axis id="c" type="union A B" /><unit name="ＰＣＬ消化予測" xAx="c" yAx="X"><data>92.057,69.075,46.274,28.715,17.001,9.793,5.553,3.121,1.745,0.973</data></unit><unit name="ＰＣＬ消化実績" xAx="c" yAx="X"><data>98,82,68,66</data></unit><unit name="バグ累積予測" xAx="c" yAx="Y" /><data>1.443,2.802,4.43,6.079,7.564,8.796,9.763,10.491,11.026,11.411</data></unit><unit name="バグ累積実績" xAx="c" yAx="Y" ><data>1,2,4,8</data></unit></gp>」と解釈され、グラフ描画機能部に渡される（<![CDATA[……]]>は、XML文書においては、それに挟まれる部分を単なる文字列として扱うことを意味するので、解釈時には取り外す）。
ＱＳ１は上記のデータを利用して、図１３のように、グラフを描画する。
【００７４】
続いて、メッセージ「B001M011」の評価を行う。
メッセージ「B001M011」にはcriteria要素（図８の行２３０〜行２３１）が含まれるので、この要素内容である論理演算式を評価し、その結果が真であれば、続くmsgDescription要素（図８の行２３２〜行２３３、行２３４〜行２３６）が処理される。
ここで、criteria要素の論理演算式の内容は、数式「B001R06」の演算結果が1.2以上か0.8以下である場合に真となるので、まず、数式「B001R06」の評価を行う。
数式「B001R06」は、図６，図７の行１１９〜行２０８の定義により、データ「B001VD07」の最後のデータ（図７の行２０５）を数式「B001R04」の演算結果のデータ「B001VF03」番目のデータで割ったものであり、これらのデータが、メッセージ「B001M01」の評価結果からも分かるように、データ「B001VD07」が「1,2,4,8」で、数式「B001R04」の演算結果が「1.443,2.802,4.43,6.079,7.564,8.796,9.763,10.491,11.026,11.411」、また、データ「B001VF03」が、ユーザ定義関数「CalcCalendar3」（図４の行０４７〜行０５２）を値「2000/2/1」と値「2000/2/4」を引数として実行（ここでデータ「B001VD04」は「2000/2/1」、データ「B001VS01」は「2000/2/4」であるため）した結果である「4」であるため、式「8/6.079」の演算結果、すなわち「1.316」が評価結果となる。
よって、「(1.316>=1.2) OR (1.316 <=0.8)」という論理演算式は真となる。
【００７５】
criteria要素値の論理演算が成立したので、それに続くmsgDescription要素が処理される。
まず、図８の行２３２〜行２３３のmsgDescription要素が処理される。このmsgDescription要素は、「type="MSGBOX"」の指定により、ＱＳ１においてはmsgDescription要素値をメッセージボックスに表示することを意味する。ここで、データ「B001VM01」の値は、「AX001D05」であるので、「B001:AX001D05:バグ累積件数の予定件数よりの乖離率が20%を越えています。」という文字列が、図１４のように、画面に表示される。
次に、図８の行２３４〜行２３６のmsgDescription要素が処理される。このmsgDescription要素は、「type="LOGFILE"」の指定により、ＱＳ１においてはmsgDescription要素値を所定のログファイルに出力することを意味する。ここで、データ「B001VS01」の値は「2000/2/4」で、データ「B001VM01」の値は、「AX001D05」であるので、「B001:2000/2/1:AX001D05:バグ累積件数の予定件数よりの乖離率が20%を越えています。」という文字列がログファイルに出力される。
【００７６】
以上で、評価ルール「B001」に基く品質評価処理が終了する。
【００７７】
次に、ソフトウェア品質評価ルールが変更になった場合の措置の例を示す。
ルール変更のシナリオは以下の通りであるとする。
(1)ソースコード行による管理からファンクションポイントに基く管理へ移行する上での暫定処置とする。
(2)品質データベースにおいて、モジュールサイズのステップ数による管理は廃止し、代用として、モジュールごとのファンクションポイントを管理するためのテーブルを設ける。
(3)品質データベースにはファンクションポイントを算出するための基礎データを入れ、ファンクションポイントを算出するには、それらのデータと別途定義する基準値を元に計算を行う。
(4)品質評価時には、ファンクションポイントベースの基準値が未決のため、１ファンクションポイント当り90COBOL行として換算し、従来の基準値を適用するものとする。
【００７８】
上記のシナリオに従って品質データベースを変更すると、図２４のようになる。
モジュール別単体テスト工程管理表（MUTS）からは実績ステップ数（MDST）を削除する。
新たに、モジュール別ファンクションポイント管理表（MFPC）を追加する。
「モジュールID」は、レコードの一意識別子である。
「入力項目数」「出力項目数」「参照項目数」「インタフェース数」「データファイル数」はそれぞれ、ファンクションポイント法上のパラメタに対応する。
これらの値にその項目別に設定される「重み」の係数を乗じ、その合計を補正前のファンクションポイントとする。
「複雑さのレベル」は、そのモジュールの難易度を示し、この値に対応した補正係数を補正前のファンクションポイントに乗じて、補正後のファンクションポイントを取得する。
その他のテーブルには変更は加えない。
【００７９】
ファンクションポイント法上の「重み」係数、難易度による補正係数、及び１ＦＰ当りのソースコード行換算係数は、すべてファイルstandards.xmlに追加するものとする。
その変更後の内容の一部を、図２４に示す。
ここでの追加範囲は、行０１０〜行０３２までである。
行０１０〜行０３２までのfp要素は、standards文書要素の直下にあり、ファンクションポイント関連のデータを保持する。
行０１１のinput要素は要素値として入力項目数に対する重み係数を持つ。
行０１２のoutput要素は要素値として出力項目数に対する重み係数を持つ。
行０１３のreference要素は要素値として参照項目数に対する重み係数を持つ。行０１４のinterface要素は要素値としてインタフェース数に対する重み係数を持つ。
行０１５のdatafile要素は要素値としてデータファイル数に対する重み係数を持つ。
行０１６〜行０２８のdifficulty要素は、補正前ファンクションポイントに対する難易度による補正係数のデータを保持する。その子要素である各coefficient要素（行０１７〜行０２７）は、degree属性で指定される複雑さのレベルに応じた補正係数を要素値としてもつ。例えば、行０２３のcoefficient要素では複雑さのレベルが7である場合に、係数1.1が適用されることを示している。
行０２９〜行０３１の１ファンクションポイント当りのソースコード行を算出するための係数のデータを保持する。その子要素であるSLOCperFP要素（行０３０）は、Lang属性で示されるプログラミング言語における標準的な１ＦＰ当りのソースコード行数を要素値として持つ。
【００８０】
上記のような、品質評価方法及び品質データベース及び関連ファイルの構成の変化に対応するために、評価ルール「B001」の定義ファイルを変更する。変更の内容は、モジュール別単体テスト工程管理表から直接参照できなくなった実績ステップ数の変わりに、モジュール別ファンクションポイント管理表の内容から導出されるファンクションポイント数からCOBOLソース行数への換算ステップ数を用いるようにすること、である。
【００８１】
まず、図５の行０６３〜行０７０のviewDefinition要素を図２５のように変更する。これによって、実績ステップ数の代わりに、ファンクションポイントを計算するために必要な基礎データを取得する。対象モジュールの「入力項目数」「出力項目数」「参照項目数」「インタフェース数」「データファイル数」「複雑さのレベル」をそれぞれ、「B001VD08」（図２５の行００９）、「B001VD09」（図２５の行０１０）、「B001VD10」（図２５の行０１１）、「B001VD11」（図２５の行０１２）、「B001VD12」（図２５の行０１３）、「B001VD13」（図２５の行０１４）で参照する。
【００８２】
次に、図５の行０８８〜行０９１のviewDefinition要素の次（すなわち図５の行０９１と行０９２の間）に、図２７のviewDefinition要素を追加する。これによって、ファンクションポイントの計算に必要な係数類を参照する。
図２６の行００１〜行００４では、入力項目数に対する重み係数を「B001VX02」で参照している。
図２６の行００５〜行００８では、出力項目数に対する重み係数を「B001VX03」で参照している。
図２６の行００９〜行０１２では、参照項目数に対する重み係数を「B001VX04」で参照している。
図２６の行０１３〜行０１６では、インタフェース数に対する重み係数を「B001VX05」で参照している。
図２６の行０１７〜行０２０では、データファイル数に対する重み係数を「B001VX06」で参照している。
図２６の行０２１〜行０２５では、データ「B001VD13」をdegree属性値としてもつ補正係数（言い換えると、品質データベースから取得した対象モジュールの複雑さのレベルに対応した補正係数）を「B001VX07」で参照している。「[@degree="x"]」と言う表現は、「degree属性に「x」をもつ要素を選択する」ということを意味する。
同様に、図２６の行０２６〜行０３０では、「COBOL」をLang属性値としてもつ換算係数を「B001VX08」で参照している。
【００８３】
次に、図７の行１９９〜行２０８のrule要素の次（すなわち、図７の行２０８と行２０９の間）に、図２７ののrule要素を追加する。
このrule要素で追加する数式「B001R07」は、対象モジュールのファンクションポイントの算出とその結果にソースコード行換算係数を乗じて、換算ソースコード行数の算出を行う。
【００８４】
最後に、図６の行１４８のpath要素のassociatedData属性値を「B001R07」に変更する。
これにより数式「B001R03」において、以前にデータ「B001VD01」すなわち対象モジュールの実績ステップ数を設定していた変数に、数式「B001R07」すなわち概算ソースコード行数を設定できるようになる。
【００８５】
上記の段落番号〔００８０〕〜〔００８４〕の修正を行うことで、実装システムを更新することなく、定義ファイルの変更のみで新しい品質評価方法に対応できるようになる。
【００８６】
次に、評価ルール定義ファイルの共有例を示す。
【００８７】
評価ルール「B001」をＱＳ１とは異なる実装系ＱＳ２と共有するものとし、ＱＳ２の実装がＱＳ１とほぼ同様であるが、幾つかのキーワードが異なっているものとする。
仮に、ＱＳ１のおけるユーザ定義関数「CalcCalendar1」をＱＳ２では「GetDate1」、ＱＳ１におけるデータソース指定キーワード「MANUAL」をＱＳ２では「UserInput」と表現するものとする。
共有する評価ルール定義ファイルとその文書型宣言ファイルは、ＱＳ１及びＱＳ２の両方からアクセス可能な評価ルールファイル保存部（例えばネットワーク上の共有ディレクトリ上など）に置かれ、必要なときに、ＱＳ１及びＱＳ２のローカルな評価ルール保存部にダウンロードされて利用されるものとする。
【００８８】
この場合は、単なる名前の置き換えでよいので、ＸＭＬのエンティティ参照機能を用いて、図２８のようにして解決できる。
まず、ＱＥＭＬの文書型宣言ファイルに、ローカルな名前解決を行うために、外部エンティティ宣言を追加する（図２８の４０１）。
次に、評価ルール定義ファイル（ここではB001.xml）において、実装システム毎に異なる名称は、エンティティ参照で表現するようにする。この例では、ＱＳ１におけるキーワード「MANUAL」は「&dst1」と置き換えられ（図９の００２）、ユーザ定義関数名「CalcCalendar1」は「&udf1;」と置き換えられている（図２８の４０３）。
そして、ＱＳ１及びＱＳ２のローカルな評価ルール保存部に、上記のエンティティ参照を解決するためのエンティティ宣言を含んだファイルlocal.dtdを置いておけば（図２８の４０４、図２８の４０５）、それぞれの実装系で当該評価ルール定義ファイルが解釈されるときに、エンティティ参照が適切に解決される。
また、それぞれの実装系が利用する品質データベースの構成が異なる場合でも、同様の方法を用いて共有することができる。
【００８９】
【発明の効果】
以上説明したように、本発明によれば、品質管理・評価方法をテキストファイルであるＸＭＬ文書で定義するため、特定の品質管理・評価方法に依存することなく、新しい品質管理・評価方法を開発、導入、運用することが容易となり、また品質管理・評価方法を異なる場所、異なる実装システム間で共有することが容易になる。品質管理・評価方法は、既存の実装システムが前提としない種類のデータソースや、既存の実装システムがユーザ定義関数として提供しない関数機能や、既存の実装システムの機能範囲外の演算方法（math要素の機能範囲）や、既存の実装システムが提供しないような評価結果の出力方法を必須のものとして要求しない限りは、自由に新しいものを開発可能である。
また、定義された品質管理・評価方法は、実装システム間に基本的な共通性がある限りは、異なる場所、異なる実装システム間で共有できる。
なお、基本的な共通性があるとは、(1)提供するユーザ定義関数の機能や評価結果出力方法に共通性があること(2)サポートするデータソースのタイプに共通性があること(3)利用可能な品質データベースの構成が類似していることを意味する。これらについて共通性が高いほど共有が容易になり、そうでない場合は共有が困難になる。但し、その場合でも、評価ルール定義ファイルは単なるテキストファイルであるため、別の実装システムで利用可能なようにそれを変更することは容易である。
【図面の簡単な説明】
【図１】本発明が適用される品質管理及び品質評価システムの構成図である。
【図２】品質評価ルールマークアップ言語ＱＥＭＬ、Ｖｅｒｓｉｏｎ１．０の文書型定義を示す図である。
【図３】図２の内容を図式的に表現した図である。
【図４】本発明における評価ルール定義ファイル例（１）を示す図である。
【図５】本発明における評価ルール定義ファイル例（２）を示す図である。
【図６】本発明における評価ルール定義ファイル例（３）を示す図である。
【図７】本発明における評価ルール定義ファイル例（４）を示す図である。
【図８】本発明における評価ルール定義ファイル例（５）を示す図である。
【図９】本発明におけるＱＳＩ評価ルール選択画面（１）を表す図である。
【図１０】本発明におけるＱＳＩ評価ルール選択画面（２）を表す図である。
【図１１】本発明におけるＱＳＩ評価ルール詳細画面を表す図である。
【図１２】本発明におけるパラメタ入力画面例を表す図である。
【図１３】本発明におけるグラフ画面例を示す図である。
【図１４】本発明における警告表示例を示す図である。
【図１５】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素内ｐａｒａｍ要素の評価方法を示す図である。
【図１６】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（１）の図である。
【図１７】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（２）の図である。
【図１８】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（３）の図である。
【図１９】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（４）の図である。
【図２０】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（５）の図である。
【図２１】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（６）の図である。
【図２２】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（７）の図である。
【図２３】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（８）の図である。
【図２４】本発明におけるｓｔａｎｄａｒｄｓ．ｘｍｌの内容変更を示す図である。
【図２５】図５の行０６３〜行０７０のｖｉｅｗ Ｄｅｆｉｎｉｔｉｏｎ要素内容変更を示す図である。
【図２６】図５の行０９１の直後のｖｉｅｗ Ｄｅｆｉｎｉｔｉｏｎ要素追加を示す図である。
【図２７】図５の行０９１の直後のｖｉｅｗ Ｄｅｆｉｎｉｔｉｏｎ要素追加を示す図である。
【図２８】本発明における評価ルール評価ファイル共有例を示す図である。
【図２９】図２の要素を一覧表示した図である。
【図３０】評価ルール「Ｂ００１」のデータソース一覧を示す図である。
【図３１】品質データベースの構成例を示す図である。
【図３２】数式一覧を示す図である。
【図３３】メッセージ「Ｂ００１Ｍ０１」で用いるデータ及び数式を示す図である。
【図３４】品質データベースの内容例（１）を示す図である。
【図３５】品質データベースの内容例（２）を示す図である。
【図３６】品質データベース変更例を示す図である。
【符号の説明】
１…評価ルールファイル保存部、２…情報共有機能、
３…評価ルールファイル、４…評価ルール読み込み部、
５…評価ルール演算部、６…品質データベース、
７…評価ルール評価結果提示部、８…実装システム、
００１〜０２２…要素番号。
【発明の属する技術分野】
本発明は、ソフトウェア開発下流工程における品質管理・品質評価に関する処理方法に係り、特に、その品質管理・品質評価方法に柔軟性と発展性を持たせるのに好適な品質管理・評価方法、およびその処理プログラムを記録した記録媒体に関する。
【０００２】
【従来の技術】
ソフトウェア開発下流工程においては一般に、その開発対象ソフトウェアの品質管理・品質評価のために、設定したテスト件数などの静的なデータや、消し込み済みテスト件数、検出されたバグ数、解決されたバグ数あるいはテストカバレージ率などの動的なデータがそれぞれの工程のレベルに応じた区分で蓄積・管理される。そして、こうしたデータを所定の目標値と比較すること、または蓄積されたデータの経時的な変動の状況を分析することで、テスト十分性や信頼性の推定を行い、そのソフトウェアの品質が所定の水準に達しているか否かなどの評価を実施する。
【０００３】
また、例えば特開平５−３１３８８１号公報に記載の評価処理方法では、上記のような品質管理データに、過去の経験に基く知識情報を加味して総合的な残存欠陥数の推定を行うことができる処理方法が提案されている。
このうよな方法では、「目標値」や「信頼性成長モデル」の策定が重要になってくる。多くの場合、それは過去のプロジェクト事例の実績値やソフトウェア組織の方針に基づいて決定される。
【０００４】
従来の技術では、実績値と目標値に基く客観的な評価が可能になっている。
しかし、現実のソフトウェア開発では、このような「外形的な」数値比較だけでは不十分である。また、システム開発技法や実装技術の進歩、あるいは新しい管理技法などにより、過去の実績に基く指標だけでは対応できないこともありうる。異なる指標、場合によっては異なる考え方に基づいた評価方法が必要になってくる。そうした意味では、特開平５−３１３８８１号公報に記載の技術において、経験則から導出された知識情報による結果の補正は可能であるものの、それも特定の方法内のものでしかなく不十分である。
また、これらの技術では品質管理・評価を機械的に行うことを前提としている。しかし、どれほど「客観的」に管理・評価を行おうとしても、すべてを完全に機械化することは不可能で、いずれかの管理レベルで「主観的」な判断が介在する余地がある。すなわち、ソフトウェア品質管理を適正に実施するには、管理者の判断を支援し、さらにスキルの向上を促すような仕組みが存在することが望ましいが、従来の技術にはシステムとしてそれを支援する機能は存在しない。
【０００５】
【発明が解決しようとする課題】
前述のように、従来の技術では、品質管理・評価方法が定型的な特定の手法に限定されがちで、新しい品質管理・評価方法を開発あるいは導入することが難しい点、及び品質管理者の判断を支援し、スキルの向上を促進する仕組みが存在しない点がそれぞれ問題であった。
【０００６】
そこで、本発明の目的は、これら従来の問題点を解決し、従来からの品質管理・評価方法のみならず、新しい品質管理・評価方法を開発あるいは導入し、運用することが容易な品質管理・評価方法及びその処理プログラムを記録した記憶媒体を提供することにある。
【０００７】
【課題を解決するための手段】
上記目的を達成するため、本発明の構造化文書により定義された品質管理及び品質評価ルールによる品質管理・評価方法では、特定の方法による品質管理・評価用のデータの収集や、収集されたデータに対して特定のルールを適用して品質評価を行うことなく、特定の形式で品質管理・評価データがデータベースに蓄積されていることを前提に、該データベース（以下、品質データベースと呼ぶ）内のデータの参照方法、参照したデータの解釈方法、参照及び解釈を行った結果を提示する方法を記述した品質管理・評価ルール（以下、評価ルールと呼ぶ）を定義し、その評価ルールを品質データベースに対して適用することで品質管理・評価を実施する。
また、上記評価ルールを構造化文書、特にＸＭＬ（Extensible Markup Language）の形式で定義すること、及びその内容についての説明記述部を設けることで、評価ルールの流通（共有）を支援する。この評価ルールを記述したファイルを、評価ルール定義ファイルと呼ぶ。
【０００８】
【発明の実施の形態】
以下、本発明の実施例を、図面により詳細に説明する。
まず、その概要を説明する。
図１は、本発明が適用するプログラムとファイル、データリポジトリ等の関連を示すシステム構成図である。
図１において、１は評価ルールを保持するデータリポジトリ（ファイル保存部）である。典型的には、ＸＭＬデータを保持できるデータベースシステムや、ＸＭＬファイルを保存しているディスク装置の領域を指す。評価ルールファイル保存部１内部におけるデータの蓄積方法、形式は問わないが、利用にあたって評価ルールが外部に読み出される際には、ＸＭＬファイル形式あるいはＸＭＬとして解釈できるデータストリームとして読み出し可能でなければならない。もちろん、評価ルールファイル保存部１が通常のディスク装置上に評価ルールファイルを保存しているだけであれば、特別な読み出しの機構は必要ない。
【０００９】
２は本発明を利用する組織等における情報共有のための装置あるいはシステム（情報共有機能）である。典型的にはWorld Wide Webサイトである。これは必須のものではないが、評価ルールファイル保存部１の内容を読み取り、評価ルールファイル３として実装システムに表示することにより、組織等における情報共有を支援する。従って、もし情報共有機能２が配置されていない場合には、評価ルールファイル保存部１から直接、評価ルール読み込み部４に入力される。
３は、評価ルールを内容として含むＸＭＬファイルである。典型的には、ファイルの形態で、評価ルールファイル保存部１から直接、あるいは情報共有機能２を経由して読み出される。また、ファイルでなくＸＭＬデータとして解釈可能なデータストリームとして読み出されることもありうる。これは、次の項目で説明するように、一般には評価ルール読み込み部４が直接評価ルールファイル保存部１または情報共有機能２にアクセスして読み込みを行う場合に発生する。
４は、本発明に基く品質評価を実施する実装システム８（アプリケーションプログラム）の評価ルール読み込み部である。指定された評価ルールを保持するＸＭＬファイルを読み込むか、あるいは評価ルールファイル保存部１あるいは情報共有機能２に直接アクセスしてデータストリームの形態で読み込むことにより、評価ルールを実装システム８で利用可能な形態に展開する。
読み込み部４の実装方法は問わないが、典型的にはＸＭＬデータを構文的に解釈する部分（ＸＭＬパーサと呼ばれる部分）と、次に説明する評価ルール演算部５への業務的なインタフェースを提供する部分の２階層で構成される。
【００１０】
５は、実際に品質評価のための演算を行う演算部である。評価ルール演算部５は評価ルール読み込み部４で読み込まれた評価ルールに基づき、後述の評価ルール評価結果提示部７が指示する時点で指定の演算を行い、その結果を指定の方法であり、評価ルール評価結果提示部７に渡し、利用者に提示させる機能をもつ。
演算を実施するにあたっては、品質データベース６から指定の方法でデータを参照する。
６は、実装システム８による品質評価の対象となるソフトウェアプロジェクトにかかる品質データを蓄積している品質データベースである。この内容や構成については制限する必要はないが、一般的な方法でアクセス可能なデータリポジトリでなければならない。典型的には、ＳＱＬ（Structured Query Language）文による操作が可能なインタフェースを装備したリレーショナルデータベースである。
７は、品質評価の結果を利用者に提示する機能を提供する評価結果提示部である。
評価ルール読み込み部４で読み込まれた評価ルールに指定された時点で評価ルール評価結果提示部７が動作し、必要に応じて評価ルール演算部５で演算処理を行わせ、その結果に基づき、所定の提示を行うか否かなどを決定する。その提示方法は実装に依存するが、典型的には警告メッセージの表示、ログファイルへの書き込み、結果レポート（ファイル）の作成などが考えられる。
【００１１】
図２及び図２９は、品質評価ルールマークアップ言語ＱＥＭＬ（Quality Evaluation rule Markup Language ） Version 1.0 の概要を示したものである。評価ルール定義ファイルは、この形式に基づいて記述する。図２は、ＱＥＭＬの文書型定義（DTD）である。
図３は、図２の内容を図式的に表現したものであって、各要素の関係が階層構造を有していることが分かる。
図２９は、要素を一覧表示したものであって、図２の各要素番号に対応して、図２９の同じ要素番号の欄に名称、内容、属性の名称、属性の内容が表示されている。ＱＥＭＬは、ＸＭＬ規格に準拠したアプリケーションであり、そのため、評価ルール定義ファイルは、一般のテキストエディタやＸＭＬエディタを利用して容易に編集することができる。また、World Wide WebブラウザなどのＸＭＬ対応製品を利用すれば、その内容を容易に参照、表示することができる。さらに、内容のプログラム上の解析には、ＸＭＬを解析するためのアルゴリズムを流用できるので、本発明の実装も容易である。なお、これらの規定は改良のため仕様変更されることもありうる。
【００１２】
以下に、本発明におけるＱＥＭＬの規定の詳細を示す。なお、図２,図３および図２９中の要素番号は、互いに対応している。
【００１３】
qeml要素（００１）は、評価ルール定義ファイルの最上位要素である。
この下には、一つ以上のqeRule要素（００３）が存在する。
【００１４】
qeRule要素（００３）は論理的に関連する一連の品質評価ルールの定義を収容する要素である。qeRule要素同士は互いに独立し、自己完結的であることが望ましいが他のqeRule要素内の定義を参照してもよい。
qeRule要素は四つのセクションを示す四つの要素を収容する。すなわち、explain要素（００４）、dataAddress要素（００５）、rules要素（００６）、messages要素（００７）である。
【００１５】
explain要素（００４）は、それが属するqeRule要素の意味的な説明を記述する部分である。この要素内の情報は通常、利用者に情報を提供する目的で利用される。
典型的には、実装システムの評価手段選択画面での評価ルールリスト表示、ＷＷＷサーバ上での品質評価ルール一覧表示ページへのリスト表示のために用いられる。
explain要素は、title要素（００８）、category要素（００９）、description要素（０１０）、association要素（０１１）を含む。
【００１６】
title要素（００８）は属する品質評価ルールの名前を示す文字列を値としてもつ。
【００１７】
category要素（００９）はそれが属する品質評価ルールを分類するための文字列を値としてもつ。複数の視点からの分類を可能とするため、一つの品質評価ルールに一つ以上のcategory要素をもつことができる。
例えば、二つのcategory要素が、それぞれ「バグ消化曲線」及び「ＣＳシステム用」という値を持っているとすれば、その品質評価ルールは「帳票種別（あるいは評価方法）」及び「適用対象システム区分」という二つの視点からの分類が可能となる。また、こうした分類の種別を示すtype属性をもつことができる。この属性の値の許容値は実装依存で決定される。
【００１８】
description要素（０１０）は、それが属する品質評価ルールを詳細に説明する文章を値としてもつ。
典型的には、適用対象システムの前提条件、開発環境、プロジェクト要員のスキルなど、適用対象システムの特性を特定するための情報を記述する。利用者はその記述内容を参考にして、その品質評価ルールの適用可否を判断する。
【００１９】
association要素（０１１）は、description要素の内容を補強するために、関連情報を記述する。type属性で関連情報の内容の種類を特定する。許容値は実装依存する。
例えば、type属性が「URL」とされていれば、association要素の内容は参考とするURLとなり、「qeId」と記述されていれば関連する他の品質評価ルールとなる。
【００２０】
dataAddress要素（００５）は、属する品質評価ルールで使用される各種データの取得方法または取得先についての定義を行う。dataAddress要素はデータの種類（取得方法）毎に定義されるので、qeRule要素内に一つ以上存在する。
dataAddress要素は、datasource要素（０１２）、viewDefinition（０１３）を含む。
【００２１】
datasource要素（０１２）は、属するdataAddress要素のデータ取得元を識別するための情報を設定する。type属性でデータソースの種類を指定し、要素の値としてはデータソースへアクセスするための情報をもつ。これらの値は実装依存である。
典型的には、type属性値「RDB」で要素値はリレーショナルデータベース名、type属性値「XML」で要素値はＸＭＬファイルフルパス名、type属性値「SYS」で要素値は省略（システム情報を取得する）、type属性値「user」で要素値は省略（実装依存のデータ取得機能から取得する）、type属性値「manual」で要素値は省略（実装システムを経由して手入力の値を取得する）、などが考えられる。
【００２２】
viewDefinition要素（０１３）は、属するdataAddress要素のデータソースに対する一回のデータ取得操作ごとに、そのデータ取得操作の方法及びそれにより取得できるデータ項目の定義を記述する。
viewDefinition要素は、command要素（０１６）とvalue要素（０１７）を含む。
【００２３】
command要素（０１６）は、属するviewDefinition要素における、データ取得操作をデータソースに対して行う際のコマンド文字列の定義を記述する。内容は実装やデータソースの種類によって異なる。データソースがコマンド文字列などを必要としないような種類のものであれば、この要素は省略できる。
典型的には、データソースがリレーショナルデータベースであれば、データを取得するためのSQL文（SELECT文）、データソースがXMLファイルであれば、要素を指定するためのデータアドレッシング記述（例えば、XPath文字列など）、データソースがシステム情報であれば、その情報種別（例えば、システム日付など）を指定するための文字列が記述される。
この文字列にはparam要素（０２２）を含むことができるので、動的にコマンド文字列を変更することもできる。
command要素には二つの属性があるが、これらはいずれもリレーショナルデータベースのように複数のレコードが結果として返され得るデータソースに属するcommand要素での使用を前提としている。
type属性は、データ取得操作によって返される結果セットが本質的に単一(single)であるか複数(multiple)であるかを示す。デフォルトは「single」である。この値が「multiple」をとる場合、その結果セット（及びその参照）は結果セット内の特定レコードを明示的に指定しない限りは、常に集合的に扱われる。
key属性は、複数行が返されるデータ取得操作において、その結果セット内の行を一意に特定するために使用するキー項目を指定する。具体的な使用方法は実装に依存する。
これは、次に説明するvalue要素のposition属性の指定方法に影響を与える。
【００２４】
value要素（０１７）はcommand要素で指定されるデータ取得操作の結果として返されるデータ項目またはデータ項目の一部分を特定し、それに識別子を付与して、品質評価ルールのほかの部分から参照可能にするために使用される。この要素は属性のみを持ち、要素としての値は持たない。
varId属性は、そのデータ項目の一意識別子である。position属性は、関連するデータ取得操作結果セットのどの項目を指しているかを指定する文字列である。これは実装依存であるが、典型的には以下のようになる。
データソースがリレーショナルデータベースの場合、コマンドの選択リストの先頭項目を指すには、「@1」とする。この結果セットに複数行が含まれる場合は、全行の第１項目を指していることになる。複数行中の特定行の項目を指すには「$」を用いる。例えば、第三行の第二項目を指定するには、「@2$3」のように記述する。特定のキー値を持つ行の項目を指定する場合、例えば、command要素のkey属性が「keyA」と指定されていれば、「@3[5]」と記述することにより、keyA=5である結果セット中の行の第三項目を指定していることになる。
【００２５】
rules要素（００６）は、属する品質評価ルール中で用いる数式のコレクションである。
【００２６】
rule要素（0１４）は、rules要素に少なくとも一つ含まれる数式の定義である。ruId属性はrule要素の一意識別子である。
rule要素はmath要素（００２）とpath要素（０１８）を含む。
【００２７】
math要素（００２）は、数式を指定する。数式の指定にはWorld Wide Web consortiumで標準化された数式記述言語MathML(TM)を取り込んで使用する。図２では、便宜上MathML(TM)のDTDの所在位置を「mmlents\mathml.dtd」としているが、現実のシステムでは実際の所在位置が記述される。
MathML(TM)の要素のうちどの要素がどのようにサポートされるのかは実装に依存する。
【００２８】
path要素（０１８）は、math要素で指定される数式の特定の要素にパラメタを与えるために用いる。パラメタの指定が不要であれば省略可能である。要素の値として、math要素の特定の下位要素を指し示すための文字列を持つ。この文字列の書式は、World Wide Web consortiumで標準化された標準のXML文書部品指示言語であるXPathである。例えば、math要素とその子孫要素が
<math > <apply><plus/> <ci>a</ci><cn>5</cn></apply></math>
のように定義されている場合に、最初のci要素を指定する場合、「apply/ci」とする。
associatedData属性は、埋め込む値を示す識別子を指定する。これはvalue属性のvarId属性の値か、他rule要素のruId属性の値である。これらの値は循環参照を避けるように指定しなければならない。（循環参照を避ける方法は実装に依存する。）また、値が評価されるのは、数式が評価される時点である。さらに、この値は数値として評価される。
もし、associatedData属性が参照するデータ項目が集合的であった場合、math要素の評価はそのデータ項目のそれぞれについて実行される。また、同一のmath要素に設定する複数のpath要素が参照するデータ項目が同一のviewDefinition要素に属し、かつそれらが集合的であった場合、それらの値を個別に参照して評価するのではなく、同期を取って評価する。例えば、あるmath要素に関連する上記の条件を満たすpath要素が二つあり、そのデータ集合に三つのデータが含まれる場合、math要素の評価回数は九回ではなく、三回になる。
type属性及びindex属性は[００３４]で後述するparam属性（０２２）のtype属性及びindex属性と同様の内容を持つ。
【００２９】
messages要素（００７）は品質評価の実行時期、評価方法、評価結果の提示方法を定義したmessage要素（０１５）をまとめるコレクション要素である。
【００３０】
message要素（０１５）は、個別の品質評価の実行時期、評価方法、評価結果の提示方法を定義する。こうした一組の定義をメッセージと呼び、このメッセージを処理することをメッセージ処理と称する。
message要素はpointOfTime要素（０１９）、criteria要素（０２０）、msgDescription要素（０２１）を含む。
msgId属性は当該message要素の一意識別子である。
【００３１】
pointOfTime要素（０１９）は、属するmessage要素の評価がいつ実行されるかを定義する。その値は実装に依存するが，典型的には、「REQUIRED」（利用者が明示的に要求したとき）、「LOADED」（評価ルール定義ファイルが実装システムに読み込まれたとき）、「CHANID=nnnn」（msgId属性の値がnnnnの別のmessage要素が評価されたときに連鎖して実行）などとなる。複数の時点で評価される可能性があるため、一つのmessage要素に一つ以上のpointOfTime要素を定義できる。
【００３２】
criteria要素（０２０）は、属するmessage要素の評価が成立する条件を定義する。
要素の値は、比較演算子（＜、＜＝、＝、＞＝、＞）、論理演算子（AND,OR,NOT）、括弧、及びパラメタによる条件式である。パラメタは固定文字列を直接記述する場合と、param要素（０２２）によって数式やデータ項目の値を参照する場合がある。条件式の評価結果が真であれば、そのmessage要素の評価が成立したことになる。criteria要素が省略された場合、そのmessage要素は常に成立することになる。
【００３３】
msgDescription要素（０２１）は、criteria要素の条件式が成立し、message要素の評価が成立したときに利用者に提示される情報を定義する。
msgDescription要素は、属するmessage要素が別のmessage要素に従属する、すなわち、別message要素内のcriteria要素内のparam要素で参照されるためだけに記述されている場合は省略される。また、同時に複数の手段で利用者に提示される場合は必要な数だけ定義される。
type属性の値は、実装に依存するがmsgDescription要素の内容を利用者に提示する手段を指定する。典型的には、「MSGBOX」（ポップアップダイアログボックスによるメッセージ表示）、「LOGFILE」（所定のログファイルへの書き込み）、「MAIL」（所定の管理者宛ての電子メール送信）などがある。
要素の値は、type属性で指定された提示方法と実装に依存する。
【００３４】
param要素（０２２）は、データ項目、数式、メッセージを参照する為に用いる。
command要素（０１６）に埋め込まれた場合は、主にそのコマンド文字列の変数として埋め込むデータ項目や数式（の計算結果）を参照する。
criteria要素（０２０）に埋め込まれた場合は、その条件式の変数として埋め込むデータ項目や数式（の計算結果）や別メッセージの（criteria要素の）評価結果を参照する。
msgDescription要素（０２１）に埋め込まれた場合は、そのメッセージ内に埋め込むデータ項目や数式（の計算結果）や別メッセージの（criteria要素の）評価結果を参照する。
param要素は要素としての値をもたない。
from属性で埋め込むデータの識別子を参照することで埋め込みデータを指定する。埋め込むデータが、データ項目の場合は、当該データ項目（value要素）のvarId属性値、数式の演算結果の場合は当該数式（rule要素）のruId属性値、メッセージの評価結果の場合は、当該メッセージ（message要素）のmsgId属性値を設定する。
【００３５】
type属性はfrom属性で参照されるデータの種類を示す値を設定する。参照データ項目が、データであれば「V」、数式であれば「R」、メッセージであれば「M」である。デフォルトは「V」である。
index属性は集合的なデータの中から特定のデータのみを指定する場合に用いる。集合的でないデータに設定した場合は無視される。値の指定方法は三種類ある。符号無しの数値を指定した場合、そのデータ集合の先頭のデータを1とした絶対出現順でデータが指定される。符号付の数値を指定した場合、プラス記号がつく場合はデータ集合の先頭からの相対位置、マイナス記号がつく場合はデータ集合の末尾からの相対位置でデータが指定される。上記のいずれでもない場合、データ項目の識別子（varId）と見做し，そのデータ内容を参照する。そのデータ項目が集合的である場合や、数値以外のものを返す場合、あるいは該当する識別子が存在しない場合はindex属性の指定はなかったものとする。結果の値は絶対位置の指定として処理される。いずれの指定方法でも、データ集合の範囲外が指定された場合は、もっとも近い正当なデータ項目を指すように補正される。この属性が指定されている場合は、その参照元を集合的ではないものとして扱う。
例えば、あるデータ集合（1,5,2,4,7,10）があったとすると、index属性の値が、「1」または「+0」または「-5」の場合は1、「6」または「-0」または「+5」の場合は10、「3」または「+2」または「-3」の場合2を指す。「7」の場合は「6」に補正されて10を指し、「-10」の場合は「-5」に補正されて1を指す。
【００３６】
次に、評価ルール定義ファイルの定義例と実装システム例を元に本発明の適用方法を説明する。説明に使用する実装システム例のシステム名はＱＳ１と呼ぶ。
以下の文中で「ＱＳ１では・・」等と記載された場合、それはＱＳ１における実装例であり、別の実装ではまた異なる実装方法をとることも可能であることを意味する。また、「データ「nnn」」という表現があった場合、それはデータ識別子（varId属性）で値「nnn」を指定され、その識別子で参照されるデータを意味する。数式やメッセージについても同様である。
図４〜図８は、評価ルール定義ファイルの一例を示した図である。
このファイルには一つの品質評価ルール（行００５〜２３９）が含まれる。これは、ＣＯＢＯＬ言語で書かれたプログラムのソースコード行をベースとした単体テスト品質評価を行うためのものある。
機能は、プログラムチェックリスト消し込み予測及びバグ摘出累積件数予測グラフ、及びそれらの実績グラフの表示と、評価実行時におけるバグ摘出累積件数の実績／予測の乖離率を算出し、それが上下20％を越えた場合に警告を発するというものである。
【００３７】
ＱＳ１においては、所定のディレクトリに格納されている評価ルール定義ファイルを一括して読み込み、利用者に適用する品質評価ルールを選択させる仕様になっている。この処理には、定義ファイル内のexplain要素の内容を用いる。図４であれば、行００６〜行０１４が該当する。
【００３８】
図９は、ＱＳ１における評価ルール選択画面の表示例図である。
この画面においては、画面部品２０１でカテゴリタイプ（分類の視点）を画面部品２０２でそのカテゴリタイプに含まれるカテゴリを選択することで、それに該当する品質評価ルールの名称が画面部品２０３に一覧表示される。
この例においては、「プログラム言語」の視点から「ＣＯＢＯＬ」言語に関する品質評価ルールを一覧しているが、図４の評価ルール定義ファイルは行００８において、type属性の値が「PrgL」（ＱＳ１の表現では「プログラム言語」）で、要素値が「COBOL」（ＱＳ１の表現では「ＣＯＢＯＬ」）であるcategory要素を記述しているため、画面部品２０３の評価ルール一覧に、title要素（行００７）の要素値を表示している。
図１０は、図９とは異なる視点で分類した評価ルール選択画面の表示例図である。
この例においては、「基準指標」（画面部品３０１）の視点から「ソース行数」（画面部品３０２）を基準とした品質評価ルールを一覧（画面部品３０３）している。図４の評価ルール定義ファイルは行００９において、type属性の値が「Base」（ＱＳ１の表現では「基準指標」）で、要素値が「LOC」（ＱＳ１の表現では「ソース行数」）であるcategory要素を記述しているため、この画面でも一覧表示されている。
【００３９】
図１１は、ＱＳ１における評価ルール詳細画面の表示例図である。
この画面は、図９または図１０の画面部品４０３で評価ルールを選択し、画面部品４０４を押下することで表示され、選択した評価ルールのexplain要素の内容を参照できる。
この例においては、図４の評価ルール定義ファイルの評価ルール「B001」（行００５）を示している。画面部品４０１にはtitle要素値が表示される。ここでは行００７のtitle要素の値が表示されている。画面部品４０２にはcategory要素の内容が表示される。ここでは、行００８〜行０１１の内容が反映されている。なお、カテゴリタイプ（type属性）の値はＱＳ１においては、「PrgL」は「プログラム言語」、「Base」は「基準指標」、「Proc」は「適用工程」、「Doc」は「文書種別」とマップされ、カテゴリ（category要素値）の値はＱＳ１においては、「COBOL」は「ＣＯＢＯＬ」、「LOC」は「ソース行数」、「UT」は「単体テスト（ＵＴ）」、「BugExtractionCurve」は「ＰＣＬ／バグ摘出曲線」とマップされ表示されている。
【００４０】
ＱＳ１においては、評価ルール選択画面で評価ルールを選択して実行することで、その評価ルールが有効になり、定義された手順で品質評価が実行される。この操作は、図９あるいは図１０の画面部品２０３，３０３から評価ルールを選択し、画面部品２０５，３０５を押下することである。
ここでは、評価ルール「B001」が実行されたものとして、以下その処理の流れを説明する。
【００４１】
まず、評価ルール「B001」で使用するデータについて説明する。
図３０は、評価ルール「B001」で使用するデータの概要を一覧表にまとめた図である。
これらのデータの定義は、図４，図５の行０１５〜行０９２に記述されているdataAddress要素から導かれる。
【００４２】
図３０の行１は図４の行０１８〜行０２１のviewDefinition要素に対応する。
図４の行０１５〜行０２２のdataAddress要素が定義するデータのデータソースのタイプは、図４の行０１７のdatasource要素の定義により、ＱＳ１においては手入力（type="MANUAL"）である。その中で、このviewDefinition要素は要素値をTargetModuleとするcommand要素（図４の行０１９）を持つ。これは、ＱＳ１においてTargetModuleという名前で識別される値を要求することを意味する。
この値は、ＱＳ１が表示するダイアログボックスを用いて利用者から入力される。こうして取得された値は、評価ルール内で、データ識別子「B001VM01」で参照される（図４の行０１８）。
command要素がもつデータ値は一つだけなので、position属性の指定は不要である。
【００４３】
図２０の行２は、図４の行０２６〜行０３０のviewDefinition要素に対応する。
図４の行０２３〜行０３１のdataAddress要素が定義するデータのデータソースのタイプは、図４の行０２５のdatasource要素の定義により、ＱＳ１においてはシステム情報（type="SYSTEM"）である。その中で、このviewDefinition要素は要素値をSYSDATEとするcommand要素（図４の行０２８）を持つ。これは、QS１においてはシステム日付を参照することを意味する。この値は、評価ルール内で、データ識別子「B001VS01」で参照される（図４の行０２９）。command要素がもつデータ値は一つだけなので、position属性の指定は不要である。
【００４４】
図３０の行３〜行６は、図４の行０３２〜行０５８のdataAddress要素に対応する。このdataAddress要素が定義するデータのデータソースのタイプは、図４行０３４のdatasource要素の定義により、ＱＳ１においてはユーザ定義関数（type="USERS"）である。ユーザ定義関数とは、ここでは、実装系が独自に提供する関数を指す。
図３０の行３は、図４の行０３５〜行０４０のviewDefinition要素に対応する。
ユーザ定義関数のcommand要素値の書式は、ＱＳ１では、関数名と引数群の列挙である。引数は、param要素またはカンマ区切りの定数で記述する。
図４の行０３７のcommand要素は、CalcCalendar1という名称のユーザ定義関数をデータ「B001VD04」と、データ「B001VD02」を引数として実行することを意味する。
「B001VD04」「B001VD02」については、詳細は後述するが、それぞれ「テスト予定日数」「テスト開始日」を意味する。ＱＳ１のCalcCalendar1関数は指定した日付を含め、その日から指定した日数分の日付を返却する関数なので、このcommand要素の内容を実行すれば、予定どおりにテストが進捗した場合のすべての日付が取得できる。このcommand要素の実行結果は複数の結果を返すので、「type="MULTIPLE"」を指定する。この値はデータ識別子「B001VF01」で参照される（図４の行０３９）。
ＱＳ１においては、複数の結果を返す場合、それが内部的な計算に利用される場合は集合的に処理され（計算をデータ数分繰り返す）、外部出力される場合はカンマ区切りの文字列に変換して渡される。
【００４５】
図３０の行４は、図４の行０４１〜行０４６のviewDefinition要素に対応する。
図４の行０４３のcommand要素は、CalcCalendar2という名称のユーザ定義関数をデータ「B001VD04」と、データ「B001VS01」を引数として実行することを意味する。ＱＳ１のCalcCalendar2関数は指定した日付を両端とする期間に含まれる日付すべてを列挙する関数なので、ここでは、テストの開始日から現在までのすべての日付が返される（「B001VD04」は「テスト開始日」、「B001VS01」は「システム日付」を意味するため）。このcommand要素の実行結果は複数の結果を返すので、「type="MULTIPLE"」を指定する。この値はデータ識別子「B001VF02」で参照される（図４の行０４５）。
【００４６】
図３０の行５は、図４の行０４７〜行０５２のviewDefinition要素に対応する。
図４の行０４９のcommand要素は、CalcCalendar3という名称のユーザ定義関数をデータ「B001VD04」と、データ「B001VS01」を引数として実行することを意味する。ＱＳ１のCalcCalendar3関数は指定した日付間の日数を計算する関数なので、ここでは、テストの開始日から現在までの日数が返される（「B001VD04」は「テスト開始日」、「B001VS01」は「システム日付」を意味するため）。この値はデータ識別子「B001VF03」で参照される（図４の行０５１）。
【００４７】
図３０行６は、図４の行０５３〜行０５７のviewDefinition要素に対応する。
図４の行０５５のcommand要素は、Rangeという名称のユーザ定義関数を固定値「1」とデータ「B001VD02」を引数として実行することを意味する。QS１のRange関数は指定した数値を両端とする範囲に含まれる整数をすべて列挙する関数なので、ここではテスト開始日からテストの予定終了日までの各日におけるテスト開始日からの経過日数すべてが返される（「B001VD02」は「テスト予定日数」を意味するため）。このcommand要素の実行結果は複数の結果を返すので、「type="MULTIPLE"」を指定する。この値はデータ識別子「B001VF04」で参照される（図４の行０５６）。
【００４８】
図３０の行７〜行９は、図５の行０５９〜行０８４のdataAddress要素に対応する。
このdataAddress要素が定義するデータのデータソースタイプは、図５の行０６１のdatasource要素の指定により、ＱＳ１ではリレーショナルデータベースである（type="RDB"）。このdatasource要素は要素値「QE0001」を持っているが、これはＱＳ１では、データベース名「QE0001」のデータベースを利用することの指定である。
図３０に、データベース「QE0001」のテーブル定義の一部（単体テストに関連する部分）を示す。
モジュール別単体テスト工程管理表では、システムに含まれるすべてのモジュールの単体テスト工程に関する基本情報を保持する。
「モジュールＩＤ」は、モジュールの一意識別子である。
「実績ステップ数」は、モジュールの実際のステップ数である。
「単体テスト予定日数」は、単体テストの所要日数の見積もりである。
「単体テストチェック件数」は、単体テスト用プログラムチェックリストに設定されたチェック件数である。
「単体テスト実績開始日」は、実際に単体テストが開始された日付である。
「単体テスト実績終了日」は、単体テストが終了した時に、その日付を設定する。
モジュール別チェック項目管理表は、単体テスト用プログラムチェックリストに設定されたチェック項目の基本情報と、その消し込み状況を保持する。
「モジュールＩＤ」は、モジュールの一意識別子である。
「チェックＩＤ」は、チェック項目の一意識別子である。「モジュールＩＤ」と「チェックＩＤ」の組み合わせでレコードを一意に識別する。
「チェック種別」は、そのチェック項目の種類のものであるかを示す文字を設定する。
例えば、通常処理をチェックする項目であれば「N」、異常処理をチェックする項目であれば「E」などである。
「消し込み日」は、そのチェック項目のチェックが完了した日を設定する。
モジュール別バグ管理表は、摘出されたバグを履歴的に一覧管理する表である。
「バグ通番」は、バグの一意識別子である。
「モジュールＩＤ」は、モジュールの一意識別子である。
「チェックＩＤ」は、チェック項目の一意識別子である。「モジュールＩＤ」と「チェックＩＤ」はモジュール別チェック項目管理表を参照する外部キーである。
「発生日」は、そのバグが発生した日である。
「解決日」は、そのバグが解決した日である。
【００４９】
図３０の行７は、図５の行０６３〜行０７０のviewDefinition要素に対応する。
データソースタイプがリレーショナルデータベースの場合、command要素の要素値は発行するＳＱＬ文など、そのデータベースが受け入れるコマンド文字列になる。
そのため、図５の行０６４のcommand要素の要素値は、param要素で参照するデータ「B001VM01」が仮に「AX001D05」であったとすると、ＳＱＬ文「SELECT MDST,MDPC,MDCC,MDAB FROM MUTS WHERE MDID='AX001D05'」であると解釈される（'はＸＭＬ文書においては単一引用符を意味する）。このＳＱＬ文を実行すると、モジュール別単体テスト工程管理表（MUTS）から、指定のモジュールＩＤ（MDID）のモジュールの、実績ステップ数（MDST）、単体テスト予定日数（MDPC）、単体テストチェック件数（MDCC）、単体テスト実績開始日（MDAB）を取得できる。モジュールＩＤは一意であるので返される結果は単一である。
図５の行０６６のvalue要素の定義により、結果の第１カラム（position="@1"）、すなわち実績ステップ数は「B001VD01」で参照される（varId="B001VD01"）。
図５の行０６７のvalue要素の定義により、結果の第２カラム（position="@2"）、すなわち単体テスト予定日数は「B001VD02」で参照される（varId="B001VD02"）。
図５の行０６８のvalue要素の定義により、結果の第３カラム（position="@3"）、すなわち単体テストチェック件数は「B001VD03」で参照される（varId="B001VD03"）。図４の行０６９のvalue要素の定義により、結果の第４カラム（position="@4"）、すなわち単体テスト実績開始日は「B001VD04」で参照される（varId="B001VD04"）。
【００５０】
図３０の行８は、図５の行０７２〜行０７７のviewDefinition要素に対応する。
図５の行０７３のcommand要素の要素値は、param要素で参照するデータ「B001VD03」が仮に「112」で、データ「B001VM01」が仮に「AX001D05」で、データ「B001VF02」が仮に「2000/2/1,200/2/2,2000/2/3,2000/2/4」の複数の値であるとすると、ＳＱＬ文「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND MCEL<=TO_DATE('2000/2/1')」「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND MCEL<=TO_DATE('2000/2/2')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL<=TO_DATE('2000/2/3')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL<=TO_DATE('2000/2/4')」
であると解釈される（<はＸＭＬ文書においては「<」を意味する）。
これらのＳＱＬ文を実行すると、モジュール別チェック項目管理表（MUTC）を集計し、指定のモジュールＩＤ（MDID）のモジュールの、指定日以前の消し込み日（MCEL）を持つレコードの総件数をチェック項目総数から差し引いた値が返される。すなわち、この例では、2000/2/1〜2000/2/4までの各日におけるチェックリスト残件数が取得できる。このＳＱＬ文自体は単一の結果しか返さないが、指定のパラメタが複数の値をとりうるため、結果として複数の結果を持つことになる。
図５の行０７６のvalue要素の定義により、結果の第1カラム（position="@1"）、すなわちチェックリスト残件数は、「B001VD06」で参照される（varId="B001VD06"）。
【００５１】
図３０の行９は、図５の行０７９〜行０８４のviewDefinition要素に対応する。
図５の行０８０のcommand要素の要素値は、param要素で参照するデータ「B001VM01」が仮に「AX001D05」で、データ「B001VF02」が仮に「2000/2/1,200/2/2,2000/2/3,2000/2/4」の複数の値であるとすると、ＳＱＬ文「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND MBOD<=TO_DATE('2000/2/1')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND
MBOD<=TO_DATE('2000/2/2')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND
MBOD<=TO_DATE('2000/2/3')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND
MBOD<=TO_DATE('2000/2/4')」
であると解釈される。
これらのＳＱＬ文を実行すると、モジュール別バグ管理表（MUTB）を集計し、指定のモジュールＩＤ（MDID）のモジュールの、指定日以前の発生日（MBOD）を持つレコードの総件数を返す。すなわち、この例では2000/2/1〜2000/2/4までの各日におけるバグ摘出累積件数が取得できる。このＳＱＬ文自体は単一の結果しか返さないが、指定のパラメタが複数の値をとりうるため、結果として複数の結果を持つことになる。
図５の行０８２のvalue要素の定義により、結果の第1カラム（position="@1"）、すなわちバグ摘出累積件数は、「B001VD07」で参照される（varId="B001VD07"）。
【００５２】
図３０の行１０は、図５の行０８８〜行０９１のviewDefinition要素に対応する。
このviewDefinition要素が属するdataAddress要素（図５の行０８５〜行０９２）が定義するデータのデータソースタイプは、図５の行０８７のdatasource要素の定義により、ＱＳ１ではＸＭＬ文書である（type="XML"）。このdatasource要素は要素値として「standards.xml」を持っているが、これはＱＳ１では、「standards.xml」というファイル名のXML文書を参照することを意味する。
データソースタイプがXML文書である場合、ＱＳ１ではcommand要素の要素値は、XPathの構文となり、その構文で指定されるＸＭＬ文書要素または属性の値が、command要素の実行結果の値となる。
図５の行０８９のcommand要素は、standards.xmlファイルのstandards文書要素の子要素utの子要素bugDensityKLOC要素の値（ここでは1Kステップ行当りのバグ件数を示す）を参照している。
この値は、図５の行０９０のvalue要素の定義により、データ識別子「B001VX01」で参照される（varId="B001VX01"）。
図３１（ａ）（ｂ）（ｃ）は、図１における品質データベース６の構成例を示す図である。
【００５３】
次に、評価ルール「B001」で使用する数式について説明する。
図３２は、評価ルール「B001」で使用する数式の概要を一覧表にまとめた図である。
これらのデータの定義は、図５〜図７の行０９４〜行２０９に記述されているrules要素から導かれる。
【００５４】
図３２の行１は、図５の行０９５〜行１１６のrule要素に対応する。
この要素で定義する数式の識別子は「B001R01」である（ruId="B001R01"）。
数式自体の定義は、MathML(TM)にしたがって記述する。このrule要素の数式は、図５の行０９７〜行１１０のmath要素で定義されている。
MathML(TM)では演算の最小単位をapply要素で表現する。基本的には、apply要素の最初の子要素に、その演算方法（加算、減算など）を示す要素を設定し、それに続いてオペランドを指定する子要素を設定する。オペランドが数字であればcn要素で定義し、そうでないならci要素で定義する。また他のapply要素を子要素にすることもできる。
例えば、「a+1」をMathML(TM)で表現すると、
<apply><plus /><ci>a</ci><cn>1</cn></apply>
のようになる。
従って、図５の行１０２〜行１０５のapply要素は「k+1」を示し、図５の行１００〜行１０６のapply要素は「k/(k+1)」を示し、図５の行０９９〜行１０７のapply要素は「log0.04236(k/(k+1))」を示し、図５の行１０８のapply要素は「1/t」を示し、図５の行０９８〜行１０９のapply要素は、「(log0.04236(k/(k+1)))^(1/t)」を示す（＾は累乗を表す）。
こうして表現された数式を実際に計算するには、変数の部分に値を設定する必要があるが、これはmath要素に続くpath要素で行う。
path要素では設定するデータの指定をassociatedData属性で、設定先を要素値のXPath構文で指定する。
図５の行１１２のpath要素ではデータ「B001VD03」をmath要素の子のapply要素の最初の子apply要素の子のapply要素の子のci要素（図５の行１０１）に設定することを示している。
図５の行１１３のpath要素ではデータ「B001VD03」をmath要素の子のapply要素の最初の子apply要素の子のapply要素の子のapply要素の子のci要素（図５の行１０３）に設定することを示している。
図５の行１１５のpath要素では、データ「B001VD02」をmath要素の子のapply要素の２番目の子apply要素の子のci要素（図５の行１０８）に設定することを示している。
この数式を計算すると、予定の日数で単体テストが終了する（収束する）場合のチェック項目残件数予測グラフを描画するためのゴンペルツ曲線の傾きを決定する値を計算することができる。
【００５５】
図３２の行２は、図６の行１１７〜行１３８のrule要素に対応する。
この要素で定義する数式の識別子は「B001R02」である（ruId="B001R02"）。
数式自体（図６の行１１９〜行１３２）は「B001R01」の数式と同様であるが、変数に設定する値が一部異なっている。
数式「B001R01」でデータ「B001VD03」を埋め込むところには、数式「B001R03」の演算結果を埋め込む（図６の行１３４及び行１３５）。「type="R"」とは数式の演算結果を参照していることを明示する（type属性省略時には値「V」がデフォルトとなる。これはデータを参照していることを示す）。
この数式を計算すると、予定の日数で単体テストが終了する（収束する）場合のバグ摘出累積件数予測グラフを描画するためのゴンペルツ曲線の傾きを決定する値を計算することができる。
【００５６】
図３２の行３は、図６の行１３９〜行１５１のrule要素に対応する。
この要素で定義する数式の識別子は「B001R03」である（ruId="B001R03"）。
このrule要素の数式は、図６の行１４１〜行１４６のmath要素に記述されている。
図６の行１４４のapply要素は「d/1000」を示し、図６の行１４２〜行１４５のapply要素は「k*(d/1000)」を示している。
図６の行１４８のpath要素ではデータ「B001VD01」をmath要素の子のapply要素の子のci要素（図６の行１４３）に設定することを示している。
図６の行１５０のpath要素ではデータ「B001VX01」をmath要素の子のapply要素の子のapply要素の子のci要素（図６行の１４４）に設定することを示している。
この数式を計算すると、現在のモジュールの規模で摘出しなければならないバグの目標数を計算することができる。
【００５７】
図３２の行４は、図６の行１５２〜行１７２のrule要素に対応する。
この要素で定義する数式の識別子は「B001R04」である（ruId="B001R04"）。
このrule要素の数式は、図６の行１５４〜行１６５のmath要素に記述されている。
図６の行１５９〜行１６２のapply要素は「b^t」を示し、図６の行１５７〜行１６３のapply要素は「0.04236^(b^t)」を示し、図６の行１５５〜行１６４のapply要素は「K*(0.04236^(b^t))」を示している。
図６の行１６７のpath要素では数式「B001R03」の演算結果をmath要素の子のapply要素の子のci要素（図６の行１５６）に設定することを示している。
図６の行１６９のpath要素では数式「B001R02」の演算結果をmath要素の子のapply要素の子のapply要素の子のapply要素の最初の子ci要素（図６の行１６０）に設定することを示している。
図６の行１７１のpath要素ではデータ「B001VF04」をmath要素の子のapply要素の子のapply要素の子のapply要素の２番目の子ci要素（図４の行１６１）に設定することを示している。
なお、データ「B001VF04」は複数の値を持つため、この数式の演算結果も同様に集合的に扱われる。
この数式を計算すると、単体テスト期間内の各日におけるバグ摘出累積予測件数を取得できる。
【００５８】
図３２の行５は、図７の行１７３〜行１９８のrule要素に対応する。
この要素で定義する数式の識別子は「B001R05」である（ruId="B001R05"）。
このrule要素の数式は、図７の行１７５〜行１９０のmath要素に記述されている。
図７の行１８３〜行１８６のapply要素は「b^t」を示し、図７の行１８１〜行１８７のapply要素は「0.04236^(b^t)」を示し、図７の行１７８〜行１８８のapply要素は「-1*K*(0.04236^(b^t))」を示し、図７の行１７６〜行１８９のapply要素は「K+(-1*K*(0.04236^(b^t)))」を示す。
図７の行１９２のpath要素はデータ「B001VD03」をmath要素の子のapply要素の子のci要素（図７の行１７７）に設定することを示している。
図７の行１９３のpath要素はデータ「B001VD03」をmath要素の子のapply要素の子のapply要素の子のci要素（図７の行１８０）に設定することを示している。
図７の行１９５のpath要素は数式「B001R01」の演算結果をmath要素の子のapply要素の子のapply要素の子のapply要素の子のapply要素の先頭の子ci要素（図７の行１８４）に設定することを示している。
図７の行１９７のpath要素はデータ「B001R01」をmath要素の子のapply要素の子のapply要素の子のapply要素の子のapply要素の２番目の子ci要素（図７の行１８５）に設定することを示している。
なお、データ「B001VF04」は複数の値を持つため、この数式の演算結果も同様に集合的に扱われる。
この数式を計算すると、単体テスト期間内の各日におけるチェックリスト残件数予測を取得できる。
【００５９】
図３２の行６は、図７の行１９９〜行２０８のrule要素に対応する。
この要素で定義する数式の識別子は「B001R06」である（ruId="B001R06"）。
このrule要素の数式は、図７の行２０１〜行２０３のmath要素に記述されている。
図７の行２０２のapply要素は「a/b」を示す。
図７の行２０５のpath要素は複数の結果を返すデータ「B001VD07」の末尾（index="-0"）のデータをmath要素の子のapply要素の最初の子ci要素に設定することを示している。
図７の行２０７のpah要素は複数の結果を返す数式「B001R04」の、データ「B001VF03」で示される位置の演算結果（例えば、「B001R04」が「0 5 7 9」の結果を持ち、「B001VF03」が「2」を返すなら、「5」がとるべき値となる）をmath要素の子のapply要素の２番目の子ci要素に設定することを示している。
この数式を計算すると、評価実行日におけるバグ摘出累積予測件数と実際の値の乖離率を取得できる。
【００６０】
前記の段落番号〔００４１〕〜〔００５９〕で説明したデータ及び数式は、メッセージ処理の開始をトリガーとして、参照・評価される。
【００６１】
評価ルール「B001」のメッセージ処理は、図７の行２１１〜行２３８のmessages要素で定義される。このmessages要素には、メッセージ識別子「B001M01」のmessage要素（図７の行２１３〜行２２６）と、メッセージ識別子「B001M011」のmessage要素（図８の行２２７〜行２３７）が含まれる。
【００６２】
メッセージ「B001M01」は、図７の行２１４のpointOfTime要素の要素値が「REQUIRED」であるため、ＱＳ１においては、評価ルール実行時に即座に処理される。
メッセージ「B001M011」は、図８の行２２９のpointOfTime要素の要素値が「CHAINED:B001M01」であるため、ＱＳ１においては、メッセージ「B001M01」が処理された時点で連鎖して実行される。
以上より、評価ルール「B001」のメッセージ処理はすべて、評価ルール適用時に一括して処理される。
【００６３】
メッセージ「B001M01」には、criteria要素が含まれていないので、そのmsgDescription要素（図７の行２１５〜行２２５）は、メッセージ処理時には常に提示される。このmsgDesciption要素は、「type="GRAPH"」の指定により、ＱＳ１においては、ＱＳ１のグラフ作成機能を利用することを意味する。ＱＳ１のグラフ作成機能では、描画に必要なデータは、XML形式で設定することになっているため、msgDescription要素の要素値は、そのXML形式データのテンプレート文字列である。
このテンプレートにデータを埋め込む場所とその内容はparam要素で指定されている（図７の行２１７、行２１８、行２１９、行２２１、行２２２、行２２４）。
図３３は、これらのparam要素で参照されているデータ及び数式を一覧表にまとめた図である。
【００６４】
メッセージ処理が開始され、msgDescription要素の内容が評価される時点で、これらの値がその定義された方法に従って評価され、その最終的な結果がmsgDescription要素内容に埋め込まれ、そのmsgDescription要素のタイプに適切な処理部に渡される。
図１５は、これらのparam要素の評価方法を示した図である。
例えば、データ「B001VD06」（図１５の００４）を参照するparam要素を評価するには、データ「B001VD03」（図１５の００５）、データ「B001VM01」（図１５の００８）、データ「B001VF02」（図１５の００９）を必要とする。このうち、データ「B001VF02」は複数の結果を返すので、データ「B001VD06」も複数の結果を返す。データ「B001VD03」を取得するには、データ「B001VM01」（図１５の０１０）が必要で、データ「B001VF02」を取得するには、データ「B001VD04」（図１５の０１１）とデータ「B001VS01」（図１５の０１２）を必要とする。データ「B001VD04」を取得するにはデータ「B001VM01」（図１５の０１３）を必要とする。
他のparam要素も同様に評価する。なお、ここに示したのは意味的なデータ間の依存関係であり、実際の演算方法は実装に依存する。
【００６５】
ここで、品質データベースが図３４，図３５で示す内容を保持していたとする。
ＱＳ１では、msgDescription要素内の出現順でparam要素を評価するため、まず、データ「B001VF01」のparam要素（図１５の００１）が評価される。
このときまず、依存関係の終端にある、データ「B001VM01」の解決が試みられる。データ「B001VM01」は、「TargetModule」パラメタを手入力するデータ項目であるため、ＱＳ１では、入力ダイアログボックスを開いて利用者に入力を促す。ここでは、値「AX001D05」を入力したものとする。
図１２はその画面表示イメージ図である。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図１６のようになっている。
【００６６】
次に、データ「B001VD04」及びデータ「B001VD02」を解決するために、これらのデータ項目定義が属するviewDefinition要素のcommand要素によって示されるＳＱＬ文「SELECT MDST,MDPC,MDCC,MDAB FROM MUTS WHERE MDID='AX001D05'」がデータベース「QE0001」に対して実行される。このviewDefinition要素には、データ「B001VD01」及びデータ「B001VD03」のデータ項目定義も含まれるため、これらのデータ項目も同時に解決される。表６のモジュール別単体テスト工程管理表テーブルの内容から、上記ＳＱＬ文の実行結果は「1232,10,112,2000/2/1」となるため、データ「B001VD01」、データ「B001VD02」、データ「B001VD03」、データ「B001VD04」はそれぞれ、「1232」、「10」、「112」、「2000/2/1」と解決される。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図１７のようになっている。
【００６７】
次に、データ「B001VF01」を解決するために、値「2000/2/1」及び「10」を引数としてユーザ定義関数「CalcCalendar1」を実行する。結果は、
「2000/2/1,2000/2/2,2000/2/3,2000/2/4,2000/2/5,2000/2/6,2000/2/7,2000/2/8,2000/2/9,2000/2/10」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図１８のようになっている。
【００６８】
次に、データ「B001VF02」のparam要素（図１５の００２）を解決する。
データ「B001VD04」はすでに評価済みであるので参照のみを行い、データ「B001VS01」の評価を行う。データ「B001VS01」はシステム日付の取得を行うものであり、ここではシステム日付を「2000/2/4」と仮定するので、評価結果は「2000/2/4」となる。
次にデータ「B001VF02」を解決するために、値「2000/2/1」及び「2000/2/4」を引数としてユーザ定義関数「CalcCalendar2」を実行する。結果は、
「2000/2/1,2000/2/2,2000/2/3,2000/2/4」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図１９のようになっている。
【００６９】
次に、データ「B001R05」のparam要素（図１５の００３）を解決する。
これに必要な、データ「B001VD03」、数式「B001R01」、データ「B001VF04」のうち、データ「B001VD03」は評価済みであるので、まず数式「B001R01」を評価する。
数式「B001R01」の評価に必要な変数はすでに評価済みであるので、それを数式に当てはめて計算する。すなわち、式「(log0.04236(112/(112+1)))^(1/10)」の計算結果「0.55577」が評価結果となる。
次に、データ「B001VF04」を評価する。このとき、引数として固定値「1」とデータ「B001VD02」の評価結果「10」を引数としてユーザ定義関数「Range」を実行する。
結果は、「1,2,3,4,5,6,7,8,9,10」となる。
よって、数式「B001R05」の評価結果は、式「112+(-1*112*(0.04236^(0.55577^t)))」の変数tに、データ「B001VF04」の評価結果の値を一つづつ設定して計算した値の集合「92.057,69.075,46.274,28.715,17.001,9.793,5.553,3.121,1.745,0.973」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図２０のようになっている。
【００７０】
次に、データ「B001VD06」のparam要素（図１５の００４）を解決する。
ここで必要なパラメタはすでに解決済みであるので、データ「B001VD06」の評価結果は、ＳＱＬ文「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND MCEL <=TO_DATE('2000/2/1')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL <=TO_DATE('2000/2/2')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL <=TO_DATE('2000/2/3')」
「SELECT 112 ? COUNT(*) FROM MTUC WHERE MDID='AX001D05' AND
MCEL <=TO_DATE('2000/2/4')」
の実行結果「98,82,68,66」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図２１のようになっている。
【００７１】
次に、数式「B001R04」のparam要素（図１５の００５）を解決する。
ここで、データ「B001VX01」として参照されるstandards.xmlファイルの「standards/ut/bugDensityKLOC」要素の要素値が、「10」であったとすると、数式「B001R03」の値は、式「1232*(10/1000)」の評価結果、すなわち「12.32」であるため、数式「B001R02」の値は、式「(log0.04236(12.32/(12.32+1)))^(1/10)」の計算結果「0.690626」である。
よって、数式「B001R04」の評価結果は、式「12.32*(0.04236^(0.690626^t))」」の変数tに、データ「B001VF04」の評価結果の値を一つづつ設定して計算した値の集合「1.443,2.802,4.43,6.079,7.564,8.796,9.763,10.491,11.026,11.411」となる。
この時点で、メッセージ「B001M01」のmsgDescription要素の評価処理の進捗状況は、図２２のようになっている。
【００７２】
最後に、データ「B001VD07」のparam要素（図１５の００６）を解決する。
ここで必要なパラメタはすでに解決済みであるので、データ「B001VD07」の評価結果は、ＳＱＬ文「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' ANDMCEL <=TO_DATE('2000/2/1')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND MCEL
<=TO_DATE('2000/2/2')」「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND MCEL <=TO_DATE('2000/2/3')」
「SELECT COUNT(*) FROM MTUB WHERE MDID='AX001D05' AND MCEL
<=TO_DATE('2000/2/4')」の実行結果「1,2,4,8」となる。こうして、メッセージ「B001M01」のmsgDescription要素の評価は最終的に図２３のようになる。
【００７３】
よって、メッセージ「B001M01」のmsgDescription要素（図７の行２１５〜行２２５）の内容は最終的に、「<gp><template>Curve1</template><axis type="y" id="X" min="0" max="120" /><axis type="y" id="Y" min="0" max="15" /><axis id="A" type="x" 2000/2/1,2000/2/2,2000/2/3,2000/2/4,2000/2/5,2000/2/6,2000/2/7,2000/2/8,2000/2/9,2000/2/10</axis><axis id="B" type="x" >2000/2/1,2000/2/2,2000/2/3,2000/2/4</axis><axis id="c" type="union A B" /><unit name="ＰＣＬ消化予測" xAx="c" yAx="X"><data>92.057,69.075,46.274,28.715,17.001,9.793,5.553,3.121,1.745,0.973</data></unit><unit name="ＰＣＬ消化実績" xAx="c" yAx="X"><data>98,82,68,66</data></unit><unit name="バグ累積予測" xAx="c" yAx="Y" /><data>1.443,2.802,4.43,6.079,7.564,8.796,9.763,10.491,11.026,11.411</data></unit><unit name="バグ累積実績" xAx="c" yAx="Y" ><data>1,2,4,8</data></unit></gp>」と解釈され、グラフ描画機能部に渡される（<![CDATA[……]]>は、XML文書においては、それに挟まれる部分を単なる文字列として扱うことを意味するので、解釈時には取り外す）。
ＱＳ１は上記のデータを利用して、図１３のように、グラフを描画する。
【００７４】
続いて、メッセージ「B001M011」の評価を行う。
メッセージ「B001M011」にはcriteria要素（図８の行２３０〜行２３１）が含まれるので、この要素内容である論理演算式を評価し、その結果が真であれば、続くmsgDescription要素（図８の行２３２〜行２３３、行２３４〜行２３６）が処理される。
ここで、criteria要素の論理演算式の内容は、数式「B001R06」の演算結果が1.2以上か0.8以下である場合に真となるので、まず、数式「B001R06」の評価を行う。
数式「B001R06」は、図６，図７の行１１９〜行２０８の定義により、データ「B001VD07」の最後のデータ（図７の行２０５）を数式「B001R04」の演算結果のデータ「B001VF03」番目のデータで割ったものであり、これらのデータが、メッセージ「B001M01」の評価結果からも分かるように、データ「B001VD07」が「1,2,4,8」で、数式「B001R04」の演算結果が「1.443,2.802,4.43,6.079,7.564,8.796,9.763,10.491,11.026,11.411」、また、データ「B001VF03」が、ユーザ定義関数「CalcCalendar3」（図４の行０４７〜行０５２）を値「2000/2/1」と値「2000/2/4」を引数として実行（ここでデータ「B001VD04」は「2000/2/1」、データ「B001VS01」は「2000/2/4」であるため）した結果である「4」であるため、式「8/6.079」の演算結果、すなわち「1.316」が評価結果となる。
よって、「(1.316>=1.2) OR (1.316 <=0.8)」という論理演算式は真となる。
【００７５】
criteria要素値の論理演算が成立したので、それに続くmsgDescription要素が処理される。
まず、図８の行２３２〜行２３３のmsgDescription要素が処理される。このmsgDescription要素は、「type="MSGBOX"」の指定により、ＱＳ１においてはmsgDescription要素値をメッセージボックスに表示することを意味する。ここで、データ「B001VM01」の値は、「AX001D05」であるので、「B001:AX001D05:バグ累積件数の予定件数よりの乖離率が20%を越えています。」という文字列が、図１４のように、画面に表示される。
次に、図８の行２３４〜行２３６のmsgDescription要素が処理される。このmsgDescription要素は、「type="LOGFILE"」の指定により、ＱＳ１においてはmsgDescription要素値を所定のログファイルに出力することを意味する。ここで、データ「B001VS01」の値は「2000/2/4」で、データ「B001VM01」の値は、「AX001D05」であるので、「B001:2000/2/1:AX001D05:バグ累積件数の予定件数よりの乖離率が20%を越えています。」という文字列がログファイルに出力される。
【００７６】
以上で、評価ルール「B001」に基く品質評価処理が終了する。
【００７７】
次に、ソフトウェア品質評価ルールが変更になった場合の措置の例を示す。
ルール変更のシナリオは以下の通りであるとする。
(1)ソースコード行による管理からファンクションポイントに基く管理へ移行する上での暫定処置とする。
(2)品質データベースにおいて、モジュールサイズのステップ数による管理は廃止し、代用として、モジュールごとのファンクションポイントを管理するためのテーブルを設ける。
(3)品質データベースにはファンクションポイントを算出するための基礎データを入れ、ファンクションポイントを算出するには、それらのデータと別途定義する基準値を元に計算を行う。
(4)品質評価時には、ファンクションポイントベースの基準値が未決のため、１ファンクションポイント当り90COBOL行として換算し、従来の基準値を適用するものとする。
【００７８】
上記のシナリオに従って品質データベースを変更すると、図２４のようになる。
モジュール別単体テスト工程管理表（MUTS）からは実績ステップ数（MDST）を削除する。
新たに、モジュール別ファンクションポイント管理表（MFPC）を追加する。
「モジュールID」は、レコードの一意識別子である。
「入力項目数」「出力項目数」「参照項目数」「インタフェース数」「データファイル数」はそれぞれ、ファンクションポイント法上のパラメタに対応する。
これらの値にその項目別に設定される「重み」の係数を乗じ、その合計を補正前のファンクションポイントとする。
「複雑さのレベル」は、そのモジュールの難易度を示し、この値に対応した補正係数を補正前のファンクションポイントに乗じて、補正後のファンクションポイントを取得する。
その他のテーブルには変更は加えない。
【００７９】
ファンクションポイント法上の「重み」係数、難易度による補正係数、及び１ＦＰ当りのソースコード行換算係数は、すべてファイルstandards.xmlに追加するものとする。
その変更後の内容の一部を、図２４に示す。
ここでの追加範囲は、行０１０〜行０３２までである。
行０１０〜行０３２までのfp要素は、standards文書要素の直下にあり、ファンクションポイント関連のデータを保持する。
行０１１のinput要素は要素値として入力項目数に対する重み係数を持つ。
行０１２のoutput要素は要素値として出力項目数に対する重み係数を持つ。
行０１３のreference要素は要素値として参照項目数に対する重み係数を持つ。行０１４のinterface要素は要素値としてインタフェース数に対する重み係数を持つ。
行０１５のdatafile要素は要素値としてデータファイル数に対する重み係数を持つ。
行０１６〜行０２８のdifficulty要素は、補正前ファンクションポイントに対する難易度による補正係数のデータを保持する。その子要素である各coefficient要素（行０１７〜行０２７）は、degree属性で指定される複雑さのレベルに応じた補正係数を要素値としてもつ。例えば、行０２３のcoefficient要素では複雑さのレベルが7である場合に、係数1.1が適用されることを示している。
行０２９〜行０３１の１ファンクションポイント当りのソースコード行を算出するための係数のデータを保持する。その子要素であるSLOCperFP要素（行０３０）は、Lang属性で示されるプログラミング言語における標準的な１ＦＰ当りのソースコード行数を要素値として持つ。
【００８０】
上記のような、品質評価方法及び品質データベース及び関連ファイルの構成の変化に対応するために、評価ルール「B001」の定義ファイルを変更する。変更の内容は、モジュール別単体テスト工程管理表から直接参照できなくなった実績ステップ数の変わりに、モジュール別ファンクションポイント管理表の内容から導出されるファンクションポイント数からCOBOLソース行数への換算ステップ数を用いるようにすること、である。
【００８１】
まず、図５の行０６３〜行０７０のviewDefinition要素を図２５のように変更する。これによって、実績ステップ数の代わりに、ファンクションポイントを計算するために必要な基礎データを取得する。対象モジュールの「入力項目数」「出力項目数」「参照項目数」「インタフェース数」「データファイル数」「複雑さのレベル」をそれぞれ、「B001VD08」（図２５の行００９）、「B001VD09」（図２５の行０１０）、「B001VD10」（図２５の行０１１）、「B001VD11」（図２５の行０１２）、「B001VD12」（図２５の行０１３）、「B001VD13」（図２５の行０１４）で参照する。
【００８２】
次に、図５の行０８８〜行０９１のviewDefinition要素の次（すなわち図５の行０９１と行０９２の間）に、図２７のviewDefinition要素を追加する。これによって、ファンクションポイントの計算に必要な係数類を参照する。
図２６の行００１〜行００４では、入力項目数に対する重み係数を「B001VX02」で参照している。
図２６の行００５〜行００８では、出力項目数に対する重み係数を「B001VX03」で参照している。
図２６の行００９〜行０１２では、参照項目数に対する重み係数を「B001VX04」で参照している。
図２６の行０１３〜行０１６では、インタフェース数に対する重み係数を「B001VX05」で参照している。
図２６の行０１７〜行０２０では、データファイル数に対する重み係数を「B001VX06」で参照している。
図２６の行０２１〜行０２５では、データ「B001VD13」をdegree属性値としてもつ補正係数（言い換えると、品質データベースから取得した対象モジュールの複雑さのレベルに対応した補正係数）を「B001VX07」で参照している。「[@degree="x"]」と言う表現は、「degree属性に「x」をもつ要素を選択する」ということを意味する。
同様に、図２６の行０２６〜行０３０では、「COBOL」をLang属性値としてもつ換算係数を「B001VX08」で参照している。
【００８３】
次に、図７の行１９９〜行２０８のrule要素の次（すなわち、図７の行２０８と行２０９の間）に、図２７ののrule要素を追加する。
このrule要素で追加する数式「B001R07」は、対象モジュールのファンクションポイントの算出とその結果にソースコード行換算係数を乗じて、換算ソースコード行数の算出を行う。
【００８４】
最後に、図６の行１４８のpath要素のassociatedData属性値を「B001R07」に変更する。
これにより数式「B001R03」において、以前にデータ「B001VD01」すなわち対象モジュールの実績ステップ数を設定していた変数に、数式「B001R07」すなわち概算ソースコード行数を設定できるようになる。
【００８５】
上記の段落番号〔００８０〕〜〔００８４〕の修正を行うことで、実装システムを更新することなく、定義ファイルの変更のみで新しい品質評価方法に対応できるようになる。
【００８６】
次に、評価ルール定義ファイルの共有例を示す。
【００８７】
評価ルール「B001」をＱＳ１とは異なる実装系ＱＳ２と共有するものとし、ＱＳ２の実装がＱＳ１とほぼ同様であるが、幾つかのキーワードが異なっているものとする。
仮に、ＱＳ１のおけるユーザ定義関数「CalcCalendar1」をＱＳ２では「GetDate1」、ＱＳ１におけるデータソース指定キーワード「MANUAL」をＱＳ２では「UserInput」と表現するものとする。
共有する評価ルール定義ファイルとその文書型宣言ファイルは、ＱＳ１及びＱＳ２の両方からアクセス可能な評価ルールファイル保存部（例えばネットワーク上の共有ディレクトリ上など）に置かれ、必要なときに、ＱＳ１及びＱＳ２のローカルな評価ルール保存部にダウンロードされて利用されるものとする。
【００８８】
この場合は、単なる名前の置き換えでよいので、ＸＭＬのエンティティ参照機能を用いて、図２８のようにして解決できる。
まず、ＱＥＭＬの文書型宣言ファイルに、ローカルな名前解決を行うために、外部エンティティ宣言を追加する（図２８の４０１）。
次に、評価ルール定義ファイル（ここではB001.xml）において、実装システム毎に異なる名称は、エンティティ参照で表現するようにする。この例では、ＱＳ１におけるキーワード「MANUAL」は「&dst1」と置き換えられ（図９の００２）、ユーザ定義関数名「CalcCalendar1」は「&udf1;」と置き換えられている（図２８の４０３）。
そして、ＱＳ１及びＱＳ２のローカルな評価ルール保存部に、上記のエンティティ参照を解決するためのエンティティ宣言を含んだファイルlocal.dtdを置いておけば（図２８の４０４、図２８の４０５）、それぞれの実装系で当該評価ルール定義ファイルが解釈されるときに、エンティティ参照が適切に解決される。
また、それぞれの実装系が利用する品質データベースの構成が異なる場合でも、同様の方法を用いて共有することができる。
【００８９】
【発明の効果】
以上説明したように、本発明によれば、品質管理・評価方法をテキストファイルであるＸＭＬ文書で定義するため、特定の品質管理・評価方法に依存することなく、新しい品質管理・評価方法を開発、導入、運用することが容易となり、また品質管理・評価方法を異なる場所、異なる実装システム間で共有することが容易になる。品質管理・評価方法は、既存の実装システムが前提としない種類のデータソースや、既存の実装システムがユーザ定義関数として提供しない関数機能や、既存の実装システムの機能範囲外の演算方法（math要素の機能範囲）や、既存の実装システムが提供しないような評価結果の出力方法を必須のものとして要求しない限りは、自由に新しいものを開発可能である。
また、定義された品質管理・評価方法は、実装システム間に基本的な共通性がある限りは、異なる場所、異なる実装システム間で共有できる。
なお、基本的な共通性があるとは、(1)提供するユーザ定義関数の機能や評価結果出力方法に共通性があること(2)サポートするデータソースのタイプに共通性があること(3)利用可能な品質データベースの構成が類似していることを意味する。これらについて共通性が高いほど共有が容易になり、そうでない場合は共有が困難になる。但し、その場合でも、評価ルール定義ファイルは単なるテキストファイルであるため、別の実装システムで利用可能なようにそれを変更することは容易である。
【図面の簡単な説明】
【図１】本発明が適用される品質管理及び品質評価システムの構成図である。
【図２】品質評価ルールマークアップ言語ＱＥＭＬ、Ｖｅｒｓｉｏｎ１．０の文書型定義を示す図である。
【図３】図２の内容を図式的に表現した図である。
【図４】本発明における評価ルール定義ファイル例（１）を示す図である。
【図５】本発明における評価ルール定義ファイル例（２）を示す図である。
【図６】本発明における評価ルール定義ファイル例（３）を示す図である。
【図７】本発明における評価ルール定義ファイル例（４）を示す図である。
【図８】本発明における評価ルール定義ファイル例（５）を示す図である。
【図９】本発明におけるＱＳＩ評価ルール選択画面（１）を表す図である。
【図１０】本発明におけるＱＳＩ評価ルール選択画面（２）を表す図である。
【図１１】本発明におけるＱＳＩ評価ルール詳細画面を表す図である。
【図１２】本発明におけるパラメタ入力画面例を表す図である。
【図１３】本発明におけるグラフ画面例を示す図である。
【図１４】本発明における警告表示例を示す図である。
【図１５】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素内ｐａｒａｍ要素の評価方法を示す図である。
【図１６】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（１）の図である。
【図１７】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（２）の図である。
【図１８】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（３）の図である。
【図１９】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（４）の図である。
【図２０】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（５）の図である。
【図２１】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（６）の図である。
【図２２】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（７）の図である。
【図２３】本発明におけるメッセージ「Ｂ００１Ｍ０１」ｍｓｇＤｅｓｃｒｉｐｔｉｏｎ要素の評価（８）の図である。
【図２４】本発明におけるｓｔａｎｄａｒｄｓ．ｘｍｌの内容変更を示す図である。
【図２５】図５の行０６３〜行０７０のｖｉｅｗ Ｄｅｆｉｎｉｔｉｏｎ要素内容変更を示す図である。
【図２６】図５の行０９１の直後のｖｉｅｗ Ｄｅｆｉｎｉｔｉｏｎ要素追加を示す図である。
【図２７】図５の行０９１の直後のｖｉｅｗ Ｄｅｆｉｎｉｔｉｏｎ要素追加を示す図である。
【図２８】本発明における評価ルール評価ファイル共有例を示す図である。
【図２９】図２の要素を一覧表示した図である。
【図３０】評価ルール「Ｂ００１」のデータソース一覧を示す図である。
【図３１】品質データベースの構成例を示す図である。
【図３２】数式一覧を示す図である。
【図３３】メッセージ「Ｂ００１Ｍ０１」で用いるデータ及び数式を示す図である。
【図３４】品質データベースの内容例（１）を示す図である。
【図３５】品質データベースの内容例（２）を示す図である。
【図３６】品質データベース変更例を示す図である。
【符号の説明】
１…評価ルールファイル保存部、２…情報共有機能、
３…評価ルールファイル、４…評価ルール読み込み部、
５…評価ルール演算部、６…品質データベース、
７…評価ルール評価結果提示部、８…実装システム、
００１〜０２２…要素番号。
Claims (2)
- コンピュータシステム上に組み込まれた品質管理データを保持するためのデータベースシステムと、品質管理・品質評価ルールを記載した構造化文書を保持するファイルによるソフトウェア品質管理方法であって、
利用する組織等に情報を共有させる手段において、上記品質管理・品質評価ルールを記載した構造化文書を保持するファイルにアクセスして、該構造化文書の内容を読み取る第１のステップと、
評価ルール読込み手段において、上記情報共有手段にアクセスして、該情報共有手段が有する構造化文書の内容を読み取り、上記構造化文書を構文的に解釈し、評価ルール演算手段へのインタフェースを提供する第２のステップと、
上記評価ルール演算手段において、上記第２のステップで読み込んだ品質管理・品質評価ルールを記載した構造化文書に基づき、上記品質管理データを保持したデータベースシステムにアクセスし、参照すべき品質管理データを読み取り、読み取った該品質管理データを参照して、演算回路で演算を行うことにより品質評価を実施する第３のステップと、
評価ルール評価結果提示手段において、上記第２のステップで構文的に解釈された構造化文書を受け取ると、上記評価ルール演算手段に対して演算する時点，演算の種類，および演算結果の方法を指示する通知を出し、演算結果として、表示部による警告メッセージの表示、書込み制御部によるログファイルへの書き込み、あるいは書込み制御部による結果レポートの作成のいずれか１つを実行する第４のステップと
を有することを特徴とするソフトウェア品質管理・評価方法。 - コンピュータが読み取り可能なプログラム及びデータを記録する記録媒体であって、
該コンピュータに、品質管理・品質評価ルールを記載した構造化文書を保持するファイルにアクセスして、該構造化文書の内容を読み取る第１の手順、情報共有手段にアクセスして、該情報共有手段が有する構造化文書の内容を読み取り、上記構造化文書を構文的に解釈し、評価ルール演算手段へのインタフェースを提供する第２の手順、上記第２の手順で読み込んだ品質管理・品質評価ルールを記載した構造化文書に基づき、品質管理データを保持したデータベースシステムにアクセスし、参照すべき品質管理データを参照して、演算回路で演算を行うことにより品質評価を実施する第３の手順、評価ルール演算手段に対して演算する時点，演算の種類，および演算結果の方法を指示する通知を出し、演算結果として、表示部による警告メッセージの表示、書込み制御部によるログファイルへの書き込み、あるいは書込み制御部による結果レポートの作成のいずれか１つを実行する第４の手順を、それぞれ実行させるためのプログラム及びデータを記録したことを特徴とする記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000087426A JP3703076B2 (ja) | 2000-03-27 | 2000-03-27 | 構造化文書により定義された品質管理及び品質評価ルールによるソフトウェア品質管理・評価方法、ならびにそのプログラムを記録した記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000087426A JP3703076B2 (ja) | 2000-03-27 | 2000-03-27 | 構造化文書により定義された品質管理及び品質評価ルールによるソフトウェア品質管理・評価方法、ならびにそのプログラムを記録した記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001273129A JP2001273129A (ja) | 2001-10-05 |
| JP3703076B2 true JP3703076B2 (ja) | 2005-10-05 |
Family
ID=18603439
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000087426A Expired - Fee Related JP3703076B2 (ja) | 2000-03-27 | 2000-03-27 | 構造化文書により定義された品質管理及び品質評価ルールによるソフトウェア品質管理・評価方法、ならびにそのプログラムを記録した記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3703076B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003345918A (ja) * | 2002-05-27 | 2003-12-05 | Nec Corp | ソフトウェア品質管理システムおよびソフトウェア品質管理方法 |
| US6938026B2 (en) * | 2003-07-21 | 2005-08-30 | Bio-Rad Laboratories, Inc. | System and method for implementing quality control rules formulated in accordance with a quality control rule grammar |
| JP5380024B2 (ja) * | 2008-09-19 | 2014-01-08 | 株式会社東芝 | テストデータ生成装置、及びテストデータ生成方法 |
| CN102012822B (zh) * | 2010-12-28 | 2014-10-15 | 西北大学 | 对生产线中的bpm构件可信评估的系统及方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06119205A (ja) * | 1992-10-01 | 1994-04-28 | Toshiba Corp | ソフトウェアの品質分析装置およびその高品質化支援装置 |
| JPH09265393A (ja) * | 1996-03-28 | 1997-10-07 | Hitachi Ltd | プログラム品質評価方法 |
| JPH11296541A (ja) * | 1998-04-14 | 1999-10-29 | Fujitsu Ltd | 構造化データ管理システム及び構造化データ管理プログラムを記録したコンピュータ読み取り可能な記録媒体 |
| JP3545256B2 (ja) * | 1998-04-17 | 2004-07-21 | 松下電器産業株式会社 | 送信装置及び受信装置 |
-
2000
- 2000-03-27 JP JP2000087426A patent/JP3703076B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001273129A (ja) | 2001-10-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6279006B1 (en) | Structured data management system and computer-readable recording medium storing structured data management program | |
| US9785907B2 (en) | Supplemental system for business intelligence systems | |
| US7418453B2 (en) | Updating a data warehouse schema based on changes in an observation model | |
| US8825695B2 (en) | Mapping dataset elements | |
| US7600182B2 (en) | Electronic data capture and verification | |
| KR101046831B1 (ko) | 문서 내 엘리먼트를 데이터베이스 내 대응 데이터에 링크하는 방법 및 컴퓨터 판독가능 기록 매체 | |
| US7475289B2 (en) | Test manager | |
| US7895238B2 (en) | Generating an information catalog for a business model | |
| US20100114628A1 (en) | Validating Compliance in Enterprise Operations Based on Provenance Data | |
| US7873680B2 (en) | Hierarchical inherited XML DOM | |
| JP2020522779A (ja) | ルールを編集、シミュレート、バージョン制御、及びビジネスプロセス管理する統合システム | |
| Hessellund et al. | Guided development with multiple domain-specific languages | |
| JP5207007B2 (ja) | モデル検証システム、モデル検証方法および記録媒体 | |
| US20070276825A1 (en) | Query reuse through recommend parameter flexibility | |
| US11947567B2 (en) | System and method for computing and managing datasets using hierarchical analytics | |
| US20090083617A1 (en) | Input form design device and input form design method | |
| US20240070580A1 (en) | Systems and Methods for Decommissioning Business Intelligence Artifacts | |
| US20060282441A1 (en) | Definition and management of procedures in a distributed environment | |
| US20020180789A1 (en) | Framework for developing web-based and email-based collaborative programs | |
| JP3703076B2 (ja) | 構造化文書により定義された品質管理及び品質評価ルールによるソフトウェア品質管理・評価方法、ならびにそのプログラムを記録した記録媒体 | |
| US20040267704A1 (en) | System and method to retrieve and analyze data | |
| US20080256092A1 (en) | Data Processing Device and Data Processing Method | |
| Yang | Improving Performance and Correctness of Database-Backed Web Applications | |
| Sonnleitner et al. | Persistence of workflow control data in temporal databases | |
| CN118170358A (zh) | 应用程序的生成方法、装置、电子设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050225 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050315 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050511 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050701 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050714 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090729 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100729 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100729 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110729 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110729 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120729 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130729 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130729 Year of fee payment: 8 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130729 Year of fee payment: 8 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140729 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |