2.3 快速交付过程划分

基于快速交付的项目管理，将软件全生命周期划分为需求、设计、开发、测试、发布和部署六个过程，这些过程既相互独立，又通过输入、输出相互联系。

2.3.1 需求过程

需求是项目所要完成的工作的集合，是确保项目完成的基础。同时，需求还是项目关键干系人期望的集合，是满足管理、业务、功能、技术等多个维度所需要生产的产品、服务或成果及相关工作的集合。

需求过程既包括具体的需求工作，又涵盖具有需求能力的团队工作内容。

1.工作内容

（1）制订项目调研计划，对需求工作涉及的人员、资源、进度、成本等进行初步计划，这是后续需求工作开展的基础。

（2）实施现状调研与需求分析。调研管理现状、系统现状，并进行业务需求及流程的梳理。

（3）编写差异报告。经过调研及需求分析，将当前系统与需求目标进行对比，并形成差异报告，指导后续工作。合理地规划与确定需求范围，有助于项目目标的实现。

（4）编写需求说明书，明确需求及相关业务流程。

（5）通过需求评审，确认需求并达成一致认可，这样可以降低后期需求变更带来的成本损失。

2.主要作用

需求过程的主要作用是获取软件需求，软件需求包括需求开发和需求管理两部分。

（1）需求开发，就是通过调查与分析，获取用户需求并定义软件需求，主要活动包括需求获取、需求分析和需求定义。工作人员需要借助相关的文档类工具来完成这些活动。

（2）需求管理，是在客户与项目组之间建立对需求的共同理解，维护好需求与其工作成果的一致性，并控制需求的变更。需求管理的主要活动包括需求确认、需求变更、需求跟踪和需求跟踪控制，需要借助项目团队共同约定的工具来实现工作的流转和交互，实现交付队伍、交付人员之间的协作和协同。

软件需求过程的工作内容和关系如图2-3所示。

软件需求具有模糊性、不确定性、变化性和主观性的特点，软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素，因此对于需求分析和需求变更的处理十分重要。通过对需求过程中问题的分析，使用知识体系中的需求工具来控制需求过程。

需求管理的具体形式包括需求调研问卷、需求调研报告、需求规格说明书、需求确认文档、需求变更文档规范等。快速交付要求在初始阶段对采集需求与用户需求的不一致性进行排查，避免需求在初始阶段发生偏差，从根本上解决项目后延的问题。这样既可以解决项目滞后的问题，提高项目交付的效率，又可以超前完成软件交付，提升项目交付的效果。

需求变更会给项目带来巨大的风险，会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降等不良后果，因而在软件开发项目中应尽量减少需求变更。若后期有变更，应采用项目变更控制系统和需求变更流程对变更进行控制，最大限度地降低需求变更带来的风险，提高软件交付效率。

为了更好地执行需求过程，还需要对需求相关的工作进行明确，如需求与客户期望功能的对应、需求的验收标准、相关需求形成的条件等。项目的需求过程是快速交付的基础与源头，明确需求可降低后期的变更损失。

2.3.2 设计过程

软件快速交付将系统分析、系统设计的工作内容合并成设计过程。在项目需求逐渐明确并进行业务流程梳理分析之后，项目的设计过程就显得尤其重要。合理的规划与设计，不仅可以使最终的产品或系统具有良好的稳定性、安全性，甚至是功能上的扩展性，而且能够适应后期的需求变化，保证最低的成本投入。设计工作可以分为总体设计与详细设计。总体设计是从战略高度或较高的层级对项目的全局与共性进行设计，保证设计方案的全局性、前瞻性和价值驱动。详细设计则基于总体设计方案，对具体的项目实现及细节进行设计。

设计过程既包括具体的设计工作，又涵盖具有设计能力的团队工作内容。

1.设计原则

设计工作需要基于对企业战略、现状、需求的充分理解，结合最佳实践来设计标准规范，规划业务架构、技术架构、总体架构等，需要遵循一系列的设计原则。

（1）安全性。要求系统能够保障用户信息、操作等多方面的安全要求，同时系统本身也要能够及时修复、处理各种安全漏洞，以提升安全性能。

