软件质量与管理2023 期末复习

发表于 更新于 分类于 阅读次数： Waline： 本文字数： 6.9k 阅读时长 ≈ 13 分钟

软件开发四大本质难题

  1. 不可见性（不因项目而异）、复杂性、可变性、一致性

软件发展三大阶段

  1. 软硬件一体化：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更；measure twice cut once、code and fix；

  2. 软件成为独立的产品：摆脱了硬件的束缚、功能强大、需求多变、兼容性要求、来自市场的压力；形式化方法、结构化程序和瀑布生命周期模型、成熟度模型；

  3. 网络化和服务化：功能更复杂 、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方式的变化、进一步的服务化和网络化、盛行开源和共享文化；迭代式开发、敏捷开发、开源软件开发方式、DevOps；

  4. 管理的三大关键要素：目标、状态、纠偏

  5. 软项目管理的三大目标：成本、质量、工期

生命周期模型

  1. 生命周期模型是对一个软件开发过程的人为划分

  2. 生命周期模型是软件开发过程的主框架，是对软件开发过程的一种粗粒度划分

  3. 生命周期模型往往不包括技术实践

DevOps

  1. 开发运维一体化

  2. 方法论的基础是软件敏捷开发、精益思想和看板 KanBan 方法

  3. 以领域驱动设计为指导的微服务架构方式

  4. 大量虚拟化技术的使用

  5. 一切皆服务 XaaS 的理念指导

  6. 构建了强大的工具链，支持高水平自动化

过程改进模型

过程改进模型：CMMI

  1. initial：开发相对混乱，没有过程概念，依赖个人英雄主义，救活文化盛行；
  2. managed：项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等；
  3. defined：公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法在公司间流传；
  4. quantitatively managed：构建预测模型，以统计过程控制的手段来管理过程；
  5. optimizing：继续应用统计方法来识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题；

过程改进模型：PDCA

image-20240102134036937
  1. 分析现状，找出问题
  2. 分析影响质量的原因
  3. 找出措施
  4. 拟定措施计划
  5. 执行措施，执行计划
  6. 检查效果，发现问题
  7. 总结经验，纳入标准
  8. 遗留问题转入下期PDCA循环

过程改进模型：IDEAL

image-20240102133953844
  1. initiating 初始
  2. diagnosing 诊断
  3. establishing 建立
  4. acting 执行
  5. leveraging 调整

过程管理模型：ISO/IEC 1504 （SPICE）

软件过程框架：RUP

敏捷开发

敏捷宣言

  1. 个人和互动 胜过 工具和流程
  2. 可以工作的软件 胜过 详尽的文档
  3. 客户合作 胜过 合同谈判
  4. 响应变化 胜过 遵循计划
  5. 尽管认为右边有价值，但更重视左边的价值

敏捷开发方法：极限编程 XP

  1. 客户作为开发团队的成员
  2. 短交付周期
  3. 结对编程
  4. 测试驱动开发
  5. 持续集成
  6. 重构
  7. 每周工作时间 <=40小时

敏捷开发方法：Scrum

image-20240102133937507
  1. Scrum中的文档：产品订单、冲刺订单、燃尽图
  2. Scrum中的角色：产品负责人、Scrum Master、开发团队
  3. 产品订单（product backlog)：整个项目的概要文档，包含了已划分优先等级的、项目要开发的系统或产品的需求清单，是动态的。
  4. 冲刺订单（sprint backlog)：细化了的文档，包含了团队如何实现下一个冲刺的需求信息。
    1. 哪些产品订单会加入一次冲刺由冲刺计划会议决定。会议中，产品负责人告诉开发团队他们需要完成产品订单中的哪些订单项，开发团队决定在下一次冲刺中承诺完成多少订单项。
    2. 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog)，这意味着在一个冲刺中需求是被冻结的。
  5. 燃尽图（burn down chart)

