今年骂了一学期rgp，没想到期末什么逆天考点都没考，给分也不错。骂错人了。

期末回忆

（过一个礼拜全忘光了，欢迎补充）

名词解释：配置项，基线，还有两个忘了

大题：自主团队领导特点，敏捷宣言和正确理解，资源估算要点，自主团队和TSP的关系，质量管理要点，V&V和需求联系，大语言模型应用

以下是集体劳动的成果。感谢文档创作者金君、张君、刘君等。

1. 押题

1.1 名词解释

  • 软件工程
  • 软件危机
    • 指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。主要体现有：
      • 软件开发费用和进度失控
      • 软件可靠性差
      • 生产出来的软件难以维护
      • 用户对“已完成”系统不满意现象经常发现
  • 软件过程
    • 软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合。这一组实践往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。
  • 质量计划：解决要开展哪些质量保证活动，以及开展活动的程度。
  • PSP
    • 个体软件过程（Personal Software Process）是一种个体级用于管理和改进软件工程师个人工作方式的持续改进过程，由CMU的Humphrey提出，着重于软件开发人员的个人培训，目的是提升软件工程师的估算、计划和质量管理能力。（TSP：从组织、团队、个人3个层次进行良好的软件工程改善模式，关注改善团队性能；CMM：关注改进组织的能力）
  • 软件项目管理
    • 软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。
  • 软件过程管理
    • 软件过程管理的目的是为了让软件过程在开发效率、质量等方面有着更好性能绩效
  • 软件生命周期
    • 生命周期模型是对软件过程的一种人为划分。
    • 典型生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法等等。
  • 瀑布模型
    • 瀑布模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型。
  • 开发策略与计划
    • 定义：是在产品组件需求基础之上，明确每个产品组件的获得方式与顺序，从而在项目团队内部建立起大家都理解的产品开发策略
  • GQM
    • GQM(Goal Question Metric)是一种应用非常广泛的建立软件度量体系的方法，从管理的目标出发，将目标归纳、分解为度量的指标，并把这些指标提炼成可以测量的值，是一种科学的、系统的思考问题的方式。
  • 二八法则（帕累托法则）
    • 80/20关系提供了一个较好的基准。一个典型的模式表明，80％的产出源自20％的投入；80％的结论源自20％的起因；80％的收获源自20％的努力。
  • 配置项
    • 在配置管理当中作为单独实体进行管理和控制的工作产品集合
    • 典型的可能作为配置项纳入配置管理的工作产品包含过程说明文档、项目开发计划文档、需求规格说明书、设计规格说明书、设计图表、产品规格说明书、程序代码、开发环境，如特定版本的编译器等、产品数据文件、产品技术文件、用户支持文档
  • 基线
    • 基线是一个或多个配置项及相关的标识符的代表，是一组经正式审查同意的规格或工作产品集合，是未来开发工作或交付的基础，而且只能经由严格的变更控制程序才能改变。

1.2 简答

  • 集成策略的定义（4个）和他们各自的特点。
    • 大爆炸、逐一添加、集簇、扁平化
  • AI浪潮中项目管理、质量管理、过程管理的挑战和机遇（预感rgp要考AI）
    • 项目管理：三要素——目标、状态、纠偏。
    • 质量管理：大语言模型进行code review并整合到流水线，帮助进行软件设计（需求分析、架构设计、用例图生成）
    • 过程管理：cmmi四五级可以用深度学习做（请lby细🔒）
  • 典型DevOps实践和方法
    • 方法论基础是敏捷软件开发、精益思想以及看板Kanban方法。
    • 以领域驱动设计为指导的微服务架构方式
    • 大量虚拟化技术的使用
    • 一切皆服务XaaS(X as a Service)的理念指导
    • 构建了强大的工具链，支持高水平自动化
  • 软件发展三大阶段，不同阶段的典型开发方法和实践。
  • PSP度量：时间、缺陷、规模、日程（TSP）

2. 录音记录

  • 课堂提问过的软件工程基本概念

https://k8be38bu17.feishu.cn/minutes/obcn42xr5q4iz87c5pu83475?from_source=finish_transcripting

2.1 过程线

img

  • 什么叫管理：三要素
  • 管理视角：追求什么，学习、效法、复现别人的成功
  • 怎么复现别人的成功呢？做法和别人一样，即需要一个软件过程
  • 传递传播软件过程，把握一个软件过程的精髓——把软件过程简化了说，即生命周期模型（描述软件工程主要特征）
  • 迭代式：前半句话，后半句话（？我上课回答过这个问题呵呵😊）
  • 对瀑布模型的正确理解：根据项目困难程度选择合适的模型….
  • PDCA和IDEAL：软件过程管理的源模型
  • CMM和CMMI：针对特定的软件开发，有一套过程改进/管理参考模型。注意，不是指导项目开发，是指导过程管理（所以CMMI和敏捷对应是一个错误的说法）
  • 软件危机和软件工程：大家应该很清楚了，软件危机产生的三个阶段，上课提到过软件宣言（四句话和下面那句前提），大家的理解有偏差
  • 在不同历史阶段的四大本质难题：复杂、不可见、演变、兼容

2.2 项目管理线

img

  • 项目管理三个目标：成本、质量、工期
  • 团队动力学：知识工作的特点要求我们要实现自我管理。领导者的接力方式，需求层次理论，期望理论，这些都会影响估算
  • 我们还讨论了自主团队
  • 环境：怎么样获得管理层的支持，去平衡自主团队
  • TSP，有哪些决策，哪些职责，九次会议分别解决什么问题
  • SCRUM的角色和职责
  • 估算目的是什么？不追求准确结果，而是达成共识。
  • 抽象的、相对的估算方式：PROBE
  • SCRUM故事点：也是抽象的
  • 通用计划框架：什么是项目计划？质量计划、风险计划、一堆需要在开始定义好的规则
  • 定量管理计划：讲了挺久的
  • 挣值管理体系：最大的优势适应变更
  • 定量管理的跟踪：定好目标之后，实战中x有偏差了如何解决。
  • “很显然，项目管理这条线学习了很多新的东西，从考试的角度来说，考试没说过就考新的。”

2.3 质量管理线

img

  • 质量管理的三要素
  • 面向用户的质量观，可以用来解释质量管理策略和背后的逻辑
  • 用缺陷管理替换质量管理
  • 用户最关注功能正确
  • 实现高质量的手段：评审
  • 个人评审中关键的控制因素：主要是评审速度
  • 为什么在编译之前而不是编译之后做评审？和评审速度、评审目标有关
  • 小组评审最难的事：评审结束后评审本身和评审过程好不好；九宫图、xx估算
  • 质量控制指标，弄清每一个指标的特点和用途
  • 质量路线图：顺序
  • 设计什么？外部内部动态静态
  • 设计的层次，图
  • 记住那张表格那张图可以完整地描述设计是什么
  • 设计评审

2.4 工程技术线

img

  • 客户需求和产品需求：一个是问题，一个是解决
  • 设计关键是自顶向下，实现自底向上
  • 集成注意两点：范围是开始到交付；基本策略四个的优缺点要了解
  • V&V：两个箭头，验证看产品需求有没有得到满足，确认看问题有没有得到解决

2.5 其他

img

前后没有关系

更多会考大家的理解能力，但是我们说很多理解也是建立在记忆的基础上

