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

(1)

基幹情報システム開発のための

生産技術及び見積技術に関する研究

大学院情報科学研究科

コンピュータサイエンス専攻井上研

究室

_{津田　道夫}

(2)

2

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

1970 年：日立製作所入社（流通 SE 部門→生産技術部門→コンサルティング部門）

1999 年：日立システムアンドサービス転属（産業･流通 SE 部門→生産技術部門）

システムエンジニア (SE) 　

　

20 年

産業・流通業担当

・建設業工事管理システム

・税理事務所向け会計シス

テム

・海運コンテナヤードシス

テム

ソフトウェア生産技術の研究･開発

　

17 年

・情報システム開発方法論の開発

・統合開発支援ツールの開発

・リバースエンジニアリング技術の

開発

・データ / ビジネスモデリング技術

の開発

阪大ー日立製作所 / 日立システム共同研究　 1990 年～現在

研究テーマ　・ソフトウェア分散開発　　　・ソフトウェア開発プ

ロセス　

　　　　　　　・ソフトウェア規模見積技術（ FP/UCP 自動計測技

術）

・産学官連携 EASE プロジェクトの参加（ 2003 年）

・阪大ソフトウェアデザイン工学高度人材育成コアの参加（ 2005

年）

・関西 9 大学連携 IT 人材育成講座 ITspiral の参加（ 2006 年）

(3)

研究の目的・内容

基幹情報システム：企業・行政機関の活動を支える情報基盤

課題・生産性と品質の確保

　　　・プロジェクト管理

が困難

　　　・業務仕様の確定が

困難

　　　・正確な見積が困難

目標１：ソフトウェア開発プロ

セスの

　　　　　標準化と一貫支援

ツール

目標２：既存ソフトウェアの再

利用

目標３：ソフトウェア規模の早

期見積

基幹情報システムの開発は、開発規模は大きく、多数・多様な要員が参加する

大規模プロジェクトになる．

　研究内容

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

　　２．リバースエンジニアリングによる業務仕様理解支援

　　３．ソフトウェア規模の試算見積

　　　　・協調フィルタリング技術による試算見積

　　　　

・ユースケースポイント法による試算見積

(4)

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

第３章

大杉直樹、松本健一、津田道夫、中屋広樹、十九川博幸、“協調フィルタリ

ング技術によるソフトウェア規模の予測、”日立システムジャーナル、第六巻、

(5)

基幹情報システム開発方法論

と

(6)

6 基幹情報システム開発方法論 HIPACE

開発方法論

HIPACE

標準手順・

PDS)

