软件过程与质量索引

软件过程与质量索引.md

软件过程与质量索引

前言、图例

PPT 本身就很乱……我尽量整理了。

感觉做 ppt 的人脑子是一团浆糊，很多地方逻辑乱七八糟的，标题层级也不一样，完全没有他做的软件过程标准那么精巧。或许这就是软件开发的常态吧（笑）

这篇文档说是索引，其实是介于索引和知识点总结之间的一个东西。希望它能对你的考试有所帮助吧。记得多用 Ctrl+F 查找。

-- Rynco, 2020.06.16

基本格式是 {页码} {知识点} ，知识点可能持续多行，直到下一个页码出现为止。

P{n} 表示幻灯片的第 n 页（或从第 n 页开始的内容）。

P{n1}--{n2} 表示幻灯片的第 n1--n2 页（不常见）。

{m}/P{n} 表示该讲第 m 段 PPT 的第 n 页，同一个小标题下之后的所有页面都是该段 PPT 的内容，不再标识 PPT 段落。

第一讲 概述

P2 影响软件变化的三个主要方面：应用基础、正确性基础、实现基础

P3--10 软件工程 1950 -- 2000

P13 VUCA

• Volatility 易变性
• Uncertainty 不确定性
• Complexity 复杂性
• Ambiguity 模糊性

P14 软件工程学科范畴

P20 应用情况、教育

第二讲 基本概念及标准

P2 质量概述

P2 戴明管理十四条

P3 Crosby 零缺陷质量观：一个中心，两个基本点，三个要素，四项原则

P4 朱兰质量二元定义

P5 质量标准的相对性

P5 软件质量

P6 定义：功能性、可靠性、易用性、效率、可维护性、可移植性

P7 影响质量的因素

• 传统观点：过程、技术、工具
• 现代观点：过程、技术、组织

P8 软件过程

P8 基本概念

• 过程是针对一个给定目标的一系列运作步骤，是在过程环境下的一系列有序活动
• 活动是过程对象一次状态改变，也叫过程步
• 任务是完成活动所需要的原子动作

项目计划是某个软件过程模型的实例

立项、需求分析、设计、编码、测试、交付、维护、退役

管理活动、质量保证、环境基础设施配置、文档管理

P9 生存期过程标准 ISO12207

第三讲 主要活动-需求工程 (1, 2)

1/P1 需求工程导论

1/P3 需求工程的原因分析

P3 软件的模拟特性

软件的三种类型：纯工具性软件/专业用户、纯工具性软件/普通用户、应用型软件

软件的模拟特性、冗余功能

它必须以准确的现实理解为基础，在现实的制约下对外实施影响，进而解决问题。

P3 软件的分析活动

P4 需求问题的技术原因分析

非技术性和社会性因素

结构化分析和面向对象分析有一定的先天缺陷

以企业为中心的软件反映了软件规模日益扩大

1/P5 需求工程

需求工程是软件工程的一个分支。包括的基本活动：

• 需求开发
  • 需求获取
  • 需求分析
  • 需求规格说明
  • 需求验证
• 需求管理

与系统工程的关系

• 系统需求开发：需求获取 -> 需求分析

• 软件需求开发：系统设计 -> 软件工程 (-> 需求阶段)

• 必要性特征：

  • 软件开发是一个工程问题
  • 计算机应用于现实世界的广泛性

• 重要性特征：

  • 处理范围广泛
  • 设计诸多参与方
  • 处理内容多样
  • 处理活动互相交织
  • 处理结果要求苛刻

1/P6 需求工程师

P6 知识要求

P6 技能要求

1/P7 需求基础

P7 需求的定义

用户为了解决问题或达到某些目标所需要的条件或能力；系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；前两者的文档化表述。

P7 理解需求内涵

P7 问题域与解系统

实体和状态构成了问题解决的基本范围，称为问题域；软件系统通过影响问题域能够帮助人们解决问题，称为解系统。映射的共同知识称为共享现象。

P8 需求与规格说明

需求是用户对问题域中的实体状态或事件的期望的描述。

直接需求、间接需求、不切实际的期望

P8 问题域特性

P8 关系

2/P1 需求分类

功能需求、性能需求、质量属性、对外接口、约束

硬件需求、软件需求、其他需求

P1 需求的层次性

• 目标 - 业务需求
• 任务 - 用户需求
• 系统行为 - 系统行为需求

P1 业务需求

目标、特性、前景、范围

P2 用户需求

直接用户、间接用户

P2 系统行为需求

P3 建模与分析活动

