ラショナル統一プロセス

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

Rational Unified ProcessRUP)は、2003年からIBMの一部門であるRational Software Corporationによって作成された反復ソフトウェア開発プロセスフレームワークです [ 1] RUPは、単一の具体的な規範的プロセスではなく、適応可能なプロセスフレームワークです。ニーズに適したプロセスの要素を選択する開発組織とソフトウェアプロジェクトチームによって調整されます。RUPは、UnifiedProcessの特定の実装です

歴史

Rational Softwareは当初、ソフトウェアプロセス製品としてRational UnifiedProcessを開発しました。この製品には、さまざまなタイプのアクティビティのサンプルアーティファクトと詳細な説明を含むハイパーリンクされたナレッジベースが含まれています。RUPは、プロセスのカスタマイズを可能 にするIBM Rational Method Composer (RMC)製品に含まれています。

経験豊富なRational技術担当者であるPhilippeKruchtenは、元のRUPチームを率いる任務を負っていました。

これらの初期バージョンは、オブジェクト指向システム(RationalフィールドスタッフによってRationalアプローチと呼ばれる)を構築するRational Software組織の広範なフィールド経験と、ユースケースなどの実践に関するObjectoryのガイダンスを組み合わせ、JimRumbaughのオブジェクトモデリングテクノロジー(OMT)からの広範なコンテンツを組み込んでいます。 )モデリングへのアプローチ、Grady BoochのBooch法、および新しくリリースされたUML0.8[2] [3]

この成長する知識ベースをより利用しやすくするために、Philippe Kruchtenは、最新のソフトウェアエンジニアリングのための明示的なプロセスフレームワークの構築を任されました。この取り組みでは、Objectoryによって開発されたHTMLベースのプロセス配信メカニズムを採用しました。結果として得られた「RationalUnifiedProcess」(RUP)は、Rationalの戦略的三脚を完成させました。

  • 開発を導い調整可能なプロセス
  • そのプロセスの適用を自動化したツール
  • プロセスとツールの両方の採用を加速したサービス。

このガイダンスは、Rationalが取得した企業の経験に基づいた知識を使用して、後続のバージョンで拡張されました。

1997年に、要件とテスト規律がアプローチに追加されました。追加の資料の多くは、Dean Leffingwell etalによって開発されたRequirementsCollegeメソッドから供給されました。Requisite、Inc。、およびSQAInc。で開発されたSQAProcessメソッドで、両社はRationalSoftwareに買収されました。

1998年、RationalSoftwareは2つの新しい分野を追加しました。

  1. ビジネスモデリングでは、このコンテンツの多くはすでに客観的プロセスに含まれていました
  2. Pure Atria Corporationの買収を通じて提供された、構成および変更管理の分野。

これらの追加により、Rationalによって定義され、RUP内で最新のソフトウェアエンジニアリング の6つのベストプラクティスとして明確に示されている一連の包括的な原則が導き出されます。

  1. リスクを主な反復ドライバーとして、反復的に開発します[4]
  2. 要件を管理する
  3. コンポーネントベースのアーキテクチャを採用する
  4. ソフトウェアを視覚的にモデル化する
  5. 品質を継続的に検証する
  6. コントロールの変更

これらのベストプラクティスは、Rationalの製品ラインと緊密に連携しており、Rationalの製品の継続的な開発を推進するとともに、Rationalのフィールドチームが顧客のソフトウェア開発作業の品質と予測可能性を向上させるために使用しました。

パフォーマンステスト、UIデザイン、データエンジニアリング、UML1.1の変更を反映する更新などの追加の手法が含まれていました。

1999年に、プロジェクト管理の分野が導入され、リアルタイムのソフトウェア開発とUML1.3を反映する更新をサポートする手法が導入されました。さらに、プロセスを説明した最初の本である統合ソフトウェア開発プロセス(ISBN  0-201-57169-2)が同じ年に発行されました。