3. 知识点复习

3.1 过程线

img

3.1.1 软件工程的两大视角

  1. 管理视角：能否复制成功？
  2. 技术视角：是否可以将问题解决得更好？

【2018】软件项目管理和软件过程管理

  1. 软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。
  2. 软件过程管理是为了让软件过程在开发效率、质量等方面有着更好性能绩效。

3.1.2 软件过程&生命周期模型

【2018】【2020-mid】⽣命周期模型与软件过程的区别和联系

  1. (3’)⽣命周期模型是对⼀个软件开发过程的⼈为划分。
  2. (3’)⽣命周期模型是软件开发过程的框架，是对软件开发过程的⼀种粗粒度划分。
  3. (2’)⽣命周期模型往往不包括技术实践。

软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合。这一组实践往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。

软件过程管理的目的是为了让软件过程在开发效率、质量等方面有着更好性能绩效。

广义软件过程

  1. 理论基石：软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。
  2. 包括：技术、人员以及狭义过程。
  3. 同义词：软件开发方法、软件开发过程。
    1. 净室 Clean Room 方法、极限编程方法、Scrum 方法、Gate 方法
      1. clean room 工程过程和 CMM 管理过程互为补充
      2. clean room 比 cmm 更注重质量，更偏向于使用一些数学工具
    2. 更一般的，敏捷软件过程/方法、轻量型过程/方法及重型过程/方法等描述也是恰当的。

生命周期模型

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

  2. 典型生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法等等。

  3. 瀑布模型&迭代式模型

    1. 瀑布模型 教材p10

    2. 瀑布模型成为一个重文档、慢节奏的过程。

    3. 【2020-mid】【2021】我们如何理解瀑布模型

      1. (4’)瀑布模型不是单⼀模型，是⼀系列模型，覆盖最简单场景(过程元素少)到最复杂的场景(过程元素多)
      2. (4’)软件项⽬应该结合实际情况选择合适过程元素的瀑布模型，基本原则是，项⽬⾯临困难和挑战越多，选择的模型应该越复杂
      3. (4’)软件项⽬团队往往低估项⽬的挑战，选择了过于简单的不适⽤的瀑布模型

    4. img

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

考点：前半句是重点还是后半句是重点

A：前半句，把开发、使用过程变成学习，思考方式，目标趋向一致，达成一致的意见，主动降低了需求变更的风险，甲乙方地位稍微拉平

发现 5. 迭代式方式将成为主流方法。

受到应用大环境的影响，当前软件开发所要解决的问题尽管仍然可以归结为经典的 4 个本质难题，但在程度上与过往相比已经有了翻天覆地的变化。某种角度上来说，单一的顺序型开发过程很难在当前的软件开发过程中得到应用，迭代式开发方法已经成为一种主流方法，甚至在未来较长时间内，应该都是主流方法。这种方式鼓励的快速交付和反馈，使得用户、开发者以及作为连接桥梁的软件系统三者之间的互动更加频繁，用户和开发者对当前所需解决的问题以及未来演变的理解可以快速取得一致。显然，这非常适合于当前越来越趋向于网络化和服务化的软件系统开发和使用的发展趋势。

3.1.3 PDCA&IDEAL

【2015B】【2016】请分别描述PDCA模型和IDEAL模型的主要步骤

PDCA模型的步骤：

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

img

IDEAL模型解决了软件组织在各种质量改进环境下的需要。它包括了软件过程改进周期中的五个阶段，IDEAL是代表这五个阶段的单词的⾸字母。

  1. I: Initiating 初始
  2. D: Diagnosing 诊断
  3. E: Establishing 建⽴
  4. A: Acting 执⾏
  5. L: Leveraging 调整

img

3.1.4 CMM&CMMI

CMM：

定义：CMM 是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。

人话：是一个评估模型，主要用于过程改进、过程评估、能力评价

5个等级和而对应的18个过程域如图：

imgimg

xqh博客：

等级一：初始级 Initial

  1. 特点：处于该级别的组织基本上没有健全的软件工程管理制度。
    1. 每件事情都用特殊的方法去做：如果特定工程遇到有能力的管理员和一个优秀的软件开发组来做，则可能是成功的。
    2. 大多数的行动只是应付危机，而非事先计划好的任务。通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。
    3. 软件过程完全取决于当前的人员配置，具有不可预测性。
  2. 要精确地预测产品的开发实践和费用之类重要的项目，是不可能的。

等级二：可重复级 Repeatable

  1. 特点：有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验。
    1. 采取了一些措施，这些措施是实现一个完备过程所必不可缺少的第一步。
      1. 典型措施包括：仔细地追踪费用和进度。
      2. 不像第一级那样，在危机状态下才行动，管理人员在问题出现时便可发现，并立即采取修正行动，防止它们变成危机。
    2. 关键一点：没有这些措施，要在问题变得无法收拾前发现它们是不可能的。在一个项目中财务的措施也可以为未来的项目拟定实现的期限和费用计划。

等级三：已定义级 Defined

  1. 特点：为软件生产的过程编制了完整的文档。
    1. 软件过程管理方面和技术方面已经做了明确的定义，并且按需要不断地改进过程。
    2. 采用评审的方法来保证软件的质量。
  2. 这个级别可以引用 CASE 环境来进一步提高质量和产生率。
  3. 在第一级的过程中，高技术会使得该危机驱动过程更加混乱。

等级四：已管理级 Managed

  1. 特点：公司对每个项目都设定质量和生产目标。
    1. 这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。
    2. 利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离。
  2. 统计质量控制措施的一个简单例子：是每千行代码的错误率，相应的目标就是随时间推移减少这个量。

等级五：优化级 Optimizing

  1. 目标：连续地改进软件过程。
    1. 使用统计质量和过程控制技术作为指导。
    2. 从各方面获得的知识将被运用在以后的项目中，从而使软件过程融入正反馈循环，使生产率和质量得到稳步的改进。

CMMI：能力成熟度集成模型

  1. 刻画了软件团队/组织从不成熟到成熟的每个阶段的特征（也就是 roadmap)
  2. 等级 2 和等级 3 关注的是当前状态
  3. 等级 4 和等级 5 是根据结果（未来）来进行管理

人话：对多个模型进行整合；改进了CMM模型

阶段式表示法&连续式表示法 前者比较常见

imgimg

等级一：初始级

开发相对混乱，依赖个人英雄主义，没有过程概念，救火文化盛行

  1. 软件组织对项目的目标与要做的努力很清晰，项目的目标可以实现。
  2. 由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务，项目实施是否成功主要取决于实施人员。

等级二：已管理级

项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等。

  1. 软件组织对项目有一系列管理程序，避免了软件组织完成任务的随机性，保证了软件组织实施项目的成功率。
  2. 软件组织在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对项目相关的实施人员进行相应的培训，对整个流程进行监测与控制，并联合上级单位对项目与流程进行审查。
  3. 从 2 级升级到 3 级的原因：固化最佳实践，对小组而言是能够更快地学习其他的做法。

等级三：已定义级

公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法可以在公司内分享。

  1. 软件组织能够根据自己的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化。
  2. 软件组织不仅能够在同类项目上成功，也可以在其他项目上成功。
  3. 科学管理成为软件组织的一种文化，成为软件组织的财富。

等级四：定量管理级

