ユースケースポイント計測支援ツールの実装とその適用
松 川 文 一†楠 本 真 二†井 上 克 郎†英繁 雄 †† 前 川 祐 介††
ソフトウェア開発における開発規模および工数を, 開発プロセスの早期段階である要求分析段階で見積るための手法が求められてきている. そのための一手法として, 開発初期に作成されるユースケー
スモデルを用いて見積りを行うユースケースポイント法が提案, 研究されている. しかし, この手法を実際に適用して見積りを行うには, ある程度の熟練度が必要とされている. 本研究では, 経験の浅い者でも見積りが可能となることを目的として, ユースケースポイントの計測を行うツールを試作した.
また試作したツールを, 実際に作成されたユースケースモデルへ適用し, ツールの評価を行った. 評価の結果, 本ツールの実用性を見出せる結果となった.

Implementation and Application of the Use Case Point Measurement Tool
Fumikazu Matsukawa† , Shinji Kusumoto† , Katsuro Inoue† ,Shigeo Hanabusa†† and Yusuke Maegawa††
Use case point (UCP) method had been proposed to estimate development effort based on
use case models which are developed at early phase of software project. In order to effectively introduce UCP method to software project, it is important to develop a supporting
tool to count UCP. This paper describes the idea to automatically calculate the UCP fromuse case model. We have also applied this tool to actual use case models and evaluated theapplicability of it.

イント法は, ファンクションポイント法をベースとし, 近

1. は じ め に年増えつつあるオブジェクト指向開発において, ライフ

ソフトウェア開発において通常, 開発規模や開発工数

サイクルの早期である要求分析の段階で作成されるユーを予測するのに, まずソフトウェアの規模を見積り, これ

スケースモデルをもとに, 開発規模および開発工数を見に基づいて開発工数と開発期間を予測する手法がとられ積るための手法である. この手法の最大のメリットは, 開ている. 近年では, ソフトウェアの機能要件だけを抽出

発プロセスの設計段階よりもさらに上流である要求分析

し, 規模を定量的に計測するファンクションポイント法

段階での工数見積が可能となることにある.

が世界的に普及しつつある. ファンクションポイント法

ユースケースポイント法は, 具体的にはユースケース

1)

は, 1979 年に A.J. Albrecht によって提案された .

モデルに記述されるアクタおよびユースケースに対して

しかしながら, ファンクションポイント法は, 計測を行

重み付けを行なうが, この作業にはある程度の熟練度をう上で, データ項目やトランザクションが明確になって必要とし, それゆえ同一プロダクトに対する計測でも, 計いる必要があり, 効果的な結果を得るには, 開発プロセス

測者の経験度によって結果に誤差が生じる可能性がある.

を設計段階まで進めておく必要がある. 近年の受注競争

本研究では, 見積り経験の浅い者でも見積りが可能との激化や, 設計に多くの時間を必要とするような複雑ななることを目的として, ユースケースモデルを入力とし,ソフトウェアの増加により, 開発プロセスのさらに早期

ユースケースポイント法に基づいて工数の見積りを行うの段階 (上流工程) で見積りを行なうための手法が求めらためのツールを試作し, 実際のプロジェクトに適用する

れてきている.

ことで, ツールの評価を行った. ユースケースポイント

この流れを受け, 1993 年, G. Karner により, ユースの自動計測にあたり, アクタとユースケースに対する重ケースポイント法が提唱されている5) . ユースケースポ

み付けの部分にいくつかのルールを設定し, モデル内の情報から計測を行っている. また, ユースケースポイン
ト法における重み付けに必要な情報が欠けているユース† 大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology,
Osaka University†† 株式会社 日立システムアンドサービス
Hitachi Systems & Services, Ltd.

ケースモデルに対しても, 過去の情報を利用することで計測を行うことを可能とした. そして実際にユースケー
スモデルが作成されたいくつかのプロジェクトを用いて,-1-

ツールによる重み付けと, 経験者による手動での重み付

一連の宣言文を指す.

けの結果との比較を行うことでツールの精度を評価した.

本研究では, 区別のため, イベントフロー内の 1 つのパ

以降, 2 で本研究が対象とするユースケースモデルにスを「イベント」と呼ぶことにする.

ついて説明を行い, 3 節では, ユースケースポイント法に

3. ユースケースポイント法

ついて説明する. 次に 4 節でツール化へ向けて設定したルールについて述べ, 5 節で, これらのルールを実装した

3.1 概

要

