エンタープライズ系ソフトウェア開発のための見積技法及び...

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

エンタープライズ系ソフトウェア開発のための見積技法及び

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

大学院情報科学研究科コンピュータサイエンス専攻

井上研究室原田　晃


研究の背景エンタープライズ系ソフトウェアとは　・企業，行政機関の経営，活動，プロセスを支援するソフトウェア

特長・多種多様である・大規模である・個別開発である・プロジェクト型の開発である・受託開発が多い・業務知識は発注者である　顧客側にある

課題課題 1 ：開発委託時に開発すべき　　　　ソフトウェアの機能仕様が曖昧課題 2 ：開発規模，開発コスト，開発期間　　　　の見積精度が低い課題 3: 機能仕様の確定に時間がかかる課題 4 ：プロジェクト管理が難しい


研究の目的・内容目的：課題 2, 3, 4 の解決 1. 早い段階での明確な根拠に基づいた　精度の高い見積技法の研究 2. 大規模なプロジェクトのプロジェクト管理を　幅広く支援するシステムの研究 3. プロジェクト開始時には曖昧な機能要件を　早期に確定する技法の研究

ここを中心に発表

要点のみを発表

研究内容・ファンクションポイント法を応用した早期見積法・ WBS に基づくプロジェクト管理システム“プロナビ”・“プロナビ”での進捗情報の自動収集・ QFD を応用した機能仕様の早期確定技法


ファンクションポイント法を応用した早期見積技法の提案とそのシステム化


見積の目的

見積時点企画段階：予算化を目的に開発費，開発期間の非常に粗い　　　　　　　　概算．開発の前段階： RFP を基にして開発規模，開発工数，開発費，　　　　　　　　開発期間を概算．業務要件設計終了以降：信頼性，性能を含めた高い精度での　　　　　　　　開発規模，開発工数，開発費，開発期間の見積．

開発費，開発期間の見積

開発規模，開発工数の見積


開発規模の尺度コード行数　・標準的な定義がない．　・いろいろな種類の行が存在する．　・再利用コードの測定が正確でない．　・プログラマの技術レベルによる規模の差異が大きい．　・高水準言語による見かけ上の生産性低下が起きる．

ファンクションポイント (FP)　・ソフトウェアの機能量をファンクションポイント (FP) という尺度で計測　・ 1979 年に IBM の Albrecht によって考案　・エンタープライズ系ソフトウェアの見積技法として標準になりつつある

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


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

ファンクションポイント法には IBM 法，ＳＰＲ法， IFPUG 法等，数十種類の計測方法が存在．現在は IFPUG 法が主流

ファンクションポイント (FP) ：処理系，ファイル系に関する　　　　　　　　　　　　　　　　　５つの要素の重み付けの和

処理系要素( ﾄﾗﾝｻﾞｸｼｮﾝﾌｧﾝｸｼｮﾝ (TF))

　　・外部入力 (EI)

　　・外部出力 (EO)

　　・外部照会 (EQ)

ファイル系要素( データファンクション (DF))

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

　　　・外部インタフェース　　　　ファイル (EIF)


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

FP の算出法


IFPUG 法の課題

IFPUG 法の課題

・ EI, EO, EQ の抽出が難しい．　　　　　　　　（具体的な処理をイメージできない）・複雑度の評価が難しい　　　　　　

・習熟者でないと難しい・開発の前段階では設計書　の記載レベルが粗く難しい

改善方法　・具体的な処理をイメージできる処理系要素を豊富に定義　・処理系要素，ファイル系要素の FP デフォルト値を設定することで　　複雑度の評価作業を削除

要素見積法


要素見積法と IFPUG 法の比較

要素機能：画面上の GUI ボタン，ファンクションキーを押すことで実行される　　　　　　　　具体的な処理 . ユーザ視点での入出力の最小単位 .

要素見積法DF ・ IFPUG 法と同一TF ・ 16 種類の具体的な処理系要素　　（要素機能） ex:既存データ変更，一覧照会，　　　明細照会複雑度評価・評価せず　ファイル系要素，処理系要素に　 FP デフォルト値 (FP単価 ) を設定

