大規模なITプロジェクトのウォーターフォールからRUP方法論への移行経験

従来のカスケード開発ライフサイクルモデルからどのように移行する必要がありましたか？

2009年に、私は「ろくでなし」プロジェクトの1つを選択して実装するよう提案されました。 誰もがすでに「ジブリ」という接頭辞を受け取りました。なぜなら、彼らはすでにそれらを取得しようとしましたが、それから何も生まれなかったからです。



大規模なプロジェクトでは、失敗の理由は多くの場合、チームの専門レベルではなく、顧客が最後まで進んで自分の努力で利益を得ることです。 プロジェクトの目標が顧客の短期および中期の目標と一致するような状況であるべきです。



優れた例：制裁措置を受け、1バレルあたり50ドルの石油価格（以前は110に対して）しかなかったため、国の指導者は推論とゆったりとした身体の動きからハイテク経済を発展させるための積極的な行動に切り替えました。



私の顧客の一人が熟していたので、私は彼に企業情報システム（ERPシステム）の新しい機能モジュールを開発するプロジェクトを始めました。これは、システムに400人の新しいユーザーを追加し、年間40,000の住宅ローンの検証を提供することでした。



2か月後、参照条件の最初のバージョンが既にありました。これは、200ページのメインTORと200ページのアプリケーションで構成され、さまざまなフォームとビジネスアルゴリズムの説明が含まれていました。 その前に、企業IP全体のメインTKを確認しましたが、実装時には600ページしかありませんでした。 したがって、モジュールの技術仕様の開発中であっても、このような大量の要件では、私たちが離陸しない可能性が非常に高く、離陸した場合、それは非常に高速ではないという考えが生まれました。



EPAMの専用開発センターのスタッフが、6500時間の開発の労力と1.5年の開発期間を発表した後、私たちは絶対に離陸しないことが明らかになりました。



自動化が必要なビジネスプロセスと手順は活発であり、市場とロシア中央銀行の要件の両方について、社内および社外の変化に絶えず適応していました。



1年半後、私たちが彼らのために縫う「パンツ」は小さいか、まったくふさわしくないでしょう。これはお金、開発時間、そして無駄になっている資源です。 これは間違いなく会社内の選択肢やキャリアの自殺ではないことを理解するために一度これを通過しようとするのに十分です。 その後、彼らは深刻なものを信用しません。



これにより、Waterfallは小規模なプロジェクトや自動化されたプロセスが絶えず変更されないプロジェクトに適しているという結論に至りました。 開発プロセスに関係するすべての人に明確になるように、早期の納品を含む他の何かが必要でした。 理想的には滝ですが、滝ではありません。 Rational Unified Processであることが判明しました。

コンテキストに関する2つの単語

同社は、Pivo​​tal CRMプラットフォームに基づいて独自の企業IPを開発および開発しています。 CISの独立した開発とCISの追加機能モジュールの理由は、国内市場に代替手段がないことと、2000年代に欧米のカウンターパートを取得するための高価なコストです。



会社の従業員に加えて、KISは全国200社以上のパートナー企業（B2B）の従業員を雇用しています。 前述のように、開発はEPAM Systemsに外部委託されています。 会社の側には、ビジネス分析とプロジェクト管理があります。

ウォーターフォール方法論の何が問題なのか（カスケードモデルの機能と欠点）

このマザーの方法論は、その後のすべての普遍的なものです。 この方法論によれば、最初のプログラムが開発されました。



この方法論を保持し、そこに組み込まれている基本事項：

1. 最初から最後まで、設計された最終結果。
   
   
   
   
   （建築結果設計）

   
   
   
   
   
   
2. 最終結果を組み立てる手順。
   
   
   
   
   （プロジェクト実施計画）

   
   
   
   
   
   
3. 一貫したプロジェクトの実施。
   
   
   
   
   分析、設計、組み立て、テスト、試運転

   
   
   
   
   
   
4. プロジェクトの実施中の結果プロジェクトおよびアセンブリ指示の変更に対する抵抗。
   
   
   
   
   プロジェクトの変更

   
   
   
   
   
   
