エンタープライズ系ソフトウェア開発のための見積技法及びプロジェクト管理支援に関する研究

(1)

1

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

エンタープライズ系ソフトウェア開発

のための見積技法及び

プロジェクト管理支援に関する研究

大学院情報科学研究科

コンピュータサイエンス専攻

井上研究室

原田　晃

(2)

研究の背景

エンタープライズ系ソフトウェアとは

　・企業，行政機関の経営，活動，プロセスを支援するソフトウェア

特長

・多種多様である

・大規模である

・個別開発である

・プロジェクト型の開発である

・受託開発が多い

・業務知識は発注者である

　顧客側にある

課題

課題 1 ：開発委託時に開発すべき

　　　　ソフトウェアの機能仕様が曖昧

課題 2 ：開発規模，開発コスト，開発期間

　　　　の見積精度が低い

課題 3: 機能仕様の確定に時間がかかる

課題 4 ：プロジェクト管理が難しい

(3)

3

研究の目的・内容

目的：課題 2, 3, 4 の解決

1. _{早い段階での明確な根拠に基づいた}

　精度の高い見積技法の研究

2. _{大規模なプロジェクトのプロジェクト管理を}

　幅広く支援するシステムの研究

3. _{プロジェクト開始時には曖昧な機能要件を}

　早期に確定する技法の研究

ここを中心に

発表

要点のみを

発表

研究内容

・ファンクションポイント法を応用した早期見積法

・ WBS に基づくプロジェクト管理システム“プロナビ”

・“プロナビ”での進捗情報の自動収集

・ QFD を応用した機能仕様の早期確定技法

(4)

ファンクションポイント法を応用した

早期見積技法の提案とそのシステム化

(5)

5

見積の目的

見積時点



_{企画段階：予算化を目的に開発費，開発期間の非常に粗い}

　　　　　　　　概算．



_{開発の前段階： RFP を基にして開発規模，開発工数，開発費，}

　　　　　　　　開発期間を概算．



_{業務要件設計終了以降：信頼性，性能を含めた高い精度での}

　　　　　　　　開発規模，開発工数，開発費，開発期間の見積．

開発費，開発期間

の見積

開発規模，開発工数

の見積

(6)

開発規模の尺度

コード行数

　

・標準的な定義がない．

　・いろいろな種類の行が存在する．

　・再利用コードの測定が正確でない．

　・プログラマの技術レベルによる規模の差異が大きい．

　・高水準言語による見かけ上の生産性低下が起きる．

ファンクションポイント (FP)

　

・ソフトウェアの機能量をファンクションポイント (FP) という尺度で計測

　・ 1979 年に IBM の Albrecht によって考案

　・エンタープライズ系ソフトウェアの見積技法として標準になりつつある

(7)

7

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

ファンクションポイント法には IBM 法，ＳＰＲ

法， IFPUG 法等，数十種類の計測方法が存在．

現在は IFPUG 法が主流

ファンクションポイント (FP) ：処理系，ファイル系に関する

　　　　　　　５つの要素の重み付けの和

処理系要素

(

ﾄﾗﾝｻﾞｸｼｮﾝﾌｧﾝｸｼｮﾝ (TF))

　　・外部入力 (EI)

　　・外部出力 (EO)

　　・外部照会 (EQ)

ファイル系要素

(

_{データファンクション (DF))}

　　　・内部論理ファイル (ILF)

　　　・外部インタフェース

　　　　ファイル (EIF)

(8)

IFPUG

法の概要

Step1

_{：ファイル系要素（ DF ）の計測}

・

ILF

_{， EIF を抽出}

・ ILF, EIF の複雑度を高，中，低の 3 段階に設定

・複雑度はデータ項目数，レコード種類数で評価

Step2

_{：処理系要素 (TF) の計測}

　・ EI ， EO ， EQ を抽出

　・ EI, EO, EQ の複雑度を高，中，低の 3 段階に設定

　・複雑度は関連ファイル数，データ項目数で評価

Step3

_{： FP の算出}

低

中

高

計

ILF

X7

X10 X15

EIF

X5

X7

X10

EI

X3

X4

X6

EO

X4

X5

X7

EQ

X3

X4

X6

FP

の算出法

(9)

9 IFPUG

_法の課題

IFPUG

法の課題