（2）可靠性。软件系统规模越大越复杂，其可靠性就越难以保证，而应用本身对系统运行的可靠性要求也越来越高，因此软件系统的可靠性直接关系系统的应用能力。可靠性需要考虑避免可能发生的故障，且一旦发生故障后，具有排除故障的能力。

（3）健壮性。要求系统能够对可能的输入进行检查，保证系统在面临各种异常或非常规操作时能够正常运行。

（4）先进性。要求系统能够结合新兴技术及发展趋势，适应未来业务的变化和技术的发展，具备前瞻性。

（5）稳定性。稳定性是系统平稳运行时应用能力的体现。系统的稳定性要求系统的设计具备高性能，适应高并发和容错、容灾。

（6）可扩展性。系统设计需要充分考虑未来的扩展需求，并留有足够的接口及API，以适应快速的迭代升级及必要的变更。

2.主要工作

（1）架构设计，包括业务架构设计、功能架构设计、应用架构设计、逻辑架构设计、技术架构设计、数据架构设计等。

（2）操作流程设计，是针对功能在系统中的执行进行的流程设计，可以极大地提升用户体验。

（3）原型设计，有助于快速地形成系统的基础，并在原型的基础上迭代增加新的功能。

（4）数据库设计，包含抽象模型、物理模型、E-R图、数据库表、字段、类型等的设计。

（5）接口设计，提供了系统与外界交互、共享数据的基础。

因设计工作的重要性，其在整个项目周期中所占的时间比重较大，优秀的设计能够充分考虑系统的扩展性和适应性，为后期的技术实现及功能扩展提供良好的基础。产品是设计出来的，产品的优劣与设计的好坏直接相关，在快速交付中要求做好设计过程，这样可以为后期的系统交付节约巨大的成本。

2.3.3 开发过程

软件编码是将上一阶段详细设计得到的处理过程的描述，转换为基于某种计算机语言的程序，即源程序代码。开发过程就是负责软件编码，把软件设计转换成计算机可以处理的程序，包括选择合理的开发平台、开发环境、开发框架、开发语言，以保证软件产品的开发质量和开发效率。

开发过程既包括具体的开发工作，又涵盖具有开发能力的团队工作内容。

软件开发过程的主要内容如图2-4所示。

1.开发平台

在烦琐的开发过程中，开发人员将常用的函数、类、抽象、接口等进行总结、封装，形成可以重复使用的中间件，而随着中间件的成熟和通用，功能更强大、更能满足企业级需求的软件开发平台应运而生。开发过程离不了开发平台，不同技术路线的开发平台、不同厂商提供的开发平台，由于功能定位、行业背景和个性化应用的不同而存在较大差别。快速交付对开发平台提出了新的要求，包括满足快捷的可视化开发、满足灵活的工作流配置、满足方便的移动应用开发、满足多样的界面风格设计、满足配置就是代码的工具、满足复杂的系统集成组件等。在开发编码阶段需要根据项目特点选择合适的开发平台。

2.开发环境

软件开发平台的选择需要依据软件开发环境，而软件开发环境主要由软件工具构成，这些工具涉及代码生成类、页面生成类、报表生成类和辅助支撑类。开发环境除了工具外，还包括操作系统环境、基础开发环境、集成开发环境、数据库等。

（1）操作系统环境，主流的操作系统有Windows、Linux、UNIX、Mac OS、iOS和Android等。

（2）基础开发环境，如支持Java开发的JDK、支持.NET开发的Framework等。

（3）集成开发环境（Integrated Development Environment，IDE）是用于提供程序开发环境的应用程序，一般包括代码编辑器、编译器、调试器和图形用户界面工具。它集成了代码编写功能、分析功能、编译功能、调试功能、Web服务等一体化的开发软件服务套件。所有具备这一特性的软件或软件组件都可以叫集成开发环境，如Eclipse、Visual Studio、C++Builder、Delphi等。集成开发环境可以独立运行，也可以和其他程序并用。

