MBA智库百科：统一软件开发过程的核心概念解析

菏泽炫佑科技

MBA智库百科：统一软件开发过程的核心概念解析

摘自MBA智库百科（）

（重定向自 RUP）

统一软件开发过程（RUP）

目录

[编辑]

什么是统一软件开发流程

统一软件开发过程（RUP）又称统一软件过程，是一种面向对象、基于网络的程序开发方法论。 据（Rose 和统一建模语言的开发者）介绍，它就像一个在线导师，可以为程序开发的各个方面和级别提供指南、模板和案例支持。 统一软件开发流程和类似产品，例如面向对象的软件流程 (OOSP) 和 OPEN，是一种将面向流程的开发方面（例如定义的阶段、技术和实践）与其他开发集成在一起的软件工程工具。组件（如文档、模型、手册、代码等）被集成到统一的框架中。

[编辑]

统一软件开发过程的核心概念

RUP 中定义了一些核心概念，如下所示：

角色：描述个人或团体的行为和职责。 RUP 预先定义了许多角色。

活动：是一个具有明确目的的独立工作单元。

工件：由活动生成、创建或修改的一条信息。

[编辑]

六大体会

1.迭代开发。 在软件开发的早期阶段，完全准确地捕捉用户需求几乎是不可能的。 事实上，我们经常遇到的问题是，在整个软件开发项目中，需求经常发生变化。 迭代开发使得需求在每次迭代过程中都可能发生变化，通过不断的细化加深对问题的理解。 迭代开发不仅可以降低项目的风险，而且每次迭代都以可执行版本结束，可以给开发人员带来启发。

2、管理需要。 确定系统需求是一个持续的过程，开发人员在开发系统之前无法完全指定系统的真实需求。 RUP 描述了如何提取、组织和记录系统的功能和约束。 用例和脚本的使用已被证明是捕获功能需求的有效方法。

3.基于组件的架构。 组件使重用成为可能，系统可以由组件组成。 基于独立、可替换、模块化组件的架构有助于管理复杂性并提高重用性。 RUP描述了如何设计一个灵活的、适应变化的、易于理解的、有利于重用的软件架构。

4.视觉建模。 RUP常常与UML联系在一起，建立软件系统的可视化模型，帮助人们提供管理软件复杂性的能力。 RUP 告诉我们如何对软件系统进行可视化建模并获取有关架构和组件的结构和行为的信息。

5. 验证软件质量。 在 RUP 中，软件质量评估不再是事后执行的单独活动或由单独的团队执行，而是构建到流程中的所有活动，以便可以及早发现软件中的缺陷。

6. 控制软件变更。 如果迭代开发中没有严格的控制和协调，整个软件开发过程很快就会陷入混乱。 RUP 描述了如何控制、跟踪、监视和修改以确保成功的迭代开发。 RUP 通过软件开发过程中的工件将更改与其他工作区隔离，从而为每个开发人员建立了一个安全的工作区。

注：Rose是该公司出品的面向对象的统一建模语言可视化建模工具。

[编辑]

统一软件开发流程的二维开发模型

RUP 软件开发生命周期是一个二维软件开发模型。 横轴按时间组织，是流程开发的生命周期特征，反映了开发流程的动态结构。 用于描述它的术语主要有周期（Cycle）、阶段（Phase）、迭代（）和里程碑（）； 纵轴是内容被组织成自然的逻辑活动，反映了发展过程的静态结构。 用于描述它的术语主要有活动（）、产品（）、工作人员（）和工作流（）。 如下所示：

[编辑]

定制统一的软件开发流程

RUP是一个通用的过程模板，包含开发过程中涉及的许多开发指南、产品和角色描述。 由于它非常庞大，因此在使用 RUP 时需要针对特定​​的开发组织和项目进行定制。 RUP 已配置。 RUP 就像一个元过程。 通过剪裁RUP，可以获得许多不同的开发过程。 这些软件开发过程可以被视为RUP的具体实例。 RUP 剪裁可以分为以下步骤：

1. 确定该项目需要哪些工作流程。 RUP 的 9 个核心工作流程并不总是需要的，而是可以选择的。

2. 确定每个工作流程需要哪些工件。

3.确定四个阶段之间如何演变。 确定阶段之间的演进应以风险控制为原则。 确定每个阶段需要哪些工作流程、每个工作流程执行到什么程度、包含哪些产品以及每个产品完成到什么程度。

4. 确定每个阶段内的迭代计划。 规划 RUP 4 个阶段中每次开发迭代的内容。

