我选择在我的项目中使用开发方法 RUP（Rational Unified Process）。这是我以前从未使用过的方法。我还在开发过程中包含了来自 Scrum 的一些元素。问题是需求规范应该包含在 RUP 模型中吗？是功能性需求还是非功能性需求？RUP 的技术分析和安全要求中应该包括什么？找不到任何信息。关于这一点的注释会很有帮助。希望有RUP经验的人可以分享一些有用的经验
问问题
3916 次
2 回答
6
RUP 有 3 个主要部分：
- 角色
- 活动
- 工作产品
每个角色都进行一项活动，并因此产生一个工作产品......
例如分析师 [角色] 开发愿景 [活动] 因此我们将拥有愿景 [工作产品]...
此外，这个 RUP 还为我们提供了一些指导方针和检查表，以正确处理我们的活动和工作产品......
RUP 为我们提供了 WORK PRODUCTS 的模板，但它们只是为了让我们了解它们的外观......
假设你可以使用 RUP 模板来实现视觉，但你可以只使用便利贴，然后像这样写一个“elavator statement”：
对于 [目标客户] 谁 [需求或机会声明] （产品名称）是 [产品类别] 即 [关键利益声明；也就是说，购买的令人信服的理由] 不同于 [主要竞争替代品] 我们的产品 [主要差异化声明]
甚至工作产品也可以是您在 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 的《应用 UML 和模式》一书中以敏捷的方式找到这些 WORK PRODUCTS 的用法...
再说一遍：不要成为模板僵尸！！！
于 2011-12-05T17:15:46.413 回答
1
尝试Wikipedia上的 Rational Unified Process 页面以获得概述。
核心需求应记录在项目描述中。RUP 倾向于非常强调“用例”，但是非常重要的是不要忽视所有细节级别的原始需求，因为这些会回答“为什么？” 问题。如果开发人员只看到用例，他们将知道他们应该构建什么（实际上是功能需求），但不知道为什么需要它。除非开发人员可以轻松访问原始分析师，否则这可能会导致非常严重的问题。
于 2010-02-18T21:02:25.370 回答