主体框架参考dxy

feat: 增加可能重要的知识点，增加知识点不涉及的往年题，增加2024回忆

1. 复习

1.1. lec1 & lec2

1.1.1. 四大本质困难和挑战

• 复杂性

• 不可见性

• 一致性

• 可变性

1.1.2. 软件危机

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

1.1.3. 软件工程

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

软件工程的两大视角

1. 管理视角——能否复制成功？

2. 技术视角——是否可以将问题解决得更好？

1.1.4. 管理的三大关键要素

• 目标

• 状态

• 纠偏

1.1.5. 软件项目管理三大目标

• 成本

• 质量

• 工期

1.1.6. 生命周期模型与软件过程的区别与联系

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

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

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

1.1.7. 软件过程的同义词

软件开发方法、软件开发过程

包括净室Cleanroom方法、极限编程方法、SCRUM方法、Gate方法等

1.1.8. 软件项目管理和软件过程管理的区别

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

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

3. 

1.1.9. 软件过程管理与软件过程改进

两者意思接近

1. 软件过程管理参考模型 CMM/CMMI, SPICE等

2. 软件过程改进参考元模型 PDCA，IDEAL

3. 

4. 

5. 

1.1.10. 软件发展三大阶段

1. 软硬件⼀体化

2. 1. 特点：软件⽀持硬件完成计算任务、功能单⼀、复杂度有限、⼏乎不需要需求变更
   2. 主流开发⽅法：线性顺序过程、三思⽽后⾏；Code and Fix；

3. 软件成为独⽴的产品

4. 1. 特点：摆脱了硬件的束缚(操作系统)、功能强⼤、个⼈电脑出现、需求多变、兼容性要求、来⾃市场的压⼒
   2. 主流开发⽅法：形式化⽅法、结构化程序设计和瀑布模型，成熟度运动

5. ⽹络化和服务化

6. 1. 特点：功能更复杂、规模更⼤、⽤户数量急剧增加、快速演化和需求不确定、分发⽅式的变化、盛⾏开源和共享⽂化
   2. 主流开发⽅法：迭代式开发、敏捷开发(XP、Scrum、Kanban)、开源软件开发⽅式、DevOps

1.1.11. CMMI成熟度模型的图

1. 4级和5级更多是根据结果（未来）来进行管理

2. 2级和3级关注的是当前的状态

1. Initial 原始级别：开发相对混乱，依赖个⼈英雄主义，没有过程概念，救⽕⽂化盛⾏

2. Managed 已管理级别：项⽬⼩组体现出项⽬管理的特征，有项⽬计划和跟踪、需求管理、配置管理等

3. Defined 已定义级别：公司层⾯有标准流程和相应的规范，每个项⽬⼩组可以基于此定义⾃⼰的过程，使得优秀的做法可以在公司共享。

4. Quantitatively Managed 定量管理级别：构建预测模型，以统计过程控制的⼿段来管理过程

5. Optimizing 优化级：继续应⽤统计⽅法识别过程偏差，找到问题根源并消除，避免未来继续发⽣类似问题。

1.1.12. 敏捷宣言

1. 个体和互动胜过过程和工具

2. 可以工作的软件胜过详尽的文档

3. 客户合作胜过合同谈判

4. 响应变化胜过遵循计划

“也就是说，尽管右项有其价值，我们更重视左项的价值。”

1.1.13. 典型软件过程和实践

1. XP（eXtreme Programing） 方法：偏重于一些工程实践的描述

2. SCRUM：管理框架和管理实践

3. Kanban

   • 精益生产（丰田制造法）的具体实现

   • 可视化工作流、限定WIP、管理周期时间

1.1.14. 典型DevOps实践和方法

1. 方法论基础是敏捷软件开发、精益思想以及看板Kanban方法。

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

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

4. 一切皆服务XaaS(X as a Service)的理念指导

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

1.2. lec3

1.2.1. 三种主要的激励方式

• 威逼

• 利诱

• 鼓励承诺：位于马斯洛需求理论的4级以上，应当是主要的方式，并且最好以团队为单位做承诺

前两者对应交易型领导方式；第三种对应转变型领导方式

1.2.2. 马斯洛的需求层次理论

• 自我实现是最高的层次

• 激励来自为没有满足的需求而努力奋斗

• 低层次的需求必须在高层次需求满足之前得到满足

• 满足高层次的需求的途径比满足低层次的途径更为广泛