5.规划工作流程的内部结构。 工作流涉及角色、活动和产品，其复杂程度与项目规模即角色数量有关。 *后，规划工作流的内部结构，通常以活动图的形式给出。

[编辑]

统一软件开发过程的阶段和里程碑

RUP 中的软件生命周期在时间上被分解为四个连续的阶段，即：初始阶段（ ）、细化阶段（ ）、构建阶段（ ）和交付阶段（ ）。 每个阶段都以一个重要的里程碑结束； 每个阶段本质上是两个里程碑之间的时间跨度。 每个阶段结束时都会进行评估，以确定该阶段的目标是否已实现。 如果评估结果令人满意，项目可以进入下一阶段。

1. 初始阶段

初始阶段的目标是建立系统的业务案例并确定项目的边界。 为了实现这一目标，有必要识别与系统交互的所有外部实体，并在高层定义交互的特征。 这一阶段意义重大，重点关注整个项目业务和需求方面的主要风险。 对于基于遗留系统的开发项目，初始阶段可能会很短。 初始阶段结束时是**个重要的里程碑：生命周期目标 ( ) 里程碑。 生命周期目标里程碑评估项目的基本可行性。

2. 细化阶段

细化阶段的目标是分析问题区域、建立良好的架构基础、准备项目计划并消除项目的*高风险元素。 为了实现这一目标，架构决策必须基于对整个系统的理解，包括其范围、主要功能和非功能需求（例如性能）。 同时，建立项目的支持环境，包括创建开发案例、创建模板、指南和准备工具。 第二个重要的里程碑出现在细化阶段结束时：生命周期结构 ( ) 里程碑。 生命周期结构里程碑为系统结构建立了管理基线，并使项目团队能够在构建阶段进行测量。 此时，将检查详细的系统目标和范围、结构选择以及主要风险的解决方案。

3、施工阶段

在构建阶段，所有剩余的组件和应用程序功能都被开发并集成到产品中，并且所有功能都经过详细测试。 施工阶段是一个制造过程，其重点是管理资源和控制运营以优化成本、进度和质量。 构建阶段结束时出现第三个重要里程碑：初始功能 ( ) 里程碑。 初始功能里程碑决定产品是否可以部署在测试环境中。 此时需要判断软件、环境、用户是否可以启动系统的运行。 此时的产品版本通常也称为“测试版”。

4. 交付阶段

交付阶段的重点是确保*终用户可以使用该软件。 交付阶段可以跨越多次迭代，包括测试产品以准备发布，并根据用户反馈进行细微调整。 在生命周期的这一点上，用户反馈应主要集中在产品调整、设置、安装和可用性问题上，所有主要的结构问题都应在项目生命周期的早期阶段得到解决。 交付阶段结束时是第四个里程碑：产品发布 ( ) 里程碑。 此时，确定目标是否已实现以及是否应开始另一个开发周期。 在某些情况下，这个里程碑可能与下一个周期的初始阶段的结束同时发生。

[编辑]

统一软件开发过程的核心工作流程

RUP中有9个核心工作流程（Core），分为6个核心流程工作流程（Core）和3个核心支持工作流程（Core）。 虽然这 6 个核心流程工作流可能会让人想起传统瀑布模型中的几个阶段，但需要注意的是，迭代过程中的各个阶段完全不同，并且在整个生命周期中会一次又一次地访问这些工作流。 九个核心工作流程在整个项目中轮流使用，在每次迭代中以不同的重点和强度重复。

1. 业务建模 ( )

业务建模工作流描述如何为新的目标组织开发愿景，并基于此愿景在业务用例模型和业务对象模型中定义组织的流程、角色和职责。

2. 要求()

需求工作流程的目标是描述系统应该做什么，并让开发人员和用户就该描述达成一致。 为了实现这一目标，必须提取、组织和记录所需的功能和约束； *重要的是了解系统解决问题的定义和范围。

3.分析与设计(&)

分析和设计工作流程将需求转化为未来系统的设计，为系统开发稳健的结构，并调整设计以匹配实施环境并优化其性能。 分析设计的结果是设计模型和可选的分析模型。 设计模型是源代码的抽象，由设计类和一些描述组成。 设计类被组织成具有良好接口的设计包（）和设计子系统（），其描述反映了类的对象如何协同工作来实现用例的功能。 设计活动以建筑设计为中心。 该架构由几个结构视图来表达。 结构视图是整个设计的抽象和简化。 该视图中省略了一些细节，以使重要特征更加清晰。 架构不仅是良好设计模型的媒介，而且还提高了系统开发过程中创建的模型的质量。

4. 实现()

