ソフトウェア・シンポジウム2017 in 宮崎

要件定義書からのファンクションポイント自動計測の試み
山田涼太 山田悠斗 楠本真二 柗本真佑 肥後芳樹
大阪大学大学院情報科学研究科{r-yamada, y-yuto, kusumoto, shinsuke, higo}@ist.osaka-u.ac.jp
要旨報システムの開発においても，要求内容に設計または開発に関する工程が含まれる場合には，原則 FP の見積り

一般にソフトウェア開発プロジェクトの見積りでは，及びその根拠を示すことが必須となりつつある [4]．そのまず開発規模が見積もられ，それを用いて工数や予算

一方，FP の導入における様々な課題のため，ベンダー・の見積りが行われる．開発規模の尺度として，最近ではユーザ企業ともに FP は十分に普及していない．1 つ目のファンクションポイント (FP) の利用が重要視されてい課題は，見積りのための基礎データが必要であることでる．一方で，FP を導入する上での幾つかの課題があり，ある．新規プロジェクトに対する FP を計測したとしてそれらの対策として計測の自動化が期待されている．

も，その値を工数に変換するためには，ある程度，過去

本稿では，開発の上流工程で作成される要件定義書をプロジェクトの FP 値と工数の情報が必要となる．次に，対象とした，FP 自動計測の試みについて報告する．提計測者の判断による誤差が生じる点である．詳細な部分案手法では，要件定義書のうち機能仕様についての記述の FP の計測には測定者の判断が必要となる．同一のソを提案するテンプレートを用いて書き換え，書き換えら

フトウェアからの FP 計測であっても，計測者によってれた仕様を解析し，計測に必要な要素を抽出することで誤差が生じてしまうという問題点が指摘されている [5]．

FP 計測を行う．4 種類の小規模な要件定義書を対象に

例えば，同じ組織の人間が同じアプリケーションに対し提案手法を適用し，手動での計測と比較することで精度て測定した場合は 12%，違う組織の人間が即していた場を確認した．その結果，3 つの要件定義書では手動計測合は 30%以上の誤差が出るという報告もされている [6]．と同様の値が，残りの 1 つの要件定義書では手動計測よ最後に，導入教育が必要である．FP 法を用いるためにり若干大きな値が計測された．

は，FP 計測方法や，見積りについての知識を身につけなければならない．それらの課題の 1 つの対策として，計測の自動化が考えられる．

FP 計測の自動化に関する研究としては，UML(UnifiedModelling Language) 図で記述された設計図からの計測[7, 8]，Web アプリケーション・プログラムからの計測

1. はじめに
一般に，ソフトウェア開発においては初期段階での[9, 10] 等があり，幾つかの制約を置いた上である程度正確な FP 値の計測が可能となっている．しかし，開発のソフトウェア開発規模の見積りが重要である [1] ．不正
確な見積りはプロジェクト失敗の原因になることも報告

上流工程で作成される主に自然語で記述された要件定義されている [2]．正確な見積りの実現を目指し，ソフト書を対象とした FP 自動計測手法は著者らの知る限りはウェア開発規模の見積りに関する研究が盛んに行われて存在しない．

いる．

本研究では，要件定義書 [11] を対象とした，FP 自動見積りの基となる開発規模の尺度としてはソースコー計測手法について検討する．まず，小規模な自然語で書ドの行数がよく使われていたが，最近ではファンクショかれた仕様に対して，仕様がどのように記述されていれンポイント (FP) [3] の利用が重要視されている．政府情149

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ば計測が可能かを確認・調査する．その結果に基づいて，自然語記述からの FP 計測方法を提案する．提案手法で計測対象

は，機能仕様を FP 計測のためのテンプレートを用いた書き換え，書き換えられた仕様を解析して FP を計測す

他システム

成績管理
アプリケーション

成績登録

生徒管理
アプリケーションる．更に提案手法に基づいた計測ツールを試作し，様々なプロジェクトの仕様書で検証することで評価を行った．
以降，2 章では研究の背景となる諸用語や関連研究につEQ

成績表参照

生徒名簿

成績検索

いて述べる．3 章では今回提案する自動計測の手法について述べる．4 章では実際に自動計測を行った結果と考平均点を含む察について述べる．最後に 5 章で本報告のまとめを述べる．

成績一覧印刷