2000年から2003年の間に、RUPインスタンスの制定と、RUPフレームワークのカスタマイズのためのツールのサポートに加えて、反復型開発に関する継続的なRationalフィールドの経験からのガイダンスが導入されました。これらの変更には次のものが含まれます。

  1. 後にアジャイルメソッドとして集合的に知られるようになるエクストリームプログラミング(XP)などのアプローチからの概念と手法の導入。これには、ペアプログラミング、テストファーストの設計、RUPによってXPが大規模なプロジェクトで使用できるように拡張できることを説明する論文などの手法が含まれていました。
  2. さまざまな反復型開発コンテキストでテスト作業がどのように実行されたかをより適切に反映するための、テスト規律の完全な見直し。
  3. さまざまなツールでRUPプラクティスを実施するための、「ツールメンター」として知られるサポートガイダンスの導入。これらは基本的に、Rationalツールのユーザーに段階的なメソッドサポートを提供しました。
  4. 顧客がRUPプロセスフレームワークからパーツを選択し、独自の追加で選択をカスタマイズし、Rationalからの後続のリリースに改善を組み込むことができるように、RUPのカスタマイズを自動化します。

IBMは2003年2月にRationalSoftwareを買収しました。

2006年、IBMは、アジャイルプロジェクトの配信に合わせて調整されたRUPのサブセットを作成しました。これは、EclipseWebサイトを通じてOpenUPと呼ばれるオープンソースメソッドとしてリリースさまし[5]

Rational UnifiedProcessのトピック

RUPビルディングブロック

RUPは、一連のビルディングブロックとコンテンツ要素に基づいており、作成する内容、必要なスキル、および特定の開発目標を達成する方法を説明する段階的な説明を記述しています。主な構成要素、つまりコンテンツ要素は次のとおりです。

  • 役割(誰)–役割は、関連するスキル、能力、および責任のセットを定義します。
  • 作業成果物(何)–作業成果物は、プロセスの作業中に作成されたすべてのドキュメントとモデルを含む、タスクから生じるものを表します。
  • タスク(方法)–タスクは、意味のある結果を提供する役割に割り当てられた作業単位を記述します。

各反復内で、タスクは9つの分野に分類されます。

プロジェクトの4つのライフサイクルフェーズ

RUPのフェーズと分野。

RUPは、4つのフェーズで構成されるプロジェクトのライフサイクルを決定しました。これらのフェーズでは、「ウォーターフォール」スタイルのプロジェクトを提示するのと同様の方法でプロセスを高レベルで提示できますが、本質的にプロセスの鍵は、すべてのフェーズ内にある開発の反復にあります。 。また、各フェーズには、達成されている目標を示す1つの主要な目標とマイルストーンが最後にあります。時間の経過に伴うRUPフェーズと分野の視覚化は、RUPハンプチャートと呼ばれます。

開始フェーズ

主な目的は、初期コストと予算を検証するための基礎として、システムのスコープを適切に設定することです。このフェーズでは、ビジネスコンテキスト、成功要因(期待される収益、市場での認知度など)、および財務予測を含むビジネスケースが確立されます。ビジネスケースを補完するために、基本的なユースケースモデル、プロジェクトプラン、初期リスク評価、およびプロジェクトの説明(コアプロジェクトの要件、制約、および主要な機能)が生成されます。これらが完了すると、プロジェクトは次の基準に照らしてチェックされます。

  • スコープの定義とコスト/スケジュールの見積もりに関する利害関係者の同意。
  • 主なユースケースの忠実性によって証明される要件の理解。
  • コスト/スケジュールの見積もり、優先順位、リスク、および開発プロセスの信頼性。
  • 開発された建築プロトタイプの深さと幅。
  • 実際の支出と計画された支出を比較するためのベースラインを確立する。