（4）数据库，是按照数据结构来组织、存储和管理数据的仓库。按照早期的数据库理论，比较流行的数据库模型有三种，分别为层次式数据库、网络式数据库和关系型数据库。在当今的互联网中，最常用的数据库模型主要有两种，即关系型数据库和非关系型数据库。关系型数据库包括Oracle、SQL Server、DB2和MySQL等，非关系型数据库包括MongoDB、Redis、HBase等。

3.开发框架

软件系统发展到今天已经变得越来越复杂，特别是服务器端软件，涉及的知识、内容和问题太多。在某些方面使用已经成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑实现。而且，框架一般是成熟的、稳健的，它可以处理系统中很多的细节问题，如事务处理、安全性和数据流控制等。当前主流的开发语言都有各自的开发框架。

（1）Java语言开发框架有Spring MVC、Spring Boot、MyBatis、Apache Shiro等。

（2）.NET语言开发框架有ASP.NET MVC、Entity Framework、Enterprise Library、NHibernate和Spring.Net等。

（3）PHP语言开发框架有ThinkPHP、Yii、CodeIgniter和Laravel等。

（4）JavaScript语言开发框架有jQuery、Ext、Dojo、Bootstrap和Node.js等。

4.开发语言

在开发过程中，不可避免地要对开发语言进行选择。选择合适的开发语言不仅能够提高开发的效率，而且对于功能实现的效果会产生不同的影响，对于高质量的系统或软件产品的形成具有重要的意义。

常用开发语言见表2-1。

在软件项目开发前，项目组要选择合适的开发语言并确定开发规范，统一好软件开发平台、开发环境和开发框架，以保障每个开发成员的开发成果高度一致。其中，服务器操作系统、数据库、开发框架是必备的要素，其他软件开发工具根据实际情况可以稍有不同。

2.3.4 测试过程

测试是通过人工操作或软件自动运行的方式来检验软件是否满足规定要求，同时明确需求预期结果与实际结果之间的差别的过程，它是为发现软件错误而执行的过程，可以用于过程改进与质量提升。软件测试是伴随着软件的产生而产生的，早期的软件规模很小，复杂程度低，通过人工手动测试就可以满足要求。随着软件规模和范围的扩大，手动测试的成本变得越来越高，同时对于互联网上的高并发等场景，手动测试已无法满足要求。在此背景下衍生出不同的测试方法和多种测试工具。

测试过程既包括具体的测试工作，又涵盖具有测试能力的团队工作内容。

软件测试的工作步骤和测试阶段如图2-5所示。

1.工作步骤

（1）编制测试方案，测试方案是指针对测试制订的详细的执行方案。

（2）制订测试计划，测试计划是针对测试过程的时间计划，通过计划的控制，保证测试的效率。

（3）编写测试用例，目的是将软件测试的行为活动进行组织归纳，将软件测试的行为转化成可管理的模式。设计测试用例时必须先有测试策略，测试用例设计包括数据、场景、断言和环境，对测试用例可以手动执行（可信判断，对不可信进行测试），也可以自动测试（脚本化执行）。常见测试用例的内容包括测试目标描述、输入数据、测试步骤、预期结果等。好的测试用例发现错误的可能性更大，因此，应当彻底检查每个测试用例的执行结果。快速交付要求对测试用例按组织级进行管理，以实现共享，测试用例管理常用工具包括Excel、TestLink、TestDirector等。

（4）形成测试报告，就是将最终测试结果整理成测试报告并反馈给相关开发过程，以改进软件的质量。

2.测试阶段

软件测试可以划分为单元测试、集成测试、系统测试和验收测试四个阶段。

（1）单元测试是对软件中的最小可测试单元进行检查和验证。

（2）集成测试是指将通过测试的单元模块组装成系统或子系统，再进行测试。

（3）系统测试就是将整个软件系统看成一个整体进行功能、性能和运行环境的测试。

（4）验收测试一般以用户测试为主，或者由质量保障人员共同参与测试，它是软件正式交给用户使用前的最后一道工序。

3.测试方法

