软件过程模型

• 瀑布模型
  特点：因果关系紧密相连，前一个阶段的输出结果，时候一个阶段的输入。

  缺点：

  • 软件需求的完整性、正确性等很难确定，甚至是不可能和不现实的
  • 严格串行化，很长时间才能看到结果
  • 基于每个阶段一次性完全解决该阶段的工作，不太现实

• 原型模型
  阶段：原型开发阶段、目标软件开发阶段

  按原型作用划分：抛弃型原型、演化型原型

• 螺旋模型
  在快速原型的基础上扩展而成。

  每阶段的组成部分：目标设定、风险分析、开发和有效性验证、评审

敏捷模型

敏捷方法的特点：

• 适应性，而非预设性
• 面向人，而非面向过程
• 迭代增量式的开发过程

主要敏捷方法：

• 极限编程 XP 极限编程中的「极限(Extreme)」是指将我们认同的有效软件开发原理和实践应用到极限，频繁地去实践，如：“如果单元测试很重要，那我们就做测试驱动开发。如果集成测试很重要，那就要在一天中进行多次集成，并且反复进行回归测试”。
• 水晶系列方法 机动性
• Scrum
  • 使用Backlog按优先级管理所有产品需求
  • 开发过程划分为多个短的迭代周期Sprint
  • 从Backlog中挑选优先级高的需求组成Sprint Backlog进行迭代开发
• 特征驱动开发 FDD
  三要素：人、过程、技术

统一过程模型 RUP

RUP把软件开发生命周期划分为多个循环（Cycle），每个循环由四个连续的阶段（Phase）组成：

• 初始（inception）：定义最终产品视图和业务模型，并确定系统范围
• 细化（elaboration）：设计及确定系统的体系结构，指定工作计划及资源要求
• 构造（construction）：构造产品并继续演进需求、体系结构、计划直至产品提交
• 移交（transition）：把产品提交给用户使用

每个阶段都由一个或多个连续的迭代（Iteration）组成。

每个阶段结束前有一个里程碑（Milestone）评估该阶段的工作。

RUP的特点：

• 用例驱动
• 以体系结构为中心（4+1视图模型）
  • 用例视图：核心，分析人员和测试人员关心此视图
  • 逻辑视图：用户
  • 实现视图：程序员
  • 进程视图：系统集成人员
  • 部署视图：系统工程师
• 迭代与增量

软件能力成熟度模型

软件能力成熟度模型 （Capability Maturity Model for Software）CMM

• Level1 初始级：随意且混乱，依赖于组织人员能力，英雄主义
• Level2 已管理级：文档化，过程化，目标化
• Level3 已定义级：结合企业自身情况，制度化
• Level4 量化管理级：建立产品质量、服务质量、过程性能的定量目标
• Level5 优化级：不断改进

需求工程

需求工程的活动阶段：

• 需求获取
• 需求分析 - 建立概念模型
• 形成需求规格/需求文档化
• 需求确认与验证 - 确认、复审、模拟仿真、快速原型
• 需求管理
  • 变更控制
  • 版本控制
  • 需求跟踪
  • 需求状态跟踪

软件需求开发的最终文档经过评审批准后，则定义了开发工作的需求基线（Baseline）。

这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定（Agreement）。

需求约定是需求开发和需求管理之间的桥梁。

需求变更管理过程

• 问题分析和变更描述
• 变更分析和成本计算
• 变更实现

需求追踪

• 正向跟踪 - 需求是否都已实现检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点
• 逆向跟踪 - 是否实现了需求外的内容检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处