私のプロジェクトでは、RUP (Rational Unified Process) という開発方法を使用することにしました。これは今まで使ったことのない方法です。また、開発プロセスにスクラムの要素をいくつか取り入れました。問題は、要件仕様が RUP モデルに何を含めるべきかということです。機能要件と非機能要件のどちらですか? また、RUP の技術分析とセキュリティ要件には何を含める必要がありますか? 情報が見つかりません。これについてのメモは役に立ちます。RUP の経験者が有益な経験を共有できることを願っています
3916 次
2 に答える
6
RUP には 3 つの主要部分があります。
- 役割
- 活動内容
- 作業成果物
各 ROLE は ACTIVITY を実行し、結果として WORK PRODUCTS を生成します...
たとえば、アナリスト [役割] ビジョン [活動] を開発すると、結果としてビジョン [作業成果物] が得られます...
この RUP に加えて、アクティビティと作業成果物を正しく行うためのガイドラインとチェックリストが提供されます...
RUP は WORK PRODUCTS のテンプレートを提供しますが、それらはどのように見えるかを示すためのものです...
ビジョンの場合、RUP テンプレートを使用できますが、ポストイットを使用して、次のような「エラベーター ステートメント」を記述するだけでよいとします。
[対象顧客] 誰が [必要性または機会の説明] (製品名) は [製品カテゴリ] である [主な利点の説明; つまり、購入するやむを得ない理由] [主な競合製品] とは異なり、当社の製品 [主な差別化の記述]
作業成果物でさえ、WIKI に書き込む簡単なステートメントである可能性があります...それらは任意の形式である可能性があります...
それらは「静的に書かれた」ドキュメントであってはなりません...「ビデオ」であってもかまいません。ソフトウェア アーキテクチャ ドキュメント[ OpenUP のアーキテクチャ ノートブック]を書く代わりに 、チームがホワイト ボードで主要なアーキテクチャを説明するビデオを作成できるとします。
****RUP ワークプロダクト テンプレートに関する警告:**
テンプレート ゾンビにならないでください。その一部を埋めてはなりません... 自分自身に尋ねるべきです。これを書くことで、どのような利益が得られるのか... 有効な答えがない場合は、書かないでください... ドキュメント本当の理由があるべきです。「文書化」のためだけに文書化しないでください...**
RUP には豊富な WORK PRODUCTS があります。
典型的なプロジェクトでは、通常、次の要件作業成果物があります。
ビジョン: 私たちが何をし、なぜ私たちがするのか? 利害関係者の合意...
補足仕様[OpenUP におけるシステム全体の要件] : 一般に、システムの非機能的 [用語が嫌い] または「品質」[私が好き] の要件をキャプチャします。
ユースケース モデル: 機能要件をユースケースとして捉える
用語集: 概念を明確にするために...
RUP は商用ですが、OpenUP はそうではありません...そのため、OpenUP WORK PRODUCTS テンプレートを参照して、どのような情報が記録されているかを知ることができます...
Eclipse Process Framework Project http://www.eclipse.org/epf/downloads/configurations/pubconfig_downloads.phpからダウンロードして、インデックス ページから読み始めます。
...-->
...--->
--->
------>
--->
....> ...................................................................
-->.................................................................
最後に、Larman の書籍 Applying UML and Patterns... で、これらの WORK PRODUCTS のアジャイルな使用法を見つけることができます。
繰り返しになりますが、テンプレートゾンビにならないでください!!!
于 2011-12-05T17:15:46.413 に答える
1
概要については、ウィキペディアのRationalUnifiedProcessページをお試しください。
コア要件は、プロジェクトの説明に文書化する必要があります。RUPは「ユースケース」に重点を置く傾向がありますが、元の要件をすべての詳細レベルで見失わないことが非常に重要です。これらは「なぜ」に答えるからです。質問。開発者がユースケースだけを見れば、何を構築するのか（事実上機能要件）はわかりますが、なぜそれが必要なのかはわかりません。開発者が元のアナリストに簡単にアクセスできない限り、これは非常に深刻な問題を引き起こす可能性があります。
于 2010-02-18T21:02:25.370 に答える