ユースケースモデルを入力とした工数見積支援ツール

ユースケースポイント計測支援ツールの
実装とその適用
松川文一† 楠本真二† 井上克郎†
英繁雄‡ 前川祐介‡
†大阪大学大学院情報科学研究科
‡株式会社
日立システムアンドサービス
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
発表内容
研究の背景と目的
ユースケースポイント法
ユースケースモデル
実装のキーアイデア
アクタ・ユースケースの分類
過去情報の利用
試作ツールとその評価
まとめ・今後の課題
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
2
研究の背景
ソフトウェア開発における開発規模，開発工数の早期
見積りの重要性
ファンクションポイント法
設計段階まで進める必要
開発期間の短いもの（Webアプリケーション等）には適用し難い
開発プロセスのより早期（要求分析段階）における見
積り手法の確立
ユースケースポイント法の提案
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3
ユースケースポイント法（UCP法）
G.Karnerによって提案[1]（1993）
プロジェクトの開発工数（人時）を見積る一手法
ユースケースモデルに基づく
オブジェクト指向開発での要求分析段階で作成
アクタ，ユースケースの重み付け
3種類（単純・平均的・複雑）に分類，重み付け
プロジェクトの技術的複雑さ，開発環境を考慮した調整
実際の適用には・・・
熟練度の要求
既存の計測ツール
複雑さ分類はユーザが行う
[1]G. Karner, “Use Case Points – Resource Estimation for Objectory Projects”, Objective
Systems SF AB, 1993.
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
4
研究の目的
ユースケースポイント法に基づいて自動計測を行う
ツールの試作
アクタ，ユースケース分類（重み付け）の自動化
過去の情報の利用（ユーザ支援）
実際のWebアプリケーションのユースケースモデルへ
の適用および評価
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
5
ユースケースモデル
システムの動作・機能要求をユーザ視点で表現
注文を出す：
構成
注文処理システム
システム
・関連するアクタ：
ユースケース図：UMLによる視覚化
注文を出す
注文を出す
・事前条件，事後条件：
アクタ：システムを使用する人間，関連する別システム
顧客
・イベントフロー：
ユースケース：ユーザが望むシステムの動作
1．顧客が「注文を出す」ボタンを押す。
2．システムは情報入力画面を表示する。
ユースケース記述：ユースケースの機能を実現するために
顧客
商品を返品する
3．顧客は商品コードを入力する。
必要な詳細情報を記述
4．システムは入力された商品コードから商品を検索する。
・
・
・
・
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
実装のキーアイデア
分類の自動化
アクタの分類
ユースケースの分類
過去情報の利用
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
7
アクタの分類
タイプ
単純
平均的
複雑
説明
重み
定義済みAPIを備える（外部システム）
1
プロトコル駆動のインタフェース（外部システム）
テキストベースのインタフェース（人間）
2
GUIを介する（人間）
3
問題点
アクタとシステム間のインタフェースに関する情報をどこから得るか
分類手法
アクタ名に関するキーワード（ユーザ設定可）により，外部システムと人間とを分
類（Step1）
関連するユースケースのイベントに対する，キーワードマッチング（Step2）
そのアクタが主体となるイベントを抽出
インタフェースに関連するようなキーワード群の設定（複雑：「ボタン」「押す」など）
マッチングの割合の高い複雑さを採用
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
8
アクタの分類イメージ
名前キーワード
（ユーザ設定可）に
よる分類（Step1）
システム
システム，サーバ・・・
キーワード（ユーザ設定可）
単純
「リクエスト」「要求」・・・
平均的
「メール」「コマンド」･･･
複雑
「ボタン」「押す」・・・
注文を出す
顧客
平均的
複雑
アクタ主体のイベントに対して
キーワードマッチングを行い、
マッチの割合が高いものを採用
（Step2）
1．顧客が「注文を出す」ボタンを押す。
2．システムは情報入力画面を表示する。
3．顧客は商品コードを入力する。
4．システムは入力された商品コードから商品を検索する。
・
・
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
9
ユースケースの分類
タイプ
ユースケースのトランザクション数
重み
単純 3個以下
注文を出す：
5
平均的 4～7個
・関連するアクタ：
複雑 8個以上
・事前条件，事後条件：
・イベントフロー：
10
15
システム
注文を出す
顧客
1．顧客が「注文を出す」ボタンを押す。
問題点
2．システムは情報入力画面を表示する。
自然言語で書かれたイベントからトランザクションを識別
3．顧客は商品コードを入力する。
4．システムは入力された商品コードから商品を検索する。
イベントの書き方は明確に定められているわけではない
・
・
分類手法
・
形態素解析と係受け解析によるトランザクション識別
・
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
10
トランザクションの識別
CaboCha[2]を用いた解析
形態素解析と日本語での係受け
の解析
統計的な日本語係受け解析ツー
ルとしては最も高精度
システムは、データを登録する。
トランザクション識別基準
主語（名詞+「は」，「が」）+述語
（動詞）のペアを抽出
アクタ，及びシステムの動作（主語
がアクタ，システムを指すもの）であ
ればトランザクションとしてカウント
[2]CaboCha: Yet Another Japanese Dependency Structure Analyzer, http://cl.aist-nara.ac.jp/~taku-ku/software/cabocha/
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
11
過去の情報の利用
手法が適用できない場合
アクタ：マッチングが取れない等
ユースケース：イベント記述がない等
過去情報から類似した要素を探し，過去に決定さ
れた複雑さをユーザに提示
→ ユーザが複雑さを手動で設定
過去の情報がなければ，デフォルト値
アクタ（外部システム）：平均的
アクタ（人間）：複雑
ユースケース：平均的
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
12
試作ツール
詳細
開発言語：Java
サイズ：約4500行, 45クラス
ライブラリ：JDK1.4.2, Xerces2 Java Parser
入力モデル：UMLモデリングツール「Describe」[3]で記
述されたユースケースモデル
XMI（XML Metadata Interchange）形式
– XMLの構文仕様によるUML記述方式
独自のDTD定義を使用
[3] Describe: http://www.jsys-products.com/product/describe/
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
13
ツール評価（1/3）
アクタ，ユースケースの複雑さ分類の正確性を評価
5つのWebシステム開発プロジェクトに対する適用
経験者による手動での分類結果との比較
プロジェクト
開発言語
アクタ数
ユースケース数
A
Java
5
15
B
Java
5
14
C
Java, VB.NET
2
20
D
Java
5
28
E
Java
8
13
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
14
ツール評価（2/3）
アクタの分類
ツールによる分類（自動）
手動での分類
単純
平均的
複雑
単純
平均的
複雑
複雑さの
一致した割合
A
0
1
4
1
0
4
0.80
B
0
3
2
3
0
2
0.40
C
0
0
2
0
0
2
1.0
D
0
1
4
1
0
4
0.80
E
0
0
8
0
0
8
1.0
プロジェクト
考察
複雑さの異なったアクタは全て外部システム
外部システムが主体となるイベント記述の欠如
システム主体のイベントに外部システムが関連（データの移動，取得）
再分類後も結果は変わらず
キーワードからのインタフェース判別は困難
→ モデル以外からの情報入手（アーキテクチャ図など）
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
15
システム
ユースケースA
人間A
外部システムA
1．人間Aは、番号を入力する。
2．システムは、番号をキーに外部システムAに問い合わせ、データを取得
し、表示する。
3．人間Aは、登録する物の種別を選択する。
4．システムは、選択された種別をキーにデータを問い合わせ、データを取
得し表示する。
・
・
・
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
16
ツール評価（3/3）
ユースケースの分類
ツールによる分類（自動）
手動での分類
単純
平均的
複雑
単純
平均的
複雑
複雑さの
一致した割合
A
13
2
0
13
2
0
1.0
B
6
7
1
10
4
0
0.64
C
11
9
0
14
6
0
0.85
D
23
4
1
27
1
0
0.82
E
2
8
3
2
8
3
1.0
プロジェクト
考察
システムによる情報表示処理に対する扱いの違い
イベント表示画面におけるユーザによる修正
再分類後は全てのプロジェクトで完全に一致
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
17
1．アクタは、プロジェクト一覧の中からプロジェクトをひ
とつ選択する。
2．システムは、選択されたプロジェクト情報を表示する。
・
・
情報表示処理をトランザクションとしない
（ツールでは識別）
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
18
まとめと今後の課題
ユースケースポイント法に基づいて計測を行うツール
の試作
ツールの評価
5つのプロジェクトに対する適用
今後の課題
外部システムのインタフェースに関する情報の探索
過去情報利用機能の評価
多くのケーススタディ
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
19
補足
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
20
UCP計測手順（1/4）
アクタの重み付け
アクタそれぞれを3タイプに分類
タイプ
単純
平均的
複雑
説明
重み係数
定義済みAPIを備えた別システム
1
プロトコル駆動のインタフェース（別システム）
テキストベースのインタフェース（人間）
2
GUIを介する人間
3
それぞれのタイプのアクタの数に係数を掛け、合計したも
の → アクタの重み
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
21
UCP計測手順（2/4）
ユースケースの重み付け
ユースケースそれぞれについて同様に分類
ユースケース内のトランザクション数に基づく
タイプ
単純
平均的
複雑
トランザクション数
3個以下
4～7個
8個以上
重み係数
5
10
15
それぞれのタイプのユースケースの数に係数を掛け、合計したもの
→ ユースケースの重み
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
22
UCP計測手順（3/4）
未調整ユースケースポイント（UUCP）
UUCP = アクタの重み + ユースケースの重み
この値に以下の要因を反映して補正
技術要因（TCF）
– プロジェクトの複雑さに関する要因
– 13の項目について0～5の6段階で評価
» 分散システム，移植可能，特別なセキュリティ, etc…
環境要因（EF）
– プロジェクトに携わるチームの経験や，開発環境に関する要因
– 8の項目について0～5の6段階で評価
» 開発経験，モチベーション，要求の安定性，etc…
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
23
UCP計測の方法（4/4）
ユースケースポイントの算出
UCP = UUCP × TCF × EF
調整係数による補正
TCF : 約±30%
EF : 約±60%
工数の算出
Karnerの提案：20人時 / 1UCP
20～30が適当か
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
24
UCP計測手順（4/6）
技術要因の重み付け
技術的複雑さ要因
（TCF : Technical Complexity Factor）
1. 13項目の要因について0～5の6段階で評価
2. 各評価値に、項目ごとに設定されている重みを掛け
てその和を算出（TFactor）
TFactor = Σ（各要因の評価点） × （重み係数）
3. TCFを以下の公式を用いて算出
TCF = 0.6 + （0.01 × TFactor）
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
25
技術要因
システムの技術要因とその重み
要因番号
要因の説明
重み
T1
分散システムである
2
T2
レスポンスまたはスループットのパフォーマンス目標が設定されている
1
T3
エンドユーザの効率（オンライン時）を重視
1
T4
内部処理が複雑
1
T5
コードが再利用可能でなければならない
1
T6
インストールしやすい
0.5
T7
使いやすい
0.5
T8
移植可能
2
T9
変更しやすい
1
T10
並行性が必要
1
T11
特別なセキュリティ機能が必要
1
T12
第三者に直接アクセスを提供している
1
T13
特別なユーザトレーニングが必要
1
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
26
UCP計測手順（5/6）
環境要因（EF : Environmental Factor）
1. 8項目の要因について0～5の6段階で評価
2. 各評価値に、項目ごとに設定されている重みを掛け
てその和を算出（EFactor）
EFactor = Σ（各要因の評価点） × （重み係数）
3. EFを以下の公式を用いて算出
EF = 1.4 + （- 0.03 × EFactor）
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
27
環境要因
チームの環境要因とその重み
要因番号
要因の説明
F1
採用するプロセスに精通している
F2
その分野での開発経験がある
F3
採用する方法論についての経験
F4
主任アナリスト（リーダー）の能力
F5
プロジェクトに対するモチベーション
F6
要求仕様の安定性
F7
F8
2015/10/1
兼任スタッフの存在
プログラミング言語の難しさ
重み
1.5
0.5
1
0.5
1
2
-1
-1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
28
アクタ分類におけるキーワード
キーワード
命名規則
「～システム」「～サーバ」
単純
「リクエスト」「要求」「通知」
平均的外部システム
「メッセージ」「メール」「送信」
人間
複雑
2015/10/1
「コマンド」「テキスト」「入力」
「ボタン」「押す」「選択」
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
29
効果的なイベント記述方針
単純な文法で記述
主語，述語，修飾語，目的語・・・
動作の主語を明確に
意味のあるアクションの集合
主アクタがシステムに要求とデータを送る
システムが要求とデータを確認する
システムがその内部状態を変更する
システムがアクタに結果を返す
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
30
過去の情報の利用（支援手法）
以下の情報を蓄積
プロジェクト情報（業種，言語，期間等）
アクタ情報（名前，業種，決定された複雑さ等）
ユースケース情報（名前，業種，決定された複雑さ等）
イベント情報（使用されたユースケース，イベント本体）
過去に計測された類似した要素の複雑さを表示することで
分類を支援
自動化の手法では決定しにくい要素
キーワードにヒットしないアクタ
イベント記述のないユースケース
自動化の手法が適用された場合も見つかれば表示
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
31
SVM（Support Vector Machine）
統計的学習理論に基づく学習モデル
パターン認識の能力において最も優秀な学習モデルの1
つ
従来モデルに比べ汎化能力が高く，過学習しにくい
手書き文字の認識や3次元画像認識など多くの分
野で応用
自然言語処理分野における文書分類
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
32
「南瓜」使用例
入力文章
簡易Tree表示
計算機処理用
フォーマット
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
33
試作ツール（システム構成）
ユースケースポイント計測システム
モデリング
Describe
モデルファイル
（XMI形式）
XMI解析部
各情報
（アクタ、ユースケース、イベント）
イベント解析
複雑度測定部
未調整ユースケースポイント
（UUCP）
GUI
結果表示
部
技術要因（TCF）
UCP測定部
ユーザ
環境要因（EF）
要因評価部
計測結果
過去のプロジェクト情報
過去計測DB
データの流れ
データベース蓄積
2015/10/1
制御の流れ
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
34
ツール評価
ユースケースの再分類結果
プロジェクト
ツール計測
手動計測
一致率
単純
平均的
複雑
単純
平均的
複雑
A
13
2
0
13
2
0
1.0
B
10
4
0
10
4
0
1.0
C
14
6
0
14
6
0
1.0
D
27
1
0
27
1
0
1.0
E
2
8
3
0
10
3
0.85
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
35
ツール評価
工数比較
プロジェクト
ツール見積工数手動見積工数
実工数
A
20.8（人時）
20.6
18.6
B
13.1
10.2
4.5
C
29.8
26.8
16.0
D
23.9
20.5
21.2
考察
プロジェクトB：自動生成部分の割合高→実工数低下
誤差の範囲：3.1%～67.8%
要求仕様段階での誤差は60%以内に抑えるべき（Bohem）
2015/10/1
第144回ソフトウェア工学研究会
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
36

Download Report