构建预测模型，以统计过程控制的手段来管理过程

  1. 软件组织的项目管理实现了数字化。
  2. 通过数字化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
  3. 在这个级别我们希望能够看到一个预测模型。

等级五：优化级

继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题

  1. 软件组织能够充分利用信息资料，对软件项目在项目实施的过程中可能出现的次品予以预防。
  2. 能够主动地改善流程，运用新技术，实现流程的优化。

关于CMMI和CMM的一些其他内容，见软件质量管理-01-概述和试论CMM/CMMI不适合在当前软件开发当中应用的原因

摘录一些重点：

一个软件组织应当定义使用本软件组织特点的软件过程，并且不断优化该过程，来更好地实现软件组织的商业目标

【2020-mid】请描述CMMI模型的5个等级的特征，并且解释为何CMMI模型不应该是敏捷方法的对立面:

原因解释:

CMMI是过程改进模型，刻画了软件组织从不成熟到成熟的路线图。 大部分敏捷方法都是开发方法，因此两者是完全不同性质的事物，将两者对立是不合适的。

3.1.5 软件危机

软件危机：是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。主要体现有：

  1. 软件开发费用和进度失控
  2. 软件可靠性差
  3. 生产出来的软件难以维护
  4. 用户对“已完成”系统不满意现象经常发现

软件工程：是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。

软件工程的两大视角： 1. 管理视角——能否复制成功？ 2. 技术视角——是否可以将问题解决得更好？

3.1.6 三大阶段

软件发展的两个趋势：

  1. 软件项目规模日益扩大：使得软件越来越难做。
  2. 软件在整个系统中的比重日益增加：将软件质量问题的影响上升到前所未有的高度。

三大阶段

【2020-mid】结合软件发展的三大历史阶段，描述不同阶段的典型软件开发方法和实践

  1. 软硬件一体化（50 年代到 70 年代）
    1. 特点：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更
    2. 主流开发方法：软件完全依赖于硬件：三思而后行（measure twice，cut once）；软件作坊：Code and Fix；编码 + 改错
  2. 软件成为独立的产品（70 年代到 90 年代）
    1. 特点：摆脱了硬件的束缚(操作系统)、功能强大、个人电脑出现、需求多变、兼容性要求、来自市场的压力
    2. 主流开发方法：形式化方法、结构化程序设计和瀑布模型
  3. 网络化和服务化（90 年代中期至今）
    1. 特点：功能更复杂、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方式的变化、进一步的服务化和网络化、盛行开源和共享文化
    2. 主流开发方法：迭代式开发、敏捷开发(XP、Scrum、Kanban)、开源软件开发方式、DevOps

三大阶段有详细展开内容，不知道考试考不考，见软件质量管理-02-软件过程的历史演变和经典工作

敏捷宣言

【2021】描述敏捷宣言

说明：敏捷方法是第三个阶段出现的方法。

  1. 敏捷软件开发宣言的 4 个简单的价值观：
    1. 个体和交互 胜过 过程和工具
    2. 可以工作的软件 胜过 面面俱到的文档
    3. 客户合作 胜过 合同谈判
    4. 响应变化 胜过 遵循计划
  2. 也就是说，尽管右项有其价值，我们更重视左项的价值

3.1.7 驱动力

软件开发有很多困难，但是本质难题是：

  1. 不可见性：软件项目是一个逻辑实体
  2. 复杂性：实体数量众多
  3. 可变性
  4. 一致性

进一步分析：

  1. 除了不可见性以外，其他三个本质难题因项目而异。
  2. 四大本质难题互相促进。
  3. 本质难题变化带动软件方法（过程）演变。

本质难题无法彻底解决。

3.2 项目管理线

3.2.1 概念

三大目标：成本、质量、工期

软件项目管理定义：应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。

3.2.2 团队动力学

【2020-mid】结合软件开发的特点介绍软件项目管理中自主型团队的必要性和自主型团队应当具备的特征

软件开发的特点

  1. 软件开发是一项既复杂又富有创造性的知识工作。
  2. 软件开发：智力劳动，需要处理和讨论极其抽象的概念，并把不同的部分（不可见）整合成一个可以工作的系统。
    1. 要求从事软件开发的工程师
      1. 必须全身心地参与工作：知识工作必须是全身心投入的，任务切换一般需要30分钟才能全身心的投入。
      2. 主观意愿上努力追求卓越。
    2. 要求管理者激励并维持激励
      1. 激励手段
      2. 维持激励手段

知识工作管理

  1. 管理知识工作的关键规则是：管理者无法管理工作者，知识工作者必须实现并且学会自我管理。
  2. 要自我管理，知识工作者必须(如下是自我管理的前提条件)
    1. 有积极性：不然可能会被其他人替代
    2. 能做出准确的估算和计划
    3. 懂得协商承诺
    4. 有效跟踪他们的计划
    5. 持续地按计划交付高质量产物

领导者特点

诚实 能力强 洞察力 鼓动力

  • 经理倾向于告知团队成员该做什么以及该怎么做；领导者则善于倾听团队成员的想法，并加以分析和改进。
  • 经理倾向于指导团队成员的工作方式；而领导者则善于通过询问来诱导团队成员向着正确的方向前进。
  • 经理倾向于说服团队成员；而领导者则善于通过激励以及设定挑战目标等方式吸引团队成员努力表现。
  • 当出现不一致意见的时候，经理倾向于做出决定；而领导者则善于提供各种沟通方式，促成团队达成一致意见。
  • 经理倾向于控制团队成员；而领导者则培养团队成员技能。
  • 经理倾向于监督团队成员；而领导者则鼓励建立起合理的授权机制。
  • 经理倾向于设定目标；而领导者则通过挑战建立目标，确定团队努力方向。

领导者的激励手段

有3种主要的激励方式：

  1. 威逼(Lv.2) (交易型)
  2. 利诱(Lv.1-2)(交易型)
  3. 鼓励承诺(Lv.4)(转变型) ：位于马斯洛需求理论的4级以上，应当是主要的方式，并且最好以团队为单位做承诺

交易型领导方式

  1. 承诺奖励激励
  2. 人们通常能找到新的方式来获得奖励，同时少做工作。
  3. 威逼和利诱属于交易型领导方式。

转变型领导方式

  1. 用成就激励
  2. 鼓励承诺属于转变型领导方式。

由于交易型领导方式很少能产生成功的并且有创造性的团队，因此转变型领导方式是首选。

马斯洛需求理论

Lv.1 生理需求

Lv.2 安全感

Lv.3 爱和归属感

Lv.4 获得尊敬

Lv.5 自我实现

低层次的需求必须在高层次需求满足之前得到满足 满足高层次的需求的途径比满足低层次的途径更为广泛

  1. 自我实现是最高的层次
  2. 激励来自为没有满足的需求而努力奋斗
  3. 低层次的需求必须在高层次需求满足之前得到满足
  4. 满足高层次的需求的途径比满足低层次的途径更为广泛