・ EI, EO, EQ の抽出が難しい．　　　　　　　

　

（具体的な処理をイメージできない）

・複雑度の評価が難しい　　　　　　

・習熟者でないと難しい

・開発の前段階では設計書

　の記載レベルが粗く難しい

改善方法

　・具体的な処理をイメージできる処理系要素を豊富に定義

　・処理系要素，ファイル系要素の FP デフォルト値を設定することで

　　複雑度の評価作業を削除

要素見積法

(10)

要素見積法と IFPUG 法の比較

要素見積法

DF

・ IFPUG 法と同一

TF

・ 16 種類の具体的な処理系要素

　　（要素機能）

ex:

既存データ変更，一覧照会，

　　　明細照会

複雑度評価

・評価せず

　

ファイル系要素，処理系要素に

　 FP デフォルト値 (FP 単価 ) を設定

IFPUG

_法

DF

・ ILF,EIF の 3 種類

TF

・ EI,EO,EQ の 3 種類

複雑度評価

・ファイル系要素，処理系要素

　とも評価

(11)

11

要素機能一覧と FP 単価

要素

FP

_単

価

要素

FP

_単

価

要素

FP

_単

価

要素機能（トランザクションファンクション (TF) ）

更新系

画面出力系

その他出力系

新規登録

5 _{問合せ応答}

5 _帳票出力

6 既存データ変更

5 _一覧照会

5 CSV

出力

5 既存データ削除

4 _明細照会

5 _{その他データ出}

力

5 マスタメンテナ

ンス

12 _{計算結果表示}

6 他システムへの出

力

5 その他更新

6 _{更新のための照}

会

4 _－

_－

－

選択肢一覧

3 _－

_－

－

その他照会

5 _－

_－

データファンクション (DF)

ILF

8 EIF

5 _－

_－

(12)

FP

単価設定の考え方

1996

_{年～ 1998 年にかけての IFPUG 法での実測結果から}

FP

_{単価の平均値を算出し，それを参考に設定．}

実測による平均値

データファンクションの FP 単価

実測値を，そのまま適用

ファンクション

FP

_平均値

IFL

8 EIF

5 EI

5 EO

6 EQ

4

(13)

13

要素機能の FP 単価の設定

要素機能に含まれる TF(EI,EO,EQ) の出現頻度と FP 値から設定

設定例

新規登録： DF の更新があり EI が 1 回出現． EI の FP 値は実測値の平均を採用

既存データ削除： EI が 1 回出現．複雑度が低く， FP 値 4 を採用

問合せ応答： EO,EQ の出現確率は半々．実測値の平均を採用

新規登録

既存データ削除

問合せ応答

EI

_出現頻度

1.0

1.0 FP

_値

5

4 EO

_出現頻度

0.5 FP

_値

6 EQ

_出現頻度

0.5 FP

値

4 要素機能の FP 単価

5

4

5

(14)

要素機能の単価精度の評価

評価基準

　　　

偏差（ FP 単価 -FP 平均値 )/FP 平均値 ) ： -10% ～ +25%

　　　　　　　

FP

平均値は実測値

11 _{の要素機能については基準内}

基準外の要素機能

偏差

出現頻度

その他更新

57.9

1.8 更新のための照会

-16.7

1.9 その他照会

42.9

0.3 CSV

出力

51.5

2.7 出現頻度が少なく

妥当と評価

(15)

15

要素機能の FP 実測値

要素機能

個数

出現頻度 %

FP

合計

FP

比率 %

FP

平均値

FP

単価

FP

偏差 %

新規登録

580

11.8 2526

12.0

4.4

5

13.6 既存

ﾃﾞｰﾀ

変更

712

14.5 2980

14.2

4.2

5

19.0 既存

ﾃﾞｰﾀ

削除

439

9.0 1671

8.0

3.8

4

5.3 その他更新

87

1.8

334

1.6

3.8

6

57.9 問合せ応答

537

11.0 2362

11.2

4.4

5

13.6 一覧照会

567

11.5 2564

12.4

4.6

5

8.7 明細照会

131

2.7

692

3.3

5.3

5 -5.7

計算結果表示

12

0.2

61

0.3

5.1

6

17.6 更新の為の照会

94

1.9

455

2.2

4.8

4 -16.7

選択肢一覧

650

13.3 2045

9.7

3.1