常用的测试方法有黑盒测试、白盒测试、静态测试、动态测试、回归测试、冒烟测试、随机测试、等价划分测试、判定表测试、负面测试和极限测试等，这些方法的内容将在知识篇中进行详细阐述。任何测试方法的选择和执行都需要测试依据来保障。测试依据包括软件需求规格、软件设计规格和软件代码规格，描述要求全面、完整、无二义性，判断要求通过判断标准。例如，黑盒测试的依据是需求，灰盒测试的依据是设计，白盒测试的依据是代码。

无论是功能测试还是性能测试，都需要相应的测试工具辅助才能够达到事半功倍的效果。自动化测试是把以人驱动的测试行为转化为机器执行的一种过程。通常在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程按步骤执行测试，将得到的实际结果与期望结果进行比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。相比于人工测试，自动化测试具有避免重复劳动、提高测试效率、增强测试能力、使测试结果更加客观等优势。

除了用专门的测试工具来执行测试外，还需要通过缺陷管理工具对测试过程进行管理。测试人员借助缺陷管理工具，对测试中发现的缺陷进行入库、分发、验证、关闭等一系列的跟踪管理。同时，组织和督促开发人员借助代码检查工具，对代码进行测试前的检查，尽可能在开发阶段就将大部分Bug扼杀，提高代码质量。

2.3.5 发布过程

发布过程是指将源代码进行编译、打包，形成可执行程序的版本构建过程，也称发布版本。发布过程是一个需要多角色参与、流程复杂的过程，其中涉及源代码管理、配置管理、版本管理、文档管理等。发布过程是项目过程中的里程碑，将明确产品的具体功能与特性，并直接影响客户的应用与体验，因此，发布过程需要提前做好多方面的准备。

发布过程既包括具体的发布工作，又涵盖具有发布能力的团队工作内容。

1.主要工作

（1）版本管理。软件发布的版本包括Alpha版、Beta版、RC版、Release版等几种类型，分别对应内部、外部、正式发布前、正式发布的版本管理。版本管理需要充分考虑发布的软件版本的应急恢复，以应对突发风险；要保证新版本发布后能够回滚到原来的版本，以保障用户业务的应用稳定性。

（2）源代码管理。源代码是软件的重要核心内容，是软件得以运行的基础。源代码管理有助于团队协作，共同完成开发任务。通过源代码管理工具，如SVN、TFS、CVS等，可以轻松实现团队开发，通过签出、编辑、签入、锁定等权限，完美地解决了多人共同操作同一对象的版本控制问题。

（3）文档管理。文档是项目成果与交付物的集合，项目完成后需要进行文档归档。快速交付要求在发布版本时，对版本的更新特性、版本说明、操作手册、技术文档等进行备份、同步更新、归档等操作。

2.发布流程

发布过程的核心是遵循发布流程，现实中根据公司的规模、项目的大小、人员的配置等情况，发布流程不尽相同。以手动发布的主要节点为例，发布流程的具体步骤如下。

（1）软件开发人员完成内部集成测试和相关的发布、部署文档，然后将版本提交至版本控制工具（以SVN为例）的版本区（Tags）中。

（2）软件质量保证人员从配置管理库的版本区中取出版本，进行本地编译验证，如果通过，则进行测试版本打包并发布测试版本。

（3）软件测试人员对测试版本进行测试，如果测试不通过，则进行迭代，直到测试通过为止。

（4）软件质量保证人员生成正式版本等待部署，并公布新版本的信息。

3.发布方式

发布过程的执行依据具体项目的特征，可以采用手动发布或工具自动发布的方式。发布后需要明确软件发布的版本功能清单和更新内容，并对外公布，清单中需要介绍软件新增功能及特性、应用改善情况、Bug修复、待解决问题、产品功能手册、产品版本说明等信息。通过这些信息的公布，让用户对软件新增的功能进行了解，改善用户体验。

常用的发布方式包括以下几种。

（1）蓝绿发布。在发布的过程中，用户感知不到服务的重启，在通常情况下是通过新旧版本并存的方式实现的，也就是说在发布的过程中，新的版本和旧的版本是互相热备的，通过切换路由权重的方式（非0即100）实现不同应用的上线或下线。

