流程要素
此页介绍了 RUP 的要素,同时介绍了一些用于定制流程使之最佳地适应项目具体需要的指南。这是实现交付优质软件和快速交付软件之间(软件悖论!)的微妙平衡的关键。.
主要描述

简介

要在交付优质软件和快速交付软件之间达到微妙的平衡(软件悖论!),关键是了解流程的必要元素并遵循某些准则来定制流程以最好地满足项目的特定需要。这应在坚持整个行业中经证实的最佳实践的同时进行,以帮助软件开发项目取得成功。  

下面描述了有效的软件流程的必要原则。

1. 远景:制定远景

对于开发满足项目干系人真正需要的产品来说,制定清晰的远景是特别关键的。

在 RUP 中,远景工件捕获非常高级的需求和设计约束,使读者可以了解要开发的系统。它向项目批准流程提供输入信息,并因而与业务案例紧密相关。它传达了有关项目的基本信息,包括为什么要开发系统以及具体要开发什么,同时它还是验证未来所有决定的标尺。

远景(与所有其他相关需求工件一起)的内容将回答以下问题(该工件可以按需要细分为独立的、更为详细的工件):

  • 主要术语是什么?(词汇表)
  • 我们要尝试解决什么问题?(问题声明)
  • 谁是项目干系人?谁是用户?他们的需要是什么?
  • 产品的功能是什么?
  • 功能性需求是什么?(用例)
  • 非功能性需求是什么?
  • 设计约束是什么?

制定一个清晰的远景和一组可理解的需求,这是需求规程和原则平衡竞争的项目干系人优先级的基本要素。这包括分析问题、了解项目干系人需要、定义系统和管理需求的变化。   

2. 计划:按计划管理

“产品只是跟产品计划一样好”FIS96 )。

构思一个新项目;评估范围和风险;监视和控制项目;计划和评估每个迭代和阶段 - 这些就是项目管理规程的“要素”。

软件开发计划收集管理项目所需的信息。它用于计划项目时间表和资源需要,以及按照时间表跟踪进度。它处理如下方面: 项目组织、时间表、预算和资源。它还可以包含对需求管理、配置管理、问题解决、质量保证、评估与测试和产品验收的计划。

在简单的项目中,对于这样的主题,每一个都可用一两个句子概括。例如,配置管理计划可以简单地声明:“在每天结束时,项目目录结构的内容将被压缩成 zip 文件,并复制到标有日期和标签的 zip 磁盘,然后标记一个版本号并放在集中的文件柜中。

计划工件的格式不如计划活动和形成这些活动的想法那么重要。;计划的形式或您所使用的构造工具并不重要。正如 Dwight D. Eisenhower 所说:“计划并不重要;重要的是实施计划。”

3. 风险:降低风险并跟踪相关问题

在项目中及早识别并着手解决风险最高的问题和跟踪它们(以及其他相关问题)非常必要。风险列表用于记录察觉到的、威胁项目成功的风险。 它按优先级的降序来识别可能导致重大负面结果的事件。

对于每个风险,都应伴有一个计划来降低该风险。它充当计划项目活动的焦点,并且是组织迭代的基础。

4. 业务案例:检验业务案例

业务用例从业务的立场提供了确定该项目是否值得投资的必要信息。

业务案例主要用于为实现项目远景而制定经济计划。一旦制定之后,业务案例就用来对项目提供的投资收益率(ROI)进行精确的评估。它提供项目的合理依据,并确定对项目的有关经济约束。它向经济决策者提供关于项目价值的信息,并用于确定该项目是否应继续前进。

该描述不应深挖问题的细节,而应就为什么需要该产品树立一个有说服力的论点。但是它必须简短,这样就容易让所有项目团队成员理解并牢记。在关键里程碑处,将重新检验业务案例,以查看预期收益和成本的估计值是否仍然准确,以及该项目是否应继续

5. 体系结构:设计组件体系结构

在 Rational Unified Process(RUP)中,软件系统(在给定点处)的体系结构是系统的重要组件与由依次减小的组件和接口组成的组件通过接口进行交互的组织或结构。主要组成部分有哪些?它们如何组合在一起?我们有框架可用来添加软件的其余部分吗?

要说明并理解软件体系结构,您必须先定义一种体系结构表示法,它是一种描述体系结构重要方面的方式。该描述可以在软件体系结构文档中找到,它以多个视图来表现体系结构。

每个体系结构视图都针对了开发流程中特定于项目干系人(用户、设计人员、经理、系统工程师、维护人员等)的一组具体问题。 这充当软件设计人员和其他项目团队成员就对项目做出的重大结构决策进行沟通的介质。