2. 準備

 成績表…内部論理ファイル(ILF) 生徒名簿…外部インターフェイスファイル(EIF)
 成績登録…外部入力(EI) 成績検索…外部照会(EQ) 成績一覧印刷…外部出力(EO)

図 1. 基本機能要素の例

本章では研究の背景となる諸用語や関連研究について

外部出力 (EO)

簡単に述べる．

計測境界外へのデータ出力を含む処理のうち，出力データに導出データを含むもの

2.1. ファンクションポイント法

外部照会 (EQ)

ソフトウェアの規模を見積もる手法の 1 つにファンク

計測境界外へのデータ出力を含む処理のうち，出力ションポイント (FP) 法 [3] がある．FP 法は，ユーザかデータに導出データを含まないものであり，処理がら見た機能の量を計測する手法で，A.J.Albrecht によっILF を更新しないものて 1979 年に提案された．画面や帳票，ファイルなどを通じた情報の入出力に着目し，それらを種類別に数え例として，図 1 に学生の成績管理アプリケーションと上げ，種類数を加重合計した値を機能量としている．以

そこに含まれる基本機能要素を示す．計測対象である成降，IFPUG 法 [12]，MarkII 法 [13]，COSMIC 法 [14] 等，

績管理アプリケーション内でデータが更新される成績表

様々な FP 法が提案されてきている．本研究では IFPUG

は ILF，成績管理アプリケーション内にはなく，成績管法を対象とし，以降，FP 法とは IFPUG 法を意味する

理アプリケーションから参照される生徒名簿は EIF となこととする．IFPUG 法は，Albrecht 版の使い勝手や曖る．また，データ入力によって成績の登録を行う成績登昧な部分を改良したバージョンであり，ビジネスアプリ

録処理は EI，成績表から平均点などの派生データを含ケーションソフトウェアを対象として欧米で広く使用さまないデータを出力させる成績検索は EQ，成績表かられている．IFPUG 法では，ソフトウェアの持つ機能か平均点などの派生データを含むデータを出力させる成績

ら 5 種類の基本機能要素を以下に示す [15]．

一覧印刷は EO となる．上記の 5 種のうち，ILF と EIF
はデータファンクション (以降，DF)，EI と EQ と EO

内部論理ファイル (ILF)

はトランザクションファクション (以降，TF) と呼ばれ，計測対象のアプリケーション内でデータが更新されそれぞれ計測に必要な要素が異なる [15]．

る論理的な関連を持ったデータの集合• DF

外部インターフェイスファイル (EIF)
計測対象のアプリケーションによってデータが参照– 種別…ILF，EIFされるデータの集合 (データは更新されない)– DET(Data Element Type)…アプリケーショ
ン上で参照される項目の数

外部入力 (EI)
計測境界外からのデータ入力によって ILF の更新– RET(Record Element Type)…データ群の属性内のサブグループの数を行う処理

150

SEA

ソフトウェア・シンポジウム2017 in 宮崎• TF

在庫不足情報は、– 種別…EI，EQ，EO

依頼番号と 送り先名と 銘柄と 数量を 持つ– DET…重複を除いた入出力項目の数に，該当処理において下記のものがあれば 1 ずつ増やデータ群です。

したもの

図 2. cabocha による解析例∗ きっかけ (処理が行われるトリガー．ボタンなど)

3. 提案手法∗ メッセージ (エラーメッセージなど)

本章では今回提案する計測手法について述べる．

– FTR(File Type Reference)…TF に関わる DFの数

3.1. 提案する FP 計測の流れ
上述した要素を用いて各機能の複雑度を計測し，その上で FP の値を求める．

2. で述べた通り，FP 法はユーザから見た機能の量を計測する手法であるため，要件定義書に記載されている• DF の複雑度情報を用いることで，計測することは可能である．しか表 1 を参照し DF の複雑度を決定する．例えば RETし，一般には，必要な情報が省略されている場合も考えが 1，DET が 26 の ILF があった場合，表 1 より複られ，必ずしも全ての情報が記載されているとは限らな雑度は低となる．

い．そこで，幾つかの小規模な仕様書に対して，どの程度詳細に記述されていれば，自動計測が可能かどうかを• TF の複雑度確認した．その結果，以下のような仮説を仮定した．

EI，EO，EQ のそれぞれに対して用意されている対応表を用いて，TF の複雑度を決定する．例えば，EI は，表 2 を参照し複雑度を求める．FTR が 2，DET が 14 の EI の場合，複雑度は中となる．