敏捷开发方法：Kanban

  1. 精益生产（丰田制造法）的具体实现
  2. 可视化工作流、限定 WIP、管理周期时间
  3. 马丁提出了微服务架构

其他开发方法：Clean Room、Gate

团队动力学

团队动力学：激励方式

  1. 威逼
  2. 利诱
  3. 鼓励承诺

团队动力学：马斯洛的需求层次理论

  1. Physiological 生理需求
  2. Safety 安全感
  3. Social 爱和归属感
  4. Esteem 自尊
  5. Self-Actualization 自我实现

团队动力学：海兹伯格的激励理论

  1. 内在因素：成就感、责任感、晋升、被赏识、认可等；
  2. 外在因素：工作环境、薪金、工作关系、安全等；

团队动力学：麦克勒格的X、Y-理论

  1. X－理论：⼈性本恶，独裁式的管理⻛格，⽤⻢斯洛的底层需求（⽣理和安全）进⾏激励
  2. Y - 理论：⼈性本善，⺠主式的管理⻛格，⽤⻢斯洛的⾼层需求（⾃尊和⾃我实现）进⾏激励

团队动力学：期望理论

  1. M = V * E
  2. 相信他们的努⼒很可能会产⽣成功的结果（V）
  3. 相信⾃⼰因为成功⽽得到相应的回报（E）

估算

项目规模估算：估算要点

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

通用计划框架

image-20240103155049343

项目规模估算：PROBE方法

  1. 设置合理的代理作为精确度量和早期规划需要的度量之间的桥梁：相对大小矩阵
  2. 相对大小而非绝对大小
image-20240103134450706

PSP质量管理

PSP质量管理：质量策略

  1. 首先确保基本没有缺陷，然后再考察其他的质量目标。
  2. 使用缺陷管理来代替质量管理
  3. 高质量的产品也就意味着组成软件产品的各个组件基本无缺陷
  4. 各个组件的高质量是通过高质量评审来实现的

PSP质量管理：质量路径 Quality Journey

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

PSP质量控制指标

PSP质量控制指标：Yield

  1. Phase Yield = 100 * 某阶段发现的缺陷个数 / （ 某阶段注入的缺陷个数 + 进入该阶段前遗留的缺陷个数）

  2. Process Yield = 100 * 第一次编译前发现的缺陷个数 / 第一次编译前注入的缺陷个数

  3. Yield 可用于制定质量计划并且在项目执行阶段用于进行风险监控、预测、识别以及控制；

  4. Yield 的计算是一种事后的质量控制手段，而且除非发现了所有的缺陷，否则很难非常精确地进行计算；也就是Yield 是估计度量，不可能精确度量；

    image-20240102160151666

  5. 上图第一个消除步骤是需求评审，第二个消除步骤是设计评审，第三个消除步骤是测试评审；

PSP质量控制指标：A/FR

  1. A/FR = PSP质检成本 / PSP失效成本，
  2. 质检成本 = 设计评审时间 + 代码评审时间，
  3. 失效成本 = 编译时间 + 单元测试时间；
  4. 理论上，A/FR 值越大，意味着质量越高，但 A/FR 值过大说明评审过多，则开发效率低下，因此 PSP 中 A/FR 期望值为 2.0

PSP质量控制指标：PQI

  1. 设计质量：设计时间应该大于编码时间，min(设计时间/编码时间,1)

  2. 设计评审质量：设计评审的时间应该大于设计时间的 50%，min(2*设计评审时间/设计时间,1)

  3. 代码评审质量：代码评审时间应该大于编码时间的 50%，min(2*代码评审时间/编码时间,1)

  4. 代码质量：代码的编译缺陷密度应当小于 10 个/千行，min(20/(编译缺陷密度+10),1)

  5. 程序质量：代码的单元测试缺陷密度应当小于 5 个/千行，min(10/(单元测试缺陷密度+5),1)

  6. PQI为以上五个质量乘积，0.4以上即可；

  7. PQI 可以预测和度量，PQI 可以用作质量规划和过程改进；