見積支援ツール U-EST に関して説明を行う. 次に 6 節

ユースケースポイント法は, オブジェクト指向開発ので, いくつかのプロジェクトのユースケースモデルを対早期段階における工数及びコスト見積手法が要求される象にして適用実験を行ったその結果についての分析と考中で, 1993 年に G. Karner によって提案された工数見察を行う. 最後に 7 節で, 本研究のまとめと今後の課題

積手法である5) . この手法は, A.J. Albrecht によるファについて述べる.

ンクションポイント法をベースとし, 開発の要求分析段
階で作成されるユースケースモデルに基づいて見積りを

2. ユースケースモデル

行う. 具体的には, ユースケースモデルに記述されるア

2.1 ユースケースモデル

クタ, ユースケースを重み付けしてその数をカウントし,本研究において対象とするユースケースモデルは, ユー

計測対象プロジェクトの技術的な要因や, 開発環境の要スケース図とユースケース記述の 2 つの要素で構成され因をもとに調整を行い, 規模, そして工数を見積る.

ている. 以下, それぞれについて説明を行う.

2.1.1 ユースケース図

3.2 計 測 手 順

ユースケース図は, ユースケースの概念を UML で視3.2.1 アクタの重み付け

覚化して表現したものである. アクタを人間の形のアイ

まず, ユースケースモデルに記述されているアクタにコンで示し, ユースケースを楕円形のアイコンで表現す

ついて, それがどのようなアクタであるかで分類を行う.

る. アクタとユースケースとの関連は実線で表す.

表 1 に詳細を示す. それぞれのタイプには重みが設定さ

2.1.2 ユースケース記述れており, 各タイプのアクタの個数に重み係数を掛け, 合ユースケース記述は, ユースケース図に記述されたユー計したものを, アクタの重み (AW : Actor W eight) とスケースそれぞれについて, 主体となるアクタの情報や,する.

アクタとシステムとのやり取りなどといった, そのユースケースの機能を実現するために必要な詳細情報を記述したものである. ユースケース記述は確立したフォーマッ
トはなく, 自由に記述が可能となっている.

タイプ

表1
説明

単純

定義済み API を備えた別システム

平均的プロトコル駆動のインタフェース (別システム), テキストベースのインタフェー
ス (人間)

複雑

GUI を介する人間

ひとつの例として, 「注文を出す」というユースケー
スに関し, ユースケース図とユースケース記述をまとめたものを図 1 に示す.

アクタのタイプと重み係数
重み係数

1
2

3

単純なアクタというのは, 定義済みの API(Application

Programing Interface) を備えた別システムを指す. 平
均的なアクタは, TCP/IP などのプロトコルを介して計測対象システムと相互作用する別システム, もしくはテキストベースのインタフェース (ASCII 端末といったもの) を介して相互作用する人間を指す. 複雑なアクタは,GUI を介して相互作用する人間がこれに分類される.
3.2.2 ユースケースの重み付け
次に, ユースケースについても同様に複雑さの分類を
図1「注文を出す」ユースケース

行う. ユースケースの場合は, イベントフロー内のトランザクションの数に基づいてその複雑さを決定する. このこのユースケース記述における, 「事前条件」「事後条

場合のトランザクションは, 原始的な一群のアクティビ

件」は, ユースケースの開始時, 及び終了時にシステム

ティと定義され, これはすべて完全に実行されるかあるがどのような状態でなければならないかを表すものであいはまったく実行されないかのどちらか一方となる. まる. この条件は必ず成り立っていなければならない. また, include するユースケースや拡張ユースケースについた, 「イベントフロー」は, ユースケースの手順を並べたては, 計測の対象としない. 分類について表 2 に示す.

-2-

タイプ

表 2 ユースケースのタイプと重み係数
説明
重み係数

単純

トランザクション数が 3 個以下

平均的

トランザクション数が 4 個から 7 個

複雑

トランザクション数が 8 個以上

Environmental F actor) と呼ばれる. 環境要因については, 表 4 に示す 8 つの要因があり, 各要因に重み係

5
10
15

数が設定されている. 計測者は, 各要因について 0 から

5 までの 6 段階で評価を行う.

ユースケースについても, 各タイプの個数に重み係数

要因番号を掛け, すべて合計する. これをユースケースの重み算出されたアクタの重みと, ユースケースの重みを合計すれば, 未調整ユースケースポイント (U U CP :U nadjusted U se Case P oint) が得られる.
U U CP = AW + U W(1)