5. プロジェクトの結果は、プロジェクトの終了時に単一の配信として配信されます。
   
   
   
   
   プロジェクト結果のアセンブリのダイナミクス

   
   
   

1-2年以上の条件でWaterfallの長期プロジェクトを実装するには、ビジネス環境、顧客のニーズ、プロジェクトの完了時点にある会社（プロジェクトのビジネス目標に関連する仮定）についての仮定を立てる必要があります。 また、プロジェクトの存続期間（プロジェクトの実施計画に関連する仮定）の各年のリソースの推定コストを想定し、設定する必要があります。



プロジェクトの内容が大きくなるほど、実装の複雑さとタイミングが増すほど、プロジェクトにはより多くの仮定が置かれます。 最も重要なのは、プロジェクトのビジネス目標に関連する仮定であり、それが間違っていることが判明した場合、プロジェクトに投資されたすべてのリソース、お金、および時間は減価されます。



実装中にプロジェクトの最終結果に大幅な変更を加えるには、最終結果とアセンブリ手順を再設計するサイクルが必要です。 重要な変更では、多くの場合、最初の作業計画に従ってすでに開始されているものの継続が許可されず、すでに行われた作業のやり直しが行われます。



このため、プロジェクトチームと関係者は、プレイ/明らかにされた状況とリスクがプロジェクト全体を継続する必要性に疑問を投げかけない場合にのみ、プロジェクトの重要な変更に抵抗します。 それにもかかわらず、変更が行われると、ほとんどの場合、追加のコストと長い納期につながります。 期間の延長により、新しい要件と新しい変更が再び発生します。 それは、勝利を収めることが不可能な悪循環のようなものです。 ここから、最初の日付と予算から絶えず出発します。



したがって、この方法論は、原子力発電所などの建物や構造物の建設プロジェクトには適していますが、それらが適用される急速に変化する環境向けの製品の開発には適していません。 修正なしの元の形での製品の寿命は5年未満です。



反復開発のアイデアは、仮定に関連するリスクを排除し、フィードバックを迅速に得る機会を提供し、誤ったビジネス仮定からの損失の規模を縮小し、次の反復の最後に受け取ったフィードバックに基づいてプロジェクト最終結果に変更を加えるように設計されています。

Rational Unified Processの利点

RUP方法論は、大規模なソフトウェアシステムを開発するために意図的に設計されています。



その基礎にあるNovation No. 1は 、「ビジネスモデリング」とそれに関連するユースケースシナリオです。



まず、将来のシステムがユーザー/ビジネスのすべてのニーズを満たす「ブラックボックス」であるビジネスユースケースを開発します。 それに基づいて、ビジネスシナリオの実行をサポートするシステムの機能を説明するシステム使用シナリオが開発されます。

企業IPの開発における主なタスクは、サポートされるビジネスプロセスの継続性を確保することです。 ビジネスプロセスの構造が壊れると、生産チェーンの後続のすべてのステップ、そして時には数百億ルーブルに相当するビジネス全体が発生します。

モスクワ取引所で取引を停止する例

モスクワ証券取引所の株式、通貨、デリバティブ市場に異常な状況が存在します... 9月1日に取引所が取引を一時停止したのは、メイン市場セクションのみです。 この失敗は4か月で4回目でした。 -Lenta.ru

したがって、企業IPの開発は、1つのプロセスを別のプロセスに置き換えるための使用に基づく新しいビジネスプロセスの設計に基づいており、特定の日から数百人が以前とは異なる方法で働き始めました。 これが、他の種類のソフトウェアからの企業IPの開発の主な主な違いです。

イノベーション2 ：システムを使用するために選択されたシステムシナリオに基づいて、アーキテクチャ上の決定が行われ、ビジネスシナリオをサポートするコンポーネントが選択され、複数のビジネスシナリオをサポートするために一緒に使用するか、特定のシナリオに合わせて調整するかを決定します。 （オブジェクト指向設計とプログラミング）

