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

1. エンタープライズ系ソフトウェア開発のための見積技法及びプロジェクト管理支援に関する研究エンタープライズ系ソフトウェア開発のための見積技法及びプロジェクト管理支援に関する研究 大学院情報科学研究科 コンピュータサイエンス専攻 井上研究室 原田　晃

2. 研究の背景 エンタープライズ系ソフトウェアとは 　・企業，行政機関の経営，活動，プロセスを支援するソフトウェア 課題 課題1：開発委託時に開発すべき 　　　　ソフトウェアの機能仕様が曖昧 課題2：開発規模，開発コスト，開発期間 　　　　の見積精度が低い 課題3:機能仕様の確定に時間がかかる 課題4：プロジェクト管理が難しい 特長 ・多種多様である ・大規模である ・個別開発である ・プロジェクト型の開発である ・受託開発が多い ・業務知識は発注者である 　顧客側にある

3. 研究の目的・内容 目的：課題2, 3, 4の解決 1.早い段階での明確な根拠に基づいた 　精度の高い見積技法の研究 2.大規模なプロジェクトのプロジェクト管理を 　幅広く支援するシステムの研究 3.プロジェクト開始時には曖昧な機能要件を 　早期に確定する技法の研究 研究内容 ・ファンクションポイント法を応用した早期見積法 ・WBSに基づくプロジェクト管理システム“プロナビ” ・“プロナビ”での進捗情報の自動収集 ・QFDを応用した機能仕様の早期確定技法 ここを中心に 発表 要点のみを 発表

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

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

6. 開発規模の尺度 コード行数 ・標準的な定義がない． 　・いろいろな種類の行が存在する． 　・再利用コードの測定が正確でない． 　・プログラマの技術レベルによる規模の差異が大きい． 　・高水準言語による見かけ上の生産性低下が起きる． ファンクションポイント(FP) ・ソフトウェアの機能量をファンクションポイント(FP)という尺度で計測 　・1979年にIBMのAlbrechtによって考案 　・エンタープライズ系ソフトウェアの見積技法として標準になりつつある ファンクションポイント法

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段階に設定 　・複雑度は関連ファイル数，データ項目数で評価 FPの算出法 Step3：FPの算出

9. IFPUG法の課題 IFPUG法の課題 ・EI, EO, EQの抽出が難しい．　　　　　　　 （具体的な処理をイメージできない） ・複雑度の評価が難しい　　　　　　 ・習熟者でないと難しい ・開発の前段階では設計書 　の記載レベルが粗く難しい 改善方法 　・具体的な処理をイメージできる処理系要素を豊富に定義 　・処理系要素，ファイル系要素のFPデフォルト値を設定することで 　　複雑度の評価作業を削除 要素見積法

10. 要素見積法とIFPUG法の比較 • 要素機能：画面上のGUIボタン，ファンクションキーを押すことで実行される 　　　　　　　　具体的な処理.ユーザ視点での入出力の最小単位. 要素見積法 IFPUG法 DF ・ILF,EIFの3種類 DF ・IFPUG法と同一 TF ・16種類の具体的な処理系要素 　　（要素機能） ex:既存データ変更，一覧照会， 　　　明細照会 TF ・EI,EO,EQの3種類 複雑度評価 ・評価せず ファイル系要素，処理系要素に FPデフォルト値(FP単価)を設定 複雑度評価 ・ファイル系要素，処理系要素 　とも評価

11. 要素機能一覧とFP単価

12. FP単価設定の考え方 • 1996年～1998年にかけてのIFPUG法での実測結果からFP単価の平均値を算出し，それを参考に設定． • 実測による平均値 • データファンクションのFP単価 • 実測値を，そのまま適用

13. 要素機能のFP単価の設定 • 要素機能に含まれるTF(EI,EO,EQ)の出現頻度とFP値から設定 • 設定例 • 新規登録：DFの更新がありEIが1回出現．EIのFP値は実測値の平均を採用 • 既存データ削除：EIが1回出現．複雑度が低く，FP値4を採用 • 問合せ応答：EO,EQの出現確率は半々．実測値の平均を採用

14. 要素機能の単価精度の評価 評価基準 偏差（FP単価-FP平均値)/FP平均値)：-10%～+25% FP平均値は実測値 11の要素機能については基準内 基準外の要素機能 出現頻度が少なく 妥当と評価

15. 要素機能のFP実測値

16. 要素機能の抽出精度の評価 旅費精算ソフトのRFP ・事前に登録しておいた出張案件から 　精算したい案件を選択 ・旅費に関する項目を入力し登録 ・登録した内容を後で修正可 ・領収書の提出等のために帳票を出力 評価方法 IFPUG法，要素見積法で 旅費精算ソフトのRFPからFPを算出 ・2段階の照会，修正の影に削除等 の行間にあるものをEI,EO,EQか ら想起するのは難しい ・RFPからEO,EQの判別が難しい ・複雑度評価が難しく時間がかかる IFPUG法 未習熟者が行うと過小見積になりやすい 要素見積法 未習熟者でもTFの抽出が容易 　計測速度がIFPUG法の3～5倍速い

17. IFPUG法による見積結果 EI,EO,EQの複雑度は“中”を仮定

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

19. 要素見積法の精度評価 6つのエンタープライズ系ソフトウェアで実測評価 ・金融分野：1 製造分野：2 公共分野：3 要素見積法が過大見積傾向になる考察 1.ﾃﾞｰﾀﾌｧﾝｸｼｮﾝのFPは6つとも過大 　・要素見積法でのILFのFP値は8であるが， 6つの実測の平均値は7.3 2.トランザクションファンクションのFPも5つで過大 　・要素機能のFP値設定に用いたEI,EO,EQの FP値はIFPUG法での複雑度“中”と“高”の 　　中間値であり，6つの実測の平均値より大 IFPUG法での実測結果を100として -4%～+11%の範囲内