1.2.3. 如何维持激励（和激励区分）

需要及时的绩效反馈。包含：

• 根据一个详细计划衡量进度

• 当前计划不准确时重做计划

• 为漫长而富有挑战性的项目提供中间反馈，即里程碑

1.2.4. 麦克勒格的X-理论和Y-理论（理解即可）

• X-理论（负面）

• • 不喜欢他们的工作并努力逃避工作
  • 缺乏进取心，没有解决问题与创造的能力
  • 更喜欢经常的指导，避免承担责任，缺乏主动性
  • 自我中心，对组织需求反应淡漠，反对变革
  • 用马斯洛的底层需求（生理和安全）进行激励

• Y-理论（正面）

• • 如果给予适当的激励和支持性的工作氛围，会达到很高的绩效预期
  • 具有创造力，想象力，雄心和信心来实现组织目标
  • 能够自我约束，自我导向与控制，渴望承担责任
  • 用马斯洛的高层需求（自尊和自我实现）进行激励

1.2.5. 海兹伯格的激励理论

• 激励因素（内在因素）

• • 成就感、责任感、晋升、被赏识、认可

• 保健因素（外在因素）

• • 工作环境、薪金、工作关系、安全等

1.2.6. 期望理论

人们在下列情况下能够受到激励并且出大量成果 M = V * E

• 相信他们的努力很可能会产生成功的结果(V)

• 他们也相信自己会因为成功得到相应的回报(E)

1.2.7. TSP Launch九次会议图

1.2.8. TSP的角色以及对应的简单职责

1. 项目组长

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

2. 计划经理

   • 带领项目小组开发项目计划
   • 带领项目小组平衡计划
   • 跟踪项目进度
   • 参与项目总结

3. 开发经理

   • 带领团队制定开发策略。
   • 带领团队开展产品规模估算和所需时间资源的估算。
   • 带领团队开发需求规格说明。
   • 带领团队开发高层设计。
   • 带领团队开发设计规格说明。
   • 带领团队实现软件产品。
   • 带领团队开展集成测试和系统测试。
   • 带领团队开发用户支持文档。
   • 参与项目总结

4. 质量经理

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

   • 向项目组长警示质量问题

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

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

   • 参与项目总结

5. 过程经理

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

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

   • 记录和维护项目的会议记录。

   • 参与项目总结。

6. 支持经理

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

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

   • 维护软件项目的词汇表。

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

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

   • 参与项目总结。

7. 开发人员

1.2.9. SCRUM小组三个角色

一名产品负责人、开发团队和一名SCRUM Master

稍微看下各自职责

• 产品负责人：将开发团队开发的产品价值最大化

• 开发团队：在每个Sprint结束时交付潜在可发布并且“完成”的产品增量

• SCRUM Master：相当于项目经理，促进和支持SCRUM、帮助每个人理解SCRUM理论、实践、规则和价值

1.2.10. 知识工作领导者应该具备的品质或特点

1. 诚实，说到做到

2. 有能力，有知识和技能

3. 有远见

4. 能鼓舞人心的

1.3. lec4

1.3.1. 估算原理

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

2. 相对大小而非绝对大小

1.3.2. PROBE 作用

1. 以 LOC VS. FP 为例

   1. 精确度量方式往往不便于早期规划/估算；
   2. 有助于早期规划/估算的度量往往难以产生精确度量结果；

2. PROBE(PROxy Based Estimation)的作用：精确度量和早期规划之间的桥梁

1.3.3. PROBE估算流程

1.3.4. 估算的四个要点

1. 尽可能划分详细一些

2. 建立对结果的信心

3. 依赖数据

4. 估算要的是过程，而非结果；估算的过程是相关干系人达成一致共识的过程

1.3.5. WBS不是重点

1.3.6. 通用计划框架

1.3.7. EVM的三种不同的实现

简单实现：只有最下面EV

中级实现：加上中间的PV线

高级实现：加上实际成本

1. BAC表示按照PV值的曲线，当项⽬完成的时候所需预算或者时间

2. 成本差异CV = EV-AC，表示的是已经完成的⼯作与所消耗的成本的差异。可以表示为消耗的时间，也可以表示为消耗的资⾦。

3. 成本差异指数CPI = EV/AC，表示单位成本创造的价值

4. 1. CPI<1说明成本超⽀
   2. CPI=1说明成本与预期⼀致
   3. CPI>1说明成本低于预期。