プロジェクトがライフサイクル目標マイルストーンと呼ばれるこのマイルストーンを通過しない場合、基準をより適切に満たすように再設計された後、プロジェクトをキャンセルまたは繰り返すことができます。

精緻化フェーズ

主な目的は、このフェーズの終わりまでの分析によって特定された主要なリスク項目を軽減することです。精緻化フェーズは、プロジェクトが具体化し始めるところです。このフェーズでは、問題ドメイン分析が行われ、プロジェクトのアーキテクチャが基本的な形になります。

精緻化フェーズの結果は次のとおりです。

  • ユースケースとアクターが特定され、ほとんどのユースケースの説明が作成されたユースケースモデル。ユースケースモデルは80%完成している必要があります。
  • ソフトウェアシステム開発プロセスにおけるソフトウェアアーキテクチャの説明。
  • アーキテクチャ的に重要なユースケースを実現する実行可能アーキテクチャ。
  • 改訂されたビジネスケースとリスクリスト。
  • プロジェクト全体の開発計画。
  • 特定された各技術的リスクを明らかに軽減するプロトタイプ。
  • 予備ユーザーマニュアル(オプション)

このフェーズは、次の質問に答えるライフサイクルアーキテクチャのマイルストーン基準に合格する必要があります。

  • 製品のビジョンは安定していますか?
  • アーキテクチャは安定していますか?
  • 実行可能なデモンストレーションは、主要なリスク要素が対処および解決されていることを示していますか?
  • 建設段階の計画は十分に詳細で正確ですか?
  • すべての利害関係者は、現在のアーキテクチャのコンテキストで現在の計画を使用して現在のビジョンを達成できることに同意しますか?
  • 実際のリソース支出と計画されたリソース支出は許容範囲内ですか?

プロジェクトがこのマイルストーンを通過できない場合でも、プロジェクトをキャンセルまたは再設計する時間はあります。ただし、このフェーズを終了した後、プロジェクトはリスクの高い操作に移行します。この操作では、変更が行われると、変更がはるかに困難になり、有害になります。

精緻化のための重要なドメイン分析は、システムアーキテクチャです。

建設段階

主な目的は、ソフトウェアシステムを構築することです。このフェーズでは、主な焦点は、システムのコンポーネントおよびその他の機能の開発にあります。これは、コーディングの大部分が行われるフェーズです。大規模なプロジェクトでは、ユースケースを管理可能なセグメントに分割して実証可能なプロトタイプを作成するために、いくつかの構築の反復が開発される場合があります。

移行フェーズ

主な目的は、システムを開発から本番環境に「移行」し、エンドユーザーがシステムを利用できるようにして理解できるようにすることです。このフェーズのアクティビティには、エンドユーザーとメンテナーのトレーニング、およびエンドユーザーの期待に照らしてシステムを検証するためのシステムのベータテストが含まれます。システムは評価フェーズも通過し、必要な作業を行っていない開発者は交換または削除されます。製品は、開始フェーズで設定された品質レベルに対してもチェックされます。

すべての目標が達成されると、製品リリースのマイルストーンに到達し、開発サイクルが終了します。

IBM Rational MethodComposer製品

IBM Rational Method Composer製品は、プロセスを作成、構成、表示、および公開するためのツールです。詳細については、 IBM Rational MethodComposerおよびオープンソースバージョンのEclipseProcess Framework(EPF)プロジェクトを参照してください。

認証

2007年1月に、IBM Certified SolutionDesignerの新しいRUP認定試験-RationalUnified Process 7.0がリリースされました。これは、 IBM Rational Certified Specialist-Rational UnifiedProcessと呼ばれるコースの以前のバージョンに代わるものです。[6]新しい試験では、RUPの内容だけでなく、プロセス構造要素に関連する知識もテストされます。[7]

新しいRUP認定試験に合格するには、IBMのTest 839:Rational Unified Processv7.0を受験する必要があります。52問の試験を受けるために75分が与えられます。合格点は62%です。[8]