P3 性能需求

P3 质量属性

P4 对外接口

P4 约束

2/P5 需求开发的路线

• 问题分析和背景分析
• 需求获取
• 需求分析
• 文档化和验证

2/P5 优秀需求特性

• 完整性
• 正确性
• 精确性
• 可行性
• 必要性
• 无歧义
• 可验证

2/P6 常见需求定义错误

• 没有反应真实需要
• 模糊和歧义的要求
• 明显的信息遗漏
• 不必要

2/P7 需求工程过程

P7 活动

P7 需求获取

P8 需求分析

P8 需求规格说明

P9 需求验证

P10 需求管理

P9 并发和迭代行

P10 实践方法的应用

2/P12 需求工程过程

第三讲 主要活动 (3, 4)

3/P1 需求分析 需求管理

P1 主要活动、主要阶段

P1 系统需求分析、软件需求分析

P2 变更管理过程、变更的记录与跟踪、跟踪分类、跟踪矩阵

3/P3 软件设计

设计目标、设计过程、设计关键、设计层次划分

3/P3 编码

软件构造、编码目标

3/P3 软件测试

3/P3 运行 维护

软件维护

维护活动分类：软件更新、矫正性维护、适应性维护、完善性维护

3/P3 项目管理

P4 主要活动

项目启动、项目规划、项目实施、项目收尾

P4 开发计划

确定工作范围、识别资源、项目评估、外购决策、项目计划

P5 风险管理

P6 场景

• 并发更新
• 防止未授权的改变或删除
• 跟踪需求变更请求和程序变更请求
• 取消需求变更
• 显示相关变化
• 收集当前系统的所有原始资料、文档和其他信息

P6 软件配置管理

P6 定义

P6 软件配置、软件配置项

P7 基线：经过正式评审和认可的一组软件配置项

P7 再生能力、可追踪能力、报告能力

P8 配置库

P8 配置管理流程

P9 配置项标识

P9 版本控制

P10 配置管理商业理念：恰好够用

P11 配置管理规划

P11--12 配置控制

变更请求的 管理、状态、评估、批准和裁决、实现

P13 状态簿记

P14 配置审计

P15 常用工具：SourceSafe、CVS、ClearCase、Git

4/P1 验证与确认 (V&V)

P1 概述

P2 建立完整性等级

P4 组织 V&V 工作

P5 总体原则

P5-6 管理、获取、供应、开发过程

创建 SVVP

4/P7 软件审查

P7--8 概述

P8--10 审查过程

P11 数据收集

P11 监控

4/P12 软件质量保证

P12 概述

P13 软件过程保证

P13 软件产品保证

P13--14 SQA 程序和报告

4/P14 软件文档

第四讲 过程模型

1/P1 主要活动：需求设计与分析、设计、编码、测试、运行与维护、软件项目管理、软件配置管理、软件验证与确认、联合软件评审、软件质量保证、软件文档

P1 软件生存周期模型定义：一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，其中这些过程、活动和任务覆盖了从该系统的需求定义到系统的使用终止。

P1 软件开发生存周期模型的内在基本特征

1/P2 编码修正模型

1/P2 瀑布模型

P3 V 模型

P4 H 模型

P4 瀑布模型的假设：一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现完成之前产生。

1/P4 增量模型

P4 增量模型的假设：需求可以分段，成为一系列增量产品。每一增量可以分别开发。

1/P6 演化模型

显式地把增量模型扩展到需求阶段。

1/P7 螺旋模型

1/P8 原型构造在生存周期模型中的应用

1/P8 生存周期模型中并发的作用

1/P8 商业组件 复用的作用

2/P1 统一过程模型（RUP）

P1 RUP 的目标：按照预先制定的时间计划和经费预算，开发出高质量的软件产品以满足最终用户的需求

P1 RUP 捕获的 6 项最佳商业实践

P1 RUP 三大特点：用例驱动、以架构为中心、迭代和增量开发

P2 RUP 的整体架构、迭代模型

P3 RUP 的核心元素

P4 迭代开发中的困难与保障

2/P5 软件生存周期过程模型的三个层次

第五讲 Infosys 模型

P1 需求

需求的管理与跟踪，与第三讲第二部分一开头的完全一致，可能是整理 PPT 的时候乱了

P3 高层设计

P4 详细设计

P6 构建 单元测试

P7 集成计划 集成测试

P7 系统测试计划 系统测试

P8 文档

P9 验收 安装

P10 维护 支持

第六讲 软件过程的建立与管理

P1 过程的建立