期望理论 Expectancy Theory

  1. 人们在下列情况下能够受到激励并且出大量成果 M = V * E
    1. 相信他们的努力很可能会产生成功的结果(V)
    2. 他们也相信自己会因为成功得到相应的回报(E)
  2. Motivation = Valence x Expectancy(Instrumentality)，即激发力量 = 效价 X 期望值
    1. M 表示激发力量，是指调动一个人的积极性，激发人内部潜力的强度。
    2. V 表示目标价值（效价），这是一个心理学概念，是指达到目标对于满足他个人需要的价值。同一目标，由于各个人所处的环境不同，需求不同，其需要的目标价值也就不同。同一个目标对每一个人可能有三种效价：正、零、负。效价越高，激励力量就越大
    3. E 是期望值，是人们根据过去经验判断自己达到某种目标的可能性是大还是小，即能够达到目标的概率。目标价值大小直接反映人的需要动机强弱，期望概率反映人实现需要和动机的信心强弱。

自主团队

什么是自主团队

软件工程师所从事的工作一般称之为复杂的知识工作。在这种性质的工作中，实现软件工程师的自我管理往往可以获得最好的工作效率和质量水平。如果整个团队的所有成员都实现了自我管理，也就形成了所谓的自主团队。

自主团队的特点 （考过，要写全）

  1. 自行定义项目的目标
  2. 自行决定团队组成形式以及成员的角色
  3. 自行决定项目的开发策略
  4. 自行决定项目的开发过程
  5. 自行制定项目的开发计划
  6. 自行度量、管理和控制项目工作

自主团队的****外部环境

  1. 项目启动阶段获得管理层的支持
    1. 项目小组应当表现出已经尽最大的可能在满足管理层的需求的工作态度。
    2. 项目小组应当在计划中体现定期需要向管理层报告的内容。
    3. 项目小组应当向管理层证明他们所制定的工作计划是合理的。
    4. 项目小组应当在项目中体现为了追求高质量而开展的工作。
    5. 项目小组应当在工作计划中允许必要的项目变更。
    6. 项目小组应当向管理层寻求必要的帮助。
  2. 在项目进展过程中获得管理层的支持
    1. 项目小组应当严格遵循定义好的开发过程开展项目开发过程。
    2. 项目小组应当维护和更新项目成员的个人计划和团队计划。
    3. 项目小组应当对产品质量进行管理。
    4. 项目小组应当跟踪项目进展，并定期向管理层报告。
    5. 项目小组应当持续地向管理层展现优异的项目表现。（挣值管理/周报/计划）

TSP角色和职责

【2021】TSP中的典型角色，描述其中五个角色的职责

项目组长

  1. 项目组长应当建设和维持高效率的团队。
  2. 项目组长应当激励团队成员积极工作。
  3. 项目组长应当合理处理团队成员的问题。
  4. 项目组长应当向管理层提供项目进度相关的完整信息。
  5. 项目组长应当充当合格的会议组织者和协调者。

TL的工作内容

  1. 激励团队成员努力工作
  2. 主持项目周例会
  3. 每周汇报项目状态
  4. 分配工作任务
  5. 维护项目资料
  6. 组织项目总结

计划经理

  1. 开发完整的、准确的团队计划和个人计划
  2. 每周准确的报告项目小组状态

计划经理的主要工作内容

  1. 带领项目小组开发项目计划
  2. 带领项目小组平衡计划
  3. 跟踪项目进度
  4. 参与项目总结

开发经理

  1. 开发优秀的软件产品
  2. 充分利用团队成员的技能

开发经理的主要工作内容

带领团队制定开发策略。

  1. 带领团队开展产品规模估算和所需时间资源的估算。
  2. 带领团队开发需求规格说明。
  3. 带领团队开发高层设计。
  4. 带领团队开发设计规格说明。
  5. 带领团队实现软件产品。
  6. 带领团队开展集成测试和系统测试。
  7. 带领团队开发用户支持文档。
  8. 参与项目总结

质量经理

  1. 项目团队严格按照质量计划开展工作，开发出高质量的软件产品
  2. 所有的小组评审工作都正常开展，并且都形成了评审报告

质量经理的主要工作内容

  1. 带领团队开发和跟踪质量计划
  2. 向项目组长警示质量问题
  3. 软件产品提交配置管理之前，对其进行评审，以消除质量问题
  4. 项目小组评审的组织者和协调者
  5. 参与项目总结

过程经理

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

过程经理的主要工作内容

  1. 带领团队定义和记录开发过程并且支持过程改进。
  2. 建立和维护团队的开发标准。
  3. 记录和维护项目的会议记录。
  4. 参与项目总结。

支持经理

  1. 项目小组在整个开发过程中都有合适的工具和环境
  2. 对于基线产品，不存在非授权的变更
  3. 项目小组的风险和问题得到跟踪
  4. 项目小组在开发过程中满足复用目标

支持经理的主要工作内容

  1. 带领团队识别开发过程中所需要的各类工具和设施。
  2. 主持配置管理委员会，管理配置管理系统。
  3. 维护软件项目的词汇表。
  4. 维护项目风险和问题跟踪系统。
  5. 支持软件开发过程中复用策略的应用。
  6. 参与项目总结。

启动过程

img

  • 分为4天完成
  • 管理层的期望和小组的期望的完成的对立冲突：
    • 996加班
    • 希望你的功能能尽快上线
  • 第一次和第二次会议由项目经理主持
  • 第三次会议
    • TSP灵活：自定义的流程让人相信项目可以成功
    • 开发策略：打算进行几个迭代周期。
  • 几个认识
    • 错误的认识：软件开发阶段理解为注入缺陷的阶段，软件测试阶段理解为消除缺陷的阶段。
    • 正确的认识：开发和测试都是既有可能引入缺陷，也有可能消除缺陷的阶段
  • 项目完成的实际时间由什么决定？最晚完成的工作的人决定的

SCRUM角色和职责

产品负责人

  • 职责是将开发团队开发的产品价值最大化
  • 是负责管理产品待办列表的唯一负责人
    • 清晰地表述产品待办列表项
    • 对产品待办列表项进行排序
    • 优化开发团队所执行工作的价值
    • 确保产品待办列表对所有人是透明和清晰的，同时显示 Scrum 团队下一步要做的工作
    • 确保开发团队对产品待办列表项有足够深的了解

开发团队

负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。

  • 是自组织的，自行决定如何把产品待办列表变成潜在可发布的功能增量
  • 是跨职能的，团队作为一个整体，拥有创建产品增量所需的全部技能
  • 不认可开发团队成员的任何头衔，不管其承担何种工作都叫开发人员
  • 不认可开发团队中所谓的“子团队”
  • 每个成员也许有特长和专注的领域，但是责任属于整个开发团队

Scrum Master

  • 促进和支持 Scrum
  • 帮助每个人理解 Scrum 理论、实践、规则和价值
  • 是一位服务型领导，负责内外沟通
  • 服务于产品负责人
    • 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项
    • 找到有效管理产品待办列表的技巧
    • 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值
    • 当被请求或需要时，引导 Scrum 事件
  • 服务于开发团队
    • 作为教练在自组织和跨职能方面给予开发团队以指导
    • 帮助开发团队创造高价值的产品
    • 移除开发团队工作进展中的障碍
    • 当被请求或需要时，引导 Scrum 事件
  • 服务于组织
    • 带领并作为教练指导组织采纳 Scrum
    • 在组织范围内规划 Scrum 的实施
    • 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发
    • 引发能够提升 Scrum 团队生产率的改变
    • 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性

3.2.3 估算和计划

估算要点

【2021】估算的要点

