【软件工程】02_软件生命周期模型

2.1 软件工程过程：PDCA 循环

软件工程中的 PDCA 循环包含四个关键阶段：

• P (Plan) - 软件规格说明（Specification）：规定软件的功能及其使用的限制。
• D (Do) - 软件开发：产生满足规格说明的软件。
• C (Check) - 软件确认：通过有效性验证以保证软件能够满足客户的要求。
• A (Action) - 软件演进：为满足客户的变更要求，软件必须在使用的过程中不断地改进。

实际上，软件工程过程是软件开发机构针对某类软件产品规定的工作步骤，科学合理的过程对软件产品质量至关重要。

2.2 软件生命周期（software life cycle）

软件生命周期指软件产品从概念提出到不再使用的整个时期，一般包括概念阶段、分析与设计阶段、构造阶段、移交阶段等。在整个软件生命周期中，贯穿了软件工程过程的六个基本活动：

1. 制定计划（P）
   • 确定要开发软件系统的总目标，明确其功能、性能、可靠性以及接口等方面的要求。
   • 研究完成该项软件任务的可行性，探讨解决问题的可能方案。
   • 制定完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查。
2. 需求分析（D）：对待开发软件提出的需求进行分析并给出详细定义，编写出软件需求说明书及初步的用户手册，提交管理机构评审。
3. 设计（D）：软件工程的技术核心，将已确定的各项需求转换成相应的体系结构，并对每个模块要完成的工作进行具体描述，编写设计说明书，提交评审。
4. 程序编码（D）：把软件设计转换成计算机可以接受的程序代码。
5. 测试（C）：在设计测试用例的基础上检验软件的各个组成部分。
6. 运行维护（A）：已交付的软件投入正式使用，并在运行过程中进行适当的维护。

2.3 过程模型（软件生命周期模型）

软件过程模型也称软件生命周期模型，描述了从软件需求定义直至软件废弃，跨越整个生存期的软件开发、运行和维护的全部过程、活动和任务的结构框架，同时明确了生命周期不同阶段产生的软件工件以及活动的执行角色。

九个传统软件生命周期模型

瀑布模型

• 优点
  • 软件生命周期的阶段划分降低了软件开发的复杂程度，提高了开发过程的透明性，便于融合软件工程过程和软件管理过程，增强了开发过程的可管理性。
  • 推迟了软件实现，强调在实现前必须进行分析和设计工作。
  • 以项目的阶段评审和文档控制为手段，有效指导整个开发过程，保证阶段之间的正确衔接，能及时发现并纠正开发过程中的缺陷，确保产品达到预期质量要求。
• 缺点
  • 模型缺乏灵活性，无法解决软件需求不明确或不准确的问题，只适用于需求明确的软件项目。
  • 风险控制能力较弱，成品时间长，体系结构的风险和错误在测试阶段才能发现，返工易导致项目延期。
  • 软件活动是文档驱动的，过多文档会增加工作量，文档完成情况可能误导管理人员。

V 模型和 W 模型

• V 模型：作为瀑布模型的变种，仍将测试作为独立阶段，未提高模型抵抗风险的能力。
• W 模型：由两个 V 型模型组成，分别代表测试与开发过程，两个过程同步进行。
• 

原型方法（prototyping）

1. 提出原因：完整准确的需求规格说明难以获取，加强评审、确认和全面测试也无法根本解决需求不稳定的问题。
2. 概述：软件原型是早期可运行的版本，反映最终系统的部分重要特性。构造软件系统的过程为：获得基本需求说明，快速构造小型软件系统；用户试用并评价；开发者根据意见改进，反复迭代直至满足用户要求。该方法可用于软件开发的多个阶段。
3. 原型的种类（目的）
   • 探索型：弄清对目标系统的要求。
   • 实验型：在系统实现前考察系统的可行性。
   • 进化型：将原型扩展到开发过程，逐步实现所有系统功能。
4. 原型的使用策略
   • 废弃策略：适用于探索型和实验型原型。
   • 追加策略：适用于进化型原型。原型需快速实现和运行，可忽略暂时不必关心的部分。
5. 优点
   • 增进软件人员和用户对系统服务需求的理解。
   • 提供有力的学习手段。
   • 容易确定系统的性能、服务的可应用性、设计的可行性和产品的结果。
   • 原型的最终版本可作为最终产品或系统的一部分。
