在一座黑塔里住着野兽，那座塔没有门也没有窗，没人能进去，也没人能离开。塔顶有一座骨头制成的牢笼，笼中羁押着的灵魂窥视着太阳。那座塔是我的身体，年笼是我的头骨，那正在唱歌聊以自慰的灵魂是我。但我还是很痛苦，我很孤独。杀了我吧。

软件生成期模型

瀑布模型、快速原型模型、增量模型、喷泉模型、统一过程、基于构建的开发模型、敏捷模型

瀑布过程

早期使用的模型。顺序依赖，物理实现推迟，保证质量，规范开发过程

需求分析→规格说明→设计→编码→综合测试→维护

强调反馈和迭代

瀑布模型特点

1. 阶段间具有顺序性和依赖性
   • 必须等前一阶段的工作完成之后，才能开始后一阶段的工作
   • 前一阶段的输出文档就是后一阶段的输入文档
2. 推迟实现的观点
   • 瀑布模型在编码之前设置了系统分析和系统设置的各个阶段。分析和设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的无力实现
   • 清楚地区分逻辑设计与物理设计，尽可能推迟软件的无力实现，是按瀑布模型开发软件的一条重要指导思想
3. 质量保证的观点
   • 每一阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务
   • 每个阶段结束前都要对所完成的文档进行评审，以便及时发现问题，改正错误

瀑布模型优点

• 可强迫开发人员采用规范化的方法
• 严格规定了每个阶段必须提交的文档
• 要求每个阶段交出所有产品都必须是经过验证（评审）的

瀑布模型缺点

• 由于瀑布模型几乎完全依赖于书面的规格说明，可能最终开发出来的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这两种情况
• 瀑布模型只适用于项目开始时需求已确定的情况

V模型：瀑布模型的变体

快速原型模型

快速原型完成的是最终产品功能的一个子集，解决瀑布模型需求分析不完善的问题。快速原型本质是快速，目的是获知用户的真正需求，需求确定了就可抛弃原型或在原型的基础上继续开发。

快速原型的优点

1. 有助于满足用户的真实需求
2. 原型系统已经通过与用户的交互而得到验证，产生的规格说明文档能正确的描述用户的需求
3. 不会因规格说明文档的问题进行较大返工
4. 开发原型的过程积累的经验，会在设计编码阶段发生错误的可能性更小，减少后续阶段弥补错误的可能性
5. 开发按线性顺序进行。

增量模型

将软件产品作为一系列增量构建来设计、编码、集成、测试。每个构建2由多个相互作用的模块构成，并且能完成特定的功能

增量模型的优点

1. 较短时间内就可以完成一些有用的工作产品，用户就能做一些有用的工作
2. 用户有较充裕的时间学习适应新产品，降低软件给用户带来的冲击
3. 项目失败风险低，若增量构建出问题，其他构建仍可以交付给用户
4. 优先级高的服务先交付，然后再其他增量构建，因此最重要的服务将接受最多的测试

增量构建的开发可采用瀑布模型方式

开发时需注意

1. 软件体系需开放，以便向现有产品加入新构建
2. 新的构建不得破坏原有软件产品

螺旋模型

将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略的风险分析。可以把他看作每个阶段之前都增加了风险分析过程的快速原型模型

在螺线上每个循环表示过程的一个阶段：

对于每个阶段：

1. 确定该阶段的目标，为实现这些目标选择方案及设定这些方案的约束条件（约束：非功能需求）
2. 从风险角度分析上一步的工作结果，努力排除各种潜在的风险（通常使用建造原型的方法）
3. 以瀑布模型的方法开发本阶段
4. 评价本阶段工作成果，并计划下阶段的工作

螺旋模型的四项活动（对应四个象限）：

1. 目标设定：定义目标，理清限制条件，指定管理计划，识别分析（并设置风险对策）
2. 风险估计与弱化：分析风险，设想弱化风险的步骤
3. 开发与验证：选择系统开发模型
4. 计划：评价开发工作，确定是否进行下个循环以及下阶段的工作

螺旋模型的优点：