估算目的是什么？估算目的是给各类计划提供决策依据

抽象的、相对的估算

估算要点：

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

PROBE估算方法

【2013】【2015A】【2018】谈谈你对项⽬估算的认识，并简要解释应⽤PROBE⽅法估算的优缺点

规模估算往往可以依据历史数据来完成，其原因在于规模估算结果的偏差产⽣原因相对客观，偏差可以⽤以修正新的估算结果。

时间估算的偏差产⽣原因更加复杂，⼀⽅⾯和规模有关，另外⼀⽅⾯，跟⼈的主观能动性有关，因此，时间估算偏差的原因可能估算结果本身，这使得历史数据中时间偏差可参考价值不⼤。

从上述讨论可以得出，对于估算来说，本质上是⼀种猜测，追求的⽬标应该是⼀致性以及估算结果的使⽤者对估算结果的信⼼。

PROBE⽅法通过定义的估算过程和数据收集以及使⽤的框架，使得估算结果可以尽可能⼀致，从⽽使得⼀些统计⽅法可以⽤来调整估算结果，增强⽤户对估算结果的信⼼。

但是这种估算⽅法⾮常依赖⾼质量的历史数据，⼀旦数据不完整或者缺失，就可能导致估算结果有显著偏差。

原理：

  • 设立合理的代理作为精确度量和早期规划需要的度量之间的桥梁
  • 使用相对大小，而非绝对大小

流程：

【2018】PROBE估算的基本流程

【2020-mid】PROBE估算的基本原理和过程，估算时间为什么不用历史数据中的生产效率？

不用生产效率：估算资源需求（如人时）的时候，生产效率一般在分母，考虑到个体软件工程师生产效率波动（忽视了人的主观能动性），易导致估算偏差范围变大。

img

处理有限的历史数据

【2020-mid】PROBE ABCD估算方法对数据质量有什么要求

img

SCRUM故事点

  1. 度量实现一个故事（Story）需要付出的工作量
    1. 抽象的：混合了对于开发特性（feature）所要付出的努力、开发复杂度、各种风险以及类似东西
    2. 相对的：设定标准之后，考虑其他特性（feature）与标准之间的相对大小关系
      1. Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21,34, 55, 89
      2. 拆分
  2. 估算要点之二：建立对结果的信心
  3. 估算要点之三：依赖数据

【2020-mid】请简要描述按照通⽤计划框架，为了开发合理的项⽬计划，应该要做哪些估算？PROBE⽅法充当什么⻆⾊。

通用计划框架

img

各类计划

质量

  1. 项目的质量计划中应当确定需要开展的质量保证活动。
  2. 典型的质量保证活动包括个人评审、团队评审、单元测试、集成测试、系统测试以及验收测试等。
  3. 在质量计划中需要解决的关键的问题是该开展哪些活动，以及这些活动开展的程度，如时间、人数和目标分别是什么。

风险

  1. 风险管理的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目产生的负面影响。

  2. 风险管理大致分成两部分，即风险识别和风险应对。

    1. 风险识别

    2. 风险：没有发生，有一定概率发生，发生后有一定影响，才是风险 。

      问题：已经发生的，比如人员调动等

    3. 识别与成本、进度及绩效相关的风险

    4. 审查可能影响项目的环境因素

    5. 审查工作分解结构的所有组件，作为风险识别的一部分，以协助确保所有的工作投入均已考虑

    6. 审查项目计划的所有组件，作为风险识别的一部分，以确保项目在各方面均已考虑

    7. 记录风险的内容、条件及可能的结果

    8. 识别每一风险相关的干系人

    9. 利用已定义的风险参数，评估已识别的风险

    10. 依照定义的风险类别，将风险分类并分组

    11. 排列降低风险的优先级

    12. 可能性很低，但是发生影响程度很大：政策变化、领导层大规模变动、公司倒闭

    13. [P（可能性）, I（影响程度）, T(阈值)]

    14. 风险应对

    15. 识别风险之后，就应当制定相应的风险管理策略，以应对各类风险。

    16. 典型的策略包括

      1. 风险转嫁
      2. 风险解决
      3. 风险缓解

定量管理计划（自顶向下）

过程模型

（子）过程性能

遵循某个特定（子）过程的之后产生结果的量化描述，既包括（子）过程度量Xi（例如，时间、缺陷消除效率、工时等），也包括产物度量Yi（例如，缺陷密度，相应时间等）。

过程能力基线

（子）过程性能基线

上述过程性能的一个定量化的刻画，一般包括均值和范围。通常用作过程性能的benchmark。

过程组合

3.2.4 跟踪

挣值管理体系

简单、中级和高级

  1. 项目的挣值管理方法(Earned Value Management，简称EVM)是用来客观度量项目进度的一种项目管理方法。
    1. 每项任务实现附以一定价值（credit）
    2. 100%完成该项任务，就获得相应价值
  2. EVM采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量。
    1. 简单实现：添加挣值（EV）
    2. 中级实现：添加成本线（AC）加入日程偏差的计算
    3. 高级实现：添加预测线（BAC），考察项目实际成本 ，当任务足够多的时候，我们就可以让预测线尽可能平直，同时我们延伸挣值（EV），找到与预测线（BAC）的交点，我们就可以明确项目的落后时间
  3. 简单实现

    1. 这种方式仅仅关注进度信息。在实现时，首先需要建立WBS，定义工作范围；其次为WBS中每一项工作定义一个价值（PV）；最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作。常用规则分别为0-100规则和50-50规则，前者只有当某项任务完成时，该任务的PV值将转化成EV值；后者只需要开始某项任务，即可以赋原PV值的50%作为EV值，完成时，再加上另外的50%。而实际完成的工作所需成本AC不对EV值产生任何影响。

    2. 中级实现

    3. 在简单实现的基础上，加入日程偏差的计算。典型计算方式有：

    4. 日程偏差SV = EV – PV;

    5. 日程偏差指数SPI = EV/PV；

    6. 高级实现

    7. 在中级实现的基础上，还需要考察项目的实际成本。

img

  1. 这套方法直接应用到软件项目中会存在问题。
    1. EVM 一般不能应用软件项目的质量管理。
    2. EVM 需要定量化的管理机制，这就使其在一些探索型项目以及常用的敏捷开发方法中的应用受到限制
    3. EVM 完全依赖项目的准确估算，然而在项目早期，很难对项目进行非常准确的估算。
  2. 在软件项目中，计划投入的时间作为挣值比较合适。

【2021】给一个挣值管理的图(4分)

  1. 项目进度如何？是提前还是落后？
  2. 项目有什么风险？

变形——燃尽图

img

  1. 燃尽图是简单的挣值管理的变形。
  2. 他是剩下的工作占的百分比。

为何适应软件项目

适应变更，能够适应新增/删除

EVM的优点

EVM提供了一个综合的项目管理视角，通过整合范围、时间和成本信息，提供了详细的项目绩效评估。这种方法有助于：

  • 提高项目透明度和可预测性：通过定期的EVM分析，可以及时识别项目中的问题和风险，并采取相应的措施。
  • 支持决策过程：提供准确的项目绩效数据，帮助项目经理和团队做出更明智的决策。
  • 增强项目控制能力：通过持续的监控和评估，可以更好地控制项目进度和成本，确保项目按计划进行。

EVM的局限性

