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

1Software 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 年）


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

課題・生産性と品質の確保　　　・プロジェクト管理が困難　　　・業務仕様の確定が困難　　　・正確な見積が困難

目標１：ソフトウェア開発プロセスの　　　　　標準化と一貫支援ツール目標２：既存ソフトウェアの再利用目標３：ソフトウェア規模の早期見積

基幹情報システムの開発は、開発規模は大きく、多数・多様な要員が参加する大規模プロジェクトになる．

　研究内容　　１．基幹情報システム開発方法論と統合開発支援ツール　　２．リバースエンジニアリングによる業務仕様理解支援　　３．ソフトウェア規模の試算見積　　　　・協調フィルタリング技術による試算見積　　　　・ユースケースポイント法による試算見積


研究業績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

第４章


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

統合開発支援ツール


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

開発方法論HIPACE

標準手順・フェーズドアプローチ標準手順(SPDS)　　　　　　・スパイラルアプローチ標準手順　　　　　　・オブジェクト指向標準手順開発技法・データ分析技法　　　　　　・構造化技法　　　　　　・部品開発 / 利用技法　　　　　　・リポジトリ利用技法　　　　　　・リエンジニアリング技法　　　　　　・オブジェクト指向技法

・大規模開発に対応した確実な開発→フェーズドアプローチ・安定性のある情報システムの開発　→ DOA （ Data Oriented Approach ：データ中心型アプローチ）

統合開発支援ツール

EAGLE

背景

・受託ソフトウェア開発量の増大による開発現場の混乱・手工業的開発手法の行き詰まり

標準化・開発工程・開発手順・ドキュメント・開発技法・開発基準


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

企画

システムテスト

基本設計

ソフト

ウェア

テスト

運用準備・移行

詳細設計

・製造

運用テスト

フェーズ

ステップ名作業名作成ﾄﾞｷｭﾒﾝﾄ成果物担当

製造設計書ﾌﾟﾛｸﾞﾗﾑ設計書作成ﾌﾟﾛｸﾞﾗﾑ機能図ﾌﾟﾛｸﾞﾗﾑ設計書ﾌﾟﾛｸﾞﾗﾑ

作成図状態遷移図ｸﾗｽ､ A 社

関数仕様書

ﾚﾋﾞｭｰ / 承認結果報告書ﾚﾋﾞｭｰ A 社

設計書ﾌﾟﾛｸﾞﾗﾑ A は

ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ作成ﾌﾟﾛｸﾞﾗﾑﾁｪｯｸﾘｽﾄﾌﾟﾛｸﾞﾗﾑﾁｪｯｸﾘｽﾄ A 社

ｺｰﾃﾞｨﾝｸﾞｿｰｽｺｰﾄﾞ A社単体ﾃｽﾄ票ﾊﾞｸﾞ､ A 社

修正票仕様変更票､

結果報告書作成ﾃｽﾄ品質表、報告書 A社承認結果報告書ﾃｽﾄ B社

チェックリスト

作成基準

コーディング基準

WBS による作業の詳細化

品質管理基準

フェー

ズ計画

終了

フェーズドアプローチ

作業

ドキュメントの統一

責任の明確化


データ中心型アプローチDOAデータは、設計情報の中で安定しているので、データ中心で開発すれば高い品質と保守性が得られる．

現行業務データ調査ドメイン分析

業務データモデリング制約分析

標準データ項目定義データ辞書登録

　 [ データ分析の手順 ]

名称 ,形式 ,意味

ドメイン：制約条件を持つ値の集合（標準定義域）制約：形式制約 ,値制約 ,導出制約 , 関連制約標準データ名称：実体名 +属性名 +ドメイン名

ドメイン名称

実体（）ｴﾝﾃﾃｨリレーション

データ制約

標準データ名称

名称標準データ名称

社員誕生年月日

別名社員誕生日

データ記号名 SHAINBIRTHDAY意味社員の誕生日