フェーズドアプローチ標準手順 (S

　　　　　　・スパイラルアプローチ標準手

順

　　　　　　・オブジェクト指向標準手順

開発技法・

データ分析技法

　　　　　　・構造化技法

　　　　　　・部品開発 / 利

用技法

　　　　　　・リポジトリ利

用技法

　　　　　　・リエンジニア

リング技法

　　　　　　・オブジェクト

指向技法

・大規模開発に対応した確実な開発→

フェーズドアプローチ

・安定性のある情報システムの開発

　

→

DOA （ Data Oriented Approach ：データ中心型アプローチ）

統合開発

支援ツール

EAGLE

背

景

・受託ソフトウェア開発量の増大による開発現場の混乱

・手工業的開発手法の行き詰まり

標準化

・開発工程

・開発手順

・ドキュメ

ント

・開発技法

・開発基準

(7)

フェーズドアプローチ標準手順 (SPDS)

企

画

システム

テスト

基本設計

ソフ

ト

ウェ

ア

テス

ト

運用

準備

・

移行

詳細

設計

・製造

運用

テス

ト

フェー

ズ

ステップ名

作業名

作成ﾄﾞｷｭﾒﾝﾄ

成果物

担当

製造

ﾌﾟﾛｸﾞﾗﾑ設計書

ﾌﾟﾛｸﾞﾗﾑ設計書作成

ﾌﾟﾛｸﾞﾗﾑ機能図

ﾌﾟﾛｸﾞﾗﾑ設計書

作成

ｸﾗｽ図､状態遷移図

A 社

関数仕様書

ﾚﾋﾞｭｰ / 承認

ﾚﾋﾞｭｰ結果報告書

A 社

ﾌﾟﾛｸﾞﾗﾑ設計書

A は

ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ

ﾌﾟﾛｸﾞﾗﾑﾁｪｯｸﾘｽﾄ作成

ﾌﾟﾛｸﾞﾗﾑﾁｪｯｸﾘｽﾄ

A 社

ｺｰﾃﾞｨﾝｸﾞ

ｿｰｽｺｰﾄﾞ

A

社

単体ﾃｽﾄ

ﾊﾞｸﾞ票､

A 社

修正票､仕様変更票

ﾃｽﾄ結果報告書作成

品質表、報告書

A

社

承認

ﾃｽﾄ結果報告書

B 社

チェックリス

ト

作成基準

コーディ

ング基準

WBS による作業の詳細化

品質

管理基準

フ

ェ

ー

ズ

計

画

終

了

フェーズドアプローチ

_作

業

ドキュメントの

統一

責任の

明確化

(8)

8 データ中心型アプローチ DOA

データは、設計情報の中で安定しているので、データ中心で開発すれ

ば高い

品質と保守性が得られる．

現行業務データ調

査

ドメイン分析

業務データモデリ

ング

制約分析

標準データ項目定

義

データ辞書登録

　 [ データ分析の手

順 ]

名称 , 形式 , 意味

ドメイン：制約条件を持つ値の集合（標準定義域）

制約：形式制約 , 値制約 , 導出制約 , 関連制約

標準データ名称：実体名 + 属性名 + ドメイン名

ドメイン名称

実体（ｴﾝﾃﾃｨ）

リレーション

データ制約

標準データ名称

名称

標準データ名

称

社員誕生年月日

別名

社員誕生日

データ記号名

SHAINBIRTHDAY

意味

社員の誕生日

属性

データタイプ

整数

長さ

６ 処理

データチェッ

ク

実在日チェック

入力編集

和暦⇒西暦変換

出力編集

西暦⇒和暦変換

データ辞

書

・データと処理プロセスのカプセル

化による

　ソフトウェアの重複排除

・部品化による生産性と保守性の向

上

(9)

統合開発支援ツール EAGLE

システム設計

プログラム設計・作成

テスト

ファイル / レコード定義

画面・帳票定義

データベース定義

画面遷移定義

コード定義

DFD

編集

システムフロー編集

ソフトウェア部品による

プログラム生成

データモデル図（ＥＲ図）定

義

分散オブジェクト論理設計図

定義

EAGLE1

ＤＢスキマ定義

DFD⇒ システムフロー自動生

成

Ｃ / Ｓ論理設計図定義

オブジェクト指向分析・設計

定義

EAGLE2 EAGLE3

ＥＲ図⇒ＳＱＬ部品生成

業務ルール部

品

ＰＡＤテスタ

スケルトン

機能部品

データ処理部

品

構造図（ＰＡＤ）

編集

ソース静的解析

テストケース生成

ソーステスタ

テストコマンド生

成

テストデータ生成

ＰＡＤ⇔プログラム生成

(10)

10 ソフトウェア部品によるプログラム生成

１ ＥＡＧＬＥ１：スケルトン

事務処理プログラムの制御構造をパターン化

した

骨組み（スケルトン）

　・スケルトンのカスタマイズはしない

　・追加コーディング部分は局所化されてい

るので

　　品質が高いプログラムができる

　・スケルトンは特定のファイル / ＤＢから

独立している

終了処理

出力処理

帳票編集処理

入力処理

初期処理

帳票作成

入力ファイル

帳票

集計処理

集計前処理

集計後処理

追加コーディング

帳票作成スケルトン

バッチ

スケルト

ン

ファイル変換・編集・更新・

チェック

22 種

類

帳票作成

( 例 ) 日付計算部品

　　　・誕生日⇒年齢計算

　　　・日付妥当性チェック

　　　・うるう年の判定

　　　・日付⇒曜日計算

　　　・期間中の通算日数計算

ＥＡＧＬＥ１：機能部品

機能部品：よく使うコードの部品化

　日付計算、単位変換など

・類似部品 / 重複部品の発生

・部品適用を設計者が判断

課題

DOA データ処理部の部品化

（ EAGLE2 データ処理部品）

(11)

ソフトウェア部品によるプログラム生成

２ ＥＡＧＬＥ２：データ処理部品

ＥＡＧＬＥ３：業務ルール部品

データ項目のドメイン共通処理を部品

化

ドメイ

ン

名称

数量

金額

日付

時刻

時間

コード

番号

区分

フラグ

日付チェック部品

実在日チェック（西暦 ) と

