信息系统项目管理师自学笔记（六）——软件开发模型

2.2 软件开发模型

对于开发模型知识点，要掌握软件生命周期的概念、各种开发模型的特点和应用场合。主要的开发模型有瀑布模型、增量模型、螺旋模型、喷泉模型、智能模型、V模型、快速应用开发模型、构件组装模型、敏捷方法和统一过程等。

2.2.1瀑布模型

瀑布模型也称生命周期法，是结构化方法中最常用的开发模型，它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段。

1. 软件计划（问题的定义及规划）：主要确定软件的开发目标及其可行性。
2. 需求分析：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。
3. ）软件设计：主要是指根据需求分析的结果，对整个软件系统进行设计，如系统框架设计和数据库设计等。软件设计一般分为总体设计（概要设计）和详细设计。
4. 程序编码：将软件设计的结果转换成计算机可运行的程序代码。在程序编写中必须要制定统一的、符合标准的编写规范，以保证程序的可读性和易维护性，提高程序的运行效率。
5. 软件测试：在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
6. 软件维护：软件维护是软件生命周期中持续时间最长的阶段。

瀑布模型的本质是“一次通过”，即每个活动只做一次，最后得到软件产品，也称做“线性顺序模型”或者“传统生命周期”，其过程是从上一项活动接收该项活动的工作对象并作为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，然后作为输出传给下一项活动。同时对该项活动实施的工作进行评审，若其工作得到确认，则继续下一项活动，否则返回前项，甚至更前项的活动进行返工。

瀑布模型有利于大型软件开发过程中人员的组织与管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。
然而软件开发的实践表明，上述各项活动之间并非完全是自上而下、呈线性图式的，因此，瀑布模型存在严重的缺陷。

1. 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样，软件与用户见面的时间间隔较长，也增加了一定的风险。
2. 在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能会导致整个软件项目开发失败。
3. 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。

2.2.2 其他经典模型

• 演化模型：也称为变换模型，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。
• 螺旋模型：将瀑布模型和变换模型相结合，综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制订计划、风险分析、实施工程及客户评价等活动，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的系统。
• 喷泉模型：为软件复用和生存周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。“喷泉”一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中，分析、设计和编码之间不存在明显的边界。
• 智能模型：是基于知识的软件开发模型，它综合了上述若干模型，并与专家系统结合在一起。该模型应用基于规则的系统，采用归约和推理机制，帮助软件人员完成开发工作，并使维护在系统规格说明一级进行。
• 增量模型：融合了瀑布模型的基本成分（重复的应用）和原型实现的迭代特征。增量模型采用随着时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的增量。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。增量模型像原型实现模型和其他演化方法一样，本质上是迭代的。与原型实现不同的是，增量模型强调每一个增量均发布一个可操作产品。增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源，如果核心产品很受欢迎，则可以增加人力实现下一个增量；当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到“镇静剂”的作用。此外，增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且不能很好地处理，就必须做全盘的系统分析。增量模型采用的将功能细化、分别开发的方法适用于需求经常改变的软件开发过程。
• 迭代模型：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。在迭代模型中，每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代模型适用于项目事先不能完整定义产品所有需求、计划多期开发的软件开发。在现代的开发方法中，例如XP、RUP等，无一例外地都推荐、主张采用能显著减少风险的迭代模型。
• 构件组装模型：基于构件的软件开发（Component Based Software Development, CBSD）模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。CBSD模型融合了螺旋模模型的许多特征，本质上是演化型的，开发过程是迭代的。CBSD模型由软件的需求分析和定义、架构设计、构件库的建立、应用软件构建、测试和发布5个阶段组成。CBSD方法使得软件开发不再一切从头开发，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程，其优点是提高了软件开发的效率；构件可由一方定义其规格说明，被另一方实现，然后供给第三方使用，CBSD模型允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。该方法的缺点是：由于采用自定义的组装结构标准，缺乏通用的组装结构标准，引入具有较大的风险；可重用性和软件高效性不易协调，需要有经验的分析人员和开发人员，一般的开发人员插不上手，客户的满意度低；过分依赖于构件，构件库的质量影响着产品质量。

2.2.3 V模型

V模型宣称测试并不是一个事后弥补行为，而是一个同开发过程同样重要的过程V模型是以测试为中心的开发模型。

V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

1. 单元测试的主要目的是针对编码过程中可能存在的各种错误。
2. 集成测试的主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其他程序部分之间的接口中可能存在的错误。
3. 系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行。
4. 验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。

