プロセスの基本

トピック
  1. 開発構想書 - 開発構想書の作成
  2. 計画- 計画の管理
  3. リスク- リスクの軽減と関連する問題点の追跡
  4. 開発企画書- 開発企画書の検証
  5. アーキテクチャー - コンポーネントに基づくアーキテクチャーの設計
  6. プロトタイプ- 製品の段階的なビルドとテスト
  7. 評価- 結果の定期的な評価
  8. 変更依頼- 変更の管理と制御
  9. ユーザー サポート- 使用可能な製品の導入
  10. プロセス- プロジェクトに合ったプロセスの採用

補足ガイダンス:


概論ページの先頭へ

ソフトウェアを扱う場合に常に問題となる、品質の高いソフトウェアの提供とソフトウェアの迅速な提供との間の微妙な調和を達成するかぎは、プロセスの重要な要素を理解することと、プロセスのカスタマイズに関するガイドラインに従って、プロジェクトの特定のニーズに適切に対応することです。ソフトウェア開発プロジェクトの成功に役立つことが業界全体で証明されている最善の実践原則に準拠して、作業を実施します。   

効果的なソフトウェア開発プロセスの基本的な原則を次に説明します。

1. 開発構想書 - 開発構想書の作成ページの先頭へ

明確な開発構想書の作成は、  利害関係者の真のニーズを満たす製品を開発する上で特に重要です。

RUP では、成果物: 開発構想書で高レベルの要求と設計上の制約の把握が可能になり、開発するシステムに対する理解が深まります。また、プロジェクトの承認プロセスに情報を提供するため、開発企画書と密接に関連します。 開発構想書は、プロジェクトに関連する基本的な「なぜ」と「何」に関わりを持ち、今後下される決断に対し、それが有効なものかどうかを計る尺度となります。

開発構想書はその他の関連するすべての要求の成果物と共に、次の質問に答えるものでなければなりません。これらの質問は、必要に応じて個別の詳細な成果物に分けられる場合があります。

  • 重要な用語は何であるか。 (用語集)
  • 解決しようとしている問題は何であるか。 (問題説明)
  • 誰が利害関係者であるか。 誰がユーザーであるか。 ユーザーのニーズは何であるか。
  • 製品機能は何であるか。
  • 機能要求は何であるか。 (ユース ケース)
  • 機能外要求は何であるか。
  • 設計上の制約は何であるか。

明確な開発構想書と理解しやすい要求の成果物セットの作成は、../../process/workflow/ovu_req.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません要求の作業分野最善の実践原則: 要求管理の重要な要素です。この作業には、問題の分析、利害関係者のニーズの理解、システムの定義、変化に応じた要求の管理などがあります。   

2. 計画- 計画の管理

「製品の良し悪しは、その製品の計画の良し悪しに完全に依存するものである」 (参考資料FIS96)。

新しいプロジェクトの立案、開発範囲とリスクの評価、プロジェクトの監視と管理、各反復とフェーズの計画と評価などは、../../process/workflow/ovu_mgm.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんプロジェクト管理の作業分野の 「重要な要素」 です。

ソフトウェア開発計画書には、プロジェクトの管理に必要な情報が収められています。 SDP は、プロジェクトのスケジュールを計画し、必要な要員を確保し、スケジュールに対する進捗を追跡するために使用します。 プロジェクトの編成、スケジュール、予算、要員などの分野を扱います。   要件管理、構成管理、問題解決、品質保証、評価およびテスト、製品検収などを包含する場合もあります。

簡単なプロジェクトでは、これらの多くはそれぞれ 1 つまたは 2 つの文にまとめられる可能性があります。たとえば、構成管理計画書では次のように簡単に述べます: 「毎日の終わりに、プロジェクト ディレクトリ構造の内容は、圧縮され、日付付きでラベルの付いた圧縮ディスクにコピーされ、バージョン番号を付与されて、中央のファイル キャビネットに配置されます」。

計画の成果物の形式は、計画書を作成する作業とそれに盛り込む内容ほど重要ではありません。形式は、概観がどのようなものでも構いませんし、どのようなツールを使用しても構いません。Dwight D. Eisenhower は、「たかが計画書、されど計画書」と述べています。

3. リスク- リスクの軽減と関連する問題点の追跡

プロジェクトの初期に、関連するその他の問題点と共に、最も高いリスク項目を割り出して除去し、その後を追跡することが重要です。  リスク リスト は、リスクを把握してプロジェクトを成功に導くことを目的とします。ここでは、深刻な結果を生む可能性のあるイベントが、重要度の高い順に整理されます。