（和暦）

過去日チェック（西暦）

未来日チェック（西暦）

年月日範囲内チェック（西

暦）

日付編集部品

年月日変換（西暦⇔和暦）

年月日算出（西暦年月日 ± 日

数 )

期間算出（西暦年月日間日

数）

月末日算出（西暦年月日）

通算週算出（年始～西暦年月

日）

235 種類

データ項目の制約を部品化

値制約：

営業店小口出金金額＜＝ 10,000

　⇒業務ルール：営業店での小口の出金は、

１件に　　　　　　つき１万円以下で

なければならない

導出制約

：

受注合計金額 = 商品標準単価 × 受注明細数量

　⇒業務ルール：受注明細の合計金額は、商

品の　　　　　　　標準単価と受注数

量の積である

：

ＩＦ　顧客住所コード＞ = １００

ＥＬＳＥ　商品輸送金額 = 商品輸送定額金額 +1

000 ⇒ 業務ルール：顧客住所が離島 (100 以上）

なら

　　　　　　商品輸送金額は定額料金

に 1000

　　　　　　円増しの金額である

(12)

12 統合開発支援ツールの評価１

生産性評価

プログラム生成率＝

Lg

Lt

Lg ：統合開発支援ツールが生成したプログ

ラムの量

Lt ：プログラム全体の規模 ( コメントを含

む )

フェーズ

EAGLE

１ EAGLE

２ EAGLE

３ プロジェクト

A

B

C

D

E

バッチ

帳表作成

_69%

_98%

_62%

_86%

_72%

ファイル処

理

78%

97%

74%

データ

チェック

50%

73%

77%

オンライ

ン

問合せ，

更新

74%

77%

72%

P 層：

_0%

F 層：

4 4%

D 層：

9 8%

46%

43%

99%

データ入力

_50%

_72%

_52%

平均生成率

_68%

_81%

_71%

バッチの生成

率は高い

Ｗｅｂ３層モ

デルではＰ層

/

Ｆ層の

生成率向上が

課題

・バッチは，ｽｹﾙﾄﾝと部品により高い生成率を維持しているが，オンラインはアーキテクチャ

　に依存するので生成率向上が課題である．

・ EAGLE1 vs EAGLE2 ではデータ処理部品の効果により＋ 13% 向上した．

(13)

統合開発支援ツールの評価２

品質評価

Ft

Lt

不良密度＝

Ft ：不良件数

_{Lt ：プログラム全体の規模 ( コメントを含む )KS}

フェーズ

EAGLE2

プロジェクト

F

G

不

良

密

度

単体テス

ト

3.7 4.8

組合せテス

ト

2.9 2.2

合計

_{6.6 7.0}

単体テスト用テストケース作成支援を適用したプロジェクト G の効果

プロジェクト F 　　　 1.54 件 /KS 　　　　　 0.68 件

/KS 　 0.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 　

　　タイプ 3

(

タイプ 1 ：単体テストレベル

　タイプ 2 ：組合せテストレベル　タイプ３：その他 )

・標準テストケース作成支援機能により単体テストでのバグ出しが増加し、組

合せテストの

　品質が向上した．

・業務仕様を確認するシステムテストや運用テストの支援技術の研究が課題で

ある．

(14)

14 統合開発支援ツールの評価３

習熟性評価

プログラム開発習熟曲線 (Y)

　　　　　

Y ： X 回目のプログラム開発平均時間（時間 /K

S ）

　　　　 Y=aX-

n

　 a ： 1 回目のプログラム開発平均時間（時間 /KS ）

　　　　　　 X ：プログラム開発経験回数

　　　　　　 n ：効果係数

成長率 (E)

　　　　 E ： X 回目と２ X 回目のプログラム開発平均時間の

比率

　　　　 Y

_2X

： (2X) 回目のプログラム開発平均時間（時間 /K

S ）

　　　　 Y

_X

： X 回目のプログラム開発平均時間（時間 /K

S ）

E=

Y

_Y

2X

X

(15)

統合開発支援ツールの評価３

　

プログラム開発習熟曲線 (Y

)

Ｘ：プログラム開発経験回数

１　　２　　３　　　４　　　５　　６　　　７　

　８　　　９　　 10

Ｙ：プログラム開発平均

時間

Ｙ =154.9X

-0.

22 Ｙ =121.8X

-0.

48 75%

50%

Y3

Y6

25%

100%

　　

₁₎

教育１ (

EAGLE

　　

教育２

(

EAGLE

2)

開発作業

教育１

教育２

成

長

率

(E

)

プログラムコー

ディング

86%

69%

テストケース設計

　　　　　＆単体

テスト

83%

74%

単体テストの

み

-

83%

ドキュメンテー

ション

86%

72%

合計

_86%

_72%

成長率 (E)

3 回目 (X=3) と 6 回目（ 2X=6 ）の生産性を比較

EAGLE 機能拡張効果により成長率が 1

2% 向上した

・習熟曲線により反復訓練の教育効果を実測した．

・支援ツールの機能差により EAGLE2 の生産性は 1.3 倍で習熟率も高い

．

　

EAGL2 では経験回数が４，５回で習熟率が上がる．

(16)

16

(17)

試算見積

試算見積：企画・計画段階での見積で , 　まだ詳細仕様は確定していない

[ メトリクス］

コード行数（ステップ）　　経験法：

個人の経験に依存するので精度が低い

　　　　　　　

開発言語 / 開発環境に依存する

　　　　　　 FP 試算法：

画面 / 帳票 / ファイル数に FP 単価を掛けて算出

FP (Function Point ） FP 要素見積法：

処理形態を要素機能に分解して FP 単価

　　　　　　　を掛けて算出

　　　　　　

協調フィルタリング法

：類似プロジェクトから予測

　　　　　　電力中研法：

画面 / 帳票 / ファイル数に FP 単価を掛けて算出

UCP(Use Case Point)

UCP 法

：ユースケースモデルのアクタ / ユースケースに

　　　　　　単価を掛けて算出

［試算見積法］

図 4.8 　｢注文を出す｣ユースケース

企画

基本設計

製造

フェーズ

詳細設計

テスト

試算見積

概算見積

詳細見積

(18)

18 協調フィルタリング

嗜好抽出・情報推薦技術として研究されてきた事例ベース類推法のひ

とつで，

データに欠陥値が含まれていても検索できるのが特長である．

書籍推薦の例

あらかじめユーザが

書籍を評価しておく

価が似ている類似ユ

ーザを選び出す

類似ユーザの評価を

用いて推薦対象ユー

ザの評価を見積る

価が高い場合，類似

ユーザが評価した書

籍を推薦する

類似度計算の例

変数

P1

α

d

変数

Pn

コサイン距離

ユークリッド距離

事例

・ユーザの行動履歴に基づく推薦： Amazon.com ,MSN Newsbot

・選択アイテムに基づく推薦： TSUTAYA,UNIQLO

(19)

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

プロジェクト実績デー

タ

：欠陥デー

タ

プロジェクト Pa

の

規模を予測する

_新規開発

開発言語： Jav

a

画面数： 30

帳票数： 20

Pa の規模予

測

Pa 規模； 500

類似プロジェクト

P

_１

：４００

FP

P

₅

：６００ F

P

予測値

④ 事例ベース検索による

プロジェクト間類似度

計算＊

③ 検索アルゴリズムの設定

⑤ 予測値計算＊

試算見積の流れ

① プロジェクト実績データ

の準備

② 予測モデルの設定

種別

言語

画

面

数

帳

票

数

規模

P

1

新規

Java

40 10 　 40

0 P

₂

C++

25

40

600 P

3

拡張

COBOL

20

300 P

4

新規

100

200

900 P

5

新規

Java

20

600 P

6

拡張

VB

100 ＊： NAIST 開発の見積ツール docfbe

予測誤差を大きくする要因

・ノイズデータ , 信頼性の低いデータの混在

・変数の設定，値の種別の設定

・類似度 / 予測値計算アルゴリズム

本研究のアプローチ

・正当なデータの準備

・最適な変数と値種別の探索

・最適な検索アルゴリズムの探索

(20)

20 試算見積の流れ

③ 検索アルゴリズムの設定

① プロジェクト実績データ

の準備

② 予測モデルの設定

日立システムのプロジェクトデータからソフトウェア規模 (FP 値）

を実測したプロジェクトを抽出した（ N=85)

6 種類の変数による予測モデルを設定した

変数

種別

欠陥率

１対応業種

カテゴリ（ 11

種類 )

0%

２開発言語

カテゴリ (3 種

類 )

0%

３画面数

数値

13%

４帳票数

数値

13%

５ファイル数

数値

0%

６一般システム特性 (14

種類 )

数値

17%

・カテゴリ変数：数値表現出来ない変数

・開発言語：「 Jaba,.Net 系｣｢ VB 系」

「その他」

・一般システム特性： FP 法国際団体 IFP

UG が

規定した特性

探索ツール（ 5000 ケースを生成）を開発して、最適な計算式を探した

類似度

計算

8 種類（コサイン，相関係数，順位相関，

ﾕｰｸﾘｯﾄﾞ距離と変数の平均値 / 中央値の組

合せ）

予測値

計算

10 種類 ( 類似プロジェクト / 見積規模の加

重平均 / 中央値 , 倍率修正値の組合せ）

探索

ツール

相関係数 ( 平均値）と

ﾕｰｸ

ﾘｯﾄﾞ距離（中央値）の

按分

類似プロジェクトの加

重

平均と倍率修正の中央

値

決定アルゴリズム r1

(21)

21 試算見積の評価方法

全プロジェクト（ N=85) 総当り方式で実績 FP 値と予測 FP 値を比較した

P

1

業種

言語

画面数

帳票数

ﾌｧｲﾙ

ｼｽﾃﾑ特性

規模

P

2

業種

言語

画面数

帳票数

ﾌｧｲﾙ

ｼｽﾃﾑ特性

規模

P

3

***

P

4

***

P

5

***

・

***

・

***

P

85

***

見積対象プロジェクト

協調フィルタリング

見積ツール docfbe

P

₁

予測規模

比

較

特性 1 データ通信

特性 8

オンライン更新

特性 2 分散処理

特性 9

複雑な処理

特性 3 性能

特性 10 再利用可能性

特性 4 高負荷構成

特性 11 インストール容

易性

特性 5 トランザクション

量

特性 12 運用性

特性 6 オンラインデータ

入力

特性 13 複数サイト

特性 7 エンドユーザ利便

特性 14 変更容易性

ｼｽﾃﾑ特性を 3 種類のデータで評価した

・数値変数 (DI=[0 ， 5]) 、

・カテゴリ変数

　６値表現 (DI=[VALUE0 ， VALUE5])

　２値表現 (DI=(LOW ， HIGH))

(22)

22 ソフトウェア規模試算見積の評価１

検索アルゴリズム

決定 r1

標準

一般ｼｽﾃﾑ特性の値

２ 値

６ 値

数値２値

評

価

指

標

相対誤差平均 (MRE )

0.2

8

0.3

3 0.43 1.03

相対誤差中央 (MedRE

)

0.2

2

0.2

8 0.30 0.42

相対誤差分散 (VRE)

0.2

7

0.2

8 0.52 3.20

相関係数 (Corr )

0.9

4

0.9

4 0.94 0.93

Pred25

56. 5%

43. 5%

37. 7%

30. 6%

標準： NAIST が設定した見積ツール

　　　　 docfbe の標準アルゴリズム

Pred25 ：相対誤差 0.25 以下

　　　　　の件数の割合

類似度

コサイン（変数の平均

値）

予測値

類似プロジェクト（加重

平均）

＋倍率修正値（加重平

均）

MRE0.28 と実用化レベルの予測が出

来た

一般ｼｽﾃﾑ特性の値表現で差が出た

・

ソフトウェア規模試算見積に協調フィルタリング法の有効性

を確認した．

・高い精度の試算見積には以下の研究が今後の課題である．

　　①変数と最適検索アルゴリズムのルール抽出技術

　　②実績データの計測技術（例：ソースコード→ FP 値）

(23)

ソフトウェア規模試算見積の評価２

NESMA 法

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%

協調フィルタリング法

FP 試算法のひとつである NESMA 法と比較した

相対誤差平均 (MRE )

NESMA 法

協調フィルタリング法

NESMA 法：試算 FP ＝ ( 更新系ファイル数 ×35) ＋ ( 参照系ファイル数 ×15)

NESMA (Netherlands Software Metrics Users Association ）

・すべての指標で協調フィルタリング法が優れている．

・相対誤差平均の偏差分布では， 22 件（全体の 26% ）が NESMA 法の結果が　優

れている．

(24)

24 ユースケースポイント法による試算見積

ユースケースモデルから規模を試算する UCP 計測支援ツール U-EST の開

発

UCP = AW + UW

AW = アクタ数 ×

重み

UW = ユースケース数 ×

重み

ア

ク

タ

タイプ

説明

重み

ユ

｜

ス

ケ

｜

ス

タイプ

説明

重み

単純

定義済み API を備えた別システム

１ 単純

トランザクション数が 3 個

以下

５ 平均的

プロトコル駆動のインタフェース

( 別システム ) ，

テキストベースのインタフェース (

人間 )

２ 平均的

トランザクション数が 4 個

から 7 個

１０ 複雑

GUI を介する人間

３ 複雑

トランザクション数が 8 個

以上

１５ ユースケース

モデル

キーワードリスト

注文を出

す

アクタ

ユースケース

ユースケース記

述

１．顧客が｢注文を出す｣ボタンを押

す

２．システムは情報入力画面を表示

する

３．顧客は商品コードを入力する　

４．システムは入力された商品コー

ドから

商品を検索する

ユースケースモデル

UCP 計測支援ツール U-EST

アクタタイプ

の自動分類

分類ルール：

４ ユースケースタ

イプの自動分類

分類ルール：７

UCP

ルール例：

ユースケース記述でキーワード

と合致する割合の多いものを

アクタタイプとする

(25)

ユースケースポイント法試算見積の評価

UCP

計測者の手動計測と支援ツール U-EST の自動計測を比較した

プ

ロ

ジ

ェ

ク

ト

アクタ

ユースケース

手動

U-EST

一致率

手動

U-EST

一致率

単

純

平

均

複

雑

単

純

平

均

複

雑

単

純

平

均

複

雑

単

純

平

均

複

雑

A

１０４０１４

０．８

１

３

２０

１

３

２０ １．０

B

３０２２１２

０．８

１

０

４０

１

０

４０ １．０

C

００２００２

１．０

１

４

６０

１

２

８０ ０．９

D

１０４１０４

１．０

２

７

１０

２

７

１０ １．０

E

００８００８

１．０

２８３

２８３ １．０

不一致 2 件は外部ｼｽﾃﾑのアクタ．

不一致 1 件はトラ

ン

ザクション数が境

界

線を挟んだユース

ケ

ース検出による．

・アクタ，ユースケース共，高い一致率を得た．

・ケーススタディ（特に大規模システム）の蓄積とキーワード、 U-EST の改良が課題である．

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

基幹情報システム開発のための

生産技術及び見積技術に関する研究

大学院情報科学研究科

コンピュータサイエンス専攻 井上研

究室

津田 道夫

2

1970 年：日立製作所入社（流通 SE 部門→生産技術部門→コンサルティング部門）

1999 年：日立システムアンドサービス転属（産業･流通 SE 部門→生産技術部門）

システムエンジニア (SE)

20 年

産業・流通業担当

・建設業工事管理システム

・税理事務所向け会計シス

テム

・海運コンテナヤードシス

テム

ソフトウェア生産技術の研究･開発

17 年

・情報システム開発方法論の開発

・統合開発支援ツールの開発

・リバースエンジニアリング技術の

開発

・データ / ビジネスモデリング技術

の開発

阪大ー日立製作所 / 日立システム共同研究 1990 年～現在

研究テーマ ・ソフトウェア分散開発 ・ソフトウェア開発プ

ロセス

・ソフトウェア規模見積技術（ FP/UCP 自動計測技

術）

・産学官連携 EASE プロジェクトの参加（ 2003 年）

・阪大ソフトウェアデザイン工学高度人材育成コアの参加（ 2005

年）

・関西 9 大学連携 IT 人材育成講座 ITspiral の参加（ 2006 年）

研究の目的・内容

基幹情報システム：企業・行政機関の活動を支える情報基盤

課題 ・生産性と品質の確保

・プロジェクト管理

が困難

・業務仕様の確定が

困難

・正確な見積が困難

目標１：ソフトウェア開発プロ

セスの

標準化と一貫支援

ツール

目標２：既存ソフトウェアの再

利用

目標３：ソフトウェア規模の早

期見積

基幹情報システムの開発は、開発規模は大きく、多数・多様な要員が参加する

大規模プロジェクトになる．

研究内容

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

２．リバースエンジニアリングによる業務仕様理解支援

３．ソフトウェア規模の試算見積

・協調フィルタリング技術による試算見積

・ユースケースポイント法による試算見積

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

コンピュータサイエンス専攻井上研

_{津田　道夫}

システムエンジニア (SE) 　

阪大ー日立製作所 / 日立システム共同研究　 1990 年～現在

研究テーマ　・ソフトウェア分散開発　　　・ソフトウェア開発プ

ロセス　

　　　　　　　・ソフトウェア規模見積技術（ FP/UCP 自動計測技

課題・生産性と品質の確保

　　　・プロジェクト管理

　　　・業務仕様の確定が

　　　・正確な見積が困難

　　　　　標準化と一貫支援

　研究内容

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

　　２．リバースエンジニアリングによる業務仕様理解支援

　　３．ソフトウェア規模の試算見積

　　　　・協調フィルタリング技術による試算見積

大杉直樹、松本健一、津田道夫、中屋広樹、十九川博幸、“協調フィルタリ

　　　　　　・スパイラルアプローチ標準手

　　　　　　・オブジェクト指向標準手順

　　　　　　・構造化技法

　　　　　　・部品開発 / 利

　　　　　　・リポジトリ利

　　　　　　・リエンジニア

　　　　　　・オブジェクト