1. 强调可选方案和学术条件，有利于已有软件的重用，将软件质量作为软件开发的重要目标
2. 减少过多测试或测试不足带来的风险
3. 维护是模型的另一个周期，因此在维护和开发之间没有本质区别

螺旋模型的缺点：

螺旋模型是风险驱动的，软件开发人员必须具有丰富的风险评估经验

喷泉模型

喷泉模型是典型的面向对象生命周期模型，“喷泉”一词体现了迭代和无间隙特性

统一过程

统一过程的工作流：

• 业务建模工作流：用商业用例为商业过程建立文档
• 需求工作流：描述做生命，需明确系统的功能需求和非功能需求（约束）
• 分析设计工作流：说明如何做，结果是分析模型和设计模型
• 实现工作流：用分层的方法组织代码结构，用构建形式实现类，对构建进行单元测试，将构建集成到可执行的系统中
• 测试工作流：验证对象间的交互，构建集成完整，需求完全实现，差错并改正
• 部署工作流：制作发布版，软件打包，分发，为用户提供支持

统一过程的阶段：初始、细化、构造、移交

• 初始阶段：关注项目计划和风险评估
• 细化阶段：关注系统的总体框架，细化初始需求，体系结构，监控风险并细化优先级，细化业务案例以及指定项目管理计划
• 构造阶段：建立系统，以交付β测试版本结束
• 移交阶段：包含β测试时期，以发布完整的系统终止

基于构建的开发模型

考虑的焦点是“集成”，而不是“实现”。开发可复用的构建来满足大型软件系统中存在的共用性

体系结构设计完成后，并不立即进行详细设计，而是针对每一系统需求考虑以下问题：

• 现有的商品化构建（COTS）能否实现该需求？
• 内部开发的可复用构建是否能实现该需求？
• 可用构建的接口与待构造的体系结构是否相容？

开发步骤（不考虑构建的开发技术）：

1. 对于该问题领域的基于构建的可用产品进行研究和评估
2. 考虑构建集成的问题
3. 设计软件架构以容纳这些构件
4. 将构建集成到框架中
5. 进行充分的测试以保证功能正常

敏捷过程

敏捷原则

1. 我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
2. 即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
3. 经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
7. 可运行软件是进度的首要度量标准。
8. 提倡可持续的开发速度。责任人(sponsor)、开发者和用户应该能够长期保持稳定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单——是减少不必要工作量的艺术——是必要的
11. 最好的架构、需求和设计出自于自组织团队。
12. 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。

敏捷开发宣言

1. 个体和交互胜过过程和工具
2. 可工作软件胜过宽泛的文档
3. 客户合作胜过合同谈判
4. 响应变更胜过遵循计划

敏捷开发更适合具有以下特征的软件开发项目：

1. 难以预测哪些需求稳定，哪些需求困难
2. 设计和构建是交错进行的（在构建验证之前很难估计应该设计到什么程度）
3. 分析，设计，构建，测试并不像设想中那么容易预测

极限编程（Extreme Progrmming, XP)

最为广泛使用的敏捷过程，包括策划、设计、编码、测试，四个框架活动的规则和实践

极限编程的主要目标在于降低因需求变更而带来的成本。 采用迭代的交付方式，每个迭代很短（1-3周时间）。在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。

极限编程的框架活动：

1. 策划：
   1. 构建“用户故事”，评估每个故事给出成本
   2. 将故事分组用户可交付增量，并对发布时期做出承诺
   3. 第一个版本发行后，项目速度将邦族建立后续发布日期
2. 设计：
   1. 保持简洁原则，鼓励使用CRC（类，责任，协作者）卡片
   2. 对实现困难的部分设计可执行原型，实现并评估原型
   3. 鼓励重构
3. 编码：
   1. 建议在编码之前为每个故事建立一系列单元测试
   2. 鼓励结伴编程
4. 测试：
   1. 所有单元测试每天都要执行
   2. 验收测试由用户定义，着眼于用户可见的，可评审的系统级的特征和功能

敏捷开发流派

Scrum开发模型

SAFe，精益企业规模化敏捷框架

迭代前开发准备

用户故事

迭代前开发准备

迭代开发