6つのベストプラクティス

障害を最小限に抑え、生産性を向上させるために、ソフトウェアプロジェクトに対して6つの最良のソフトウェアエンジニアリングプラクティスが定義されています。これらは次のとおりです。[9] [10]

繰り返し開発する
すべての要件を事前に知っておくのが最善です。ただし、多くの場合、そうではありません。開発フェーズの観点からコストを最小限に抑えるソリューションの提供を扱ういくつかのソフトウェア開発プロセスが存在します。
要件を管理する
ユーザーが設定した要件を常に念頭に置いてください。
コンポーネントを使用する
高度なプロジェクトを分解することは提案されているだけでなく、実際には避けられません。これにより、個々のコンポーネントをより大きなシステムに統合する前にテストする機能が促進されます。また、コードの再利用は大きなプラスであり、オブジェクト指向プログラミングを使用することでより簡単に実行できます
視覚的にモデル化する
ダイアグラムを使用して、すべての主要なコンポーネント、ユーザー、およびそれらの相互作用を表します。統一モデリング言語の略である「UML」は、このタスクをより実行可能にするために使用できるツールの1つです。
品質を確認する
いつでもプロジェクトの主要部分をテストするようにしてください。プロジェクトが進むにつれてテストは重くなりますが、ソフトウェア製品を作成する際には常に重要な要素となるはずです。
コントロールの変更
多くのプロジェクトは多くのチームによって作成され、場合によってはさまざまな場所で、さまざまなプラットフォームが使用されることもあります。そのため、システムに加えられた変更が同期され、常に検証されるようにすることが不可欠です。継続的インテグレーションを参照)。

も参照してください

参考文献

  1. ^ IBMがRationalを買収
  2. ^ ジェイコブソン、ステン(2002-07-19)。「合理的な客観的プロセス-UMLベースのソフトウェアエンジニアリングプロセス」Rational Software ScandinaviaAB 2014年12月17日取得
  3. ^ クルーシュテン、フィリップ(2004-05-01)。Rational Unified Process:はじめに。アディソン-ウェスリーp。33. ISBN 97803211977022014年12月17日取得
  4. ^ Aked、​​Mark(2003-11-25)。「RUPの概要」IBM 2011年7月12日取得
  5. ^ http://epf.eclipse.org/wikis/openup/
  6. ^ クレブス、ヨッヘン(2007-01-15)。「RUP認証の価値」IBM 2014年5月5日取得
  7. ^ 「スペーサーIBM認定ソリューションデザイナー-IBMRational UnifiedProcessV7.0」IBM 2008年5月13日取得
  8. ^ 「テスト839:Rational Unified Processv7.0」IBM 2008年5月13日取得
  9. ^ Stephen Schach(2004)。古典的でオブジェクト指向のソフトウェア工学6 / e、WCB McGraw Hill、ニューヨーク、2004年。
  10. ^ WaybackMachineで2009年5月1日にアーカイブされRationalUnifiedProcessホワイトペーパー

さらに読む

  • Ivar JacobsonGrady Booch、およびJames Rumbaugh(1999)。統合ソフトウェア開発プロセス
  • Gary PolliceLiz Augustine、Chris Lowe、およびJas Madhur(2003)。小規模チーム向けのソフトウェア開発:RUP中心のアプローチ
  • パー・クロール、フィリップ・クルーシュテン(2003)。Rational Unified Processが簡単になりました:RUPの実践者向けガイド
  • Krollによると、Bruce Mac Isaac(2006)。敏捷性と規律が容易に:OpenUPとRUPからの実践
  • フィリップ・クルーシュテン(1998)。Rational Unified Process:はじめに
  • Ahmad Shuja、Jochen Krebs(2007)。RUPリファレンスおよび認定ガイド
  • ウォーカーロイス、ソフトウェアプロジェクト管理、統合フレームワーク

外部リンク