软件工程发展

• 软件开发的四大本质难题：不可见性、复杂性、可变性、一致性。
  • 除了不可见性以外，其他三个本质难题因项目而异。
  • 四大本质难题互相促进，可以缓解，但是不能够彻底解决。
• 软件发展的三大阶段
  • 软硬件一体化：50 年代到 70 年代
    • 特点：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎没有需求变更。
    • 开发方法：线性顺序过程、三思而后行（Measure twice，cut once）、编码和改错（code and fix）。
  • 软件成为独立的产品：70 年代到 90 年代
    • 特点：软件摆脱硬件的束缚（操作系统）、功能强大（个人电脑的出现）、需求多变、兼容性要求、来自市场的压力。
    • 开发方法：形式化方法、结构化程序设计和瀑布模型
  • 网络化和服务化：90 年代中期至今
    • 特点：功能更复杂、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方式的变化、进一步的服务化和网络化、盛行开源和共享精神
    • 开发方法：迭代式开发、敏捷开发（XP、Scrum、KanBan）、开源软件开发方式、DevOps

软件工程与管理

管理

区分软件项目管理和软件过程管理

• 管理的三大关键要素：目标、状态、纠偏
• 软件项目管理：软件项目管理是应用方法、工具、技术以及人员来完成软件项目，实现项目目标的过程。
  • 软件项目管理的三大目标：成本、工期、质量。
  • 软件项目管理的对象是各项软件项目。
  • 软件项目管理的管理视角可以细分为软件过程和生命周期模型。
• 软件过程管理：软件过程管理的目的是为了让软件过程在开发效率、质量等方面有着更好的性能绩效。
  • 软件过程管理的对象是软件过程。
• 软件过程改进：与关键过程管理的含义相近。
  • 软件过程管理参考模型：CMM/CMMI、SPICE 等
  • 软件过程改进参考模型：PDCA、IDEAL

软件过程

软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践（具有一定先后顺序）的集合

广义软件过程

广义软件过程的同义词包括：软件开发方法、软件开发过程

• 广义软件过程包括技术、人员以及狭义软件过程
• 例子：净室 Clean Room 方法、极限编程方法、Scrum 方法、Gate 方法、敏捷软件过程/方法、轻量型过程/方法和重量型软件过程/方法

生命周期模型

• 生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法。
• 生命周期模型与软件过程的区别和联系
  • 生命周期模型是对软件过程的一种人为划分。
  • 生命周期模型是软件开发过程的框架，是对软件开发过程的一种粗粒度划分。
  • 生命周期模型往往不包括技术实践。
• 如何理解瀑布模型
  • 瀑布模型不是单一模型，是一系列模型，覆盖最简单场景（过程元素少）到最复杂的场景（过程元素多）。
  • 软件项目应该结合实际情况选择合适的过程元素的瀑布模型。基本原则是，项目面临的困难和挑战越多，选择的模型应该越复杂。
  • 软件项目团队往往低估了项目的挑战，选择了过于简单的不适用的瀑布模型。

敏捷软件开发

• 目的：使软件开发团队具有高效工作和快速响应变化的能力。
• 特征：小周期迭代、快速响应变更、价值交付、自动化。
• 雪鸟会议与敏捷宣言：
  • 个体和交互 胜过 过程和工具
  • 可以工作的软件 胜过 面面俱到的文档
  • 客户合作 胜过 合同谈判
  • 响应变化 胜过 遵循计划
• 具有误导性的描述
  • 轻量级方法：对 XP 为代表的一类方法的误导，轻量级和重量级没有具体的区分想法。
  • 拥抱变更、变更驱动：对待变更，所有的软件工程方法都是限制和管理的态度。所有正式的项目都是计划驱动的，否则计划的作用无法体现。
  • 测试驱动开发可以提供更高的开发质量：没有足够的证据支持。

敏捷软件开发方法

