PDCA循环，针对针对工程项目的质量目标提出的模型，称为戴明环（Plan, Do, Check, Action）

软件工程过程是为了获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。 具体活动包括: 软件规格说明、软件开发、软件确认、软件演进、

指软件产品从考虑其概念开始，到该软件产品不再使用为止的整个时期。 一般包括概念阶段、分析与设计阶段、构造阶段、移交和运行阶段等不同时期。 软件生命周期的六个基本步骤：制定计划（P）、需求分析（D）、设计（D）、程序编码（D）、测试（C）、运行维护（A）。 软件生命周期和戴明环的对应关系：

对软件过程的概括描述和抽象，包括各种活动（Activities）、软件工件（artifacts）和参与角色（Actors/Roles）等。

工作流程 需求分析—软件需求—分析—程序设计—编码—测试—运行 每个阶段都需要进行审核和文档输出（文档驱动）

模型作用 为软件开发和维护提供了有效的管理模式。在软件开发早期，在消除非结构化软件、降低软件复杂度、促进软件开发工程化方面起着显著的作用。

每个开发活动的特征： ·本活动依赖于上一项活动的输出作为工作对象，这些输出一般是代表某活动结束的里程碑式文档。 ·根据本阶段的活动规程执行相应的任务。 ·本阶段活动的最终产出——软件工件，将会作为下一活动的输入。 ·对本阶段活动执行情况进行评审。

优点： 降低复杂度、提高透明性和可管理性、强调需求分析和设计、阶段审核和文档输出保证了阶段之间的正确衔接，能够及时发现问题。 缺点： 缺乏灵活性、不适用于需求不明的开发情况、风险控制能力较低、文档驱动增加了系统的工作量、只依赖于文档来评估进度，可能会得出错误结论、成功周期较长

适用场景： 需求明确、较大型系统、开发周期不紧张

工作流程： 在瀑布模型的基础上，一次性开发难以成功，因此，演化模型提倡进行“两次开发”，分别是试验开发和产品开发。每个开发阶段按照瀑布模型进行具体开发活动。

优点： 明确用户需求、提高系统质量、降低开发风险 缺点： 管理难度提高、开发结构化较差、可能抛弃文档驱动、可能导致产品结构化较差

适用场景： 需求不清、开发周期短的中小型系统。

模型概述： 结合瀑布模型和演化模型的优点，在需求不清时，对最核心或最清晰的需求，利用瀑布模型实现。再对后续需求进行重复开发（可能按照需求的优先级逐个进行），从而逐步建成一个完整的软件系统。

优点： 保障核心功能实现、开发风险较低、保障最高优先级的功能的可靠实现、提高系统稳定性和可维护性。 缺点： 增量粒度难以合理选择、确定所有的需求服务较困难

模型概述： 又称迭代模型，每个阶段是相互重叠、多次反复的。每个开发阶段没有次序要求，可以并发进行，在某个阶段随时补充其他阶段中遗漏的需求。

优点： 提高效率、缩短周期 缺点： 管理结构性较差

模型概述： 是瀑布模型的变种。它将测试模块细化分解，把测试看作与开发同等重要的过程，每一测试阶段的前提和要求是对应开发阶段的文档。

测试模块： ·单元测试：根据详细设计说明书，检测每个单元模块是否符合预期要求。主要检查编码过程中可能存在的错误。 ·集成测试：根据概要设计说明书，检测模块是否正确聚集。主要检查模块与接口之间可能存在的错误。 ·系统测试：根据需求分析，检测系统作为一个整体在预定环境中能否正常的有效工作。 ·验收测试： 是否满足客户的需求。

优点： 改进开发效率和开发效果 缺点： 前期出现错误的话，后期难以挽救和弥补或者花费的代价巨大。

模型概述： 由两个V模型构成，分别代表测试与开发过程。每个开发过程对应一个测试，体现了开发和测试的并行关系，测试的不局限于程序，对于阶段文档也需要进行测试。

优点： 增加了软件各开发阶段中应同步进行的验证和确认活动。 缺点： 开发，测试活动保持着一种前后关系，无法支持迭代软件开发模型。

模型概述： 将开发过程分为四个类型：风险分析、制定计划、实施工程、客户评估。每次评估之后确定是否进行螺旋线的下一个回路。

适用对象： 风险较高、开发周期较长的大型软件项目

优点和缺点：

降低风险，但是开发周期长。

模型概述： 将整个系统模块化，在一定构件模型的支持下，复用构件库中软件构件，通过组装构件构造软件系统。开发过程就是构件组装的过程，是迭代的过程，维护过程就是构件升级、替换和扩充的过程。

优点： 软件复用充分，提高效率，允许多项目同时开发，降低开发费用，提高可维护性，可实现分步提交软件产品。 缺点： 构件组装结构没有通用标准，组装过程存在风险、构件可重用性和系统高效性不易协调；构件质量直接影响产品质量。

模型概述： 增量型开发模型，通过大量使用可复用 构件，采用基于构件的建造方法赢得了快速开发。 其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。RAD目的是快速发布系统方案，而技术上的优美相对发布的速度来说是次要的。

优点： 开发周期短 缺点： 需求分析的阶段时间较短、适用性一般

适用范围 适合于管理信息系统开发，不适合于技术风险较高、与外围系统的互操作性较高的系统开发

在传统的软件生命开发周期中，原型方法是经常被使用的一种开发方法。

瀑布模型以及基于瀑布模型的软件生命周期模型，都需要精确的需求才能很好地执行后续的开发活动，但是准确的需求分析很难获取。 原型方法指在获得基本需求后，快速分析，实现一个小型的软件系统原型，满足用户的基本要求。用户可以提出修改意见，校正需求。 原型方法主要用于明确需求，但也可以用于软件开发的其他阶段。

1、废弃策略

2、追加策略

优点： 有助于快速理解用户需求、容易确定系统性能和设计可行性、有利于建成最终系统。 缺点： 文档容易被忽略、建立原型增加工作量、项目难以有效规划和管理。

模型概述： 它是一类面向对象的程序开发方法论，既是一个生命周期模型，也是一个支持面向对象软件开发的工具。 软件生命周期在时间上被分解为四个顺序的阶段：初始阶段、细化阶段、构造阶段、交付阶段。每个阶段在阶段结尾执行一次评估，确定阶段目标是否满足、是否可以进入下一个阶段。以用例为驱动，软件体系结构为核心，应用迭代及增量的新型软件生命周期模型。

各阶段工作说明 初始阶段：了解业务，确定项目边界。包括验收规范、风险评估、资源估计、阶段计划制定等 细化阶段：分析问题领域，建立软件体系结构基础，编制项目计划，完成技术要求高、风险大的关键需求开发。 构造阶段：将所有剩余的技术构件和业务需求功能开发出来，集合成产品，所有功能被详细测试。 移交阶段：重点是确保软件可被最终用户使用。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。

每个迭代的主要活动： 核心过程工作流（6个）：业务建模、需求、分析和设计、实现、测试、部署 核心支持工作流（3个）：配置和变更管理、项目管理、环境

模型特点： ·适应性开发：小步骤、快速反馈和调整； ·使用用例驱动软件建模：用例是获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量。 ·可视化软件建模：使用UML进行软件建模。

模型概述： 一种以实践为基础的软件工程过程和思想。使用快速反馈测试（测试驱动）、大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。主要强调用户满意，开发人员可以对需求的变化作出快速的反应。 每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。

特点：