このようにして算出された未調整ユースケースポイン
トに対し, 計測対象のシステムの複雑さや, 開発に関わる

重み係数

F1

採用する開発プロセスに精通して
いる

1.5

F2
F3

その分野での開発経験

0.5
1

F4

主任アナリスト (リーダー) の能
力

0.5

F5

プロジェクトに対するモチベーショ
ン

1

F6
F7
F8

要求仕様の安定性

2-1-1(U W : U se Case W eight) とする.
3.2.3 未調整ユースケースポイントの算出

表 4 環境要因とその重み係数
要因の説明採用する開発方法論についての経験

兼任スタッフの存在
プログラミング言語の難しさ

人々の経験レベルといった要因を考慮した調整を行う.

3.2.4 技術要因の評価

要因ごとの評価点と, 各要因に設定された重み係数を

まず, 対象のシステムの技術的な要因を考慮した調整

掛け, すべての数値を合計したものを EF actor とする.

係数を算出する. これは技術要因 (T CF : T echnicalEF actor =Complexity F actor) と呼ばれる. システムの技術要因

P{(各要因の評価点)×(重み係数)}

最後に, (3) 式を用いて, 環境要因の調整係数を算出する.

については, 表 3 に示す 13 の項目があり, 各要因には重EF = 1.4 + (−0.03 × EF actor)

み係数が設定されている. 計測者は, これら 13 の項目そ

3.2.6 ユースケースポイントの算出

れぞれについて, 0 から 5 までの 6 段階で評価を行う.

(3)(1) 式で算出した未調整ユースケースポイントに, 各調整係数を掛け合わせることで, ユースケースポイント

表 3 システムの技術要因とその重み係数
要因番号
要因の説明
重み係数

(U CP : U se Case P oint) が得られる.

T1
T2

分散システムである

T3

エンドユーザの効率 (オンライン時) を重視1(4) 式で算出されたユースケースポイントに対して, 工

T4
T5

内部処理が複雑

1
1

Karner は, 1UCP あたり 20 人時という係数を用いるこ

T6
T7
T8
T9
T10
T11
T12

インストールしやすいT13

特別なユーザトレーニングが必要

レスポンスまたはスループットのパフォーマンス目標が設定されている

コードが再利用可能でなければな
らない
使いやすい
移植可能である
変更しやすい並行性が必要特別なセキュリティ機能が必要
第三者に直接アクセスを提供している

2
1

U CP = U U CP × T CF × EF

(4)

3.2.7 工数の見積り数への変換を行う. 変換にあたり, 手法の提案者であるとを提案している5) . しかしながら, 文献9) では, 以下に

0.5
0.5
2
1
1
1
1

( 1 ) 環境要因 F1〜F6 について評価が 2 以下である要因

1( 3 ) (1) と (2) の個数の合計について

示すような, 環境要因の評価について考慮した新しい係数が提案されている.
の個数をカウントする.

( 2 ) F7 と F8 について評価が 4 以上である要因の個数をカウントする.

( a ) 合計が 2 以下：20 人時/1UCP
要因ごとの評価点と, 各要因に設定された重み係数を掛( b ) 合計が 3 または 4：28 人時/1UCPけ, すべての数値を合計したものを T F actor とする.

( c ) 合計が 5 以上：プロジェクトの変更が必要 (失T F actor =P{(各要因の評価点)×(重み係数)}

敗の危険性)

最後に, (2) 式を用いて, 技術要因の調整係数を算出する.

T CF = 0.6 + (0.01 × T F actor)

4. 提 案 手 法(2)

4.1 計測方針概要

3.2.5 環境要因の評価

3 節で述べたユースケースポイント法に基づいて計測

次に, 開発に関わる人々の経験や, 開発環境を考慮した調整係数を算出する.