個々のコンポーネントが存在するため、それらを再利用して、相互に交換することができます。 より多くのコンポーネントが一緒に使用されるほど、コンポーネントに変更を加える際に、隣接するビジネスシナリオを壊す可能性が高くなります。 また、共通コンポーネントの存在により、システムの開発に関するその後の作業の速度と規模が制限されます。 1つのチームがいくつかの共通コンポーネントの変更にコミットしている場合、他のチームは、最初のチームが作業を終了し、ビジネスユースケースをデバッグするまで、変更を開始できません。

Novation No. 3 ：システムを使用するための専用シナリオが存在するため、それらをプライマリとセカンダリに分けることができます。 二次シナリオは一次シナリオの実行結果に基づいており、それは概して自給自足です。 これにより、反復を分離し、それらのすべてのシナリオの実装を分解する機会が与えられます。

ウォーターフォールには反復がありません。機能要件を自己完結型ブロックに分割し、それらを反復で実装することが非常に困難な場合があるためです。 これは不可能だと言っているわけではありませんが、可能ですが、ほとんどの場合、この結果はITソリューションの実際のプロトタイプではなく、将来のプログラムの一部になります。 これはビジネスを容易にするものではありません。1年で実用的なプロトタイプを取得できます。ここでの反復の存在は役立ちますが、それほど多くはありません。

これは、RUPの概念が簡略化された形式でどのように見えるかです。





各ビジネスシナリオは、システムのユースケースで展開されます。 各システムシナリオは、インターフェイス、アルゴリズム、データの要件に基づいており、機能的ではありません（パフォーマンス、可用性時間、応答速度など）。 識別された要件に基づいて、システムとその機能モジュール（サービスサブシステム）の将来のアーキテクチャが決定されます。 サブシステムはコンポーネントに分けられます。 コンポーネントには実行可能コードが含まれています。



RUPの主なアイデアは、最初のイテレーションで、将来のシステムのプロトタイプを、ビジネスシナリオの一部を使用/アプリケーションの準備ができた状態で発行することです。 プロジェクト結果の一部（増分）の配信は各反復の最後に実行されるため、これにより、結果の中間バージョンの使用から利益を得て、実装中にプロジェクトへの投資を回収できます。

RUPの適用方法

ステップ1-会社が採用したものとは異なる技術的なタスクテンプレートの使用について、マネージャーと同意しました。 新しいTKは、ビジネスおよびシステムの使用シナリオに基づいています。 この決定は、RUPで作業するという決定よりも早く行われ、「企業IPのTKはどうあるべきか」という記事に記載されているいくつかの理由によります（この記事の最後にある「読むべきもの」セクションのリンク）。



ステップ2-ターゲットビジネスプロセスを設計し、ToRの最初のバージョンを準備しました。 実装の複雑さと期間の見積もりを受け取った後、このプロジェクトにRUPを使用することを決定しました。 ターゲットビジネスプロセスを5つのビジネスプロシージャ/プロジェクトの5つの段階に分割しました。 TKの最初のバージョンは、ターゲットプロセスに移行するためのコンセプト/ロードマップになりました。



ステップ3-自動化戦略の決定：ビジネスプロセス全体の入力または出力ポイントから移動します。



「入力ポイントから」の最初の戦略は、電圧を作成し、チェーン内の他のすべてのステージを自動化することを強制します。 ビジネスプロセスの後続の段階では、作業に必要な主要なデータはなくなります。



「出口点から」の2番目の戦略にはこの緊張はありませんが、前の段階で作成および蓄積されたデータと履歴はありません。 必要な情報をCISに定期的に転送する必要があります。



最初の戦略に進みましょう。 後続のステージに必要な情報を提供する問題は、データをExcelにアップロードすることで解決しました。 ビジネスユーザーがExcelからKISに完全に切り替えるモチベーションを高め、ビジネスアナリストと協力して要件を作成するための時間を割く適切なサポートと意欲という形で、予期せぬ効果が得られました。



ステップ4-システムモジュールの最初の部分の技術仕様を準備しました（2回目の反復）。 最初の部分の開発中に、TKは2番目の部分（3回目の反復）の準備ができました。