PSP质量控制指标：Review Rate

  1. 代码评审速度小于 200 LOC（代码行）/h
  2. 文档评审速度小于 4 page（文档采用页）/h

PSP质量控制指标： DRL

  1. BW以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是 DRL
  2. DRL只能度量，不能预测

PSP设计模板

PSP设计模板

  1. 操作规格模板 OST：描述系统与外界的交互，用于场景描述：也就是”用户“与”待设计系统的正常情况和异常情况下的交互。
  2. 功能规格模式 FST：描述系统的对外接口，是一种静态信息的展现。
  3. 状态规格模式 SST：可以精确定义程序的所有状态、状态之间的转换以及伴随着每次状态转换的动作。
  4. 逻辑规格模式 LST：可以精确描述系统的内部静态逻辑。

PSP设计模板：与UML对比

  1. OST：UML用例图、时序图

  2. FST：UML 类图，但方法的行为类图没有描述

  3. SST：UML 状态图，但是 SST 中描述的关于状态、状态转换条件以及状态转换中的动作没有对应的 UML 图示方法。

  4. LST：没有对应图

  5. UML 中的时序图和类图所描述的类之间的关系以及对象之间的交互信息在4 个设计模板中没有对应的内容；

PSP设计模板：动静内外

  1. 外部动态：OST,FST
  2. 外部静态：FST
  3. 内部动态：SST
  4. 内部静态：LST

PSP设计验证

PSP设计验证方法：状态机验证

  1. 检查状态机，消除死循环和陷阱状态

  2. 检查状态转换，验证完整性和正交性

  3. 评价状态机，检验是否体现设计意图

PSP设计验证方法：符号化验证

  1. 适合复杂的计算过程（？），不适合于有复杂逻辑的场合；
  2. 纯手工验证方法容易引入错误；
  3. 唯一一种提供全面设计验证的手段；

PSP设计验证方法：执行表验证

  1. 可用于复杂逻辑的验证；
  2. 每次只能验证一个用例；手工验证比较耗时，容易引入错误。

PSP设计验证方法：跟踪表验证

  1. 是执行表验证的补充，可以每次验证多个用例

PSP设计验证方法：正确性验证

团队工程开发

需求分类

  1. 客户需求：描述的是客户的期望，是客户解决问题的愿望；
  2. 产品需求：描述的是开发团队所提供的解决方案。即针对上述的客户需求，开发团队设计出一个可以帮助客户解决工作当中碰到的问题的方案。
  3. 产品组件需求：描述的是组成产品的各个组件的需求规格。与产品需求相比，这是更低层次，更为细致的描述了上述解决方案中的某个组件的功能、性能与形式等。

需求开发的步骤

  1. 需求获取：采用”诱导“式方法获取客户的显式需求和隐式需求
  2. 需求汇总
  3. 需求验证
  4. （需求文档制作）：需求开发工作完成的一个基本标志是形成了一份完整的、规范的、经过评审的需求规格说明书。

团队设计：设计标准

  1. 命名规范
  2. 接口标准
  3. 系统出错信息
  4. 设计表示标准

团队设计：复用性支持

  1. 复用接口标准
  2. 复用文档标准
  3. 复用质量保证机制

集成策略选择：大爆炸集成策略

  1. 将所有已经完成的组件放在一起进行一次集成
  2. 优点：需要很少的测试用例
  3. 缺点：需要所有有待集成的组件质量非常高，否则会出现难以定位缺陷位置的问题，从而消耗很多测试时间；另外，系统越复杂，规模越大，问题越突出

集成策略选择：逐一添加集成策略

  1. 与大爆炸集成策略相反，采取一次添加一个组件的方式进行集成
  2. 优点：很容易定位缺陷位置，特别是在产品组件质量不高的情况下，每次集成之前都有着坚实的质量基础
  3. 缺点：需要测试用例非常多；存在有大量的回归测试，测试时间成本大

