基幹情報システム開発のための 生産技術及び見積技術に関する研究 大学院情報科学研究科 コンピュータサイエンス専攻 井上研究室 津田 道夫 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 1970年：日立製作所入社（流通SE部門→生産技術部門→コンサルティング部門） 1999年：日立システムアンドサービス転属（産業･流通SE部門→生産技術部門） システムエンジニア(SE) 20年 産業・流通業担当 ・建設業工事管理システム ・税理事務所向け会計システム ・海運コンテナヤードシステム ソフトウェア生産技術の研究･開発 17年 ・情報システム開発方法論の開発 ・統合開発支援ツールの開発 ・リバースエンジニアリング技術の開発 ・データ/ビジネスモデリング技術の開発 阪大ー日立製作所/日立システム共同研究 1990年～現在 研究テーマ ・ソフトウェア分散開発 ・ソフトウェア開発プロセス ・ソフトウェア規模見積技術（FP/UCP自動計測技術） ・産学官連携EASEプロジェクトの参加（2003年） ・阪大ソフトウェアデザイン工学高度人材育成コアの参加（2005年） ・関西9大学連携IT人材育成講座 ITspiralの参加（2006年） Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 2 研究の目的・内容 基幹情報システム：企業・行政機関の活動を支える情報基盤 基幹情報システムの開発は、開発規模は大きく、多数・多様な要員が参加する 大規模プロジェクトになる． 課題 ・生産性と品質の確保 ・プロジェクト管理が困難 ・業務仕様の確定が困難 ・正確な見積が困難 目標１：ソフトウェア開発プロセスの 標準化と一貫支援ツール 目標２：既存ソフトウェアの再利用 目標３：ソフトウェア規模の早期見積 研究内容 １．基幹情報システム開発方法論と統合開発支援ツール ２．リバースエンジニアリングによる業務仕様理解支援 ３．ソフトウェア規模の試算見積 ・協調フィルタリング技術による試算見積 ・ユースケースポイント法による試算見積 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 3 研究業績 博士論文 Michio Tsuda, Sadahiro Ishikawa, Osamu Ohno, Akira Harada, Mayumi Takahashi, Shinji Kusumoto, Katsuro Inoue,” Effectiveness of an Integrated Case Tool for Productivity and Quality of Software Developments,” IEICE Transactions on 第２章 Information and Systems, Vol.E89-D, No.4, pp.1470-1479, April 2006 津田道夫、楠本真二、松川文一、山村知弘、井上克郎、英繁雄、前川祐介、 “ユースケースポイント計測におけるアクタとユースケースの自動分類の試みと 第４章 支援ツールの試作、”電子情報通信学会論文誌（採録決定） M. Tsuda, Y. Morioka, M. Takadachi, and M. Takahashi,” Productivity analysis of software development with an integrated CASE tool,” Proc. of the 14th 第２章 International Conference on Software Engineering, PP.49-58, 1992 I.Nagaoka, K.Sanou, D. Ikeo, T. Nagashima, S. Akiba, M. Tsuda,” Reverse Engineering Method Experience For Industrial COBOL System,” Proc. of the 4th Asia Pacific Software Engineering and International Computer Science 第３章 Conference(APSEC97/ICSC97),PP.220-228,1997 大杉 直樹、松本 健一、津田 道夫、中屋 広樹、十九川 博幸、“協調フィルタリ ング技術によるソフトウェア規模の予測、”日立システムジャーナル、第六巻、 第４章 PP.59-66、2006 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 4 基幹情報システム開発方法論と 統合開発支援ツール Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 5 基幹情報システム開発方法論HIPACE 背 景 ・受託ソフトウェア開発量の増大による開発現場の混乱 ・手工業的開発手法の行き詰まり 開発方法論 HIPACE 標準化 ・開発工程 ・開発手順 ・ドキュメント ・開発技法 ・開発基準 標準手順・フェーズドアプローチ標準手順(SPDS) ・スパイラルアプローチ標準手順 ・オブジェクト指向標準手順 開発技法・データ分析技法 ・構造化技法 ・部品開発/利用技法 ・リポジトリ利用技法 ・リエンジニアリング技法 ・オブジェクト指向技法 統合開発 支援ツール EAGLE ・大規模開発に対応した確実な開発→フェーズドアプローチ ・安定性のある情報システムの開発 →DOA（Data Oriented Approach：データ中心型アプローチ） Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 6 フェーズドアプローチ標準手順(SPDS) フェーズドアプローチ フ ェ ー ズ 企 画 計 画 作 業 終 了 基本設計 詳細 設計 ・製造 ソフト ウェア テスト システム テスト ドキュメントの統一 WBSによる作業の詳細化 フェーズ ステップ名 作業名 作成ﾄﾞｷｭﾒﾝﾄ 成果物 製造 ﾌﾟﾛｸﾞﾗﾑ設計書 ﾌﾟﾛｸﾞﾗﾑ設計書作成 ﾌﾟﾛｸﾞﾗﾑ機能図 ﾌﾟﾛｸﾞﾗﾑ設計書 作成 運用 準備 ・ 移行 運用 テスト 担当 責任の 明確化 A社 ｸﾗｽ図､状態遷移図 関数仕様書 ﾚﾋﾞｭｰ/承認 ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ チェックリスト 作成基準 ﾌﾟﾛｸﾞﾗﾑﾁｪｯｸﾘｽﾄ作成 ﾌﾟﾛｸﾞﾗﾑﾁｪｯｸﾘｽﾄ ｺｰﾃﾞｨﾝｸﾞ ｿｰｽｺｰﾄﾞ 単体ﾃｽﾄ ﾊﾞｸﾞ票､ 修正票､仕様変更票 ﾃｽﾄ結果報告書作成 承認 品質表、報告書 ﾚﾋﾞｭｰ結果報告書 A社 ﾌﾟﾛｸﾞﾗﾑ設計書 Aは コーディング 基準 A社 A社 A社 品質 管理基準 ﾃｽﾄ結果報告書 A社 B社 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 7 データ中心型アプローチDOA データは、設計情報の中で安定しているので、データ中心で開発すれば高い 品質と保守性が得られる． データ辞書 [データ分析の手順] 現行業務データ調査 名称,形式,意味 名称 ドメイン分析 業務データモデリング ドメイン名称 実体（ｴﾝﾃﾃｨ） リレーション 制約分析 標準データ項目定義 データ辞書登録 ドメイン：制約条件を持つ値の集合（標準定義域） 制約：形式制約,値制約,導出制約,関連制約 標準データ名称：実体名+属性名+ドメイン名 社員誕生年月日 別名 社員誕生日 データ記号名 SHAINBIRTHDAY 意味 属性 データ制約 標準データ名称 標準データ名称 処理 社員の誕生日 データタイプ 整数 長さ ６ データチェック 実在日チェック 入力編集 和暦⇒西暦変換 出力編集 西暦⇒和暦変換 ・データと処理プロセスのカプセル化による ソフトウェアの重複排除 ・部品化による生産性と保守性の向上 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 8 統合開発支援ツールEAGLE EAGLE1 EAGLE2 EAGLE3 システム設計 ファイル/レコード定義 コード定義 画面・帳票定義 画面遷移定義 データベース定義 ＤＢスキマ定義 DFD編集 システムフロー編集 プログラム設計・作成 テスト ソフトウェア部品による プログラム生成 ソーステスタ 機能部品 スケルトン データ処理部品 業務ルール部品 DFD⇒システムフロー自動生成 分散オブジェクト論理設計図定義 構造図（ＰＡＤ）編集 Ｃ/Ｓ論理設計図定義 ＰＡＤ⇔プログラム生成 データモデル図（ＥＲ図）定義 ＰＡＤテスタ テストコマンド生成 テストケース生成 テストデータ生成 ソース静的解析 ＥＲ図⇒ＳＱＬ部品生成 オブジェクト指向分析・設計定義 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 9 ソフトウェア部品によるプログラム生成１ ＥＡＧＬＥ１：スケルトン ＥＡＧＬＥ１：機能部品 事務処理プログラムの制御構造をパターン化した 骨組み（スケルトン） ・スケルトンのカスタマイズはしない ・追加コーディング部分は局所化されているので 品質が高いプログラムができる ・スケルトンは特定のファイル/ＤＢから独立している 帳票作成スケルトン 入力ファイル 帳票作成 帳票 バッチ スケルトン 初期処理 追加コーディング 入力処理 集計前処理 帳票編集処理 集計処理 出力処理 集計後処理 機能部品：よく使うコードの部品化 日付計算、単位変換など (例)日付計算部品 ・誕生日⇒年齢計算 ・日付妥当性チェック ・うるう年の判定 ・日付⇒曜日計算 ・期間中の通算日数計算 課題 ・類似部品/重複部品の発生 ・部品適用を設計者が判断 終了処理 ファイル変換・編集・更新・チェック 22種類 DOAデータ処理部の部品化 （EAGLE2データ処理部品） 帳票作成 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 10 ソフトウェア部品によるプログラム生成２ ＥＡＧＬＥ２：データ処理部品 データ項目のドメイン共通処理を部品化 ＥＡＧＬＥ３：業務ルール部品 データ項目の制約を部品化 ドメイン 日付チェック部品 値制約：営業店小口出金金額 ＜＝ 10,000 名称 実在日チェック（西暦) と（和暦） 数量 過去日チェック（西暦） 金額 未来日チェック（西暦） 日付 年月日範囲内チェック（西暦） 時刻 日付編集部品 時間 年月日変換（西暦⇔和暦） コード 年月日算出（西暦年月日±日数) 番号 期間算出（西暦年月日間日数） 区分 月末日算出（西暦年月日） フラグ 通算週算出（年始～西暦年月 日） ⇒業務ルール ： 営業店での小口の出金は、１件に つき１万円以下でなければならない 導出制約： 受注合計金額=商品標準単価×受注明細数量 ⇒業務ルール ： 受注明細の合計金額は、商品の 標準単価と受注数量の積である 関連制約： ＩＦ 顧客住所コード＞=１００ ＥＬＳＥ 商品輸送金額=商品輸送定額金額+1000 ⇒業務ルール ： 顧客住所が離島(100以上）なら 商品輸送金額は定額料金に1000 円増しの金額である 235種類 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 11 統合開発支援ツールの評価１ 生産性評価 プログラム生成率＝ Lg Lg：統合開発支援ツールが生成したプログラムの量 Lt：プログラム全体の規模(コメントを含む) Lt フェーズ EAGLE１ EAGLE２ プロジェクト A B C D E 帳表作成 69% 98% 62% 86% 72% ファイル処理 78% 97% 74% データチェック 50% 73% 77% 問合せ， 更新 74% 77% 72% データ入力 50% 72% 52% 68% 81% バッチ オンライン 平均生成率 EAGLE３ P層： 0% 46% F層：44% 43% D層：98% 99% バッチの生成率 は高い Ｗｅｂ３層モデル ではＰ層/Ｆ層の 生成率向上が 課題 71% ・バッチは，ｽｹﾙﾄﾝと部品により高い生成率を維持しているが，オンラインはアーキテクチャ に依存するので生成率向上が課題である． ・EAGLE1 vs EAGLE2ではデータ処理部品の効果により＋13%向上した． Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 12 統合開発支援ツールの評価２ 品質評価 不良密度＝ Ft Lt Ft：不良件数 Lt：プログラム全体の規模(コメントを含む)KS 単体テスト用テストケース作成支援を適用したプロジェクトGの効果 フェーズ プロジェクト 単体テスト 不 良 組合せテスト 密 合計 度 EAGLE2 F G 3.7 4.8 2.9 2.2 6.6 7.0 プロジェクトF (2.9件/KS) プロジェクトG (2.2件/KS) 組合せテストの不良分布 タイプ1 タイプ2 タイプ3 1.54件/KS 0.68件/KS 0.68件/KS 53% 23.5% 23.5% 0.99件/KS 45% 0.66件/KS 0.55件/KS 30% 25% (タイプ1：単体テストレベル タイプ2：組合せテストレベル タイプ３：その他) ・標準テストケース作成支援機能により単体テストでのバグ出しが増加し、組合せテストの 品質が向上した． ・業務仕様を確認するシステムテストや運用テストの支援技術の研究が課題である． Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 13 統合開発支援ツールの評価３ 習熟性評価 プログラム開発習熟曲線(Y) Y：X回目のプログラム開発平均時間（時間/KS） Y=aX-n a：1回目のプログラム開発平均時間（時間/KS） X：プログラム開発経験回数 n：効果係数 成長率(E) Y2X E= Y X E：X回目と２X回目のプログラム開発平均時間の比率 Y2X：(2X)回目のプログラム開発平均時間（時間/KS） YX ：X回目のプログラム開発平均時間（時間/KS） Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 14 統合開発支援ツールの評価３ プログラム開発習熟曲線(Y) 成長率(E) 3回目(X=3)と6回目（2X=6）の生産性を比較 Ｙ：プログラム開発平均時間 教育１( EAGLE1) 教育２ (EAGLE2) 100% 開発作業 成 長 率 (E ) Ｙ=154.9X-0.22 75% 50% Y3 Ｙ=121.8X-0.48 Y6 25% １ ２ ３ ４ ５ ６ ７ ８ ９ 10 Ｘ：プログラム開発経験回数 教育１ 教育２ プログラムコーディング 86% 69% テストケース設計 ＆単体テスト 83% 74% - 83% ドキュメンテーション 86% 72% 合計 86% 72% 単体テストのみ EAGLE機能拡張効果により成長率が12%向 上した ・習熟曲線により反復訓練の教育効果を実測した． ・支援ツールの機能差によりEAGLE2の生産性は1.3倍で習熟率も高い． EAGL2では経験回数が４，５回で習熟率が上がる． Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 15 ソフトウェア規模の試算見積 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 16 試算見積 フェーズ 企画 基本設計 試算見積 詳細設計 概算見積 製造 テスト 詳細見積 試算見積：企画・計画段階での見積で, まだ詳細仕様は確定していない [メトリクス］ コード行数（ステップ） ［試算見積法］ 経験法：個人の経験に依存するので精度が低い 開発言語/開発環境に依存する FP試算法：画面/帳票/ファイル数にFP単価を掛けて算出 FP (Function Point） FP要素見積法：処理形態を要素機能に分解してFP単価 を掛けて算出 協調フィルタリング法：類似プロジェクトから予測 電力中研法：画面/帳票/ファイル数にFP単価を掛けて算出 UCP(Use Case Point) UCP法：ユースケースモデルのアクタ/ユースケースに 単価を掛けて算出 図4.8 ｢注文を出す｣ユースケース Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 17 協調フィルタリング 嗜好抽出・情報推薦技術として研究されてきた事例ベース類推法のひとつで， データに欠陥値が含まれていても検索できるのが特長である． 書籍推薦の例 あらかじめユーザが 書籍を評価しておく 類似度計算の例 変数 P1 推薦対象ユーザと評価 が似ている類似ユ ーザを選び出す 類似ユーザの評価を用 いて推薦対象ユーザの 評価を見積る ユークリッド距離 d コサイン距離 Pn α 変数 推薦対象ユーザの評 価が高い場合，類似 ユーザが評価した書籍 を推薦する 事例 ・ユーザの行動履歴に基づく推薦：Amazon.com ,MSN Newsbot ・選択アイテムに基づく推薦：TSUTAYA,UNIQLO Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 18 ソフトウェア規模試算見積 プロジェクトPaの 規模を予測する 新規開発 開発言語：Java 画面数：30 帳票数：20 類似プロジェクト P１：４００FP P5：６００FP 試算見積の流れ プロジェクト実績データ ①プロジェクト実績データの準備 言語 新規 Java 40 10 400 C++ 25 40 600 COBOL 20 ②予測モデルの設定 P1 ③検索アルゴリズムの設定 ④事例ベース検索による プロジェクト間類似度計算＊ 予測値 Paの規模予測 Pa規模；500 種別 ⑤予測値計算＊ P2 P3 拡張 P4 新規 P5 新規 Java P6 拡張 VB 画 面 数 帳 票 数 規模 300 100 200 900 20 20 600 100 ： 欠陥データ ＊：NAIST開発の見積ツールdocfbe 予測誤差を大きくする要因 ・ノイズデータ,信頼性の低いデータの混在 ・変数の設定，値の種別の設定 ・類似度/予測値計算アルゴリズム 本研究のアプローチ ・正当なデータの準備 ・最適な変数と値種別の探索 ・最適な検索アルゴリズムの探索 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 19 試算見積の流れ ①プロジェクト実績データの準備 日立システムのプロジェクトデータからソフトウェア規模(FP値） を実測したプロジェクトを抽出した（N=85) ②予測モデルの設定 6種類の変数による予測モデルを設定した 変数 種別 欠陥率 １ 対応業種 カテゴリ（11種類) 0% ２ 開発言語 カテゴリ(3種類) 0% ３ 画面数 数値 13% ４ 帳票数 数値 13% ５ ファイル数 数値 0% ６ 一般システム特性(14種 類) 数値 17% ③検索アルゴリズムの設定 ・カテゴリ変数：数値表現出来ない変数 ・開発言語：「Jaba,.Net系｣｢VB系」「その他」 ・一般システム特性：FP法国際団体IFPUGが 規定した特性 探索ツール（5000ケースを生成）を開発して、最適な計算式を探した 決定アルゴリズムr1 類似度 計算 8種類（コサイン，相関係数，順位相関，ﾕｰｸﾘｯ ﾄﾞ距離と変数の平均値/中央値の組合せ） 予測値 計算 10種類(類似プロジェクト/見積規模の加重平均/ 中央値,倍率修正値の組合せ） 探索 ツール 相関係数(平均値）とﾕｰｸ ﾘｯﾄﾞ距離（中央値）の按分 類似プロジェクトの加重 平均と倍率修正の中央値 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 20 試算見積の評価方法 全プロジェクト（N=85)総当り方式で実績FP値と予測FP値を比較した 見積対象プロジェクト P1 業種 言語 画面数 帳票数 P2 業種 言語 画面数 帳票数 ﾌｧｲﾙ ｼｽﾃﾑ特性 規模 P3 *** *** *** *** *** *** *** P4 *** *** *** *** *** *** *** P5 *** *** *** *** *** *** *** ・ *** *** *** *** *** *** *** ・ *** *** *** *** *** *** *** P85 *** *** *** *** *** *** *** 特性1 データ通信 特性8 オンライン更新 特性2 分散処理 特性9 複雑な処理 特性3 性能 特性10 再利用可能性 特性4 高負荷構成 特性11 インストール容易性 特性5 トランザクション量 特性12 運用性 特性6 オンラインデータ入力 特性13 複数サイト 特性7 エンドユーザ利便性 特性14 変更容易性 ﾌｧｲﾙ ｼｽﾃﾑ特性 規模 比 較 P1予測規模 協調フィルタリング 見積ツールdocfbe ｼｽﾃﾑ特性を3種類のデータで評価した ・数値変数(DI=[0，5])、 ・カテゴリ変数 ６値表現(DI=[VALUE0，VALUE5]) ２値表現(DI=(LOW，HIGH)) Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 21 ソフトウェア規模試算見積の評価１ 評 価 指 標 検索アルゴリズム 決定r1 標準 一般ｼｽﾃﾑ特性の値 ２値 ６値 数値 ２値 相対誤差平均(MRE ) 0.28 0.33 0.43 1.03 相対誤差中央 (MedRE ) 0.22 0.28 0.30 0.42 相対誤差分散(VRE) 0.27 0.28 0.52 3.20 相関係数(Corr ) 0.94 0.94 0.94 0.93 標準：NAISTが設定した見積ツール docfbeの標準アルゴリズム 類似度 コサイン（変数の平均値） 予測値 類似プロジェクト（加重平均） ＋倍率修正値（加重平均） Pred25：相対誤差0.25以下 の件数の割合 Pred25 56.5 43.5 37.7 30.6 % % 一般ｼｽﾃﾑ特性の値表現で差が出た % % MRE0.28と実用化レベルの予測が出来た ・ソフトウェア規模試算見積に協調フィルタリング法の有効性を確認した． ・高い精度の試算見積には以下の研究が今後の課題である． ①変数と最適検索アルゴリズムのルール抽出技術 ②実績データの計測技術（例：ソースコード→FP値） Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 22 ソフトウェア規模試算見積の評価２ FP試算法のひとつであるNESMA法と比較した NESMA法 相対誤差平均(MRE ) 協調フィルタリング法 0.72 相対誤差平均(MRE ) 0.28 0.65 相対誤差中央(MedRE ) 0.22 0.59 相対誤差分散(VRE) 0.27 0.94 相関係数(Corr ) 0.94 23.5% Pred25 56.5% NESMA法 協調フィルタリング法 ・すべての指標で協調フィルタリング法が優れている． ・相対誤差平均の偏差分布では，22件（全体の26%）がNESMA法の結果が 優れている． NESMA法：試算FP＝(更新系ファイル数×35)＋(参照系ファイル数×15) NESMA (Netherlands Software Metrics Users Association） Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 23 ユースケースポイント法による試算見積 ユースケースモデルから規模を試算するUCP計測支援ツールU-ESTの開発 ユースケースモデル ユースケース記述 ユースケース アクタ 注文を出 す タイプ ア ク タ １．顧客が｢注文を出す｣ボタンを押す ２．システムは情報入力画面を表示する ３．顧客は商品コードを入力する ４．システムは入力された商品コードから 商品を検索する 説明 重み 単純 定義済みAPIを備えた別システム １ 平均的 プロトコル駆動のインタフェース(別システム)， テキストベースのインタフェース(人間) ２ 複雑 GUIを介する人間 ３ ユースケース モデル キーワードリスト UCP = AW + UW ユ ｜ ス ケ ｜ ス AW = アクタ数 × 重み UW = ユースケース数 × 重み タイプ 説明 重み 単純 トランザクション数が3 個以下 ５ 平均的 トランザクション数が4 個から7 個 １０ 複雑 トランザクション数が8 個以上 １５ UCP計測支援ツールU-EST アクタタイプの 自動分類 ユースケースタイプ の自動分類 分類ルール：４ 分類ルール：７ UCP ルール例： ユースケース記述でキーワード と合致する割合の多いものを アクタタイプとする Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 24 ユースケースポイント法試算見積の評価 UCP計測者の手動計測と支援ツールU-ESTの自動計測を比較した プ ロ ジ ェ ク ト アクタ 手動 ユースケース U-EST 手動 単 純 平 均 複 雑 単 純 平 均 複 雑 一致率 A １ ０ ４ ０ １ ４ B ３ ０ ２ ２ １ C ０ ０ ２ ０ D １ ０ ４ E ０ ０ ８ U-EST 単 純 平 均 複 雑 単 純 平 均 複 雑 一致率 ０．８ １３ ２ ０ １３ ２ ０ １．０ ２ ０．８ １０ ４ ０ １０ ４ ０ １．０ ０ ２ １．０ １４ ６ ０ １２ ８ ０ ０．９ １ ０ ４ １．０ ２７ １ ０ ２７ １ ０ １．０ ０ ０ ８ １．０ ２ ８ ３ ２ ８ ３ １．０ 不一致1件はトラン ザクション数が境界 線を挟んだユースケ ース検出による． 不一致2件は外部ｼｽﾃﾑのアクタ． ・アクタ，ユースケース共，高い一致率を得た． ・ケーススタディ（特に大規模システム）の蓄積とキーワード、U-ESTの改良が課題である． Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 25 むすび 研究成果 今後の研究方針 1.情報システム開発方法論と統合開発 支援ツールの開発 1.開発方法論の拡充 ・開発方法論を標準化してグループに展開した ・ソフト部品によるプログラム自動生成を実現した （生成率70%～80%，品質30%向上） ・教育効果を測定して教育の重要性を示した （習熟曲線により経験４，5回で習熟する） 2.ソフトウェア規模の試算見積 ・協調フィルタリング法による試算見積の実用性 (相対誤差平均0.28）を測定した ・ユースケースポイント自動計測支援ツールを 開発して有効性（一致率0.8～1.0)を確認した 3.リバースエンジニアリングによる業務仕様 理解支援 上流工程の開発技法・支援ツールの研究． ・業務要件のﾓﾃﾞﾙ化とモデルの評価・検証技法 ・非機能要件(信頼性、安全性等）の設計技法 2.試算見積の実用化研究 実績データの自動取得・蓄積・再利用技術． ・成果物（ソース等）→実績FP/UCP計測技術 3.エンピリカルソフトウェア工学 定常的にプロジェクト実績データを収集・分析 して，そこから知見を発見して現場にフィード バックするエンピリカルアプローチは重要である． ・プロジェクトデータ自動収集技術 ・プロジェクトコクピット（診断・警告）技術 ・プロジェクト分析の法則・理論抽出技術 Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 26
© Copyright 2024 ExpyDoc
