开发方法：从"瀑布"到"敏捷"的进化史

🔄 6.1 软件生命周期：软件的"生老病死"

软件和人一样，有诞生也有消亡。GB8566-88把软件的一生分成8个阶段：

🌊 6.2.1 瀑布模型：一条道走到黑

瀑布模型就像瀑布一样，从一个阶段单向流向下一个阶段。每个阶段结束有固定的文档流入下一阶段，所以也叫面向文档的开发模型。

瀑布V模型是瀑布的变体——编码后那段弯成V形：需求分析↔系统测试，概要设计↔集成测试，详细设计↔单元测试。左设计右测试，对称呼应，更强调验证。

🌀 6.2.2-6.2.3 演化模型与螺旋模型：做两次肯定更好

演化模型核心信念：人的认知是渐进的，不可能一次理解所有需求。所以把瀑布跑多轮，每轮迭代完善。

螺旋模型=瀑布+演化+风险分析。每圈四步：需求定义→风险分析→工程实现→评审。最大特色是在每个阶段前做严格的风险识别、分析和控制。

📦 6.2.4 增量模型：先上核心，逐步加料

增量模型两种策略：

• 增量发布：先做好整体分析设计，然后分版本发布。V1=核心功能，V2=扩展...每个版本都是完整的、可用的。增量要均匀——V1一个月V2六个月就失去意义了。
• 原型法：需求不明或技术架构不确定时，先快速搭原型验证，一般会抛弃原型重做。重点是获取精确需求或验证架构可用性。

🧩 6.2.5 构件组装模型：搭积木式开发

构件组装模型=搭积木。需求分析后把系统划分为一组构件集合，每个构件独立、自包容，通过接口协作。构件可自己开发、重用已有的、或买第三方的。

优点：扩展容易、可重用降低成本、可并行开发。
缺点：需要经验丰富的架构师、可能为重用牺牲性能、学习成本高、第三方构件质量不可控。

🏗️ 6.3 统一过程(UP)：二维开发的大管家

UP（Unified Process）由Rational公司开发，是迭代的二维开发模型。

横轴（时间）=4个阶段：

• 📡 初始：界定范围、明确目标。业务建模和需求是重头戏。
• 📋 细化：抽象逻辑模型、设计架构。分析设计是主要活动。
• 🔨 构建：基本完成系统构建。实施和测试是主要活动。
• 📦 交付：产品化、重构、修改、测试、部署。

纵轴（工作流）=9个核心工作流：业务建模、需求、分析设计、实施、测试、部署（6个工程活动）+ 配置与变更管理、项目管理、环境（3个管理/支持活动）。

4个里程碑：目标(初始结束)→架构(细化结束)→能力(Alpha测试后)→发布(测试完成、发布培训后)。

架构设计师在UP中至关重要——建立架构模型、细化架构、保持概念完整性、定义设计方法/指南/编码指南/评审设计，所以UP也被称为以架构为中心的开发模型。

🏃 6.4.1 极限编程(XP)：12个最佳实践的"组合拳"

2001年2月，17位"无政府主义者"在犹他州发表《敏捷软件开发宣言》。XP是其中最鲜艳的旗帜。

XP四大价值观：

• 🗣️ 沟通：程序员不善言谈？用结对编程逼你开口
• 🧘 简单：够用即好，不考虑明天
• 🔁 反馈：开发过程不是黑盒，持续反馈暴露问题
• 💪 勇气：应对变化，敢于重构

四大价值观之下，隐藏着更深刻的东西：尊重。

12个最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周40小时、现场客户、编码标准。

🎯 6.4.2 特征驱动开发(FDD)：几页纸的过程

FDD来自一个新加坡银行项目。Jeff De Luca和Peter Coad接手时客户刚经历了一次项目失败，团队士气低落。最终用特征驱动+彩色建模获得了巨大成功。

6种角色：项目经理(保护伞)、首席架构设计师、开发经理、主程序员、程序员、领域专家。

5个核心过程：开发整体对象模型→构造特征列表→计划特征开发→特征设计→特征构建。设计和构建合并起来反复迭代。

FDD最有特色：类的个体所有——代码分配给特定的人维护，不像其他模型代码共有。优点是概念完整、最熟悉的人维护、有自豪感；缺点是依赖关系增强、A等B修改才能用。另一个特色：审查——作为最佳实践明确提出，发现测试发现不了的缺陷（建模、需求和设计期的缺陷）。

📊 6.4.3 Scrum：短迭代的"冲刺者"

Scrum是增量、迭代的开发框架。整个开发由若干短迭代(Sprint)组成，每个Sprint建议2-4周。

5个活动：

• 📝 产品待办事项列表梳理：持续维护需求列表，排序、分解、合并、估算
• 🗓️ Sprint计划会议：选哪些做、怎么做。时长=Sprint每周对应2小时
• ⏰ 每日Scrum：15分钟站会。三问：昨天干啥、今天干啥、有啥阻碍。不是向管理层汇报，是团队内部沟通
• 👀 Sprint评审会议：展示产品增量，调整Backlog
• 🔄 Sprint回顾会议：反思流程、工具、人际关系，制定改进计划

5大价值观：承诺、专注、开放、尊重、勇气。

💎 6.4.4 水晶方法与6.4.5 其他敏捷

水晶方法(Crystal)由Cockburn建立，是一组方法家族：Crystal Clear(≤6人)、Yellow、Orange、Red。最常用的是Crystal Clear。

透明水晶七大体系特征：① 经常交付 ② 反思改进 ③ 渗透式交流（同屋工作，背景听觉获取信息）④ 个人安全（指出问题不怕报复）⑤ 焦点（清楚最重要任务，有时间做）⑥ 与专家用户方便联系 ⑦ 自动测试+配置管理+经常集成的技术环境。

其他敏捷方法：

• 🔓 开放式源码：开发人员地域分散，靠"补丁"并行排错——与其他敏捷强调同地工作不同
• 🔄 ASD方法：Jim Highsmith提出，三个非线性阶段——猜测、合作与学习

♻️ 6.5 软件重用与构件技术

软件一旦产生就可以无限复制，重用意义重大。7种重用形式：

构件=自包容+可重用的程序集。两大特性：自包容（功能完整、内外界限清晰）+ 可重用。三大构件标准：CORBA、Java Bean/EJB、COM/DCOM。1968年NATO会议就提出了"软件组装生产线"的梦想。

📐 6.6 基于架构的软件设计(ABSD)

ABSD是架构驱动方法，三个基础：① 功能分解（内聚耦合技术）② 选择架构风格实现质量和业务需求 ③ 软件模板的使用。ABSD是递归的、迭代的，每步清晰定义，不管设计是否完成架构总是清晰的——降低随意性。

ABSD的输入：抽象功能需求（含变化需求）、用例、抽象的质量和业务需求、质量因素、架构选项、约束。

基于架构的软件开发模型(ABSDM)=6个子过程：

🔢 6.7 形式化方法：用数学证明"没错"

形式化方法=用严格的数学方法+形式化规约语言精确定义软件系统。非形式化用自然语言/图形/表格，形式化用数学。

两部分：形式化描述（解决"做什么"）+ 形式化验证（验证程序是否满足描述）。形式化描述两类：① 建立计算模型描述行为 ② 定义系统必须满足的属性。