软件项目管理 — 生存期模型

  路线图： 生存期

项目初始：
  - 项目确立
  - 生存期

项目阶段和项目生存期

• 项目的执行组织通常将项目分成【若干个项目阶段】，以便提供更好的【管理控制】，并与项目执行组织的持续运作之间简历恰当联系；

• 【项目阶段的全体】被成为【项目生存期】；

• 每个项目阶段以一个或几个可交付成果的完成作为标志；

• 【项目生存期】用来定义一个【项目的开始与结束】；

• 项目中的各个子项目也可能有明显不同的项目生存期；

项目生存期的特点

• 费用和人力投入开始比较低，然后逐渐升高，在项目的实施、控制阶段，达到最高峰。此后主键下降，直到项目的终止；

• 项目开始时风险和不确定性最高，随着任务一项项的完成，不确定因素主键减少，项目成功完成的概率将会逐渐增加；

• 随着项目的进行，项目变更和改正错误所需要的花费将随着项目生存期的推进而激增；

• 项目干系人的影响逐步降低

项目生存期典型阶段

* 启动阶段： 【概念和建议】
 
* 中间阶段： 【开发、执行、验证】
 
* 完成阶段： 【收尾】
 

软件生存期模型

1、软件开发的一种框架。
 
2、说明了软件的活动和进行软件开发的过程。
 
3、这个模型可以是以活动为中心，可以以产品为中心的。

软件生存期模型特征

1、描述了开发的主要阶段；
2、定义了每一个阶段要完成的主要过程和活动；
3、规范了每一个阶段的输入和输出；
4、提供了一个框架，可以将必要的活动映射到该框架中；

软件生存期模型的变迁

作坊式 =》 过程控制 =》 敏捷模型 =》DevOps

软件生存期模型分类

预测型模型

传统的方法，需要提前进行大量的计划工作，然后一次持续的执行；

• 瀑布模型
• V模型

适应型模型

• 迭代模型： 允许对未完成的工作进行反馈，从而改进和修改该工作；

• 增量模型： 想客户提供已完成的，可以立即使用的可交付成果；

• 敏捷模型： 同时利用迭代和增量特征，便于完善工作；

混合模型

方法	需求	活动	提交	目标
预测型	固定	整个项目只执行一次	提交一次	成本可管理
迭代型	变化	一直重复执行直到正确为止	提交一次	正确的解决方案
增量型	变化	每个特定增量的活动只执行一次	频繁小增量提交	速度
敏捷型	变化	一直重复执行直到正确为止	频繁小增量提交	通过频繁提交和反馈体现客户价值

预测性生存期模型

• 充分利用已知和已经证明的事物，不确定性和复杂性减少，允许项目团队将工作分解为一系列可预测的小组；

• 要求项目是高确定性的、有明确的需求顺序执行；

• 包括瀑布模型和V模型；

============================================================
【需求分析】 =》 【设计】 =》 【实施】 =》 【测试】 =》 【交付】

瀑布模型

瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。

瀑布模型适合的项目： 【项目的需求要明确】【解决方案要明确】【短期项目】

V模型

V模型是瀑布模型的一个变种，强调【测试与开发的一一对应关系】

项目规划 - 接收测试
需求分析 - 系统测试
总体设计 - 集成测试
详细设计 - 单元测试
   编码和调试

V模型优缺点
优点 ：

1. 强调测试过程与开发过程的对应性和并行性。
2. 开发进程比较严格，执行过程需要严密控制。
3. 为项目提供了按阶段的检查点，当前一个阶段完成后，只需关注后续阶段。

缺点：

1. 不能适应需求的快速变化
2. 项目的实现方案需要很明确
3. 不能存在变更

V模型适合的项目： 【项目的需求很明确】【解决方案很明确】【项目对系统的性能安全很严格】

迭代型生存期模型

• 迭代型生存期模型： 通过连续的原型或概念验证来改进产品或成果，每个新的原型都能带来相关新的反馈和团队见解。这种迭代有利于识别和减少项目的不确定性；

• 原型模型： 是在需求阶段快速构建一部分系统的生存期模型，实现客户或未来用户与系统的交互，用户或客户可以作为进一步修改系统的依据；

在实践中，迭代型生存期模型直接等同于原型模型。

原型模型适合的项目 【项目需求不明确】【希望减少项目需求的不确定性】【确定显示界面、第一次开发的产品，验证可行性等】

增量模型： Incremental Model

增量型生存期模型的策略是不同时开发项目需求，将需求分段，使其成为一系列增量产品

• ★ 每一增量可以分别实施，每一个增量包括需求分析、设计、实施、测试、提交等；
• ★ 每一增量是一个交付成果；
• ★ 第一增量通常是实现基本需求的核心产品；

增量模型优缺点

优点：

• 可以较好地适应变化，客户可以不断地看到所开发地软件，从而降低风险。
• 可以避免一次性投资太多带来地风险。
• 可以更快地开发出可操作地系统。
• 可以减少开发过程中用户需求地变更。
  缺点：
• 软件需具备开放式地体系结构。
• 早期需求地不稳定或不完整可能导致有地增量需要重新开发，增加了过程控制地难度。
  

敏捷宣言： 
1. 个体交互胜过过程工具
2. 客户合作胜过合同谈判
3. 可以工作的软件胜过面面俱到的文档
4. 响应变化胜过遵循计划

* 应对迅速变化需求的快速软件开发方法
* 是一种以人为核心的迭代、遵循渐进的开发方法
* 是一种轻量级的软件开发方法