流程要素主题
简介
要在交付优质软件和快速交付软件之间达到微妙的平衡(软件悖论!),其关键是了解流程的必要元素,并遵循定制流程的某些指南来最好地满足项目的特定需要。这应在坚持整个行业中经证实的最佳实践的同时进行,以帮助软件开发项目取得成功。 下面描述了有效的软件流程的必要原则。 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 中的每个规程及其许多最佳实践。 |
Rational Unified Process
|