Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (17)
Destaque
Destaque (20)
Semelhante a 19-B-4 開発品質向上のための、ASQ/ALMソリューション
Semelhante a 19-B-4 開発品質向上のための、ASQ/ALMソリューション (20)
Mais de Developers Summit
Mais de Developers Summit (20)
19-B-4 開発品質向上のための、ASQ/ALMソリューション
- 1. 開発品質向上のための、ASQ／ALMソ 開発品質向上のための、ASQ／ALMソ のための リューション ~品質向上策・活用していないのは何故ですか？~ 品質向上策・活用していないのは何故ですか？ していないのは何故ですか 19-B-4 藤原 祐之 ﾏｲｸﾛﾌｫｰｶｽ株式会社 技術部 Testing & ASQ/ALM ソリューション マネジャー Developers Summit 2010
- 2. 開発プロジェクトの現状 開発プロジェクトの現状 プロジェクトの 開発チームはビジネスの期待にそえるようなアプリケーションを提供すべく絶え間なく努力して いるが・・・ 繰返される問題 100% 15% 18% 19% 納期に間に合わない 28% 23% 24% ビジネスに合致しない （本来の目的を満たさない） 51% 46% 失敗 予算超過 53% 44% 49% 問題を 46% 問題を含む 結局、システムが期待通りに完 成功 成せず、ビジネスの失敗に 34% 35% 32% 26% 28% 29% 0% 1998 2000 2002 2004 2006 2009 Developers Summit 2010 2
- 3. プロジェクト成功率向上を目指して プロジェクト成功率向上を目指して 成功率向上 長期の景気低迷、予算削減が続く今だからこそ、プロジェクトを 黒字で終わらせることが最重要課題。 開発プロジェクトを納期内に問題なく納めるために、効果があると思 われる工夫は全て試してみる価値があるのではないでしょうか？ Developers Summit 2010 3
- 4. 統一されていない品質チェック体制の 統一されていない品質チェック体制の場合 されていない品質チェック体制 • 設計 開発 • テスト • 運用 • 要員投入による • Word、Excelによる • ソースコード • •負荷テスト •ドキュメント作成 ・要員の工数増大 手動によるテスト • ・人手によるテストのミス フリーツールによる • ドキュメント同士 •コードレビュー の関連がなく、管 理が属人化 フリーのテストツール • •による自動化 他ツールと連携が無い ・VerUPやバグ修正が無い ・情報の分断 ・他ツールと連携が無い ・連携機能を自作 手作業によるドキュメントおよびソースコードの管理 手作業もしくはフリーツールによる品質管理 ・上書きや削除によるファイル（データ）の損失 ・メンテナンス出来ないソースコードの山 ・過去ファイル（データ）の検索にかかる無駄な工数 ・フリーツールの調査、設定に工数が増大 一貫した品質管理が出来ず、管理工数も増大 Developers Summit 2010 4
- 5. 様々な品質管理手法 要求の 要求の開発 テスト自動化 テスト自動化 メトリクス分析 メトリクス分析 要求の 要求の構造化 テスト管理 テスト管理 コードカバレッジ 要件の 要件の管理 テストファースト ・・・ 要求ドリブン開発・テスト 要求ドリブン開発・テスト ドリブン開発 リスクベーステスト Agile開発 Agile開発 負荷テスト 負荷テスト 継続的インテグレーション 継続的インテグレーション コードインスペクション Developers Summit 2010 5
- 6. 活用されない理由？ 活用されない理由？ されない理由 聞いたことが無い いたことが無 試してみたが、上手くいかなかった してみたが、上手くいかなかった 役に立つとは思えない つとは思 やり方 やり方がわからない 調べたり、試したりする時間がない べたり、 したりする時間がない 時間 Developers Summit 2010 6
- 7. 活用までのステップ 活用までのステップ 守 指導者に方法を習い、教えを受けた内容が身につくまで繰り 返し作業に打ち込む。 破 今までの成果を保持しつつ、他の方法なども積極的に学び、 良いところは取り入れていく。 離 身につけたことを自分に合うように修正し、独自の方 法を生み出して更に磨きをかける。 Developers Summit 2010 7
- 8. マイクロフォーカスのASQ製品ソリューション ~Automated Software Quality~ • 設計 開発 • テスト • 運用 • 開発支援ツール • テスト自動化ツール • 継続的な品質チェック 継続的な品質チェック • インテグレーション • 開発の初期段階から、定期的な品質チェックを自動化することで 問題の早期発見と品質管理の効率化を実現。 Developers Summit 2010 8
- 9. マイクロフォーカスのALM製品ソリューション ~Application Lifecycle Management~ • 設計 開発 • テスト • 運用 • 要件分析 • モデリング • 開発支援 • テスト自動化 • 負荷テスト • •／管理 •ツール •ツール •ツール •ツール 要件・障害・テスト管理ツール ・ ・ ・ 構成管理ツール 統一した体制で品質を管理し、全体像を把握可能 Developers Summit 2010 9
- 10. 開発品質管理手法 Developers Summit 2010 10
- 11. ユースケースによるシナリオの構造化 ユースケースによるシナリオの構造化 従来の要件定義書 ユースケースによるシナリオ記述 ATMに関する要件 に する要件 ATMに関する要件 に する要件 1.システムは正当なPINを持ったユーザからの金銭要求 1. 事前条件 しか受け付けない。 •顧客は銀行のキャッシュカードを所有している 2.システムは各々の取引において、レシートを印刷する。 • 銀行のシステムに繋がっており、オンライン状態である 3.システムは現金引き出しに関連するメニューを表示す • システムは支払い用の現金を備えている る。 2. 主シナリオ 曖 1. ユーザはキャッシュカード キャッシュカードをATMに挿入する。 キャッシュカード 4.システムは、ユーザの口座に指定した引き出し金額を 昧 満たしているかチェックする。 2. システムはキャッシュカードから情報を読み取る。 な 3. キャッシュカードが使用可能か調べるために、“ユーザの 5.ユーザはレシート印刷出来ないことを知らされ、そのま 要 重 ま操作を続行するか尋ねられる。 認証”を行う。 件 複 6.システムはATMに設定されている金額以下しか支払う 4. システムはその時点で有効なメニュー 有効なメニュー 有効なメニューを表示する。 ことが出来ない。 5. ユーザは“引き出し”メニューを選択する。 7.システムはユーザにキャッシュカードを返却出来なくて 構造化 6. システムは既定の引き出し金額リストを表示意する。 はならない。 7. ユーザは引き出し金額を選択する。 8.システムはユーザにレシートを印刷するかどうか選択 8. 補助シナリオ“口座の残額をチェック”を呼び出す。 肢を与える。 9. 補助シナリオ“引き出しの実施”を呼び出す。 9.システムは口座に十分な金額があれば現金を支給す 10. システムはユーザのキャッシュカードを返却する。 る。 11. ユーザはキャッシュカードをとる。 順 12. システムはユーザに要求金額を支払う。 10.ATMは処理が完了したらカードを返却する。 序 11.システムが処理を実行するためには、銀行のシステ が 13. システムは引き出しのトランザクションログを記録する。 ムに繋がっていなければならない。 無 い ・余計な工数や手戻りが発生 ・前提条件などを、独立させて見やすく表記 ・意味を想像しながらシステムを設計せざるを得ない ・順序立てて、分かりやすい言葉で記述することで、ス ・ストーリー性が無いため、テストが困難に トーリー性を明確に ・ユーザの視点が欠けており、細かすぎる傾向 Developers Summit 2010 11
- 12. 要件の 要件の管理 イテレーション０ イテレーション０ イテレーション１ イテレーション２ イテレーション１ イテレーション２ ・・・・・ リポジトリ 相違点レポートによって変 相違点レポートによって変 レポートによって 更量を 更量を定量化 各イテレーション毎にベ イテレーション毎 ースラインを設定 ースラインを設定 ある時点での要件 時点での要件の ベースライン ： ある時点での要件の情報 名前を けてリポジトリに保存 保存。 を、名前を付けてリポジトリに保存。 現在の状態と 現在の状態と個々のベースラインとの違いをリストアップすることで、アプリケーション開発 のベースラインとの違いをリストアップすることで、アプリケーション開発 のライフサイクルにおける過剰 要件変更を抑止。 過剰な のライフサイクルにおける過剰な要件変更を抑止。 ＝＞例えば、変更はイテレーション単位で１０％以内に ＝＞例えば、変更はイテレーション単位で１０％以内に抑えるなど はイテレーション単位 Developers Summit 2010 12
- 13. 要求ドリブン開発・テスト 要求ドリブン開発・テスト ドリブン開発 要件の 要件の構造化 品質チェック 品質チェック テスト自動化 テスト自動化 運用監視 設計 • 開発 • テスト • 運用 • 継続的な品質チェック • インテグレーション • 要件の分析と管理を徹底し、システム開発が間違った方向に行くことを防止 要件の分析と管理を徹底し システム開発が間違った方向に くことを防止 開発 った方向 要件から正確に導出したテスト仕様により ユーザの要望 要件から正確に導出したテスト仕様により、ユーザの要望を満たしたシステムであることを から正確 したテスト仕様により、 要望を チェック、保証する チェック、保証する 性能面でのユーザ要望を早期に明確化し 問題が後期に発覚するのを でのユーザ要望 するのを防 性能面でのユーザ要望を早期に明確化し、問題が後期に発覚するのを防ぐ Developers Summit 2010 13
- 14. Agile開発 Agile開発 XP スクラム クリスタル その他 関係者間の円滑なコミュニ 関係者間の円滑なコミュニ 編成したチームで、 編成したチームで、同じゴー したチームで プロジェクトに関わる人数 人数と プロジェクトに関わる人数と ルを目指 目指す 重要度によって、対応する方 重要度によって、対応する方 によって する FDD ケーション ルを目指す 毎日、１５分のスクラム会議 法論を 法論を使用 DSDM ドキュメント、コード、 ドキュメント、コード、ルール 毎日、１５分のスクラム会議 などを極力 極力シンプルに などを極力シンプルに を 開く など 頻繁なテスト なテスト、 頻繁なテスト、レビューによ 製品、リリース、 製品、リリース、スプリントの 方法論自体を 使用しなが 方法論自体を、使用しなが るフィードバック バックログを作成 管理する 作成・ バックログを作成・管理する らレビュー＆チューニング。 らレビュー＆チューニング。 導入や変更を 導入や変更を受け入れ、実 など する勇気 施する勇気 ・イテレーション開発によるリスクの最小化 ・イテレーション開発によるリスクの最小化 開発によるリスクの ・コミュニケーションの円滑化による作業効率向上 円滑化による作業効率向上と ・コミュニケーションの円滑化による作業効率向上と Developers Summit 2010 14
- 15. クリスタル方法論 クリスタル方法論 重要度 • 人数の増加に 人数の増加に伴い、より大規模なク より大規模なク 大規模 リスタル方法論（右）を使用 リスタル方法論（ 方法論 Life L6 L20 L40 L80 • プロジェクトの重要度 プロジェクトの重要度に伴い、より厳 重要度に より厳 密なクリスタル方法論（上）を使用 なクリスタル方法論 方法論（ • 月以内のインクリメンタル のインクリメンタル開発 4か月以内のインクリメンタル開発 Essential E6 E20 E40 E80 money • 中間インクリメント反省会の インクリメント反省会 中間インクリメント反省会の実施 Discretionary D6 D20 D40 D80 money Comfort C6 C20 C40 C80 オレンジ レッド 関係者の 関係者の人数 イエロー クリア ・プロジェクトに関わる人数と重要度によって、対応する方法論を使用。 ・プロジェクトに関わる人数と重要度によって、対応する方法論を使用。 人数 によって する方法論 ・方法論自体を、使用しながらレビュー＆チューニングする。 方法論自体を 使用しながらレビュー チューニングする。 しながらレビュー＆ Developers Summit 2010 15
- 16. ツールによる継続的な品質チェック ツールによる継続的な品質チェック よる継続的 品質チェック 品質チェック 設計 開発 テスト 運用 継続的な品質チェック 継続的な品質チェック ・静的ソースコード解析によるコードインスペクション 静的ソースコード解析によるコードインスペクション ソースコード解析 問題を むコードを、初期段階から定期的に れなく検証 から定期的 – 問題を含むコードを、初期段階から定期的に漏れなく検証 – メトリクス値（メソッド複雑度）によって、メンテナンス性も可視化して定期的にチェ メトリクス値 メソッド複雑度）によって、メンテナンス性 可視化して定期的 複雑度 して定期的にチェ ック Developers Summit 2010 16
- 17. コードインスペクション 計画 準備 レビュー エラー修正 エラー修正 修正の 修正の検証 ・要求仕様・ユースケース 要求仕様・ユースケース ・ビジネスプロセス ・プロジェクト計画 ・プロジェクト計画 ・各種設計書 ・ソースコード ・テスト計画 ・テスト計画 ・・・ コードレビューによる問 コードレビューによる問 コードレビューによる修 コードレビューによる修 題点チェック 題点チェック 正確認チェック 正確認チェック • ソースコードのレビューはツールによる自動化が可能。 ソースコードのレビューはツールによる自動化が可能。 自動化 • ソースコードレビューで全ての問題を つけられる訳ではないが、工数の削減とチェ ソースコードレビューで全ての問題を見つけられる訳ではないが、工数の削減とチェ 問題 ック漏れの防止には大きな効果がある。 防止には 効果がある ック漏れの防止には大きな効果がある。 Developers Summit 2010 17
- 18. コードレビュー結果サンプル コードレビュー結果サンプル 結果 C#の解析結果サンプル C#の解析結果サンプル Javaの解析結果サンプル Javaの解析結果サンプル ・問題を起こす可能性があるソースを、開発の初期段階で検出 ・メトリクス値（複雑度）によって、メンテナンス性の低いコードを検出 Developers Summit 2010 18
- 19. メトリクス（複雑度） メトリクス（複雑度）分析 0 2 A0 euclid(int m, int n) 構文を解析し 構文を解析し、ノードと 0 1 3 { /* Assuming m and n both greater than 0. エッジの数 エッジの数を計算 1 4 * return their greatest common divisor. 2 5 * Enforce m >= n for efficiency. 3 6 */ 3 2 4 4 7 int r; 8 A1 if (n > m) { 5 9 A2 r = m; 5 6 MacCabeのの 6 10 A3 m = n; 11 A4 n = r; 複雑度 Cyclomatic複雑度 7 7 12 } 8 13 A5 A6 r = m % n; /* m modulo n */ 8 12 10 14 A7 while (r != 0) { 9 9 15 A8 m = n; 11 16 A9 n = r; 10 17 A10 r = m % n; /* m modulo n */ 18 A11 } 11 19 A12 return n; 13 12 20 A13 } 14 13 ノードエッジの数 ノードエッジの数 から複雑度 複雑度を から複雑度を計算 ・ソースコードの構造を分析し、メンテナンス性の悪さを数値化。 Developers Summit 2010 19
- 20. 継続的インテグレーションでのコードレビュー活用 継続的インテグレーションでのコードレビュー活用 インテグレーションでのコードレビュー ２０１X年 月 日 ２０１ 年X月X日 ２０１X年 月 日 ２０１ 年X月Y日 サブシステム アセンブリ のコードレビュー結果 のコードレビュー結果 のコードレビュー結果 のコードレビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 ・・・ レビュー結果 レビュー結果 レビュー結果 レビュー結果 ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・ ・ ・ ・ レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 レビュー結果 ・潜在エラーを事前にチェックし、次工程への持ち越しを防止 ・メトリクス値（複雑度）の数値化により、メンテナンス性の低いコーディング のままリリースさせない仕組みづくりが可能 Developers Summit 2010 20
- 21. コードカバレッジ結果サンプル コードカバレッジ結果サンプル 結果 行単位のカバレッジ結果 行単位のカバレッジ結果 のカバレッジ カバレッジの進捗状況グラフ カバレッジの進捗状況グラフ 進捗状況 ・テスト実行時に、実行済み行と未実行行を記録 ・テスト進捗状況を把握し、カバレッジ率を一定以上に保つことによってテスト品質を 管理、向上 Developers Summit 2010 21
- 22. ユニットテストとカバレッジを組 ユニットテストとカバレッジを組み合わせ、進捗率を管理 わせ、進捗率を ２０１X年 月 日 ２０１ 年X月X日 ２０１X年 月 日 ２０１ 年X月Y日 サブシステム アセンブリ のユニットテスト結果 のユニットテスト結果 のユニットテスト結果 のユニットテスト結果 カバレッジ カバレッジ カバレッジ カバレッジ ・・・ カバレッジ カバレッジ ・・ ・・ ・・ ・・ ・・ ・・ ・・ ・・ マージ結果 マージ結果 マージ結果 マージ結果 XMLカバレッジ結果 カバレッジ結果 カバレッジ XMLカバレッジ結果 カバレッジ結果 カバレッジ Excelなどを利用し などを利用し などを利用 てカバレッジ率 てカバレッジ率によ 進捗レポートを レポートを作 る進捗レポートを作 成 ・ユニットテスト時にカバレッジ情報を収集し 結果をマージすることで全体 ・ユニットテスト時にカバレッジ情報を収集し、結果をマージすることで全体 情報 をマージすることで のテスト進捗情報を 進捗情報 のテスト進捗情報を管理 22 Developers Summit 2010
- 23. 分散開発環境における変更／構成管理 分散開発環境における変更／ における変更 構成管理ツール「StarTeam」 構成管理ツール「StarTeam」 が、プロジェクトの開発資料および活動をリポジト プロジェクトの開発資料および活動をリポジト 開発資料および活動 リによって一元的 管理。チームが離れて作業する分散開発環境においても、 一元的に 作業する分散開発環境においても リによって一元的に管理。チームが離れて作業する分散開発環境においても、 チーム間のコミュニケーションを円滑化 チーム間のコミュニケーションを円滑化。円滑化。 Geographically Distributed Development 統合された資料および活動の管理 （分散環境での開発支援） Developers Summit 2010 23
- 24. 従来の開発とAgile開発のテスト配分 従来の開発とAgile開発のテスト配分 開発のテスト 従来の 従来の開発 開発 Agile開発 機能 テスト 機能 テスト 結合 結合 テスト テスト ユニット テスト ユニット テスト ・各フェーズのテストを、それぞれの特性にあったツールで自動化し、作業 フェーズのテストを、それぞれの特性にあったツールで自動化し 特性にあったツールで自動化 効率とシステム品質を向上。 とシステム品質 効率とシステム品質を向上。 Developers Summit 2010 24
- 25. テストの自動化 テストの自動化 テストの手順を記録、再生、チェックしてテストを自動化 • 同じ操作を繰り返すテスト（回帰テスト・スモークテスト）の効率を向上 • テスト結果をチェックすることにより精度の高いテストができる 一度目に録画。 テストの流 テストの流れ それ以降は再生 テスト テスト 同じテスト 計画 実施 OSのパッチ 使用DBの変更 など 機能 効果 テストを録画・再生 繰り返しテストの工数削減 発生箇所も指摘 デグレードの防止 Developers Summit 2010 25
- 26. 新たなテスト自動化方式 ~Silk４J~ たなテスト自動化方式 Silk４ 自動化 Javaによる画面操作系テストの による画面操作系テストの による画面操作系 で のテストケースとし EclipseでJunitのテストケースとし スクリプト てテストを作成 てテストを作成 操作記録 or 記述 調整 Junitの結果として確認 の結果として確認 として によるチェックを追加 ・Assertionによるチェックを追加 によるチェックを ・実行時にブラウザ種を選択 実行時にブラウザ にブラウザ種 実行 共通のスクリプトで 共通のスクリプトで、複数種ブラウザ →共通のスクリプトで、複数種ブラウザ のテストに対応 のテストに対応 を拡張し 画面系のテストファーストを実現。 のテストファーストを実現 ・UnitTestを拡張し、画面系のテストファーストを実現。 ＝＞.NET対応も進行中 ＝＞ 対応も 対応 Developers Summit 2010 26
- 27. リスクベーステスティング リスク低減が リスク低減が遅いバターン 低減 リスク コスト テスト 効率 リスク低減が リスク低減が早いバターン 低減 リスク コスト テスト テストを効果的 テストを効果的 効率 に実施 ・同じコストで、より効果的にリスクを減らすテストを実現。 Developers Summit 2010 27
- 28. リスクベーステスティング テスト可能範囲 テスト可能範囲 テスト不可範囲 テスト不可範囲 重要なテストが、 重要なテストが、 なテストが テスト漏 テスト漏れになる 可能性 リスク（重要度）によって順番づけを リスク（重要度）によって順番づけを 順番 テスト範囲 範囲を 行い、テスト範囲を調整 テスト可能範囲 テスト可能範囲 テスト不可範囲 テスト不可範囲 ・リソース（要員、マシン）がスケジュール内で実施可能な範囲に、リスク（重要度）の 高いテストを実施。 ＝＞重大な問題がテスト対象から外れるケースを、軽減することができる。 Developers Summit 2010 28
- 29. リスクベーステスティング ~Quality Optimizer~ ・サーバでテストケースを管理し、リスク係数を設定することによって、リソースとスケ ジュールに合ったテスト計画立案を支援。 Developers Summit 2010 29
- 30. テストケースの管理と テストケースの管理と自動実行 管理 自動テスト環境 自動テスト環境 テスト プロジェクトA プロジェクト 自動テスト 自動テスト テストケース１ テストケース１ 合格 （テストツール＋テストスクリプト） テストツール＋テストスクリプト） テストケース２ テストケース２ 不合格 実行/結果 実行 結果 ・・・ マニュアルテスト テストケース１ テストケース１ 合格 テストケース２ テストケース２ 不合格 ・・・ プロジェクトB プロジェクト 自動テスト 自動テスト テストケース１ テストケース１ 合格 サーバでテスト マニュアルテスト ケースカバレッ 情報を ジ情報を管理 テストケース２ テストケース２ 不合格 手動でのテスト でのテスト） （手動でのテスト） ・・・ マニュアルテスト テストケース１ テストケース１ 合格 テストケース２ テストケース２ 不合格 実行/結果 実行 結果 ・・・ ・テストケースをサーバでグループ化し、集中管理 ・指定したマシンでのテスト自動実行や、関連したテストの順次実行を管理 Developers Summit 2010 30
- 31. テストカバレッジ管理 テストカバレッジ管理 テストカバレッジ状況の確認 ・プロジェクト毎、テストグループ毎のテスト網羅率（カバレッジ）を監視 ・レポート機能によって、テスト進捗を明確化 Developers Summit 2010 31
- 32. 負荷テスト 負荷テスト 負荷をかけた時の問題箇所、改善対象 問題箇所の 問題箇所の割合 チューニングによる改善効果 チューニングによる改善効果 Webサーバ SQL Appサーバ データベース DB アプリケーション NW ハードウェア ・負荷をかけて問題が発生する場合、その多くがAppサーバであり、原因は SQLの作り方であるケースが多い。 ＝＞具体的に、問題箇所と原因を特定する方法は？ Developers Summit 2010 32
- 33. マイクロフォーカスの性能分析ソリューション マイクロフォーカスの性能分析ソリューション 性能分析 ツールによって、負荷をかけた時の問題を総合的に分析 仮想ユーザ DB Webサーバ アプリケーションサーバ Server Analysis Module JDBC-ODBC メインフレーム Web Method Method Service URL JSP-ASP MQ 「負荷テスト」によるサーバ状態の監視: • トランザクションとネットワークの負荷を、現実に近い状態でエミ ュレーション: • 各コンポーネントのパフォーマンス状態を関連させて分析 • パフォーマンスのボトルネックをピンポイントに指摘（メソッド、SQL、など） 33 Developers Summit 2010
- 34. マイクロフォーカスの性能分析ソリューション マイクロフォーカスの性能分析ソリューション 性能分析 負荷テストツール（SilkPerformer）の分析結果から、dynaTrace 機能のサーバ解析結果にドリルダウン ・負荷をかけるだけではなく、サーバの状態を分析してボトルネックをピンポ イントに検出。 Developers Summit 2010 34
- 35. まとめ ・開発、テストの作業を効率化し、品質を向上させるための方法 は、数多く提案されています。 ・品質向上策のどれかが、みなさんの開発現場において、非常 に大きな成果を出すことが出来るかもしれません。 ・開発プロジェクトを納期内に問題なく納めるために、最適な品質向上 策を見つけ、試し、成果を出して、拡張することを検討下さい。 Developers Summit 2010 35
- 36. Copyright © 2010 Micro Focus. All Rights Reserved. 記載の会社名、製品名は、各社の商標または登録商標です。 Developers Summit 2010