品質指標はシステム規模をベースに決定されます。
品質を品質指標により評価しようとする場合、品質指標を算出するベースとなるシステム規模を求めなければなりません。
品質指標＝システム規模×係数
（係数は、品質指標ごとに、プロジェクトの特性によって決まります）
システム規模を算出する方法としては、主に次の２つが考えられています。
・プログラムのソースラインで集計する方法
・システムが実現する機能をカウントする方法
ＳＬＯＣ
ＳＬＯＣは「Source Lines Of Code」の略語で、プログラムソースのライン数を表す用語です。
プログラムソース内には、プログラムの名称や作者が記述されている文や、後のプログラム修正に役立たせるためのコメント文など、いろいろな要素が含まれていますが、システムの規模を計測する上で必要となるのは、ロジックが記述されている部分です。
そこで、カウント対象とするソースラインは、命令語が含まれる文としています。
ちなみに、プログラムソースのライン数を単純にカウントしたものを「物理ＬＯＣ」とし、システム規模計測用に補正したライン数を「論理ＬＯＣ」と呼ぶこともあります。
ＳＬＯＣの課題
ところで、ＳＬＯＣには次に挙げる課題があります。
・プログラムをコーディングした後でないとカウントができず、実装モレやロジックミスがあった場合には誤差が生じてしまう。
・プログラムの可読性や保守性を高めるために共通ロジックを用意するとライン数が減少してしまいますが、プログラムの機能としては共通ロジック部分も含むものであり、その点を考慮してライン数をカウントすることは困難。
・同じ機能を実装するにあたり、いくつかの処理手順が考えられる場合、ロジックによりライン数が変動してしまう。
・同じ処理内容であっても、プログラミング言語によりソースライン数が大きく変わってしまう可能性あり。画面系プログラムとデータベースやファームウェアを制御するプログラムで、それぞれに最適なプログラミング言語を採用した場合は換算する必要がある。
ＳＬＯＣにてシステムの規模を計測することには問題があるとして、実装する機能を難易度によりポイント化して、それを集計するという方法が考え出されています。
ＦＰ法
システム規模を実装する機能に基づいて数値化する方法の代表的なものとして、ＦＰ(ファンクションポイント)法があります。
1979年にＩＢＭのアレン・J・アルブレヒト(A.J.Albrecht)が考案した方法で、1986年にアメリカで設立されたＩＦＰＵＧ(International Function Point Users Group)がマニュアルを策定し、国際的な普及と定着を進めており、ＩＳＯ/ＩＥＣにて国際標準化に取り組んでいます。
日本でも、1994年にＪＦＰＵＧ(Japan Function Point Users Group)が設立されており、また主要なＩＳＯ/ＩＥＣ規格がＪＩＳ(日本工業規格)も制定されています。
ＦＰ法計算
ファンクションポイント法では、機能の処理内容と機能を実現するデータを計測して、システム規模を算出します。
【トランザクションファンクション】
処理内容を、次の３種に分解します。
| ＥＩ(External Input)：外部入力 |
| 外部からデータを入力する機能 画面からのデータ入力や外部ファイルの取込などのデータ更新など |
| ＥＱ(External inQuiry)：外部照会 |
| データを参照し表示する機能 検索条件を指定して画面や帳票として出力表示する |
| ＥＯ(External Output)：外部出力 |
| 外部へデータを出力する機能 データを加工し画面や帳票、ファイルとして出力する |
それぞれの機能に対し、処理の複雑度を見極めて「難・中・軽」の３段階に当てはめ、割り当てられているポイントを取得します。
【データファンクション】
データを、次の２種に分解します。
| ＩＬＦ(Internal Logical File)：内部論理ファイル |
| システムで管理される機能を実現するためのデータ |
| ＥＩＦ(External Interface File)：外部インターフェースファイル |
| システムの外部に存在し、参照されるデータ |
各データを、項目数に応じて大・中・小の３段階に当てはめ、割り当てられているポイントを取得します。
計測対象のトランザクションファンクションとデータファンクションを合計したＦＰ値がシステム規模となります。
開発されるシステムに特殊な要素が含まれる時には、事前に取り決めておいた調整係数を加味してＦＰ値を算出する場合もあります。
ファンクションポイント法であれば、システム開発で対象となる機能が定義された時点でシステム規模を明らかにすることができます。しかも、プログラミング言語による違いやプログラムロジックによる変動を考慮する必要はありません。
試験密度(試験項目数)などの品質指標が早い段階でわかることになりますので、試験計画が立案しやすく、試験設計の品質を高めることにもつながります。
ＵＣＰ法
ＦＰ法と同じように、システム規模をユースケースから求められるポイント(ユースケースポイント＝Use Case Point)で計測する方法です。
ユースケースというのは、ＵＭＬ(統一モデリング言語)の表示法の一つであるユースケース図で表されるシステムの機能的要求を示すものです。それぞれのユースケース図は、システムに要求されるタスクを成し遂げる一連の処理の流れを表現したもので、その総和がシステムの全体像になります。
ＵＣＰ法計算
ユースケース図には、作業に主体となるアクターと、振舞いを表現するユースケースが記述されていますので、アクターとユースケースを抽出します。
抽出したアクターをインターフェースとして、複雑度を「単純・平均・複雑」の３段階で採点します。
抽出したユースケースも、同様に複雑度を「単純・平均・複雑」の３段階で採点します。
採点をしたインターフェースとユースケースの合計値をＵＵＣＰ(未補正ユースケースポイント)とします。
次に実現するシステムにおける技術的な複雑度を１３の技術要因から、また環境的な複雑度を８の環境要因から、それぞれ評価し係数を算出します。
最後にＵＵＣＰに対して技術要因係数と環境要因係数を反映させてＵＣＰを決定します。
システム規模算出法
| ＳＬＯＣ |
| コーディング(実装)後でないと計測できない：設計時は過去の実績値より推測する １行単位に正確に計測できるが、開発言語や実装ロジックにより変動 |
| ＦＰ法 |
| 機能とデータを複雑度で分類し計測：見積時、設計時に計測可 ファンクションポイントとして定量化されるため、変動要素は少ない |
| ＵＣＰ法 |
| アクターとユースケースを複雑度で分類し、技術要因と環境要因を加える ユースケースとして定量化されるため、変動要素は少ない |
ＳＬＯＣは制御系システムを含め全てのプログラムを製作するシステムに対応可ですが、ＦＰ法とＵＣＰ法は業務系システムには適合するものの制御系システムには対応ができなせん。
しかし、ＦＰ法とＵＰＣ法は、システムに実装したい機能が判明した時点からシステム規模の算出ができる上、変動要素も少ないので、システム規模算出には適していると考えられます。
ただし、ＵＣＰ法を採用するにはＵＭＬのスキルが必要となります。