IFPUG 法DF ・ ILF,EIF の 3 種類TF ・ EI,EO,EQ の 3 種類

複雑度評価・ファイル系要素，処理系要素　とも評価


要素機能一覧と 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 －－


FP 単価設定の考え方1996 年～ 1998 年にかけての IFPUG 法での実測結果からFP 単価の平均値を算出し，それを参考に設定．

実測による平均値

データファンクションの FP 単価実測値を，そのまま適用

ファンクション FP平均値IFL 8

EIF 5

EI 5

EO 6

EQ 4


要素機能の 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


要素機能の単価精度の評価評価基準　　　偏差（ FP 単価 -FP 平均値 )/FP 平均値 ) ： -10% ～ +25%　　　　　　　　　　　　　　　　　　　　　　　　　 FP 平均値は実測値

11 の要素機能については基準内基準外の要素機能

偏差出現頻度

その他更新 57.9 1.8

更新のための照会 -16.7 1.9

その他照会 42.9 0.3

CSV 出力 51.5 2.7

出現頻度が少なく妥当と評価


要素機能の 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


要素機能の抽出精度の評価評価方法　 IFPUG 法，要素見積法で旅費精算ソフトの RFP から FP を算出

旅費精算ソフトの RFP・事前に登録しておいた出張案件から　精算したい案件を選択・旅費に関する項目を入力し登録・登録した内容を後で修正可・領収書の提出等のために帳票を出力

　

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

要素見積法　未習熟者でも TF の抽出が容易　計測速度が IFPUG 法の 3～ 5倍速い

・ 2 段階の照会，修正の影に削除等の行間にあるものを EI,EO,EQ から想起するのは難しい・ RFP から EO,EQ の判別が難しい・複雑度評価が難しく時間がかかる


IFPUG 法による見積結果未習熟者の見積習熟者の見積考え方結果

(FP)考え方結果 (FP)

事前に登録しておいた出張案件から精算したい案件を選択

EQ×1 精算したい案件の選択は条件入力→候補一覧， 1 件選択→精算案件内容表示の手順．ここに 2 つの照会が存在し前者は計算を伴う可能性が高いので EO と判断．

EO×1EQ×1

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

EI×1 文面どおり登録の TF があると判断． EI×1

登録した旅費精算の内容を後で修正できる．

EI×1 修正するのは登録した内容の表示が必要．そのために 2 段階の照会が発生．更に修正には削除機能が含まれる．

EO×1EO×1EI×2

旅費精算書の帳票出力 EO×1 帳票出力には計算が伴うので EO と判断．

EO×1

17 36

EI,EO,EQ の複雑度は“中”を仮定


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

要素見積法での考え方見積結果(FP)

｢案件の選択｣とあるので案件を表示する明細照会を抽出．明細照会があれば一覧照会があることを想起．

一覧照会明細照会

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

修正は既存データ変更になるが既存データ削除もあると想起．更新の確認のための一覧照会，明細照会を想起．

既存データ変更既存データ削除

一覧照会明細照会

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


要素見積法の精度評価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 つの実測の平均値より大

85

90

95

100

105

110

115

Pj1 Pj2 Pj3 Pj4 Pj5 Pj6

FP計DF FPTF FP


見積支援システム AP-Estimate

アクセス制御

見積結果管理部

見積 DB(RDB)

プロジェクト A

見積結果Ver1

見積結果Ｖｅｒ２

プロジェクト B見積結果

Ver1見積結果

Ver2

登録・取込処理

規模見積TF の計測

DF の計測

バージョン比較規模比較処理

表示処理

収集分析改善

AP-EstimateサーバーIntranet

ｸﾗｲｱﾝﾄ PC

ｸﾗｲｱﾝト PC

見積者

生産管理部門

登録

取込


AP-Estimate の利用状況利用件数金融系： 14 プロジェクト製造系： 60 プロジェクト