属性データタイプ整数

長さ６処理

データチェック

実在日チェック

入力編集和暦⇒西暦変換

出力編集西暦⇒和暦変換

データ辞書

・データと処理プロセスのカプセル化による　ソフトウェアの重複排除・部品化による生産性と保守性の向上


統合開発支援ツール EAGLE

システム設計プログラム設計・作成テスト

ファイル /レコード定義

画面・帳票定義

データベース定義

画面遷移定義

コード定義

DFD編集システムフロー編集

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

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

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

EAGLE1

ＤＢスキマ定義

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

Ｃ /Ｓ論理設計図定義

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

EAGLE2 EAGLE3

ＥＲ図⇒ＳＱＬ部品生成

業務ルール部品

ＰＡＤテスタ

スケルトン機能部品

データ処理部品

構造図（ＰＡＤ）編集

ソース静的解析

テストケース生成

ソーステスタ

テストコマンド生成

テストデータ生成

ＰＡＤ⇔プログラム生成


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

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

事務処理プログラムの制御構造をパターン化した骨組み（スケルトン）　・スケルトンのカスタマイズはしない　・追加コーディング部分は局所化されているので　　品質が高いプログラムができる　・スケルトンは特定のファイル /ＤＢから独立している

終了処理

出力処理

帳票編集処理

入力処理

初期処理

帳票作成

入力ファイル

帳票

集計処理

集計前処理

集計後処理

追加コーディング

帳票作成スケルトン

バッチスケルトン

ファイル変換・編集・更新・チェック

22種類

帳票作成

(例 ) 日付計算部品　　　・誕生日⇒年齢計算　　　・日付妥当性チェック　　　・うるう年の判定　　　・日付⇒曜日計算　　　・期間中の通算日数計算

ＥＡＧＬＥ１：機能部品機能部品：よく使うコードの部品化　日付計算、単位変換など

・類似部品 /重複部品の発生・部品適用を設計者が判断

課題

DOA データ処理部の部品化（ EAGLE2 データ処理部品）


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

ＥＡＧＬＥ２：データ処理部品ＥＡＧＬＥ３：業務ルール部品

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

名称

数量

金額

日付

時刻

時間

コード

番号

区分

フラグ

日付チェック部品

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

過去日チェック（西暦）

未来日チェック（西暦）

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

日付編集部品

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

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

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

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

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

235種類

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

値制約：営業店小口出金金額＜＝ 10,000　⇒業務ルール：営業店での小口の出金は、１件に　　　　　　　　　　つき１万円以下でなければならない導出制約：受注合計金額=商品標準単価×受注明細数量　⇒業務ルール：受注明細の合計金額は、商品の　　　　　　　　　　　標準単価と受注数量の積である関連制約：ＩＦ　顧客住所コード＞=１００ＥＬＳＥ　商品輸送金額 =商品輸送定額金額 +1000 ⇒業務ルール：顧客住所が離島 (100以上）なら　　　　　　　　　　商品輸送金額は定額料金に 1000　　　　　　　　　　円増しの金額である


統合開発支援ツールの評価１生産性評価

プログラム生成率＝LgLt

Lg：統合開発支援ツールが生成したプログラムの量Lt ：プログラム全体の規模 ( コメントを含む )フェーズ EAGLE１ EAGLE２ EAGLE３

プロジェクト A B C D E

バッチ帳表作成 69% 98% 6

2%86% 7

2%ファイル処理

78% 97% 74%

データチェック

50% 73% 77%

オンライン

問合せ，更新

74% 77% 72%

P層： 0%

F層： 44%

D層： 98%

46%43%99%

データ入力 50% 72% 52%

平均生成率 68% 81% 71%

バッチの生成率は高い

Ｗｅｂ３層モデルではＰ層/Ｆ層の生成率向上が課題

・バッチは，と部品により高い生成率を維持しているが，オンラインはアーキテクチャｽｹﾙﾄﾝ　に依存するので生成率向上が課題である．・ EAGLE1 vs EAGLE2ではデータ処理部品の効果により＋ 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 ：組合せテストレベル　タイプ３：その他 )