实现工作流的目的包括以层次子系统的形式定义代码的组织结构； 以组件的形式实现类和对象（源文件、二进制文件、可执行文件）； 将开发的组件作为单元进行测试和集成 由单个开发人员（或团队）将结果生成到可执行系统中。

5. 测试

测试工作流程应验证对象之间的交互，验证软件中所有组件的正确集成，验证所有需求是否已正确实现，识别并确认在软件部署之前已提出并处理了缺陷。 RUP提出了迭代方法，即在整个项目中进行测试，尽早发现缺陷，从根本上降低修改缺陷的成本。 测试类似于三维模型，从可靠性、功能和系统性能进行。

6. 部署（）

部署工作流程的目的是成功构建软件并将其分发给*终用户。 部署工作流程描述了与确保软件产品对*终用户的可用性相关的活动，包括打包软件、构建软件本身以外的产品、安装软件以及向用户提供帮助。 在某些情况下，这可能还包括规划和进行 beta 测试、移植现有软件和数据以及正式验收。

7.配置和变更管理(&)

配置和变更管理工作流程说明了如何控制多成员项目中的大量工件。 配置和变更管理工作流程为管理不断发展的系统中的多个变体、在软件创建期间跟踪版本提供了指导。 工作流描述了如何管理并行开发、分布式开发以及如何自动创建项目。 它还解释了如何维护产品修改原因、时间和人员的审核记录。

8. 项目管理（ ）

软件项目管理平衡各种潜在冲突的目标，管理风险，克服限制，并成功交付令用户满意的产品。 其目标包括：提供项目管理框架，为规划、人员配备、执行和监控项目提供实用指南，以及提供风险管理框架。

9.环境()

环境工作流的目的是向软件开发组织提供软件开发环境，包括流程和工具。 环境工作流程重点关注配置项目流程所需的活动。 他们还支持制定项目规范的活动，提供有关如何在组织中实施该流程的分步指导和说明。

[编辑]

统一软件开发流程的迭代开发模型

RUP 中的每个阶段都可以进一步分解为迭代。 迭代是一个完整的开发周期，它产生产品的可执行版本（*终产品的子集），从一个迭代逐步发展到另一个迭代，成为*终系统。 传统的项目组织是顺序传递每个工作流，并且每个工作流只传递一次，这就是我们熟悉的瀑布生命周期（见下图）。 这样做的结果是，到实施结束时，当产品完成并开始测试时，分析、设计、实施阶段遗留下来的大量隐藏问题就会出现，项目可能不得不停止。一个漫长的纠错周期就开始了。

一种更灵活、风险更小的方法是多次经历不同的开发工作流程，这可以让您更好地理解需求，构建健壮的架构，并*终交付一系列增量完成的版本。 这称为迭代生命周期。 工作流程中的每个顺序传递称为迭代。 软件生命周期是软件逐步开发的迭代过程。 迭代包括生成可执行版本的开发活动，以及使用该版本所必需的其他辅助组件，例如版本描述、用户文档等。因此，开发迭代在某种意义上是所有工作流程中的一个完整过程，其中至少包括：需求工作流程、分析设计工作流程、实现工作流程、测试工作流程。 它本身看起来就像一个小型瀑布项目（见下图）。

与传统的瀑布模型相比，迭代过程具有以下优点：

1）降低增量支出的风险。 如果开发人员重复迭代，损失只是错误开发的迭代的成本。

2) 降低产品无法按照既定时间表进入市场的风险。 通过在开发早期识别风险，可以尽早解决这些风险，而不是在开发后期匆忙解决。

3）加快整个开发工作的进度。 因为开发人员知道问题的焦点是什么，所以他们的工作效率更高。

4）由于用户需求在一开始无法完全定义，通常会在后续阶段进行细化。 因此，迭代过程模型更容易适应需求的变化。

[编辑]

统一软件开发过程的十个要素

1. 开发前景

拥有清晰的愿景是开发满足利益相关者真正需求的产品的关键。 展望抓住了 RUP 需求过程的关键点：分析问题、理解涉众需求、定义系统以及在需求变化时对其进行管理。 愿景为更详细的技术要求提供了高级别的、有时是合同的基础。 顾名思义，它是软件项目的清晰的、通常是高层的视图，可供流程中的任何决策者或实施者使用。 它捕获了非常高水平的要求和设计约束，以便潜在的读者能够理解要开发的系统。 它还为项目审批流程提供输入，因此与业务案例密切相关。 *后，因为前景构成了“项目是什么？” 和“为什么我们要做这个项目？”，我们可以使用前景作为验证未来决策的一种方式。 愿景声明应回答以下问题，必要时可分解为更小、更详细的问题： 关键术语是什么？ （词汇​​表）我们要解决的问题是什么（问题陈述）涉及的人有哪些？ 用户是谁？ 他们各自的需求是什么？ 产品有什么特点？ 功能要求是什么？ （用例）？ 非功能性需求有哪些？ 设计限制是什么？

