1.2 软件研发模型
软件研发模型（Software Development Model）是指软件开发全部过程、活动和任务的结构框架。合理使用研发模型可以提供软件研发效率，降低研发成本，提升软件质量。
常见的研发模型包括需求、设计、编码和测试等阶段，有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。
目前比较流行的研发模型主要有：瀑布模型、快速原型模型、螺旋模型、RUP流程和敏捷模型。
1.2.1 瀑布模型
1970年，温斯顿·罗伊斯（Winston Royce）提出了著名的瀑布模型。如图1-2所示。在早期，该模型应用的最为广泛，也是最容易理解和掌握的研发模型。
图1-2 瀑布模型
瀑布模型最早是根据工业流水线演变过来的，它的核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划的六个基本活动，由上而下、相互衔接起来，如同瀑布流水，逐级下落。
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改，直到项目成功。
瀑布模型是属于线性过程，过于强调文档的作用，并要求每个阶段都要仔细验证，适合一些规模小，需求明确的项目研发。随着软件的发展，现软件的功能也越来越多，逻辑也变得越来越复杂，所以瀑布模型已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。
3）测试活动置后，导致早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果；导致测试人员的闲置，测试力度不够，不利于项目的研发。
4）瀑布模型最大问题是不能够适应用户需求的变化。
1.2.2 快速原型模型
快速原型模型（Rapid Prototype Model）又称为原型模型。如图1-3所示。快速原型模型是在瀑布模型基础上演进的一种研发模型。原型模型弥补了瀑布模式不足的地方，相对瀑布模型而言，原型模型更关注用户需求的正确性，也符合人们开发软件的习惯。
快速原型模型需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。该模型的主要思想就是通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求。同时，原型模型采用逐步求精的方法来完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈做出快速的响应。
在工作中，很多公司把原型模型称为DEMO，即演示版，便于需求调研以及软件初期的设计。相对测试工程师而言，在实施测试活动中也可以参考DEMO进行测试设计。
图1-3 原型模型
1.2.3 螺旋模型
1988年，巴利·玻姆（Barry Boehm）正式发表了软件系统开发的螺旋模型。如图1-4所示。它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
图1-4 螺旋模型
螺旋模型（Spiral Model）采用一种周期性的方法来进行系统开发。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括制定计划、风险分析、实施工程和客户评估4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又上升了一个层次。螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。
2）风险分析：分析评估所选方案，由风险专家识别和消除风险。
3）实施工程：实施软件开发和验证。
4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。降低软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。
由于该模式成本过高，目前商业模式下几乎不采用该模型，但是该模式相关安全系数极高，目前用在军方应用比较多。
1.2.4 RUP流程
RUP（Rational Unified Process），是由Rational公司（Rational公司已被IBM并购）推出的一种统一软件开发过程，以用例驱动和体系结构为核心的增量迭代的软件过程模式。如图1-5所示。目前也是比较流行的研发模型。
图1-5 RUP流程
RUP有2个轴，横轴表示时间，是过程的生命周期，体现了开发过程的动态结构，主要用来描述软件的周期、阶段、迭代和里程碑；纵轴表示工作流，体现开发过程的静态结构，主要用来描述软件活动的工作流。
1．RUP的阶段划分
RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始化、细化、构造和发布。每个阶段结束于一个主要的里程碑（Milestones），每个阶段本质上是两个里程碑之间的时间跨度。下面简单介绍RUP的四个阶段：
1）初始化阶段：本阶段具有非常重要的意义，必须识别所有与系统交互的特性。在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。
2）细化阶段：分析问题领域，建立比较完善的体系结构基础，编制项目计划，规避项目中风险较大的元素。同时为项目建立支持环境，包括模板、准则等，并准备工具。
3）构造阶段：由开发人员对所有的构件和应用程序进行集成，并对所有的功能进行详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。
4）发布阶段：发布阶段的重点是确保软件对最终用户是可用的。发布阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。
2．RUP的核心工作流
RUP的9个核心工作流，它们分为6个核心过程工作流和3个核心支持工作流。下面简单介绍RUP的每个工作流：
1）业务建模（Business Modeling）：主要描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。
2）需求（Requirement）：主要的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织和文档化；最重要的是理解系统所解决问题的定义和范围。
3）分析和设计（Analysis&Design）：将需求转化成系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，并优化其性能。其结果是一个设计模型和一个可迭代的分析模型。设计模型是源代码的抽象，它由设计类和一些描述组成。设计类被组织成具有良好接口的设计包和设计子系统，而描述主要体现了类的对象如何协同工作实现用例的过程。
4）实现（Implementation）：将层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
5）测试（Test）：通过三维模型（可靠性、功能性和系统性能）进行测试。主要检测所有的需求是否已被正确，所有的组件是否被正确集成。RUP提出了迭代的方法，意味着在整个项目中进行测试，应尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。
6）部署（Deployment）：部署主要描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行Beta测试版、移植现有的软件和数据以及正式验收。
7）配置和变更管理（Configuration&Change Management）：其描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，并跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发以及自动化创建工程。同时也阐述了对产品修改原因、时间和人员审计记录。
8）项目管理（Project Management）：平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
9）环境管理（Environment Management）：该工作流向软件开发组织提供软件开发环境，包括过程和工具，并集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步介绍的指导手册并介绍了如何在组织中实现过程管理。
1.2.5 敏捷模型
2001年是全球的软件行业最具有历史意义的一年。在这一年年初，“敏捷联盟”成立了，它是由美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者的聚会而成立的。
敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。简单来说，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发宣言就是尽早的、持续的交付有价值的软件来使客户满意，如图1-6所示。
图1-6 敏捷开发宣言
敏捷模型（Agile Model）的原则有以下几点：
1．快速迭代
传统项目一般大约半年发布一次版本。而在敏捷中采用小版本，其需求、开发和测试更加简单快速。
2．让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。
3．编写可测试的需求文档
开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。
4．多沟通，尽量减少文档
任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。越有经验，越会强调良好高效的沟通的重要性。
团队要确保日常的交流，面对面沟通比邮件效果强得多。
5．做好产品原型
建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。
6．及早考虑测试
及早地考虑测试在敏捷开发中很重要。传统的软件开发，如果测试用例很晚才开始写，这将导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。