これは環境要因 (EFを行うツールを作成するにあたって,:-3-• アクタの分類に必要な情報をどのようにして得, そ

まれることも考えられる. そこで, 各タイプのキーワー

して判断するか.

ド群において, キーワード全体数に対するマッチング数• ユースケースのイベントフローからどのようにトラの割合の高いものを採用することにする (図 2 参照). ま

ンザクションを識別, カウントするか.

た, このキーワードについてもユーザが変更・追加可能が考慮すべきポイントとなった. 次項以降, それぞれのとする.

計測方針について詳細を記す.

• ルール A-2:対象となるアクタが関連しているユース

4.2 アクタの計測方針

ケースのイベントを抽出し, タイプごとのキーワー

Karner の定義によれば, アクタのタイプ分類の基準は,

ド群 (ユーザ変更可) に対するマッチングの割合によ

そのアクタが, システムに対してどのようなインタフェー

りタイプを決定する

スで相互作用するかということである. しかし, モデルに記述されるアクタは, インタフェースに関する情報をそれ自身が明示的に持っているわけではない. そこで我々は, 以下に示す 2 つのステップにより, アクタの分類を行うことにした.

4.2.1 Step1: アクタ名による分類
表 1 を見ると, まずアクタが人間であるか, もしくは外部のシステムであるかで, タイプの候補を 2 つに絞ることができる. 外部システムであれば単純, もしくは平均的であり, 人間であれば平均的, もしくは複雑となる. そこで, 第 1 段階として, まず人間か外部システムであるかを判断する.
具体的には, アクタにつけられた名前に注目し, 外部シ
ステムであると判断できるキーワードを設定し, それを

図2

アクタの複雑さ決定イメージ

名前の語尾に持つアクタを外部のシステム, そうでなければ人間とする. キーワードには例として, 「システム」

4.2.3 分類不可能時の処理「サーバ」などが挙げられる. また, 見積を行う組織, 団

上記の方針によりアクタのタイプを決定するが, 関連体等で, ある特定の命名規則を設定する可能性も考慮し,するユースケースのイベントフローに, 用意したキーワー

このキーワードはユーザによる変更・追加も可能とする.

ドに全くマッチしない場合も考えられる. このような場

外部システムに関するキーワードとしたのは, 人間であ合, 支援手法として, 過去の情報を利用することを考える場合の名前には無数のパターンが考えられ, 外部シスる.
具体的には, まずそれまでに計測がなされたプロジェ

テムに関するそれよりも量が膨大であると判断したため

クトの様々な情報をデータベースとして蓄積する. そのである.

• ルール A-1:アクタ名の語尾にキーワード (ユーザ変中のアクタの情報から, 分類が不可能なアクタに類似し更可) を持つアクタは外部システム, それ以外を人たアクタを検索し, 見つかった情報をユーザに提示する.
検索はアクタ名の部分一致による検索を行い, アクタ名,

間とする

4.2.2 Step2: キーワードによる分類

そしてそのアクタに対して過去に決定された複雑さ等のアクタ名による第 1 段階の分類後, 絞られた 2 つの候

情報を表示する. ユーザはそれを受けて, 複雑さを手動で補から 1 つに決定する第 2 段階の分類を行う. ここか設定, 修正を行うことができる. 複数の類似アクタが見らは, どのようなインタフェースを持つかに依存するが,つかった場合は, その複雑さについて多数決で決定する.

先に述べた様にアクタ自身はその情報を陽には持たない.

もし, 過去の情報からも類似したアクタが見つからな

そこで我々は, 対象アクタが相互作用するユースケース

かった場合は, デフォルトの複雑さとして, 外部システムのイベントフローに着目し, インタフェースに関する情であれば「平均的」, 人間であれば「複雑」とする.

• ルール A-3:キーワードにマッチしないアクタにつ報がそこから得られないかと考えた.
具体的には, インタフェース情報に関するようなキー

いては過去の情報を利用する

ワード群を, それぞれのタイプで設定し, アクタが関連す• ルール A-4:ルール A-2 及び A-3 が適用できない

るユースケースのイベントから, 対象アクタが主体とな場合は, デフォルトの複雑さ (外部システム:「平均るイベントを取り出し, そのイベント本体とのマッチン的」, 人間:「複雑」) とする

グをとり, 複雑さを決定する. しかし, 例えばあるイベン

4.2.4 汎化に対する処理

トに, 異なるタイプに設定したキーワードが重複して含アクタ間には汎化関係が存在するが, Karner はこの汎-4-化関係については特に言及してはいない. 我々はこの関認識するかが問題となる. 文献4) では, イベントフロー係が存在する場合, 親アクタの機能を継承した子アクタの効果的な記述方法としていくつかの指針を挙げている.

については, 自身が関連するユースケースを調べるだけ

その中の以下に挙げる 2 つに着目した.

ではなく, 親アクタの関連するユースケースをも調べて• 単純な文法で記述する

マッチングをとるべきであると考える. また, もし親ア

これは, 記述する文章の構造を単純にするというクタに関連が全く存在していない場合は, 機能を継承しことである. つまり, 主語, 修飾語, 目的語, 述語のた子アクタが既に存在するため, カウント対象に入れるセット, 少なくとも主語と述語だけでもきちんと記述するべきであるということ.