6. 缺点
   • 文档容易被忽略。
   • 建立原型的许多工作可能被浪费。
   • 项目难以规划和管理。
7. 应用过程：可支持软件生命周期的不同阶段，如辅助或代替分析阶段、辅助设计阶段、代替分析与设计阶段、代替分析、设计和实现阶段，甚至代替全部开发阶段（典型的演化模型）。

演化模型

主要针对需求不明确的软件项目。由于项目开发初始阶段对需求认识不清，再开发难以避免。但该模型也存在缺点：

• 可能抛弃瀑布模型的文档控制优点，开发过程不透明。
• 探索式演化模型可能导致最终软件系统的结构较差。
• 可能使用不符合主流、要求或不成熟的工具和技术。

增量模型

结合了瀑布模型和演化模型的优点，允许客户逐步提出需求，“增量” 需求的划分与实现集成以不影响系统体系结构为前提。

• 优点
  • 增强客户使用系统的信心，便于客户逐步提出后续增量需求。
  • 项目总体失败的风险较低。
  • 增量优先级的确定保障了系统重要功能部分的可靠性。
  • 同一体系结构提高了系统的稳定性和可维护性。
• 缺点
  • 增量的粒度选择存在问题。
  • 确定所有的基本业务服务比较困难。

螺旋模型

针对大型软件项目提出，将瀑布模型与演化模型结合，并加入风险分析。沿着螺线旋转，在四个象限分别进行以下活动：

• 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。
• 风险分析：分析所选方案，考虑如何识别和消除风险。
• 实施工程：实施软件开发。
• 客户评估：评价开发工作，提出修正建议。

该模型适合大型软件开发，但风险分析需要丰富的评估经验，风险规避需要深厚的专业知识，应用难度较大。

喷泉模型（迭代模型）

认为软件开发过程具有迭代和无间隙两个本质特征，适用于面向对象的软件开发过程。对象概念的引入及表达方式的统一，使开发活动的迭代和无间隙性易于实现。

构件组装模型

本质上是演化的，开发过程是迭代的，由五个阶段组成：需求定义和分析、软件体系结构设计、构件开发、应用软件构造、测试和发布。开发步骤如下：

1. 定义和分析需求。
2. 标识项目所需构件。
3. 从库中查找构件或相似构件。
4. 若可用则进入下一步，否则自行开发或修改，确认后入库。
5. 为新系统进行第 m 次迭代构造。
6. 测试、确认。

快速应用开发（RAD）模型

是增量型的软件开发过程模型，采用构件组装方法进行快速开发，包含以下阶段：

1. 业务建模：通过捕获业务过程中信息流的流动及处理情况，描述业务处理系统的功能，可辅之以数据流图。
2. 数据建模：为支持业务过程的数据流建立数据对象集合，定义属性和关系，构成数据模型，可辅之以 E - R 图。
3. 过程建模：定义数据对象在信息流中完成业务功能的方式，描述数据对象的增加、修改、删除、查找，细化数据流图中的处理框。
4. 应用生成：利用第四代语言（4GL）编写处理程序，重用已有构件或创建新的可重用构件，利用环境工具自动生成应用系统。
5. 测试及迭代：因大量重用，一般只作总体测试，新创建的构件需单独测试。一轮需求开发完成后，可迭代进入下一轮需求开发。

2.4 新型软件生命周期模型

统一软件开发过程

RUP（Rational Unified Process）是面向对象的基于 web 的程序开发方法论，既是软件生命周期模型，也是支持面向对象软件开发的工具，将软件开发过程要素和软件工件要素整合在统一框架中。

RUP 的基本结构

RUP 是二维的软件开发模型：

