ビジネスアプリ開発者のための機能規模測定手法COSMIC法入門（第3回）

今回の記事では、COSMIC 法の測定上の一般的な注意点と機能規模の集計方法について説明します。今回の記事までの内容をマスターすれば、COSMIC 法で簡単なビジネスアプリケーションの規模測定ができるようになるでしょう。

測定上の一般的な注意点

入出力するデータグループ

筆者が COSMIC 法を学び始めた段階で悩んだのは、注目オブジェクトとデータグループの関係です。より具体的には複数の注目オブジェクトを結合して表示するという場合をどのように考えたらよいかという点です。例えば、要求から「従業員」と「所属」という 2 つの注目オブジェクトが存在することが分かり、画面上で「所属」と「従業員名」を 1 行にまとめて表示することが求められたような場合です。画面上のデータグループは、「従業員」と「所属」の 2 つと考えればよいのでしょうか？

このような場合は、画面上のデータのまとまりに基づいてデータグループは設定すればよいのです。例に即して言えば、「所属」と「従業員名」を属性に持つ「従業員データ」というデータグループがエクジット (E) されると考えるのです。このようにエクジットされるデータグループは必ずしも注目オブジェクトと 1 対 1 に対応する訳ではありませんので、その点に注意が必要です。

注目オブジェクトのキーと関連

COSMIC 法では、注目オブジェクトの各インスタンスを見分けるための識別子を各注目オブジェクトが持っていると仮定します。データベース用語で言えば、各注目オブジェクトは主キーを持っているということになります。さらに、注目オブジェクト間の関連で多重度が 1 対 多 のものは 多側の多重度の注目オブジェクトが外部キーを持っていると考えます。ここで、注意が必要なのは多対多の多重度の関連です。UML のクラス図では 1 本の関連の線に多対多の多重度を付け加えれば済みますが、COSMIC 法ではそのような関連を明示的に関連クラスとして表現します。

例えば、「学生」クラスと「科目」クラスの間には「履修する」という多対多の関連を考えることができます。この関連を COSMIC 法では「学生」注目オブジェクトと「科目」注目オブジェクトの間に挟まった「履修関連」という注目オブジェクトとしてモデル化します。その結果、「学生」から「科目」を辿る際には「履修関連」に対するリード (R) が発生することになります。