定义候选体系结构、优化体系结构、分析行为并设计系统组件,这是分析与设计规程及原则提升抽象级别的“要素”。

6. 原型:递增地构造和测试产品

RUP 是为了尽早排除问题和解决风险和问题而构建、测试和评估产品的可执行版本的一种迭代方法。

递增地构造和测试系统的组件,这是实施测试规程及原则通过迭代证明价值的“要素”。

7. 评估:定期评估结果

使用直接从现行活动中推断出的客观数据进行持续的开放式沟通,以及不断演进的产品配置,这在任何项目中都很重要。定期的状态评估为处理、沟通和解决管理问题、技术问题和项目风险提供了一种机制。除了确定这些问题外,每次评估都应指定一个到期日和一个负责解决问题的责任人。这应按需要定期跟踪并更新。

这些项目快照提供了让管理层关注的缓冲时间。尽管阶段可能有所不同,但强制功能需要捕获项目历史记录并进行解析才能除去限制进度的任何障碍或瓶颈。

迭代评估捕获迭代的结果、符合评估条件的程度、得到的教训和要实施的流程变更。

迭代评估是迭代法的一个必要工件。根据项目的范围和风险以及迭代的性质,它的范围可能包括从简单的演示和结果记录到完整的正式测试复审记录。

关键集中在流程问题以及产品问题上:“您越早地落后,就需要越多的时间追赶。”

8. 变更请求:管理并控制变更

在向用户展示第一个原型时(通常比这还要早),就将产生变更请求。 (生活的一种必然!)为了控制这些更改并有效地管理项目的范围和项目干系人的期望,重要的是通过变更请求来建议对任何开发工件所作的所有变更并始终使用一个流程来管理。

变更请求用于记录和跟踪缺陷、增强请求和任何其他类型的产品变更请求。 变更请求的好处在于它们提供决策的记录,而且鉴于它们的评估流程,可确保所有项目团队成员都理解潜在变更的影响。变更请求对于管理项目的范围以及评估建议变更的影响非常必要。

在项目生命周期中发生变更时管理和控制项目的范围,同时尽可能保持考虑并满足所有项目干系人需要的目标 - 这是配置与变更管理规程支持材料:控制变更的“要素”。

9. 用户支持:部署可用的产品

流程用于生产可用的产品。流程的所有方面都应保持着这个目标进行定制。产品通常不仅仅是软件。至少应该有一个《用户指南》(可能通过联机帮助来实施)。也可以包含一个《安装指南》和《发行说明》。根据产品的复杂性,还可能需要培训资料以及伴随任何产品打包的材料清单。 这些相关联的活动就形成部署规程。 

10. 流程:采用适合您的项目的流程

选择适合您正开发的产品类型的流程是非常必要的。即使在选定一个流程后,也不能盲目遵循这个流程 - 必须应用常理和经验来配置流程和工具,以满足组织和项目的需要。

为项目改编流程是环境规程的一个重要部分。

关于根据项目和组织来调整 RUP 的更多信息,请参阅概念:RUP 定制

结论

以上“要素”提供了一种快速评估流程并确定在何处改进最有益的方法。重要的是探索在忽略这些要素中任何一个的情况下会发生什么。例如:

  • 没有远景?您可能失去方向并可能容易因走弯路而烦恼。
  • 没有流程?没有一般的流程,团队会在何人何时有何举动方面沟通不力、发生误解。
  • 没有计划?您将无法跟踪进度。
  • 没有风险列表?您现在可能正专注于错误的问题,并可能在今后 5 个月时间内都在挖一口未知的矿井。
  • 没有业务案例?您会冒在这个项目上浪费时间和金钱的风险。它可能会取消或破产。
  • 没有体系结构?您可能无法在出现通信、同步和数据访问问题时处理它们;可能存在规模和性能方面的问题。
  • 没有产品(原型)?尽快将产品摆在客户面前。光是积累一堆文书并不能让您或您的客户确信产品将会取得成功 - 并且这会使超出预算和时间表和/或彻底失败的风险最大化。
  • 没有评估?不要回避现实。重要的是面对真相。究竟离截止期限有多近?距离您的质量目标或预算目标又如何呢?是否所有问题都得到充分的跟踪?
  • 没有变更请求?您如何跟踪项目干系人的请求?您如何区分它们的优先次序?以及不让较低优先级的请求落空?
  • 没有用户支持?当用户有问题或不确定如何使用产品时怎么办?获得帮助的难易程度如何?

这些“要素”还介绍了 RUP 中的每个规程分组:RUP 规程,并支持其主要原则