5. ⽇程偏差SV = EV – PV，表示进度偏差。

6. 1. SV<0表示进度落后；SV=0表示进度正常
   2. SV>0表示进度超前。

7. ⽇程偏差指数SPI = EV/PV

8. 预计完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是按照⽬前的进展已经成本消耗情况，整个项⽬完成的时候所需消耗的成本。

1.3.8. 看懂燃尽图

什么时候比进度快，什么时候比进度慢

1. 燃尽图是简单的挣值管理的变形。

2. 他是剩下的工作占的百分比。

1.3.9. EVM的局限性

• 一般不能应用软件项目的质量管理

• 需要定量化的管理机制，这就使其在一些探索型项目以及常用的敏捷开发方法中的应用受到限制

• 完全依赖项目的准确估算，然而在项目早期，很难对项目进行非常准确的估算

1.3.10. TSP 总结过程阶段

• 准备阶段

• 过程数据评审阶段

• 人员角色评价阶段

• 总结报告撰写阶段

1.4. lec5

PSP中也采用了面向用户的视图，定义质量为满足用户需求的程度。

1.4.1. PSP质量策略

用缺陷管理代替质量管理

高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷

各个组件的高质量是通过高质量评审来实现的

1.4.2. 测试消除缺陷的流程

• 发现待测程序的一个异常行为；

• 理解程序的工作方式；

• 调试程序，找出出错的位置，确定出错原因；

• 确定修改方案，修改缺陷；

• 回归测试，以确认修改有效

1.4.3. 评审消除缺陷的流程

• 发现缺陷的同时，也知道了缺陷的位置和原因；

• 修正缺陷；

1.4.4. Yield计算方法

Yield指标用以度量每个阶段在消除缺陷方面的效率

• Phase Yield = 100*(该阶段发现（即消除）的缺陷个数)/(该阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数)