P1 软件过程定义

P1 确定软件模型 (一个组织应使用尽可能少的软件过程模型)

P2 确定活动

P2 确定活动间的关系

P2 将每个活动的有用信息文档化

P3 剪裁过程文档化

P3 改善过程文档化

P4 过程获得认可并培训员工

P4 不断地使用和改善过程

P4 软件过程的监控

P4 监控过程的执行

P5 过程变更的处理

P5 过程变更的实施

P6 软件过程基础数据

P6 PDB

P6 Process Database (PDB，软件过程数据库)

P7 过程能力基线

P7 过程资产

• 检查表
  • 活动
  • 评审
• 指南
• 模板

P7 Body Of Knowledge

知识体，BOK

第七讲 软件生命周期质量关注点

1/P1 QA工作的六个策略

P1 宽而广

P1 窄而深

P2 关键路径

P2 TOP3

P2 前宽后窄

P2 核心工件

1/P3 需求开发与管理 的质量关注点

P3 需求获取

P4 需求分析

P5 需求评审

P6 需求变更

1/P7 软件开发 的质量关注点

P7 软件走查

P7 意义

P7 最佳实践

P7--8 示例

1/P9 软件测试 的质量关注点

P9 单元测试、集成测试与系统测试

P9 测试阶段包含的活动

P9 缺陷分析

P10 示例

2/P1 项目管理基本概念

P1 定义：为创造独特的产品、服务或结果而进行的一次性努力

为什么：为实现共同的目标，需要行之有效的协作方式

特征：临时性、独特性、不确定性

P1--2 项目管理十大知识域

项目整合管理、范围管理、进度管理、费用管理、质量管理、资源管理、沟通管理、风险管理、采购管理、利益相关当的需求和期望管理

P3 项目生命周期及其管理

2/P3 项目管理基本概念

P3 启动阶段

P3 规划阶段

P3 实施阶段

P3 收尾阶段

P4 三重制约

P4 五大过程

P4 QA 关注点

2/P5 软件项目策划 的管理关注点

P5 组织结构图

P5 WBS 分解（工作分解结构，Work Breakdown Structure）

P6 软件项目估算

P7 生命周期模型定义 项目阶段 里程碑

P8 制定详细进度计划

P8 软件项目计划评审

2/P9 实施与收尾 的管理关注点

P9 风险管理

P9 识别风险或机会的方法：分类法、头脑风暴法、调查问卷法、检查单法、WBS 驱动法

P10 三个维度 优先级 持续风险管理模型

P10 十大常见风险

P11 项目沟通

P11 沟通与回报机制

P11 沟通计划

P11 高效会议

P11 项目监控

P11 监控手段

P12 每日站会 燃尽图

P12 周例会 看板

P12 里程碑评审

P13 项目数据分析

工作日志

P14 变更管理

变更源头、变更影响分析、变更流程

变更控制委员会

P15 项目验收

P15 项目总结

2/P16 QA 工作难点

2/P16 QA 工作方针

2/P16 QA 工作方法

2/P16 QA 工作原则

2/P17 知识体系 技能

第八讲 组织与敏捷

P1 计划驱动的过程

P1--2 特征

P2 面临的问题

P2 管理思想

P3 有效的组织结构与管理

P3 组织结构基因

P3 部件冗余结构：人是可替换的部件。控制和命令、专制、官僚。

P3 功能冗余结构：在个人身上建立更多的技能和功能。高绩效的、民主、自主。

P3 功能冗余结构的六条标准

P3 功能冗余扁平结构

P4 X/Y 理论

P4 X 理论：懒惰、低能。规范控制。

P4 Y 理论：聪明、有潜力。激励支持。

P4 科学管理：提高效率、降低成本

计划和改进工作与正常工作分开。

项目经理的五项职责：计划、组织、协调、指挥、控制

P5 组织文化演进：部件冗余+X -> 部件冗余+Y -> 功能冗余+Y

P5 敏捷思维

P10 敏捷思维：尊重、协作、改进和学习周期、为所有权自豪、专注于交付价值、有能力适应改变

P11 VUCA 乌卡时代

团队 - 建立互信、共享目标

建立扁平的组织架构，信息共享

科学赋能，决策去中心化

主动、敏捷、洞察、预见

第九讲 精益与看板

P2 丰田生产方式

P2 精益思想：有效组织人类活动的一个新的思维方法。目标是减少浪费，更多地交付对个人和社会有用的价值。

P2 思想基础：交付价值、减少浪费、尊重人、改进无涯；关注接力棒而不是跑者、停生产线。