• 横轴：在时间上将生命周期过程展开成四个阶段（Phase），每个阶段有特有的里程碑（Milestone）标志结束，阶段内又划分不同的迭代（Iteration），体现软件开发过程的动态结构。
  • 初始阶段
    • 阶段目标：通过业务用例了解业务，确定项目边界，包括验收规范、风险评估、资源估计、阶段计划等。需识别所有与系统交互的外部实体，如外部角色和用例，并详细描述重要用例。
    • 里程碑：软件目标里程碑，包括项目愿景、原始用例模型、原始业务风险评估、原型、原始业务场景等文档，需进行评审确保理解用例需求、评估风险和计划可行。
  • 细化阶段
    • 阶段目标：分析问题领域，建立适合需求的软件体系结构基础，编制项目计划，完成关键需求的开发。
    • 里程碑：体系结构里程碑，包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等，通过评审确保体系结构稳定、解决高风险需求和技术机制、修订计划可行。
  • 构造阶段
    • 阶段目标：开发并集成所有剩余技术构件和稳定业务需求功能，详细测试所有功能，重点是管理资源和控制开发过程以优化成本、进度和质量。
    • 里程碑：运行能力里程碑，包括可运行的软件产品、用户手册等，决定产品是否可在测试环境部署，需确定软件、环境和用户是否可开始系统运行。
  • 移交阶段
    • 阶段目标：软件产品正常运行并交付用户使用，交付阶段可跨越多次迭代，包括产品测试和基于用户反馈的少量调整。
    • 里程碑：产品发布里程碑，包括维护和售后支持文档手册等，需确定最终目标是否实现，是否开始下一个版本的开发周期。
• 纵轴：按活动内容组织，包括活动（activity）、活动产出的工件（artifact）、活动的执行角色（worker）以及活动执行的工作流（workflow），体现软件开发过程的静态结构。

RUP 的迭代增量开发思想

RUP 以用例为驱动，软件体系结构为核心，应用迭代及增量思想。每个阶段可进一步划分为一个或多个迭代过程，从一个迭代到另一个迭代增量形成最终系统，融合了喷泉模型和增量模型。它将项目开发目标划分为阶段性小目标，每次迭代包含需求、设计、实施（编码）、部署、测试等活动。

RUP 的核心工作流

• 6 个核心过程工作流（Core Process Workflows）：商业建模、需求、分析和设计、实现、测试、部署。
• 3 个核心支持工作流（Core Supporting Workflows）：配置和变更管理、项目管理、环境。

RUP 的最佳实践（Best Practice）

• 短时间分区式的迭代。
• 适应性开发。
• 在早期迭代中解决高技术风险和高业务价值的问题。
• 不断让用户参与迭代结果的评估。
• 在早期迭代中建立内聚的核心架构。
• 不断验证质量，尽早、经常和实际地测试。
• 使用用例驱动软件建模。
• 可视化软件建模，使用 UML 进行软件建模。
• 仔细管理需求。
• 实行变更请求和配置管理。

敏捷开发

定义

敏捷方法的主要特点是具有快速及灵活的响应变更能力，是以人为核心、迭代、循序渐进的开发方法。软件项目被切分成多个子项目，各子项目成果经过测试，具备集成和可运行特征，软件一直处于可使用状态。敏捷方法包括极限编程（XP）、Scrum、功能驱动开发（FDD）、水晶、净室开发等，都遵循 “敏捷宣言” 原则。

极限编程（eXtreme Programming）

XP 是轻量级的软件开发方法，基于实践的软件工程过程和思想，使用快速反馈、大量交流和保证测试来满足用户需求，强调用户满意，开发人员能快速响应需求变化。

• 工作环境：项目开发人员担任不同角色并履行相应权利和义务，用户也是项目组一部分，所有人在开放的开发环境中工作。
• 需求分析
  • 开发人员和客户将需求转化为小的需求模块（User Story），记录在小卡片（Story Card）上。
  • 客户根据商业价值指定模块优先级，开发人员确定开发风险。
  • 经过评估后，模块被安排在不同开发周期，客户得到开发计划并为每个模块指定验收测试（功能测试）。
• 设计：内层过程基于 Test Driven Development 周期，每个开发周期有大量单元测试。随着测试进行，通过的单元测试增多，便于客户和开发人员检验承诺履行情况。同时，提倡设计复核、代码复核以及重整和优化，优化设计过程。
• 编程：提倡配对编程，代码所有权归整个开发队伍。程序员遵守编程规范，任何人可修改他人程序，修改后确保通过单元测试。
• 测试：提倡在写程序前先写单元测试。开发人员经常整合开发好的模块（持续集成），每次整合后运行单元测试；进行代码复核和修改时，也运行单元测试；发现 BUG 则增加相应测试。除单元测试外，还有整合测试、功能测试、负荷测试和系统测试等，这些测试是开发过程的重要文档，也是交付用户的内容之一。