尽管EVM有许多优点，但也存在一些局限性：

  • 需要详细和准确的数据：EVM依赖于详细和准确的项目数据。如果数据不准确或不完整，EVM分析的结果可能会误导项目管理。
  • 实施复杂度高：EVM的实施需要系统的方法和工具，对于一些小型项目或资源有限的组织，实施可能会比较复杂和耗时。
  • 不适用于所有项目：EVM主要适用于大型和复杂项目，对于一些简单或短期项目，可能不适用或没有必要实施。

定量管理跟踪（自底向上）

然后定量管理的跟踪，那么其实就是刚才说的这边定好的目标了，那么在实战当中你要做的一件事情，你要确保所有人x都是这样要求。x如果有偏差了，你要想办法去解决它，这是这个项目管理这条线，那很显然项目管理这条线大家可能那个新的东西非常多， up 都是新的。

3.3 质量管理线

img

3.3.1 概念

质量管理的挑战：三要素

软件项目的日程、成本以及质量三大目标统一于质量目标

面向用户的质量观

  1. PSP中也采用了面向用户的视图，定义质量为满足用户需求的程度。在这个定义中，就需要进一步明确：
    1. 用户究竟是谁？
    2. 用户需求的优先级是什么？
    3. 这种用户的优先级对软件产品的开发过程产生什么样的影响？
    4. 怎样来度量这种质量观下的质量水平？
  2. 典型用户质量期望
    1. 这款软件产品必须能够工作：因此可以使用缺陷管理代替质量管理
    2. 这款软件产品最好有较快的执行速度
    3. 这款软件产品最好在安全性、保密性、可用性、可靠性、兼容性、可维护性、可移植性等方面表现优异。
  3. 指导意义
    1. 开发在前，运维在后
    2. 高质量开发确保DevOps中的价值顺畅流动
    3. 个体软件工程师的技能、过程直接影响产品质量
    4. PSP关注提升个体软件工程师工程技能

质量管理策略和背后的逻辑

策略：

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

为什么有效?

  1. 提高生产效率，通过关注每个组件的质量，往往可以避免在集成测试和系统测试消除
  2. 大量缺陷，减少消除代价，提升生产效率

【2018】什么是面向用户的质量观？这对质量管理的策略有什么影响？

【2014】请区分质量管理和缺陷管理之间的联系和差异，并解释为何在软件开发中将质量和生产效率两者进行妥协不合适？

【2014】为了追求极高的软件产品的质量目标，可能有的方法和这些方法的先后顺序分别是什么？(质量路径)

3.3.2 评审

个人评审

关键控制因素：主要是评审速度

时机选择：

  1. 编译、评审
    1. 对于某些类型的缺陷而言，通过编译发现并消除的效率往往是通过评审发现并消除的数倍。
      1. 越来越强大的编译器一般可以发现超过90%的拼写错误。
      2. 不管怎么努力，评审还是会遗漏约20-50%的语法错误。
      3. 即便编译器遗漏了一些类似语法的错误，这些错误也不难通过单元测试消除。
    2. 一些基于解释执行的集成开发环境，可以实现消除编译错误。
  2. 评审、编译
    1. 为了确保评审的效率，不管在评审之前有没有编译，评审的速度是一定的，也就意味着评审所需时间是一定的，那么如果先评审后编译，在编译阶段就可以节省较多的时间。
    2. 编译器会大概会遗漏9%左右的缺陷，从前面讨论可知，为了有较高的质量，这些缺陷仍然期望通过评审加以消除。
    3. 有数据表明，编译过程中缺陷较多，往往意味着单元测试中缺陷也较多。
    4. 即便单元测试也可以发现一些类似语法的错误，但是，毕竟还有些很难发现，而单元测试之后的一些缺陷消除环节的Pahse Yield往往还低于单元测试。
    5. 编译之前评审也是一种自我学习的好机会。
    6. 干净的编译，即编译过程没有缺陷对于软件工程师来说，也有极大的成就感。

小组评审

小组评审的意义

  1. 有利于更好地发现缺陷，预防风险，提高Process Yield进而确保质量。
  2. 在个人评审之后安排小组评审，也有利于提升个人的技能。特别是那些个人评审未发现而个人评审发现的缺陷，往往都需要引起足够的注意。软件工程师通过对这些缺陷的分析，往往可以学到很多东西。

过程质量控制方式

？

九宫图（网上找的） https://nippleshot.github.io/2020/11/28/SoftwareQuality5.html

img

Capture & recapture（网上找的）

img

  • 好处 ：不要历史数据，所以实际工作当中更容易被使用
  • 实际情况当中，3个人以上的人来评审。那么把“独立发现错误最多的人–他发现的错误当中别人都没发现的”作为A。剩下的人作为整体作为B

3.3.3 质量控制指标

【2021】基于Yield构建预测模型，并列举该模型的可能改进方案

总体思想:利用回归技术预测软件开发过程中各阶段的Inject Rate(缺陷注入率)和Yield(缺陷消除率)

Yield指标只能用来估算，不可以用来度量。结合Yield指标和上图，只需要知道如下指标就可以基于Yield指标 构建一个基本的缺陷预测模型:

  1. 注入阶段注入多少缺陷
  2. 缺陷注入的密度(需求每一⻚注入多少缺陷)
  3. 缺陷注入的速度(每小时注入多少缺陷)
  4. 消除阶段的缺陷注入密度和速度。
  5. 历史数据中的软件规模、文档规模、开发人员规模

可能的改进方案:可能的改进是假设注入水平和消除水平都符合正态分布，因此，可以用蒙特卡罗方法模拟结果。

Yield

  1. Yield指标用以度量每个阶段在消除缺陷方面的效率。
    1. Phase Yield = 100 * (某阶段发现的缺陷个数)/(某阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数)
    2. Process Yield = 100 * (第一次编译前发现的缺陷个数)/(第一次编译前注入的缺陷个数)；
  2. 例子
阶段 Injected Removed remain Yield
DFD 10 0 10 0
DFD REVIEW 0 4 6 40
CODING 20 2 24 1/13 * 100
CODE REVIEW 0 12 12 50
UNIT 0 12 0 100
  1. Yield体现缺陷消除的效率问题
    1. 上游的问题可以引发更多的问题。
    2. 不能确定单元测试后是否有错误，不可知。
  2. IBM：最后的测试如果发现了一个错误，那么其中一定还有一个错误没有被发现（所以最后的Yield的值为50），修改后如下（没有发现的也按照原本的比例来分）