集成策略选择：集簇集成策略

  1. 是对逐一添加集成策略的改进，把有相似功能或者有关联的模块优先进行集成，形成可以工作的组件，然后以组件为单位继续较高层次的集成
  2. 优点：可以尽早获得一些可以工作的组件，有利于其它组件测试工作的开展
  3. 缺点：过于关注个别组件，而缺乏系统的整体观，不能尽早发现系统层面的缺陷

集成策略选择：扁平化集成策略

  1. 优先集成高层的部件，然后逐步将各个组件、模块的真正实现加入系统。即尽快构建一个可以工作的扁平化系统
  2. 优点：可以尽早发现系统层面的缺陷
  3. 缺点：为了确保完成的系统，需要大量的打“桩”（stub），即提供一些直接提供返回值的伪实现。这种方式往往不能覆盖整个系统应该处理的多种状态

验证与确认 V & V

  1. 验证（Verification)活动也是检验获得的产品和产品组件能不能满足各自事先定义好的需求规格；单元测试、集成、详细设计评审；

  2. 确认（Validation)活动是为了确保产品可以满足客户的需求以及实际操作场景的要求；验收测试、需求评审；

团队项目规划

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

  1. 提供了项目范围基线，是范围变更的重要输入。
  2. 可以展现项目整体观，使得项目团队成员可以集中注意力实现项目的目标上。
  3. 为开发项目提供了一个整体框架，防止遗漏项目的可交付成果。
  4. 使得项目中各个角色的责任更明确，帮助项目团队的建立和获得项目成员的承诺。
  5. 为评估和分配任务提供具体的工作包的定义，工作包可以分配给项目某个成员或者另一个团队。
  6. 是进行估算和编制项目日程计划的基础。
  7. 可以帮助项目团队理解工作内容，分析项目的风险。

TSP九次会议

image-20240102221907258

项目跟踪：挣值管理（EVM）

image-20240102232458769
  1. 项目的挣值管理方法是用来客观度量项目进度的一种项目管理方法
  2. 简单实现：这种方式仅仅关注进度信息。在实现时，首先需要建立WBS，定义工作范围；其次为WBS中每一项工作定义一个价值（PV）；最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作。常用规则分别为0-100规则和50-50规则，前者只有当某项任务完成时，该任务的PV值将转化成EV值；后者只需要开始某项任务，即可以赋原PV值的50%作为EV值，完成时，再加上另外的50%。而实际完成的工作所需成本AC不对EV值产生任何影响。
  3. 中级实现：在简单实现的基础上，加入日程偏差的计算。
  4. 高级实现：在中级实现的基础上，还需要考察项目的实际成本。
  5. SV = PV - EV; SPI = EV/PV; CV = AC - EV; CPI = EV/AC;
  6. 预计完成成本EAC = BAC / CPI

挣值管理的局限性

  1. 一般不能应用软件项目的质量管理。
  2. 需要定量化的管理机制，这就使得在一些探索型项目以及常用的敏捷开发方法中的应用受到限制。
  3. 完全依赖项目的准确估算，然而在项目早期，很难对项目进行非常准确的估算。

TSP经典角色

TSP经典角色：总结

  1. 项目组长
  2. 计划经理：开发完整的、准确的团队计划和个人计划；每周准确的报告项目小组状态
  3. 开发经理：开发优秀的软件产品；充分利用团队成员的技能
  4. 质量经理：项目团队严格按照质量计划开展工作，开发出高质量的软件产品；所有的小组评审工作都正常开展，并且都形成了评审报告
  5. 过程经理：所有团队成员准确的记录、报告和跟踪过程数据；所有的团队会议都有相应会议记录。
  6. 支持经理：项目小组在整个开发过程中都有合适的工具和环境；对于基线产品，不存在非授权的变更；项目小组的风险和问题得到跟踪；项目小组在开发过程中满足复用目标
  7. 开发人员

