なぜ他のものよりもUPプロセスを採用するのですか?相対的な利点は何ですか?私はそれがUMLと密接に関連していることを知っていますが、明らかにこれが唯一の利点ではありませんか?なぜ他のアプローチよりもこのアプローチを選ぶのですか?
3 に答える
それはあなたが比較するプロセス/方法論に本当に依存すると思います。詳細なしで、UPの一般的な特徴だけを述べることができます。これは、オブジェクト指向の分析と設計でモデリング手法を使用した、十分に説明された役割とアクティビティを備えた反復型インクリメンタル手法です。これは、垂直方向(時間)にフェーズに分割され、水平方向に反復に分割され、要件、分析、設計、テスト展開など、ソフトウェア開発のさまざまな側面に関するアクティビティのグループに水平方向に分割されます。
私は RUP とスクラム マスターの認定を受けています。ほとんどのチームは、「すぐに使える」プロセスが完璧に適合しないことに気付きます。そうは言っても、統合プロセスはプロジェクトからリスクを早期に取り除くことに重点を置いています。ただし、UP が過度に複雑であるという理由だけでリスクのレベルを導入する多くの実装を見てきました。プロジェクトの性質、組織構造、およびコンプライアンスや規模などのその他の要因に応じて、UP は簡単に調整できる一連のプラクティスを提供します。
私たちは完全な UP プロセスの実践者ではありませんが、UP プロセスを頻繁に使用して、必要な製品の種類と、その製品のアクティビティを実行する責任を負う役割を確認しています。設計から展開フェーズまでのさまざまな側面が詳しく説明されており、開発ライフサイクルに役立つさまざまなテンプレート、ガイドライン、およびプロセスが付属しているため、気に入っています。
見てみましょう: http://epf.eclipse.org/wikis/openup/
私たちはプロジェクトによってメンバーが異なる役割を担うチームなので、その役割に移動し、目の前のプロジェクトに必要な製品を確認するだけです。プロジェクトの重さ/複雑さに応じて、日常業務に役立つ製品を選択します。UML は私たちが大いに依存している資産であり、OpenUP (または他の UP 化身) 内の利点としてもたらされます。