見積もりの精度 Accuracy of Estimation：The Rational Edge（4/4 ページ）

[Denton Tarbet（プロジェクト管理／プランニングコンサルタント），Galorath Incorporated]

Rational-SEER-Rational：ソフトウェア開発ライフサイクルの統合

　以下、補足としてSEER for Softwareの概説を行う（編集部）。

　 標準の「ソフトウェア開発ライフサイクルプロセス」はプロジェクトデザイン、見積もり、リソースアロケーション、そしてトラッキングを自動化する。「IBM Rational Software Modeler」「SEER for Software」、そして「IBM Rational Portfolio Manager」のシームレスな統合はこのプロセスを包括的にサポートする。

ステップ1：仮コンセプトの評価：決行か中止か？

　SEER for Softwareを使えば、数千の完了プロジェクトから集約した大規模で拡張可能なプロジェクト知識ベースにより、概念レベルでプロジェクトを定義できる。SEERは、大規模なプロジェクト履歴に基づいてあっという間にソフトウェアプロジェクトをシミュレートし、コスト、作業、納期、そしてリスクの当初の大まかな見積もりを計算できる。

ステップ2：ソフトウェアデザインの開発

　プロジェクトの決行が決まったら、ビジネスプロセスデザインとシステム要件の取得、ユースケースの用意、そしてユースケースから実行イメージコードへの変換をIBM Rational開発ツールが支援する。

ステップ3：詳細見積もりの作成

　「Rational Software Modeler」「Rational Software Architect」、あるいは「Rational Software Developer」のデザインをSEERに書き出して当初の見積もりを洗練させ、広範なトレードオフ分析を行い、プロジェクトの可変要素（単独および組み合わせ）を修正し、図3のようにして最適なデザイン手法を判断する。幹部らに具体的なプロジェクトの目的達成率と、基盤の制約や仮定をわずかに変更するだけでそれが改善できることを示す。

図3 SEER for Software（上の画面/クリックで拡大）とIBM Rational Developmentツール（下の画面/クリックで拡大）のスキャンは、複数のオプションを評価し、ソフトウェアデザインの洗練と最適化に役立つ

ステップ4：リソースの割り当てとポートフォリオの管理

　最終承認したSEERの見積もりを（プロジェクトとプログラムデータを一元管理するために）IBM Rational RPMに書き出し、組織全体においてリソースと優先事項を長期にわたって最適に管理すること、重複しているリソースも十分に活用されていないリソースもないこと、そしてプロジェクトの遅延によってリソースのコンフリクトが発生する場所を確定させる（図4）。

図4 SEER for SoftwareのProject Monitoring、Control（上の画面）とRational Portfolio Manager（下の画面）は、プロジェクトとプログラムデータの一元管理や、プロジェクトパフォーマンスのトラッキング、そしてプロジェクトにおけるリソースと優先事項の最適な管理を保証する（クリックで拡大）

ステップ5：プロジェクトの期限厳守

　SEERでは、実際のプロジェクトパフォーマンスや進展を結果（スケジュール、リソース、および欠陥）と比較測定することができる。途中で修正が必要な場合、ユーザーは、目的で大きく妥協することなくプロジェクトを軌道に戻すのに最適な是正措置を判断することができる。プロジェクトの結果は、プロセス改善のためのフィードバックに利用可能で、プロジェクト履歴のデータベースやレポジトリに組み入れることもできる。

指定通りのプロジェクトが時間内／予算内／期限内に完成

　IBMとGalorathソリューションは共同で、ソフトウェア開発組織が自分たちのプランニングプロセスを自動化および遂行できるようにするシームレスなソリューションを提供している。

• 完成度の高いシームレスなソリューションをソフトウェア開発ライフサイクル全体に提供
• 組織によるコスト、商品化までの時間、機能のトレードオフの理解と最適化を支援
• クラス最高の見積もり機能（コスト、スケジュール、作業、リスク、および信頼性）を提供
• 社内全体で標準化された見積もりのベストプラクティスを実現
• 事業部門と技術プロバイダーで共通の言語を使うことにより協調して意思決定を推進
• 予想されたコスト、スケジュール、人員配備目標への準拠状況を測定するプロジェクト基準を提供することでガバナンス構想を支援
• プロジェクトプロセスと結果を時間の経過に伴い確実に向上させる

---

本記事は「The Rational Edge」に掲載された「On time and on budget, as specified: An integrated approach to the Software Development Lifecycle」をアットマーク・アイティが翻訳したものです。

---

「The Rational Edge」バックナンバー

• トランザクション管理の複雑性を克服する（パート1）
• アジャイルとシステムテストの新たな関係（後編）
• アジャイルとシステムテストの新たな関係（前編）
• アジャイル開発の広範な普及を目指して
• 見積もりの精度 Accuracy of Estimation
• 複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
• 複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
• 鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
• 人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
• 自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
• プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
• 開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
• 反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
• 開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
• 開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
• 初歩の「Perl」「Python」「Ruby」
• ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
• 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
• UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
• UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
• 「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
• プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
• 専門家に聞くモデル駆動開発のメカニズム
• 「設計」や「構築」よりも重宝されるスキル
• キミのコードが汚い理由
• 汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
• 汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
• ウォーターフォールから反復型への移行手順
• ソフトウェアアーキテクティングのメリット
• ソフトウェアアーキテクティングのプロセス
• ソフトウェアアーキテクトの役割
• ソフトウェアアーキテクチャって何なの？（後編）
• ソフトウェアアーキテクチャって何なの？（前編）
• ITプロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）