TSP典型角色：项目组长

  1. 项目组长应当建设和维持高效率的团队。

  2. 项目组长应当激励团队成员积极工作。

  3. 项目组长应当合理处理团队成员的问题。

  4. 项目组长应当向管理层提供项目进度相关的完整信息。

  5. 项目组长应当充当合格的会议组织者和协调者。

  6. 你是天生的领导者

  7. 你有能力识别问题的关键并且做出客观的决策

  8. 你不介意偶尔充当“恶人”

  9. 你尊敬你的团队成员

  10. 激励团队成员努力工作

  11. 主持项目周例会

  12. 每周汇报项目状态

  13. 分配工作任务

  14. 维护项目资料

  15. 组织项目总结

TSP经典角色：计划经理

  1. 开发完整的、准确的团队计划和个人计划

  2. 每周准确的报告项目小组状态

  3. 最为重要的一点是，你做事有条理和逻辑

  4. 你对于过程数据非常感兴趣，期待通过每周输入的数据来了解项目当前状况

  5. 你认为计划非常重要，也愿意要求团队成员跟踪和度量他们的工作

  6. 带领项目小组开发项目计划

  7. 带领项目小组平衡计划

  8. 跟踪项目进度

  9. 参与项目总结

TSP经典角色：开发经理

  1. 开发优秀的软件产品

  2. 充分利用团队成员的技能

  3. 你喜欢创造事物

  4. 你愿意成为软件工程师，并且喜欢带领团队开展设计和开发工作

  5. 你具备足够的背景可以胜任设计师的工作，并且可以领导设计团队开展工作

  6. 你熟悉主流的设计工具

  7. 你愿意倾听和接受其他人的设计思想

  8. 带领团队制定开发策略。

  9. 带领团队开展产品规模估算和所需时间资源的估算。

  10. 带领团队开发需求规格说明。

  11. 带领团队开发高层设计。

  12. 带领团队开发设计规格说明。

  13. 带领团队实现软件产品。

  14. 带领团队开展集成测试和系统测试。

  15. 带领团队开发用户支持文档。

  16. 参与项目总结

TSP经典角色：质量经理

  1. 项目团队严格按照质量计划开展工作，开发出高质量的软件产品

  2. 所有的小组评审工作都正常开展，并且都形成了评审报告

  3. 你关注软件产品的质量

  4. 你有评审方面的经验，熟悉各种评审方法

  5. 你有协调组织有效评审的能力

  6. 带领团队开发和跟踪质量计划

  7. 向项目组长警示质量问题

  8. 软件产品提交配置管理之前，对其进行评审，以消除质量问题

  9. 项目小组评审的组织者和协调者

  10. 参与项目总结

TSP经典角色：过程经理

  1. 所有团队成员准确的记录、报告和跟踪过程数据。

  2. 所有的团队会议都有相应会议记录。

  3. 你对过程定义、过程度量非常感兴趣

  4. 你对过程改进非常感兴趣

  5. 带领团队定义和记录开发过程并且支持过程改进。

  6. 建立和维护团队的开发标准。

  7. 记录和维护项目的会议记录。

  8. 参与项目总结。

TSP经典角色：支持经理

  1. 项目小组在整个开发过程中都有合适的工具和环境

  2. 对于基线产品，不存在非授权的变更

  3. 项目小组的风险和问题得到跟踪

  4. 项目小组在开发过程中满足复用目标

  5. 你对于各种开发工具很感兴趣，熟悉各类工具的适用场合。

  6. 你对版本控制工具很熟悉，也熟悉配置管理流程。

  7. 对于本项目所有工具而言，你都是专家。

  8. 带领团队识别开发过程中所需要的各类工具和设施。

  9. 主持配置管理委员会，管理配置管理系统。

  10. 维护软件项目的词汇表。

  11. 维护项目风险和问题跟踪系统。

  12. 支持软件开发过程中复用策略的应用。

  13. 参与项目总结。

TSP经典角色：开发人员