A1 DF 計測の基となるアプリケーションで扱われるデー
タは，アプリケーションが行う処理（機能）での入力や処理の中で使われる項目として表れている．また，表の形で記載されることもある．

• 複雑度からの FP 計測
A2 DF において，DF が持つ項目についての情報は仕抽出された基本要素の複雑さ毎の個数を表 3 に代入様に明記されている必要がある．

し，それぞれに設定されている重み数を掛けて足し合わせた値が FP となる．前述の例であれば，複雑A3 DF の種別は，TF において参照する DF が明記されていれば更新されるか否かが分かる．

度「低」の ILF(RET：1，DET：26) であれば重みは 10 となる．また，複雑度「中」の EI(FTR：2，A4 DF の DET は，TF において参照する DF と入出力項目が明記されていれば特定することができる．

DET：14) であれば重みは 4 となる．
2.2

自然言語解析ツール cabocha

A5 TF 計測の基となるアプリケーションが提供する機能は，処理を表す文章や図を用いて表現されること

cabocha は Support Vector Machines(SVM) に基づ
く日本語係り受け解析器である [16]．入力として与えられた文中の各単語の品詞と各文節の係り先を取得する．

が多い．

A6 TF の種別は，仕様に含まれた特定の用語および出力項目と参照する DF から判別できる．

図 2 に解析例を示す．矢印はその文節の係り先を表している．図 2 からは，『このデータ群は、』という文節は『データ群です。』に係り，『依頼番号と』という文節が間

A7 TF において，全ての TF に「きっかけの有無」が存在する．

接的に『持つ』という文節に係っていることが分かる．

151

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 1. ILF と EIF の複雑度
PPPPDETPP
1-19 20-50 > 50
PPRET
P1低低中

表 2. EI の複雑度
PPPPDETPP
1-4 5-15
PPFTR
P0-1
低低> 15
中2-5

低中高2

低中

高>5

中高高>2

中高高

表 3. FP の算出のための計算表
低中高ILF□× 7=□□× 10=□□× 15=□

EIF□× 5=□□× 7=□□× 10=□

EI□× 3=□□× 4=□□× 6=□

EO□× 4=□□× 5=□□× 7=□

EQ□× 3=□□× 4=□□× 6=□

合計FP

A8 TF において，DET の根拠となる「入出力項目」「メッセージの有無」および FTR の根拠となる「関わる DF」についての情報は仕様に明記されている必

要件定義書

機能仕様

品質仕様

…

書き換え

要がある．

計測用の仕様以上の仮説に基いて，以下の４つのステップを提案する．

要素の抽出

また，概要を図 3 を示す．

計測に必要な要素
自動計測

1. 要件定義書における機能を説明する部分の文章を自FP

動計測用テンプレートに合わせて計測用の仕様へと変換する．

図 3. 提案する FP 計測手法の概要

2. 変換した仕様から計測に必要な要素を抽出する．
• 一般には図表参照と記載されている部分について，文章で記述されていること．

3. 解析結果を用いて FP を計測する．

図 4 にて例を示す．例えば「ログインは図４の画面を3.2. 提案手法の前提用いて行う．
」と記載されている場合，「ログイン画面では、名前とパスワードを入力し、ログインボタンを押す

今回の提案手法は，3. の最初で述べた小規模な仕様書ことでログインを行う。」と図を参照せずに，文章としに対する試行結果に基づくものであるので，いわゆる在て記載する．

庫管理等のビジネスアプリケーションに関する要件定義書が対象となる．また，要件定義書では，機能を説明す

3.3. テンプレートを用いた書き換える部分の文章において以下の条件を満たすものとする．

• 主語，述語，目的語が整った誤解の生まれない文であること．

計測には大きく分けて，DF と TF の計測が必要であり，それぞれの計測において必要な要素が存在する．そ

152

SEA

ソフトウェア・シンポジウム2017 in 宮崎