3 -3.2

その他照会

17

0.3

59

0.3

3.5

5

42.9 帳票出力

586

12.0 3170

15.1

5.4

6

11.1 CSV

出力

133

2.7

433

2.1

3.3

5

51.5 その他

ﾃﾞｰﾀ

出力

294

6.0 1285

6.1

4.4

5

13.6 他

ｼｽﾃﾑ

への出力

61

1.2

329

1.6

5.4

5 -7.4

合計

4898

100.0 20996

100.0

65.5

74

221.8

(16)

要素機能の抽出精度の評価

評価方法

　

IFPUG

_{法，要素見積法で}

旅費精算ソフトの RFP から FP を算出

旅費精算ソフトの RFP

・事前に登録しておいた出張案件から

　精算したい案件を選択

・旅費に関する項目を入力し登録

・登録した内容を後で修正可

・領収書の提出等のために帳票を出力

　

IFPUG

_法

　

未習熟者が行うと過小見積になりやすい

要素見積法

　

未習熟者でも TF の抽出が容易

　計測速度が IFPUG 法の 3 ～ 5 倍速い

・ 2 段階の照会，修正の影に削除等

の行間にあるものを EI,EO,EQ か

ら想起するのは難しい

・ RFP から EO,EQ の判別が難しい

・複雑度評価が難しく時間がかかる

(17)

17

IFPUG

法による見積結果

未習熟者の見積

習熟者の見積

考え方

結果

(FP)

考え方

結果 (FP)

事前に登録しておいた出

張案件から精算したい案

件を選択

EQ×1

_{精算したい案件の選択は条件入力→}

候補一覧， 1 件選択→精算案件内容

表示の手順．ここに 2 つの照会が

存在し前者は計算を伴う可能性が高

いので EO と判断．

EO×1

EQ×1

旅費に関する事項を入力

し登録する

EI×1

文面どおり登録の TF があると判断

．

EI×1

登録した旅費精算の内容

を後で修正できる．

EI×1

修正するのは登録した内容の表示

が必要．そのために 2 段階の照会

が発生．

更に修正には削除機能が含まれる．

EO×1

EI×2

旅費精算書の帳票出力

EO×1

_{帳票出力には計算が伴うので EO と}

判断．

EO×1

17

36 EI,EO,EQ

の複雑度は“中”を仮定

(18)

要素見積法による見積結果

要素見積法での考え方

見積結果

(FP)

案件の選択とあるので案件を表示する明細照会を抽

｢

｣

出．明細照会があれば一覧照会があることを想起．

一覧照会

_明細照会

旅費精算の登録は新規登録．

新規登録

修正は既存データ変更になるが既存データ削除もある

と想起．更新の確認のための一覧照会，明細照会を想

起．

既存データ変更

既存データ削除

一覧照会

明細照会

帳票出力そのものが要素機能の中に存在．

帳票出力

40

(19)

19

要素見積法の精度評価

6 つのエンタープライズ系ソフトウェアで実測評価

・金融分野： 1 製造分野： 2 公共分野： 3

IFPUG

法での実測結果を 100 として

-4%

_{～ +11% の範囲内}

要素見積法が過大見積傾向になる考察

1. ﾃﾞｰﾀﾌｧﾝｸｼｮﾝ

の

FP

は 6 つとも過大

　・要素見積法での ILF の FP 値は 8 であるが，

　　 6 つの実測の平均値は 7.3

2. トランザクションファンクションの FP も 5 つで過大

　・要素機能の FP 値設定に用いた EI,EO,EQ の

　　 FP 値は IFPUG 法での複雑度“中”と“高”の

　　中間値であり， 6 つの実測の平均値より大

(20)

見積支援システム AP-Estimate

アクセス制御

見積結果管理部

見積 DB(RDB)

プロジェクト A

見積結果

Ver1

見積結果

Ｖｅｒ２

プロジェクト B

見積結果

Ver1

見積結果

Ver2

登

録

・

取

込

処

理

規模見積

TF

の

計測

DF

計測

の

バージョン比較

規模

比較処理

表示

処理

収集

分析

改善

AP-Estimate

サーバー

Intranet

ｸﾗｲｱﾝﾄ PC

ト

ｸﾗｲｱﾝ

PC

見積者

登録

取込

(21)

21

AP-Estimate