最初の反復は、CISを使用するビジネスプロセスが完全に規定され、将来のモジュールのアーキテクチャの最初のバージョンが開発された概念参照規約の準備でした。



ステップ5-モジュールの最初の部分がリリースされ、その試運転が開始された後、最初の部分のTORと3番目の部分のTKへの追加の準備を開始しました（4回目の反復）。 さらに、最初に見逃された要件と、使用面で失敗した要件が含まれています。



結果 -すべてのことについて、本当に1.5年かかりました。 作業用プロトタイプ（システムモジュールの最初の部分）は、プロジェクト開始日から6か月後に取得されました。 残りは2か月ごとに来ました。







アーキテクチャの観点から見ると、新しい機能モジュールのコンポーネントは彼専用に研ぎ澄まされ、メインICのコンポーネントは使用しませんでした。 これが許可されました：

1. モジュールの変更によって定期的に生成されるエラーが発生したときにシステム全体を安定させるため、およびIPの一般的な機能に加えられた変更のエラーによるモジュール。
2. 新しいモジュールの開発と並行して、既存のCIS機能の開発に関する作業を実施する。

RUPはUML表記に直接関連付けられていますが、ビジネスおよびシステムの使用シナリオを記述するためにそれらを使用する必要はありませんが、他の表記も同様です。 主なものは、使用される表記法は、ステートメントを調整承認するビジネスユーザーと、参照条件を引き続き使用して設計および技術文書に翻訳するシステムアナリストと開発者の両方にとって理解可能であることです。 ビジネスシナリオを説明するために、eEPCとARIS、およびIDEF0 / 3表記の要件を使用して、システムシナリオのフレームワークを設定しました：プロセス入力、プロセス出力、エグゼキューター。



「企業IPのTKはどうあるべきか」という記事は、ビジネスシナリオとシステムのユースケースがどのように見えるかについてのアイデアを提供します。 元のRUPマニュアルでは、システムシナリオのコンパイル時にユーザーインターフェイスをスケッチすることは推奨されていませんが、要素を視覚化することでビジネスシナリオとシステムシナリオの両方の理解を促進するため、ユーザーインターフェースが必要であると考えました。 これは実際にはシステムの最初のプロトタイプでしたが、クリックはできませんでした。



このプロジェクトの後、書かれたTKは新しいテンプレート（標準）になりました。 このプロジェクトは、会社のソフトウェア開発の技術および生産プロセス全体にも影響を与え、リズミカルになりました。

RUP方法論の技術面とその適用方法を理解するための少しの理論

RUPの各反復は、要件の収集とその分析、設計、開発、テスト、および配信に関する5段階の作業すべてを含む古典的なウォーターフォールです。 しかし、RUPは、プロジェクトのフェーズとして、要件の収集と分析、設計、構築、実装などの概念も導入しています。







これについて詳しく説明します。



最初の反復、フェーズ分析



システムの将来のユーザーの要件を収集することに専念しています。 ユーザーは各作業を指示し（ユーザーがシステムを使用するシナリオ）、アナリストは個々の操作と手順からワークフロー全体を組み立てようとします。 この反復の目標は、システム/将来のIPベースのビジネスプロセスを使用するビジネスシナリオを入力することです。 複数存在する可能性があるため、1つに集中しないでください。

顧客会社は銀行です。 彼は、顧客のオフィスや地下鉄の駅に設置されたATMを使用して、顧客にリモート現金引き出しサービスの提供を開始したいと決めました。



このサービスを提供するには、銀行で利用可能なソフトウェアを開発および変更する必要があります。 要件の収集とその分析中に、サービスビジネスシナリオで3つの主要な手順が特定されました。

1. 銀行の従業員がATMに現金を積み込みます。
2. 銀行口座からの依頼によるクライアントへの現金引き出し。
3. ダウンロードおよび発行された請求書の数の説明。

この反復では、将来のシステムのアーキテクチャの設計、プログラム開発、テスト、および配信に関連する作業はまだありません。 RUPは必要な条件を設定しませんが、あなたの裁量でそれらを満たせます。



