Transcript FP - Software Engineering Laboratory

エンタープライズ系ソフトウェア開発
のための見積技法及び
プロジェクト管理支援に関する研究
大学院情報科学研究科
コンピュータサイエンス専攻
井上研究室
原田 晃
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
1
研究の背景
エンタープライズ系ソフトウェアとは
・企業，行政機関の経営，活動，プロセスを支援するソフトウェア
特長
課題
・多種多様である
・大規模である
・個別開発である
・プロジェクト型の開発である
・受託開発が多い
・業務知識は発注者である
顧客側にある
課題1：開発委託時に開発すべき
ソフトウェアの機能仕様が曖昧
課題2：開発規模，開発コスト，開発期間
の見積精度が低い
課題3:機能仕様の確定に時間がかかる
課題4：プロジェクト管理が難しい
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
2
研究の目的・内容
目的：課題2, 3, 4の解決
1.早い段階での明確な根拠に基づいた
精度の高い見積技法の研究
2.大規模なプロジェクトのプロジェクト管理を
幅広く支援するシステムの研究
3.プロジェクト開始時には曖昧な機能要件を
早期に確定する技法の研究
研究内容
・ファンクションポイント法を応用した早期見積法
・WBSに基づくプロジェクト管理システム“プロナビ”
・“プロナビ”での進捗情報の自動収集
・QFDを応用した機能仕様の早期確定技法
ここを中心に
発表
要点のみを
発表
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3
ファンクションポイント法を応用した
早期見積技法の提案とそのシステム化
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
4
見積の目的
開発規模，開発工数
の見積
開発費，開発期間
の見積
見積時点
企画段階：予算化を目的に開発費，開発期間の非常に粗い
概算．
開発の前段階：RFPを基にして開発規模，開発工数，開発費，
開発期間を概算．
業務要件設計終了以降：信頼性，性能を含めた高い精度での
開発規模，開発工数，開発費，開発期間の見積．
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
5
開発規模の尺度
コード行数
・標準的な定義がない．
・いろいろな種類の行が存在する．
・再利用コードの測定が正確でない．
・プログラマの技術レベルによる規模の差異が大きい．
・高水準言語による見かけ上の生産性低下が起きる．
ファンクションポイント(FP)
・ソフトウェアの機能量をファンクションポイント(FP)という尺度で計測
・1979年にIBMのAlbrechtによって考案
・エンタープライズ系ソフトウェアの見積技法として標準になりつつある
ファンクションポイント法
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
ファンクションポイント法
ファンクションポイント(FP) ： 処理系，ファイル系に関する
５つの要素の重み付けの和
ファイル系要素
(データファンクション(DF))
・内部論理ファイル(ILF)
・外部インタフェース
ファイル(EIF)
処理系要素
(ﾄﾗﾝｻﾞｸｼｮﾝﾌｧﾝｸｼｮﾝ(TF))
・外部入力(EI)
・外部出力(EO)
・外部照会(EQ)
ファンクションポイント法にはIBM法，ＳＰＲ法，IFPUG法等，
数十種類の計測方法が存在．
現在はIFPUG法が主流
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
7
IFPUG法の概要
Step1：ファイル系要素（DF）の計測
・ILF，EIFを抽出
・ILF, EIFの複雑度を高，中，低の3段階に設定
・複雑度はデータ項目数，レコード種類数で評価
Step2：処理系要素 (TF)の計測
・EI，EO，EQを抽出
・EI, EO, EQの複雑度を高，中，低の3段階に設定
・複雑度は関連ファイル数，データ項目数で評価
Step3：FPの算出
FPの算出法
低
中
高
ILF
X7
X10
X15
EIF
X5
X7
X10
EI
X3
X4
X6
EO
X4
X5
X7
EQ
X3
X4
X6
計
FP
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
8
IFPUG法の課題
IFPUG法の課題
・EI, EO, EQの抽出が難しい．
（具体的な処理をイメージできない）
・複雑度の評価が難しい
・習熟者でないと難しい
・開発の前段階では設計書
の記載レベルが粗く難しい
改善方法
・具体的な処理をイメージできる処理系要素を豊富に定義
・処理系要素，ファイル系要素のFPデフォルト値を設定することで
複雑度の評価作業を削除
要素見積法
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
9
要素見積法とIFPUG法の比較
要素見積法
DF
・IFPUG法と同一
TF
・16種類の具体的な処理系要素
（要素機能）
IFPUG法
DF
・ILF,EIFの3種類
TF
・EI,EO,EQの3種類
ex:既存データ変更，一覧照会，
明細照会
複雑度評価
・評価せず
ファイル系要素，処理系要素に
FPデフォルト値(FP単価)を設定
複雑度評価
・ファイル系要素，処理系要素
とも評価
要素機能：画面上のGUIボタン，ファンクションキーを押すことで実行される
具体的な処理.ユーザ視点での入出力の最小単位.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
10
要素機能一覧と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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
11
FP単価設定の考え方
1996年～1998年にかけてのIFPUG法での実測結果からFP単
価の平均値を算出し，それを参考に設定．
実測による平均値
ファンクション
FP平均値
IFL
8
EIF
5
EI
5
EO
6
EQ
4
データファンクションのFP単価
実測値を，そのまま適用
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
12
要素機能のFP単価の設定
要素機能に含まれるTF(EI,EO,EQ)の出現頻度とFP値から設定
設定例
EI
EO
EQ
新規登録
既存データ削除
出現頻度
1.0
1.0
FP値
5
4
問合せ応答
出現頻度
0.5
FP値
6
出現頻度
0.5
FP値
4
要素機能のFP単価
5
4
5
新規登録：DFの更新がありEIが1回出現．EIのFP値は実測値の平均を採用
既存データ削除：EIが1回出現．複雑度が低く，FP値4を採用
問合せ応答：EO,EQの出現確率は半々．実測値の平均を採用
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
13
要素機能の単価精度の評価
評価基準
偏差（FP単価-FP平均値)/FP平均値)：-10%～+25%
FP平均値は実測値
11の要素機能については基準内
基準外の要素機能
偏差
出現頻度
その他更新
57.9
1.8
更新のための照会
-16.7
1.9
その他照会
42.9
0.3
CSV出力
51.5
2.7
出現頻度が少なく
妥当と評価
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
14
要素機能の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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
15
要素機能の抽出精度の評価
評価方法
IFPUG法，要素見積法で
旅費精算ソフトのRFPからFPを算出
IFPUG法
未習熟者が行うと過小見積になりやすい
要素見積法
旅費精算ソフトのRFP
・事前に登録しておいた出張案件から
精算したい案件を選択
・旅費に関する項目を入力し登録
・登録した内容を後で修正可
・領収書の提出等のために帳票を出力
・2段階の照会，修正の影に削除等
の行間にあるものをEI,EO,EQか
ら想起するのは難しい
・RFPからEO,EQの判別が難しい
・複雑度評価が難しく時間がかかる
未習熟者でもTFの抽出が容易
計測速度がIFPUG法の3～5倍速い
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
16
IFPUG法による見積結果
未習熟者の見積
考え方
習熟者の見積
結果(FP)
考え方
結果(FP)
事前に登録しておいた出
張案件から精算したい案
件を選択
EQ×1
EO×1
EQ×1
旅費に関する事項を入力
し登録する
登録した旅費精算の内容
を後で修正できる．
EI×1
精算したい案件の選択は条件入力→
候補一覧，1件選択→精算案件内容
表示の手順．ここに2つの照会が存在
し前者は計算を伴う可能性が高いので
EOと判断．
文面どおり登録のTFがあると判断．
EI×1
EO×1
修正するのは登録した内容の表示が
必要．そのために2段階の照会が発生． EO×1
更に修正には削除機能が含まれる．
EI×2
旅費精算書の帳票出力
EO×1
帳票出力には計算が伴うのでEOと判
断．
EI×1
EO×1
17
36
EI,EO,EQの複雑度は“中”を仮定
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
17
要素見積法による見積結果
要素見積法での考え方
見積結果(FP)
｢案件の選択｣とあるので案件を表示する明細照会を抽出．
明細照会があれば一覧照会があることを想起．
一覧照会
明細照会
旅費精算の登録は新規登録．
新規登録
修正は既存データ変更になるが既存データ削除もあると想
起．更新の確認のための一覧照会，明細照会を想起．
既存データ変更
既存データ削除
一覧照会
明細照会
帳票出力そのものが要素機能の中に存在．
帳票出力
40
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
18
要素見積法の精度評価
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つの実測の平均値より大
115
110
105
100
95
FP計
DF FP
TF FP
90
85
Pj1
Pj2
Pj3
Pj4
Pj5
Pj6
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
19
見積支援システムAP-Estimate
ｸﾗｲｱﾝﾄPC
AP-Estimateサーバー
Intranet
アクセス制御
登録
見積結果管理部
取込
登
録
・
取
込
処
理
見積DB(RDB)
規模見積
TFの
計測
バージョン比較
規模
比較処理
表示
処理
見積者
ｸﾗｲｱﾝトPC
プロジェクトA
見積結果
Ver1
DFの
計測
見積結果
Ｖｅｒ２
プロジェクトB
見積結果 見積結果
Ver1
Ver2
収集
分析
改善
生産管理部門
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
20
AP-Estimateの利用状況
利用件数
金融系：14プロジェクト
製造系：60プロジェクト
利用者からのヒアリング結果
画面仕様が不明確な状況でも見積ができた．
見積作業を契機に仕様の不明確な箇所を顧客と詰めること
ができた．
業務に精通していなくても見積ができた．
見積根拠が明確になり顧客，社内のｽﾃｰｸﾎﾙﾀﾞｰからの理解
を得やすい．
大きな追加，変更の発生の度に見積をするので，トラッキング
コントロールができ，プロジェクト管理不良が低減した．
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
21
まとめ
要素見積法の確立
精度が高い（IFPUG法の-4%～+11%の範囲）
仕様の明確でない開発の前段階でも要素機能の抽出が容易
複雑度の評価が不要なので計測速度がIFPUG法の3～5倍
速い
見積支援システムAP-Estimateの開発
見積作業を契機に仕様の不明確な箇所を顧客と詰めること
ができた．
見積根拠が明確になり顧客，社内のｽﾃｰｸﾎﾙﾀﾞｰからの理解
を得やすい．
大きな追加，変更の発生の度に見積をするので，トラッキング
コントロールができ，プロジェクト管理不良が低減した．
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
22
WBSに基づく
プロジェクト管理システムの実現
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
23
「プロナビ」の必要性
ソフト開発プロジェクトの特徴
プロナビ
・作業，成果物が膨大
・プロジェクトメンバが多い
・開発拠点が分散
・情報共有が難しい
（計画，状況，成果物）
・利用する参考資料が膨大
・WBSによるプロジェクトのモデル化
人手でのプロジェクト管理が難しい
WBSに基づくプロジェクト管理システム
「プロナビ」を開発
・工程，作業の階層化
・工程，作業，成果物，参考資料の
相互関連付けと一元管理
・プロジェクト計画時の工程，作業，
成果物の明確化
・プロジェクト進捗状況の把握
・プロジェクトメンバ間での成果物の共有
・規則，標準，ワークシート等の知識の活用
・プロセス，作業の標準化
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
24
標準プロナビWBS
第1階層：プロジェクト
経営管理システム
従業員管理システム
要求分析
経営管理システム
業務要件設計
アーキテクチャ設計
処理方式設計
ソフト方式設計
テスト計画
・・・
第2階層：サブプロジェクト
・・・
第3階層：フェーズ
ビジネスプロセス設計
システム部品定義書
・・・
・・・
第4階層：作業ステップ
第5階層：成果物
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
25
プロナビWBSとプロジェクト計画の対応
前提ワーク
WORK1.1
経営管理システム
参照する知識情報
文書作成基準
従業員管理システム
ワークの計画/状態
責任者：原田晃
開始予定日：2004/4/5
WORK1
システム計画
WORK2
要求分析
終了予定日：2004/4/16
情報付与
実績開始日：2004/4/5
実績終了日：－
WORK2.1
ビジネスプロセス分析
進捗状況：着手
成果物ファイル
成果物ファイル名：用語集
担当者：粟根達志
WORK2.1.1
業務用語集
登録者：粟根達志
登録日時：2004/4/9 10:00:00
更新日時：2004/4/16 15:00:00
バージョン番号：2
進捗状況：顧客レビュー中
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
26
プロナビの構成
クライアントPC
プロナビWebサーバ
プロジェクト計画
策定
プロジェクト
情報DB
プロジェクト情報
管理部
成果物
DB
成果物管理部
管理者
プロジェクト情報表示
project view
クライアントPC
プロジェクト情報表示
project view
private view
知識情報管理部
知識情報
DB
開発者
成果物作成
知識情報
表示
Intranet/Internet
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
27
プロナビを利用したプロジェクト管理例
従来手法によるプロジェクト管理
管
理
者
プロナビによるプロジェクト管理
進捗状況
の
把握
・開発者から進捗状況の報告を受け， ・project viewからﾜｰｸの進捗状況を
ガントチャートに記入
把握．
・必要に応じて成果物DBに格納されてい
る成果物の内容を直接，確認
成果物の
管理
・電子ﾌｧｲﾙか印刷して決められた
DB
か書棚で保管．最新の情報が洩れ
ることがある．
作業，ｽｹ ・ｶﾞﾝﾄﾁｬｰﾄから確認
開 ｼﾞｭｰﾙ確認
発
・前提ﾜｰｸの成果物や知識情報を
成果物
者
参照し作成
作成
・成果物ﾌｧｲﾙとしてﾊﾞｰｼﾞｮﾝ番号が付加
さ
れ成果物DBに格納
・project viewから確認
・project viewに表示された前提ﾜｰｸや
知識情報の一覧から選択し内容を参照
・成果物や知識情報が保管されてい ・一覧表示される資料はWBSのﾜｰｸと対
る場所から探し出すために負荷が
応づいており探す負荷は殆どない
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
28
評価とまとめ
評価：6年間で2000を超えるプロジェクトで適用されており，アンケート結果や
プロマネへのヒアリング結果からプロジェクト管理を支援する有用な
システムと評価できる
アンケート結果
100ﾌﾟﾛｼﾞｪｸﾄの管理者にｱﾝｹｰﾄし109人より回答
・95%の人が満足(成果物の管理に満足:34% ，分散拠点から利用に満足：33%）
ヒアリング結果
評価項目
効
果
開発作業の高効率化
・他の担当者が作成した最新の成果物を簡単に参照でき仕様の確認が容易になった
・作業手順，記述例等の知識情報を参照しながら作業できるので経験の浅い開発者でも効
率的に進めることができる
成果物の管理
・バージョン管理が行われているので,バージョンの間違いによる作業ミスがなくなった
情報の共有化
・プロジェクトメンバ全員が常に同じ情報を即時に共有できた
・プロジェクト基準書，開発計画書のようなプロジェクト方針の周知徹底が簡単にできた
進捗情報の把握
・進捗情報の把握，成果物の内容確認等の煩雑な作業を簡略化できた
・直接，成果物の内容を確認できるので，進捗状況を正確に把握できるようになった
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
29
プロナビでの進捗情報の自動収集
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
30
WBSモデルの変更
1.WBSモデルへの機能階層の組込 C-1 プロジェクト
C-1-1 サブブロジェクト
・成果物の上位に機能階層を新設
C-1-1-1 ソフトウェア方式設計
・機能は大機能，中機能の2階層化 C-1-1-2 ソフトウェア詳細設計
大機能1
中機能11
中機能12
中機能13
60(FP)
50(FP)
45(FP)
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 シーケンス図
2.成果物の状態定義
3.WBS階層の状態定義
状態
着手
作成完了
QA承認済
PM承認済
顧客承認済
状態
未完了
完了
定義
成果物の作成に着手した状態
成果物の作成が完了した状況
品質保証部門(QA)が承認した状態
プロマネが承認した状態
顧客が承認した状態
定義
更新者
担当者
担当者
品質保証部門
PM
PM
更新者
当該階層以下の成果物が完了していない状態
PM
当該階層以下の全成果物が完了した状態
PM
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
31
自動収集した進捗情報の出力例
工
程
ソ
フ
ト
詳
細
設
計
担
当
成果
物予
定数
未完了
B
60
未完了
60
60
中機能12
65
中機能13
－
大機能
中機能
FP
進
捗
－
－
300
180
大機能1
－
180
中機能11
大機能2
階層の
状態
成果物の状態
PM
承認
済
73
QA
承認
済
78
作成
完了
着
手
80
顧客
承認
済
70
78
78
C
50
40
43
48
50
50
完了
D
15
15
15
15
15
15
0
未完了
E
25
20
20
25
25
25
55
0
未完了
F
10
5
8
8
8
8
120
120
完了
G
30
30
30
30
30
30
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
32
QFDを応用した機能仕様の
早期確定技法「仕様発散防止QFD」
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
33
仕様発散防止QFDの概要
目的 重要度，難易度が高く，遅延した時の影響が大きい機能の
仕様を早期に確定する
Step1:ユーザニーズを反映した機能の優先順位付け（機能重要度）
Step2:機能複雑度評価による開発前の
潜在リスクの見極め
Step3:危険度評価による開発着手後の
リスク監視
評価項目
業務特性
システムインターフェース有無
接続マシンの新規性
マンマシンインターフェース
他業務との連携の度合
評価項目
業務仕様提示度合
懸案事項残存率(%)
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
34
仕様発散防止QFDの例
危険度評価(1回目)
機能一覧
A業務
B業務
機能
機能
重要度 複雑度
危険度評価(2回目)
業務仕
様提示
度
懸案
残存率
危険
度
業務仕
様提示
度
懸案
残存率
危険
度
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
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
仕様を早く決定すべき
対策の結果,仕様を早期に決定
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
35
むすび
研究成果
1.要素見積法の確立
・開発の前段階でも精度が高く計測も速い
・精度はIFPUG法の-4%～+11%の範囲
・計測速度は3～5倍速い
今後の研究方針
1.COCOMOⅡの改善
・AP-Estimateとﾌﾟﾛﾅﾋﾞが連携して，開発
2.WBSに基づくプロジェクト管理システム
規模、工数、期間を計画から終了までを
“プロナビ”の開発
・2000を超えるﾌﾟﾛｼﾞｪｸﾄで適用実績
・109人のﾌﾟﾛﾏﾈへのｱﾝｹｰﾄで95%が満足と回答
・成果物管理，進捗情報の把握，情報の共有化，
開発作業の効率化で効果大
ﾄﾚｰｽし，ﾃﾞｰﾀを蓄積
3.QFDを応用した機能仕様の早期確定技法
の確立
・仕様の確定状況をQFDを応用して数値化
・数値の悪い機能から対策することで仕様の早期
確定を支援
・蓄積されたﾃﾞｰﾀを分析することにより
開発規模、工数、期間の相関関係を
指標化
2.ｿﾌﾄｳｪｱ生産性、品質の指標化
・EASEﾌﾟﾛｼﾞｪｸﾄでのEPM、AP-Estimate,
ﾌﾟﾛﾅﾋﾞで収集、蓄積したﾃﾞｰﾀの分析による
ｿﾌﾄｳｪｱ生産性、品質に関する指標の設定
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
36