P3 两大支柱：准时化、自动化

P3--5 准时化（看板）

P5--6 自动化：内建质量、停止并修正、持续改善的基础

P6 原则步骤

P6 精益价值观

P7 精益软件开发

P7 原则：消除浪费、增强学习、内建质量、推迟承诺、快速交付、尊重员工、整体优化（系统思维）

P8 看板核心实践

P8 可视化工作流

P8 显式化工作流程

P8 限制在制品数量（核心机制）：加速价值流动、暴露问题

P9 度量和管理流动

P9 协同改进

P10 看板应用实例

P14--16 分析看板

P12 看板方法总结

第十讲 敏捷概述

P1 定义

敏捷不是：方法论、特定开发软件的方式、流程的框架

敏捷是一组价值观和原则

P2 价值观

个体和互动 > 流程和工具

可用的软件 > 详尽的文档

与客户合作 > 在合同上交涉

响应变化 > 遵循计划

P2--4 原则

1. 最优先要做的是尽早、持续地交付有价值的软件，让客户满意。
2. 欣然面对需求变化，即使在开发后期。敏捷过程利用变化为客户维持竞争的优势。
3. 频繁地交付可工作的软件，从数周到数月，交付周期越短越好。
4. 在团队内外，面对面交谈是最有效，也是最高效的沟通方式。
5. 在整个项目过程中，业务人员必须和开发人员每天都在一起工作。
6. 以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好。
7. 可工作的软件是衡量进度的首要标准。
8. 敏捷过程倡导可持续开发。
9. 坚持不懈的追求技术卓越和良好的设计，以此增强敏捷的能力。
10. 简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。
11. 最好的架构、需求和设计来自自组织的团队。
12. 团队定期反思如何提升效率，并依此调整自己的行为。

P4 应用敏捷

P6 团队如何变得敏捷

P6 敏捷实践

第十一讲 极限编程

极限编程 (XP, Extreme Programming)

P1 概述

极限编程是一套软件开发方法，由一系列与开发相关的规则、规范和惯例组成。其规则和文档较少，流程灵活，易于小型开发团队使用。XP认为软件开发有效的活动是：需求、设计、编码和测试，并且在一个极限的环境下使它们发挥到极致，做到最好

• 极限的工作环境应付变化的环境
• 极限的需求
• 极限的设计
• 极限的编程
• 极限的测试
• 短期交付

P2 XP 过程模型

P2 需求（用户故事）

P3--4 发布规划（范围、资源、实践、质量）

P3 发布规划 预测项目速度 版本发布计划

P3 发布规划 人员职责划分

P4 架构隐喻

P5 迭代开发

P5 测试驱动的开发

P5 验收测试

P6 小发布

P6 迭代过程的细化

P6 迭代规划

P7 开发过程的细化

P7 站立会议（站着开会、早会）：加强内部交流

P7 集体拥有代码：双人编程、测试驱动、残酷重整、人员轮换、故事墙

P8 燃尽图

P9 集体拥有代码过程的细化

P9 项目管理

P10 独立宣言：Value, Customer, Uncertainty, Individuals, Team, Context

P10 项目管理 领导风格

P10--11 小结

第十二讲 用户故事与估算

P2 用户故事

P2 概念

• 用来确认用户和用户需求的简短描述
• 描述了对用户、系统和软件购买者有价值的功能

P2 三要素：作为 …… 我想要 …… 以便于 ……

P2 写用户故事

P2 3C 原则：卡片、交谈、确认

P3--5 INVEST 原则：可独立开发的、可协商的、有价值的、大小可估算的、粒度合适的、可测试的

P5 分级：Epic 史诗、Theme 主题、Story 故事、Task 任务

P5--6 实现约束

P6 优先级

P6 MoSCoW 原则：必须有、应该有、可以有、不会有

P6 验收标准

P6--7 标准（代表外部质量）：AC1 描述，在 (given) 前提条件下，当 (when) 做什么事情，会发生 (then) 预期结果

P8 职责划分

P8 估算

P8 估算用户故事的大小 方法

1. 选择单位（理想天、故事点）
2. 理解故事
3. 估计
4. 一致同意

P9 实践

将大小和速度分开

P9 使用用户故事的原因

P9--10 传统需求与用户故事描述的需求的不同

P10 敏捷开发的需求敏捷化手段

P11 贯穿整个产品实现流程

P11 提高沟通效果

P11 适合于迭代开发 鼓励延迟细节 传播隐性知识

---

CC-BY. 2020 Rynco