べきではないと考える. このことから, 以下のルールを• 意味のあるアクションの集合を含める

追加する.

• ルール A-4:汎化関係のあるアクタについては, 子ア

ユースケースの複雑さを決定するためには, 認識

クタは親アクタの関連するユースケースのイベント

されるべきトランザクションは, ユーザあるいはシステムにとって意味のある内容である必要がある.

フローともマッチングをとる• ルール A-4:親アクタに関連するユースケースが存Jacobson は, 相互作用について代表的な 4 つの部品在しない場合, その親アクタはカウントの対象としとして以下を挙げている4) .

ない– 主アクタがシステムに要求とデータを送る.

4.3 ユースケースの計測方針– システムが要求とデータを確認する.

Karner の定義から, ユースケースの複雑さは, その内– システムがその内部状態を変更する.

部の処理 (トランザクション) の数によって決まる. 故に– システムがアクタに結果を返す.

計測に当たっては, ユースケースモデルにおけるユース

よって, このような処理内容を 1 つのトランザクショ

ケース記述内の, イベントフローに着目する. トランザク

ンとして認識すべきであると考えた.

ションの数をカウントする最も単純な方法としては, イ

以上の事項から, ユースケースのトランザクションについて, 次のルールで計測を行う.

ベントフロー内のイベントの数をカウントすることが考えられる. しかしながら, ユースケース記述は定まった• ルール U-1:ユースケース記述内のイベントフロー

フォーマットが存在せず, 作成者が自由に記述することに対して形態素解析を行い, 主語と述語のセットをができる. それ故, 例えばトランザクションが 2 つ認識

1 つのトランザクション候補とする

できる様な処理が, 1 つのイベントとして記述される可• ルール U-2:抽出された候補のうち, アクタの動作お能性もある. 自由に記述可能なイベントフローから, い

よびシステムのレスポンスであるものを 1 つのトラ

かにしてトランザクションを認識・カウントを行うかがンザクションとする課題であった.

4.3.3 分類不可能時の処理

4.3.1 形態素解析と統語解析

Karner の定義に基づいてユースケースの複雑さを決先に述べたように, 単純にイベントの数をトランザク

定するには, イベントフローが記述されていることが前ションの数として複雑さを判断する方法では, 作成者が 1提となる. しかしながら, 実際の開発においては, ユース

トランザクションと認識すべき処理を 1 イベントとしてケース図が記述されていてもそのイベントフローまでは意識して記述しない限り, 正しく計測を行うことができ

記述されないこともある. このような場合, アクタの場合ない. そこで我々は, 全てのイベント記述に対し, 形態素と同様に, 過去の蓄積された情報を利用することを考え

解析および統語解析を行うことで細かい分析を行い, そる. 蓄積されたユースケースの情報から, 対象となるユーの結果からトランザクションを認識し, カウントする方スケースに類似したユースケースを検索し, 見つかった法を考えた.

情報をユーザに提示する. ユーザはそれを受けて, 複雑

両解析を行うにあたり, 日本語係り受け解析器「南瓜」11)

さの設定, 修正を行うことができる. 検索はユースケーを採用することにした. 「南瓜」は, SVM(Support Vec-

ス名の部分一致による検索を行い, ユースケース名, そし

tor Machines) に基づく日本語係り受け解析6) 器であり,て過去に決定された複雑さ等の情報を表示する. 複数見

統計的な日本語係り受け解析器として最も精度が高いとつかった場合は, その複雑さについて多数決で決定する.

されている (89.29%) システムである. また, バックト

もし, 過去の情報からも類似したユースケースが見つ

ラックを行なわない決定的な解析アルゴリズム (Cascadedからなかった場合は, デフォルトの複雑さとして, 「平均Chunking Model)7) を採用しており, 効率の良い解析が的」とする.

• ルール U-3:イベントフローを持たないユースケー可能となっている.

4.3.2 トランザクションの識別スについては過去の情報を利用する「南瓜」を用いて, 各イベントに対して解析を行うが,• ルール U-4:ルール U-1 及び U-2, U-3 が適用できその結果を用いてどのように 1 つのトランザクションをない場合は, デフォルトの複雑さ「平均的」とする-5-

4.3.4 包含や拡張に対する処理

5.2.2 複雑度測定, UUCP 計測部

Karner の提案した手法では, 包含や拡張ユースケース

