1 / 26

基幹情報システム開発のための 生産技術及び見積技術に関する研究

基幹情報システム開発のための 生産技術及び見積技術に関する研究. 大学院情報科学研究科 コンピュータサイエンス専攻 井上研究室. 津田　道夫. 1970 年：日立製作所入社（流通 SE 部門→生産技術部門→コンサルティング部門） 1999 年：日立システムアンドサービス転属（産業･流通 SE 部門→生産技術部門）. 研究の目的・内容. 基幹情報システム：企業・行政機関の活動を支える情報基盤. 基幹情報システムの開発は、開発規模は大きく、多数・多様な要員が参加する 大規模プロジェクトになる．. 課題 ・生産性と品質の確保 　　　 ・プロジェクト管理が困難

presley
Download Presentation

基幹情報システム開発のための 生産技術及び見積技術に関する研究

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 基幹情報システム開発のための生産技術及び見積技術に関する研究基幹情報システム開発のための生産技術及び見積技術に関する研究 大学院情報科学研究科 コンピュータサイエンス専攻 井上研究室 津田　道夫

  2. 1970年：日立製作所入社（流通SE部門→生産技術部門→コンサルティング部門）1970年：日立製作所入社（流通SE部門→生産技術部門→コンサルティング部門） 1999年：日立システムアンドサービス転属（産業･流通SE部門→生産技術部門）

  3. 研究の目的・内容 基幹情報システム：企業・行政機関の活動を支える情報基盤 基幹情報システムの開発は、開発規模は大きく、多数・多様な要員が参加する 大規模プロジェクトになる． 課題 ・生産性と品質の確保 　　　 ・プロジェクト管理が困難 　　 　・業務仕様の確定が困難 　 　　・正確な見積が困難 目標１：ソフトウェア開発プロセスの 　　　　　標準化と一貫支援ツール 目標２：既存ソフトウェアの再利用 目標３：ソフトウェア規模の早期見積 　研究内容 　　１．基幹情報システム開発方法論と統合開発支援ツール 　　２．リバースエンジニアリングによる業務仕様理解支援 　　３．ソフトウェア規模の試算見積 　　　　・協調フィルタリング技術による試算見積 ・ユースケースポイント法による試算見積

  4. 研究業績 博士論文 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 第４章

  5. 基幹情報システム開発方法論と統合開発支援ツール基幹情報システム開発方法論と統合開発支援ツール

  6. 基幹情報システム開発方法論HIPACE ・受託ソフトウェア開発量の増大による開発現場の混乱 ・手工業的開発手法の行き詰まり 背景 開発方法論 HIPACE 標準手順・フェーズドアプローチ標準手順(SPDS) 　　　　　　・スパイラルアプローチ標準手順 　　　　　　・オブジェクト指向標準手順 標準化 ・開発工程 ・開発手順 ・ドキュメント ・開発技法 ・開発基準 開発技法・データ分析技法 　　　　　　・構造化技法 　　　　　　・部品開発/利用技法 　　　　　　・リポジトリ利用技法 　　　　　　・リエンジニアリング技法 　　　　　　・オブジェクト指向技法 統合開発 支援ツール EAGLE ・大規模開発に対応した確実な開発→フェーズドアプローチ ・安定性のある情報システムの開発 →DOA（Data Oriented Approach：データ中心型アプローチ）

  7. フェーズ ステップ名 作業名 作成ﾄﾞｷｭﾒﾝﾄ 成果物 担当 製造 ﾌﾟﾛｸﾞﾗﾑ設計書 ﾌﾟﾛｸﾞﾗﾑ設計書作成 ﾌﾟﾛｸﾞﾗﾑ機能図 ﾌﾟﾛｸﾞﾗﾑ設計書 作成 ｸﾗｽ図､状態遷移図 A社 関数仕様書 ﾚﾋﾞｭｰ/承認 ﾚﾋﾞｭｰ結果報告書 A社 WBSによる作業の詳細化 ﾌﾟﾛｸﾞﾗﾑ設計書 Aは ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ ﾌﾟﾛｸﾞﾗﾑﾁｪｯｸﾘｽﾄ作成 ﾌﾟﾛｸﾞﾗﾑﾁｪｯｸﾘｽﾄ A社 ｺｰﾃﾞｨﾝｸﾞ ｿｰｽｺｰﾄﾞ A社 チェックリスト 作成基準 単体ﾃｽﾄ ﾊﾞｸﾞ票､ A社 コーディング基準 修正票､仕様変更票 ﾃｽﾄ結果報告書作成 品質表、報告書 A社 承認 ﾃｽﾄ結果報告書 B社 フェーズドアプローチ標準手順(SPDS) フェーズドアプローチ フェーズ 企画 基本設計 詳細 設計 ・製造 ソフト ウェア テスト システム テスト 運用テスト 運用 準備 ・ 移行 計画 作業 終了 ドキュメントの統一 責任の 明確化 品質 管理基準

  8. データ中心型アプローチDOA データは、設計情報の中で安定しているので、データ中心で開発すれば高い 品質と保守性が得られる． [データ分析の手順] データ辞書 現行業務データ調査 名称,形式,意味 ドメイン分析 ドメイン名称 実体（ｴﾝﾃﾃｨ） 業務データモデリング リレーション 制約分析 データ制約 標準データ項目定義 標準データ名称 データ辞書登録 ドメイン：制約条件を持つ値の集合（標準定義域） 制約：形式制約,値制約,導出制約,関連制約 標準データ名称：実体名+属性名+ドメイン名 ・データと処理プロセスのカプセル化による 　ソフトウェアの重複排除 ・部品化による生産性と保守性の向上

  9. 統合開発支援ツールEAGLE EAGLE1 EAGLE2 EAGLE3 ファイル/レコード定義 コード定義 ソフトウェア部品による プログラム生成 ソーステスタ 画面・帳票定義 画面遷移定義 ＰＡＤテスタ スケルトン 機能部品 データベース定義 ＤＢスキマ定義 テストコマンド生成 データ処理部品 DFD編集 システムフロー編集 テストケース生成 業務ルール部品 DFD⇒システムフロー自動生成 テストデータ生成 構造図（ＰＡＤ）編集 分散オブジェクト論理設計図定義 ソース静的解析 ＰＡＤ⇔プログラム生成 Ｃ/Ｓ論理設計図定義 データモデル図（ＥＲ図）定義 ＥＲ図⇒ＳＱＬ部品生成 オブジェクト指向分析・設計定義

  10. 追加コーディング 入力ファイル 帳票作成スケルトン 集計前処理 初期処理 帳票作成 集計処理 入力処理 集計後処理 帳票編集処理 帳票 出力処理 終了処理 ソフトウェア部品によるプログラム生成１ ＥＡＧＬＥ１：スケルトン ＥＡＧＬＥ１：機能部品 事務処理プログラムの制御構造をパターン化した 骨組み（スケルトン） 　・スケルトンのカスタマイズはしない 　・追加コーディング部分は局所化されているので 　　品質が高いプログラムができる 　・スケルトンは特定のファイル/ＤＢから独立している 機能部品：よく使うコードの部品化 　日付計算、単位変換など (例)日付計算部品 　　　・誕生日⇒年齢計算 　　　・日付妥当性チェック 　　　・うるう年の判定 　　　・日付⇒曜日計算 　　　・期間中の通算日数計算 課題 ・類似部品/重複部品の発生 ・部品適用を設計者が判断 DOAデータ処理部の部品化 （EAGLE2データ処理部品）

  11. ソフトウェア部品によるプログラム生成２ ＥＡＧＬＥ２：データ処理部品 ＥＡＧＬＥ３：業務ルール部品 データ項目のドメイン共通処理を部品化 データ項目の制約を部品化 値制約：営業店小口出金金額 ＜＝ 10,000 　⇒業務ルール ： 営業店での小口の出金は、１件に　　　　　　　　　　つき１万円以下でなければならない 導出制約： 受注合計金額=商品標準単価×受注明細数量 　⇒業務ルール ： 受注明細の合計金額は、商品の　　　　　　　　　　　標準単価と受注数量の積である 関連制約： ＩＦ　顧客住所コード＞=１００ ＥＬＳＥ　商品輸送金額=商品輸送定額金額+1000 ⇒業務ルール ： 顧客住所が離島(100以上）なら 　　　　　　　　　　商品輸送金額は定額料金に1000 　　　　　　　　　　円増しの金額である 235種類

  12. Lg プログラム生成率＝ Lt 統合開発支援ツールの評価１ 生産性評価 Lg：統合開発支援ツールが生成したプログラムの量 Lt：プログラム全体の規模(コメントを含む) バッチの生成率は高い Ｗｅｂ３層モデルではＰ層/Ｆ層の 生成率向上が課題 ・バッチは，ｽｹﾙﾄﾝと部品により高い生成率を維持しているが，オンラインはアーキテクチャ 　に依存するので生成率向上が課題である． ・EAGLE1 vs EAGLE2ではデータ処理部品の効果により＋13%向上した．

  13. Ft 不良密度＝ Lt 組合せテストの不良分布 タイプ1　　　　　　　タイプ2　　　タイプ3 プロジェクトF 1.54件/KS 0.68件/KS0.68件/KS (2.9件/KS) 53% 23.5% 23.5% プロジェクトG 0.99件/KS 0.66件/KS 0.55件/KS (2.2件/KS) 45% 30% 25% (タイプ1：単体テストレベル　タイプ2：組合せテストレベル　タイプ３：その他) 統合開発支援ツールの評価２ 品質評価 Ft：不良件数 Lt：プログラム全体の規模(コメントを含む)KS 単体テスト用テストケース作成支援を適用したプロジェクトGの効果 ・標準テストケース作成支援機能により単体テストでのバグ出しが増加し、組合せテストの 　品質が向上した． ・業務仕様を確認するシステムテストや運用テストの支援技術の研究が課題である．

  14. Y2X E= YX 統合開発支援ツールの評価３ 習熟性評価 プログラム開発習熟曲線(Y) Y：X回目のプログラム開発平均時間（時間/KS） Y=aX-na：1回目のプログラム開発平均時間（時間/KS） X：プログラム開発経験回数 n：効果係数 成長率(E) E：X回目と２X回目のプログラム開発平均時間の比率 Y2X：(2X)回目のプログラム開発平均時間（時間/KS） YX ：X回目のプログラム開発平均時間（時間/KS）

  15. Ｙ：プログラム開発平均時間 教育１(EAGLE1) 教育２(EAGLE2) 100% Ｙ=154.9X-0.22 75% 50% Y3 Ｙ=121.8X-0.48 Y6 25% １　　２　　３　　　４　　　５　　６　　　７　　８　　　９　　10 Ｘ：プログラム開発経験回数 統合開発支援ツールの評価３ プログラム開発習熟曲線(Y) 成長率(E) 3回目(X=3)と6回目（2X=6）の生産性を比較 EAGLE機能拡張効果により成長率が12%向上した ・習熟曲線により反復訓練の教育効果を実測した． ・支援ツールの機能差によりEAGLE2の生産性は1.3倍で習熟率も高い． EAGL2では経験回数が４，５回で習熟率が上がる．

  16. ソフトウェア規模の試算見積

  17. 試算見積 フェーズ 企画 基本設計 詳細設計 製造 テスト 試算見積 概算見積 詳細見積 試算見積：企画・計画段階での見積で,　まだ詳細仕様は確定していない [メトリクス］ ［試算見積法］ コード行数（ステップ）　　経験法：個人の経験に依存するので精度が低い 開発言語/開発環境に依存する FP試算法：画面/帳票/ファイル数にFP単価を掛けて算出 FP (Function Point） FP要素見積法：処理形態を要素機能に分解してFP単価 　　　　　　　　　　　　　　　　　　　　　　　　　　　を掛けて算出 協調フィルタリング法：類似プロジェクトから予測 　　　　　　　　　　　　　　電力中研法：画面/帳票/ファイル数にFP単価を掛けて算出 UCP(Use Case Point) UCP法：ユースケースモデルのアクタ/ユースケースに 　　　　　　　　　　　　　　　　　　　　単価を掛けて算出 図4.8｢注文を出す｣ユースケース

  18. 類似度計算の例 変数 P1 ユークリッド距離 d Pn コサイン距離 α 変数 協調フィルタリング 嗜好抽出・情報推薦技術として研究されてきた事例ベース類推法のひとつで， データに欠陥値が含まれていても検索できるのが特長である． 書籍推薦の例 あらかじめユーザが 書籍を評価しておく 推薦対象ユーザと評価が似ている類似ユ ーザを選び出す 類似ユーザの評価を用いて推薦対象ユーザの評価を見積る 推薦対象ユーザの評価が高い場合，類似ユーザが評価した書籍を推薦する 事例 ・ユーザの行動履歴に基づく推薦：Amazon.com ,MSN Newsbot ・選択アイテムに基づく推薦：TSUTAYA,UNIQLO

  19. ： 欠陥データ ソフトウェア規模試算見積 試算見積の流れ プロジェクトPaの 規模を予測する プロジェクト実績データ ①プロジェクト実績データの準備 新規開発 開発言語：Java 画面数：30 帳票数：20 ②予測モデルの設定 ③検索アルゴリズムの設定 類似プロジェクト P１：４００FP P5：６００FP ④事例ベース検索による プロジェクト間類似度計算＊ 予測値 Paの規模予測 Pa規模；500 ⑤予測値計算＊ ＊：NAIST開発の見積ツールdocfbe 予測誤差を大きくする要因 ・ノイズデータ,信頼性の低いデータの混在 ・変数の設定，値の種別の設定 ・類似度/予測値計算アルゴリズム 本研究のアプローチ ・正当なデータの準備 ・最適な変数と値種別の探索 ・最適な検索アルゴリズムの探索

  20. 試算見積の流れ 日立システムのプロジェクトデータからソフトウェア規模(FP値） を実測したプロジェクトを抽出した（N=85) ①プロジェクト実績データの準備 ②予測モデルの設定 6種類の変数による予測モデルを設定した ・カテゴリ変数：数値表現出来ない変数 ・開発言語：「Jaba,.Net系｣｢VB系」「その他」 ・一般システム特性：FP法国際団体IFPUGが 規定した特性 ③検索アルゴリズムの設定 探索ツール（5000ケースを生成）を開発して、最適な計算式を探した 決定アルゴリズムr1 探索 ツール

  21. 試算見積の評価方法 全プロジェクト（N=85)総当り方式で実績FP値と予測FP値を比較した 見積対象プロジェクト 比 較 P1予測規模 協調フィルタリング 見積ツールdocfbe ｼｽﾃﾑ特性を3種類のデータで評価した ・数値変数(DI=[0，5])、 ・カテゴリ変数 　６値表現(DI=[VALUE0，VALUE5]) 　２値表現(DI=(LOW，HIGH))

  22. ソフトウェア規模試算見積の評価１ 標準：NAISTが設定した見積ツール docfbeの標準アルゴリズム Pred25：相対誤差0.25以下 　　　　　の件数の割合 MRE0.28と実用化レベルの予測が出来た 一般ｼｽﾃﾑ特性の値表現で差が出た ・ソフトウェア規模試算見積に協調フィルタリング法の有効性を確認した． ・高い精度の試算見積には以下の研究が今後の課題である． 　　①変数と最適検索アルゴリズムのルール抽出技術 　　②実績データの計測技術（例：ソースコード→FP値）

  23. ソフトウェア規模試算見積の評価２ FP試算法のひとつであるNESMA法と比較した 相対誤差平均(MRE ) NESMA法 協調フィルタリング法 NESMA法 協調フィルタリング法 ・すべての指標で協調フィルタリング法が優れている． ・相対誤差平均の偏差分布では，22件（全体の26%）がNESMA法の結果が　優れている． NESMA法：試算FP＝(更新系ファイル数×35)＋(参照系ファイル数×15) NESMA (Netherlands Software Metrics Users Association）

  24. ユースケースモデル ユースケース記述 ユースケース １．顧客が｢注文を出す｣ボタンを押す ２．システムは情報入力画面を表示する ３．顧客は商品コードを入力する　 ４．システムは入力された商品コードから 商品を検索する アクタ 注文を出す ユースケースポイント法による試算見積 ユースケースモデルから規模を試算するUCP計測支援ツールU-ESTの開発 UCP = AW + UW AW = アクタ数 × 重み UW = ユースケース数 × 重み UCP計測支援ツールU-EST ユースケース モデル アクタタイプの自動分類 分類ルール：４ ユースケースタイプの自動分類 分類ルール：７ UCP ルール例： ユースケース記述でキーワード と合致する割合の多いものを アクタタイプとする キーワードリスト

  25. ユースケースポイント法試算見積の評価 UCP計測者の手動計測と支援ツールU-ESTの自動計測を比較した 不一致1件はトラン ザクション数が境界 線を挟んだユースケ ース検出による． 不一致2件は外部ｼｽﾃﾑのアクタ． ・アクタ，ユースケース共，高い一致率を得た． ・ケーススタディ（特に大規模システム）の蓄積とキーワード、U-ESTの改良が課題である．

  26. むすび 研究成果 1.情報システム開発方法論と統合開発 　支援ツールの開発 ・開発方法論を標準化してグループに展開した ・ソフト部品によるプログラム自動生成を実現した 　（生成率70%～80%，品質30%向上） ・教育効果を測定して教育の重要性を示した 　（習熟曲線により経験４，5回で習熟する） 2.ソフトウェア規模の試算見積 ・協調フィルタリング法による試算見積の実用性 (相対誤差平均0.28）を測定した ・ユースケースポイント自動計測支援ツールを 　開発して有効性（一致率0.8～1.0)を確認した 3.リバースエンジニアリングによる業務仕様 　理解支援 今後の研究方針 1.開発方法論の拡充 上流工程の開発技法・支援ツールの研究． ・業務要件のﾓﾃﾞﾙ化とモデルの評価・検証技法 ・非機能要件(信頼性、安全性等）の設計技法 2.試算見積の実用化研究 実績データの自動取得・蓄積・再利用技術． ・成果物（ソース等）→実績FP/UCP計測技術 3.エンピリカルソフトウェア工学 ・プロジェクトデータ自動収集技術 ・プロジェクトコクピット（診断・警告）技術 ・プロジェクト分析の法則・理論抽出技術 定常的にプロジェクト実績データを収集・分析 して，そこから知見を発見して現場にフィードバックするエンピリカルアプローチは重要である．

More Related