第14章 统一软件开发过程

统一软件开发过程

14.1统一软件开发过程概述什么是软件开发过程统一软件开发过程简介统一软件开发过程发展历程什么是软件开发过程工程化开发方法的需要：开发成本失控、可靠性低、人月神话软件开发过程：指的是一款软件从无到有，直到最后交付使用以及维护的全过程。这个过程包含了许多软件开发方面的方法、技术、实践，并且也包括一些软件相关产物，如文档、模型、代码等等的制造和产生。什么是软件开发过程现如今，业内有许多成熟的软件过程可供借鉴，例如：RationalUnifiedProcess（RUP，统一软件开发过程）Object-OrientedSoftwareProcess（OOSP，面向对象开发过程）OPENProcessFramework（OPEN过程框架）Scrum（一种迭代式增量软件开发过程，通常用于敏捷软件开发）ExtremeProgramming（极限编程）DynamicSystemsDevelopmentMethod（DSDM，动态系统开发方法）统一软件开发过程简介统一软件开发过程（简称RUP）是一套由IBM下属的Rational分部提出的软件工程方法，它由IvarJacobson的TheObjectoryProcess和TheRationalApproach发展而来。统一软件开发过程将软件开发过程按照时序组织成几个阶段，每个阶段有当前阶段的最重要任务，并且根据这些任务的完成情况为下一个阶段提供输入，实现每个阶段的逻辑连接。统一软件开发过程发展历程14.2过程总览水平轴表示时间，从左到右看是从初始阶段到接近完成阶段的发展过程。纵轴上表示过程的某个静态内容，它们代表了一系列的工作活动。14.3阶段和迭代——时间维度在RUP中，一个软件的生命周期被分为许多轮，每一轮是一个子开发过程，其成品是当前制作产品的新一版。并且RUP将每一轮又分为四个阶段，它们是：起始阶段（Inceptionphase）细化阶段（Elaborationphase）构建阶段（Constructionphase）转化阶段（Transitionphase）起始阶段起始阶段是一个项目的开始，在这个阶段中软件开发团队需要建立好业务事例，并确定好该项目的范围。首先，要识别出所有与系统存在交互的外部实体；其次，需要在高层次上来定义和说明这些交互的本质特征。业务事例包含项目标准、风险评估、资源需求估计、阶段计划项目标准定义了项目完成时应当达到的一些条件；风险评估发掘在软件开发过程中可能遇到的各种问题；资源需求估计是对完成这个项目所需要的资源消耗的估算；阶段计划需要提供与阶段对应的日期，并提出用于阶段交接的里程碑。细化阶段细化阶段的主要目的是分析问题域，为整个项目计划的执行建立一个稳定的结构基础，以及消除一些风险系数最高的因素。细化阶段具有承前启后的意义：一方面，细化阶段的结果可能为整个项目的进一步开展提供了重要的依据，也可能为这个项目宣判死刑；另一方面，在细化过程交付之后，项目将从前面的轻量级、低风险的工作进入高风险、高投入的工作中。细化阶段的重点控制对象是系统分析的稳定性和开发的可行性。构建阶段在构建阶段中，我们将要开发和整合所有剩余的组件和应用特性，然后对所有的功能和特性进行完全的测试。在这个过程中，我们应当着重管理资源和控制活动，以求优化资金和时间成本，并力保产品质量在已有的资源条件下达到最高。构建流程可以是线性的也可以是并行的。转化阶段转化阶段又称为交付阶段，因为其主要目的就是把制作出来的软件产品交付给用户使用。转化过程的核心任务可以总结成三个：使用户可以在无帮助环境下自由使用产品；使投资者认同这个项目确实已经部署完毕，并且符合评估标准；尽可能有效率地使产品达到最终产品标准。迭代RUP中的每一个阶段都可以进一步分解为多个迭代。一次迭代定义为一个完整的循环开发过程，在每一轮过程中需要有内部或外部的产出。迭代过程具有以下几个显著优点：可以更早地弱化风险；更灵活地处理各种变化；更高层次的复用；开发团队不必一次完成所有工作，可以在工作的过程中学习和调整；通常提供了更高的产品质量。14.4过程的静态结构“谁”——工作者“什么方法”——活动“做什么”——制品“什么时候”——工作流工作者工作者定义了软件开发工作中某个工作单位的行为和责任，这个工作单位可能指某个个体，或者某个工作小组。工作者更像是一种角色：在不同的时刻（也可能同时），同一个个体可能担任着不同的工作者角色。确定的工作者角色担任着确定的任务和责任，它要亲力亲为地完成那些任务。活动活动定义了一件事或一个动作，并且必须存在一个特定的工作者角色负责执行这个活动。一些常见的活动举例：设计一轮迭代（工作者：项目主管）发现用例和参与者（工作者：系统分析师）检查软件设计（工作者：设计检查员）运行性能测试（工作者：性能测试员）制品制品描述了一个过程中产生、修改或使用的事物。制品是一个工作者执行某件活动的工具（输入），也是一个工作者执行活动后的成果（输出）。一些常见的制品：模型：用例模型、设计模型、分析类模型等模型中的元素：类、用例、参与者、子系统等文档：需求分析文档、可行性分析文档、用户手册等代码可执行文件工作流当活动具备了工作者、活动、制品三个核心元素之后，需要使用工作流来对活动的操作顺序进行描述。除此之外，工作流还可以展示工作者之间的交互关系。工作流就是展示一个活动的可见价值的流程，其最重要的意义是它为活动设计者对于活动进度宏观掌控提供了可能。14.5核心工作流六个核心工程工作流:业务建模工作流需求工作流分析与设计工作流实现工作流测试工作流部署工作流三个属于核心支持工作流：项目管理工作流配置与变更管理工作流环境工作流业务建模工作流在业务建模阶段我们对一些鲜明的业务过程进行建模，这种模型也就是本书第二部分中着重介绍过的业务用例模型。分析业务用例的过程就是帮助设计人员理解业务的过程。需求工作流在需求工作流中，首要任务是让开发者与客户经过反复地磋商，最终确定这个系统究竟应该做什么。对于需求调研得到的文档，我们应首先对其进行需求分析。简而言之，就是获取参与者和用例的过程。分析和设计工作流在分析和设计工作流中，我们主要关心这个系统将如何被实现。对于这个问题，我们考虑三个方面：系统在某个环境下运行时的性能；对于用户需求的满足程度；系统结构的稳定性。分析和设计工作流的输出主要是设计模型，还可能有一套分析模型。设计模型包含一系列包，和其中的设计类与子系统，对于各个组件应当有良好的接口定义，并且应当包含一些说明描述这些设计类应当如何协作以完成特定的用例任务。实现工作流实现工作流就是编程实现各个设计组件的过程。实现工作流的主要任务目标是：通过子系统等模型确认代码结构；实现各个组件中的类；对组件进行单元测试；将实现的成果整合进已有的可运行系统中。测试工作流测试工作流将要贯穿开发过程的始终，在测试时我们使用三个标准来评价当前的制品，即可靠性、功能性和性能，其中性能又分为应用性能和系统性能。核心任务可以列举为：确认对象间交互可用；确认组件与其余系统部分整合良好；确认当前组件的所有需求已经满足；确认缺陷已经在软件部署之前被解决。部署工作流部署工作流的主要工作就是输出可用的完整产品，并将产品交付到用户手中。部署工作流可能涉及以下几个活动：生成软件的release版本；打包软件；分发软件；安装软件；为用户提供必要帮助。项目管理工作流在项目管理工作流中，我们主要关心迭代开发过程当中某些特定的方面，其目标是为了使任务更容易高质量地完成。在这个阶段中我们需要提供：一个用于管理软件密集型项目的框架；开发过程中计划、执行、人员调配和项目监控等过程的实用指导；风险管理框架。配置和变更管理工作流配置和变更管理工作流描述了开发团队应当如何掌控数量庞大的制品。为什么需要控制制品：同时更新导致出错——几个不同的工作者分别对同一制品进行更改，后提交的一方将先提交的制品覆盖；交流不及时——制品中某些部分已经被修改或修复，但某些制品的分享者并不知情，仍然在进行修改；版本混淆——版本混淆表现在我们发现了某个版本下某个模块的问题，却无法找到对应版本的制品去做修复。环境工作流环境工作流的目的是给予开发人员以足够的编码工具、第三方库等等各类资源，这些工作资源统称为环境。这个工作流关注那些使得项目进程得以顺利进行的辅助活动，此工作流需要及时地提供一些指导原则、开发包、实用库，以便开发人员保持高效率的工作。14.6在统一软件开发过程中使用UML起始阶段常用UML图细化阶段常用UML图构建阶段常用UML图转化阶段常用UML图起始阶段常用UML图在起始阶段，通常有用例图、类图、活动图、顺序图等UML图的参与。获取用户需求之后首先要将这些需求转化为系统的顶层用例图。在确定了用例之后，需要为重要用例添加事件流描述。有了事件流描述之后就可以为一些用例中使用到的系统功能来指定分析类。对于一些重点用例，可以绘制它们的动态模型。细化阶段常用UML图在细化阶段经常需要使用到类图、包图、组件图几种静态视图，以及所有动态视图。静态视图中，细化阶段的类图主要描述系统的设计类。动态视图用来确定任意时