XMI 解析部において抽出した情報を元に, 4 節で説明については考慮しないとされている5) が, このようなユーした方針に従い, 各アクタ, ユースケースのタイプ分類をスケースに, システムの本質的な処理が含まれる場合も行う. またその結果から, 未調整ユースケースポイントあることが指摘されており2),8) , 機能規模計測においてを算出する. 各アクタ, ユースケースに対する分類結果,無視できるものではないと考える.

及び未調整ユースケースポイントは, GUI を通してユー

包含や拡張の関係が存在するとき, それをひとつのユー

ザに提示する.

スケースとして処理を記述し, その処理を含むユースケー

また, 表示される結果に対し, ユーザは手動にて分類をスは, 自身のイベントフロー内で包含 (拡張) ユースケー

再設定することも可能であり, 変更による各計測値へのスを参照するイベントとして記述を行う. このことから,更新は随時自動で行われる.

我々は以下に示すルールを設定する.

5.2.3 調整要因評価部• ルール U-5:包含または拡張するユースケースは, 1

技術要因, 環境要因それぞれに対して, ユーザがダイア

つのユースケースとして複雑さを決定し, 計測対象

ログ上で評価を行い, 評価値を入力する. 入力された結とする果をもとに, 各調整係数を算出し, 画面に表示する.

• ルール U-6:それらを参照するユースケースは, イベ

5.2.4 UCP 測定部
複雑度測定部, および調整要因評価部の結果を受けて,ントにおけるその参照処理をトランザクションに含

ユースケースポイント値を算出し, 画面に表示する. まめないた, その結果見積られる工数 (人時で算出) も同時に画面

5. 工数見積り支援ツール U-ESTに表示する. ユースケースポイント値から工数値への変5.1 ツール概略

換係数は, ユーザによる変更が可能である.

本 ツ ー ル U-EST(Usecase-based Estimation Sup-

6. 評

porting Tool) は, XMI(XML Metadata Interchange)
形式で記述されたユースケースモデルを入力とし, 4 節

価

6.1 評 価 概 要で述べた方針に基づいて, ユースケースポイントの計測,

試作したツールが行う分類が妥当なものであるかどう

及び工数の見積りを行う. 開発言語は Java であり, 規模

かを評価するため, 実際のプロジェクトにおいて作成さは 42 クラス, 約 4.2KLOC である.

れたユースケースモデルに対して, ツールを適用した. 今

5.2 システム構成回用いたプロジェクトは, 小中規模の Web システム開発

本ツールのシステム構成図を図 3 に示す. システムはプロジェクトであり, 全部で 5 つある. 表 5 に, その規模

4 つのサブシステムから構成されており, 以下に説明を等について記す.

記す. すべての処理はユーザが GUI を通して操作する.

対象となるプロジェクトのユースケースモデルにおけるアクタ, ユースケースの複雑さに関して, ツールによって決定された複雑さと, 経験者の手動によって決定された複雑さとの比較を行い, 4 節で述べた手法の正確性を評価する.
表5
プロジェクトA
B
C
D
E

プロジェクトデータ

開発言語

Java
Java
Java, VB.NET
Java
Java

アクタ数

ユースケース数

5
5
2
5
8

15
14
20
28
13

6.1.1 複雑さ分類の結果
図3

アクタ, ユースケースについて, ツールと手動での分類

システム構成

結果について表 6, 表 7 に示す.

5.2.1 XMI 解析部

各表は, ツールによる分類と, 手動での分類での, 各複

XMI 形式で記述されたモデルファイルを解析し, 記述

雑さに分類された要素の数を記している. タイプの一致されたアクタ, ユースケース, イベント等, 計測に必要な割合という項目は, ツールで決定された複雑さと手動で情報を抽出する.

決定された複雑さが一致した要素の数の, 全体数に対す-6-

る割合を示したものである.

実装の上では, 関連するユースケースのイベントから,

ここで, 今回の評価においては, アクタの分類を行うた

主にアクタが主体となる動作を抽出してキーワードのマッ

めのキーワード群として, 文献9) をもとに, 以下のキー

チングを行っていたため, 今回のケースでは, アクタが外ワードを用いた.

部システムの場合, キーワードのマッチングを行うこと• 命名規則キー：「システム」「サーバ」ができず, 過去の情報の利用による値, もしくはデフォル• 単純：「リクエスト」「送信」「要求」「通知」

ト値となってしまったことが原因であった.