利用者からのヒアリング結果画面仕様が不明確な状況でも見積ができた．見積作業を契機に仕様の不明確な箇所を顧客と詰めることができた．業務に精通していなくても見積ができた．見積根拠が明確になり顧客，社内のｽﾃｰｸﾎﾙﾀﾞｰからの理解を得やすい．大きな追加，変更の発生の度に見積をするので，トラッキングコントロールができ，プロジェクト管理不良が低減した．


まとめ要素見積法の確立

精度が高い（ IFPUG 法の -4%～ +11% の範囲）仕様の明確でない開発の前段階でも要素機能の抽出が容易複雑度の評価が不要なので計測速度が IFPUG 法の 3～ 5倍速い

見積支援システム AP-Estimate の開発見積作業を契機に仕様の不明確な箇所を顧客と詰めることができた．見積根拠が明確になり顧客，社内のｽﾃｰｸﾎﾙﾀﾞｰからの理解を得やすい．大きな追加，変更の発生の度に見積をするので，トラッキングコントロールができ，プロジェクト管理不良が低減した．


WBS に基づくプロジェクト管理システムの実現


「プロナビ」の必要性

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

WBS に基づくプロジェクト管理システム「プロナビ」を開発

ソフト開発プロジェクトの特徴・作業，成果物が膨大・プロジェクトメンバが多い・開発拠点が分散・情報共有が難しい　（計画，状況，成果物）・利用する参考資料が膨大

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

・工程，作業の階層化・工程，作業，成果物，参考資料の　相互関連付けと一元管理

・プロジェクト計画時の工程，作業，　成果物の明確化・プロジェクト進捗状況の把握・プロジェクトメンバ間での成果物の共有・規則，標準，ワークシート等の知識の活用・プロセス，作業の標準化


標準プロナビWBS

経営管理システム

従業員管理システム経営管理システム

要求分析業務要件設計ソフト方式設計

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

処理方式設計システム部品定義書

・・・

・・・

・・・

・・・

第 1 階層：プロジェクト

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

第 3 階層：フェーズ

第 4 階層：作業ステップ

第 5 階層：成果物


プロナビ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

更新日時： 2004/4/16 15:00:00

バージョン番号： 2

進捗状況：顧客レビュー中

情報付与


プロナビの構成

プロジェクト情報 DB

成果物DB

知識情報DB

プロジェクト情報管理部

成果物管理部

知識情報管理部

プロジェクト計画策定

プロジェクト情報表示project view

プロジェクト情報表示project view

private view

成果物作成

知識情報表示

プロナビ Webサーバクライアント PC

クライアント PC

管理者

開発者

Intranet/Internet


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

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

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

管理者

進捗状況の把握

・開発者から進捗状況の報告を受け，　ガントチャートに記入

・ project view からの進捗状況をﾜｰｸ　把握．・必要に応じて成果物 DB に格納されてい　　る成果物の内容を直接，確認

成果物の管理

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

　か書棚で保管．最新の情報が洩れ　ることがある．

・成果物として番号が付ﾌｧｲﾙﾊﾞｰｼﾞｮﾝ加さ　れ成果物 DB に格納

開発者

作業，ｽｹｼﾞｭｰﾙ確認

・ｶﾞﾝﾄﾁｬｰﾄから確認・ project view から確認

成果物作成

・前提の成果物や知識情報をﾜｰｸ　参照し作成・成果物や知識情報が保管されている場所から探し出すために負荷が大

・ project view に表示された前提ﾜｰｸや　知識情報の一覧から選択し内容を参照・一覧表示される資料は WBS のﾜｰｸと対　応づいており探す負荷は殆どない