2回目の反復、フェーズ分析



ビジネスシナリオが定義されると、収集された要件は、ビジネスシナリオとシステムシナリオの手順に従ってレイアウトされます。 この段階では、最初の反復で特定されなかったビジネスシナリオの手順も明らかになります。

2回目の反復では、主なビジネスシナリオ用に2つの追加手順が特定されました。

1. ATMから銀行に送られた現金の終了に関する監視と通知。
2. ATMの操作性またはその中の問題/エラーの存在の監視と通知。

現金引き出しサービスの可用性を年中無休で確保するため。

この反復の結果は次のとおりです。

1. 90％の完全なビジネスシナリオ。
2. 各ビジネスシナリオの意図された、詳細ではないシステム使用シナリオ。
3. 収集された要件は、ビジネスおよびシステムのシナリオに従って構成されます。

3番目の反復、フェーズ設計



特定されたビジネスシナリオは実装の優先順位を設定し、それらの最も重要なものがこの反復で研究の対象になります。選択されたビジネスシナリオでは、主要なステップステージが強調表示されます。これは後続のすべてのステップの基礎であり、それがなければ残りの実装は意味がありません。これらの手順については、システムを使用するシナリオの詳細を説明します。



最終結果はシステムアナリストとアーキテクトに送信され、システム内で何が起こるかをシミュレートします。クラス、それらの間の協力、および相互作用シーケンスは区別されます。将来のシステムのアーキテクチャの基本的な考え方が形成され、サブシステム、システムコンポーネント、およびITソリューションのノード間のそれらの分散が強調表示されます。



すでにこのイテレーションで開発作業を開始でき、イテレーションの結果は主要なビジネスシナリオの段階である主要なステップの実装をサポートする既製のプロトタイプになります。フィードバックを収集して要件を明確にするために、ユーザーに既に表示することができます。



基礎となるアーキテクチャは最初のテストボールであり、後続の反復で調整されるため、このプロトタイプは試用版または工業用に移行されません。







4番目の反復であるフェーズ設計



は、分析を完了して設計作業を開始した3番目の反復と並行して開始されます。







この反復では、残りのビジネスシナリオの主要なステップステージが作成されています。主要なビジネスシナリオの次のステップではなく、それらが解決されている理由は、プログラム全体の将来のアーキテクチャを決定するためです。



各ビジネスシナリオでは、実装に将来のシステムの特定のコンポーネントが必要になる場合があり、このため、各ビジネスシナリオのアーキテクチャ上の決定は相互に調整する必要があります。



この反復の結果は次のようになります。

1. 各ビジネスシナリオのアーキテクチャソリューション。
2. Consensus Project 1.0システムアーキテクチャ
3. 主要なビジネスシナリオの最初のステップに加えて、セカンダリビジネスシナリオの既製の最初のステップを含むプロトタイプの2番目のバージョン。

5回目の反復、ビルドフェーズ



は、分析作業が完了し、設計作業が開始されると、4回目の反復と並行して開始されます。反復の開始までに、3回目の反復中に作成されたプロトタイプのユーザーによるテストの結果に従って、フィードバックが既に受信されていると想定されます。ここでは、主要なビジネスシナリオの残りの手順と、関連するシステム使用シナリオを作成します。



作業の「設計」段階が始まるまでに、4番目の反復が実装（開発）され、プロトタイプの2番目のバージョンがテストされると想定されています。

システムアーキテクチャ全体の合意されたプロジェクトが改良され、その後、いくつかの概念的な変更の導入が実質的にゼロに削減されますが、完全に二次的なビジネスシナリオが実装されないため、依然として可能です。



反復の結果は次のとおりです。

1. 完全に実装された主要なビジネスシナリオ。
2. システム2.0アーキテクチャ全体の一貫した設計
3. 主要なビジネスシナリオを実装するシステムの3番目のバージョンと、セカンダリビジネスシナリオの最初の手順。