2. 实现计划

“产品的质量取决于产品的计划。” 在 RUP 中，软件开发计划 (SDP) 集成了管理项目所需的各种信息，并且可能包括在启动阶段开发的一些单独的内容。 SDP 必须在整个项目中得到维护和更新。 SDP定义了项目进度（包括项目计划和迭代计划）和资源需求（资源和工具），并可以根据项目进度跟踪项目进度。 同时也指导其他流程内容的规划（原文：）：项目组织、需求管理计划、配置管理计划、问题解决计划、QA计划、测试计划、评估计划和产品验收计划。

在较简单的项目中，这些计划的陈述可能只有一两句话。 例如，配置管理计划可以简单地说明：每天结束时，项目目录的内容将被压缩成 ZIP 包，复制到 ZIP 磁盘，标记日期和版本，并放置在中央文件柜中。 软件开发计划的格式远不如计划活动本身以及驱动这些活动的想法重要。 正如艾森豪威尔（D.）所说：“计划就是一切。” “实现计划”——以及列表中的第 3、4、5 和 8 项——抓住了 RUP 中项目管理过程的本质。 项目管理流程包括以下活动：构思项目、评估项目规模和风险、监视和控制项目以及规划和评估每个迭代和阶段。

3. 识别并降低风险

RUP 的要点之一是在项目早期识别并解决*大的风险。 项目团队识别的每个风险都应该有相应的缓解或解决计划。 风险列表应既作为项目活动的规划工具，又作为确定迭代的基础。

4. 分配和跟踪任务

在任何项目中，从正在进行的活动和不断发展的产品的客观数据中得出持续分析非常重要。 在 RUP 中，定期项目状态评估提供了报告、沟通和解决管理问题、技术问题和项目风险的机制。 一旦团队确定了这些障碍（栅栏），他们就会指派一名人员负责所有这些问题并指定解决日期。 应定期跟踪进展情况，并在必要时发布更新。 （原文：be as 。）这些项目“快照”突出了需要管理层注意的问题。 虽然周期可能会有所不同，但定期评估使管理人员能够了解项目的历史并消除限制进度的任何障碍或瓶颈。

5. 检查业务理由

业务案例从业务角度提供了必要的信息，以决定项目是否值得投资。业务案例还可以帮助制定实现项目前景所需的经济计划。 它提供了开展该项目的理由并建立了经济约束。 随着项目的进展，分析师使用业务案例来正确估计投资回报 (ROI)。 业务案例不应深入研究问题的细节，而应为项目创建一个简短但令人信服的理由，以便所有项目成员都能轻松理解和记住。 在关键里程碑处，管理者应审查业务案例MBA智库百科：统一软件开发过程的核心概念解析，计算实际成本、预期回报，并决定是否继续该项目。

6.设计组件架构

在 RUP 中，软件系统的体系结构是指系统关键组件的组织或结构。 组件之间通过接口进行交互自动化软件开发，组件又由更小的组件和接口组成。 即主要有哪些部分？ 它们如何组合在一起？ RUP 提供了一种非常系统的方法来设计、开发和验证架构。 分析和设计过程包括以下步骤：定义候选架构、细化架构、分析行为（用例分析）和设计组件。 要陈述和讨论软件架构，您必须首先创建描述架构重要方面的架构表示。 在 RUP 中，架构表示由软件架构文档捕获，该文档提供架构的多个视图。 每个视图都描述了一组利益相关者所关心的正在进行的系统的某些方面。 利益相关者是*终用户、设计师、经理、系统工程师、系统管理员等。 该文档使系统架构师和其他项目团队成员能够有效地传达与架构相关的主要决策。

7. 增量构建和测试产品

RUP 中实现和测试过程的关键点是在整个项目生命周期中增量地编码、构建和测试系统组件，并在启动后的每次迭代结束时生成可执行版本。 在细化阶段的后期，有一个架构原型可供评估； 如有必要，它可以包括用户界面原型。 然后，在构建阶段的每次迭代中，组件不断集成到可执行的、经过测试的版本中，*终发展为*终产品。 动态且及时的配置管理和审查活动也是这一基本流程要素的关键（原文：）。

八、验证与评价结果