関連を辿る際にデータベースの SQL の JOIN を使って、注目オブジェクトの結合を行えるのではないかと考える読者の方もいらっしゃるかもしれません。しかし、COSMIC 法の測定では JOIN のようなリレーショナルデータベース固有のコマンドは使えないと考えてください。つまり、関連クラスに類するものを含めて注目オブジェクトを 1 つずつリード (R)　し、外部キーと主キーの対応で関連を辿るという形でデータ移動モデルを作るのです。そのように関連を辿る際に、リード (R) を数えるのは注目オブジェクトのクラス(種類）単位であり、インスタンス単位ではないということに気をつける必要があります。別の言い方をすれば、辿る関連で結ばれた注目オブジェクトのインスタンスがいくつあろうと、各注目オブジェクトを 1 回だけリード (R) すればよいということです。

入力データの妥当性確認（バリデーション）やドロップダウンリスト

すでに前回の記事で触れましたが、画面からマスターデータに対応するデータを入力する際には以下のように複数の方法を用いることができます。

1. 郵便番号などのようにマスターデータに対応する文字列や数字を直接入力する
2. 都道府県名のドロップダウンリストのように、マスターデータの行（タプル）の集合から要素を選択する

1. のような場合、ふつうのソフトウェアではデータが入力された際に入力されたデータと一致するデータが注目オブジェクト（エンティティ）の中に存在するかをまずバリデーション（妥当性確認）します。そのために、注目オブジェクトのリード (R) が発生します。従って、1. の機能プロセスではデータが入力された際にエントリー (E) 1 つとリード (R) 1 つが実行されることになります。

2. の場合は、データ入力画面表示を行う際にドロップダウンリストの項目となるマスターデータに対応する注目オブジェクトのリードが発生します。すると、2. の機能プロセスには画面表示のきっかけを与えるエントリー (E) 1 つ、注目オブジェクトのリード (R) 1 つ、ドロップダウンリストを表示するエクジット (X) 1 つが存在することになります。

当然のことながら、ドロップダウンリストの項目がプログラムコード中に定義(ハードコード）されている場合には注目オブジェクトのリードは発生しません。

エラーメッセージや確認メッセージ

前節で述べたような入力データのバリデーションを行う場合、データが入力された際に入力されたデータと一致するデータが注目オブジェクト（エンティティ）の中に存在しない場合には、エラーとなり、エラーメッセージをユーザインタフェースに表示しなければならないでしょう。

COSMIC 法では、このようなエラーメッセージの表示を機能プロセス毎に最大 1 つまでエクジット（X）としてカウントします。つまり、 1 つの機能プロセスで複数のエラーメッセージが発生しうる場合にも、それらは出力メッセージという 1 つの種類のデータグループだと考えてエクジット (X) 1 つとしてカウントします。確認や警告のメッセージが表示される場合も、それらはエラーと同じ出力メッセージのデータグループだと考え、機能プロセス単位に 1 つのエクジット (X) とカウントします。

エラーメッセージをカウントする例として、前出の郵便番号のようにマスターデータに対応する文字列や数字を直接入力する機能プロセスを考えてみましょう。エラーメッセージの表示を考慮すると、この機能プロセスはエントリー (E) 1 つ、リード (R) 1 つ、エクジット (X) 1 つの合計 3 CFP の規模ということになります。

なお、COSMIC 法ではエラーメッセージとしてカウントするのはアプリケーションエラーに起因するものだけです。従って、メモリー不足の時に発生するような例外の出力はエラーメッセージとしてカウントしませんのでご注意ください。

コントロールコマンド

ソフトウェアによっては、[ファイル]、[編集]などメニュー上に利用できる機能の一覧が表示され、それらの機能から利用したいものを選択すると、選択した機能を使うためのダイアログ等の画面が表示されるというような形になっているものがあります。あるいは、１つの画面上に機能を選択するボタンが配置しており、それらの１つを押下すると選択した機能を利用するための画面が表示される場合もあるでしょう。

これらの場合に、選択した機能を利用する画面の表示に際してリード (R)、ライト (W)、エクジット (X)などのデータ移動が発生しないこともあります。このようなデータ移動を伴わない画面遷移を「コントロールコマンド」と呼びます。

「コントロールコマンド」は、機能の選択というきっかけに続く、リード(R)、ライト(W)、エクジット(X)が実行されませんので機能プロセスになりません。そのため、「コントロールコマンド」は機能規模のカウントには含みません。

機能規模の集計

正味機能規模

COSMIC法では、ソフトウェアを構成する、すべての利用者機能要件に対する機能規模の総和を求めることでソフトウェア全体の機能規模を求めることができます。この機能規模を本記事では「正味機能規模」と呼びます。各利用者機能要件の機能規模は、その利用者機能要件を構成する機能プロセスの規模の総和として求まります。

以下に示すような簡単な集計表をスプレッドシートで作れば、正味機能規模の値を簡単に算出できます。この集計表では、行に機能プロセス、列にデータグループを設定します。さらに、特定の機能プロセスで発生するデータ移動の種類を、データ移動の対象となるデータグループ（列）と機能プロセス（行）が交差するセルに入力します。

例えば、郵便番号のようにマスターデータに対応する文字列や数字を直接入力する機能プロセスのデータ移動はエントリー (E) 1 つ、リード (R) 1 つ、エクジット (X) 1 つですが、これらを以下の表のように入力します。

機能プロセス数が多くなると、登場するデータグループが増えるために表の横幅が広くなり、表への入力がしづらくなったり、見づらくなったりします。そのため、筆者は利用者機能要件単位で別シートに記入しています。

そのように、利用者機能要件単位でシートを作成した場合には、集計表の一番右端の列では機能プロセス毎のデータ移動の合計数を算出し、一番最後の行の一番右端の列では機能プロセス毎の規模を合計することで、利用者機能要件の機能規模を算出するようにスプレッドシートで演算式を定義します。

比較のために IFPUG 法で機能規模を求める際のステップを紹介しましょう。IFPUG 法で機能規模を求める際のステップは、以下の 4 ステップになります。

1. データファクションを測定する
2. トランザクションファクションを測定する
3. データファクションとトランザクションファクションを合計して未調整ファクションポイント (UFP: Unadjusted Function Point) を求める
4. 未調整ファクションポイントに調整係数を掛けて、ファンクションポイント (FP: Function Point) を求める

1.で行うことをより詳しく説明すれば、以下のようになります。

1. 計測対象のアプリケーションがアクセスするファイルを内部論理ファイル (LIF) と外部インタフェースファイル (EIF) に分類する
2. 各ファイルのデータエレメントタイプ (DET) とレコードエレメントタイプ (RET) を求める
3. DET と RET の値の組み合わせと複雑度の対応表を用いて各ファイルの複雑度を求める
4. ファイルの種類と複雑度の組み合わせと FP 値の対応表を用いて各ファイルの FP 値を求める

残る　2、4　についての説明は省略しますが、COSMIC 法の機能規模の算出方法が IFPUG 法の機能規模の算出に比べて簡単だということを少し理解して頂けたのではないかと思います。

変更機能規模

COSMIC 法では、ソフトウェアを変更した場合にその変更の規模を測定する方法も提供されています。本記事では、この変更の規模を「変更規模」と呼びます。

機能プロセスの変更規模は、以下の 3 種類のデータ移動の数の総和で算出されます。

• 追加されたデータ移動
• 削除されたデータ移動
• 変更されたデータ移動

ここで、「追加されたデータ移動」と「削除されたデータ移動」について説明する必要はないでしょうが、「変更されたデータ移動」がなにを意味しているかピンとこないかもしれません。

「変更されたデータ移動」には、以下の 2 つの場合があります。

1. データ移動をするデータグループの属性や種類が変更される
2. データ移動に関与するデータ処理が変更される

これらの 2 つの場合に該当するデータ移動が「変更されたデータ移動」になります。ここで注意すべき点は、データグループの属性が変わった場合にその属性を使うデータ処理に関わるデータ移動だけが「変更されたデータ移動」になるという点です。

例えば、住所録ソフトウェアに対して「宛先」という注目オブジェクトを考えることができますが、その宛先の属性として「勤務先」という属性が追加されたとします。その場合、「宛先」の名字と名前だけを一覧表示する画面のデータ処理（＝表示）では「勤務先」という属性は使いませんので、「宛先」を表示するエクジット (X) は「変更されたデータ移動」としてカウントしません。その一方で、「宛先」の全属性を入力したり、編集する画面では「勤務先」という属性が表示されるので、「宛先」を表示するエクジット (X) は「変更されたデータ移動」としてカウントします。

ソフトウェア全体の変更機能規模はすべての利用者機能要件の変更規模の総和として求めることができます。つまり、ソフトウェア全体の変更機能規模は以下のような式で求めることができます。

新規開発の場合は、正味機能規模と変更機能規模の値は同じになり、それらは開発対象のソフトウェアの開発規模と開発されたソフトウェアの規模を表します。それに対して、改修開発の場合は正味機能規模と変更機能規模の値は通常同じになりません。それは、改修開発の正味機能規模は改修後のソフトウェアの規模を表し、変更機能規模は改修開発の規模を表すからです。

終わりに

今回の記事で、COSMIC 法を使った機能規模測定の基本は網羅しました。この基本を使えば、J2EE などのWeb 系のシンクライアントのソフトウェアの機能規模を測定できるでしょう。

次回の記事では、測定上で悩む点を筆者がどのように扱っているかという藤井流測定プラクティスと COSMIC 法のデータ移動モデルの UML での表現を紹介する予定です。

参考文献

• [1] COSMIC 法の公式サイト, https://cosmic-sizing.org/, (参照 2016-02-29)
• [2] JFPUG の COSMIC 法のページ, https://www.jfpug.gr.jp/cosmic/top.htm, (参照 2010-08-05)
• [3] COSMIC-FFP による業務アプリケーションソフトウェア規模測定の指針, https://www.jfpug.gr.jp/cosmic/BAGv1_0j.pdf, (参照 2010-08-05)

参考文献[2][3]について：
本記事を掲載した時には日本語訳のドキュメントがリンク先で公開されていましたが、2016年2月現在はリンク先に存在しないようです。日本語訳としては、代わりにJIS規格「JISX0143 ソフトウェア－ＣＯＳＭＩＣ機能規模測定手法」をご覧ください。JIS規格は、日本工業標準調査会JISCの公式サイトhttps://www.jisc.go.jp/のJIS検索ページにてJIS番号「X0143」で検索すると閲覧できます。（2016年2月追記）