- 软件生产随规模增大复杂度增大
- 软件危机
- 即便是应用最为广泛的软件也有大量的错误
- 遍及我们生活各个方面的软件不可避免会出现问题，危及生命、业务，导致灾难
- 从未真正解决
- 项目失败原因
- 规模
- 管理
- 质量
- 软件过程理论的基石：软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。
- 休哈特
- 质量改进的奠基人
- 最早提出「计划-执行-检查（Plan-Do-See）」的概念
- 戴明
- 质量改进
- PDCA 循环：Plan, Do, Check, Action
- 十四点原则
- 朱兰
- 奠定全面质量管理（TQM）的理论基础
- 质量三步曲：计划，控制，改进
- 朱兰质量螺旋
- 80/20 原则：只有 20% 来自基层操作人员，而恰恰有 80% 的质量问题是由于领导责任所引起的。
- 克劳士比
- 提出了「零缺陷」的概念
- 质量管理的绝对性
- 质量改进的基本要素
- PDCA 模型
- 分析现状，找出问题
- 分析影响质量的原因
- 找出措施
- 拟定措施计划
- 执行措施，执行计划
- 检查效果，发现问题
- 总结经验，纳入标准
- 遗留问题转入下期 PDCA 循环
- IDEAL 模型：
- I: Initiating 开始
- D: Diagnosing 诊断、评价
- E: Establishing 建立
- A: Acting 执行
- L: Leveraging 调整
- 软件能力成熟度模型（CMM）
- 初始级
- 可重复级
- 已定义级
- 已经管理级
- 优化级
- 敏捷过程
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
- 极限编程（XP）
- 客户作为开发团队的成员——客户代表
- 使用用户素材
- 短交付周期
- 验收测试
- 结对编程
- 测试驱动开发
- 集体所有
- 持续集成
- 可持续的开发速度
- 重构
- 使用隐喻
- Scrum：一种迭代式增量软件开发过程，通常用于敏捷软件开发。
- PSP/TSP：
- PSP：着重于开发人员个人能力的提升
- TSP：提供定义过的团队构建流程、团队作业框架和一个有效的管理环境
- Rational 统一过程（RUP）：
- 迭代式开发
- 管理需求
- 使用基于构件的体系结构
- 可视化建模
- 验证软件质量
- 控制软件变更
- 平衡敏捷与规范
- 敏捷过程与规范过程各有自己的特点和优点
- Boehm 给出了影响敏捷与规范方法选择的五个维度：
- 动态性
- 危险性
- 规模
- 人员
- 文化
- 计划驱动的开发人员必须敏捷，敏捷开发人员必须规范。成功的关键在于找到两者的平衡点。
- 思考题
- 如何刻画软件过程特征：
- 敏捷 VS. 规范
- 敏捷 VS. 过程驱动
- 敏捷 VS. 传统
- 敏捷 VS. 瀑布模型
- 如何刻画软件过程特征：
- PSP 渊源和作用
- 过程改进运动：TQM、Humphrey 早期工作、PSP/TSP
- PSP 作用：
- 个人级别估算和计划
- 承诺和拒绝承诺
- 理解和改进
- 工业水准的过程和规范
- 客观决策的数据
- 什么是 PSP
- 包括了数据记录表格、过程操作指南和规程在内的结构化框架
- 一个基本的 PSP 流程包括策划、设计、编码、编译、单元测试以及总结等阶段
- 所有开发活动需要记录时间和缺陷日志
- PSP 基本原则
- 软件系统整体质量由质量最差的组件决定
- 应该自己度量并且跟踪、总结
- 过程度量
- PSP 基本度量项
- 时间
- 缺陷
- 规模
- 日程
- 时间日志、缺陷日志
- 度量标准：
- 选择的规模度量方式必须反映开发成本
- 选择的度量方式必须精确
- 选择的度量方式必须能用自动化方法来统计
- 选择的度量方式必须有助于早期规划
- 度量方式：LOC（Line Of Codes）
- 物理
- 逻辑
- PSP 基本度量项
- PROBE 估算方法：
- PROxy Based Estimation
- 相对大小矩阵
- 线性回归调整规模估算
- 线性回归调整时间估算
- 应用：
- 历史数据的处理：简单方法、正态分布、对数正态分布
- 有限历史数据
- 个别极端数据的处理
- 不适用：
- 历史数据少于 3 个数据点
- 有足够的历史数据，但是数据的质量不高
- 性质：
- 相关性 r ≥ 0.7
- 显著性 s ≤ 0.05
-
软件项目的日程、成本以及质量三大目标统一于质量目标。
-
质量概念
- 与软件产品满足规定的和隐含的需求能力有关的特征或者特性的全体
- 内外两部分的特性：其外部质量特性面向软件产品的最终用户，其内部质量特性则不直接面向最终用户
- 对人（用户）的价值
-
PSP 需要定义什么
- 用户究竟是谁
- 用户需求的优先级是什么
- 这种用户的优先级对软件产品的开发过程产生什么样的影响
- 怎样来度量这种质量观下的质量水平
-
PSP 质量策略
- 用缺陷管理来替代质量管理
- 高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷
-
测试消除缺陷的典型流程：
- 发现待测程序的一个异常行为
- 理解程序的工作方式
- 调试程序，找出出错的位置，确定出错原因
- 确定修改方案，修改缺陷
- 回归测试，以确认修改有效
-
评审发现缺陷典型流程：
- 遵循评审者的逻辑来理解程序流程
- 发现缺陷的同时，也知道了缺陷的位置和原因
- 修正缺陷
-
PSP 评审过程质量：
- 评审检查表
- 个性化
- 评审检查表的建立和维护
- 评审检查表的使用方法
- 质量控制指标
- 其他因素
- 环境
- 评审时机
- 个人评审和小组评审
- 缺陷预防
- 评审检查表
-
质量指标之一：Yield
- Yield 指标用以度量每个阶段在消除缺陷方面的效率
- Phase Yield = 100 * 某阶段发现的缺陷个数 / ( 某阶段注入的缺陷个数 + 进入该阶段前遗留的缺陷个数 )
- Process Yield = 100 * 第一次编译前发现的缺陷个数 / 第一次编译前注入的缺陷个数
- Yield 倒推
-
质量指标之二：A/FR
- A/FR = PSP 质检成本 / PSP 失效成本
- 期望 2.0
- 过高的 A/FR 意味着过多的评审
-
质量指标之三：PQI
- 五个数据乘积：
- 设计质量：设计的时间应该大于编码的时间
- 设计评审质量：设计评审的时间应该大于设计时间的 50%
- 代码评审质量：代码评审时间应该大于编码时间的 50%
- 代码质量：代码的编译缺陷密度应当小于 10 个/千行
- 程序质量：代码单元测试缺陷密度应当小于 5 个/千行
- 五个数据乘积：
-
质量指标之四：Review Rate
- 高质量的评审又需要软件工程师投入足够的时间进行评审
- 在 PSP 的实践中，代码评审速度小于 200 LOC/小时，文档评审速度小于 4 Page/小时
-
质量指标之五：DRL（缺陷消除效率比）
- DRL 度量的是不同缺陷消除手段消除缺陷的效率
- 其计算方式是以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是 DRL
-
评审的其他考虑因素
- 打印后评审往往效果更好
- 评审时机选择：编译前 VS. 编译后
- 个人评审和小组评审
- 先后顺序
- 小组评审的意义
- 组织形式
- 缺陷预测
- 缺陷预防
-
设计与质量的关系
- 低劣的设计是导致软件在开发中返工、不易维护和用户不满的主要原因
- 充分设计可以显著减少最终程序的规模，提升质量
- 设计本身就是一种排错
-
PSP 设计过程
- 见图（pp.36）
-
PSP 设计什么
-
设计目标程序在整个应用系统中的位置
-
设计目标程序的使用方式
-
设计目标程序与其他组件以及模块之间的关系
-
设计目标程序外部可见的变量和方法
-
设计目标程序内部运作机制
-
设计目标程序内部静态逻辑
-
表格：
动态信息 静态信息 外部消息 交互信息（服务、消息等） 功能（继承、类结构） 内部消息 行为信息（状态机） 结构信息（属性、业务逻辑）
-
-
PSP 设计模板
-
操作规格模板（Operational Specification Template，简称 OST）
-
功能规格模板（Functional Specification Template，简称 FST）
-
状态规格模板（State Specification Template，简称 SST）
-
逻辑规格模板（Logical Specification Template，简称 LST）
-
表格：
动态信息 静态信息 外部消息 OST FST FST 内部消息 SST LST
-
-
UML 常用图
- 用例图
- 时序图
- 类图
- 状态机图
-
设计流程
- 系统需求：用户需要什么
- 功能规格模板、操作规格模板、系统规格说明：系统该做什么
- 逻辑规格模板、状态规格模板、高层设计：系统该如何工作
- 模块需求：程序要求什么
- 功能规格模板、操作规格模板、模块规格说明：模块该做什么
- 逻辑规格模板、状态规格模板、详细设计：模块内部该如何工作
- 模块源码
-
PSP 设计验证方法
- 意义：简单评审不足以发现复杂缺陷
- 状态机验证
- 符号化执行验证
- 执行表验证
- 跟踪表验证
- 正确性验证
- 需求开发
- 需求是一切工程活动的基础
- 分类：客户需求、产品需求、产品组件需求
- 需求获取
- 「诱导」：积极地、前瞻性地识别额外需求
- 需求汇总
- 整理各种来源的信息，识别缺失的信息
- 解决冲突的需求
- 需求的整理和转化
- 推导未显式描述的需求内容
- 需求验证
- 对需求进行分析和确认，以确保符合使用者预期
- 活动：建立场景、分析需求、确认需求
- 需求文档制作
- 为了满足用户和开发者对初始规定有个共同的了解
- 特征：
- 内聚特征
- 完整特征
- 一致特征
- 原子特征
- 可跟踪特征
- 非过期特征
- 可行性特征
- 非二义性特征
- 强制特征
- 可验证特征
- 团队设计
- 基本和 PSP 过程一致
- 额外考虑：
- 团队智慧：分工、参与程度
- 设计标准：命名规范、接口标准、出错信息、设计表示标准
- 设计复用：接口、文档标准、质量保证机制
- 设计的可测试性支持：减少测试代码数量、合理的测试计划
- 测试的可用性支持：模拟、原型
- 实现策略
- 评审考虑
- 复用策略
- 可测试性考虑
- 集成策略选择
- 大爆炸集成策略
- 逐一添加集成策略
- 集簇集成策略
- 扁平化集成策略
- 验证与确认
- 都是为了提升最终产品的质量而采取的措施
- 目的不同：
- 验证是目的是确保选定的工作产品与事先指定给该工作产品的需求一致
- 确认的目标则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确
- 活动：
- 环境准备
- 对象选择
- 活动实施
- 结果分析
- 经验
- 项目管理应当保持适当的节奏，这就需要准确的估算、动态可工作的计划指导以及实时的跟踪和调整。
- 工作分解结构（Work Breakdown Structure，WBS）
- WBS 定义：把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
- 创建 WBS 方法：
- 识别和分析可交付成果及相关工作
- 确定工作分解结构的结构与编排方法
- 自上而下逐层细化分解
- 为工作分解结构组成部分制定和分配标志编码
- 核实工作分解的程度是必要且充分的
- 检查标准：
- 最底层要素不能重复
- 所有要素必须清晰完整定义
- 最底层要素要有责任人，来估算进度和成本
- 最底层要素是实现目标的成分必要条件
- 范围管理：包括确保项目做且只做成功完成项目所需的全部工作的各过程
- 开发策略与计划：明确每个产品组件的获得方式与顺序
- 生命周期模型（pp.12）
- V 字形：对应
- 需求调查 系统测试
- 需求开发 集成测试
- 结构设计 接口测试
- 详细设计 单元测试
- 编码调试
- V 字形：对应
- 日程计划
- 估算规模、估算资源、规划日程
- 质量计划
- 应当确定需要开展的质量保证活动
- 包括个人评审、团队评审、单元测试、集成测试、系统测试以及验收测试等
- 需要解决的关键的问题是该开展哪些活动，以及这些活动开展的程度，如时间、人数和目标分别是什么
- 风险计划
- 在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目产生的负面影响
- 风险管理分为两部分：
- 风险识别
- 风险应对
- 挣值管理方法（EVM）
- 采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量
- BAC 表示按照 PV 值的曲线，当项目完成的时候所需预算或者时间
- 成本差异 CV = EV - AC
- 成本差异指数 CPI = EV/AC
- 日程偏差 SV = EV – PV
- 日程偏差指数 SPI = EV/PV
- 预计完成成本 EAC = AC + (BAC - EV) / CPI = BAC / CPI
- 局限性
- EVM 一般不能应用软件项目的质量管理
- 需要定量化的管理机制，就使其在一些探索型项目以及常用的敏捷开发方法中的应用受到限制
- EVM 完全依赖项目的准确估算，然而在项目早期，很难对项目进行非常准确的估算
- 里程碑评审
- 往往是指某个时间点，用以标记某项工作的完成或者阶段的结束
- 内容：相关的承诺、执行计划、当前的状态讨论、面临的风险讨论
- 其他计划跟踪：日程计划跟踪、承诺计划跟踪、风险计划跟踪、数据收集计划跟踪、沟通计划跟踪
- 纠偏活动的管理
- 偏差原因分析
- 纠偏措施定义
- 纠偏措施管理
- 项目总结的意义
- 提供一个系统化的方式来总结经验教训、防止犯同样的错误、评估项目团队绩效、积累过程数据等。提供给项目团队成员持续学习和改进的机会。
- 过程：准备、总结、报告阶段
- PMBOK
- 范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整合管理 ⑨ 大知识领域。
- TSP 总结过程阶段
- 准备阶段
- 过程数据评审阶段
- 人员角色评价阶段
- 总结报告撰写阶段
- 配置管理的基本概念
- 配置项
- 基线
- 配置管理简介
- 配置管理的目的是建立与维护工作产品的完整性
- 配置管理活动（pp.6）
- 度量与分析：
- 意义：可以支持如下的项目管理活动：客观的估计与计划 / 根据建立的计划和目标，跟踪实际进展 / 识别与解决过程改进相关议题 / 提供将度量结果纳入未来其他过程的基础
- 度量与分析活动（pp.8）
- GQM 方法
- Goal、Question、Metric
- Sample：
- G：确保稳定性、可预测性的开发过程来满足计划的里程碑
- Q：我的项目是否按照计划的轨迹前进，计划的里程碑都能实现吗
- M：软件项目开发工作的挥发性（分支、流、统一变更管理活动）
- 决策分析
- 建立决策分析指南
- 建立评价标准
- 识别候选方案
- 选择评价方法
- 评价候选方案
- 选择解决方案
- 自主团队
- 特点：
- 自行定义项目的目标
- 自行决定团队组成形式以及成员的角色
- 自行决定项目的开发策略
- 自行定义项目的开发过程
- 自行制定项目的开发计划
- 自行度量、管理和控制项目工作
- 外部环境：
- 启动阶段得到管理层的支持
- 进展中获得管理层的支持
- 特点：
- TSP 对自主团队的支持
- PSP 个人技能培养 → 团队成员
- TSP 团队组建过程 → 团队规范
- TSP 团队工作过程 → 团队管理
- TSP Launch
- 建立产品目标和业务目标
- 角色分配、小组目标定义
- 开发流程定义和策略选择
- 整体计划
- 质量计划
- 个人计划
- 风险评估
- 准备向管理层汇报计划
- 汇报计划
- Launch 总结
- 团队文化和激励
- 人的需求层次：
- 生理需求
- 安全感
- 爱和归属感
- 获得尊敬
- 自我实现
- 人的需求层次：
- TSP 角色
- TL（项目组长，Team Leader）
- 计划经理
- 开发经理
- 质量经理
- 过程经理
- 支持经理