の利用状況

利用件数

金融系： 14 プロジェクト

製造系： 60 プロジェクト

利用者からのヒアリング結果

画面仕様が不明確な状況でも見積ができた．

見積作業を契機に仕様の不明確な箇所を顧客と詰めること

ができた．

業務に精通していなくても見積ができた．

見積根拠が明確になり顧客，社内の

ｽﾃｰｸﾎﾙﾀﾞｰ

からの理解

を得やすい．

大きな追加，変更の発生の度に見積をするので，トラッキ

ングコントロールができ，プロジェクト管理不良が低減

した．

(22)

まとめ

要素見積法の確立

精度が高い（ IFPUG 法の -4% ～ +11% の範囲）

仕様の明確でない開発の前段階でも要素機能の抽出が容易

複雑度の評価が不要なので計測速度が IFPUG 法の 3 ～ 5

倍速い

見積支援システム AP-Estimate の開発

見積作業を契機に仕様の不明確な箇所を顧客と詰めること

ができた．

見積根拠が明確になり顧客，社内の

ｽﾃｰｸﾎﾙﾀﾞｰ

からの理解

を得やすい．

大きな追加，変更の発生の度に見積をするので，トラッキ

ングコントロールができ，プロジェクト管理不良が低減

(23)

23

WBS

に基づく

(24)

「プロナビ」の必要性

人手でのプロジェクト管理が難しい

WBS

_{に基づくプロジェクト管理システム}

ソフト開発プロジェクトの特徴

・作業，成果物が膨大

・プロジェクトメンバが多い

・開発拠点が分散

・情報共有が難しい

　（計画，状況，成果物）

・利用する参考資料が膨大

プロナビ

・ WBS によるプロジェクトのモデル化

・工程，作業の階層化

・工程，作業，成果物，参考資料の

　相互関連付けと一元管理

・プロジェクト計画時の工程，作業，

　成果物の明確化

・プロジェクト進捗状況の把握

・プロジェクトメンバ間での成果物の共有

・規則，標準，ワークシート等の知識の活用

・プロセス，作業の標準化

(25)

25

標準プロナビ WBS

経営管理システム

従業員管理システム

経営管理システム

要求分析

業務要件設計ソフト方式設計

アーキテクチャ設計テスト計画ビジネスプロセス設計

処理方式設計

システム部品定義書

・・・

第 1 階層：プロジェクト

第 2 階層：サブプロジェクト

第 3 階層：フェーズ

第 4 階層：作業ステップ

第 5 階層：成果物

(26)

プロナビ WBS とプロジェクト計画

の対応

経営管理システム

従業員管理システム

WORK1

システム計画

WORK2

要求分析

WORK2.1

ビジネスプロセス分析

WORK2.1.1

業務用語集

前提ワーク

WORK1.1

参照する知識情報文書作成基準

ワークの計画 / 状

態

責任者：原田晃

_{開始予定日： 2004/4/5}

終了予定日： 2004/4/16

実績開始日： 2004/4/5

実績終了日：－

進捗状況：着手

成果物ファイル

成果物ファイル名：用語集

担当者：粟根達志

登録者：粟根達志

登録日時： 2004/4/9 10:00:00

情報付与

(27)

27

プロナビの構成

プロジェクト

情報 DB

成果物

DB

知識情報

DB

プロジェクト情報

管理部

成果物管理部

知識情報管理部

プロジェクト計画

策定

プロジェクト情報表示

project view

プロジェクト情報表示

project view

private view

成果物作成

知識情報

表示

プロナビ Web サーバ

クライアント PC

管理者

開発者

Intranet/Internet

(28)

28 プロナビを利用したプロジェクト管

理例

従来手法によるプロジェクト

管理

プロナビによるプロジェクト管理

管

理

者

進捗状況

の

把握

・開発者から進捗状況の報告を受

け，

　ガントチャートに記入

・ project view からﾜｰｸの進捗状況を

　把握．

・必要に応じて成果物 DB に格納され

てい　

　る成果物の内容を直接，確認

成果物の

管理

・電子ﾌｧｲﾙか印刷して決められた

DB

　か書棚で保管．最新の情報が洩

れ

　ることがある．

・成果物ﾌｧｲﾙとしてﾊﾞｰｼﾞｮﾝ番号が付

加さ

