4. 软件开发过程¶
4.1. 软件开发过程¶
一个 软件开发过程 仅仅是将一个软件项目划分为不同的工作阶段或阶段。每个阶段都有特定的活动，这些活动用于帮助计划和管理工作进度。一个软件开发过程是为了提高质量、成本或进度绩效，或所有这些方面而实施的。虽然软件实践者有多少种软件开发过程，但只有少数获得了知名度。这些更常见的过程是本节讨论的内容。
所有软件开发过程本质上都是弗朗西斯·培根于 1620 年首次描述的 Plan-Do-Check-Act 循环的变体 [Bacon]。是的，没错。存在许多软件开发过程，它们以不同详细程度描述了 Plan-Do-Check-Act 循环。如今，这些过程大多被归类为两大类之一： 敏捷 或 计划驱动 。
1960 年代出现了计划驱动的过程。随着软件项目规模的增长，出现了几种令人担忧的趋势：
软件项目经常超出预算，或者未能交付任何成果
主要缺陷和故障变得更加普遍
软件维护成本开始增加
当时，没有专业的程序员阶层。工程师、数学家和物理学家编写程序以支持他们的工作。最早的软件开发过程是从制造和工程过程中借鉴而来的。其中最早的是系统开发生命周期（SDLC）。SDLC 的目标是“以非常审慎、有结构和有条理的方式追求信息系统开发，要求从想法的诞生到最终系统的交付，生命周期的每个阶段都必须严格且顺序地执行” [1]。计划驱动的方法仍然是今天大多数软件开发的“传统”方式。
敏捷方法产生于对 1990 年代常用的计划驱动流程僵化性的挫败感，当时技术热潮正在升温。技术变化速度超过了项目跟进的速度，许多项目失败是因为当它们准备好交付时，竞争环境已经发生了足够的变化，使得产品即使没有过时，至少也不再具有具有吸引力的商业成功。
敏捷方法的从业者往往是一个多样化且充满分歧的群体，但他们作为一个整体，起草了一份被几乎所有敏捷过程模型所采纳的单一声明。它被称为 敏捷宣言 [2]。此处即为其全文：
我们通过实践并帮助他人实践，正在揭示出更好的软件开发方式 软件。| 通过这项工作，我们珍视：| | 个人与互动 胜过过程与工具 | 工作软件 胜过详尽文档 | 客户协作 胜过合同谈判 | 响应变化 胜过遵循计划 | | 也就是说，虽然右侧的项目有价值，但我们更珍视 左侧的项目 更多 。
今天可用的许多文档暗示，选择一种过程是一个 非此即彼 的问题。一个项目必须要么是计划驱动，要么是敏捷的。现实情况稍微复杂一些，支持不同过程模型的人之间可能会出现激烈的分歧。总结这两组人之间差异的一种方法是考察他们传播的谣言。
针对计划驱动过程的常见误解包括：
- 无法应对变化
过于庞大且复杂
产品成本更高
仅适用于大型组织
过时
普遍适用 - 软件开发具有不确定性，而 X 流程提高了可预测性，因此所有软件开发者都应使用 X 流程
针对敏捷过程的常见误解包括：
敏捷等同于黑客
- 它是一把“银弹”
易于实现，效果显著
- 随心所欲
无成本或进度承诺
- 与传统流程不兼容
无文档、架构或规划
不适用于固定总价项目
- 普遍适用
信息技术变革的步伐正在加速，敏捷方法比纪律严明的方法更能适应变化，因此敏捷方法将取代信息技术世界。
事实是，存在许多敏捷和计划驱动的方法。所有方法或多或少都是计划驱动的，有些比其他的方法具有更多的“敏捷”特性。因此，更准确的描述是将过程视为存在于一个连续体上，该连续体的一个轴代表拥抱变化（敏捷性）的相对意愿，而另一个轴代表全面的前期规划以及遵守该计划的重要性。不存在任何过程位于两个极端之一。
Scrum 不是一个完整的软件开发过程描述，因为它只涵盖项目管理。
CMMI 是一个过程改进模型，而不是软件开发方法论，但常被视作一种。
每个组都有一个优势区间，如下表所示，在该区间内它优于其他组。
特性 |
敏捷 |
基于计划 |
|---|---|---|
主要目标 |
快速交付价值，响应变化 |
可预测性、稳定性与高保障 |
规模 |
小型团队与项目 |
大型团队与项目 |
环境 |
动荡的、以项目为中心的环境 |
稳定的、以组织为中心的环境 |
需求 |
用户故事。预期快速变化。 |
正式的项目、能力、接口、质量等规格说明。预期渐进变化。 |
开发 |
简单设计、短增量。重构被认为成本低。 |
详细的架构与设计。重构被认为成本高。 |
测试 |
可执行测试验证需求 |
有文档的测试计划验证需求 |
在敏捷性与纪律性之间权衡利弊是软件开发项目必须自行做出的决定。
Figure 4.4.2: 改编自《平衡敏捷性与纪律：困惑者的指南》[Boehm03]_¶
4.1.1. 瀑布模型¶
最初描述于 1970 年，瀑布过程是另一个从制造和建筑过程中借鉴的早期软件开发过程。瀑布模型是一个序列设计过程，其中进展被视为像瀑布一样稳定地向下流动，通过几个不同的阶段。
虽然存在许多变体，但大多数实际使用中的瀑布模型过程都至少包含以下阶段：
需求：系统和软件需求，记录在产品需求文档中。
分析：产生模型、模式和业务规则。
设计：产生软件架构。
实现：软件的开发和集成。
验证：缺陷的系统发现与调试。
维护：完整系统的安装、迁移、支持和维护。
瀑布模型易于理解，并在 1980 年代被广泛使用，但因缺乏灵活性而受到批评。尽管美国国防部于 1985 年正式认可了该模型，但十年后国防部用其他过程指导取代了它。
4.1.2. 有理统一过程¶
统一软件开发过程或统一过程是一个流行的迭代和增量软件开发过程框架。
有理统一过程（RUP）由 Rational Software Corporation 于 1996 年创建。RUP 不是一个单一的具体规定性过程，而是一个可适应的过程框架，旨在由开发组织和软件项目团队根据需要进行定制，这些团队将选择适合其需求的过程元素。
RUP 基于一组构建块和内容元素，描述了要生产的内容、所需的必要技能以及逐步说明具体开发目标如何实现。主要的构建块或内容元素如下：
- 角色（谁）
角色定义了一组相关的技能、能力和职责。
- 工作成果（内容）
工作成果代表任务产生的结果，包括在通过流程工作时产生的所有文档和模型。
- 任务（如何）
任务描述了分配给角色的工作单元，该工作单元提供有意义的结果。
Figure 4.4.4: RUP 学科与迭代¶
RUP 将项目定义为一系列 迭代 。迭代是执行项目任务的时间段。在每个迭代中，任务被分为九个学科：
六个“工程”学科
商业建模
需求
分析与设计
实现
测试
部署
并且还有三个“支撑”学科
配置与变更管理
项目管理
环境
4.1.3. 其他基于计划的方案¶
- 军事方法（国防部）
- DoD-STD-2167
一种以文档驱动的方法，为交付物规定了大量的“数据项描述”。鼓励进行裁剪，但很少执行。
- MIL-STD-1521
详细说明了所需的一组顺序审查和审计。
- MIL-STD-498
修订了 2167，允许在系统工程、规划、开发和集成方面具有更大的灵活性。
- MIL-STD-499B
定义了系统工程管理计划的内容。
- 通用流程标准（ISO、EIA、IEEE）
- EIA/IEEE J-STD-016
对 MIL-STD-498 的推广，包含商业软件流程。
- ISO 9000
包含软件的质量管理标准。
- ISO 12207 和 15504
处理软件生命周期以及评估软件流程的方法。
- 清洁房间（Harlan Mills，IBM）
使用统计过程控制和基于数学的验证来开发具有认证可靠性的软件。
名称源自于防止精密电子元件缺陷的物理洁净室。
- 软件能力成熟度模型（SEI、空军及其他机构）
一个流程改进框架，软件能力成熟度模型源于空军选择合格软件系统开发者的需求。
收集最佳实践，将其组织成五个级别递增的过程成熟度的关键实践领域。
- 软件工厂（日立、通用电气等）
一项长期的、综合性的工作，旨在提高软件质量、软件重用和软件开发生产力。
高度以处理驱动，强调早期缺陷减少。
- CMM 集成（SEI、DoD、NDIA 及其他）
CMMI 旨在集成软件工程和系统工程 CMM，并将 CMM 概念扩展到其他学科。
它是一套使用通用架构、词汇和一组过程领域来解决多种学科问题的模型和评估方法组合。
- 个人软件过程 (PSP)/团队软件过程 (TSP) (Watts Humphrey, SEI)
- PSP
一种用于开发软件的形式、指南和程序的结构化框架。旨在通过使用自我测量来提高个人编程技能。
- 旅行商问题
基于 PSP，并通过团队规划与控制支持工业级软件的开发。
4.1.4. 极限编程（XP）¶
由肯特·贝克于 20 世纪 90 年代末创立，XP 被认为是或许最著名的敏捷方法。XP 无疑是最早获得主流软件开发项目关注的敏捷方法之一。XP 是从为戴姆勒 - 克莱斯勒公司开发信息系统所获得的经验中提炼而成的。就敏捷实践而言，它相当具有规定性，相当严谨，并且最初期望所有实践都被遵循。肯特·贝克曾引用过
如果你没有执行全部 12 项实践，那么你就没有在做 XP。
在《 Extreme Programming Explained 》中，Kent Beck 描述了极端编程（XP）作为一种软件开发纪律，它组织人员以更高效地生产更高质量的软件。XP 试图通过多个短的开发周期而不是一个长周期来降低需求变更的成本。变更不应被视为负担，而应被视为软件项目的自然、不可避免且可取的方面，并应加以规划，而不是试图定义一组稳定的需求。
XP 以几种核心实践为特征，包括故事、结对编程、简单设计、测试优先、单元测试和持续集成。
XP 过程描述了在软件开发过程中执行的四个基本活动：编码、测试、倾听和设计。
- 编码
XP 认为，软件开发过程中唯一真正重要的产物是代码——计算机可以解释的软件指令。没有代码，就没有可运行的产品。
编码也可用于找出最合适的解决方案。编码也有助于交流关于编程问题的想法。程序员在处理复杂的编程问题时，或者难以向同行解释解决方案时，可能会以简化的方式对其进行编码，并使用代码来展示他们的意思。支持这一观点的人认为，代码总是清晰简洁的，不可能有多种解释。其他程序员也可以通过编码他们的想法来对这段代码提供反馈。
- 测试
单元测试用于确定给定功能是否按预期工作。程序员会编写尽可能多的自动化测试，这些测试可能会“破坏”代码；如果所有测试都成功运行，那么编码就完成了。在转向下一个功能之前，每一段编写的代码都会进行测试。
验收测试验证程序员所理解的需求是否满足客户的实际要求。
最初，鼓励进行系统级集成测试，将其作为每日日终活动，以便在单独部分与连贯功能广泛偏离之前，尽早检测出不兼容的接口并重新连接。
- 倾听
程序员必须倾听客户对系统的需求，以及所需的“商业逻辑”。他们必须充分理解这些需求，以便就问题可能如何被解决，或者无法被解决的技术方面，向客户提供反馈。客户与程序员之间的沟通在规划游戏中得到了进一步阐述。
- 设计
随着软件系统的增长，设计的重要性日益增加。然而，小型程序可以用相对较少的设计构建，但随着软件规模的扩大，所需的设计也越来越多。通常，在项目生命周期中，不仅需要更多的前期设计，还需要不断检查和重新审视设计。
4.1.5. 晶体¶
由艾利斯·科克伯恩于 20 世纪 90 年代末创立，水晶被构想为一组按颜色组织的软件开发过程，包括清晰、黄色、橙色和红色。迄今为止，只有水晶清晰，即该家族中最轻量级的过程，得到了完整的文档记录。
Crystal 根据团队规模和项目关键程度提供不同级别的“仪式”。Crystal 实践汲取了敏捷和计划驱动方法以及心理学和组织发展研究的精华。
4.1.6. Scrum¶
Scrum 是一种敏捷软件管理流程。
项目被划分为 30 天的工作区间（“冲刺”），其中实现来自优先列表（“待办清单”）中的特定数量的需求。短（10-15 分钟）“斯克里普会议”每日举行，维持团队与项目干系人（猪和鸡）之间的协调。
4.1.7. 特征驱动开发 (FDD)¶
FDD 是一种轻量级、基于架构的过程，首先建立整体对象架构和功能列表。