• Process Yield = 100*(第一次编译前发现的缺陷个数）/（第一次编译前注入的缺陷个数）【编译不会注入缺陷】

1.4.5. A/FR计算方法

A/FR = PSP质检成本/PSP失效成本；（期望值是2.0）

PSP中定义的失效成本为编译时间和单元测试时间之和。

PSP中定义的质检成本为设计评审时间与代码评审时间之和。

• 理论上，A/FR的值越大，往往意味着越高的质量。

• 过高的A/FR往往意味着做了过多的评审，反而会导致开发效率的下降

1.4.6. PQI计算方法

5个数据乘积

• 设计质量：设计的时间应该大于编码的时间, min{设计时间/编码时间, 1}

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

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

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

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

1.4.7. Review Rate计算方法

PSP的实践中，代码评审速度小于200 LOC/小时，文档评审速度小于4 Page/小时

1.4.8. DRL计算方法

缺陷消除效率比 度量的是不同缺陷消除阶段消除缺陷的效率。

以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是DRL

1.4.9. 质量路径Quality Journey

1-6是针对特定项目，其中6是保证质量的终极手段，78不是针对特定项目的

• Step 1：各种测试

• Step 2：进入测试之前的产物质量提升

• Step 3：评审过程度量和稳定

• Step 4：质量意识和主人翁态度

• Step 5：个体review的度量和稳定

• Step 6：诉诸设计

• Step 7：缺陷预防

• Step 8：用户质量观——其他质量属性

1.4.10. 典型设计过程

1.4.11. PSP设计模板展现的信息

设计的内容

• 操作规格模板（Operational Specification Template， 简称OST），描述的是系统与外界的交互。

• 功能规格模板（Functional Specification Template， 简称FST），描述的是系统对外的接口，静态信息的描述。

• 状态规格模板（State Specification Template，简称SST），精确定义程序的所有的状态、状态之间的转换以及伴随着每次状态转换的动作。

• 逻辑规格模板（Logical Specification Template，简称LST），可以精确描述系统的内部静态逻辑。为了消除描述的二义性，一般建议用伪代码配合形式化符号来描述设计结果

1.4.12. 了解一下和UML的对应关系

• UML的用例图和时序图提供了与PSP中OST同样的信息；

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

• UML类图中记录了方法的型构，然而方法的行为没有描述，这一点在PSP的FST中有相应的内容；

• PSP中的LST用以描述程序的静态逻辑，这在UML没有对应的图示方法；

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

1.4.13. 看一下每种设计验证方法

意义：简单评审不足以发现复杂缺陷

• 状态机验证

  • 消除死循环和陷阱状态。
  • 验证完整性和正交性
  • 检验是否体现设计意图。

• 符号化执行验证（不适合复杂逻辑，适合验证复杂计算）提供全面设计验证

  • 识别伪码程序中的关键变量；
  • 将这些变量用代数符号表示，重写伪码程序；
  • 分析伪码程序的行为。

• 执行表验证

  • 识别伪码程序的关键变量；
  • 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量；
  • 初始化被选定的变量；
  • 跟踪被选择的关键变量的变化情况，从而判断程序行为。

• 跟踪表验证（执行表验证方法的一种扩充）

  • 识别伪码程序的关键变量；
  • 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量；
  • 初始化被选定的变量；
  • 识别将伪码程序符号化的机会，并加以符号化；
  • 定义并且优化用例组合；
  • 跟踪被选择的关键变量的变化情况，从而判断程序行为。

• 正确性验证（伪码程序当成数学定理，采用形式化方法加以推理和验证）

  • 分析和识别用例；
  • 对于复杂伪码程序的结构，应用正确性检验的标准问题逐项加以验证；
  • 对于不能明确判断的复杂程序结构，使用跟踪表等辅助验证。

1.5. lec6

1.5.1. 不同种类的需求

• 客户需求

• 产品需求

• 产品组件需求

客户所受到的限制也应当作为需求开发过程中需要重点关注的内容。

1.5.2. 四种集成策略

/* 什么意思、优势和劣势 */

1. 大爆炸集成策略

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

2. 逐一添加集成策略

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

3. 集簇集成策略

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

4. 扁平化集成策略

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

1.5.3. 验证和确认的区别

都是为了提升最终产品的质量而采取的措施

目的不同。

1. 验证（Verification）的目的是确保选定的工作产品与事先指定给该工作产品的需求一致。

2. 确认（Validation）的目标则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确。

1.6. lec7

配置管理基本概念：配置项、基线

配置管理的目的是建立与维护工作产品的完整性

1.6.1. 决策分析活动的图

2. 往年题

2.1. 选择题

2.1.1. 第二讲

1. “Measure twice, cut once” 描述的是下述哪个软件开发场景：
   A. 软件设计；
   B. 代码评审；
   C. 需求开发；
   D. V&V；

2. 整体来看，我们可以把软件的发展分为三大阶段，以下不属于三大主要阶段的是：
   A. 软硬件一体化； (1950s - 1970s)
   B. 网络化和服务化； (1970s - 1990s)
   C. 云计算化和云原生；
   D.软件成为独立产品；(1990s - )

3. 以下描述中，不属于软件开发本质困难或者本质挑战的是：
   A. 质量难题；
   B. 复杂性；
   C. 不可见；
   D. 一致性；

4. 以下描述中，哪一种实践是软硬件一体化阶段的典型实践：
   A. Code and Fix；
   B. 迭代式开发；
   C. 瀑布生命周期模型；
   D. 成熟度模型；

2.1.2. 第三讲

1. 对比TSP和SCRUM，下列说法不恰当的是：
   A. 都是过程框架，需要填补具体实践之后才是一个可以工作的过程；
   B. 一种是计划驱动方法，另外一种是敏捷方法； （所有都是计划驱动）
   C. SCRUM适合迭代式场景，TSP适合瀑布场景； （两者都适合）
   D. 两种方法都需要进行度量数据收集、分析，从而支持管理决策；

2. 以下特征适用麦克勒格Y理论（McGregors Theory Y）激励的场合是：
   A. 关注工作环境，薪金等；
   B. 更喜欢经常的指导，避免承担责任，缺乏主动性
   C. 自我中心，对组织需求反应淡漠，反对变革
   D. 能够自我约束，自我导向与控制，渴望承担责任

3. 以下关于马斯洛的需求层次理论描述不正确的是：
   A. 自我实现是寻求自尊（Esteem）
   B. 激励来自为没有满足的需求而努力奋斗
   C. 低层次的需求必须在高层次需求满足之前得到满足
   D. 满足高层次的需求的途径比满足低层次的途径更少

4. 以下关于团队动力学的论述，不恰当的是：
   A. 马斯洛的需求层次理论可以用来更好地维持激励水平； （马斯洛的需求层次理论知道怎么激励，维持激励需要及时的绩效反馈）
   B. 智力工作的激励方式中，应该尽可能使用鼓励承诺这种方式；
   C. 麦克勒格的X理论适合用马斯洛底层需求激励；
   D. 海兹伯格的激励理论区分为内在因素和外在因素两种

2.1.3. 第四讲

1. 下列关于挣值管理方法的描述中正确的是：
   A. 挣值管理中进度的计算可以区分悲观和乐观两种方式（悲观乐观 50 50 / 100）
   B. 挣值管理的简单、中级和高级实现三种方式中，只有高级实现才会涉及成本因素
   C. 挣值管理与项目类型无关
   D. 挣值管理不适用与需求频繁变更的软件项目管理中（挣值管理适用需求频繁变更）

2. 下述关于WBS的描述中，哪些说法不正确的？
   A. WBS应该对应OBS
   B. WBS提供了范围管理的基础
   C. WBS工作分解最底层的要素是实现目标的充分必要条件
   D. WBS分解的时候，同一层不能应用不同标准

3. 下述关于EVM的描述中，哪些说法不正确的？
   A. EVM不适用于质量管理
   B. EVM的中级实现中引入成本信息
   C. EVM高度依赖估算准确
   D. EVM可以适应需求变更

2.1.4. 第五讲

1. 关于PSP质量管理策略，下列说法中正确的是：
   A. 用缺陷管理替代质量管理，既有必要性，也有合理性；
   B. 基本无缺陷的开发是通过开展高质量的评审来实现的；
   C. 经过训练，评审是所有消除缺陷的手段当中最高效的； (编译是最快的)
   D. PSP质量策略主要解决的是外部质量，而非内部质量；

2. 关于DRL，下列说法中不正确的是：
   A. 这是一种模块级开发中质量控制的指标
   B. DRL以单元测试每小时发现缺陷率作为基准，考察上游其他缺陷消除阶段的消除效率；
   C. DRL以单元测试发现的缺陷个数作为基准，考察上游其他缺陷消除阶段消除缺陷的效率；
   D. DRL只能预测，不能度量（DRL 只能度量）

3. 关于PQI，下列说法中不正确的是：
   A. PQI表征模块级别开发中的过程规范化程度
   B. PQI越高越好，可以充分保障质量； （成本高）
   C. PQI越低越好；
   D. PQI不能用作质量规划 （可以用于质量规划）

4. 关于PQI，下列说法中正确的是：
   A. PQI可以辅助判断模块开发质量
   B. PQI可以提供过程改进的依据
   C. PQI确保大于1，从而确保开发质量； （0~1）
   D. PQI只能预测，不能度量（可以预测、也可度量）

5. 关于Yield，下列说法中正确的是：
   A. Yield可以辅助判断模块开发质量
   B. Yield可以提供过程改进的依据
   C. Yield区分为Process Yield和Phase Yield；
   D. Yield只能预测，不能度量（因为不能证明一个程序没有 bug）

6. 关于评审速度，下列说法中正确的是：
   A. 进行代码评审的时候，控制评审速度不超过每小时1000LOC就能实现大部分质量要求；
   B. 实战中，评审速度应该根据资源水平而定，时间充分就评审慢一些；
   C. 文档评审速度应该控制每小时不超过4页；
   D. 评审速度与人的技能有关，技能强的人可以突破 每小时1000 LOC代码这个限制；

7. 关于Humphrey 梳理的Quality Journey，下列说法中正确的是：
   A. Quality Journey中列出的步骤可以在适当的时候更换顺序；
   B. 由于需求是一切工程活动的基础，因此加强需求开发应该是Quality Journey早期的必备步骤；
   C. Quality Journey仍然仅仅是在“用缺陷管理替代 质量管理”这一基本策略之下进行讨论；
   D. Quality Journey中测试应该先于评审得到贯彻和改善

8. 下述设计模板中用来记录内部动态信息的是：
   A. OST；
   B. SST；
   C. LST；
   D. FST；

9. 下述关于PSP四大设计模板和UML典型设计图 的描述中完全正确的是：
   A.OST在UML中没有对应的设计图； （用例图、时序图）
   B. UML中的类结构以及类之间的关系，在PSP四大设计模板中无法体现；
   C. LST在UML中可以通过类图来体现； （没有对应图示）
   D.FST在UML中可以通过类图来体现；（只有型构、缺乏方法的行为描述）

10. 一个完全正确的状态机应该满足：
    A.没有死循环和陷阱；
    B. 状态转化条件满足正交性；
    C.状态转化条件满足完整性；
    D.状态转化条件满足独立性；

11. 下列关于各种设计验证手段的描述中正确的是：
    A.执行表是唯一一种提供全面设计验证的手段； （符号化验证才是）
    B. 跟踪表是唯一一种提供全面设计验证的手段； （符号化验证才是）
    C.受限于手工方式，都易于出错；
    D.符号化执行验证不适合复杂的计算过程；（适合复杂的计算过程，不适合复杂逻辑）

12. 下述关于质量的描述中，哪些说法不正确的？
    A. 质量是一种多重属性的组合
    B. 最终用户一般不能感知内部质量
    C. 安全和保密一般不是质量要素
    D. 质量与主观感受有关

13. 下述关于质量控制指标，哪些说法正确？
    A. A/FR应该是越高越好（2.0就好，太高了代价大）
    B. Yield是一种精确度量模块质量的手段（估计度量）
    C. 评审活动应该早于编译或者测试活动而开展（评审放前还是放后的时间开销是一样的，但是先评审可以改错，减少编译和测试的时间）
    D. PQI只能事后统计，不能用于指导质量计划（PQI 可以预测和度量，可以指导质量计划）

14. 下述设计验证手段的描述，哪些是正确的？
    A. 符号化执行容易引入人为错误
    B. 状态机验证是唯一一种提供一般意义的上的正确性检验的验证手段（至少还有符号化验证）
    C. 执行表的对设计缺陷的验证能力强于跟踪表（弱于跟踪表，跟踪表是执行表的扩展）
    D. 正确性检验是唯一可靠的设计验证手段（真值表也是）

15. 关于使用程序正确性证明手段验证while-do循 环设计的描述中，正确的是：
    A. 如果设计是正确的，那么应满足的条件之一是循环判断条件最后一定可以变为false；
    B. 如果设计是正确的，那么应满足的条件之一是循环判断条件为真的时候，单独的循环结构执行结果与 循环体再加一个循环结构，其执行结果一致；
    C. 如果设计是正确的，那么应满足的条件之一是循环判断条件为false的时候，循环体内所有变量不能被 修改；
    D. 该方法并不能保证循环体算法实现设计意图。

2.1.5. 第六讲

1. 下面描述属于典型客户需求的是：
   A.客户期望；
   B.预算限制；
   C.法律法规限制；
   D.系统功能描述

2. 在团队设计活动中，应该注意设计标准，下列属于典型的设计标准应该约定的是：
   A.命名规范；
   B.接口标准；
   C.出错或者异常处理信息；
   D.设计表示方式

3. 典型地，在团队设计活动中，应该注意哪些内容：
   A.设计标准的应用；
   B.复用的考虑；
   C.可测试性支持；
   D.可用性支持

4. 关于集成策略，下述描述中正确的是：
   A. 当待集成组件质量普遍不高的时候，不可以使用扁平化策略； （不可大爆炸，但是可以扁平化）
   B. 当需要尽早获取可以工作的组件的时候， 应该使用集簇式策略；
   C. 当待集成组件质量普通较高的时候，可以使用大爆炸式集成策略；
   D. 持续集成本质上就是逐一添加策略。

5. 当考虑集成策略的时候，应该注意如下哪些方面？：
   A. 待集成组件的质量状态；
   B. 待集成组件的获取方式；
   C. 待集成组件的功能和关系；
   D. 待集成组件的数量；

6. 关于扁平化集成策略和集簇式集成策略，下述说法中正确的是：
   A. 扁平化策略可以较早地充分地暴露系统级别的错误； （不能充分）
   B. 扁平化策略对于系统级别错误的暴露能力有限；
   C. 集簇式集成策略有助于复用策略的实现；
   D. 扁平化策略和集簇式策略的优缺点正好相反；（大爆炸和逐一添加是相反的，扁平化和集簇式不是）

7. 下述活动是典型的验证（Verification）的是：
   A. 需求评审；
   B. 详细设计评审；
   C. 单元测试；
   D. 试运行；

8. 下述活动是典型的确认（Validation）的是：
   A. 验收测试；
   B. 代码评审；
   C. 系统测试；
   D. 持续集成；

9. 下述产物中属于典型的确认（Validation）对象的是：
   A.接口设计文档；
   B.源代码；
   C.用户手册；
   D.系统使用培训材料（视频、录像等）；

10. 下述关于需求开发的描述中，哪些是正确的？
    A. 客户需求是指客户提出的关于软件功能的具体要求 （功能的描述是解决方案，不是客户需求，是产品需求）
    B. 工期或者预算往往都是客户需求的一个方面 （法律法规、现有接口、环境等）
    C. 产品需求需要跟客户充分讨论才能获取
    D. 客户应该在需求开发活动中起到主导作用

2.1.6. 第七讲

1. 下述产物中属于典型的配置项是：
   A. 接口设计文档；
   B. 源代码；
   C. 用户手册；
   D. 系统使用培训材料（视频、录像等）；

2. 团队内部的配置审计通常应该关注什么：
   A. 物理审计；
   B. 配置项列表；
   C. 配置管理记录；
   D. 基线计划；

3. 下列关于决策分析的论述中，不恰当的是：
   A. 决策分析指南中最关键的是明确需要开展决策分析活动的判定标准，即什么场合之下需要开展正式的决策分析活动；
   B.评价方法是体现决策者利益诉求的关键，因此，需要谨慎设计； （评价标准才是关键）
   C.候选方案的识别应该晚于于评价标准；
   D.现实生活中的项目投标就是一个典型的决策分析活动；（招标才是决策分析过程）

4. 下列关于根因分析的论述中，不恰当的是：
   A. 根因分析必须基于丰富的数据来选择合适的问题； （有的时候没有丰富的数据）
   B. 鱼骨图是根因分析的有效手段；
   C. 典型地，可以从技术、人员、培训以及过程角度开展根因分析；
   D. 根因分析活动终止的唯一特征就是找到相应的根因的明确解决方案；（或者确定没有解决方案）

2.2. 问答题

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

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

2. 【2023】下列说法是否正确，为什么?

   1. 软件过程管理是软件项目管理应该要实现目标：软件过程管理和软件项目管理完全是两回事，项目过程管理应当有专门的人去做。因此并不是实现目标，错误的。
   2. 在公司导入敏捷过程是我们今年过程改进的主要目标：过程管理和过程改进是类似的，这个说法在概念上是合适的，但是操作的时候可能存在问题。
   3. XP与CMM/CMMI是对立的两种软件开发方法：
      1. CMM和CMMI并不是软件开发方法，而是软件过程管理和改进，CMM和CMMI是没有较大区别的，错误的。
      2. XP是敏捷的软件开发方法
   4. CMM/CMMI不适合当今互联网环境的项目管理需求：CMM/CMMI是用来做过程管理和改进的，根本不是满足项目管理需求的手段，正确的。
   5. PDCA和IDEAL不适合在敏捷环境中使用：PDCA，IDEAL是软件过程改进参考元模型，因此是适合在敏捷环境中使用的，错误的。
   6. 不同的软件开发过程应该使用不同的生命周期模型，反之亦如此：生命周期模型是由人类划分的，不一定，错误的

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

   1. 规模估算往往可以依据历史数据来完成，其原因在于规模估算结果的偏差产⽣原因相对客观，偏差可以⽤以修正新的估算结果。
   2. 时间估算的偏差产⽣原因更加复杂，⼀⽅⾯和规模有关，另外⼀⽅⾯，跟⼈的主观能动性 有关，因此，时间估算偏差的原因可能估算结果本身，这使得历史数据中时间偏差可参考价值不⼤。
   3. 从上述讨论可以得出，对于估算来说，本质上是⼀种猜测，追求的⽬标应该是⼀致性以及估算结果的使⽤者对估算结果的信⼼。使用⼀些统计⽅ 法可以⽤来调整估算结果，增强⽤户对估算结果的信⼼。 但是这种估算⽅法⾮常依赖⾼质量的历史数据，⼀旦数据不完整或者缺失，就可能导致估 算结果有显著偏差。

4. 【2020-mid】请结合软件开发的特点介绍软件项⽬管理中⾃主型团队的必要性以及⾃主团队应该具备的特征?

   1. 软件开发是⼀项既复杂⼜富有创造性的知识⼯作 (1’)
   2. 软件开发是⼀种智⼒劳动 (1’)
      1. 处理和讨论极其抽象的概念
      2. 把不同的部分(不可⻅)整合成⼀个可以⼯作的系统
   3. ⾃主团队具备如下的特点: (每两点1分)
      1. 自行定义项⽬的⽬标
      2. 自行决定团队组成形式以及成员的⻆⾊
      3. 自行决定项⽬的开发策略
      4. 自行定义项⽬的开发过程
      5. 自行制定项⽬的开发计划
      6. 自行度量、管理和控制项⽬⼯作

5. 过程改进模型可不可以作为评价公司能⼒的标准？⽐如某公司宣称⾃⼰达到了CMMI 5級，开发能⼒⽐⾕歌 强，你认为合理吗？

   结论：不可以.CMMI不是过程优劣的标准，也不适⽤作公司之间的能⼒⽐较，它是每个公司⾃我反思改进的依据。 理由： 由于企业所处环境以及业务⽬标等的差异，过程改进模型对不同企业的含义不同。

6. 第⼀次开会的时候，为什么要构建⾼质量软件不是⼀个怡当的计划？

   回答：可以⽤期望理论来解释 期望理论的公式是：Motivation = Valence x Expectancy(Instrumentality)，即激发⼒量= 价值（效价）×完 成⽬标的可能性。但是显然在期望理论上，这在提⾼了Valence的同时，却也提⾼了完成的难度，降低了公式⾥的期望值Expectancy。如果开发团队认为完成项⽬的难度过⾼，反⽽会降低整个团队的凝聚⼒、信心和⼯作效率。

7. 估算和实际完全⼀样，问准不准

   1. 场景⼀：规模：估算1000LOC，实际1000LOC
   2. 场景⼆：时间：估算50⼩时，实际50⼩时

   答案：不能简单地说：历史数据能⽤，估算和实际相同就⼀定估算准确，在说历史数据时需要分类，如果是规 模可以认为可以相信，⽽时间不能随便相信。规模⽅⾯，认为这种是准确的，时间⽅⾯，⽆论⼤⼩，都不该认 为是准确或者可以信任的。因为时间可能就是估算多少时间，就按照多少时间去完成，假如估算60⼩时，最 后可能上报完成时间就是60⼩时

8. 从定义需求到⽇程计划，定义需求、概要设计是⼈⼯⼲预的，估算和⽇程是⽤模型⾃动产⽣的，⽇程计划有⼀ 半⼈⼯⼲预、⼀半⽣成，这样做会带来什么的好处？

   可以更能扛住别⼈的质疑：

   定义需求： 需求是否精准，需求是否需要存在，需求需要多少时间和规模

   团队资源⽔平： 不要轻易做出承诺，基于历史数据和计算机⽩动⽣成的估算不会被⼈质疑

9. 【2013】【2021】基于Yield指标构建缺陷预测模型，并列举该模型的可能改进⽅案

   1. 总体思想：利⽤回归技术预测软件开发过程中各阶段的缺陷注入率和Yield(缺陷消除率) Yield指标只能⽤来估算，不可以⽤来度量。
   2. 结合Yield指标和上图，只需要知道如下指标就可以基于Yield指标构建⼀个基本的缺陷预测模型：
      1. 注⼊阶段注⼊多少缺陷
      2. 缺陷注⼊的密度（需求每⼀⻚注⼊多少缺陷）
      3. 缺陷注⼊的速度（每⼩时注⼊多少缺陷）
      4. 消除阶段的缺陷注⼊密度和速度。
      5. 历史数据中的软件规模、⽂档规模、开发⼈员规模
   3. 可能的改进⽅案：可能的改进是假设注⼊⽔平和消除⽔平都符合正态分布，因此，可以⽤蒙特卡罗⽅法模拟结果。

3. 2024 软件质量管理题

3.1. 选择题

全部ppt上的题，但个别题做了修改，需要注意

如 PPT 上是

下述产物中属于典型的确认（Validation）对象的是：
A.接口设计文档；
B.源代码；
C.用户手册；
D.系统使用培训材料（视频、录像等）；

但试卷上问

下述产物中属于典型的验证对象的是：
A.接口设计文档；
B.源代码；
C.用户手册；
D.系统使用培训材料（视频、录像等）；

3.2. 简答题

1. 生命周期模型与软件过程的区别；很多人认为瀑布模型是在官僚式的，重型的，谈谈你的理解

2. 什么是质量管理；为了做到质量管理，需要做什么？

3. 描述Quality Journey

4. 结合“凡战者，以正合，以奇胜”，谈谈对敏捷宣言的理解

5. 自主型团队的必要性以及自主团队应该具备的特征

6. 谈谈对估算的理解和开展估算

7. 软件定量管理的基本范式

8. 结合过程改进模型的特性，谈谈CMM/CMMI对当前软件开发实践的价值