各リスクの割り出しと共に、そのリスクを軽減する計画を立案する必要があります。リスク リストは、プロジェクトの作業の中心となり、組織立った反復を決定する基準となります。

4. 開発企画書- 開発企画書の検証

開発企画書 はビジネスの観点から、このプロジェクトに投資する価値があるかどうかを決定するのに必要な情報を提供します。

開発企画書の主な目的は、プロジェクトの開発構想書を実現するための、経済的な計画を作成することです。 作成された開発企画書は、プロジェクトの投資効果 (ROI) を正しく評価するために使用します。 開発企画書によって、プロジェクトの正当性を明確にし、経済的な制約を確立します。 また、経済面での意思決定者に、プロジェクトの経済効果について情報を提供し、プロジェクトを推進するかどうかの判断材料とします。

この説明は問題の詳細に深く立ち入るべきではなく、どうしてこの製品が必要かという説得力のある議論を展開すべきです。 ただし、これは短くし、プロジェクト チームの全メンバーが理解して覚えられるよう、十分簡単にする必要があります。 重要なマイルストーンに達するたびに、開発企画書を調べてコストと収益の見積もりが正しいかチェックし、プロジェクトを継続するかどうか再検討します。

5. アーキテクチャー - コンポーネントに基づくアーキテクチャーの設計ページの先頭へ

Rational Unified Process (RUP) においては、ソフトウェア システムの (ある時点での) アーキテクチャーは、システムの主要なコンポーネントの組織または構造です。 その主要なコンポーネントはインターフェイスを通じてより小規模なコンポーネントやインターフェイスから構成されるコンポーネントと相互に作用し合います。  主要な部分は何でしょうか。 これらをどのように組み合わせるのでしょうか。 残りのソフトウェアを追加する際の基盤となるフレームワークはありますか。

ソフトウェア アーキテクチャーについて説明するためには、アーキテクチャーの重要な側面を表現する手段であるアーキテクチャーの表現方法を最初に定義する必要があります。 この定義は、複数のビューでアーキテクチャーを表すソフトウェア アーキテクチャー説明書に取り入れられます。

各アーキテクチャー ビューでは、開発過程で利害関係者が関心を抱く、特定のひとまとまりの事項を取り上げます。そのような利害関係者とは、エンドユーザー、設計者、管理者、システム エンジニア、保守担当者などです。ソフトウェア アーキテクチャー説明書は、プロジェクトで行われるアーキテクチャー上重要な決断に関して、ソフトウェア アーキテクトとその他のチーム メンバー間のコミュニケーションの手段として利用します。

アーキテクチャーの候補の定義、アーキテクチャーの改良、振る舞いの分析、およびシステムのコンポーネントの設計は、分析と設計の作業分野最善の実践原則: アーキテクチャーとコンポーネントの利用の「重要な要素」です。

6. プロトタイプ- 製品の段階的なビルドとテストページの先頭へ

RUP は、製品の実行可能なバージョンのビルド、テスト、評価に対する反復型の手法であり、問題の洗い出しとリスクおよび問題の解決を早期に行うことを目的としています。

システム コンポーネントの段階的なビルドとテストは、実装の作業分野、../../process/workflow/ovu_test.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテストの作業分野、最善の実践原則: 反復的な開発の「重要な要素」です。

7. 評価- 結果の定期的な評価

進行中の作業から直接発生した客観的なデータを継続的に参照すること、製品構成を展開することは、どのようなプロジェクトにおいても重要です。   通常のステータス評価書は、管理と技術上の問題やプロジェクトのリスクを特定し、伝達し、解決するメカニズムを提供します。   問題の把握に加え、各問題には、解決に責任を持つ責任者と共に期限日を割り当てる必要があります。  問題は定期的に追跡し、必要により更新する必要があります。

これらのプロジェクトのスナップショットにより、管理における注意力が強化されます。 期間はさまざまなため、強制機能ではプロジェクトの履歴が把握され、解決されて、進行を妨げる障害やボトルネックが除去される必要があります。

反復評価書では、反復の結果、評価基準がどれくらい満たされているか、教訓と実装される変更を把握します。

反復評価書は反復アプローチには不可欠の成果物です。 プロジェクトの開発範囲とリスク、反復の本質によって、反復評価書の内容は、シンプルなデモンストレーションと結果の記録から、すべての正式なテストのレビュー記録まで多岐に渡ります。