阶段 Injected Removed remain Yield
DFD 10+4 0 14 0
DFD REVIEW 0 4 10 2/7 * 100
CODING 20+8 2 36 2/19 * 100
CODE REVIEW 0 12 12 1/3 * 100
UNIT 0 12 12 50
  1. 基于Yield指标构建缺陷预测模型，并列举该模型的可能改进方案
    1. 总体思想：利用回归技术预测软件开发过程中各阶段的Inject Rate(缺陷注入率)和Yield(缺陷消除率)
    2. Yield指标只能用来估算，不可以用来度量。结合Yield指标和上图，只需要知道如下指标就可以基于Yield指标构建一个基本的缺陷预测模型：
      1. 注入阶段注入多少缺陷
      2. 缺陷注入的密度（需求每一页注入多少缺陷）
      3. 缺陷注入的速度（每小时注入多少缺陷）
      4. 消除阶段的缺陷注入密度和速度。
      5. 历史数据中的软件规模、文档规模、开发人员规模
    3. 步骤
      1. 确定纳入影响因子的数据以及数据度量方法
      2. 从系统历史库中收集历史数据，并进行整理
      3. 依照回归技术进行计算
      4. 在项目进行过程中不断收集数据，与预测数据进行比较，调整回归参数
      5. 项目过程中依据实际数据与预测数据的误差进行风险的预防、识别和控制
    4. 改进方案
      1. 维护历史数据：历史数据在简单性、可理解性、稳定性、可度量性、相关性等方面的质量都有影响。
      2. 影响因子的选择：不仅仅有软件规模的数据，还需要有开发过程、文档、人员等方面的数据，并将其可度量化。
      3. 反馈模型：随着开发实际数据的产生，将这些数据作为输入变量放回模型来调整参数。
      4. 蒙特卡洛方法：假设注入水平和消除水平都符合正态分布，计算均值和标准差并用蒙特卡洛方法模拟结果。

A/FR

  1. A/FR = PSP质检成本/PSP失效成本；
    1. 质检成本 = 设计评审时间 + 代码评审时间
    2. 失效成本 = 编译时间 + 单元测试时间

img

  1. A/FR控制目标
    1. 理论上，A/FR的值越大，往往意味着越高的质量。
    2. 过高的A/FR往往意味着做了过多的评审，反而会导致开发效率的下降。作为指南，在PSP中A/FR的期望值就是2.0

PQI

  1. 5个数据乘积
    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}
  2. PQI与交付后缺陷密度的关系

img

  1. PQI与集成时缺陷数的关系

img

  1. PQI的作用
    1. 判断模块质量
    2. 评估项目质量
    3. 为软件改进做依据

Review Rate

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

DRL

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

img

3.3.4 Quality Journey

Journey是什么？顺序？

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

设计

模版：要设计哪些信息？

设计什么：

  1. 设计目标程序在整个应用系统中的位置
  2. 设计目标程序的使用方式
  3. 设计目标程序与其他组件以及模块之间的关系
  4. 设计目标程序外部可见的变量和方法
  5. 设计目标程序内部运作机制
  6. 设计目标程序内部静态逻辑

模版：

  1. 操作规格模板（Operational Specification Template， 简称OST）
  2. 功能规格模板（Functional Specification Template， 简称FST）
  3. 状态规格模板（State Specification Template，简称SST）
  4. 逻辑规格模板（Logical Specification Template，简称LST）

img

操作规格模板OST

  1. 描述系统与外界的交互，用于场景描述：也就是”用户“与”待设计系统的正常情况和异常情况下的交互。
  2. 定义测试场景和测试用例，用来与用户讨论需求的基础，特别是操作相关的需求描述
  3. 与UML比较：用例图、时序图

功能规格模板FST

  1. 描述系统的对外接口，是一种静态信息的展现。
  2. 提供的典型信息有类和继承关系、外部可见的属性和方法等。
  3. 用形式化符号等方法描述方法等行为，消除二义性。
  4. 与UML对比：UML类图，但类图的方法的行为没有描述

状态规格模板SST

  1. 可以精确定义程序的所有状态、状态之间的转换以及伴随着每次状态转换的动作。
  2. SST模板中，需要描述如下的信息
    1. 所有状态的名称
    2. 所有状态的简要描述
    3. 在SST中需要使用的参数和方法的名称与描述
    4. 状态转换的条件
    5. 状态转换是发生的动作。
  3. 与UML对比：UML状态图

逻辑规格模板LST

  1. 可以精确描述系统的内部静态逻辑。为了消除描述的二义性，一般建议使用伪代码配合形式化符号来描述设计结果。
  2. LST模板中，需要描述如下的信息
    1. 关键方法的静态逻辑
    2. 方法的调用
    3. 外部引用
    4. 关键数据的类型和定义
  3. 与UML对比：没有对应图

设计的层次

img

设计评审

状态机验证

  1. 检查状态机的完整性和正交性
    1. 完整性：对于状态机中任何一个状态，对应的所有条件组合，下一个状态的转换都有定义。
    2. 正交性：对于状态机中任何一个状态，其所有下一个状态的转换条件都不能相同。
  2. 验证步骤
    1. 检查状态机，消除死循环和陷阱状态
    2. 检查状态转换，验证完整性和正交性
    3. 评价状态机，检验是否体现设计意图
  3. 具体验证方法参见PPT
    1. 使用状态图，检查死循环和陷阱状态
    2. 使用真值表来进行分析

符号化验证

  1. 将描述设计的逻辑规格(一般用伪代码程序表示)用代数符号来表示是，然后系统地开展分析和验证
  2. 验证步骤
    1. 识别伪码程序中的关键变量
    2. 将这些变量使用代数符号表示，重写伪码程序
    3. 分析伪码程序的行为。
  3. 具体示例见PPT：交换两个变量的值
  4. 优点
    1. 实施简单，可以给出一般化的验证结果
    2. 适用于不复杂的算法，特别是遗漏系统的改造中，应用这种方法识别和理解原有的设计
  5. 缺点：不适合于有复杂逻辑的场合；纯手工验证方法容易引入错误。

执行表验证

  1. 执行表
  2. 步骤
    1. 识别伪码程序的关键变量
    2. 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量
    3. 初始化被选定的变量
    4. 跟踪被选择的关键变量的变化情况，从而判断程序行为
  3. 优点：实施简单；结果可靠，可用于复杂逻辑的验证。
  4. 缺点：每次只能验证一个用例；手工验证比较耗时，容易引入错误。

跟踪表验证

  1. 步骤
    1. 识别伪码程序的关键变量
    2. 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量
    3. 初始化被选定的变量
    4. 识别将伪码程序符号化的机会，并加以符号化
    5. 定义并且优化用例组合
    6. 跟踪被选择的关键变量的变化情况，从而判断程序行动。
  2. 跟踪表应用符号化以及用例识别等方法，对程序的一般化行为进行验证，是执行表验证的补充，可以每次验证多个用例，从而提供更加高效地开展验证工作。

正确性验证

  1. 将伪码程序当做数字定理，采用形式化方法加以推理和验证
  2. 步骤
    1. 分析和识别用例
    2. 对于复杂伪码程序的结构，应用正确性验证的标准问题逐项加以验证
    3. 对于不能明确判断的复杂程序结果，使用跟踪表等辅助验证
  3. While-Do循环的验证
    1. 条件1：condition 是否最终一定会为”假”，从而使得循环可以结束。
    2. 条件2：condition 为”真”的时候，单独的循环结构执行结果与循环体再加一个循环结构，其执行结果是否一致？
    3. 条件3：condition 为”假”的时候，循环体内所有变量是否未被修改？

3.4 工程技术线

img

3.4.1 需求

  1. 客户需求描述的是客户的期望，是客户解决问题的愿望。
    1. 客户需求可能很简单，也可能很复杂；可能很清晰，也可能模糊。
    2. 比如，客户希望有一种快速进行数据计算的工具帮助其完成繁琐的计算工作。
  2. 产品需求描述的是开发团队所提供的解决⽅案。即针对上述的客户需求，开发团队设计出⼀个可以帮助客户解决⼯作当中碰到的问题的⽅案。
  3. 产品组件需求描述的是组成产品的各个组件的需求规格。与产品需求相比，这是更低层次，更为细致的描述了上述解决方案中的某个组件的功能、性能与形式等。