・標準テストケース作成支援機能により単体テストでのバグ出しが増加し、組合せテストの　品質が向上した．・業務仕様を確認するシステムテストや運用テストの支援技術の研究が課題である．


統合開発支援ツールの評価３習熟性評価プログラム開発習熟曲線 (Y) 　　　　　 Y： X 回目のプログラム開発平均時間（時間 /KS ）　　　　 Y=aX-n 　 a ： 1回目のプログラム開発平均時間（時間 /KS ）　　　　　　　　　　　　 X：プログラム開発経験回数　　　　　　　　　　　　 n ：効果係数

成長率 (E) 　　　　 E ： X 回目と２ X 回目のプログラム開発平均時間の比率　　　　 Y2X ： (2X)回目のプログラム開発平均時間（時間 /KS ）　　　　 YX ： X 回目のプログラム開発平均時間（時間 /KS ）

E=Y2X

YX


統合開発支援ツールの評価３　プログラム開発習熟曲線 (Y)

Ｘ：プログラム開発経験回数１　　２　　３　　　４　　　５　　６　　　７　　８　　　９　　 10

Ｙ：プログラム開発平均時間

Ｙ =154.9X-0.22

Ｙ =121.8X-0.48

75%

50%Y3

Y625%

100%　　教育１ ( EAGLE1)　　教育２ (EAGLE2)

開発作業教育１教育２

成長率(E)

プログラムコーディング

86% 69%

テストケース設計　　　　　＆単体

テスト

83% 74%

単体テストのみ

- 83%

ドキュメンテーション

86% 72%

合計 86% 72%

成長率 (E)

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

EAGLE 機能拡張効果により成長率が12%向上した

・習熟曲線により反復訓練の教育効果を実測した．・支援ツールの機能差により EAGLE2 の生産性は 1.3倍で習熟率も高い．　 EAGL2では経験回数が４，５回で習熟率が上がる．


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


試算見積

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