ここでは、システムはプロトタイプではなく、最終バージョンとしてビジネスユーザーに転送されるシステムに似ているため、システムをビジネスユーザーに試用のために転送することはすでに可能です。分析作業が完了して設計作業が開始されると



、6回目の反復、ビルドフェーズ



が5回目の反復と並行して開始されます。



セカンダリビジネスシナリオの残りの手順と段階、および関連するシステムユースケースが登録されます。この反復の最初に、プロトタイプの2番目のバージョンがテストされ、4番目の反復中に作成され、2次ビジネスシナリオの主要なステップと段階での作業に関するフィードバックがユーザーから受け取られたと想定されます。



反復の結果は次のとおりです。

1. .
2. 3.0
3. , -.

ビジネスユーザーによるシステムの本格的な試運転と、産業用のフィッティングが始まります。



7番目の反復、実装フェーズ：



ここでは、試運転中に特定されたビジネスシナリオの実装にいくつかの重要な変更が加えられ、産業運用でのシステムの完全な使用を許可しません。



8回目の反復、実装フェーズ



この反復では、ユーザーによるシステムの使いやすさを改善し、作成されたソリューションを最適化するための作業が進行中です。ユーザーは、主にサイトの速度とスループットに関心があります。システムはサポートのために転送されています。プロジェクトを完了して終了するための正式な手順が進行中です。



小計



RUP方法論は、反復回数とその位相分布に条件を課しません。フェーズと反復の概念は、リスク、リソース要件を削減し、プロジェクトのリズムを設定し、大規模な情報システムを開発するときに必要な変更を加える機会を提供するために導入されました。





各反復の結果により、次の反復の計画が改善され、次の反復に追加のリソースが必要かどうか、フェーズを完了するために追加の反復が必要かどうかについての理解が深まります。数人の最小限のチームがプロジェクトの作業を開始でき、その拡張は次の反復の計画によって正当化されます。



フェーズの完了の結果は、プロジェクト計画と経済性を明確にします。ここでは、プロジェクトを継続するかどうか、ビジネスフレームワーク内にとどまるためにプロジェクトのコンテンツ（ビジネス要件の量）を絞り込むか拡張する必要があるかどうか、プロジェクト結果の所要納期、そのコスト（予算）および収益性（投資収益率）を決定します。

おわりに

特にPMBoKとGOSTに基づいて作成された方法論を備えたプロジェクトオフィスがある場合、ITプロジェクトの実装方法を企業が採用する原則を変更するのは容易ではないことを理解しています。記事を読んだ後、当面の見通しがまだウォーターフォールであることを理解している場合、次の最小値を実装することをお勧めします。

1. IPの使用に基づいて自動化されたビジネスプロセスを規定します。これは、50％以上の既製のユーザー文書と受け入れテストです。
   
   
   
   
2. プロジェクトの時間を定めるために、少なくとも年に1回は、設計ドキュメントの変更の再設計、準備、承認に関する全範囲の作業を完了する必要があります。
   
   
   
   
3. 1,5. . 1,5.
   
   
   
   
4. : .
   
   
   
   30% . , — , .
   
   
   
   , , . , , () , - .
   
   
   
   これにより、ToRに従って実施されるプロジェクトの実装フェーズの終了について、お客様と穏やかに同意することができます。

私の意見では：

• ウォーターフォールは最初のギアです（1年に1回リリースされる最初の速度）。
• RUP-2番目（四半期リリース）、
• スクラム-3回目（隔週/月次リリース）、
• かんばんは、自動更新構築（継続的統合）、自動テスト（受け入れテスト駆動開発）、自動配信および展開（継続的展開）とともに4番目（1日1回のリリース）です。

RUPの開発に関するトピックで他に読むべきこと

1. « ?»
   
   
   
   , , . , .
   
   
   
   . RUP.
   
   
   
   
2. « »
   
   
   
   , RUP.
   
   
   
   — - / -. , .
   
   
   
   - UML, -. IDEFx Structured Analysis and Design Technique ( ) . ISO PMI. .
   
   
   
   
3. - . RUP Rational IBM. - Business Studio . 12 .