ログイン画面(処理名)処理は、（入力項目）を入力することによって、（項目|DF名）を(用語)します。
（DF名）を参照し、(項目)を得ます。
(メッセージ名）というメッセージが表示されることがあります。

名前
passwordログイン

用語・・・登録，更新，削除，表示，出力，印刷など

ログイン画面では、名前とパスワードを入力することでログインを行う。

図 5. TF のテンプレートを出力したか」「何を参照したか」のみをテンプレート

図 4. 図から文章への変換に合わせて記せばよいため，FP 計測の知識がない者であっても変換は容易である．

れらの要素を持った仕様であれば，理論的には自動計測は可能であるが，前述の「主語，述語，目的語が整った誤解の生まれない文」であっても自由度が存在するため，今回はテンプレートを用いて書き換えを行う．

3.3.2

DF のテンプレート記述

DF の計測に必要な要素は以下の通りである．
3.3.1• 種別…ILF，EIF

TF のテンプレート記述• DET…アプリケーション上で参照される項目の数

TF に必要な要素は以下の通りである．

• RET…データ群の属性内のサブグループの数• 種別…EI，EQ，EO

RET とは，１つの DF の中に混在している異なる意• DET…入出力項目の数 (重複は除く)+1(きっかけの有無)+1(メッセージの有無)

味合いを持つデータのまとまりの数を指す．しかし，仕• FTR…関わる DF の数サブグループであるかを判別することは，仕様の中で直様から得られる要素を用いて対象の DF がどの DF の接的な言及が行われていない限り不可能である．そのた

今回の計測では全ての TF にきっかけがあると仮定しめ，本研究では RET を常に 1 として数えることとした．ているので，テンプレートに沿って書き換えられた文章

よってテンプレートに沿って書き換えられた文章のみでから FP 計測を行うためには，「種別」「入出力項目」「メッFP 計測を行うためには，その文章から「種別」「アプリセージの有無」「関わる DF の数」といった情報が得られケーション上で参照される項目の数」といった情報が得なければならない．計測に必要な要素を含み，かつ判別られなければならない．計測に必要な要素を含み，かつの容易な文章を作るためのテンプレートが図 5 である．

判別の容易な文章を作るためのテンプレートが図 8 であ図 5 のテンプレートに変換する際，処理に入力項目やる．実際に図 8 のテンプレートを用いて変換を行うと図参照，メッセージが存在しない場合はそれぞれ「(入力9 上部にある文章は，図 9 下部のように変換される．

項目) を入力することによって、」や「(DF 名) を参照して、(項目) を得ます。」，「(メッセージ名) というメッセー

3.4. 自然言語解析による要素の抽出ジが表示されることがあります。」の部分を記載しない．
実際に要件定義書内の文章をテンプレートへと書き換

先述したテンプレートに沿って書き換えた仕様からえる．交通費登録内容の照会という機能 [17] を用いて説FP 計測に必要な要素を以降で述べる方法で抽出する．

明する．当該機能は，図 6 のような文章で記述されている．これをテンプレートに変換した場合，図 7 のように3.4.1なる．上記の通り，「UI に」などのような FP 計測に関係DF からの要素抽出ない部分が取り除かれ，計測に必要な要素のみが残った

図 8 のテンプレートにおける (項目) は当該 DF が持ことが分かる．また，基本的に「何を入力したか」「何つ全項目である．しかし DF の FP 計測に必要なものは

153

SEA

ソフトウェア・シンポジウム2017 in 宮崎「所有する項目の数」ではなく「アプリケーション上で精算データの照会は、UIに社員番号と登録日付を入力することで、画面中央に利用日と目的と金額と交通機関とFromとToを表示する。
エラーが起きた際にエラーメッセージが表示される。
社員番号と登録日付を基に、交通費精算ファイルを参照することで利用日と目的と利用金額と交通機関とFromとToを得る。

参照される項目の数」であるため，このテンプレートからでは DET が数えられない．また，種別についての言及もない．そこで，前述した TF の情報を用いて以下のように判別を行う．

• DET の判別

図 6. 変換前の文章

当該 DF のテンプレートにて示された項目のうち，TF の中で一度以上使用された項目のみを DET として数え上げる．

精算データの照会処理は、社員番号と登録日付を入力することによって、利用日と目的と利用金額と交通機関とFromとToを表示します。
交通費精算ファイルを参照し、利用日と目的と利用金額と交通機関とFromとToを得ます。
また、入力データに誤りがあった際エラーというメッセージの表示を行います。

• ILF と EIF の判別
当該 DF が一度でも EI 内にて登録や更新が行われていた場合は ILF，そうでない場合は EIF として判別する．例として「A を更新する。」と記述さ

図 7. 変換後の文章れていれば A は ILF と判別される．

3.4.2

そのようなデータがない，つまり DF の項目をそのTF からの要素抽出まま出力していれば EQ と判別する．

図 5 のテンプレートにおける (入力項目)，(出力項目)は DET の一部である入出力項目に相当し，(データ群)は処理に関わる DF を示している．また，「〜というメッ

3.4.3

TF でない処理についてセージが表示されることがあります」という文によってメッセージの有無が判別できる．従って，このテンプレー

今回の計測上，仕様の書き換えの際に TF ではない処

トで，「入出力項目」「メッセージの有無」「関わる DF の理を TF のテンプレートを使って変換してしまう場合が数」は文章から直接読み取れる．

あり得る．今回の手法では，EI, EQ, EO の判断のため一方で「種別」については明記が行われていない．そ辞書に登録している「更新」や「表示」「出力」等の用

こで，このテンプレートから該当 TF の種別が EI，EQ，語が存在しない場合，EI，EQ，EO ではないとして TF

EO の 3 種の内どれに該当するのかを以下の 2 段階で判別する．

としては扱われないため，計測には問題ない．

• EI と EQ，EO の判別方法
EI と EQ，EO の判別を使われている用語で行3.4.4

う．具体的には，「登録」，「更新」といった外部入力

重複処理について

FP 計測において，処理内容が同一の処理は重複処理と呼ばれる．この重複処理は複数存在しても 1 つしか計に関する用語であれば EI，「表示」，「出力」といった用語が用いられているなら EQ，EO といった判測しないルールとなっている．そのため，図 10 のよう別を行う．判別のための用語は，辞書に別途登録しに同一の項目を持つ処理が複数存在した場合，それらをておく．

重複処理と判断し，1 つしか数えないようにする．

• EQ と EO の判別方法
EQ と EO の判別には，動詞の目的語となる項

3.5. FP の計測目を用いて判別を行う．具体的には，FP 計測規則

[12] に則って，DF に含まれていないデータ（項目）

ここまでのステップにて FP 計測に必要な要素が全てが出力されていれば，トランザクションにおいて何揃うため，2．1．で記述したように要素から複雑度およらかの処理を行っていると判断して EO と判別し，び FP を算出する．

154SEA

ソフトウェア・シンポジウム2017 in 宮崎

処理名(DF名)は、（項目）を持つデータ群です。

図 8. DF のテンプレート

データベース名
データ項目
図書情報
出版社，題名，著者名
利用者情報
氏名，利用者番号

種別 入力
項目

図書検索A

EQ

図書検索B

EQ

出力項目

参照した メッセージ
DFの有無

図書 題名，番号 著者名
図書 題名，
番号 著者名

図書情報
図書情報

有り
有り

処理名以外の全項目の内容が一致
「図書検索A」と「図書検索B」は重複処理と判断

図 10. 重複処理となる例

要件定義書

図書情報は、出版社と題名と著者名を持つデータ群です。
利用者情報は、氏名と利用者番号を持つデータ群です。

機能仕様

品質仕様

…

手動による書き換え

計測用の仕様cabochaによる自然言語解析
試作ツール

図 9. DF のテンプレート記述への変換

計測に必要な要素
自動計測FP

3.6. 計測ツールの実装

図 11. 計測フローと計測ツールの役割

これまでに述べた方針に基づく FP 計測ツールを Java
言語を用いて試作した．計測ツールの役割は「cabochaを用いた自然言語解析による計測に必要な要素の抽出」
および「DF や TF の種類などの cabocha では抽出できない要素の判別」，そして「要素を用いた FP の算出」
である．図 11 に本研究における FP 計測の流れと計測ツールの関係を示す．

4.1. 対象システムの概要
今回自動計測の対象とした 4 つのシステムの概要を記す．

1. 旅費精算システム
交通費の管理を行うシステムである．社員が出張

計測の流れは以下の通りである．

にて支払った交通費を登録しておくことで上司がそ

1. 要件定義書のうち，機能に関わる部分の文章を意味内容が明確となるよう手動で変換する．

れを確認，承認できる．また，承認されたものについては銀行への支払い命令が行われる [17]．

2. 書き換えた文章をテンプレートを用いて計測用の仕2. 図書システム

様に手動で変換する．

図書の管理を行うシステムである．図書の登録や増冊，検索や削除などが行える．ある企業の社内勉

3. 計測用の仕様に cabocha による自然言語解析を行い，計測に必要な要素を抽出する．

強用資料に記載されているものである．

3. 酒屋問題
酒の在庫管理を行うシステムである．積荷として4. 3．で抽出した要素を用いて，FP 計測を行い結果を運ばれてきた酒の銘柄や本数の登録や，出庫指示な出力する．

どが行える [18]．

4. ケーススタディ

4. 健康情報サイト
病院や健康情報について扱うサイトである．健康

本章では，対象となる 4 つの仕様書に対して自動計測診断が行われている病院の検索や健診情報の登録がを行った結果及び考察をまとめる．

行える [19]．

155

SEA

ソフトウェア・シンポジウム2017 in 宮崎

表 4. 計測結果
図書システム

旅費精算
手動DFILF
EIF

71710EI
TF

EQ
EO
FP

自動

71710

1252202069

手動

1414012522020

自動

01340

69

710手動

1414

酒屋問題

01340

44

71044

4.2. 提案手法の計測結果と手動計測結果の比較

自動

141431238

手動14140924

健康情報

21210122731241

自動21210307541496307541496

高く，結果として今回のように付随処理の分多く計測される可能性も高い．この問題に関しては，自動先述した 4 つのシステムの要件定義書に対して，FP計測後の結果をファイル出力し，利用者の手によっ計測の熟練者 (一部は FP 計測における国際資格であるて修正・変更を行う方法による解決が望ましい．

CFPS[20] の有資格者）による手動計測結果および計測ツールによる自動計測結果を表 4 に示す．表 4 より，手動で計測した結果と比べ，酒屋問題において TF と FP

2. DF が明記されていない場合の対応
今回は DF や TF について記述が正確に行われているという条件で FP 計測手順を提案したため，有が 3 ずつ多く計測されていることが分かる．

資格者が計測した際の値と近いものを得ることができた．しかし，実際の要件定義書の中には DF につ4.3. 考察いて明示的に記載されていないケースが存在する．

1. 誤差についての分析
旅費精算システム・図書システム・健康情報サイ

その場合，今回の研究にて提案した手法をそのままトの要件定義書に対しては，手計算で得られた FP扱われているデータ項目の集合を DF の候補とすると同様の値を得ることができたが，酒屋問題に関しということを考えており，今後その詳細を検討するては誤差が生じた．この原因について考察する．

予定である．

適用できないため，一つのアイデアとして，TF で酒屋問題における誤差の原因を調べたところ，本5. あとがき

来無視すべき付随処理を計測していることが原因であった．付随処理とは TF として扱われる処理に本研究では，自然言語で書かれた仕様書からの FP 自おいて，本来の処理に付随して行われる処理の事を動計測の実現を試みた．その方法として，テンプレート言う．酒屋問題においては酒の在庫情報を更新するを用いて仕様を書き換えた上で，自然言語解析を用いて「在庫情報更新処理」が相当し，この処理は本来出FP 計測に必要な要素を抽出し FP 計測を行う手法を提案した．4 つの仕様書を対象とし，提案手法を用いて自動計測を行った．その結果，3 つの仕様書においては手庫の指示を担う出庫指示票を出力する処理である「出庫指示票出力処理」に付随して行われる処理であったが，今回の提案手法での計測では別々の処理計算で見積りが行った場合と同様の FP を算出することとして計測された．FP 計測においてこの付随処理は無視される，つまり計測されないものであるが，その処理が付随処理であるかどうかは FP 計測の知ができた．残り 1 つの仕様書では手計算で得られた FPと異なる値が得られたことから，その原因に対する考察を行った．

識がある者でしか判断できず，またツール側から判本研究の今後の課題としては，下記のような事が考え断することもできない．そのため，FP 計測の知識られる．

があまりない者がテンプレートへの変換を行った場合，この付随処理も含めて記述してしまう可能性が

1. 適用事例の追加

156SEA

ソフトウェア・シンポジウム2017 in 宮崎今回取り扱った 2 つの要件定義書は最大でも FP

IEEE Transactions on Software Engineering, Vol.
16, No. 1, pp. 64-71, IEEE, 1990.

が 100 程度のものであり，また，FP が小さいために要件定義書内で扱われる処理も種類が少ない．そ[6] B．Kitchenham. The problem with function
points. IEEE software, Vol. 14, No. 2, p. 29, IEEEのため，FP が大きく，また，多種多様な要件定義書への適用を行いそこで生じた問題点を解決するこComputer Society, 1997.とで，本研究の実用性を高める．

[7] T. Uemura, S. Kusumoto, and K. Inoue. Function-

2. 手法の改善

point analysis using design specifications based on
the united modelling language.Journal of software
maintenance and evolution:Research and practice,

テンプレートを用いた書き換えコストの調査やテンプレート記述以外のより計測に適した記述方法の提案，および穴埋め式記述を用いたツールの開発にVol. 13, No. 4, pp. 223-243, IEEE Computer Society, Wiley Online Library, 2001.

よるより記述量の少ない計測手法の提案などによって本研究における手法そのものの改善を行い，本研究およびツールの有益性を高める．

[8] G. Cantone, D. Pace, and G. Calavaro. Applying function point to united modeling language:

謝辞

Conversion model and pilot study.Software Metrics, 2004．Proceedings．10th International Symposium on, pp. 280-291. IEEE, 2004.

本研究を進めるにあたって，貴重なご助言を頂きました株式会社 NTT データ 鵜澤仁氏，一般財団法人経済[9] T. Edagawa, T. Akaike, Y. Higo, S. Kusumoto,
S. Hanabusa, and T. Shibamoto. Function point

調査会 大岩佐和子氏，押野智樹氏に深く感謝申し上げます．
本研究は一部，日本学術振興会科学研究費補助金基盤研究（S）（課題番号：25220003）の支援を受けている．

参考文献

measurement from web application source code
based on screen transitions and database accesses.
Journal of Systems and Software, Vol. 84, No. 6,
pp. 976-984, Elsevier, 2011.
[10] P. Fraternali, M. Tisi, and A. Bongio. Automating
function point analysis with model driven development. In Proceedings of the 2006 conference of[1] B．Boehm, C．Abts, S．Chulani. Software de- velopment cost estimation approaches - A survey. Annals of software engineering, Vol. 10, No. 1-4, pp.

the Center for Advanced Studies on Collaborativeresearch, p. 18. IBM Corp．, 2006.

177-205, Springer, 2000.
[2] R．L．Glass. Facts and fallacies of software engi-[11] IEEE Computer Society． Software Engineering
StandardsCommittee, IEEE-SA Standards Board.

neering, Addison-Wesley Professional, 2002.

IEEE recommended practice for software requirements specifications, IEEE, 1998.

[3] A．J．Albrecht. Function point analysis. Encyclopedia of Software Engineering, Vol. 1, pp. 518524,Addison-Wesley Professional, 1994.

[12] IFPUG: Function Point Counting Practices Manual, Release 4．3. International Function Point[4] 総務省行政管理局. 政府情報システムの整備及び管Users Group, 2010.

理に関する標準ガイドライン実務手引書. 政府情報システムの整備及び管理に関する標準ガイドライン[13] C．R．Symons. Software sizing and estimating:Mk実務手引書, p. 122, 内閣官房情報通信技術 (IT) 総II FPA (function point analysis), John Wiley &Sons, Inc．, 1991.

合戦略室,2015.

[5] G．C．Low, D．R．Jeﬀery. Function points in theestimation and evaluation of the software process.

[14] 山口正明 (著) 調重俊 (監修) . ファンクションポイ
ント cosmic‐ ﬀp 法実践ガイド―組込み系・リアル157

SEA

ソフトウェア・シンポジウム2017 in 宮崎

タイム系に最適なソフトウェア規模・工数の見積り
方法, 日科技連出版社, 2007.

[15] 柏本隆志, 楠本真二, 井上克郎, 鈴木文音, 湯浦克彦, 津田道夫. イベントトレース図に基づく要求仕様書からのファンクションポイント計測手法. Vol.

41,No. 6, pp. 1895-1904, 2000.
[16] Cabocha/南瓜 https://taku910.github.io/cabocha/.
[17] 日本ファンクションポイントユーザ協会. ファンク
ションポイント計測コース演習編課題テキスト,2014.

[18] 山崎利治. 共通問題によるプログラム設計技法解説.
情報処理, Vol. 25, No. 9, p. 934, 1984.

[19] 経済調査会調査研究部第二調査研究室. Web サイト
制作費の見積りの現状と課題, 2015.
[20] CFPS 概 要. http://www.jfpug.gr.jp/app-def/S102/wp/?page id=1374.

158

SEA