• 平均的 (システム)：「メッセージ」「メール」「送信」• 平均的 (人間)：「コマンド」「テキスト」「入力」「画6.1.3 アクタの分類に対する対策と再分類
前述の考察を受けて, 複雑さの違いが生じたアクタに対し, 関連するユースケースのイベントについて, 計測対面」「表示」• 複雑：「入力」「画面」「ボタン」「押す」「表示」

象システムが主体となる動作に注目してキーワードマッ
チングを行い, 再分類を試みた.

表6

複雑さの分類結果 (アクタ)

ツールによる分類
単純
平均的
複雑

A
B
C
D
E

0
0
0
0
0

1
3
0
1
0

4
2
2
4
8

その結果, キーワードマッチングを行うことはできた

手動による分類
単純
平均的
複雑

1
3
0
1
0

0
0
0
0
0

4
2
2
4
8

タイプの
一致割合

0.80
0.40
1.0
0.80
1.0

ものの, 決定した複雑さとしては前回と変わらなかった.
さらに分析を進める中で, アクタが外部システムである
場合, そのインタフェースに関する情報をイベントから得るのは困難であることが判った. それゆえ, アクタが外部システムである場合, そのインタフェースに関する情報を, 別の要素から得る必要がある. 今後, インタフェー
スに関する情報の探索, そして多くのケーススタディを

アクタの分類については, プロジェクト B においてそ通して, キーワード設定の有効性を評価する必要がある.

の一致割合が低いものとなったが, 残りのプロジェクト

6.1.4 ユースケースの分類に対する考察については高い一致割合を示した.

まず, 手動計測よりも重みが高い結果となったプロジェ
クト B, C, D について, 各ユースケースの認識トランザ

表7

A
B
C
D
E

複雑さの分類結果 (ユースケース)

クション数を分析してみると, その数が同じか, 手動よりツールによる分類
単純
平均的
複雑

手動による分類
単純
平均的
複雑

13
6
11
23
10

13
10
14
27
2

2
7
9
4
2

0
1
0
1
1

2
4
6
1
8

0
0
0
0
3

タイプの
一致割合

1.0
0.64
0.85
0.82
0.38

も多く認識していた. その差は 1〜2 程度のものであったのだが, 複雑さの判断が手動と異なっていたユースケー
スは, そのトランザクション数の差が, 複雑さの分類の境界で起こっていたために, 手動よりも複雑さが高くなっていたのである.
この原因について更に分析を行うと, 手動計測者の計測方針として, システムが単に情報を表示するだけといっ

ユースケースについては, 一致割合が 0.38〜1.0 と, 広た動作を, トランザクションとしていないことがわかっ

範囲に渡る結果となった. ユースケースの重みでみると,た. シナリオではこの, システムの単なる情報表示も 1

プロジェクト B, C, D で手動よりも高く, プロジェクト

つのイベントとして記述されており, 形態素解析, 統語解E においては手動よりも低いという結果になった.

析を行った結果, トランザクション認識がなされていた

6.1.2 アクタの分類に対する考察ため, 手動計測よりもトランザクション数が多くなった

手動による分類との違いが生じたアクタは, すべて人と考えられる.

間ではなく, 外部システムであった. そこでユースケー

次に, 手動計測よりも重みが低い結果となったプロジェ

スシナリオについて詳しく分析すると, アクタが人間でクト E について同様に分析を行うと, 今度はトランザクある場合は, 動作の方向がアクタからシステムに対するション数を手動計測よりも少なく認識していた. そこでものであるが, アクタが外部システムである場合は, そのイベント 1 つ 1 つに注目してみると, このプロジェクト

動作の方向が主に計測対象のシステムからその外部シスに記述されたユースケースシナリオは, 他のプロジェク

テムに対するものとなることがわかった. つまりアクタ

トとは異なり, アクタのシステムに対する処理と, それにが人間である場合は, そのアクタが動作の主体となるイ

対するシステムのレスポンスが 1 つのイベントとして記

ベントが記述されているものの, アクタが外部システム

述されており, しかもシステムの動作について, その主体の場合は動作の主体ではなく対象となり, それが主体とがシステムであることが陽に記述されていなかった. 前なるイベントとして陽に記述されず, むしろ計測対象シ

述の形態素解析による計測方針では, 主語と述語のセッステムが主体となる動作における対象として記述される

トを 1 つのトランザクションとするため, 主語が省略さことが多いことがわかった.

れた記述であると, トランザクションとして認識されな-7-

い. このことが, 手動計測よりもトランザクション数をシステム開発プロジェクトであったが, 他の様々な少なく認識した原因であると考えられる.