　れ成果物 DB に格納

開

発

者

作業，ｽｹｼ

確認

ﾞｭｰﾙ

・

ｶﾞﾝﾄﾁｬｰﾄ

から確認

・ project view から確認

成果物

作成

・前提ﾜｰｸの成果物や知識情報を

　参照し作成

・成果物や知識情報が保管されて

・ project view に表示された前提ﾜｰｸ

や

　知識情報の一覧から選択し内容を参

(29)

29

評価とまとめ

評価： 6 年間で 2000 を超えるプロジェクトで適用されており，アンケート結果や

　　　　プロマネへのヒアリング結果からプロジェクト管理を支援する有用な

　　　　システムと評価できる

アンケート結果

100 ﾌﾟﾛｼﾞｪｸﾄ

の管理者に

ｱﾝｹｰﾄ

し

109 人より回答

・ 95% の人が満足 ( 成果物の管理に満足 :34% ，分散拠点から利用に満足： 33% ）

評価項目

効　　　　　　　果

開発作業の高効率化・他の担当者が作成した最新の成果物を簡単に参照でき仕様の確認が容易になった

・作業手順，記述例等の知識情報を参照しながら作業できるので経験の浅い開発者

でも効率的に進めることができる

成果物の管理

・バージョン管理が行われているので , バージョンの間違いによる作業ミスがなく

なった

情報の共有化

・プロジェクトメンバ全員が常に同じ情報を即時に共有できた

・プロジェクト基準書，開発計画書のようなプロジェクト方針の周知徹底が簡単に

できた

進捗情報の把握

・進捗情報の把握，成果物の内容確認等の煩雑な作業を簡略化できた

・直接，成果物の内容を確認できるので，進捗状況を正確に把握できるようになっ

た

ヒアリング結果

(30)

(31)

31

WBS

モデルの変更

1.WBS

モデルへの機能階層の組込

・成果物の上位に機能階層を新設

・機能は大機能，中機能の 2 階層化

2. 成果物の状態定義

C-1

プロジェクト

C-1-1

サブブロジェクト

C-1-1-1

ソフトウェア方式設計

C-1-1-2

ソフトウェア詳細設計

C-1-1-2-1

大機能 1

C-1-1-2-1-1

中機能 11

C-1-1-2-1-1-1

プログラム仕様書

C-1-1-2-1-1-2

シーケンス図

状態

定義

更新者

着手

成果物の作成に着手した状態

担当者

作成完了

成果物の作成が完了した状況

担当者

QA

承認済

品質保証部門 (QA) が承認した状

態

品質保証部門

PM

承認済

プロマネが承認した状態

PM

顧客承認済顧客が承認した状態

PM

大機能

1 中機能

11 60(FP)

中機能

12 50(FP)

中機能

13 45(FP)

3.WBS

階層の状態定義

状態

定義

更新者

未完了当該階層以下の成果物が完了していない状態

PM

完了

当該階層以下の全成果物が完了した状態

PM

(32)

自動収集した進捗情報の出力例

工

程

大機能

中機能

FP

進

捗

階層の

状態

担

当

成果

物予

定数

成果物の状態

顧客

承認

済

PM

承認

済

QA

承認

済

作成

完了

着

手

ソ

フ

ト

詳

細

設

計

－

300

180 _未完了

B

80

70

73

78

78 大機能 1

－

180

60 _未完了

C

50

40

43

48

50

50 中機能

11

60

60 完了

D

15

15 中機能

12

65

0 未完了

E

25

20

25

25 中機能

13

55

0 未完了

F

10

5

8

8 大機能 2

－

120

120 _完了

G

30

(33)

33

QFD

を応用した機能仕様の

早期確定技法「仕様発散防止

QFD

」

(34)

仕様発散防止 QFD の概要

目的　重要度，難易度が高く，遅延した時の影響が大きい機能の

　　　　仕様を早期に確定する

Step1:

_{ユーザニーズを反映した機能の優先順位付け（機能重要度）}

エンタープライズ系ソフトウェア開発のための見積技法及びプロジェクト管理支援に関する研究

1

エンタープライズ系ソフトウェア開発

のための見積技法及び

プロジェクト管理支援に関する研究

大学院情報科学研究科

コンピュータサイエンス専攻

井上研究室

原田 晃

研究の背景

エンタープライズ系ソフトウェアとは

・企業，行政機関の経営，活動，プロセスを支援するソフトウェア

特長

・多種多様である

・大規模である

・個別開発である

・プロジェクト型の開発である

・受託開発が多い

・業務知識は発注者である

顧客側にある

課題

課題 1 ：開発委託時に開発すべき

ソフトウェアの機能仕様が曖昧

課題 2 ：開発規模，開発コスト，開発期間

の見積精度が低い

課題 3: 機能仕様の確定に時間がかかる

課題 4 ：プロジェクト管理が難しい

3

研究の目的・内容

目的：課題 2, 3, 4 の解決

1.

早い段階での明確な根拠に基づいた

精度の高い見積技法の研究

2.

大規模なプロジェクトのプロジェクト管理を

幅広く支援するシステムの研究

3.

プロジェクト開始時には曖昧な機能要件を

早期に確定する技法の研究

ここを中心に

発表

要点のみを

発表

研究内容

・ファンクションポイント法を応用した早期見積法

・ WBS に基づくプロジェクト管理システム“プロナビ”

・“プロナビ”での進捗情報の自動収集

・ QFD を応用した機能仕様の早期確定技法

ファンクションポイント法を応用した

早期見積技法の提案とそのシステム化

5

見積の目的

見積時点



企画段階：予算化を目的に開発費，開発期間の非常に粗い

概算．



開発の前段階： RFP を基にして開発規模，開発工数，開発費，

開発期間を概算．



業務要件設計終了以降：信頼性，性能を含めた高い精度での

開発規模，開発工数，開発費，開発期間の見積．

開発費，開発期間

の見積

開発規模，開発工数

の見積

開発規模の尺度

コード行数

・標準的な定義がない．

・いろいろな種類の行が存在する．

・再利用コードの測定が正確でない．

・プログラマの技術レベルによる規模の差異が大きい．

・高水準言語による見かけ上の生産性低下が起きる．

ファンクションポイント (FP)

・ソフトウェアの機能量をファンクションポイント (FP) という尺度で計測

・ 1979 年に IBM の Albrecht によって考案

・エンタープライズ系ソフトウェアの見積技法として標準になりつつある

7

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

ファンクションポイント法には IBM 法，ＳＰＲ

原田　晃

　・企業，行政機関の経営，活動，プロセスを支援するソフトウェア

　顧客側にある

　　　　ソフトウェアの機能仕様が曖昧

　　　　の見積精度が低い

_{早い段階での明確な根拠に基づいた}

　精度の高い見積技法の研究

_{大規模なプロジェクトのプロジェクト管理を}

　幅広く支援するシステムの研究

_{プロジェクト開始時には曖昧な機能要件を}

　早期に確定する技法の研究

_{企画段階：予算化を目的に開発費，開発期間の非常に粗い}

　　　　　　　　概算．

_{開発の前段階： RFP を基にして開発規模，開発工数，開発費，}

　　　　　　　　開発期間を概算．

_{業務要件設計終了以降：信頼性，性能を含めた高い精度での}

　　　　　　　　開発規模，開発工数，開発費，開発期間の見積．

　・いろいろな種類の行が存在する．

　・再利用コードの測定が正確でない．

　・プログラマの技術レベルによる規模の差異が大きい．

　・高水準言語による見かけ上の生産性低下が起きる．

　・ 1979 年に IBM の Albrecht によって考案

　・エンタープライズ系ソフトウェアの見積技法として標準になりつつある

ファンクションポイント (FP) ：処理系，ファイル系に関する

　　　　　　　５つの要素の重み付けの和

　　・外部入力 (EI)

　　・外部出力 (EO)

　　・外部照会 (EQ)

_{データファンクション (DF))}

　　　・内部論理ファイル (ILF)

　　　・外部インタフェース

　　　　ファイル (EIF)

_{：ファイル系要素（ DF ）の計測}

_{， EIF を抽出}

_{：処理系要素 (TF) の計測}

　・ EI ， EO ， EQ を抽出

　・ EI, EO, EQ の複雑度を高，中，低の 3 段階に設定

　・複雑度は関連ファイル数，データ項目数で評価

_{： FP の算出}

_法の課題

・ EI, EO, EQ の抽出が難しい．　　　　　　　

・複雑度の評価が難しい　　　　　　