顾名思义，RUP 的迭代评估捕获迭代的结果。 评估确定迭代满足评估标准的程度，还包括吸取的经验教训和实施的流程改进。 根据项目的规模和风险以及迭代的特点，评估可能是演示及其结果的简单记录，也可能是完整的、正式的测试评审记录。 这里的关键是关注流程和产品问题。 越早发现问题，出现问题的可能性就越小。 （原文：你跌倒了，你就需要更多的时间去追赶。）

9. 管理和控制变更

RUP 的配置和变更管理流程的要点是在变更发生时以及整个生命周期中管理和控制项目的规模。 目的是考虑所有利益相关者的需求并尽可能满足他们，同时仍然及时交付合格的产品。 在用户获得产品的**个原型之后（通常在他们要求更改之前），他们会要求更改。 变更提议和管理流程保持一致非常重要。 在 RUP 中，变更请求通常用于记录和跟踪缺陷和增强请求，或对产品提出的任何其他类型的变更请求。 变更请求提供了一种评估变更潜在影响并记录有关这些变更的决策的方法。 它们还有助于确保所有项目团队成员了解变革的潜在影响。

10. 提供用户支持

在 RUP 中，部署过程的重点是打包和交付产品以及帮助*终用户学习、使用和维护产品的任何必要材料。 项目团队至少应该为用户提供用户指南（也许通过在线帮助），可能还包括安装指南和发行说明。 根据产品的复杂程度，用户可能还需要相应的培训材料。 *后，通过物料清单（BOM）清楚地记录哪些材料应随产品一起交付。 关于要求，当有人读完我的元素列表后，他们可能会强烈不同意我的选择。 比如他会问，要求在哪里？ 它们不重要吗？ 我会告诉他为什么我没有包括它们。 有时，我会问项目组（尤其是内部项目的项目组）：“你们的需求是什么？”，我得到的答案是：“我们确实没有任何需求。” 一开始我对此感到非常惊讶（我有军事航天开发背景）。 他们怎么可能没有要求呢？ 当我进一步询问时，我发现需求对于他们来说就是外界提出的一套强制性的声明，要求他们必须做的事情，否则项目验收就无法通过。 但他们肯定没有得到这个声明。 尤其是当项目组陷入同时研发的局面时，产品需求自始至终都在演变。 于是，我又问了他们一个问题：“好吧，那么你们的产品前景如何？”。 然后他们的眼睛就亮了。 然后，我们就**要素（“开发前景”）中列出的问题沟通得很顺利，需求自然流动（原文：和正义的流动。）。 也许只有对于根据具有明确要求的合同工作的项目团队来说，在元素列表中包含“满足要求”才有用。 请记住，我的清单只是为了进一步讨论的起点。

[编辑]

统一软件开发流程总结

RUP 具有许多优点：提高团队生产力、迭代开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量和控制软件变更等，为每个开发人员的所有关键开发活动提供必要的指南、模板、工具指导并确保所有成员共享相同的知识库。 它建立了简洁、清晰的流程结构，为开发流程提供了更大的通用性。 但同时它也存在一些缺点：RUP只是一个开发过程，并没有涵盖软件过程的所有内容。 例如，缺乏软件操作和支持的内容； 另外，它不支持多项目开发结构，这是肯定的。 在一定程度上降低了开发组织内广泛重用的可能性。 可以说RUP是一个非常好的开始，但它并不完美。 在实际应用中，可以根据需要进行改进，并可以用OPEN、OOSP等其他软件过程的相关内容来补充和完善RUP。

[编辑]

各种软件过程模型的特点

不同的软件过程模型对软件开发过程有不同的认识和认识，支持不同的软件项目和开发组织。 下表比较分析了各种软件过程模型的特点及其适用的软件项目类型。

各种软件过程模型的特点

型号名称、技术特点、适用范围

瀑布模型

简单，分阶段，阶段之间有因果关系，

每个阶段完成后会有审核，允许反馈，但不支持

用户参与，需要预先确定的需求

需求易于定义且难以更改的软件系统

快速原型模型

不需要提前完整定义需求，支持用户参与。

支持需求的逐步改进和确认，能够适应用户需求的变化

需求复杂、难以确定、动态变化的软件系统

增量模型

软件产品是一点一点增量开发的，

允许开发活动并行和重叠

with risks and user needs

迭代模型

It is not to a at one time. The

is as a of user needs and .

whose are to and

model

model, rapid model and model

type of and risk

where are to and , and risks are high

鲁普

, and : it can be ,

, , and ;

that are and whose are to and ;

The team has rich in and

[编辑]

参考

Tan , Mao , Dong Wei. [M]. Press, 2009.04.

from ""

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等