20. 見積支援システムAP-Estimate ｸﾗｲｱﾝﾄPC AP-Estimateサーバー Intranet 登 録 ・ 取 込 処 理 規模見積 アクセス制御 TFの 計測 DFの 計測 登録 見積結果管理部 バージョン比較 見積者 取込 規模 比較処理 表示 処理 見積DB(RDB) ｸﾗｲｱﾝトPC プロジェクトA 見積結果 Ver1 見積結果 Ｖｅｒ２ プロジェクトB 収集 分析 改善 見積結果 Ver1 見積結果 Ver2 生産管理部門

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

22. まとめ • 要素見積法の確立 • 精度が高い（IFPUG法の-4%～+11%の範囲） • 仕様の明確でない開発の前段階でも要素機能の抽出が容易 • 複雑度の評価が不要なので計測速度がIFPUG法の3～5倍速い • 見積支援システムAP-Estimateの開発 • 見積作業を契機に仕様の不明確な箇所を顧客と詰めることができた． • 見積根拠が明確になり顧客，社内のｽﾃｰｸﾎﾙﾀﾞｰからの理解を得やすい． • 大きな追加，変更の発生の度に見積をするので，トラッキングコントロールができ，プロジェクト管理不良が低減した．

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

24. 「プロナビ」の必要性 ソフト開発プロジェクトの特徴 ・作業，成果物が膨大 ・プロジェクトメンバが多い ・開発拠点が分散 ・情報共有が難しい 　（計画，状況，成果物） ・利用する参考資料が膨大 • プロナビ • ・WBSによるプロジェクトのモデル化 ・工程，作業の階層化 ・工程，作業，成果物，参考資料の 　相互関連付けと一元管理 ・プロジェクト計画時の工程，作業， 　成果物の明確化 ・プロジェクト進捗状況の把握 ・プロジェクトメンバ間での成果物の共有 ・規則，標準，ワークシート等の知識の活用 ・プロセス，作業の標準化 人手でのプロジェクト管理が難しい WBSに基づくプロジェクト管理システム 「プロナビ」を開発

25. 標準プロナビWBS 第1階層：プロジェクト 経営管理システム 第2階層：サブプロジェクト 経営管理システム ・・・ 従業員管理システム 第3階層：フェーズ ・・・ 要求分析 業務要件設計 ソフト方式設計 ビジネスプロセス設計 第4階層：作業ステップ アーキテクチャ設計 テスト計画 ・・・ 処理方式設計 システム部品定義書 第5階層：成果物 ・・・

26. プロナビWBSとプロジェクト計画の対応 経営管理システム 従業員管理システム 情報付与 WORK1 システム計画 WORK2 要求分析 WORK2.1 ビジネスプロセス分析 WORK2.1.1 業務用語集

27. プロジェクト計画 策定 プロジェクト情報表示 project view プロナビの構成 クライアントPC プロナビWebサーバ プロジェクト 情報DB 管理者 プロジェクト情報 管理部 成果物 DB 成果物管理部 クライアントPC プロジェクト情報表示 project view private view 知識情報管理部 知識情報 DB 開発者 成果物作成 知識情報 表示 Intranet/Internet

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

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

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

31. WBSモデルの変更 1.WBSモデルへの機能階層の組込 ・成果物の上位に機能階層を新設 ・機能は大機能，中機能の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 シーケンス図 2.成果物の状態定義 3.WBS階層の状態定義

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

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

34. 仕様発散防止QFDの概要 目的　重要度，難易度が高く，遅延した時の影響が大きい機能の 　　　　仕様を早期に確定する Step1:ユーザニーズを反映した機能の優先順位付け（機能重要度） Step2:機能複雑度評価による開発前の 　　　　潜在リスクの見極め Step3:危険度評価による開発着手後の 　　　　リスク監視

35. 仕様発散防止QFDの例 仕様を早く決定すべき 対策の結果,仕様を早期に決定

36. むすび 研究成果 1.要素見積法の確立 ・開発の前段階でも精度が高く計測も速い ・精度はIFPUG法の-4%～+11%の範囲 ・計測速度は3～5倍速い 2.WBSに基づくプロジェクト管理システム 　“プロナビ”の開発 ・2000を超えるﾌﾟﾛｼﾞｪｸﾄで適用実績 ・109人のﾌﾟﾛﾏﾈへのｱﾝｹｰﾄで95%が満足と回答 ・成果物管理，進捗情報の把握，情報の共有化， 　開発作業の効率化で効果大 3.QFDを応用した機能仕様の早期確定技法 の確立 ・仕様の確定状況をQFDを応用して数値化 ・数値の悪い機能から対策することで仕様の早期 　確定を支援 今後の研究方針 1.COCOMOⅡの改善 ・AP-Estimateとﾌﾟﾛﾅﾋﾞが連携して，開発 　規模、工数、期間を計画から終了までを 　ﾄﾚｰｽし，ﾃﾞｰﾀを蓄積 ・蓄積されたﾃﾞｰﾀを分析することにより 　開発規模、工数、期間の相関関係を 　指標化 2.ｿﾌﾄｳｪｱ生産性、品質の指標化 ・EASEﾌﾟﾛｼﾞｪｸﾄでのEPM、AP-Estimate, ﾌﾟﾛﾅﾋﾞで収集、蓄積したﾃﾞｰﾀの分析による ｿﾌﾄｳｪｱ生産性、品質に関する指標の設定