产品经理

？

3.4.2 设计

自顶向下

考虑点

  1. 团队智慧的使用

发挥团队智慧两大挑战：

  1. 确定整体架构之前很难进行分工。解决方法视软件系统规模而定，适当人数参与开发，其他参与架构评估和关键问题验证。

  2. 团队成员在讨论和评审会议中的参与程度，采用适当方法调动参与，如轮流询问。

  3. 设计标准

    1. 命名规范
    2. 接口标准
    3. 系统出错信息（标准化测试的好处：方便定位错误）
    4. 设计表示标准

  4. Design of Reuse

    1. 在设计阶段必须要充分考虑复用的可能。为了支持复用，软件项目团队需要建立一套复用管理流程，具体而言，包括
      1. 复用接口标准
      2. 复用文档标准
      3. 复用质量保证机制
    2. 什么时候考虑复用

  5. 可测试性支持

设计可测试性考虑主要体现在两方面：一是要尽可能减少测试代码的数量；二是要制作合理的测试计划。

  1. 可用性支持
    1. 可用性的问题应当在设计阶段就开始考虑，而不能推延到实现阶段。
    2. 针对每一个关键功能都定义操作概念和操作场景。
    3. 分析操作场景以确保软件系统开发完成之后，系统使用者会满意。
    4. 必要时，可以邀请最终用户参与场景的评审，使用模拟、原型等技术，更好的把握用户真实意图。

3.4.3 实现

考虑点：

  1. 评审
    1. 设计的时候采用的策略是自顶向下、逐层精化，这有利于建立系统的整体观，
    2. 实现的时候为了方便对实现结果评审，建议采用自底向上的方式进行，首先实现底层的内容，然后对这些底层的模块进行评审，有利于复用策略的应用。
  2. 复用
    1. 采用自底向上的开发策略有利于进行复用。
    2. 几个经典的复用策略
      1. 编码注释的应用：编码注释采用统一格式，标明功能，调用方式。异常信息等有利于复用的信息。
      2. 站立式会议：在会上，团队成员可以讨论实现计划，识别可复用组件，了解现有的复用组件库中的内容
  3. 可测性

实现计划必须与测试计划一致，不能出现集体测试的时候部分模块未实现的情况。

3.4.4 集成

覆盖范围

开始到交付

基本策略

大爆炸集成策略

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

逐一添加集成策略

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

集簇集成策略

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

扁平化集成策略

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

CI/CD是哪种？

maybe逐一添加

3.4.5 V&V

什么是V&V?

  1. 验证(Verification)活动也是检验获得的产品和产品组件能不能满足各自事先定义好的需求规格；
  2. 确认(Validation)活动是为了确保产品可以满足客户的需求以及实际操作场景的要求。
  3. 验证(Verification)和确认(Validation)都是为了提升最终产品的质量⽽采取的措施。

V&V的区别与联系

  1. 验证和确认的⽬的不同：
    1. 验证是⽬的是确保选定的⼯作产品与事先指定给该⼯作产品的需求(即产品需求或产品组件需求)⼀致。
    2. 确认的目的则是确保开发完成的产品或者产品组件在即将要使⽤该产品或者产品组件的环境中⼯作正确，关注的是客户需求的满足。
  2. 验证和确认又是相互依存、关系紧密的两个活动
    1. 验证活动的依据来源于确认的目标，即产品组件需求必须与客户需求一致。
    2. 验证活动为确认活动提供了前提条件，在完成产品需求和产品组件需求之前，考虑客户需求是否满足是没有意义的。

3.5 其他

3.5.1 配置和管理

img

  1. 配置项：
    1. 在配置管理当中作为单独实体进行管理和控制的工作产品集合
    2. 典型的可能作为配置项纳入配置管理的工作产品包含过程说明文档、项目开发计划文档、需求规格说明书、设计规格说明书、设计图表、产品规格说明书、程序代码、开发环境，如特定版本的编译器等、产品数据文件、产品技术文件、用户支持文档
  2. 基线：基线是一个或多个配置项及相关的标识符的代表，是一组经正式审查同意的规格或工作产品集合，是未来开发工作或交付的基础，而且只能经由严格的变更控制程序才能改变。
    1. 发布一个基线包括该基线所有的配置项以及这些配置项的最新变更，因此，可以将基线作为接下来工作的基础。
    2. 典型的发布基线时间点为需求分析之后、设计完成之后、单元测试之后以及最终产品发布。
    3. 是配置项持续演进的稳定基础

3.5.2 度量和分析

GQM方法的原理和应用

  1. GQM(Goal Question Metric)是一种应用非常广泛的建立软件度量体系的方法，从管理的目标出发，将目标归纳、分解为度量的指标，并把这些指标提炼成可以测量的值，是一种科学的、系统的思考问题的方式。

    1. 实施过程：从上到下的分析过程和从下到上的执行过程，首先提出度量目标Goal，然后将目标细化为关于过程或产品的特定问题Q，这些问题以度量Metric的方式得到回答。将一个个模糊的、抽象的目标，分解成具体的、可测量的问题。

    2. 概念层(目标)：目标是为某个特定的对象而定义的。这里的对象是指软件产品、软件过程以及相关的资源等。定义的目标基于不同原因和不同质量模型,也要参考不同的角色视图与特定的环境。

    3. 操作层(问题)：基于一定的刻画上述目标是否达成或者目标达成的进展情况的模型，使用一系列的问题来定义所研究的对象, 然后得出评价或评估特定目标达成进展情况。所选择的问题应当尽量体现质量相关的话题。

    4. 量化层(度量)：试图以量化的方式回答上述操作层识别出来的问题。

  2. 示例：
    1. 例子一：PM
      1. G：确保稳定性、可预测性的开发过程来满足计划的里程碑
      2. Q：我的项目是否按照计划的轨迹前进，计划的里程碑都能实现吗？
      3. M：软件项目开发工作的挥发性(分支、流、统计变更管理UCM活动)
    2. 例子二：QM
      1. G：最大化所有团队贡献者的生产力
      2. Q：开发人员能够完成分配给他们的任务吗，或者他们遇到障碍了吗？
      3. M：由个体或者工作组产生的项目工作的量级

3.5.3 决策分析和解决方案

  1. 决策分析的意义：错误的决策往往会给项目带来灾难性后果。为了降低这种错误决策的风险，往往需要尽可能基于客观事实和正确的流程来开展决策与分析活动
  2. 决策分析往往包含以下活动
    1. 建立决策分析指南
    2. 建立评价标准
    3. 识别候选方案
    4. 选择评价方法
    5. 评价候选方案
    6. 选择解决方案

img

3.5.4 根因分析与解决方案

  1. 避免类似错误反复发生
  2. 一个正式根因分析过程往往包含下列的活动：
    1. 识别和选定问题
    2. 根因分析
    3. 建立改进的行动方案
    4. 实施改进，评估效果
  3. 根因分析活动

img

  1. 根因分析典型示例

img

4. 往年题

https://meeting.tencent.com/v2/cloud-record/share?id=487a430c-1f7e-40ba-a1b5-030a99fc6ee4&from=3