2.2.5 快速应用开发

• 快速应用开发（Rapid Application Development, RAD）模型是一个增量型的软件开发过程模型，强调极短的开发周期。
• RAD模型是瀑布模型的一个高速变种，通过大量使用可复用构件，采用基于构件的建造方法赢得快速开发。

RAD模型各个活动期所要完成的任务如下。

1. 业务建模：以什么信息驱动业务过程运作？要生成什么信息？谁生成它？信息流的去向是哪里？由谁处理？可以辅之以数据流图回答以上问题。
2. 数据建模：为支持业务过程的数据流找到数据对象集合，定义数据对象属性，并与其他数据对象的关系构成数据模型，可辅之以E-R图（实体—联系图）。
3. 过程建模：使数据对象在信息流中完成各业务功能。创建过程以描述数据对象的增加、修改、删除和查找，即细化数据流图中的处理框。
4. 应用程序生成：利用第四代语言（4GL）写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成并构造出整个应用系统。
5. 测试与交付：由于大量重用，一般只做总体测试，但新创建的构件还是要测试的。

RAD模型通过大量使用可复用构件加快了开发速度，对信息系统的开发特别有效。但是像所有其他软件过程模型一样，RAD方法也有以下一些缺陷：

1. 并非所有应用都适合RAD。RAD模型对模块化要求比较高，如果有哪一项功能不能被模块化，那么建造RAD所需要的构件就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能赢得，RAD方法也有可能不能奏效。
2. 开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。
3. RAD只能用于信息系统开发，不适合技术风险很高的情况。当一个新应用要采用很多新技术或当新软件要求与已有的计算机程序有较高的互操作性时，这种情况就会发生。

2.2.5 敏捷开发

敏捷开发的发展过程中，出现了多个不同的流派，例如，极限编程（Extreme Programming, XP）、自适应软件开发、水晶方法、特性驱动开发等。但其中的基本原则是一致的。从开发者的角度，主要的关注点有短平快会议（Stand Up）、小版本发布（Frequent Release）、较少的文档（Minimal Documentation）、合作为重（Collaborative Focus）、客户直接参与（Customer Engagement）、自动化测试（Automated Testing）、适应性计划调整（Adaptive Planning）和结对编程（Pair Programming）；从管理者的角度，主要的关注点有测试驱动开发（Test-Driven Development）、持续集成（Continuous Integration）和重构（Refactoring）。
XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学且充满乐趣的软件开发方式，适用于小型或中型软件开发团队，并且客户的需求模糊或需求多变。与其他方法相比，其最大的不同如下：

• 在更短的周期内，更早地提供具体、持续的反馈信息。
• 迭代地进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断地发展它。
• 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
• 依赖于口头交流、测试和源程序进行沟通。
• 倡导持续的演化式的设计。
• 依赖于开发团队内部的紧密协作。
• 尽可能达到程序员短期利益和项目长期利益的平衡。
  ————————————————————————
• XP由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联，并通过行为贯穿于整个生命周期。
• XP的核心是其总结的四大价值观，即沟通、简单、反馈和勇气。它们是XP的基础，也是XP的灵魂。
• XP的5个原则是快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
• 在XP方法中，贯彻的是“小步快走”的开发原则，因此工作质量决不可打折扣，通常采用测试先行的编码方式来提供支持。
• 在XP中，集成了12个最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户和编码标准。

2.2.6 统一过程

• 统一过程（Unified Process, UP）是一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。
• UP是基于构件的，在为软件系统建模时，UP使用的是UML。与其他软件过程相比，UP具有三个显著的特点，即用例驱动、以基本架构为中心、迭代和增量。
• UP中的软件过程在时间上被分解为4个顺序的阶段，分别是初始阶段、细化阶段、构建阶段和交付阶段。
• 基于UP的软件过程是一个迭代过程。初始、细化、构建和交付四个阶段就是一个开发周期，每次经过这四个阶段就会产生一代软件。
  ——————————————————————
• 初始阶段的任务是为系统建立业务模型并确定项目的边界。
• 细化阶段的任务是分析问题领域，建立健全的架构基础，淘汰项目中最高风险的元素。
• 在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。
• 当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。
• UP的工作流程分为两部分，即核心工作流程与核心支持工作流程。核心工作流程（在项目中的流程）包括业务需求建模、分析设计、实施、测试和部署；核心支持工作流程（在组织中的流程）包括环境、项目管理、配置与变更管理。