• 极限编程方法 XP
  • 将好的开发实践运用到极致，规定开发人员每周工作时间不超过 40 小时，连续加班不可以超过两周。
  • 典型方法：比如客户作为开发团队的成员、短交付周期、结对编程、测试驱动开发（Test Driven Design, TDD）、持续集成、重构。
• Scrum：
  • 3 个角色：产品负责人、Scrum Master、开发团队。
  • 3 个工件：产品订单（优先级、动态）、冲刺订单（细化、冻结）、燃尽图。
  • 5 个活动：Sprint、Sprint Planning、Sprint Daily Standup、Sprint Review、Sprint Retrospective（冲刺/迭代回顾）。
• KanBan 方法：
  • 精益生产（丰田制造法）的具体实现
  • 活动：可视化工作流、限制 WIP、管理周期时间
• Scrum vs. XP：
  • 迭代周期不同：Scrum 的迭代周期为 2-4 周，XP 的迭代周期为 1-2 周。
  • 迭代中是否允许需求变更：Scrum 迭代中需求冻结，XP 只要时间资源相同即可变更。
  • 迭代中是否严格遵守需求优先级：Scrum 比较灵活(可能有需求依赖)，XP 严格遵守。
  • 过程工程化：Scrum 开发过程并未工程化，XP 对开发流程严格定义。
• Linus 定律：如果有足够多的beta测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。

迭代式开发方法

定义：大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成，而是通过多个迭代周期，逐步来交付。

各类模型

CMM

Capability Maturity Model，能力成熟度模型，是一种软件过程管理/改进参考模型

• CMM 是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。
• CMM 的五个等级：
  • 初始级 Initial：几乎没有健全的软件工程管理制度。（特定过程）
  • 可重复级 Repeatable：有基本的软件项目的管理行为，设计和管理技术是基于相似产品中的经验，复用以前的成功。（已经规范的过程）
  • 已定义级 Defined：为软件生产的过程编制了完整的文档。（标准过程）
  • 已管理级 Managed：公司为每个项目都设定质量和生产目标。（可预测的过程）
  • 优化级 Optimizing：持续地改进软件过程（持续改进过程）

CMMI

Capability Maturity Model Integration，能力成熟度模型集成

• CMMI 刻画软件团队/组织从不成熟到成熟的每个阶段的特征
• CMMI 的五个等级：
  • 初始级 Initial：过程不可预测、项目管理很少、开发相对混乱。个人英雄主义、救火文化
  • 已管理级 Managed：以项目为单位进行管理，相对被动的管理。有项目计划和跟踪、需求管理、配置管理等
  • 已定义级 Defined：以公司为单位进行管理，相对主动的管理。公司层面有标准流程和相应规范，每个项目小组可以基于此定义自己的流程
  • 定量管理级 Quantitatively：过程被度量和管理。构建预测模型，用统计过程控制的手段来管理过程
  • 优化级 Optimizing：关注与过程改进。继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题

PDCA

Plan、Do、Check、Action。软件过程改进模型

PDCA 模型的步骤：

• 分析现状，找出问题
• 分析影响质量的原因
• 找出措施
• 拟定措施计划
• 执行措施，执行计划
• 检查效果，发现问题
• 总结经验，纳入标准
• 遗留问题转入下期 PDCA 循环

Plan：1-4，Do：5，Check：6，Action：7，8

IDEAL

Initialing、Diagnosing、Establishing、Acting、Leveraging

其他模型

1. SPICE模型：软件过程管理模型
2. ISO/IEC：软件过程改进模型
3. RUP Rational Unified Process：软件过程框架

PSP 个体软件过程

为什么有 PSP

• 软件系统的整体质量由该系统中质量最差的组件所决定。
• 软件组件的质量取决于开发工程师所使用的开发过程。
• 软件工程应当自己度量、跟踪自己的工作流程，并建立持续的自我改进机制，自己管理软件组件的质量。

PSP 质量管理

质量观与质量策略

• 质量观：
• 质量策略：使用缺陷管理来替代质量管理、各个组件的高质量是通过高质量评审来实现的。

质量步骤