（2）滚动升级发布。一般是取出一个或多个服务器停止服务，执行更新，然后重新将其投入使用，如此周而复始，直到集群中所有的实例都更新成新版本。

（3）灰度发布。灰度发布是增量发布的一种类型，它的执行方式是在原有软件生产版本可用的情况下，同时部署一个新的版本，即同时运行同一个软件产品的多个版本。其实，灰度发布是滚动升级发布的一种变体，灰度发布是先划分出新版本的路由权重，新版本通过真实数据验证后，再进行剩余旧版本的升级。

（4）回滚发布。回滚发布是指将应用或服务回退到上一个可用的发布版本，目前只支持针对蓝绿发布的回滚。

2.3.6 部署过程

软件项目或软件产品的部署作为六大过程的最后一个过程，在软件全生命周期中占据了重要的地位。部署过程是一个操作复杂、需要重复和严格验证的过程，因为每一次需求变更、Bug修复都需要进行重新部署。软件部署需要考虑系统部署环境的安装与配置，在部署过程中需要准备好应用服务器、操作系统、中间件、数据库及相关依赖项的初始化包。

部署过程既包括具体的部署工作，又涵盖具有部署能力的团队工作内容。

1.主要工作

（1）硬件环境准备，即提供物理服务器或云虚拟服务器，安装操作系统，完成网络配置，提供负载均衡F5服务器等。

（2）软件安装，即为项目部署准备必要的软件环境，如安装数据库软件、配置 Java环境变量、安装Web服务器等。

（3）部署软件包，如Java Web项目的部署，需要修改其运行环境的配置文件，然后将软件部署到Web服务器（Apache、WebLogic等）中，最后启动服务。

（4）部署验证，即验证项目是否可用、部署版本是否正确等工作。

在B/S架构模式下，传统的手动部署就是部署人员将软件包上传到Web服务器发布目录中。在C/S架构模式下，除了要发布服务器端应用服务外，还要提供一个文件服务器用来放置客户端软件安装包，以供用户下载。

2.部署策略

除全新部署外，常见的部署策略还有蓝绿部署、滚动升级部署、灰度部署和回滚部署。每种部署策略都有相应的执行计划模板。

1）蓝绿部署

蓝绿部署的前提条件是拥有双份资源或支持双端口模式，通过负载均衡服务和操作API接口来实施，具体步骤如下。

（1）设置系统将要部署的资源列表。

（2）将新版本部署容器部署到资源列表中。

（3）调用负载均衡服务和API接口更新负载均衡配置。

（4）更新资源的标签。

考虑到用户可能会手动介入，以确定是否需要更新负载配置，通常会将第二步、第三步分为两个子执行计划。

2）滚动升级部署

这种部署策略相对于蓝绿部署，更加节约资源，它不需要运行两个集群、两倍的实例数。滚动升级部署通过负载均衡服务和操作API 接口来实施，具体步骤如下。

（1）设置滚动升级系数（步进），如20%/n个。

（2）依次为20%的部署容器移除负载，并在原资源处部署新版本，然后加入负载。

3）灰度部署

灰度部署的执行方式是在原有软件生产版本可用的情况下，同时部署一个新的版本。灰度部署的本质是同时运行一个软件产品的多个版本。灰度部署通过负载均衡服务和操作API 接口来实施，具体步骤如下。

（1）设置新旧版本的路由权重，如90%的用户继续使用旧版本，10%的用户使用新版本。

（2）为10%的部署容器移除负载，并在原资源处部署新版本，然后加入负载。

（3）等待真实数据验证通过后，再进行剩余旧版本的滚动升级。

4）回滚部署

回滚部署是指将应用或服务回退到上一个可用版本，目前只支持针对蓝绿发布的回滚部署。它通过调用负载均衡服务和操作API接口，更新负载配置来实现。

在执行部署过程时，需要充分考虑用户使用系统的稳定性和高可用性。对于安全性及对性能有更高要求的部署过程，还需要考虑系统的高性能。通过集群部署、分布式部署、负载均衡等多种方式，实现高性能的大型软件部署，部署过程中还应充分考虑容灾和容错。