[ メトリクス］

コード行数（ステップ）　　経験法：個人の経験に依存するので精度が低い　　　　　　　　　　　　　　　　　　　開発言語 / 開発環境に依存する　　　　　　　　　　　　　　 FP 試算法：画面 /帳票 / ファイル数に FP単価を掛けて算出FP (Function Point ） FP 要素見積法：処理形態を要素機能に分解して FP単価　　　　　　　　　　　　　　　　　　　　　　　　　　　を掛けて算出　　　　　　　　　　　　　　協調フィルタリング法：類似プロジェクトから予測　　　　　　　　　　　　　　電力中研法：画面 /帳票 / ファイル数に FP単価を掛けて算出

UCP(Use Case Point) UCP 法：ユースケースモデルのアクタ / ユースケースに　　　　　　　　　　　　　　　　　　　　単価を掛けて算出

［試算見積法］

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

企画基本設計製造フェーズ詳細設計テスト

試算見積概算見積詳細見積


協調フィルタリング嗜好抽出・情報推薦技術として研究されてきた事例ベース類推法のひとつで，データに欠陥値が含まれていても検索できるのが特長である．

書籍推薦の例

あらかじめユーザが書籍を評価しておく

推薦対象ユーザと評価が似ている類似ユーザを選び出す

類似ユーザの評価を用いて推薦対象ユーザの評価を見積る

推薦対象ユーザの評価が高い場合，類似ユーザが評価した書籍を推薦する

類似度計算の例

　

変数 P1

α

d

変数

Pn コサイン距離

ユークリッド距離

事例・ユーザの行動履歴に基づく推薦： Amazon.com ,MSN Newsbot・選択アイテムに基づく推薦： TSUTAYA,UNIQLO


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

プロジェクト実績データ

：欠陥データ

プロジェクト Paの規模を予測する新規開発開発言語： Java画面数： 30帳票数： 20

Pa の規模予測Pa 規模； 500

類似プロジェクト

P １：４００FPP5 ：６００ FP予測値

④事例ベース検索によるプロジェクト間類似度計算＊

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

⑤予測値計算＊

試算見積の流れ

①プロジェクト実績データの準備②予測モデルの設定

種別言語画面数

帳票数

規模

P1 新規 Java 40 10 　 400

P2 C++ 25 40 600

P3 拡張 COBOL 20 300

P4 新規 100 200 900

P5 新規 Java 20 20 600

P6 拡張 VB 100

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

予測誤差を大きくする要因・ノイズデータ ,信頼性の低いデータの混在・変数の設定，値の種別の設定・類似度 /予測値計算アルゴリズム

本研究のアプローチ・正当なデータの準備・最適な変数と値種別の探索・最適な検索アルゴリズムの探索


試算見積の流れ

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

①プロジェクト実績データの準備②予測モデルの設定

日立システムのプロジェクトデータからソフトウェア規模 (FP値）を実測したプロジェクトを抽出した（ N=85)

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

変数種別欠陥率

１対応業種カテゴリ（ 11種類 )

0%

２開発言語カテゴリ (3種類 )

0%

３画面数数値 13%

４帳票数数値 13%

５ファイル数数値 0%

６一般システム特性 (14種類 )

数値 17%

・カテゴリ変数：数値表現出来ない変数・開発言語：「 Jaba,.Net系｣｢ VB系」「その他」・一般システム特性： FP 法国際団体 IFPUGが規定した特性探索ツール（ 5000 ケースを生成）を開発して、最適な計算式を探した

類似度計算

8種類（コサイン，相関係数，順位相関，距離と変数の平均値ﾕｰｸﾘｯﾄﾞ /中央値の組

合せ）

予測値計算

10種類 (類似プロジェクト / 見積規模の加重平均 /中央値 ,倍率修正値の組合せ）

探索ツール

相関係数 (平均値）とﾕｰｸ距離（中央値）のﾘｯﾄﾞ

按分

類似プロジェクトの加重平均と倍率修正の中央値

決定アルゴリズム r1


試算見積の評価方法全プロジェクト（ N=85)総当り方式で実績 FP値と予測 FP値を比較した

P1 業種言語画面数帳票数ﾌｧｲﾙ特性ｼｽﾃﾑ規模

P2 業種言語画面数帳票数ﾌｧｲﾙ特性ｼｽﾃﾑ規模

P3 *** *** *** *** *** *** ***

P4 *** *** *** *** *** *** ***

P5 *** *** *** *** *** *** ***

・ *** *** *** *** *** *** ***

・ *** *** *** *** *** *** ***

P85 *** *** *** *** *** *** ***

見積対象プロジェクト

協調フィルタリング見積ツール docfbe

P1予測規模

比較

特性1

データ通信特性 8 オンライン更新

特性2

分散処理特性 9 複雑な処理

特性3

性能特性 10

再利用可能性

特性4

高負荷構成特性 11

インストール容易性

特性5

トランザクション量

特性 12

運用性

特性6

オンラインデータ入力

特性 13

複数サイト

特性7

エンドユーザ利便性

特性 14

変更容易性

特性をｼｽﾃﾑ 3種類のデータで評価した・数値変数 (DI=[0， 5]) 、・カテゴリ変数　６値表現 (DI=[VALUE0， VALUE5])　２値表現 (DI=(LOW， HIGH))


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

検索アルゴリズム決定 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

Pred25 56.5%

43.5%

37.7%

30.6%

標準： NAIST が設定した見積ツール　　　　 docfbe の標準アルゴリズム

Pred25 ：相対誤差 0.25以下　　　　　の件数の割合

類似度コサイン（変数の平均値）

予測値類似プロジェクト（加重平均）＋倍率修正値（加重平均）

MRE0.28と実用化レベルの予測が出来た一般特性の値表現で差が出たｼｽﾃﾑ

・ソフトウェア規模試算見積に協調フィルタリング法の有効性を確認した．・高い精度の試算見積には以下の研究が今後の課題である．　　①変数と最適検索アルゴリズムのルール抽出技術　　②実績データの計測技術（例：ソースコード→ FP値）


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

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 法の結果が　優れている．


ユースケースポイント法による試算見積ユースケースモデルから規模を試算する UCP 計測支援ツール U-EST の開発

UCP = AW + UW

AW = アクタ数 × 重み UW = ユースケース数 × 重み

アクタ

タイプ説明重みユ｜スケ｜ス

タイプ説明重み

単純定義済み API を備えた別システム１単純トランザクション数が 3 個以下

５

平均的プロトコル駆動のインタフェース(別システム )，テキストベースのインタフェース (人間 )

２平均的トランザクション数が 4 個から 7 個

１０

複雑 GUI を介する人間３複雑トランザクション数が 8 個以上

１５ユースケースモデル

キーワードリスト

注文を出す

アクタユースケース

ユースケース記述１．顧客が注文を出すボタンを押｢｣

す２．システムは情報入力画面を表示する３．顧客は商品コードを入力する　４．システムは入力された商品コードから商品を検索する

ユースケースモデル

UCP 計測支援ツール U-EST

アクタタイプの自動分類

分類ルール：４

ユースケースタイプの自動分類

分類ルール：７

UCPルール例：ユースケース記述でキーワードと合致する割合の多いものをアクタタイプとする


ユースケースポイント法試算見積の評価UCP 計測者の手動計測と支援ツール U-EST の自動計測を比較した

プロジェクト

アクタユースケース手動 U-EST

一致率手動 U-EST

一致率単純

平均

複雑

単純

平均

複雑

単純

平均

複雑

単純

平均

複雑

A １０４０１４０．８１３

２０１３

２０１．０

B ３０２２１２０．８１０

４０１０

４０１．０

C ００２００２１．０１４

６０１２

８００．９

D １０４１０４１．０２７

１０２７

１０１．０

E ００８００８１．０２８３２８３１．０

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

不一致 1件はトランザクション数が境界線を挟んだユースケース検出による．

・アクタ，ユースケース共，高い一致率を得た．・ケーススタディ（特に大規模システム）の蓄積とキーワード、 U-EST の改良が課題である．


むすび

研究成果1.情報システム開発方法論と統合開発　支援ツールの開発・開発方法論を標準化してグループに展開した・ソフト部品によるプログラム自動生成を実現した　（生成率 70%～ 80%，品質 30%向上）・教育効果を測定して教育の重要性を示した　（習熟曲線により経験４， 5回で習熟する）2.ソフトウェア規模の試算見積・協調フィルタリング法による試算見積の実用性　 (相対誤差平均 0.28）を測定した・ユースケースポイント自動計測支援ツールを　開発して有効性（一致率 0.8～ 1.0) を確認した3.リバースエンジニアリングによる業務仕様　理解支援

今後の研究方針1.開発方法論の拡充　上流工程の開発技法・支援ツールの研究．・業務要件の化とモデルの評価・検証技法ﾓﾃﾞﾙ・非機能要件 (信頼性、安全性等）の設計技法2.試算見積の実用化研究　実績データの自動取得・蓄積・再利用技術．・成果物（ソース等）→実績 FP/UCP 計測技術3.エンピリカルソフトウェア工学

・プロジェクトデータ自動収集技術・プロジェクトコクピット（診断・警告）技術・プロジェクト分析の法則・理論抽出技術

定常的にプロジェクト実績データを収集・分析して，そこから知見を発見して現場にフィードバックするエンピリカルアプローチは重要である．

Documents

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

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