評価とまとめ評価： 6 年間で 2000 を超えるプロジェクトで適用されており，アンケート結果や　　　　プロマネへのヒアリング結果からプロジェクト管理を支援する有用な　　　　システムと評価できるアンケート結果100 ﾌﾟﾛｼﾞｪｸﾄの管理者にｱﾝｹｰﾄし 109人より回答・ 95% の人が満足 (成果物の管理に満足 :34% ，分散拠点から利用に満足： 33% ）

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

・作業手順，記述例等の知識情報を参照しながら作業できるので経験の浅い開発者でも効率的に進めることができる

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

情報の共有化・プロジェクトメンバ全員が常に同じ情報を即時に共有できた・プロジェクト基準書，開発計画書のようなプロジェクト方針の周知徹底が簡単にできた

進捗情報の把握・進捗情報の把握，成果物の内容確認等の煩雑な作業を簡略化できた・直接，成果物の内容を確認できるので，進捗状況を正確に把握できるようになった

ヒアリング結果


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


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


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

工程

大機能中機能 FP 進捗

階層の状態担

当

成果物予定数

成果物の状態顧客承認済

PM承認済

QA承認済

作成完了

着手

ソフト詳細設計

－－ 300 180 未完了 B 80 70 73 78 78 78

大機能 1 － 180 60 未完了 C 50 40 43 48 50 50

中機能11

60 60 完了 D 15 15 15 15 15 15

中機能12

65 0 未完了 E 25 20 20 25 25 25

中機能13

55 0 未完了 F 10 5 8 8 8 8

大機能 2 － 120 120 完了 G 30 30 30 30 30 30


QFD を応用した機能仕様の早期確定技法「仕様発散防止

QFD」


仕様発散防止 QFD の概要目的　重要度，難易度が高く，遅延した時の影響が大きい機能の　　　　仕様を早期に確定する

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

Step2: 機能複雑度評価による開発前の　　　　潜在リスクの見極め　　

Step3:危険度評価による開発着手後の　　　　リスク監視

評価項目業務特性システムインターフェース有無接続マシンの新規性マンマシンインターフェース他業務との連携の度合

評価項目業務仕様提示度合懸案事項残存率 (%)


仕様発散防止 QFD の例

機能重要度

機能複雑度

危険度評価 (1 回目 ) 危険度評価 (2 回目 )

機能一覧業務仕様提示

度

懸案残存率

危険度

業務仕様提示

度

懸案残存率

危険度

A業務

A1申請 284 640 × 20 128 ○ 10 4

A2 参照・更新

284 640 × 40 200 ○ 16 6

A3 書出力 83 140 × 30 25 △ 40 75

A4 票出力 83 140 △ 15 7 ○ 35 12

B業務

B1 ﾃﾞｰﾀ参照 89 133 △ 10 2 ○ 10 1

B2 ﾃﾞｰﾀ参照 89 340 ○ 15 3 ○ 15 3

B3 更新 174 73 ○ 20 3 ○ 20 3

B4 参照 32 133 △ 25 11 ○ 20 4

仕様を早く決定すべき対策の結果 , 仕様を早期に決定


むすび研究成果1. 要素見積法の確立・開発の前段階でも精度が高く計測も速い・精度は IFPUG 法の -4%～ +11% の範囲・計測速度は 3～ 5倍速い2.WBS に基づくプロジェクト管理システム　“プロナビ”の開発・ 2000 を超えるﾌﾟﾛｼﾞｪｸﾄで適用実績・ 109人のﾌﾟﾛﾏﾈへのｱﾝｹｰﾄで 95% が満足と回答・成果物管理，進捗情報の把握，情報の共有化，　開発作業の効率化で効果大3.QFD を応用した機能仕様の早期確定技法の確立・仕様の確定状況を QFD を応用して数値化・数値の悪い機能から対策することで仕様の早期　確定を支援

今後の研究方針1.COCOMOⅡ の改善・ AP-Estimate とﾌﾟﾛﾅﾋﾞが連携して，開発　規模、工数、期間を計画から終了までを　ﾄﾚｰｽし，ﾃﾞｰﾀを蓄積・蓄積されたﾃﾞｰﾀを分析することにより　開発規模、工数、期間の相関関係を　指標化

2. ｿﾌﾄｳｪｱ生産性、品質の指標化・ EASE ﾌﾟﾛｼﾞｪｸﾄでの EPM、 AP-Estimate,

ﾌﾟﾛﾅﾋﾞで収集、蓄積したﾃﾞｰﾀの分析によるｿﾌﾄｳｪｱ生産性、品質に関する指標の設定

エンタープライズ系ソフトウェア開発 のための見積技法及び...

Documents

エンタープライズ系ソフトウェア開発のための見積技法及び...