ここで重要な点は、製品の問題だけでなく問題の処理に着目することです。「後手に回るほど、追いつくには時間がかかります」。

8. 変更依頼- 変更の管理と制御ページの先頭へ

ユーザーに最初のプロトタイプが提供されるとすぐに (また、その前であっても)、変更が要求されます (世の中で最も確実なものの 1 つ)。これらの変更を管理し、プロジェクトの範囲および利害関係者の期待を効果的に管理するために、開発成果物へのすべての変更は変更依頼を通じて提案され、一貫したプロセスで管理する必要があります。

変更依頼は、障害、拡張依頼など、製品に対するあらゆるタイプの変更の依頼を記録し、追跡するために使用します。 変更依頼の利点は、決定事項の記録が残ることです。 さらに、その評価プロセスによって、プロジェクト全体に、確実に変更の影響を周知できます。 変更依頼は、プロジェクトの開発範囲の管理と提案された変更の影響の評価にとって重要です。

目標を維持し、すべての利害関係者のニーズを考慮して対応しながら、プロジェクトのライフサイクルを通じて変更が発生するたびに、その変更に応じてどのような大きさであってもプロジェクトの範囲を管理します。これは、構成と変更管理の作業分野最善の実践原則: 変更管理の「重要な要素」です。

9. ユーザー サポート- 使用可能な製品の導入ページの先頭へ

プロセスの目的は、使用可能な製品を生産することです。  プロセスのすべての局面は、この点を念頭に置いてカスタマイズする必要があります。  通常、製品が単一的なソフトウェアであることは少ないと言えるでしょう。  最低限、オンライン・ヘルプを介して実装されるユーザー ガイドが必要です。  また、インストール ガイドとリリース ノートも加える可能性があります。   製品の複雑さに応じて、トレーニング教材、製品パッケージと共に部品構成表も必要です。

10.プロセス- プロジェクトに合ったプロセスの採用ページの先頭へ

開発する製品に合ったプロセスを選択することが重要です。プロセスを選択した後でも、そのプロセスにむやみに従う必要はありません。プロセスとツールは、常識と経験に照らし、組織とプロジェクトのニーズを満たすように構成する必要があります。

プロジェクトに合ったプロセスの採用は、../../process/workflow/ovu_env.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません環境の作業分野で重要な部分です。

プロジェクトと組織での RUP の採用について詳しくは、「../../process/workflow/environm/co_polpr.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません概念: RUP のカスタマイズ」を参照してください。

まとめページの先頭へ

以上の基本は、プロセスの迅速な評価と最も改善の利点のある領域を特定する手段を提供します。これらの基本のいずれかを無視した場合に何が発生するか考察することは重要です。次に例を示します。

  • 開発構想書がない場合、目標を見失い、すぐに回り道して迷ってしまう可能性があります。
  • 共通のプロセスがない場合、チーム内の意思の疎通が阻害され、それぞれの役割分担について誤解が発生する場合があります。
  • 計画書がない場合、進行を追跡できません。
  • リスク リストがない場合、見当違いの問題に焦点を当てる可能性があり、思いもしなかった大きな問題が 5 か月後に発生するようなこともあります。
  • 開発企画書がない場合、プロジェクトでの時間と資金を失う危険性があります。プロジェクトはキャンセルされるか、破産する可能性があります。
  • アーキテクチャーがない場合、問題が発生したときに、通信、同期、データ アクセスを処理できないことがあります。規模と性能に問題がある可能性があります。
  • 製品 (プロトタイプ) がない場合、できるだけ早く、顧客よりも先に製品を入手します。机上の仕事を積み上げるだけでは、ユーザーや顧客に製品が正常であることを保証できず、予算とスケジュールの超過やはっきりとした障害のリスクを最大にする可能性があります。
  • 評価がない場合、現実から顔をそむけないで、真実に向き合うことは重要です。 期限はどの程度近づいているのか、目標は品質なのか、予算なのか、 すべての問題を適切に追跡しているかを確認することは大切です。
  • 変更依頼がない場合、利害関係者からの変更の依頼をどのように追跡するのか、どのように優先付けするかを検討します。優先度の低い依頼を無視しないようにします。
  • ユーザー サポートがない場合、ユーザーが質問を持っていたり、製品の使用方法を理解できなかったりした場合、どうなりますか。サポートを受けるのは容易ではなくなります。

これらの「基本」では、RUP の各作業分野と数多くの最善の実践原則への導入部も用意されています。 



Rational Unified Process   2003.06.15