项目生命期确定了将项目开始和结束连接起来的阶段。
项目生命周期阶段 重点
- 概念/启动阶段：确立项目需求和目标
- 开发/计划阶段：检验需求并开发项目计划
- 执行/实施阶段：将计划付诸实施
- 结束/收尾阶段：最终产品交付与验收
软件产品生存期 vs 项目生存期
- 产品生存期：从产品调研到淘汰的全过程（调研→批准→需求→设计→开发→测试→交付→批量生产→维护→升级→淘汰）
- 项目生存期：从项目批准到交付的全过程（批准→需求→设计→开发→测试→交付）
软件项目生存期模型特征
- 描述开发的主要阶段
- 定义每一阶段要完成的主要过程和活动
- 规范每一阶段输入和输出
项目生存期模型对比 重点
| 模型 | 核心思想 | 主要优点 | 主要局限 | 适合场景 |
|---|---|---|---|---|
| 瀑布模型 | 按计划、需求、设计、编码、测试、维护顺序线性推进 | 阶段清晰，文档完整，便于计划和管理 | 变更成本高，用户较晚看到产品，难以及时发现需求偏差 | 需求明确、方案明确、有类似项目经验的短期项目 |
| V 模型 | 将开发阶段与测试阶段一一对应，强调验证和确认 | 测试活动更早规划，质量控制关系清晰 | 仍然偏线性，对需求变化适应能力弱 | 质量要求高、需求较稳定、需要明确测试对应关系的项目 |
| 螺旋模型 | 以风险分析为核心，通过多轮循环逐步推进 | 风险控制能力强，用户可较早看到产品，适合复杂项目 | 管理复杂，对风险识别和评估能力要求高 | 风险是主要制约因素、需求不明确、采用新技术、规模大的项目 |
| 原型模型 | 快速构造原型，通过用户反馈不断修改完善 | 有助于澄清需求，降低需求误解，用户参与度高 | 原型可能被误当作最终系统，后期结构和质量可能受影响 | 需求模糊、用户难以一次性说明需求的项目 |
| 增量模型 | 先交付系统的一部分，再逐步增加功能和性能 | 可较早交付可用系统，降低一次性投入风险，便于分批验证 | 需要良好的总体架构设计，增量划分不当会导致集成困难 | 需求大部分明确但可能变化、需要逐步投放市场的项目 |
| 敏捷模型 | 迭代和增量结合，频繁交付并持续响应变化 | 适应需求变化，交付周期短，客户反馈及时 | 对团队协作和客户参与要求高，弱文档可能影响长期维护 | 需求变更频繁、需要快速交付价值的项目 |
| 混合模型 | 结合预测型和敏捷型方法，按项目部分选择不同方式 | 兼顾计划控制与变化响应，适应性强 | 方法组合复杂，需要明确哪些部分采用预测型或敏捷型 | 同一项目中既有稳定需求又有不确定需求的场景 |
生存期选择 重点
| 类型 | 特点 | 适合场景 |
|---|---|---|
| 预测型 | 提前大量计划，一次性执行 | 需求明确、方案明确、短期项目 |
| 迭代型 | 允许反馈改进和修改工作 | 需求不明确 |
| 增量型 | 向客户提供已完成的可用交付 | 功能逐步增加 |
| 敏捷型 | 既有迭代又有增量，频繁交付 | 需求变更频繁 |
预测模型
瀑布模型
- 计划→需求分析→设计→编码→测试→维护
- 适合：需求明确、方案明确、有类似项目经验的短期项目
V 模型
- 强调测试与开发的对应关系
迭代模型
螺旋模型
- 四个象限：制定计划、风险分析、实施工程、客户评估
- 通过风险管理驱动，用户可以更早看到产品
- 适合：风险是主要制约因素、需求不明确、采用新技术、规模大
原型模型
- 快速构造原型，不断修改完善
增量模型
- 首先构建系统一部分，逐步增加功能和性能
- 特点：循序渐进避免一次性投入过大风险、更快开发出可操作的系统
- 适合：需求大部分明确但可能变化、对市场把握不准
敏捷模型 重点
敏捷是一种迭代、循序渐进的开发方法，应对迅速变化的需求。
敏捷宣言 4 价值观
- 个体和交互胜过过程和工具
- 工作软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
Scrum 模型
- 1990 年代初由 Ken Schwaber 提出
- 迭代开发，2-4 周为一个 Sprint
- 会议：迭代计划会、每日站会、迭代评审会、迭代回顾会
XP（极限编程）
- 由 Kent Beck 提出
- 强调结对编程、TDD、持续集成等实践
DevOps
DevOps 是 Development 和 Operations 的组合，促进开发、技术运营和质量保障部门之间的沟通、协作与整合。
混合模型
结合预测型和敏捷型的特点，适应不同项目需求。