タイプ, 規模のシステムにも適用実験を行い, ユース

6.1.5 ユースケースの分類に対する対策と再分類

ケースポイント法の正確性, 及び可用性の評価を行

前述の考察をもとに, プロジェクト B, C, D, E についう必要がある.

て, 単なる情報表示をトランザクションとして除外し, さ8. 謝らにプロジェクト E については, 主語の省略された動作

辞についてトランザクションとして含め, 再分類を行った.

本研究において，御協力を頂きました 株式会社日立シ

その結果, 手動による分類と完全に一致する結果となっステムアンドサービス 産業・流通システムサービス事業部 津田 道夫 氏, 高橋 まゆみ 氏に深く感謝致します．

た. このことから, 今後のツール改良点として,• トランザクションとして識別すべき動作, もしくは識別しない動作をキーワードなどの情報として予め用意する• 主語との対応が取れなかった等, 識別できなかった
イベント情報をユーザに知らせるなどが考えられる. しかしながら, 先に述べた Jacobsonによる 4 つの意味のあるアクションの集合の部品を考慮すると, システムによる情報表示は, アクタへ結果を返す動作であるとみなすこともでき, トランザクションとして含めるべきであるとも考えられる. ゆえに, このことについては今後より議論する必要がある.

7. お わ り に本研究では, 近年注目されている早期工数見積手法であるユースケースポイント法に基づいて, ユースケース
モデルから機能規模を計測し, 工数見積りを支援するツールの試作を行った. また, 試作したツールを, 実際に開発された 5 つのプロジェクトにおいて, 実際に作成された
ユースケースモデルへ適用し, 経験者による手動での計測結果と比較することで, ツールの精度の評価を行った.
比較の結果, ツールの計測結果は, 手動での計測結果に近いものとなったことを確認し, 実用化の可能性を見出せる結果となった.
今後の課題を以下に挙げる.

( 1 ) 今回評価に用いたユースケースモデル中のユースケー
ス図は, トップレベルのものを対象としたが, ユース
ケースを階層化し, 更に詳細なユースケース図が記述される場合もある. この場合の分類, 及び計測方法について考慮する必要がある.

( 2 ) より多くのプロジェクトに対するケーススタディを行うことで, アクタ分類のキーワードの精度向上, 及びツール, 手法の実用性の向上を目指す必要がある.
その上で, 定まった記述形式の存在しないユースケー
スモデルについて, 最適なテンプレートの提供も課題となる.

( 3 ) 既存の多くの見積手法 (ファンクションポイント法,
COCOMOII など) との比較を行うことで, 手法の精度向上を測る. また, 他手法との併用による効果も調査の価値がある.

( 4 ) 更に, 今回の評価に用いたプロジェクトは全て Web
-8-E

参

考

文

献

1) A.J. Albrecht, “Function Point Analysis”, Encyclopedia of Software Engineering, 1994, 1:518-524.
2) B. Anda, H. Dreiem, D.I.K. Sjoberg, M. Jorgensen, “Estimating Software Development Effort based on Use Cases - Experiences from Industry”, Fourth International Conference on the
UML, 2001, 487-504.
3) B.W. Bohem,“Software Engineering Economics”, Prentice Hall, 1981.
4) A. Cockburn, 山岸耕二ほか [訳], “ユースケース実
践ガイド - 効果的なユースケースの書き方”, 翔泳社, 2001.
5) G. Karner, “Use Case Points - Resource Estimation for Objectory Projects”, Objective Systems
SF AB(Rational Software), 1993.
6) 工藤 拓, 松本 裕治, “Support Vector Machine による日本語係り受け解析”, 情報処理学会自然言語処
理研究会報告, 2000, NL-138.
7) 工藤 拓, 松本 裕治, “チャンキングの段階適用による日本語係り受け解析”, 情報処理学会論文誌, 2002,
43:1834-1842.
8) K. Ribu, “Estimating Object-Oriented Software
Projects with Use Cases”, Master of Science Thesis University of Oslo, 2001.
9) G. Schneider, J.P. Winters, 羽生田栄一 [訳], “
ユースケースの適用:実践ガイド”, ピアソン・エデュ
ケーション, 2000.
10) J. Smith, “The Estimation of Effort Based on
Use Cases”, Rational Software white paper, 1999.
11) CaboCha : Yet Another Japanese Dependency
Structure Analyzer,
http://cl.aist-nara.ac.jp/~taku-ku/softwar
e/cabocha/.