1. 各种测试
2. 进入测试之前的产物质量提升
3. 评审过程度量和稳定
4. 质量意识和主人翁态度
5. 个体 review 的度量和稳定
6. 诉诸设计
7. 缺陷预防
8. 用户质量关 —— 其他质量属性

PSP 度量

PROBE 方法

Proxy Based Estimation

• 精确度量和早期规划之间的桥梁。
• 使用相对大小而不是绝对大小。

估算要点：

1. 尽可能划分地详细一些。
2. 建立对结果的信心。
3. 依赖数据。
4. 估算要的是过程，而不是结果。估算是相关干系人达成一致共识的过程。

Yield 指标

• Phase Yield = $\frac{某个阶段发现的缺陷个数}{某个阶段注入的缺陷个数 + 进入该阶段前遗留的缺陷个数} \times 100$
• Process Yield = $\frac{第一次编译前发现的缺陷个数}{第一次编译前注入的缺陷个数} \times 100$

• 最后的 Yield 一定为 50:最后的测试如果发现了一个错误，那么其中一定还有一个错误没有被发现
• 新增的缺陷按照注入的比例来分配

基于 Yield 指标构建缺陷预测模型，并列举该模型的可能改进方案

• 总体思想：利用回归技术预测软件开发过程中各阶段的 Inject Rate（缺陷注入率）和 Yield（缺陷消除率）
• Yield 指标只能用来估算，不可以用来度量。结合 Yield 指标和上图，只需要知道如下指标就可以基于 Yield 指标构建一个基本的缺陷预测模型：
  • 注入阶段注入多少缺陷
  • 缺陷注入的密度（需求每一页注入多少缺陷）
  • 缺陷注入的速度（每小时注入多少缺陷）
  • 消除阶段的缺陷注入密度和速度。
  • 历史数据中的软件规模、文档规模、开发人员规模
• 步骤
  • 确定纳入影响因子的数据以及数据度量方法
  • 从系统历史库中收集历史数据，并进行整理
  • 依照回归技术进行计算
  • 在项目进行过程中不断收集数据，与预测数据进行比较，调整回归参数
  • 项目过程中依据实际数据与预测数据的误差进行风险的预防、识别和控制
• 改进方案
  • 维护历史数据：历史数据在简单性、可理解性、稳定性、可度量性、相关性等方面的质量都有影响。
  • 影响因子的选择：不仅仅有软件规模的数据，还需要有开发过程、文档、人员等方面的数据，并将其可度量化。
  • 反馈模型：随着开发实际数据的产生，将这些数据作为输入变量放回模型来调整参数。
  • 蒙特卡洛方法：假设注入水平和消除水平都符合正态分布，计算均值和标准差并用蒙特卡洛方法模拟结果。

A/FR

• A/FR = $\frac{PSP 质检成本}{PSP 失效成本}$
• 理论上，A/FR的值越大，往往意味着越高的质量。
• 过高的A/FR往往意味着做了过多的评审，反而会导致开发效率的下降。作为指南，在PSP中A/FR的期望值就是 2.0

• 质检成本 = 设计评审时间 + 代码评审时间
• 失效成本 = 编译时间 + 单元测试时间

PQI

PQI 表示为五个数据的乘积：

• 设计质量：设计的时间应该大于编码的时间
• 设计评审质量：设计评审的时间应该大于设计时间的 50%
• 代码评审质量：代码评审时间应该大于编码时间的 50%
• 代码质量：代码的编译缺陷密度应当小于 10 个/千行
• 程序质量：代码单元测试缺陷密度应当小于 5 个/千行

Review Rate

• 评审的速度（Review Rate）是一个用以指导软件工程师开展有效评审的指标
• 高质量的评审需要软件工程师投入足够的时间进行评审
• 在 PSP 的实践中，代码评审速度小于 200 LOC/小时，文档评审速度小于 4 Page/小时

DRL

• 缺陷消除效率比度量的是不同缺陷消除手段消除缺陷的效率。
• 其计算方式是以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是DRL。

通用计划框架

TSP 团队软件过程

TODO