2023秋季《软件质量保障》课堂笔记

课堂笔记

0.开始之前

1. 项目管理
   1. 什么是项目管理，项目管理的这些方法有哪些
   2. 那软件项目估算的时候到底该如何去做这个估算
   3. 对于这个计划的跟踪来说，你该如何去做这个计划的跟踪？
   4. 什么是配置管理？配置管理的要点是什么
   5. 风险管理？通常有哪些做法，比如说风险的识别风险的系数通常指的是什么？这些是一些就是围绕着项目管理的一些基本概念。
2. 质量管理
   1. 怎么来做质量管理？
   2. 通过什么一些质量实践质量指标
   3. 然后怎么来进行跟踪
3. 软件过程
   1. 为什么要有这个软件过程，为什么要有生命周期模型，这个过程跟这个生命周期模型之间的这个关系究竟是什么？
   2. 从一个人的一个过程，到一个小组的一个过程，这背后从团队的动力学角度来说，有哪些东西是要特别在意的
   3. 什么叫自组织的团队，自组织的团队到底有什么样一些特点

十大问题

1. 软件过程管理和软件项目管理是不是一回事？如果不是，两者差异是什么？

   1. 软件过程管理更多关注的是什么？类似于做流水线的升级改造这样的一些工作，本质上它关注的是过程本身。也就是对于软件开发来说，一个企业的软件开发所使用的方法所使用的工具，这些是不是最适合的？这个工具如果不好了，我们该怎么去进行优化，你的这个方法如果不好了，该怎么去进行调整，这个其实是属于软件过程管理的概念。
   2. 软件项目管理是针对于特定的一个项目组，项目目标的一个实现。如一个软件项目小组或者说某一个特定软件项目的成本质量、工期、要实现的这些目标。项目管理关注的是目标的一个实现。
   3. 所以软件过程管理跟软件项目管理是两个完全不一样的东西。
   4. 发散一下，CMMI指导的是软件过程管理、软件过程改进，而不是软件项目管理。

2. 软件估算过程中，项目经验/历史数据的作用是什么？您的答案经得起细问吗？比如，能具体解释如何把项目经验/历史数据转变成估算结果？估算结果经得起时间考验吗？比如，隔了3个月，能保证估算结果一致？

   1. 充分考虑团队动力学方面，怎样有更好的激励？
      1. 完成任务后价值越大，激励程度越高
      2. 自己所认为的成功的把握
   2. 估算尽可能要细一点，建立起对结果的信心。用相对大小，有规模的描述（如历史数据），对历史数据进行适当加工变成抽象的，拥有标准和尺度的数据。

3. 所以，估算究竟追求的目标是什么？

   1. 估算追求所有的参与者对规范结果的一个认同。而不是追求估算结果客观上的正确性（做不到）。这是互相讨论、妥协、认同的过程。如果偏的离谱也没关系，大家都认可更重要。看起来是猜测，但没关系，大家达成一致就可以。
   2. 一个问题：假设你的估算结果和实际结果都一样，能不能认为估算准确？从规模看，可以说准确，但从时间上看，不一定是估的准，可能只是只给了你这么多时间，所以完成。

4. 什么叫做XX管理？管理的要素有哪些？如何区分有管理（或者好的管理）还是没有管理（或者不好的管理）？这种判断如果只能事后从结果判断，有意义吗？

   1. 三要素：有目标、状态跟踪、纠偏措施。企业里面的认知：测试、review、自动评审、代码扫描，比较混乱。三要素是核心。
   2. 目标：一般是高质量开发。要定义的具体，比如高质量有数据去量化、刻画（每千行的缺陷数不要超过一个）
   3. 状态跟踪：最终结果出来之前，比如单元测试做了，验收还没做，可以回答最终验收测试时，每千行的缺陷数不要超过一个的质量目标能否实现？当前的状态不能支持目标实现，就纠正；可以支持，就维持。
   4. 困难点就是状态跟踪：【状态跟踪的方法】
      1. 如果构建预测模型出来（见软件定量管理和过程建模仿真），输入xy去预测z当然就可以。
      2. 或者做一些数据：把单元测试的代码覆盖率和最终交付的曲线密度做线性回归、或者相关性检验，如果强相关就用小的预测模型建立单元测试的代码覆盖率和最终质量水平的线性关系就可以了，无需构建复杂XYZ很多的大模型。
      3. 基于历史经验：质检失效比A/FR（2.0以上）。PQI（0.4以上）达到了就说明质量目标是可以实现的。
   5. 怎么支持Z？一堆Y。怎样支持Y，一堆X、Y是单元测试的某一阶段。质量管理要有这样关系的体现。【预测模型】

5. 接上一问题，什么叫做软件质量？当您宣称做了质量管理，实际上真的对质量有管理吗？

   1. 质量的路线图：明确告诉怎样追求极高的质量，哪些先做哪些后做，跟质量概念有关。

6. 正确建立对敏捷宣言的理解：

   1. 本质上讲有些东西是基础，而有些东西是锦上添花。
   2. 没有右项，左项是没有意义的。仍然要有文档、流程和工具。
   3. 如何判断右项如果做得足够了开始重视左项？需要经验的判断，看当前项目的状态和上下文。
   4. 同样瀑布模型也需要经验。首先，不是单一模型，从最简单到最复杂。根据项目的特点，越复杂越有挑战性，融入过程的元素应该越多。但很多人过低地判断了项目的难度和挑战，选择了过于简单的瀑布模型。

7. 从没有度量就没有管理/改进，到软件项目度量毫无意义，到包含2200多指标项的研发效能度量，到研发效能引发血案，这是想闹哪样？究竟要不要度量？

   1. 要理解度量体系的构建。GQM方法。规模越大，度量要求肯定越高。度量要服务于你管控的目标
   2. Goal Question Metrics

8. 从极度反对CMM到自己搞开发运维一体化成熟度模型，所以，这是成熟度模型的问题？还是其他问题？

   1. 成熟度模型不是软件项目管理方法，是过程改进的参考模型。
   2. 描述的是，过程/企业从不成熟到成熟的路线图。只要能用过程描述的一件事情，成熟的路线图永远都是一样的。（决定了CMM和CMMI的价值）
   3. 一个软件/模块开发，刚开始自己定义步骤；接下来和别人融合、借鉴、分享、提升，把过程做成标准过程；四级：通过一些数据模型做更好的管控，比如对未来结果的预测；五级：优化自己的过程，让生产效率、质量水平越来越高，叫做持续优化。
   4. 揭示了某种客观规律，任何一个过程，从不成熟到成熟走的路线都是一样的。

9. 定量管理的本质是什么？用数据就是定量管理了？DevOps模式下，还需要定量管理吗？

   1. 定量管理的基本范式。
   2. 一定要看到定量模型，然后用构建的模型指导项目实践。
   3. 建模过程中，想办法提高对未来结果的预测能力：消除异常、应用统计方法、检验等。
   4. 用数据的简单应用不是定量管理，但数据是前提条件，一定要看到模型。
   5. 模型的搭建是自顶向下的过程，识别一堆Y->识别一堆X。X称之为关键子过程性能的关键影响因素。
   6. 定量管理的本质：把关键影响因素控制好了，期望Y、Z都能符合要求。
   7. DevOps下也要做定量管理，还能做得更好。传统项目中人会介入；DevOps迭代速度快、数据更多、质量也高（人的干扰少，自动化工具产生），统计角度标准差小，数据可用性高，所以做定量管理可以更好。

10. 关于工程实践。需求分析究竟要解决什么问题？设计究竟要设计什么？测试的目的是什么？为实现这个目的，测试实践的重点应该是什么？

    1. 严格区分客户需求和产品需求。客户需求是问题，产品需求是解决方案。
    2. 设计：内部外部动态静态四个象限的内容填满。设计的标准、可用性、可测试性，要在设计过程中注意。
    3. 测试：跟VER and VAL有关。验证(Verification)和确认(Validation)
       1. 测试不是提升质量水平的手段，是帮助我们掌握质量状态的手段。
       2. 验证(Verification)关注产品需求有没有得到体现，解决方案从设计出来到开发完成有没有偏，有没有正确实现。
       3. 确认(Validation)关注客户需求有没有得到满足，客户期望解决的问题有没有很好的解决。
       4. 测试时的侧重点：
          1. 集成测试：功能和一开始设计的是或否一样。CI（持续集成）
          2. 验收测试/试运行测试：不是关注有没有错误/功能实现，是从用户的角度，想要解决的为有没有解决好。

1.概述

软件开发的四大本质难题

四大本质难题是什么

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

四大本质难题之间的关系

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

几个注意点

1. 软件开发四大本质难题永远存在，不可能彻底解决，在不同时期凸显程度有差异。
2. 软件开发本质上是智力劳动，开发者心理方面的因素不可忽视

软件发展

软件发展的两个趋势：规模+比例

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

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

主要体现有：

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

软件工程

1. 软件工程是一门研究用工程化的方法构建和维护有效的、实用的和高质量的软件的学科。
2. 软件工程的两大视角
   1. 管理视角：能否复制成功？
   2. 技术视角：是否可以将问题解决得更好？

管理

1. 管理的三大关键要素：目标、状态（是在接近目标还是在远离目标）和纠偏。
2. 大部分情况下，管理仅仅是视图复制其他地方（场景）的成功，但是这种复制一般不容易
3. 软件项目管理是为了降低/减少各种无谓的损耗来实现本该有的性能。
4. 软件过程改进是为了达到更好的效能，其中质量/缺陷是首要目标或限制。

软件项目管理

1. 典型的三大目标：成本、质量和工期。
2. 定义：软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。
   1. 软件项目管理包括估算、计划、跟踪、风险管理、范围管理、人员管理、沟通管理等等。
   2. 软件项目管理的对象是各类软件项目
3. 可以细分为两种管理视角：软件过程与生命周期模型

软件过程

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

广义软件过程：

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

生命周期模型

1. 生命周期模型是对软件过程的一种人为划分。
2. 生命周期模型是软件开发过程的主框架，是对软件开发过程的一种粗粒度划分
3. 生命周期模型往往不包括技术实践
4. 典型生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法等等。

软件过程管理

1. 软件过程管理的对象是软件过程。
2. 软件过程管理的目的是为了让软件过程在开发效率、质量等方面有着更好性能绩效（Performance）

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

1. 两者含义接近
2. 软件过程管理参考模型 CMM/CMMI，SPICE 等。
3. 软件过程改进参考元模型PDCA、IDEAL 等。

思考和讨论

A.软件项目管理关注项目目标的实现，软件过程管理关注过程本身，这里应该改成软件项目管理。错。

B.过程管理和过程改进是类似的，过程管理会关注一个企业软件开发所使用的方法、工具是否适合？这个工具/方法如果不好了，怎么去进行优化/调整。对。

C.CMM和CMMI并不是软件开发方法，而是软件过程管理/改进模型。XP是敏捷软件开发方法。错。

D.CMM和CMMI是软件过程管理/改进模型，不是软件项目管理，对。

E.PDCA，IDEAL 是软件过程改进参考元模型，适合在敏捷环境中使用的，错。

F.生命周期模型是对软件过程的一种人为划分，所以可能一样，错。

答案：BD

A.是的，CMMI是软件过程管理/改进模型

B.CMMI不是过程优劣的标准，也不适用作公司之间的能力比较，它是每个公司自我反思改进的依据。理由:

1. 由于企业所处环境以及业务目标等的差异，过程改进模型对不同企业的含义不同。
2. （例子1）一个银行, 它的开发模型可能对软件的数据一致性、可靠性有很高的要求，它的开发模型可能会更侧重测试、原型等。而另一个嵌入式方向的公司，它的开发模型就会更关注性能。
3. （例子2）或者说一个项目每天更新100次，不一定比一个每天更新1次的项目，就更有创新或更有价值。

因此，成熟度等级不应该脱离企业环境直接横向比较；处于相同的成熟度等级，也并不能说明这些企业的研发能力也是相同的。

C.敏捷是开发方法/软件过程，CMMI是软件过程改进模型

软件过程管理/改进模型：CMM

1. 定义：CMM 是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。
2. 级别：分为五个级别，一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

等级一：初始级 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 Capability Maturity Model Integration 成熟度模型

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

等级一：初始级

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

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

等级二：已管理级

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

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

等级三：已定义级

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

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

等级四：定量管理级

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

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

等级五：优化级

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

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

一些理解

1. CMM/CMMI 不适用于软件开发的原因
   1. CMM/CMMI 并不是一种具体的软件过程或者软件开发方法
      1. CMM/CMMI 建立了一组有效地描述成熟软件组织特征的准则。
      2. CMMI 是过程改进模型而非软件过程或者软件过程模型：CMMI 指导软件过程改进，不指导开发。
      3. 按照 CMM/CMMI 模型的要求，一个软件组织应当定义使用本软件组织特点的软件过程，并且不断优化该过程，来更好地实现软件组织的商业目标。
   2. CMM/CMMI 并不能作为检验软件过程优劣的标准：过程改进对不同企业的含义不一样，成熟度等级无法脱离企业环境直接横向比较。
   3. CMM/CMMI 与其他软件过程或者软件开发方法的比较是没有任何意义的。
2. 一些误解：
   1. CMMI 模型需要适当裁剪以适应公司的实际情况：需要裁剪的是公司内部定义的组织级开发流程和开发规范。
   2. CMMI 模型太重了，不适合互联网时代的轻量级开发：这个说法的错误之处在于，不一定是 CMMI 重或者轻，而是，CMMI 根本就不是开发模型。
   3. CMMI 模型只适合大公司、大项目，不适合小项目：首先没人检验过；其次，项目的大小衡量本身也缺乏值得信赖的参考依据；最后，接受这种说法的人还是把 CMMI 当成是一种特殊的开发模型。
   4. CMMI 模型只适合需求不变或者很少变化的场合，不适合需求不确定，变化很多的场合：CMMI 不是开发模型，与需求变化与否无关，谈不上适应或者不适应。
3. CMMI 不是过程优劣的标准，也不适合用作公司之间的能力比较，说法怎么样？对的，CMMI 本身是有评级。（美国国防部订单招标要求企业至少达到 CMMI 的 3 级。因为公司的能力需要绝对东西，也就是能力强，能力弱，而 CMMI 衡量的是相对的水平，CMMI 仅仅关注在本公司的目标下的等级
4. 更多讨论：试论 CMM/CMMI 不适合在当前软件开发当中应用的原因

软件过程管理模型：ISO/IEC 1504

1. 也叫 SPICE（Software Process Improvement and Capability Determination）
2. 过程类别共有五种，分别是
   1. 客户-供应商（CUS)过程
   2. 工程（ENG）过程
   3. 支持（SUP）过程
   4. 管理（MAN）过程
   5. 组织（ORG）过程

软件过程框架：RUP

1. Rational 统一过程（Rational Unified Process）
2. 最佳实践
   1. 迭代式开发
   2. 管理需求
   3. 使用基于构件的体系结构
   4. 可视化建模
   5. 验证软件质量
   6. 控制软件变更
3. RUP 软件开发生命周期
   1. 初始阶段：建立业务模型，定义最终产品视图，并且确定项目的范围
   2. 精化阶段：设计并确定系统的体系结构，制定项目计划，确定资源需
   3. 构建阶段：开发出所有构件和应用程序，把它们集成为客户需要的产品，并且详尽地测试所有功能
   4. 移交阶段：把开发的产品提交给用户使用

软件过程改进模型

1. 重点关注“过程质量”，强调“持续改进”
2. 获得 ISO 9000 标准认证的企业应该具有 CMM 第 2~3 级的水平

软件质量管理发展：软件质量大师的主要观点和贡献、工作

描述下述质量管理大师的主要观点和贡献，工作对软件过程和项目管理的借鉴意义

Shewhart

1. 最早将统计控制的思想引入质量管理，是质量改进奠基人;
2. 提出 PDS 模型（计划执行检查 Plan-Do-See)，后被戴明进一步发展为 PDCA。

2.软件过程的历史演变和经典工作

软件发展的三大阶段：

1. 软硬件一体化阶段：软件完全依附于硬件，软件作坊（50 年代到 70 年代）
2. 软件成为独立的产品（70 年代到 90 年代）
3. 网络化和服务化（90 年代中期至今）

软硬件一体化阶段

软件完全依赖于硬件

1. 软件应用典型特征：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更。
2. 软件开发典型特征：硬件太贵、团队以硬件工程师和数学家为主。
3. 典型软件过程和实践
   1. 非常线性
   2. 三思而后行（measure twice，cut once）
   3. 编码+改错 Code and Fix

软件作坊

1. 软件应用典型特征：功能简单、规模小。
2. 软件开发典型特征：很多非专业领域人员涌入软件、高级程序语言出现、质疑权威文化盛行。
3. 典型软件过程和实践：
   1. Code and Fix：不适合大型软件项目开发！

软件成为独立的产品

1. 软件应用典型特征：
   1. 摆脱了硬件的束缚（OS）
   2. 功能强大
   3. 规模和复杂度剧增
   4. 个人电脑出现 -> 普通人成为软件用户
      1. 需求多变
      2. 兼容性要求
   5. 来自市场的压力
2. 典型软件过程和实践
   1. 形式化方法：将所有的方法当作数学方法，做数学化的检验，主要解决质量和正确性问题。
   2. 结构化程序设计和瀑布模型
      1. 自顶向下，逐步求精。
      2. 问题和不足（效率和质量）
         1. 形式化在扩展性和可用性方面存在不足。
         2. 瀑布模型成为一个重文档、慢节奏的过程。
   3. 成熟度模型

网络化和服务化

1. 软件应用典型特征：
   1. 功能更复杂、规模更大
   2. 用户数量急剧增加
   3. 快速演化和需求不确定
   4. 分发方法的变化（SaaS）
2. 典型软件过程和实践：
   1. 迭代式大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成，而是通过多个迭代周期，逐步来交付。
   2. 雪鸟会议和敏捷宣言
      1. 个体和互动 胜过 流程和工具
      2. 可以工作的软件 胜过 详尽的文档
      3. 客户合作 胜过 合同谈判
      4. 响应变化 胜过 遵循计划
      5. 尽管右项有价值，但是我们更重视左项的价值
   3. XP eXtreme Programming 方法：偏重于一些工程实践的描述
   4. Scrum：管理框架和管理实践。
   5. KanBan
      1. 精益生产（丰田制造法）的具体实现
      2. 可视化工作流、限定 WIP(制品)、管理周期时间
   6. 开源软件开发方式：
      1. 一种基于并行开发模式的软件开发的组织与管理方式。
         1. Linus 定律：如果有足够多的 beta 测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。
         2. “早发布，常发布，倾听用户的反馈”、“把你的用户当作开发合作者对待，如果想让代码质量快速提升并有效排错，这是最省心的途径”、“设计上的完美不是没有东西可以再加，而是没有东西可以再减”
         3. 代码管理：严格的代码提交社区审核制度
      2. 一些演化：内部开源（inner source）、众包（Crowdsourcing）

当前软件发展现状

1. 软件应用典型特征
   1. 进一步服务化和网络化（移动是主流）随处可见（pervasive）
   2. 用户需求的多样性进一步凸显
   3. 软件产品和服务的地位变化
   4. 错综复杂的部署环境。
   5. 近乎苛刻的用户期望
      1. 多：功能丰富，个性化
      2. 快：快速使用，及时更新，快速解决问题
      3. 好：稳定，可靠，安全，可信
      4. 省：用户的获得成本低，最好免费
2. 软件开发的典型特征
   1. 空前强大的开发和部署环境：XaaS，IaaS、PaaS、SaaS、FaaS
   2. 盛行开源和共享文化‘
   3. 盛行敏捷开发
   4. 软件工程的潜在支撑力量获得了长足进步（AI、大数据、云计算）
3. 【2021Fall】典型DevOps实践和方法：
   1. 方法论的基础是软件敏捷开发、精益思想和看板 KanBan 方法
   2. 以领域驱动设计为指导的微服务架构方式
   3. 大量虚拟化技术的使用
   4. 一切皆服务 XaaS(X as a Service) 的理念指导
   5. 构建了强大的工具链，支持高水平自动化。

思考与讨论

答案：B。三思而后行。在软硬件一体化阶段，硬件成本非常高的环境下，编码完成后需要对代码进行详细的审阅，确认无误后再交给硬件运行。

现在：机器成本低，人力成本高，所以让机器反复测试验证产品，再让人工跑测试

答案：C。云计算化和虚拟化属于网络化。软件作坊属于软硬件一体化。

答案：A。

A.软硬件一体化阶段-软件作坊

B.网络化与服务化

C.D.软件成为独立的产品

答案：A

3.团队动力学

1. 软件开发的特点
   1. 软件开发是一项既复杂又富有创造性的知识工作。
   2. 软件开发：智力劳动，需要处理和讨论极其抽象的概念，并把不同的部分（不可见）整合成一个可以工作的系统。
      1. 要求从事软件开发的工程师
         1. 必须全身心地参与工作：知识工作必须是全身心投入的，任务切换一般需要 30 分钟才能全身心的投入。
         2. 主观意愿上努力追求卓越。
      2. 要求管理者激励并维持激励
         1. 激励手段
         2. 维持激励手段
2. 管理知识工作的关键规则是：管理者无法管理工作者，知识工作者必须实现并学会自我管理
   1. 要自我管理，知识工作者必须（自我管理的前提条件）
      1. 有积极性
      2. 能做出准确的估算和计划
      3. 懂得协商承诺
      4. 有效跟踪他们的计划
      5. 持续地按计划交付高质量产品。
   2. 知识工作者实现自我管理：胶冻状团队。
3. 知识工作者的管理需要的是领导者，而不是经理，领导者需要诚实、有能力、有远见、鼓舞人心。

领导者激励手段

1. 威逼：完全依靠不同角色的等级关系，通常是上级强制要求下属必须完成某些工作。
2. 利诱：通过许诺一定的好处来吸引下属努力工作
3. 鼓励承诺：
   1. 建立承诺文化，利用软件工程师希望得到别人尊重的心理，鼓励他们合理承诺并努力满足承诺，从而得到别人的尊重。
   2. 位于马斯洛需求理论的 4 级以上，应当是主要的方式，并且最好以团队为单位做出承诺

交易型领导方式

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

转变型领导方式

1. 用成就激励
2. 鼓励承诺属于转变型领导方式。
3. 由于交易型领导方式很少能产生成功并且有创造性的团队，因此转变型领导方式是首选。

马斯洛的需求层次理论

1. 五个层次：生理需求（Physiological)、安全感（Safety)、爱和归属感（social)、获得尊敬（Esteem)、自我实现（Self-Actualization)
2. 注意
   1. 自我实现是最高的层次。
   2. 激励来自为没有满足的需求而努力奋斗。
   3. 低层次的需求必须在高层次需求满足之前得到充分满足。
   4. 满足高层次的需求的途径比满足低层次的途径更为广泛。
3. 威逼利诱比较低层，鼓励承诺在 4-5 层，效果比较好

承诺形式的激励

1. 在个人级别，承诺有很大差异

   1. 有些人对承诺非常认真
   2. 有些人对承诺非常轻率。

2. 在满足以下条件下，团队承诺比个人承诺的激励作用更大

   1. 所有团队成员共同参与作出承诺。
   2. 团队依赖于每一位成员履行自己的承诺。
   3. 如果有计划在支撑承诺，那么就更为可信

3. 软件开发团队在制定承诺时，需要保证：

   1. 承诺是自愿的公开的、可信（行）的
   2. 向团队做出承诺。

   1. 承诺需要有详细计划支撑
   2. 开发者需要参与承诺的协商和设计。

除了以团队形式作出承诺以外，承诺文化的建立还要求在项目进行过程中维持承诺水平。

1. 及时提供各种反馈信息是维持承诺的有效手段。
2. 反馈信息包括项目进度、更新后的项目计划以及里程碑实现情况等。

leader 和 manager 的区别

维持激励水平

维持激励需要及时的绩效反馈

1. 绩效反馈包括

   1. 根据一个详细计划衡量进度。
   2. 当前计划不准确时重做计划
   3. 为漫长而富有挑战性的项目提供中间反馈，即里程碑

2. 激励水平的重要影响因素

   1. 回报：回报越大，激励水平越高
   2. 期望：完成这件事情的把握越大，激励水平越高

其他激励相关理论

海兹伯格的激励理论

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

麦克勒格的 X、Y－理论

1. 麦克勒格的 X－理论：人性本恶，独裁式的管理风格
   1. 不喜欢他们的工作并努力逃避工作
   2. 缺乏进取心，没有解决问题与创造的能力
   3. 更喜欢经常的指导，避免承担责任，缺乏主动性
   4. 自我中心，对组织需求反应淡漠，反对变革
   5. 用马斯洛的底层需求（生理和安全）进行激励
2. 麦克勒格的 Y-理论：人性本善，民主式的管理风格
   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. 数据

自主团队

定义

一个团队必须包括至少两个成员，他们为了共同的目标和愿景而努力工作，他们每个人都有明确的角色和相应的职责定义，任务的完成需要团队成员互相依赖和支持。

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

特点

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

自主团队的必要性

1. 自主团队可以形成“胶冻态团队”。在这样的团队中存在一种神奇的力量，这种神奇力量弥漫于该团队做的所有工作
2. 团队成员互相支持，更为重要的是，团队成员在任何时刻都知道应该以怎样的方式帮助别人;团队成员相互信任，有强烈的归属感
3. 团队在适当的知道会聚集在一起，研究现状，讨论策略。

自主团队的形成

1. 自主团队不是偶然形成的。
2. 大部分情况下，在团队建立之初，团队成员往往有着不同的目标;缺乏清晰的角色定义和职责安排。对于待开发的产品只有模糊的概念;团队成员也有着不同的工作习惯和工作方法。
3. 经过一段时间的协同工作，团队成员可以慢慢培养团队协作方式，从而逐渐演化成自主团队。

自主团队的外部环境

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

TSP对自主团队的支持

TSP Launch

制定开发策略是第三次会议。

TSP 的典型角色

领导者与经理的区别

项目组长TL

项目组长的目标和衡量指标

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

典型TL技能

1. 你是天生的领导者
2. 你有能力识别问题的关键并且做出客观的决策
3. 你不介意偶尔充当“恶人”
4. 你尊敬你的团队成员

TL工作内容

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

计划经理

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

典型技能

1. 最为重要的一点是，你做事有条理和逻辑
2. 你对于过程数据非常感兴趣，期待通过每周输入的数据来了解项目当前状况
3. 你认为计划非常重要，也愿意要求团队成员跟踪和度量他们的工作

工作内容

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

开发经理

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

典型技能

1. 你喜欢创造事物
2. 你愿意成为软件工程师，并且喜欢带领团队开展设计和开发工作
3. 你具备足够的背景可以胜任设计师的工作，并且可以领导设计团队开展工作
4. 你熟悉主流的设计工具
5. 你愿意倾听和接受其他人的设计思想

工作内容

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

质量经理

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

典型技能

1. 你关注软件产品的质量
2. 你有评审方面的经验，熟悉各种评审方法
3. 你有协调组织有效评审的能力

工作内容

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

过程经理

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

典型技能

1. 你对过程定义、过程度量非常感兴趣
2. 你对过程改进非常感兴趣

工作内容

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

支持经理

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

典型技能

1. 你对于各种开发工具很感兴趣，熟悉各类工具的适用场合。
2. 你对版本控制工具很熟悉，也熟悉配置管理流程。
3. 对于本项目所有工具而言，你都是专家。

工作内容

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

典型Scrum 小组角色

• 典型SCRUM团队由一名产品负责人、开发团队和一名SCRUM Master组成

• SCRUM团队是跨职能的自组织团队

1. 产品负责人，代表利益所有者
   1. 产品负责人的职责是将开发团队开发的产品价值最大化。
   2. 产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：
      1. 清晰地表述产品待办列表项；
      2. 对产品待办列表项进行排序，使其最好地实现目标和使命；
      3. 优化开发团队所执行工作的价值；
      4. 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及
      5. 确保开发团队对产品待办列表项有足够深的了解。
2. 开发团队
   1. 负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。
   2. 开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。开发团队具有下列特点：
      1. 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
      2. 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
      3. Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。
      4. Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，
      5. 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
3. Scrum Master，类似于项目经理，负责维护过程和任务
   1. 促进和支持 SCRUM
   2. 帮助每个人理解 SCRUM 理论、实践、规则和价值
   3. SCRUM Master 是一位服务型领导。
      1. 帮助 SCRUM 团队之外的人了解如何与 SCRUM 团队交互是有益的
      2. 改变 SCRUM 团队之外的人与 SCRUM 团队的互动方式来最大化 SCRUM 团队所创造的价值。
   4. Scrum Master 服务于产品负责人，包括：
      1. 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
      2. 找到有效管理产品待办列表的技巧；
      3. 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
      4. 理解在经验主义的环境中的产品规划；
      5. 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
      6. 理解并实践敏捷性；以及，
      7. 当被请求或需要时，引导 Scrum 事件。
   5. Scrum Master 以各种方式服务于开发团队，包括
      1. 作为教练在自组织和跨职能方面给予开发团队以指导；
      2. 帮助开发团队创造高价值的产品；
      3. 移除开发团队工作进展中的障碍；
      4. 按被请求或需要时，引导 Scrum 事件；以及，
      5. 在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
   6. Scrum Master 以各种方式服务于组织，包括：
      1. 带领并作为教练指导组织采纳 Scrum；
      2. 在组织范围内规划 Scrum 的实施；
      3. 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
      4. 引发能够提升 Scrum 团队生产率的改变；以及，
      5. 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。

思考和讨论

典型SCRUM团队由一名产品负责人、开发团队和一名SCRUM Master(项目经理)组成

TSP由项目组长、开发经理、质量经理、支持经理、计划经理、过程经理组成

共性：

1. 跨职能团队： TSP和Scrum都主张跨职能的团队。在这两种方法中，团队成员通常具备不同的技能，可以在需要时协同工作，以实现更好的灵活性和应变能力。
2. 自组织性： TSP和Scrum都强调团队的自组织性。团队有权自主决策如何实现项目目标，并对团队的运作负责。这有助于激发团队成员的积极性和创造性。
3. 定期评审和反馈： 两者都支持定期的评审和反馈机制。这些机制有助于团队及时发现问题、调整方向，并不断提高工作效率。
4. 迭代和增量开发： TSP和Scrum都采用迭代和增量的开发方式。项目工作分成多个迭代，每个迭代都有一个可交付的产品增量。这有助于降低项目风险，提高可交付价值。

对高效团队的帮助：

1. 团队协作： 共同强调团队协作，通过跨职能团队的形式，使得团队成员更好地协同工作，促进信息共享和沟通。
2. 自组织性： 两者都通过强调自组织性来激发团队成员的积极性，提高团队的执行效率。自组织的团队更能应对变化和快速适应。
3. 迭代开发： 通过迭代开发，团队能够更快地响应变化、及时发现和解决问题，有助于提高团队的灵活性和适应性。
4. 透明度和反馈： 定期的评审和反馈机制提供了透明度，使团队了解项目的状态和进度。透明度有助于团队做出及时的调整。
5. 持续改进： 两者都鼓励团队进行持续改进，通过不断地反思和调整过程，提高工作效能，减少浪费，专注于价值交付。

团队中有3种激励方式 1.威逼 2.利诱 3.鼓励承诺 ，这三种方式下的团队有什么特点，哪种最好？

1. 威逼：这样的团队，团队成员会比较有压力，在一定程度上提高团队效率。但Leader和团队成员是一种对立的关系，团队结构不稳定，如果逼得太紧，可能就会产生反抗情绪。动力是为了保住自己的工作岗位。马斯洛第二级。

2. 利诱：团队成员的工作动力是为了奖励，可能变成为了完成任务而完成任务，团队成员的工作态度可能变成了做完任务而不是做好任务。或者为了利益，大家争着干一些活儿，为了卷而卷。马斯洛第一级。

3. 鼓励承诺：肯定了团队成员的主观能动性。团队成员的工作动力不仅来自于团队的鼓励，也有自我价值的肯定与实现，加强了团队成员在团队中的归属感和认同感，朝着一个良性的方向发展。马斯洛四级以上。

前两种，大家倾向于以最低标准完成工作，第三种，大家完成工作还为了赢得尊重。第三种看起来最好。

第一次开会的时候，为什么“要构建高质量软件”不是一个恰当的计划？/为什么把目标定义成高质量开发不合适？

• 可以用期望理论来解释。期望理论 Motivation = Valence x Expectancy(Instrumentality)，即 激发力量 = 价值（效价）x 期望难度。
• 在第一次开会的时候，如果提出一个过于雄心勃勃和庞大的计划，可能确实会提高软件目标的价值，也就是提高了完成目标的吸引力。但是显然在期望理论上，这在提高了valence的同时，却也提高了完成的难度，降低了公式里的期望值Expectancy。如果开发团队认为完成项目的难度过高，反而会降低整个团队的凝聚力、信心和工作效率。（Expectancy有点像工作量、开发难度）
• 一个应用案例：顶会审稿人不够，稿子太多看不过来
  • 措施：取消ddl，你任何时候都能写，任何时候都能提交
  • 然后发现：提交的数量急剧下降。因为大家都觉得时间都还够。

B.只要是商业环境的所有项目，所有方法都是计划驱动方法（都要做计划、估算、跟踪）所以SCRUM也是计划驱动的

C.迭代式和瀑布都是迭代式场景

答案：BC

答案：D。Y理论用马斯洛的高层需求（自尊和自我实现）进行激励

答案：AD。A自我实现是五层的，寻求自尊是四层的，D高层次更多

答案：A。维持激励水平依靠绩效反馈，而马斯洛指导怎么做激励

4. 估算、计划和跟踪

PROBE 方法

1. 估算的目的是给各类计划提供决策依据

PROBE：精确度量和早期规划需要的度量之间的桥梁：相对大小矩阵

PROBE 方法例子

1. 估算房子面积大小
   1. 使用房间相对大小矩阵
   2. 使用房间作为代理
2. 估算程序规模和工作量
   1. 使用代码相对大小矩阵
      1. 每个组件都有设定的类型（计算、逻辑或数据）
      2. 规模（非常小、小、中、大、非常大）
   2. 假设
      1. 如果新建立的组件与以前建立的组件类似，那么新组建所需的工作量与旧组件一样。
      2. 当开始一个新项目时，我们可以将任务划分为与代码库中组件相似的类型和规模，然后利用线性回归方法来估算项目的工作量。

方法思想

1. 在 PROBE 估算中，需要建立自己的代码库，以跟踪所有程序的规模和工作量，而代码库中的每个组件都有设定的类型（计算、逻辑或数据等）和规模（非常小、小、中、大、非常大）。
   1. 如果新建立的组件与以前建立的组件类似，那么新组件所需的工作量与旧组件一样。
   2. 当开始一个新项目时，我们可以将任务划分成与代码库中组件相似的类型和规模，然后利用线性回归方法来估算项目的工作量。
2. 估算本质上是一种猜测，追求的目标是一致性以及估算结果的使用者对估算结果的信心。
   1. PROBE 方法通过定义估算过程和数据收集以及使用的框架，使得估算结果可以尽可能一致，从而使得一些统计方法可以用来调整估算结果，增强用户对估算结果的信心。
   2. PROBE 方法非常依赖高质量的历史数据，一旦数据不完整或缺失，会导致估算结果有明显偏差。

1. 上述框架中，那些步骤必须人为的干预
   1. 定义需求
   2. 概要设计：划分由人为开始，规模划分好之后估算是自动产生的
   3. 日程计划
2. 这会带来什么的好处？比较容易扛住别人的质疑。
   1. 攻击点：资源和时间是否被高估了
   2. 解决：估算没有代码行 PROBE 只有功能点是大中小。

PROBE 估算过程

1. 概要设计
   1. 确定产品功能，以及产生这些功能所需的程序组件/模块
   2. 将程序组件/模板与你之前写的程序相比较，估算它们的规模
   3. 最后将程序组件/模块估算综合给出总规模
2. 估算要点：
   1. 尽可能划分详细一些：估算多个部件的时候，总的误差会比各个部件的误差的总和小
   2. 建立对结果的信心
   3. 依赖数据
   4. 估算要的是过程，而非结果，估算的过程是相关干系人达成一致共识的过程。

计划

工作分解结构WBS

1. 工作分解结构是以可交付成果为导向对满足项目目标和开发交付产物的项目相关工作进行的分解。
   1. 它归纳和定义了项目的整个工作范围。
   2. 每下降一层代表对项目工作的更详细定义。
2. 作用/特点
   1. 提供了项目范围基线，是范围变更的重要输入。
   2. 可以展现项目整体观，使得项目团队成员可以集中注意力实现项目的目标上。
   3. 为开发项目提供了一个整体框架，防止遗漏项目的可交付成果。
   4. 使得项目中各个角色的责任更明确，帮助项目团队的建立和获得项目成员的承诺。
   5. 为评估和分配任务提供具体的工作包的定义，工作包可以分配给项目某个成员或者另一个团队。
   6. 是进行估算和编制项目日程计划的基础。
   7. 可以帮助项目团队理解工作内容，分析项目的风险。
3. 表示方式
   1. 树型层次结构
   2. 清单型层次结构

创建 WBS

1. 将复杂的项目逐步分解为一系列明确定义的工作任务并作为随后计划活动的指导文档。
2. 要将整个项目分解成工作包：
   1. 识别和分析可交付成果以及相关工作。
   2. 确定工作分解结构的结构与编排方法。
   3. 自上而下逐层细化分解。
   4. 为工作分解结构组成部分制定和分配标志编码。
   5. 核实工作分解的程度是必要且充分的。

好的 WBS 的检查标准

1. 最底层要素不能重复，即任何一个工作应该在 WBS 中的一个地方且只应该在 WBS 中的一个地方出现。
2. 所有要素必须清晰完整定义，即相应的数据词典必须完整定义。
3. 最底层要素必须有定义清晰的责任人，可以支持成本估算和进度安排。
4. 最底层要素是实现目标的成分必要条件，即项目的工作范围得到完整体现。

范围管理

1. 包括确保项目做且只做成功完成项目所需的全部工作的各过程。
2. WBS 为范围管理提供了基础
   1. 收集需求
   2. 定义范围
   3. 创建 WBS
   4. 核实范围
   5. 控制范围变更

开发策略与计划

1. 定义：是在产品组件需求基础之上，明确每个产品组件的获得方式与顺序，从而在项目团队内部建立起大家都理解的产品开发策略
2. 注意事项：
   1. WBS 的使用
   2. 产品组件开发顺序的考虑
   3. 产品组件获得方式的考虑

过程框架：生命周期模型

1. 生命周期模型的各个阶段
   1. 项目启动阶段
   2. 项目策划阶段
   3. 需求开发阶段
   4. 技术实现阶段
   5. 集成与测试阶段
   6. 交付与维护阶段
   7. 项目总结

日程计划原理和方法

1. 任务计划描述了项目所有的任务清单，任务之间的先后顺序以及每个任务所需时间资源。
2. 资源清单
3. 日程计划描述了每个任务在日志上的安排，即每个任务计划哪天开始和计划哪天结束。
4. 制定资源计划，结合任务计划就可以定义日程计划
5. 团队形式的日程计划考虑
   1. 资源平衡：要求项目团队结合每个团队成员的工作效率、工作内容以及资源水平，找到一个时间点，让所有团队成员几乎同时完成任务
   2. 资源同步：安排日程时必须兼顾某些项目人物之间的依赖关系。

典型计划流程回顾

1. 估算规模
2. 估算资源
3. 规划日程

质量计划原理和方法

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

风险计划

1. 风险管理的目标是：在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目产生的负面影响。
2. 风险管理是一个持续的、前瞻的过程，此过程是项目管理的重要部分。有效的风险管理是通过相关干系人的合作与参与，尽快且积极地识别风险，指定项目风险管理计划。
   1. 风险管理需要同时考虑有关成本、进度、绩效以及其他风险的内部及外部来源。
   2. 在项目初期进行变更或修正的工作负荷，通常比在项目后期来得容易、花费较低且较不具破坏性。
   3. 早期且积极的风险侦测是重要的。
3. 风险管理大致分为两部分，即风险识别和风险应对。
4. 早期风险侦测的重要性：在项目初期进行变更或修正的工作负荷，通常比在项目后期来得容易、花费较低及较不具破坏性。

风险识别

1. 风险：没有发生，有一定概率会发生，发生后有一定影响
2. 问题：已经发生的，比如人员调动等。
3. 典型的识别方法
   1. 检查 WBS 的每个组件以找出相应的风险
   2. 使用定义好的风险分类表上来评估风险
   3. 访谈相关的领域专家
   4. 与类似项目进行比较来审查风险管理
   5. 检查以往项目的总结报告或组织级数据库
   6. 检查设计规格和协议书需求。
4. 典型的风险识别活动包括
   1. 识别与成本、进度及绩效相关的风险
   2. 审查可能影响项目的环境因素
   3. 审查工作分解结构的所有组件，作为风险识别的一部分，以协助确保所有的工作投入均已考虑
   4. 审查项目计划的所有组件，作为风险识别的一部分，以确保项目在各方面均已考虑
   5. 记录风险的内容、条件及可能的结果
   6. 识别每一风险相关的干系人
   7. 利用已定义的风险参数，评估已识别的风险
   8. 依照定义的风险类别，将风险分类并分组
   9. 排列降低风险的优先级
      1. 可能性很低，但是发生影响程度很大：政策变化、领导层大规模变动、公司倒闭
      2. [P（可能性）, I（影响程度）, T（阈值）]

风险应对

1. 识别风险之后，就应当制定相应的风险管理策略，以应对各类风险
2. 典型的策略包括
   1. 风险转嫁
      1. 指通过某种安排，在放弃部分利益的同时，将部分的项目风险转嫁到其他的团队或者组织。
      2. 比如有的公司采取外包的方式，把一部分有技术风险的产品组建交由其他公司开发，在放弃部分收益的同时，也规避了技术风险。
   2. 风险解决
      1. 指采用一些有效措施，使得风险的来源不再存在。
      2. 这往往是一种预防性的手段，比如针对项目面临的技术风险，采取技术调研或者引进技术专家的手段，使得原有的风险来源不再存在或者存在可能性极低，从而测试解决该风险。
   3. 风险缓解
      1. 指容忍风险的存在，采取一些措施监控风险，不让风险对项目最终目标的实现造成负面影响。
         1. 一般情况下，都需要指定相应的风险缓解计划：理性对待每个关键性的风险，研究可选择的应对方案，并对每个风险皆制定相应的行动过程，是风险缓解计划的关键内容。
         2. 特定风险的风险缓解计划包括规避、降低及控制风险发生可能性的技术和方法，或降低风险法身时遭受的损失程度的方法，或上述两者。
      2. 监控风险：
         1. 当风险超过设定的阈值时，实施风险缓解计划，以使受冲击的部分回归到可接受的风险等级。
         2. 只有当风险结果评定为高或者无法接受时，才相应指定风险缓解计划和紧急应对计划，其他情况只需要适当监控即可。

计划评审与各方承诺

1. 项目各项计划完成之后，需要与各类计划的相关干系人开展评审工作，解决工作中相互矛盾与不一致的地方，并获得参与项目的各方对项目计划的承诺。
   1. 识别每一项计划所需支持，并与相关干系人协商承诺。
   2. 记录所有的承诺，包括完整的承诺和临时的承诺，并确保由适当层次的人员签署。
   3. 适当与资深管理人员一起审查承诺。

团队项目规划：TSP 项目启动

TSP 的九次会议

• 几个认识
  • 错误的认识：软件开发阶段理解为注入缺陷的阶段，软件测试阶段理解为消除缺陷的阶段。
  • 正确的认识：开发和测试都是既有可能引入缺陷，也有可能消除缺陷的阶段
• 项目完成的实际时间由什么决定？最晚完成的工作的人决定的
• 经过平衡的计划和没有平衡的计划有什么不一样？更有把握去成功。

跟踪与分析

项目跟踪意义

1. 在项目进展过程中开展跟踪活动的目的在于了解项目进度，以便在项目实际进展和计划产生严重偏差时，可采取适当的纠正措施。
   1. 项目进度滞后与是否需要参照物，即项目计划。
   2. 项目跟踪需要管理偏差而采取的纠偏措施。
2. 团队项目的跟踪与管理主要包括进度的跟踪（利用不同跟踪方法，例如挣值管理、里程碑评审）、纠偏活动管理

项目的挣值管理方法EVM

什么是 EVM？

1. 项目的挣值管理方法是用来客观度量项目进度的一种项目管理方法。
   1. 每项任务实现附以一定价值（credit）
   2. 100%完成该项任务，就获得相应的价值。
2. EVM 采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量。

挣值管理实现

1. 简单实现：这种方式仅仅关注进度信息。

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

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

   1. 日程偏差SV = EV – PV;
   2. 日程偏差指数SPI = EV/PV；

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

挣值管理图解

PV：Planned Value,截止某时间点计划要完成工作量的价值（理想情况） 4000元

EV：Earned Value,截止到某时间点实际已经完成工作量的价值 3000元

AC：Actual Cost,截止到某时间点实际已经发生的成本 5000元

BAC：对完成该项目的计划预算 10000元花钱快做事慢

绩效指标：

成本偏差CV=EV-AC ** 成本绩效指数CPI=EV/AC** 每花一元钱，完成做了多少钱的事

进度偏差SV=EV-PV 进度绩效指数SPI=EV/PV 实际完成的工作量与计划完成工作量之比

EAC= AC+(BAC-EV)/CPI 按照目前的进展已经成本消耗情况+整个项目完成时所需消耗的成本

挣值管理会带来什么好处？可以很好的适应项目的动态变化。

挣值管理的度量

1. BAC 表示按照 PV 值的曲线，当项目完成的时候所需预算或者时间
2. 成本差异 CV = EV-AC，表示的是已经完成的工作与所消耗的成本的差异。可以表示为消耗的时间，也可以表示为消耗的资金。
3. 成本差异指数 CPI = EV/AC，表示单位成本创造的价值
   1. CPI<1 说明成本超支
   2. CPI=1 说明成本与预期一致
   3. CPI>1 说明成本低于预期。
4. 日程偏差 SV = EV – PV，表示进度偏差。
   1. SV<0 表示进度落后；SV=0 表示进度正常
   2. SV>0 表示进度超前。
5. 日程偏差指数 SPI = EV/PV
6. 预计完成成本 EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是按照目前的进展已经成本消耗情况，整个项目完成的时候所需消耗的成本。

挣值管理的应用

1. 发现项目已经滞后
   1. 削减功能，使得已经完成的任务的 EV 值增加
   2. 通过加班或加人等手段，有效提升获取 EV 值的速度
   3. 加强成本监控
2. 见课本 126 页相关例子
   1. EV 值显示的项目落后可能是假象
   2. 分析例子

挣值管理的局限性

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

另一种挣值管理变形：燃尽图

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

里程碑评审

1. 软件项目的里程碑往往是指某个时间点，用以标记某些工作的完成或者阶段的结束。
   1. 典型的里程碑事件：
      1. 完成某项工作
      2. 获得干系人签字认可
      3. 完成某产物的评审
      4. 修改或交付某产物
2. 里程碑评审的审查内容包括：
   1. 项目相关的承诺，如日期、规格、质量等等；
   2. 项目各项计划的执行状况；
   3. 项目当前的状态讨论；
   4. 项目面临的风险讨论等
3. 里程碑评审也可用于质量管理

其他类型跟踪方法

1. 日程计划跟踪
2. 承诺计划跟踪
3. 风险计划跟踪
4. 数据收集计划跟踪
5. 沟通计划跟踪

纠偏活动的管理

典型的纠偏活动包括：偏差原因分析、纠偏措施定义、纠偏措施管理

1. 偏差原因分析：收集偏差相关的各种信息，基于收集到的信息，开展充分的分析工作，找出偏差的根本原因。
2. 纠偏措施定义：确认偏差的根本原因，就可以有针对性地定义纠偏的措施。
3. 纠偏措施管理：管理纠偏措施直到结项。

项目审查

审查的内容包括

1. 项目相关的承诺，如日期、规格、质量等等。
2. 项目各项计划的执行状况。
3. 项目当前的状态讨论
4. 项目面临的风险讨论
5. 其他计划跟踪
6. 日程计划跟踪
7. 承诺计划跟踪
8. 风险计划跟踪
9. 数据收集计划跟踪
10. 沟通计划跟踪

项目总结

项目总结的定义

1. 项目总结需要系统化有条理的进行，才能不遗漏重要的内容。
2. 因此往往需要事先定义总结过程，然后就按部就班地开展总结工作。

一般项目总结流程

基于 PMBOK 的总结方式，包含范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整合管理 9 大知识领域（每个领域具体内容见 Lec-4)

1. 项目范围包括产品范围和项目范围。对项目范围管理的总结应当主要关注项目的需求开发过程与变更管理中的得失，对需求管理实际执行情况的差距进行原因分析，找到改进的机会。
2. 时间管理所关注的就是项目的日程计划以及对日程计划的跟踪和管理状况。因此主要考察计划的准确程度以及各个里程碑的偏差情况。
3. 成本管理包括对成本进行估算、预算和控制的各个过程，从而确保项目在批准的预算内完工
4. 质量管理包括执行组织确定质量政策、目标与职责的各过程和活动，从而使项目满足其预定的需求。
5. 人力资源管理包括组织、管理与领导项目团队的各个过程。
6. 沟通管理包括为确保项目信息及时且恰当地生成、收集、发布、存储、调用最终处置所需的各个过程
7. 风险管理包括风险管理规划、风险识别、风险分析、风险应对规划和风险监控等各个过程。
8. 采购管理包括从项目组织外部采购或获得所需产品、服务或成果的各个过程。
9. 整合管理包括为识别、定义、组合、统一与协调项目管理过程组的各过程及项目管理活动而进行的各种过程和活动

TSP 项目总结方式

1. 准备阶段
2. 过程数据评审阶段：该阶段往往由过程经理或者质量经理带领整个团队分析过程数据，识别过程改进机会。
   1. 可以结合典型 TSP 团队角色，逐个讨论改进领域。如团队领导力、计划准确性、过程优劣、质量管理能力、开发环境以及配置管理等。
   2. 此外，也可以就 TSP 教练的作用进行评价。
   3. 过程数据评审阶段还要求开发团队的所有成员都整理过程改进提案（PIP）：PIP 是 TSP 过程中供开发人员在日程工作中记录改进想法的工具。其基本思想是积累小的改进，慢慢形成大的改进。在软件开发过程中，重大的改进机会不多，因此，往往需要从小做起，慢慢积累之后，就会形成对原有过程的显著改进。小的改进机会虽然多，但是容易被遗忘，PIP 的作用就在于提供了一个标准表格工具，允许软件工程师时时记录改进方案。在项目总结阶段，将开发过程中记录的所有 PIP 整理出来，形成整个开发周期的过程改进提案，供讨论，以确定下个开发周期要实施的过程改进。
3. 人员角色评价阶段（角色包括项目组长、计划经理、开发经理、质量经理、过程经理和支持经理）：详见 Lec-4
4. 总结报告撰写阶段

通用项目总结流程

1. 准备阶段
2. 总结阶段
3. 报告阶段

项目总结的意义

提供一个系统化的方式来总结经验教训、防止犯同样的错误、评估项目团队绩效、积累过程数据等，给项目团队成员持续学习和改进的机会。

思考与讨论

A：WBS是将项目分解为细粒度的功能元素，用来指导项目开发的规划和设计。
OBS是关于项目内部组织的，是将项目团队一些特点进行分工、职责分配。
他们的分析方法类似，但不需要彼此对应。错。

B:WBS可以对项目功能或者项目的开发过程做分解，可以方便范围管理的分阶段
进行。正确。

C：正确。

D：每一层确实必须用同样的标准分解。

答案：A。

A.EVM是度量项目开发进度、成本的，不适用于质量管理，正确。

B.低级实现引入EV(挣值) ，中级引入BAC（项目总预算），高级引入成本（AC）错误

C.估算越准确当然越好，正确

D.挣值管理可以实时计算项目实际进度和预期进度的区别，正确

答案：B。

答案：ABC。

D：挣值管理很好的适应于需求变更

5. 质量管理

PSP 质量观与质量策略

1. 软件项目的日程、成本以及质量三大目标统一于质量目标
2. 什么是软件质量？
   1. 与软件产品满足规定的和隐含的需求能力有关的特征或者特征的全体
   2. PSP 中定义质量为满足用户需求的程度，需要明确用户需求的范围、优先级、度量方式
3. 软件质量分为内外两部分的特性
   1. 其外部质量特性面向软件产品的最终用户。
   2. 其内部质量特性不直接面向最终用户。
4. 软件质量的不同视角
   1. 软件质量为软件产品可以改变世界，使世界更加美好的程度。从用户的角度考察软件质量，用户满意度是最为重要的判断标准。
   2. 软件质量是对人（用户）的价值，这一定义强调了质量的主观性，即对于同一款软件而言，不同的用户对其质量有不同的体验。

面向用户的质量观

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

质量策略

1. 使用缺陷管理来代替质量管理
2. 高质量的产品也就意味着组成软件产品的各个组件基本无缺陷
3. 各个组件的高质量是通过高质量评审来实现的；

质量路径 Quality Journey

为了追求极高的质量，你有哪些手段？

顺序不能更换。

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

发现缺陷的几个示例流程

测试消除缺陷的典型流程

1. 发现待测程序的一个异常行为
2. 理解程序的工作方式
3. 调试程序，找到出错的位置，确定出错的原因：非常耗时，在项目后期可能会消耗数天甚至数周的时间
4. 确定修改方案，修改缺陷
5. 回归测试，以确认修改有效

评审发现缺陷的典型流程

在如下的步骤中，每一步消耗的时间都不会太多。尽管评审的技能因人而异，但是，通过适当培训和积累，有经验的评审者可以发现 80%左右的缺陷。

1. 遵循评审者的逻辑来理解程序流程
2. 发现缺陷的同时，也知道了缺陷的位置和原因
3. 修正缺陷

评审与测试

评审检查表

1. 评审检查表的建立和维护：示例见课本
2. 评审检查表的使用

评审形式

打印后评审效果更好

1. 单个屏幕可以展现的内容比较有限（评审对象比较复杂的时候，单个屏幕往往不能体现评审对象的整体结构、整体安全、整体性能以及其他整体属性）
2. 评审人员的注意力：基于屏幕的评审往往容易受到干扰，从而影响评审人员的注意力

评审时机

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

评审的具体形式

个人评审、小组评审

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

评审中缺陷预防过程中的缺陷数据选择

1. 选择那些在系统测试、验收测试以及应用环节出现的缺陷，特别是验收测试和应用环节中的缺陷，这些缺陷往往意味着软件开发过程本身有不足之处。
2. 选择那些在出现频率较高或者消除代价较高的缺陷，这些缺陷如果可以预防，往往可以节省较多开发的代价，从而体现缺陷预防的优势。
3. 选择那些预防方法容易识别和实现的缺陷，这样的策略容易让软件工程师迅速看到缺陷预防的好处，鉴定使用缺陷预防策略的信心。

PSP 质量控制的衍生指标

Yield 指标

基本定义

1. 定义了各个阶段在消除缺陷方面的效率
   1. Yield 指标越高越好
   2. Process Yield 我们期望在 80 以上

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

Yield 的计算是一种事后的质量控制手段，而且除非发现了所有的缺陷，否则很难非常精确地进行计算。

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

改进方案

1. 结果受限于历史数据在简单性、可理解性、稳定性、可度量性、相关性等方法的质量。因此，维护历史数据。
2. 影响因子的选择上面不仅仅需要有关软件规模的数据，还需要有关开发过程、开发文档、开发人员等方面的数据，并且需要将数据可度量化。
3. 反馈模型。即在开发过程中随着实际数据的产生，将这些数据作为输入变量放入模型中以调整回归参数。
4. （重要）可能的改进是假设注入水平和消除水平都符合正态分布，计算均值和标准差，因此，可以用蒙特卡罗方法模拟结果。

A/FR

1. COQ(Cost of Quality)
   1. 失效成本：分析失效现象、查找原因，做必要的修改所消耗的成本
   2. 质检成本：评价软件产品，确定其质量状况所消耗的成本
   3. 预防成本：识别缺陷根本原因、采取措施预防其再次发生所消耗的成本
2. 质检失效比
   1. A/FR = PSP 质检成本 / PSP 失效成本
   2. 质检成本 = 设计评审时间 + 代码评审时间
   3. 失效成本 = 编译时间 + 单元测试时间
3. 理论上，A/FR 值越大，意味着质量越高，但 A/FR 值过大说明评审过多，则开发效率低下，因此 PSP 中 A/FR 期望值为 2.0

PQI 过程质量指标

1. 为 5 个数据的乘积（以基准值作为 1，最后结果越接近 1，质量越高）
   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. 用途
   1. 判断模块开发质量
   2. 规划质量活动计划
   3. 过程改进

Review Rate

1. 评审的速度是一个用以指导软件工程师开展有效评审的指标
2. 代码评审速度小于 200 LOC（代码行）/h
3. 文档评审速度小于 4 page（文档采用页）/h

DRL 缺陷消除效率比

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

发现的效率：代码评审 > 设计评审 > 设计检查 > 代码检查 > 单元测试 > 系统测试

PSP 的设计

1. PSP 设计过程的关注点并不是具体的设计方法，而是设计的步骤定义以及设计的表现形式

设计与质量的关系

1. 低劣的设计是导致在软件开发中返工、不易维护以及用户不满的主要原因。
2. 充分设计可以显著减少最终程序的规模，提升质量
3. 设计本身也是一种排除错误的过程。

设计什么

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

设计的过程

设计内容

	动态信息	静态信息
外部信息	交互信息（服务、消息等）	功能（继承、类结构等）
内部信息	行为信息（状态机）	结构信息（属性、业务逻辑等）

设计模板

	动态信息	静态信息
外部信息	OST/FST	FST
内部信息	SST	LST

操作规格模板 Operational Specification Template

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

功能规格模板（Functional Specification Template， 简称 FST）

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

状态规格模板（State Specification Template，简称 SST）

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

逻辑规格模板（Logical Specification Template，简称 LST）

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

UML

1. UML 图有用例图、时序图、类图、状态机图
2. UML 的用例图和时序图提供了与 PSP 中 OST 同样的信息；
3. UML 中的时序图和类图所描述的类之间的关系以及对象之间的交互信息在 PSP4 个设计模板中没有对应的内容；
4. UML 类图中记录了方法的型构，然而方法的行为没有描述，这一点在 PSP 的 FST 中有相应的内容；
5. PSP 中的 LST 用以描述程序的静态逻辑，这在 UML 没有对应的图示方法；
6. UML 中的状态图与 SST 描述的状态图类似，但是 SST 中描述的关于状态、状态转换条件以及状态转换中的动作没有对应的 UML 图示方法。

PSP 设计验证方法

状态机验证

1. 检查状态机的完整性和正交性

   1. 完整性：对于状态机中任何一个状态，对应的所有条件组合，下一个状态的转换都有定义。
   2. 正交性：对于状态机中任何一个状态，其所有下一个状态的转换条件都不能相同。

2. 验证步骤

   1. 检查状态机，消除死循环和陷阱状态
   2. 检查状态转换，验证完整性和正交性
   3. 评价状态机，检验是否体现设计意图

3. 具体验证方法

   • 检验状态机，消除死循环和陷阱状态。

     死循环是指在状态机中存在不能跳出的状态转换回路。在图 4‑11中，状态CheckID和CheckPW之间存在回路。仔细考察相应的转换条件和动作，CheckPW回到CheckID的时候，试验次数n必须小于最大容许出错的次数nMax，而本身n又会递增。因此，总有一次n将大于或者等于nMax，此时，CheckPW状态将转换到End状态，也就是跳出循环。通过上述分析，我们认为，在图 4‑11所示的状态机图中不存在死循环。

     状态机中的陷阱状态是指在状态机中存在某个状态A，不存在从A状态转换到结束状态的路径。同样的，经过仔细考察，在图 4‑11所示的状态机图中，所有状态都可以经由一定的状态转换到大End状态，因此，也不存在陷进状态。

     

   • 检查状态转换，验证完整性和正交性。

     • 检验从CheckPW状态出发的状态组合
     • 列真值表：检查完整性和正交性（感觉Timeout也应该作为一个变量？）

符号化验证

1. 将描述设计的逻辑规格（一般用伪代码程序表示）用代数符号来表示，然后系统地开展分析和验证
2. 验证步骤
   1. 识别伪码程序中的关键变量
   2. 将这些变量使用代数符号表示，重写伪码程序
   3. 分析伪码程序的行为。
3. 具体示例见 PPT：交换两个变量的值（赋初值，罗列每一步变量的变化。注意值没变时不用写！！）
4. 优点：这种方法通常用在验证一些复杂算法中，特别是对遗留系统的改造中，往往应用这种方法来识别和理解原有的设计。
5. 缺点：这种验证方法不适用于有复杂逻辑的场合，而且，纯手工的验证方法也容易引入一些人为的错误。

执行表验证

1. 执行表
2. 步骤
   1. 识别伪码程序的关键变量
   2. 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量
   3. 初始化被选定的变量（!Valid看成常量，就不是关键变量了）
   4. 跟踪被选择的关键变量的变化情况，从而判断程序行为这里Test表示该行有没有执行成功的赋值，有就是T；然后Check会跟踪一下，Get似乎没有（看ID那一列）
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 为”假”的时候，循环体内所有变量是否未被修改？

思考和讨论

A：PSP策略里有“拿缺陷管理替代质量管理”，因为质量管理无法管理（可靠稳定、快、质量稳定不行，因为定义、状态跟踪和纠偏很麻烦，这是管理的三要素很难定义），所以用缺陷管理替换（首要需求是不出错）正确。

B：评审是高质量的保障，测试是检测质量状态的，正确。

C：编译的速度是最快的，时间最短，错误。

D：PSP主要解决用户需求，处理缺陷。而外部质量直接面向最终用户，对应用户需求，正确。

答案：ABD

答案：CD

DRL(UT) DRL(X/UT) 期望永远大于1，可以度量

答案：BCD

A：PQI=0，没做设计/设计评审，指标低代表过程本身有问题（五个指标相乘）

B：不是越高越好，0.4

答案：AB

它可以判断和评估项目某个模块的质量，指出问题，做针对性的改进建议，为软件改进做依据，可以帮助制定质量计划。AB是对的，
C: 范围[0,1] 不可能大于1
D: 本身就是一个度量指标

答案：ABCD

D：分子是事实，分母只能猜测，可以用1:1的比例，或其他，分母永远是预测出来的

答案：C。

AD：小于200LOC

B：评审速度根据目标而定。

答案：CD

A：不能更换顺序

B：不涉及到需求，step1是测试

D：最后一条是用户质量观——其他质量属性，所以先考虑1-7中的缺陷，再考虑其他质量属性.

答案：B。

	动态信息	静态信息
外部信息	OST/FST	FST
内部信息	SST	LST

答案：B

A：时序图用例图都可以表示OST

C：LST可以通过伪代码方式表现

D：FST是系统对外的接口，没有类图能描述行为

AB：符号化执行、跟踪表、执行表等都是全面的

D：符号化表通常用在验证一些复杂算法中，但不适用于有复杂逻辑的场合

答案：C

加粗的地方是跟踪表唯一与执行表不同的，所以跟踪表比执行表适用面更好（因为可以用于伪代码）

答案：ABC

与D独立性无关，如果加的话看跟设计意图是否一致

答案：C。

C：安全和保密性也是质量要素

D:质量是与用户的主观感受有关的（如易用性），有多重属性

答案：C

A：A/FR不是越高越好，2.0左右就可以了

B：yield是估算指标，无法精确度量

C：评审应该放在编译之前，先评审再做编译、测试更省时间，否则评审完了后面还是要编译一次

D：PQI可以指导质量计划

答案：A

B：不是唯一一种，严格来说只有符号化执行，但用了符号化执行的跟踪表也行（因为用代数符号后方便当做数学定理，进行推理和验证？）

C：弱于（跟踪表=执行表+符号化）

D：不仅是正确性检验，其他的验证手段也都很可靠

答案：ABCD
A：要能跳出循环，不是死循环，A当然对
B：正确，反正跳出条件都一样，无非是一次循环都执行几次循环体。
C：是的
D：程序正确性证明手段不能一定实现算法意图。因为算法意图是否实现，要看你的循环体语句，你修改状态是不是改对了。

6.团队工程开发

TSP 提供了：

1. 一个已经定义的团队构建过程
2. 一个团队作业框架
3. 一个有效的管理环境

需求开发

需求开发包含需求获取、需求汇总、需求验证

需求分类

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

为什么说“需求是一切工程活动的基础”

1. 设计活动一定是依据需求而开展的
2. 产品集成活动中，各个组件之间的接口必须满足事先确定的接口需求，否则会造成接口不匹配。
   1. 验证（Verification）活动也是检验获得的产品和产品组件能不能满足各自事先定义好的需求规格。
   2. 确认（Validation）活动是为了确保产品可以满足客户的需求以及实际操作场景的要求。
3. 此外，需求也是项目计划活动的关键输入。比如，项目的规模估算、成本估算等必须参考需求来进行。

需求获取

1. 需求是采用”诱导“式方法获取客户的显式需求和隐式需求，尽可能的识别客户的期望与所受到的限制。
   1. “诱导”不仅仅是普通的需求采集，隐含了更加积极地、前瞻性地识别那些客户没有明确提供的额外需求。
   2. 客户所受到的限制也应当作为需求开发过后需要关注的内容。限制包括技术、成本、时间、风险、行业规则、法律等等。

需求汇总

1. 整理各种来源的信息，识别缺失的信息。
2. 解决冲突的需求
   1. 需求的整理和转化：我们需要将客户的需求转换为产品需求和产品组件的需求
   2. 推导未显式描述的需求内容，例如采用某项技术的附属需求

需求验证

1. 对需求进行分析和确认，以确保符合使用者预期
2. 典型活动包括
   1. 建立和维护操作概念和相关的场景；场景一般而言是指使用产品时可能发生的时间顺序。
   2. 分析需求，以确保其必要性、充分性和平衡性。
   3. 确认需求，以确保将要产生的产品能在预期的用户环境中运行并且工作正常。

需求文档制作

1. 需求开发工作完成的一个基本标志是形成了一份完整的、规范的、经过评审的需求规格说明书。
2. 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

团队设计

团队智慧

发挥团队智慧两大挑战

1. 确定整体架构之前很难进行分工
2. 鼓励团队成员在讨论和评审会议中的参与程度

设计标准

1. 命名规范：项目小组应当设计一个统一的命名规范来命名各个模块并建立系统词典
2. 接口标准：组件之间的接口标准和格式也需要作为设计标准的内容之一加以定义
3. 系统出错信息：系统异常信息和出错信息往往也需要通过一个规范加以标准化
4. 设计表示标准：设计表示标准定义了设计工作的产物应当满足的标准。

复用性支持

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

可测试性考虑

设计可测试性考虑主要体现在两方面

1. 要尽可能减少测试代码的数量
2. 要制作合理的测试计划。

可用性考虑

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

实现策略

评审的考虑

1. 设计的时候采用的策略是自顶向下、逐层精化，这有利于建立系统的整体观，
2. 实现的时候为了方便对实现结果评审，建议采用自底向上的方式进行，首先实现底层的内容，然后对这些底层的模块进行评审，有利于复用策略的应用。

复用策略

1. 采用自底向上的开发策略有利于进行复用。
2. 几个经典的复用策略
   1. 编码注释的应用：编码注释采用统一格式，标明功能，调用方式。异常信息等有利于复用的信息。
   2. 站立式会议：在会上，团队成员可以讨论实现计划，识别可复用组件，了解现有的复用组件库中的内容

可测试性考虑

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

集成策略选择

大爆炸集成策略

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

逐一添加集成策略

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

集簇集成策略

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

扁平化集成策略

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

验证与确认 V&V

什么是 V&V?

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

V&V 的区别与联系

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

V&V 的活动

1. 环境准备
   1. 对于验证工作，如果是评审，则需要准备文件材料、人员以及会议场所等；如果是测试，需要准备模拟器、场景生成程序、环境控制以及其他系统接口等
   2. 对于确认工作，则需要模拟真实环境和场景
2. 对象选择
   1. 对于验证工作，验证对象往往从工作产品中选择
   2. 对于确认工作，确认对象从产品中选择
3. 活动实施
   1. 确认工作活动包括早期对产品需求评审工作和最后的验收测试
   2. 验证工作：一般的评审和测试工作
4. 结果分析
   1. 对于评审结果，可以根据评审结果反思软件开发过程的合理性、以及是否还有隐藏的缺陷
   2. 对于验收测试的结果，则可以关注那些一直遗留到验收阶段才被发现的缺陷，看看这些缺陷在什么阶段被引入，为什么前面未能发现等

V&V 的例子

1. 单元测试：验证
2. 集成：验证
3. 需求评审：确认
4. 验收测试：确认

思考与讨论

答案：ABC。

客户需求描述的是客户的期望，是客户解决问题的愿望，典型的客户需求通常不包含功能，客户所受到的限制也应当作为需求开发过程中需要重点关注的内容。

系统功能描述包含在产品需求中。

答案：ABCD

答案：ABCD

答案：BCD

扁平化：先搭建系统（插桩），然后把组件替换成真实代码.A应该是不可以用大爆炸

答案：ABCD

D：如果有20、30个，不能大爆炸（多了）；如果只有2个，大爆炸和逐一添加是一回事

答案：BC

A：可以尽早，但不充分

B：因为打桩可能遗漏掉很多场景，往往不能覆盖整个系统应该处理的多种状态

C:集簇集成策略改进了逐一添加，将有相似功能或者有关联的模块优先进行集成，形成可以工作的组件。因为它是自底向上，同时按照相似功能分类，有助于复用策略。

D：大爆炸和逐一添加优缺点正好相反，没说逐一添加和扁平化

答案：BC

确认是一头一尾（用户需求），验证是当中的部分（产品需求）

• 事实上，确认和验证贯穿开发始终（但上面的更好理解）

看解决方案本身有没有正确实现（评审、测试）：验证

客户的问题有没有得到好的解决：确认

答案：A

软件开发典型流程：需求-设计-开发-代码评审-单元测试-集成测试（大部分是功能测试）-系统测试-试运行/验收

答案：BCD

确认解决用户的问题，对应用户需求

A：如果是中间件，不是完整系统，可能要（但是等同于用户手册）

答案：BC

A：客户需求是问题，产品需求是解决方案，软件功能性描述是解决方案，所以是产品需求

D：客户不能主导，否则得应付很多变化

7.项目支持活动

项目管理支持活动包含：配置管理、度量和分析、决策分析和根因分析。

配置管理

配置管理的目的

建立与维护工作产品的完整性

配置管理的概念

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

配置管理的流程

配置管理是用管理的手段监督和指导如下工作的流程[CMMI 2006]

1. 识别和记录配置项的物理特性和功能特性
2. 控制上述特性的变更；
3. 记录和报告变更过程和相应的配置项状态
4. 验证配置项是否与需求一致

配置管理活动

1. 识别配置项
2. 建立配置管理系统
3. 创建和发布基线
4. 跟踪变更请求
5. 控制配置项变更
6. 建立配置管理记录
7. 配置审计

配置管理各个活动之间的关系

度量和分析

度量和分析简介

1. 意义：在软件项目管理决策的过程中，基于客观的数据很重要，这种客观决策可以显著消除错误决策的风险。而这些客观数据的获得，必须依照一定的流程以正确的方式获得和使用。度量和分析活动就定义了上述客观数据的获取与使用方式。
2. 目的：建立与维持度量能力，以支持管理的信息需要。

度量和分析活动

1. 建立度量目标
2. 指定度量方式
3. 指定数据收集和保存的流程
4. 指定分析流程
5. 收集度量数据
6. 分析度量数据
7. 保存数据和结果
8. 交流度量结果

活动组成就是 8 个圆圈内的内容

GQM 方法的原理和应用

1. GQM(Goal Question Metric)是一种应用非常广泛的建立软件度量体系的方法，从管理的目标出发，将目标归纳、分解为度量的指标，并把这些指标提炼成可以测量的值，是一种科学的、系统的思考问题的方式。
   1. 概念层（目标）：目标是为某个特定的对象而定义的。这里的对象是指软件产品、软件过程以及相关的资源等。定义的目标基于不同原因和不同质量模型,也要参考不同的角色视图与特定的环境。
   2. 操作层（问题）：基于一定的刻画上述目标是否达成或者目标达成的进展情况的模型，使用一系列的问题来定义所研究的对象, 然后得出评价或评估特定目标达成进展情况。所选择的问题应当尽量体现质量相关的话题。
   3. 量化层（度量）：试图以量化的方式回答上述操作层识别出来的问题。
2. 示例：
   1. 例子一：PM
      1. G：确保稳定性、可预测性的开发过程来满足计划的里程碑
      2. Q：我的项目是否按照计划的轨迹前进，计划的里程碑都能实现嘛？
      3. M：软件项目开发工作的挥发性（分支、流、统计变更管理 UCM 活动）
   2. 例子二：QM
      1. G：最大化所有团队贡献者的生产力
      2. Q：开发人员能够完成分配给他们的任务吗，或者他们遇到障碍了吗？
      3. M：由个体或者工作组产生的项目工作的量级
   3. 详见课本 153-155 页

决策分析

根因分析

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

思考与讨论

答案：ABCD

配置审计要建立完整性

答案：ABCD

答案：BD

A对 B：评价标准最关键，而不是评价方法 C对 D：招标才是

答案：AD

A：不是所有时候都有丰富的数据，有时没有

D：有时候没有明确解决方案，也可以结束

8.定量管理与仿真建模

高成熟度项目管理

CMMI 模型

一般的项目管理

1. 主要关心
   1. 当前状况（注意：也可能使用数据）
   2. 是否需要调整干预
2. 但是，回答不了必须进行预测的问题，例如
   1. 维持现状，项目最后是否能成功？
   2. 如果某些方面进行调整，会有什么不同的结果？

定量的项目管理

1. 基于数据，主要关心
   1. 你对当前状态理解是否有足够信心？
   2. 对偏差的理解
2. 回答如下典型问题
   1. 项目最后是否能成功？多大把握？是否需要预防？
   2. 如果某些方面进行调整，会有什么不同的结果？

为什么需要理解偏差

1. 有的时候，我们会面临这样的问题
2. 客户希望 10 周以内交付，但是，历史数据表明，类似任务是 9~11 周完成，那这个任务该接受么？

定量管理

1. 构建定量模型
   1. 子过程能力基线
   2. 过程模型
2. 应用模型：监控影响子过程的关键因素

基本概念

1. （子）过程性能：遵循某个特定（子）过程的之后产生结果的量化描述，既包括（子）过程度量 Xi（例如，时间、缺陷消除效率、工时等），也包括产物度量 Yi（例如，缺陷密度，相应时间等）。
2. （子）过程性能基线：上述过程性能的一个定量化的刻画，一般包括均值和范围。通常用作过程性能的 benchmark。
3. 过程或子过程性能模型：依据子过程的逻辑关系构建相应的数学模型，描述子过程性能基线和整体过程有意义的性能输出（例如，质量、生产效率、成本等）之间关系。例如过程 Yield 和 Phase Yield。

定量模型构建的关键实践

1. 基于 Yield 来构建一个基本的缺陷预测模型，假设
   1. 上述阶段分别为需求开发、需求评审、设计、设计评审、编码、测试；
   2. 需要基于该模型也测最终产出物中有多少个缺陷？
2. 讨论
   1. 需要补充哪些数据？请设计一个可行的数据获取要求；
   2. 上述数据显然不可能是一个恒定不变的数据，该如何处理？

定量模型应用（定量管理）的关键实践

常用定量管理技术

1. 定量管理技术通常被分为非统计技术和统计技术，这些技术的使用能够帮助解决软件项目管理中多种问题。

常用非统计技术

1. 非统计技术一般是为了描述数据集整体特征或者关联关系，从而帮助选择适用的统计技术以应用于给定的数据集，以及调查通过数据分析检测到异常的原因。例如，检查表（或列联表），帕累托图，直方图，因果图，散点图等。

直方图

1. 直方图以频率统计的方式进行显示，可以描述过程属性的频率，例如缺陷修复的时间、每次测试发现的缺陷的个数、每天无故障工作的时间、计算产品的不合格率等。
2. 一般用于有助于判断过程是否正常，过程能力是否满足需要，不良产品是否发生，分析产品质量问题的原因等。

帕累托图

1. 一种特殊的直方图
2. 按照由高到低排列的直方图

因果图

1. 因果图是用来分析影响产品质量的各种原因的一种有效的定性的分析图，它将对特性或结果有影响的要素加以分类分析，是一种发现问题根本原因的方法，可以让项目组成员通过头脑风暴、集思广益的方法从各个方面各种不同的角度找出这些问题的所有原因。

散布（点）图

1. 整理和观察收集到的数据的常用图形工具
2. 散布图表示的是一个变量相对于另一个变量的表现情况，可以假定一个变量是因变量，另一个变量是自变量。散布图通常表现了 5 种相关关系。如图所示的散布图中分别表现了两个变量之间的弱正相关、弱负相关、不相关、强正相关、强负相关。

常用统计技术

1. 统计思维认识到许多决策是在不确定条件下做出的。统计方法有助于量化这种不确定性并指导采取行动以减少不确定性。
2. 统计分析支持许多类型的决策，在支持过程管理决策的统计分析中，有效的过程管理通常需要两级决策
   1. 实时控制单个活动或子流程
   2. 根据当前和已完成的活动对未来和最终过程的结果进行预测
3. 常用的统计技术包括：统计过程控制图，回归分析，方差分析，预测区间，假设检验，敏感性分析等

控制图

1. 控制图是根据概率统计原理构造的一种图，用来监测生产过程是否处于控制状态。
2. 控制图是对过程质量数据测定、记录从而进行质量管理的一种用科学方法设计的图。
3. 图上有中心线（CL)、上控制限（UCL)和下控制限（LCL)，并有按时间顺序抽取的样本统计量数值的描点序列。

1. 控制图可由正态分布演变而来
2. 正态分布可用两个参数即均值 μ 和标准差 σ 来决定。正态分布有一个结论对质量管理很有用，即无论均值 μ 和标准差 σ 取何值，产品质量特性值落在 μ±3σ 之间的概率为 99.73%，落在 μ±3σ 之外的概率为 100%-99.73%=0.27%，而超过一侧，即大于 μ+3σ 或小于 μ-3σ 的概率为 0.27%/2=0.135%≈1‰。

1. 两类错误（需要检验）：
   1. Ⅰ 类错误：虚发警报错误，在生产正常的情况下,纯粹出于偶然而点子出界的概率虽然很小,但不是绝对不可能发生。故当生产正常而根据点出界判断生产异常就犯了虚发警报错误,发生这种错误的概率通常记以 α
   2. Ⅱ 类错误：漏发警报错误,在生产异常的情况下,产品质量的分布偏离典型分布,但总有一部分产品的质量特性值在上下控制界之内。如果抽到这样的产品进行检测描点,根据点未出界判断生产正常就为漏发警报错误,此概率通常记以 β。

补充：软件开发实践

敏捷软件开发

1. 敏捷中也有计划驱动

敏捷目的

为了使软件开发团队具有高效工作和快速响应变化的能力

敏捷原则

1. 最重要的是通过尽早和不断交付有价值的软件满足客户需要
2. 欢迎需求的变化
3. 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好
4. 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作
5. 最好的信息传达方式是面对面的交谈

敏捷宣言

敏捷宣言内容

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

敏捷软件开发方法

极限编程 XP

1. eXtreme Programming，极限的含义是指把好的开发实践运用到极致
2. 极限编程的有效实践
   1. 客户作为开发团队的成员 —— 客户代表
   2. 使用用户素材
   3. 短交付周期
   4. 验收测试
   5. 结对编程——结对编程就是由两名开发人员在同一台计算机上共同编写解决同一个问题的程序代码，通常一个人编码，另一个人对代码进行审查与测试，以保证代码的正确性与可读性。结对编程是加强开发人员相互沟通与评审的一种方式。
   6. 测试驱动开发——极限编程强调“测试先行”。在编码之前，应该首先设计好测试方案，然后再编程，直至所有测试都获得通过之后才可以结束工作。
   7. 集体所有
   8. 持续集成
   9. 可持续的开发速度 <=40h/week
   10. 开放的工作空间
   11. 重构
   12. 使用隐喻

Scrum

1. 迭代式增量软件开发过程：

1. Scrum 中的文档
   1. 产品订单（product backlog)：整个项目的概要文档，包含了已划分优先等级的、项目要开发的系统或产品的需求清单，是动态的。
   2. 冲刺订单（sprint backlog)：细化了的文档，包含了团队如何实现下一个冲刺的需求信息。
      1. 哪些产品订单会加入一次冲刺由冲刺计划会议决定。会议中，产品负责人告诉开发团队他们需要完成产品订单中的哪些订单项，开发团队决定在下一次冲刺中承诺完成多少订单项。
      2. 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog)，这意味着在一个冲刺中需求是被冻结的。
   3. 燃尽图（burn down chart)
2. Scrum 常见活动
   1. Sprint Planning Meeting
   2. Daily standup meeting
   3. review meeting
   4. retrospective meeting
   5. sprint
3. Empirical Process Control VS. Statistical Process Control，不同于统计过程控制方法（也叫预测式、计划式）不能解决不可预见的需求变化问题，Scrum 采用的实证过程控制承认问题无法完全理解或定义，即用户可以在项目过程中变更需求，关注于如何使开发团队快速推出和响应需求变化的能力最大化
4. Scrum VS. XP
   1. 迭代周期不同。XP 迭代周期为 12 周，而 Scrum 迭代周期为 24 周
   2. 迭代中是否允许需求变更。XP 中只要变更需求与原需求所需时间资源相等即可变更，而 Scrum 在迭代中需求被冻结
   3. 迭代中，需求是否严格按照优先级来实现。XP 中务必遵守优先级别，Scrum 中则比较灵活，原因是可能有需求依赖问题
   4. 过程工程化。Scrum 开发过程并未工程化，要求开发者自觉保证，但 XP 则对开发流程定义严格，例如 TDD，结对编程，重构等

Kanban 方法

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

补充：PSP 个体软件过程

PSP 是什么？

1. PSP 是包括了数据记录表格、过程操作指南和规程在内的结构化框架。
2. PSP 着重于软件开发人员的个人能力提升，体现在估算能力、计划能力、计划执行以及质量管理等方面
3. 基本的 PSP 包括策划、设计、编码、编译、单元测试以及总结等阶段。
   1. 每个阶段都有相应的过程操作指南，用来指导该阶段的开发活动。
   2. 每个阶段，都有相应的过程操作指南，用来指导该阶段的开发活动。
   3. 所有的开发活动都需要记录相应的时间日志和缺陷日志。

PSP 基本原理（为什么要有 PSP）

1. 软件系统的整体质量由该系统中质量最差的某些组件所决定
2. 软件组件的质量取决于开发工程师所使用的开发过程。
3. 软件工程师应当自己度量、跟踪自己的工作流程，并建立持续的自我改进机制（在自己开发过程的偏差中学习、总结，并将这些经验教训整合到自己的开发实践），自己管理软件组件的质量。

上述基本原理除了继续肯定“过程质量决定最终产品质量“这一软件过程改进的之外，更加突出了个体软件工程师在管理和改进自身过程中的能动性。这就形成了 PSP 的理论基础。

PSP 的成熟度级别

PSP 的度量

基本度量项

1. 度量时间：序号、所属阶段、开始时间、结束时间、中断时间、净时间、中断原因
2. 度量缺陷：序号、发现日期、注入阶段、消除阶段、消除时间、关联缺陷、缺陷产生原因
3. 度量规模：使用 PROBE 方法
   1. 选择的规模度量方式必须反映开发成本
   2. 度量规模必须被精确定义
   3. 度量规模必须有自动化方法统计
   4. 有助于早期规划
4. 日程（TSP）

度量的作用

1. 度量体现着决策者对试图要实现的目标的关切程度。
2. 度量帮助过程的实践者了解过程状态，理解过程偏差。

规模度量标准

1. 选择的度量方式必须反映开发成本。
2. 选择的度量方式必须精确。
3. 选择的度量方式必须能用自动化方法来统计。
4. 选择的度量方式必须有助于早期规划。

规模的度量的困境

1. 精确的度量方式往往不便于早期规划。
2. 有助于早期规划的度量往往难以生成精确度量结果。

注意点 1：整理历史数据

以估算规模为例，可以假定代理规模与实际程序规模之间存在简单关系映射、正态分布、对数正态分布，也可以假定不知道两者之间的关系，按照线性回归方法进行计算。

1. 简单方法

   1. 内容：最小值作为 VS、最大值作为 VL、中值作为 M,VS 与 M 均值作为 S、VL 与 M 均值作为 L
   2. 优点：计算简单
   3. 缺点：不稳定

2. 正态分布法

   1. 内容：均值作为 M，计算标准差 σ，则 S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ
   2. 优点：相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵

3. 对数正态分布法:

   1. 内容：
      1. 以 e 为底计算所有数据的自然对数
      2. 取对数之后的值的均值作为 M，计算相应标准差 σ;S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ
      3. 取反对数
   2. 优点：更加符合人们对于程序的规模的直观感觉，因为大多数人习惯写很多规模很小的程序，少量规模较大的程序

4. 线性回归方法

   1. 计算的时候计算了两组线性回归的参数，也就是项目所需的资源并不是直接由程序规模和历史数据中的生产效率相除得到。程序的复杂度和程序规之间并不是简单的正相关关系。
   2. 线性回归方法估算的是一定概率条件下估算值的分布。例如最终实际程序规模有 90%的可能性落在（a,b)区间内
   3. Range 为在一定概率条件下的变化区间，而 p 为概率
   4. Variance 为扰动程度：有时候，历史数据中的一些极端数据会造成相关性的“假象”，故需要先进行数据除噪。

5. Plan Size 和估算的类数量不呈现 45 度，是受到了估算误差和方法外代码的数量共同影响

6. 该方法没有使用生产效率进行计算，为什么在 PROBE 中不使用生产效率？这样子使用好不好？因为 Plan Size 是在一个范围内波动，生产效率也在一个范围内波动，如果将生产效率作为分母，那么可能会导致更大的误差，也就违背了误差的出发点。

7. 估算能力的强弱关注是多稳定，而不是多接近具体的实际情况

注意点 2：处理有限的历史数据

1. 规模估算
   1. 往往可以依据历史数据来完成，使用代理规模与实际程序规模之间的关系。
   2. 其原因在于规模估算结果的偏差产生原因相对客观，偏差可以用以修正新的估算结果。
   3. 估算规模对历史数据的要求如下

其中 r 为相关性（两组数据之间相互关联的程度，PSP 中要求 r>= 0.7)，其中 S 为显著性（两组数据的相关关系出现的偶然性，PSP 要求 s<=0.05)

1. 时间估算
   1. 使用代理规模和实际开发时间的关系。
   2. 时间估算的偏差产生原因更加复杂：一方面和规模有关，另一方面和人的主观能动性有关。
   3. 历史数据中的时间偏差可参考价值不大。

其中 r 为相关性（两组数据之间相互关联的程度，PSP 中要求 r>= 0.7)，其中 S 为显著性（两组数据的相关关系出现的偶然性，PSP 要求 s<=0.05)

注意点 3：处理极端数据

1. 极端数据可能造成相关性假象。

往年真题

这篇文档按照ppt结构整理往年题中的选择题和大题，不含课堂练习（移步ppt整理.md）

同时，因为ppt整理内容冗杂，这里总结必背的知识点。

2023回忆

选择：

这个题把确认改成验证了

还有个新选择题：下面的内容+EVM仅仅能用在大型项目。

我忘了EVM不能用在质量管理了orz

大题：

1.生命周期模型+软件过程；瀑布模型

2.质量管理的理解，如何做到质量管理

3.质量路径

4.敏捷宣言

5.自主团队的特征和为什么要用自助团队

6.项目估算的理解和如何开展估算

7.定量管理的基本范式

8.CMMI对软件研发实践的启发，参考价值

1.概述

内容

XX管理：目标、状态、纠偏

软件开发典型流程：需求-设计-开发-代码评审-单元测试-集成测试（大部分是功能测试）-系统测试-试运行/验收

选择

‏关于软件过程管理，以下哪一种说法是比较贴切的：

‏A.软件过程管理关注的是企业软件过程能力的稳定输出和提升。

B.软件过程管理主要关注软件成本和质量目标的达成。

C.进入互联网时代，软件过程管理是过于老套的话题。

D.软件过程管理是软件企业发展到较高层次才需要关心的话题。

正确答案：A

‎软件危机和软件工程这两个概念提出时间是？

A.上世纪八十年代

B.上世纪六十年代

C.上世纪七十年代

D.上世纪五十年代

正确答案：B

软件开发的本质难题中哪一个与软件发展阶段没有直接关系？

A.可变性

B.不可见性

C.一致性

D.复杂性

正确答案：B

关于Brooks提及的软件开发本质难题，下列说法中不准确的是。AB

A.本质难题总共有四个，分别为复杂、不可见、可变和质量挑战

B.既然是本质难题，那就说明是根植于软件开发本身，因而是不可能在软件开发当中得到缓解

C.严格来说，只有不可见才是真正的“本质”难题，其他三个因项目而异

D.四大本质难题贯穿软件发展的不同历史段，但是在不同历史阶段，相互凸显程度不一样

质量挑战不是本质难题；本质难题可以缓解，不可消除

下列哪些项不属于管理活动应该包含的要素？ABD

A.成本：成本、质量、工期是软件项目管理的三大目标，不是三大要素

B.质量

C.目标：管理活动包括目标、状态、纠偏

D.工期

下列名词和术语中不属于软件过程的有哪些？BD

A.SCRUM

B.CMM/CMMI：是过程改进模型，而非软件过程或软件过程模型

C.GATE方法

D.IDEAL：是过程改进模型

【2015B】CMM的创始⼈是哪位_____? C

Boehm

Juran

Humphrey

Crosby

简答

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

1. (3’)生命周期模型是对一个软件开发过程的人为划分，以突出验证和上游开发阶段之间的对应关系。
2. (3’)生命周期模型是软件开发过程的框架，是对软件开发过程的一种粗粒度划分，侧重于主要阶段而不是内部细节。
3. (2’)生命周期模型往往不包括技术实践。

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

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

1. 管理对象上：前者是各类软件项目，后者是软件过程
2. 实现目标上：前者的三大典型目标是成本、质量和工期，为了降低/减少各种无谓的损耗来实现本该有的性能；后者是为了让软件过程在开发效率、质量等方面有着更好性能绩效
3. 参考模型上：前者参考生命周期模型，后者是CMM/CMMI，SPICE等

【2022Fall】随着 ChatGPT 的横空出世，以大模型为代表的 AI 技术势必对各行各业带来前所未有的影响。具体到软件工程，人工智能技术的应用也日渐常见，请结合这一背景畅想下本课程涉及的若干话题可能在这一波 AI 浪潮中的挑战和机遇。至少应该包括如下话题：项目管理、质量管理、过程改进。

软件项目管理是针对于特定的一个项目组，项目目标的一个实现。如一个软件项目小组或者说某一个特定软件项目的成本质量、工期、要实现的这些目标。项目管理关注的是目标的一个实现。

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

1. 软件项目管理包括估算、计划、跟踪、风险管理、范围管理、人员管理、沟通管理等等。
2. 软件项目管理的对象是各类软件项目

PSP 中面向用户的质量观，定义质量为满足用户需求的程度。

质量策略

1. 使用缺陷管理来代替质量管理
2. 高质量的产品也就意味着组成软件产品的各个组件基本无缺陷
3. 各个组件的高质量是通过高质量评审来实现的；

PSP 质量控制的衍生指标

过程改进：CMMI模型

1. 项目管理：

挑战：

• 复杂性增加： 大规模AI项目可能涉及复杂的模型训练、部署和维护，增加了项目管理的难度。
• 不确定性： AI项目中存在许多不确定性因素，如模型性能、数据质量等，需要灵活的项目管理方法。

机遇：

• 自动化项目管理： 利用AI技术自动化项目管理任务，例如资源分配、进度跟踪，提高管理效率。
• 数据驱动决策： 利用大数据和分析技术，基于实时数据做出更准确的决策，提高项目成功的概率。

2. 质量管理：

挑战：

• 模型不透明性： 对于使用深度学习等复杂模型的项目，模型的不透明性可能导致质量评估的困难。
• 数据质量： AI系统对高质量数据的依赖性，使得数据质量成为质量管理的关键挑战。

机遇：

• 自动化测试： 利用AI技术实现自动化测试，提高测试覆盖率和效率。
• 质量监控： 利用实时监控和分析技术，对系统性能和输出进行持续监测，及时发现潜在问题。

3. 过程改进：

挑战：

• 快速变化的技术： AI技术的快速发展使得过程改进需要更加灵活，适应快速变化的技术环境。
• 人才需求： 缺乏AI方面的专业人才可能限制过程改进的实施。

机遇：

• 自适应过程： 引入自适应的过程改进方法，能够根据项目和技术的变化进行灵活调整。
• AI辅助决策： 利用AI技术辅助决策过程改进策略，提高改进的准确性和效果。

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

软件过程改进模型PDCA 模型的步骤：

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

IDEAL模型

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

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

2.软件过程的历史演变和经典工作

选择

以下哪个因素促成了软件成为独立的产品？

A.操作系统的出现

B.高级程序设计语言的出现

C.互联网的出现

D.个人电脑的出现

正确答案：A

‌根据敏捷宣言，以下哪项描述了更多的价值？

A.响应变化、个体和交互、流程和工作、客户协作

B.客户协作、遵循计划、可工作的软件、个体交互

C.个体和交互、可工作的软件、客户协作、响应变化

D.可工作的软件、个体交互、响应变化、相近的文档

正确答案：C

‍以下描述中，哪几种是网络化和服务化这个阶段的典型软件应用特征？

A.用户数量急剧增加

B.通过SaaS等方式来发布软件系统

C.快速演化、需求不确定

D.通过CD和DVD等方式支持大容量和快速分发软件拷贝

正确答案：A、B、C

关于形式化方法的描述当中，不正确的有哪些？

‎A.这种方法是网络化和服务化阶段用来应对软件开发本质四大难题而提出来的（错误，应该是软件成为独立的产品）

B.这种方法应用范围有限，例如：不适合跟客户讨论需求。

C.这种方法的主要目的是解决软件开发的效率问题（主要解决质量和正确性）

D.这种方法对开发人员技能有较高的要求

正确答案：A、C

关于迭代式方法的说法哪些是比较恰当的？

‌A.迭代式方法主要是为了解决软件开发的质量问题（应该是解决效率）

B.迭代式方法是上世纪九十年代中后期才出现的一种方法（1970-1980，敏捷才是九十年代中后期）

C.迭代式方法主要特征在于将软件开发过程视作一个逐步学习和交流的过程

D.迭代式方法是指一类具有类似特征的方法

正确答案：C、D

DevOps的哪些特点可以有效支撑当前社会对软件系统的期望？

A.敏捷开发、精益思想以及看板方法，支持快速开发、交付、迭代和演化

B.微服务架构设计

C.虚拟机技术的大量应用

D.工具链支持高效率的自动化

正确答案：A、B、C、D

下列软件应用和开发的典型特征中属于软硬件一体化阶段的是？BC

A.可以通过引入操作系统，摆脱了硬件束缚（软件成为独立的产品）

B.几乎不需要考虑需求变更

C.缺乏科班的软件工程师

D.系统兼容对应软件开发的成败非常关键（软件成为独立的产品）

【2015B】XP规定开发⼈员每周⼯作时间不超过___⼩时，连续加班不可以超过两周，以免降低⽣产率？(B)

30

40

50

60

下列不属于看板方法典型实践的是？BD

A.可视化工作流

B.站立式会议

C.限定WIP

D.重构

下列术语描述的技术或者方法是同类型的是？CD

A.CMMI SPICE PDCA：前两者是软件过程管理，后一个是软件过程改进

B.IDEAL XP SCRUM：IDEAL 是软件过程改进，XP 和 SCRUM 是软件过程

C.Cleanroom Gate TSP：软件过程

D.Waterfall SCRUM XP：软件实践

简答

【2021Fall】【2020-mid】如何理解瀑布模型（6 分）

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

【2022Fall】【2021Fall】【2020-mid】请完整描述敏捷宣言的内容。我们应该如何正确理解敏捷宣言？（10 分）

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

一些不合适的关于敏捷的说法：

• 轻量级方法：这是对 XP 一类方法的误导，实际上，这类方法对工程规范有着极为严格的要求
• 变更驱动：仅仅是口号，对待变更，所有软件工程方法都是限制和管理的态度
• TDD 可以提供更高的开发质量：并没有足够的证据支持

【2020-mid】请结合软件发展的三大阶段，描述不同阶段的特点+典型软件开发方法和实践（10分）

1. 软硬件一体化
   1. 特点：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更
   2. 主流开发方法：线性顺序过程，事实上是硬件开发流程；measure twice cut once；Code and Fix；
2. 软件成为独立的产品
   1. 特点：摆脱了硬件的束缚(操作系统)、功能强大、个人电脑出现、需求多变、兼容性要求、来自市场的压力
   2. 主流开发方法：形式化方法、结构化程序设计和瀑布模型、成熟度模型
3. 网络化和服务化
   1. 特点：功能更复杂、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方式的变化、进一步的服务化和网络化、盛行开源和共享文化
   2. 主流开发方法：迭代式开发、敏捷开发(XP、Scrum、Kanban)、开源软件开发方式

brooks本质难题对它的影响：

严格来说，只有不可见才是真正的“本质”难题，其他三个因项目而异（复杂性：实体数量众多；不可见性：软件项目是一个逻辑实体；可变性；一致性）

四大本质难题贯穿软件发展的不同历史段，但是在不同历史阶段，相互凸显程度不一样

”迭代式：大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成， 而是通过多个迭代周期，逐步来完成交付。“中什么词最重要？

逐步学习和交流的过程：确保满足客户的反馈和期望。

背一下迭代式的定义

【2015B】【2016】请结合 SCRUM 这种敏捷方法论述敏捷方法应该具备的特征？同时解释为何常见的若干种描述敏捷方法对立面的方法的特征（例如，严格、重型、计划驱动等等）并不合适？10’

1. 特征
   1. 小周期迭代
   2. 快速响应变更
   3. 价值交付
   4. 自动化
2. 特征解释：
   1. 严格：所有优秀的工程方法和实践都是严格的。
   2. 重型：如上，此外，轻量级和重型其实并没有刻画具体方法，何为重型，并没有严格定义；而且，对于变更这件事情，几乎所有方法都是限制，因此，很难说敏捷方法是轻量级方法。
   3. 计划驱动：所有正式的项目都是计划驱动的，否则计划的作用无法体现

【2015A】敏捷方法的特征有哪些？哪些关于敏捷特征的说法施加于敏捷方法之上是不合适的？为什么？10’

1. 特征：小周期迭代式持续交付、敏捷宣言
2. 关于敏捷方法的一些特征表述可能带着一定的误导，例如：
   1. 轻量级方法：这是对以 XP 为代表的一类方法的误导，事实上，这类方法对工程规范有着极为严格的要求;
   2. 拥抱变更、变更驱动：仅仅是口号，对待变更，所有软件工程方法都是限制和管理的态度。
   3. TDD 可以提供更高的开发质量：并没有足够的证据支持。

【2014】为何说将“规范方法”、“计划驱动方法”等特征作为敏捷方法的对立面带有很大的误导性质？如何通过多种维度改进这种对各类开发过程的理解？10’

1. 敏捷：敏捷目的、敏捷价值观、敏捷原则
2. 影响敏捷与规范方法选择的五个维度
   1. 如果只有强有力的规范而缺乏敏捷，将导致官僚作风，进而停滞不前。团队将陷入为了测量而测量的处境之中，缺乏创新。
   2. 缺乏创新的敏捷则如同一个新创公司在盈利之前的不负责任的狂热
   3. 计划驱动的开发人员必须敏捷，敏捷开发人员必须规范。

这是因为敏捷方法并不排斥规范和计划，它们只是更加注重适应变化和快速交付价值。

严格的纪律和缺乏敏捷性会导致官僚主义和缺乏创新，而缺乏纪律的敏捷方法会导致不负责任的狂热和不稳定。因此，计划驱动的开发人员需要敏捷的思维方式和能力，而敏捷的开发人员需要有纪律的方法和实践来确保质量和可维护性。

不对立，反而相得益彰：

• 计划驱动的开发人员必须敏捷，敏捷开发人员必须规范。成功的关键在于找到两者的平衡点。

• 这个平衡点随项目所处的环境以及所涉及的风险而变化。仅凭一腔热情径直地采用极端方法的开发人员，必须学会如何根据实际情况恰当地平衡敏捷与规范。

【2021】简述DevOps实践、方法、技术(10分)

1. 方法论的基础是软件敏捷开发、精益思想和看板 KanBan 方法
2. 以领域驱动设计为指导的微服务架构方式
3. 大量虚拟化技术的使用
4. 一切皆服务 XaaS(X as a Service) 的理念指导
5. 构建了强大的工具链，支持高水平自动化。

Linus定律

大教堂与市集：开源软件开发方式

如果有足够多的 beta 测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。

3.团队动力学

选择

**下列描述当中，属于过程经理的工作内容有哪些？AC **

A.建立团队的开发标准

B.主持项日周例会（项目组长）

C.记录周例会的会议记录

D.制定开发计划（计划经理）

简答

【2020-mid】请结合软件开发的特点介绍软件项目管理中自主型团队的必要性以及自主团队应该具备的特征？5 分

1. 软件开发是一项既复杂又富有创造性的知识工作 (1’)
2. 软件开发是一种智力劳动 (1’)
   1. 处理和讨论 极其抽象的概念
   2. 把不同的部分（不可见）整合成一个可以工作的系统
3. 这就要求软件开发工程师
   • 全身心参与工作
   • 主观意愿上追求卓越
4. 这就要求管理者激励并维持激励
5. 管理知识工作的关键规则是：管理者无法管理知识工作者，知识工作者必须实现并且学会自我管理。要自我管理，知识工作者必须：
   • 有积极性
   • 能做出准确的估算和计划
   • 懂得协商承诺
   • 有效跟踪自己的计划
   • 持续按计划交付高质量产物
6. 而“胶冻态团队”恰恰可以让知识工作者实现自我管理，也就是自主团队。
7. 含义：软件工程师所从事的工作一般称之为复杂的知识工作。在这种性质的工作中，实现软件工程师的自我管理往往可以获得最好的工作效率和质量水平。如果整个团队的所有成员都实现了自我管理，也就形成了所谓的自主团队。
   • 自主团队可以形成“胶冻态团队”。
8. 自主团队具备如下的特点： （每两点 1 分）
   1. 自行定义项目的目标
   2. 自行决定团队组成形式以及成员的角色
   3. 自行决定项目的开发策略
   4. 自行定义项目的开发过程
   5. 自行制定项目的开发计划
   6. 自行度量、管理和控制项目工作

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

• 项目组长：激励团队成员，主持例会，汇报项目状态，分配工作任务，维护项目资料，组织项目总结
• 开发经理：指定开发策略，开展产品规模估算和时间资源估算（由开发经理做，而非计划经理做）；开发需求规格说明、高层设计、设计规格说明、用户支持文档；实现软件产品，开展集成测试和系统测试，参与项目总结
• 计划经理：带领小组开发项目计划，平衡计划，跟踪项目进度，参与项目总结
• 过程经理：带领团队定义和记录开发过程并且支持过程改进，建立和维护团队的开发标准（命名规范、编码规范、接口标准、…），记录和维护项目的会议记录，参与项目总结
• 质量经理：带领团队跟踪质量计划，向项目组长警示质量问题，评审以消除质量问题，项目小组评审的组织者和协调者，参与项目总结
• 支持经理：识别开发过程中需要用到的工具和设施，管理配饰管理系统，维护软件项目词汇表，维护项目风险和问题跟踪系统，支持开发过程中复用策略的应用，参与项目总结

【2022Fall】结合“软件开发作为一种知识工作，需要领导者而不是一般的经理”，阐述知识工作领导者应该具备的品质或者特点（至少三项）

•Honest – did what they said they would do 诚实 – 说到做到

•Competent – skills and knowledge 能力 – 技能和知识

•Visionary – can they see past the horizon, do they have a believable view of a desirable future? 远见——透过事物看本质，对理想的未来有可信的看法

•Inspirational – do they have a positive, enthusiastic, and energetic view of the future? 鼓舞人心-对未来有积极、热情、精力充沛的看法

马斯洛需求理论是什么，对软件工程实践的启发？

1. 五个层次：生理需求（Physiological)、安全感（Safety)、爱和归属感（social)、获得尊敬（Esteem)、自我实现（Self-Actualization)
2. 注意
   1. 自我实现是最高的层次。
   2. 激励来自为没有满足的需求而努力奋斗。
   3. 低层次的需求必须在高层次需求满足之前得到充分满足。
   4. 满足高层次的需求的途径比满足低层次的途径更为广泛。
3. 威逼利诱比较低层，鼓励承诺在 4-5 层，效果比较好

请描述高质量评审团队的特征，并解释TSP是如何支持高质量评审团队的

问自主团队的特征

4.估算、计划和跟踪

选择

关于PROBE估算法，下述各种说法中，不正确的有哪些？

A.PROBE估算结果带着小数，肯定不准确，因而， 不应该在项目估算的时候使用。

B.PROBE不能给出精确估算，因而适合用来跟用户讨论需求和规模。（精确度量和早期规划需要的度量之间的桥梁）

C.PROBE方法不能用来估算质量。

D.PROBE方法不需要历史数据。

正确答案：A、B、D

下列关于挣值管理方法的描述中错误的是？ C

A.这是一种可以用来跟踪项目预算消耗的方法

B.这种方法高度依赖估算准确性

C.这种方法可以支持质量管理

D.这种方法可以用来跟踪项目进度

C：挣值管理方法不支持质量管理，因为它们关注的是成本节约而不是质量改进。他们必须找到将质量考虑在内的正确解决方案来支持质量管理。

完成一份完整的项目日程计划，需要下列哪些信息？ABD

A.任务清单

B.任务顺序

C.质量要求

D.人员资源水平

PROBE方法估算规模的时候，下列说法不恰当的是：AC

PROBE A 方法要求三组以及三组以上的代理规模数据和实际规模数据，且要求其相关性R²大于等于 7；（是R>0.7）

PROBE C 方法仅仅需要根据上一次项目中估算值和实际值的比例进行调整即可；

应用 PROBE A 方法的估算结果一定会好于 PROBE B 方法；（不一定）

PROBE 方法的优势之一是采取了相对大小，而非绝对大小，辅助估算着思考和判断；

下列指标中适合用作风险参数的是：ABC

A.发生概率；

B.影响程度；

C.风险系数；

D.触发阈值

简答

【2020】EVM进度差异?为什么?

整体提前了，这周的工作没达到计划，创造价值比预计的少，可能是低估了项目的难度

总体进度，通过to date看，Earned value to date这一项里Actual>Plan,说明迄今为止进度没有落后。

但是，Hours to date总共花的时间大于预期，每个小时预期创造0.3个价值，而实际每小时创造0.28的价值，说明实际工作效率不如预期，所以在下周或者过几周，这个项目的进度可能就会逐渐落后。

【2021】EVM项目进度如何？是提前还是落后？项目有什么风险？

第一天需要完成50个值，第二天需要完成20个值，第三天需要完成30个值。

BAC：第一天50，第二天70，第三天100.

超期情况，EV：第二天50值，AC：第二天100值。

CV=EV-AC=-50,SV=EV-PV=-20，所以进度滞后，进度效率低；费用超支，资金使用效率低

有可能出现第二天用户说，任务B和任务C不做了（项目进度落后变为了项目进度正常

EVM例题

（1） 项目进度是否有偏差？偏差百分比多少？对应偏差日期约为多少周？（本题满分2分）

出现偏差，EV=22.3,PV=28.3,SPI=EV/PV=79% 偏差百分比约为-20% 对应偏差日期约为7*-20%=-1.4周

（2） 出现进度偏差的原因是什么？（本题满分2分）

出现进度偏差的原因可能是项目团队低估了工作的难度。

（3） 原计划在17周完成，按照目前进度，预计什么时候完成？ （本题满分2分）

actual 效率 22.3 / 493.4 = 0.045 每个hour获得的EV Value
plan 效率 28.2 / 467 = 0.060
实际时间T * 0.045 = 17 * 0.06 T = 22.6

根据目前进度，预计项目大约会在第23周完成。

（4） 如果还需要按照原定计划完成，在允许调整（增加或者减少）人员的情况下，可以怎么调整？为什么？ （本题满分4分）

如果还需要按照原定计划完成，可以增加项目团队的人数或增加每个人的任务量，以提高效率与进度。

【2020】请简要描述按照通用计划框架，为了开发合理的项目计划，应该要做哪些估算？PROBE 方法充当了什么角色？

【2020】请描述一下PROBE方法的基本原理和过程，并解释在应用PROBE A方法估算时间的时候，为什么不用历史数据中的生产效率数据

基本原理（4’）：2点

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

过程：

概要设计：确定产品功能和生产它们所需的组件/模块，将它们与现有程序进行比较，估算它们的规模，并将它们组合起来得出总规模。

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

【2013】【2015A】【2018Fall】谈谈你对项目估算的认识，并简要解释应用 PROBE 方法估算的优缺点。

• 项目估算
  • 规模估算：可以根据历史数据来完成，其原因在于规模估算结果的偏差产生原因相对客观，偏差可以用以修正新的估算结果
  • 时间估算：产生原因更加复杂，一方面和规模有关，另一方面和人的主观能动性有关；因此时间估算偏差的原因可能来自估算结果本身，这使得历史数据中时间偏差参考价值不大
• 估算本质上是一种猜测，追求的目标是一致性以及估算结果使用者对估算的信心
• PROBE估算原理：相对大小矩阵
• PROBE优缺点
  • 优点：通过定义的估算过程、数据收集以及使用的框架，使得估算结果尽可能一致，从而使得一些统计方法可以被用来调整估算结果，增强使用者对估算结果的信心
  • 缺点：但是这种估算方法非常依赖高质量的历史数据，如果数据不完整或质量不高，就可能导致估算结果有显著偏差

【2020-mid】请描述 PROBE ABCD 方法在估算规模的时候，对历史数据的质量有什么要求？

PROBE A B C D 方法需要使用高质量的历史数据来估算规模。这些数据必须完整、准确、可靠，并且客观地反映现实。它还必须准确反映给定时期的规模以及时期之间的变化情况。

【2013】【2014】【2015A】【2015B】【2016】如何制定一份让人无法拒绝的计划，请描述基本步骤和一些注意事项

正推:除了概要设计和资源估算之外，其他环节尽可能自动化完成。充分参考历史数据进行估算

1. 估算规模

2. 估算资源

3. 日程计划：任务清单->资源清单->日程计划

4. 质量计划

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

5. 风险计划

   1. 目标：在风险发生前，识别出潜在的问题，以消除潜在问题对项目产生的负面影响。
   2. 风险管理大致分为两部分，即风险识别和风险应对。
   3. 识别风险之后，就应当制定相应的风险管理策略，以应对各类风险。典型的策略包括：风险转嫁、风险解决、风险缓解

【2014】请解释规模估算和资源估算中估算偏差含义之间的差异，并据此简要列举对软件开发活动的启发？

工作量与实际工作量之间的差距 VS 资源数量与实际资源数量之间的差距。

启发：编写描述准确的需求文档，监控估算偏差，并及时分析以避免延误。

【2022Fall】挣值管理的三种实现方式。分别是简单、中级以及高级。请分别描述上述三种方式所具备的特质。

1. 简单实现：这种方式仅仅关注进度信息。

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

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

   1. 日程偏差SV = EV – PV;
   2. 日程偏差指数SPI = EV/PV；

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

【2023】【2022】规模估算和资源估算的要点

1. 尽可能划分详细一些：估算多个部件的时候，总的误差会比各个部件的误差的总和小
2. 建立对结果的信心
3. 依赖数据
4. 估算要的是过程，而非结果，估算的过程是相关干系人达成一致共识的过程。

估算的目的：给各类计划提供决策依据

【2014】估算与计划的差异

目的不同、包含的活动不同、典型计划流程包括估算

1. 估算目的是给各类计划提供决策依据，估算对象分为规模、时间和日程。估算追求所有的参与者对规范结果的一个认同。而不是追求估算结果客观上的正确性
2. 项目计划主要包括规模、资源估算、日程计划、质量计划、风险计划等，目的分别是保证项目的进度、质量、在风险发生前识别问题等
3. 典型计划流程回顾：估算规模、估算资源、规划日程

【2014】应对风险的典型策略有哪些？请举例说明

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

典型策略：

1. 风险转嫁：通过某种安排，在放弃部分利益的同时，将部分的项目风险转嫁到其他的团队或者组织。比如有的公司采取外包的方式，把一部分有技术风险的产品组建交由其他公司开发。
2. 风险解决：指采用一些有效措施，使得风险的来源不再存在。比如针对项目面临的技术风险，采取技术调研或者引进技术专家的手段。
3. 风险缓解：指容忍风险的存在，采取一些措施监控风险，不让风险对项目最终目标的实现造成负面影响。一般情况下，都需要指定相应的风险缓解计划。当风险超过设定的阈值时，实施该计划，以使受冲击的部分回归到可接受的风险等级。

5.质量管理

内容

质量实践和质量管理是不一样的

1. 质量实践包括测试等等
2. 质量管理是对质量的管理，而不是实践，管理必须有上面所说的三个要素（有目标、状态跟踪、纠偏措施）

选择

关于质量路径（Quality Journey），下列说法中哪些不恰当。

A.质量路径与个体软件工程师无关，是团队层面的集体努力。

B.高质量软件产品最终还是需要依赖测试来确保。

C.进入测试之前的高质量，是获得测试之后高质量软件系统的前提条件。

D.质量路径中所列举的方法都是提升开发质量的有效手段，可以随意选择使用。

正确答案：A、D

关于面向用户的质量观，我们应该关注如下哪些问题？

A.用户期望是否有优先级？

B.用户期望的优先级对软件开发的影响？

C.界面和可操作性是首要的，因为这是用户能直接感受到的。

D.真实用户是谁？

正确答案：A、B、D

PSP当中为什么用缺陷管理替代质量管理？下述说法中正确的是：

A.因为缺陷管理相关的活动（例如，测试等）本来就是软件开发中必须要开展的活动。

B.因为缺陷往往对应了面向用户质量观中的首要用户期望。

C.因为单纯质量管理很难操作。

D.因为缺陷管理和质量管理其实是一回事。

正确答案：B、C

关于评审检查表，下述说法中不恰当的是：

A.评审检查表应该保持稳定，确保缺陷不会被遗漏

B.评审检查表应该定期更新

C.项目团队所有人应该共用一份评审检查表，体现统一性

D.评审检查表应该是个性化的

正确答案：A、C

关于评审，下述说法中不恰当是：

A.代码的个人评审应该安排在单元测试之后，确保评审对象有着较高的质量，提升评审价值。

B.如果安排了代码的小组评审，那么代码个人评审就可以不用做。

C.代码的个人评审也应该通过评审检查表来进行。

D.代码的个人评审最好交叉进行，因为阅读自己代码容易产生思维定式，不利于缺陷发现。

正确答案：A、D

关于质量的各种定义当中，下述哪些质量属性属于内部属性？

A.可靠性

B.安全性

C.可移植性

D.可扩展性

正确答案：C、D

下述各个度量项中，哪一个不是PSP的基本度量项？

A.规模

B.缺陷

C.时间

D.风险

正确答案：D

关于PQI，下述说法中不恰当的是：

A.PQI五个分指标都可以超过1.0，比如，设计时间多于编码时间的时候，该分指标就超过1.0了

B.PQI越高越好，最好达到1.0

C.PQI可以为过程改进提供依据

D.PQI可以用来辅助判断模块开发的质量

正确答案：A、B

简答

【2020】请用真值表检验从CheckPW状态出发的状态组合，并给出该状态机是否正确的明确结论和理由。（本题满分 10 分）

（注意这里在转换条件的基础上多写了->CheckID 后面才接/后面的内容）

符合完整性：所有条件组合都包含在内，每一列都有东西。(不存在有一种排列组合ABC都没有变化)

违反正交性：同样条件组合的下一个状态需要唯一。（这里同一条件同时跳到BC状态是错误的）

【2014】如何对某个软件产品组件进行产品质量评价？可以选择哪些度量元，这些度量元如何辅助判断产品组件的质量？

基本度量项：

1. 度量时间：序号、所属阶段、开始时间、结束时间、中断时间、净时间、中断原因
2. 度量缺陷：序号、发现日期、注入阶段、消除阶段、消除时间、关联缺陷、缺陷产生原因
3. 度量规模：使用 PROBE 方法
4. 日程（TSP）

质量控制的衍生指标：

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

A/FR：质检失效比，用来衡量成功鉴定与失败鉴定的比率。

PQI：过程质量指标，用于提高最终产品的质量水平。

Review Rate：评审的速度，用于衡量软件工程师花在审查上的时间。

DRL（缺陷消除效率比）：衡量缺陷去除活动的有效性。

【2015A】请结合 A/FR、PQI、Review Rate、DRL、Yield 尽可能具体描述一个软件项目应该如何从多方面来确保开发的高质量？

这些指标既是开发过程中质量管理的一些参考指标，同时也体现在计划安排中应该注意的质量元素。具体如下：

1. 在项目计划过程中应该安排确保高质量开发结果的活动，例如，按照 A/FR、PQI 等指标的要求，安排对各类产物（文档和代码）的个人评审和小组评审；
2. 这些评审活动应该满足一定的要求，特别体现在时间方面。例如，评审时间应该多于测试时间的两倍以上（A/FR）；评审时间应该是相应开放时间的 50%以上（PQI）；评审速度要求（Review Rate）等
3. 充分借鉴质量指标所体现的开发质量状况，尽早制订相应的质量补救措施。例如，PQI 所体现的缺陷密度、所有上述指标的参考值等等。一旦超标，往往意味着质量方面有偏差，应当及时补救。
4. 利用 yield 等指标，构建质量预测模型，更加积极地判定和控制开发质量；
5. 依据 PQI 和 Yield 指标所体现的信息，通过过程改进来提升开发质量。

【2014】解释过程度量项定义时应当注意的方面，并且据此评价 PSP 基本度量元的合理之处？

注意的方面：范围、定义、目标值、收集方法、报告方法和持续改进措施。

PSP 基本指标在时间、缺陷、规模、日程方面是合理的，并且是可操作的、可量化的和可测量的，以提供准确的评估。

【2013】【2018Fall】解释 PQI 指标，如何计算，如何使用

PQI 是用于衡量软件过程整体质量的指标。它由五个指标组成：设计、设计审查、代码审查、代码质量和程序质量。计算为 0.0 到 1.0 之间的值。当PQI值大于0.4时，组件的质量趋向于较高，当较低时，检查数据发现特定方面较低以进行改进。

用途：判断模块开发的质量，规划质量活动，过程改进。

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

联系：确保产品或服务的质量。都是管理，有定义、状态跟踪和纠偏这三个要素。

差异：PSP 中采用了面向用户的质量观，定义质量为满足用户需求的程度。而客户的首要需求是不出错，所以质量管理：防止缺陷的发生。

而缺陷管理：识别并纠正已发生的任何缺陷。所以可以替换质量管理（因为质量管理的可靠稳定、快、质量稳定不好定义三要素）。

在软件开发中，将质量和生产效率进行妥协可能导致一系列问题，这是因为质量和生产效率通常是相互关联的，而不是完全独立的。以下是一些原因说明为何在软件开发中不应该轻易妥协质量以换取生产效率：

1. 维护性和可维护性： 低质量的代码通常更难以维护。虽然可能通过快速开发来提高生产效率，但如果代码质量低下，将来的维护成本可能会急剧增加。高质量的代码更容易理解、调试和修改。
2. Bug 密度和软件稳定性： 生产效率的提高通常是通过更快速的迭代和交付实现的。然而，如果牺牲了质量，可能导致更高的 bug 密度。这可能会影响软件的稳定性，增加用户面临的问题。
3. 用户满意度： 质量问题直接关系到最终用户的体验。低质量的软件可能导致用户的不满，降低产品或服务的可接受性。用户满意度对于软件的长期成功至关重要。
4. 技术债务： 对质量的妥协可能导致积累的技术债务。技术债务是一种类似于财务债务的概念，表示为了提高开发速度而采取的一些捷径。这些债务可能需要未来花费更多的时间和资源来偿还。
5. 代码可读性和团队协作： 高质量的代码通常更具可读性，这对于团队协作至关重要。如果代码难以理解，团队成员之间的沟通效率将降低，可能导致更多的错误和问题。
6. 品牌声誉： 质量问题可能对品牌声誉产生负面影响。软件产品的品质直接影响用户对品牌的信任度。在竞争激烈的市场中，品牌声誉是一项重要的资产。

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

PSP 中采用了面向用户的质量观，定义质量为满足用户需求的程度。在这个定义中，就需要进一步明确：

1. 用户究竟是谁？
2. 用户需求的优先级是什么？
3. 这种用户的优先级对软件产品的开发过程产生什么样的影响？
4. 怎样来度量这种质量观下的质量水平？

典型用户质量期望：

1. 这款软件产品必须能够工作：因此可以使用缺陷管理代替质量管理
2. 这款软件产品最好有较快的执行速度
3. 这款软件产品最好在安全性、保密性、可用性、可靠性、兼容性、可维护性、可移植性等方面表现优异。

对质量管理策略的影响：需要开发者在开发过程中考虑用户的优先级，衡量质量的高低。使用缺陷管理。

质量策略：

1. 使用缺陷管理来代替质量管理
2. 高质量的产品也就意味着组成软件产品的各个组件基本无缺陷
3. 各个组件的高质量是通过高质量评审来实现的；

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

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

考点是质量路径！！！

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

PSP质量策略是什么，如何在实际项目中应用？

质量策略：

1. 使用缺陷管理来代替质量管理
2. 高质量的产品也就意味着组成软件产品的各个组件基本无缺陷
3. 各个组件的高质量是通过高质量评审来实现的；

应用：

1. 进行评审与测试：使用评审检查表，个人评审，小组评审等。

2. PSP质量控制的衍生指标：Yield、A/FR、PQI、Review Rate、DRL来消除缺陷、度量产品质量等。

PSP基本度量项有哪些？

1. 度量时间：序号、所属阶段、开始时间、结束时间、中断时间、净时间、中断原因
2. 度量缺陷：序号、发现日期、注入阶段、消除阶段、消除时间、关联缺陷、缺陷产生原因
3. 度量规模：使用 PROBE 方法
   1. 选择的规模度量方式必须反映开发成本
   2. 度量规模必须被精确定义
   3. 度量规模必须有自动化方法统计
   4. 有助于早期规划
4. 日程（TSP）

【2013】【2015A】如果对质量的追求是无止境的，在不考虑资源和成本的前提下，有哪些可能有效的策略？

1. 重视测试，并且将测试过程文档化并且稳定化;（设计+评审+测试）
2. 重视小组评审，同样定义评审过程，并且使得评审过程的 performance 稳定化
3. 重视个人评审，提升评审者技能;
4. 重视设计
5. 开展设计验证
6. 质量策略：
   1. 使用缺陷管理来代替质量管理
   2. 高质量的产品也就意味着组成软件产品的各个组件基本无缺陷
   3. 各个组件的高质量是通过高质量评审来实现的；
   4. 首先确保基本没有缺陷，然后再考察其他的质量目标。

【2014】评审质量指标

• Yield
  • 
• A/FR
  • PSP质检成本/PSP失效成本，越高越好，但值太大的话评审过多，所以期望是2
• PQI
  • 5个数据乘积：设计质量 * 设计评审质量 * 代码评审质量 * 代码质量 * 程序质量
• 评审速度
  • 代码评审速度小于200 LOC/小时，文档评审速度小于4 Page/小时
• DRL
  • 以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是DRL

【2014】请解释设计的层次的概念和意义，并解释如何将 PSP4 个设计模版应用在不同的设计层次之中？

功能规格模板和操作规格模板用于规格说明，状态规格模板和逻辑规格模板用于高层设计/详细设计。

PSP设计模板的用途与UML的关系

名称	用途	与UML比较
操作规格模板（Operational Specification Template）	描述系统与外界的交互； 用于场景描述； 定义测试场景和测试用例； 用来与用户讨论需求	用例图、时序图
功能规格模板（Functional Specification Template）	描述系统对外接口； 包括类和继承关系、外部可见的属性和方法； 用形式化符号消除二义性	无对应图UML有类图方法的型构，但行为没有描述
状态规格模板（State Specification Template）	定义程序状态、状态之间转换以及状态转换动作	UML状态图
逻辑规格模板（Logical Specification Template）	描述系统内部静态逻辑； 用为代码配合形式化符号描述设计结果； 包括关键方法静态逻辑、方法调用、外部引用、关键数据的类型和定义	无对应图

UML时序图和类图所描述的类之间的关系以及对象之间的交互信息在PSP模板中没有

6.团队工程开发

简答

【2020】解释客户需求与产品需求，并解释V&V的区别与联系。

• 客户需求是客户的期望，期望解决某个实际问题
• 产品需求是开发团队提供的解决方案
• 验证（Verification）检验产品或产品组件能不能满足预先定义的需求规格
• 确认validation 确保产品可以满足客户需求以及实际操作场景下的要求
  联系：
• 验证的依据来源于确认的目标，即产品组件需求必须和客户需求一致。
• 验证活动为确认活动提供前提条件，在完成产品需求和产品组件需求之前，考虑客户需求是否满足是没有意义的。

【2014】请解释需求开发中客户需求和产品需求的差别，并设计一个流程来完成需求开发工作？6’

客户需求描述的是客户的期望。往往表现为，客户在实际工作中碰到了一些具体问题，希望通过某个东西来帮忙解决这些问题。客户的这种解决问题的愿望，往往就表述为客户需求。比如，客户希望有一种快速进行数据计算的工具帮助他/她完成繁琐的计算工作。这就是一个客户需求。

客户需求可能很简单，也可能很复杂；可能很清晰，也可能很模糊。这就需要开发团队与客户一起进行交流、协商，从而弄清客户的真正意图。

产品需求描述的是开发团队所提供的解决方案。即针对上述的客户需求，开发团队设计出一个可以帮助客户解决工作当中碰到的问题的方案。

一个流程：

需求获取、需求汇总、需求验证、需求文档制作

【2013】【2015A】产品组件集成策略有哪些？请解释这些策略的优缺点。在此基础上，解释如果要实现高质量集成，可能需要注意哪些方面。

大爆炸集成策略

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

逐一添加集成策略

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

集簇集成策略

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

扁平化集成策略

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

7.项目支持活动

选择

**在TSP的团队组建过程中，确定软件开发策略的是第几次会议？C **

A.第一次

B.第二次

C.第三次

D.第四次

简答

为什么精确的度量方式往往不便于早期规划，而有助于早期规划的度量往往难以产生精确度量结果？

• 由于项目的不确定性，很多细节都不能够确定。
• 度量更好地反映项目的当前状态，使规划更容易。然而，由于不同开发阶段的度量方式不同，因此很难产生准确的指标。

【2013】请解释配置管理中配置项和产品基线的概念，并设计一个流程对单元测试后已经纳入配置库的代码，修改集成测试中的若干问题后，该如何控制变更

1. 配置项：
   1. 在配置管理当中作为单独实体进行管理和控制的工作产品集合
   2. 典型的可能作为配置项纳入配置管理的工作产品包含过程说明文档、项目开发计划文档、需求规格说明书、设计规格说明书、设计图表、产品规格说明书、程序代码、开发环境，如特定版本的编译器等、产品数据文件、产品技术文件、用户支持文档
2. 基线：基线是一个或多个配置项及相关的标识符的代表，是一组经正式审查同意的规格或工作产品集合，是未来开发工作或交付的基础，而且只能经由严格的变更控制程序才能改变。
   1. 发布一个基线包括该基线所有的配置项以及这些配置项的最新变更，因此，可以将基线作为接下来工作的基础。
   2. 典型的发布基线时间点为需求分析之后、设计完成之后、单元测试之后以及最终产品发布。
   3. 是配置项持续演进的稳定基础
3. 如何控制变更（疑似是超纲内容）
   1. 跟踪变更请求：
      1. 启动变更请求处理程序，将变更情况保存在变更请求数据库中
      2. 分析变更建议和所需进行的修改将对工作产品、进度、日程等造成的影响
      3. 如果变更请求影响到其他基线，则与相关的干系人一起审查这些变更请求，并取得他们的同意
      4. 跟踪变更申请直到结项
   2. 控制配置项变更：
      1. 确认这些修订已得授权
      2. 更新配置项
      3. 将旧基线归档保存，并获取新基线
      4. 执行审查，确保该变更没有对基线造成意料外的影响
      5. 上当记录配置项的变更内容和变更理由

配置管理活动：

1. 识别配置项
2. 建立配置管理系统
3. 创建和发布基线
4. 跟踪变更请求
5. 控制配置项变更
6. 建立配置管理记录
7. 配置审计

【2013】请结合 GQM 思想解释 PSP 过程的基本度量元有哪几个？

GQM 一个完整的GQM过程分为七个阶段:先期调研、制定GQM目标、产生GQM计划、产生测量计划、收集整理数据、数据分析、打包.其中最能体现GQM思想的是制定GQM目标和产生GQM计划两个阶段

• 概念层（目标goal）：目标是为某个特定的对象而定义的。这里的对象是指软件产品、软件过程以及相关的资源等。

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

• 量化层（度量measure）：试图以量化的方式回答上述操作层识别出来的问题。

PSP基本度量项

• 度量时间：所属阶段、开始时间、结束时间、中断时间、净时间

• 度量缺陷：发现日期、注入阶段、消除阶段、消除时间、关联缺陷

• 度量规模：

  • 选择的规模度量方式必须反映开发成本
  • 必须精确定义
  • 必须能有自动化方法统计
  • 有助于早期规划

• 日程（TSP）

【2015B】请描述一下度量和分析活动在一个软件项目当中的作用，以及应该如何正确开展？

作为项目管理支持类的活动，度量和分析活动可以支持如下的项目管理活动：

1. 客观的估计与计划
2. 根据建立的计划和目标，跟踪实际进展
3. 识别与解决过程改进相关议题
4. 提供将度量结果纳入未来其他过程的基础

意义：定义了客观数据的获取和使用方式， 帮助软件项目管理决策

正确开展：

1. 可以描述度量和分析活动
   1. 建立度量目标
   2. 指定度量方式
   3. 指定数据收集和保存的流程
   4. 指定分析流程
   5. 收集度量数据
   6. 分析度量数据
   7. 保存数据和结果
   8. 交流度量结果
2. 也可以描述 GQM（见上一题）

8.定量管理与仿真建模

选择

下列描述中可能是子过程性能的是：AB

它描述有意义的性能输出，如过程 Yield 和 Phase Yield

A.需求评审消除缺陷的百分比；

B.单元测试消除的缺陷密度；

C.验收测试后暴露的缺陷数；

D.代码评审速度；

以下各种定量管理技术当中，属于非统计技术的是：A

A.帕累托分析；

B.控制图；

C.假设检验；

D.方差分析法；

以下定量管理技术中，属于统计技术有：AC

A.预测区间分析；

B.饼图；

C.敏感性分析；

D.因果分析；

下列描述中属于定量管理场景的是：AD

A.我们通过控制关键子过程的性能来确保项目整体目标的达成；

B.我们分析了导致生产效率不稳定的因素，并采取措施避免再次发生；

C.我们通过每天站立式会议和周例会控制项目进度偏差不超过 20%；

D.我们通过挣值管理方法来确保进度和成本与预期相符；(关心偏差)

如上图，完全基于 Phase Yield 来构建一个缺陷预测模型，下列数据中必不可少的是：B

A.每个注入缺陷阶段缺陷注入速度（个/小时）；

B.每个缺陷消除阶段消除的缺陷个数；

C.每个阶段中从上游阶段遗留下来的缺陷比例；

D.每个缺陷消除阶段消除缺陷的比例；

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

通过软件过程建模和仿真，有助于完成下列哪些工作：ABD

A.编制项目计划；

B.编制项目质量管理计划；

C.项目经理培训；

D.组织技术革新；

下列步骤当中，不属于建模典型步骤的是：C

A.定义和选择结果变量；

B.对过程进行抽象；

C.规划过程改进计划；

D.选择输入参数；

上图是控制图的示例图，中心线（CL）两侧按照±σ，±2σ和±3σ分成 ABC 三个区域，以下描述中，属于要进一步探索的异常过程症状的是：C

连续 4 个点呈现上升或者下降趋势；

连续 8 个点在中心线两侧，但是没有一个点在 C 区域；

连续 3 个点中有 2 个落在中心线同侧的 B 区以外；

连续 6 个点在中心线同一侧；

简答

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

1. 五个等级的特征
   1. Initial 原始级别：过程不可预测，控制不善且反应迟钝。（开发相对混乱，依赖个人英雄主义，没有过程概念，救火文化盛行）
   2. Managed 已管理级别：项目过程通常具有反应性特征。(项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等)
   3. Defined 已定义级别：组织内的过程通常具有主动性特征。（公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法可以在公司共享。）
   4. Quantitatively Managed 定量管理级别：过程经过度量和控制（构建预测模型，已统计过程控制的手段来管理过程）
   5. Optimizing 优化级：专注于过程改进（继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题。）
2. 原因解释：CMMI 是过程改进参考模型，敏捷是软件开发方法，两者是完全不同性质的事物

CMMI模型并不是开发模型，是⼀个过程改进的模型，刻画了软件组织从不成熟到成熟的路线图，简单说，CMMI模型不是⼀种具体的开发方法。而大部分所谓的敏捷方法都是开发方法，

因此，两者是完全不同性质的事物，将这两者对立是不合适的。

【2022Fall】CMMI为什么四级和五级被称为高等级？与普通等级的本质差别是什么？

三级之前已经是标准过程了。

四级：通过一些数据模型做更好的管控，比如对未来结果的预测；

五级：专注于过程改进，继续应用统计方法识别过程偏差，让生产效率、质量水平越来越高。

本质差别：基于数据构建定量模型，关心偏差，对项目的状态更加有信心，更加明确项目是否能成功、哪些地方要调整。

【2016】CMMI每个等级的提升其过程改进的重点和出发点在哪里

1. Initial 原始级别：
   • 重点： 强调个人英雄主义，项目相对混乱，缺乏组织过程。
   • 出发点： 着重解决项目上的问题，没有过程概念。
2. Managed 已管理级别：
   • 重点： 强调项目管理，有一定的反应性。
   • 出发点： 引入项目管理实践，关注需求管理、配置管理等，确保项目按计划执行。
3. Defined 已定义级别：
   • 重点： 强调在组织层面定义过程，具有主动性。
   • 出发点： 制定标准流程和规范，使得每个项目小组可以基于这些定义构建自己的过程（自主团队），实现过程的标准化。
4. Quantitatively Managed 定量管理级别：
   • 重点： 强调度量和控制过程。
   • 出发点： 引入度量手段，构建预测模型，通过定量的方法来管理和控制过程，以实现更高的可靠性。
5. Optimizing 优化级：
   • 重点： 强调持续过程改进。
   • 出发点： 应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题，实现持续优化。

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

Phase Yield = 100 * (某阶段发现的缺陷个数) / (某阶段注入的缺陷个数 + 进该阶段前遗留的缺陷个数)
Process Yield = 100 * (第一次编译前发现的缺陷个数) / (第一次编译前注入的缺陷个数)

图中阶段分别是需求开发、需求评审、设计、设计评审、编码、测试、测试评审

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

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

   2. 注入阶段缺陷注入水平（密度或者速度）
   3. 消除阶段缺陷消除水平（速度或者能力）
   4. 历史数据中的软件规模、文档规模、开发人员规模

3. 步骤

   1. 先假设所有都是关键子过程。经过敏感度分析-多元回归分析后，最后一般剩下三个关键子过程，其他有影响但是影响不大。这样就构建出了过程模型，其实指的就是关键子过程的数学关系
      1. 如z = ay1 + by2 + cy3 + d，其中 y1 = ex1 + fx2 + g。X为关键子过程性能的关键影响因素，一般是根据经验找出来的。
      2. 关键子过程有性能描述，比如y是注入的缺陷，它的值是变量不是常量，每一次有波动。
      3. 模型为了预测缺陷，需要知道关键子过程的波动范围，一般是均值±一个标准差。
   2. 在项目进行过程中不断收集数据，与预测数据进行比较，调整回归参数
   3. 项目过程中依据实际数据与预测数据的误差进行风险的预防、识别和控制

4. 改进方案

   1. 结果受限于历史数据在简单性、可理解性、稳定性、可度量性、相关性等方法的质量。因此，维护历史数据。
   2. 影响因子的选择上面不仅仅需要有关软件规模的数据，还需要有关开发过程、开发文档、开发人员等方面的数据，并且需要将数据可度量化。
   3. 反馈模型。即在开发过程中随着实际数据的产生，将这些数据作为输入变量放入模型中以调整回归参数。
   4. 假设注入水平和消除水平都符合正态分布，计算均值和标准差，因此，可以用蒙特卡罗方法模拟结果。

基本范式

1. 构建定量模型
   1. 子过程能力基线
   2. 过程模型：关键子过程的数学关系（输入和输出之间的数学关系）
2. 应用模型：监控影响子过程的关键因素

补充

2022Fall-选择题

题面	选项	解析
以下关于规模估算和度量的描述中，正确的是：	A. 功能点是一种可提供精确规模度量结果的方式 B. 规模数据扮演了沟通历史数据的桥梁的角色 C. 规模估算通常不用于质量计划当中 D. PROBE 只用于规模估算	AB
关于 PSP 缺陷日志，哪些信息是至关重要的	A.缺陷发现时间 B.缺陷重现方式 C.缺陷根因描述 D.缺陷关联的其他缺陷	ACD

更早的选择题

出处	题面	选项
2015B	下述内容在状态机验证中不用以验证状态机本身是否正确的是	A. 没有隐藏的陷阱和死循环 B. 状态转换是否完整 C. 状态描述是否完整 D. 状态转换是否正交	C
2015B	为了制定 Schedule plan，下述描述中，哪一项是不需要的	A. Task size B. Task Order C. Schedule Hour D. Task hour for each task	A
2015B	在上题中，还需要补充下述哪一项数据就可以定义 Schedule Plan 了	A. Task List B. Plan Value C. Earned Value D. Nothing	A

主观题

更早的参考题目

【2016】TSP 项目经理、过程经理、计划经理的工作内容、项目总结角度 9’

【2014】马斯洛的“人的需求层次理论”描述的需求层次有哪几个？这样分层对软件开发有什么启发？6’

【2014】为了确保最终软件产品的质量，在项目计划阶段应该注意哪些问题？4 分

【2015B】请解释在质量保障活动中的 V&V 分别是什么含义？两者之间的关系是什么？5 分

【2014】请举例说明验证和确认的区别和联系？ 4 分

【2014】请罗列集成测试的典型策略，并且解释各个集成测试策略的优缺点？8’

【2015B】请给出需求开发的完整过程，并且解释客户需求和产品需求的各自含义以及在需求开发过程中该如何体现客户需求和产品需求？8’

1. 基于风险分析平衡敏捷与规范
   1. 敏捷风险 > 计划驱动风险，启用基于风险的计划驱动方法
   2. 计划驱动风险 > 敏捷风险，启用基于风险的敏捷方法
   3. 不能判断，则通过架构把敏捷部分封装起来，在敏捷部分使用基于风险的敏捷方法，在其他地方启用基于风险的计划驱动方法。

【2015B】请解释 A/FR，PQI 的计算方式，并且解释这两个指标有什么用途？10’

不在 2023Fall 课程范围内的简答题

【2015A】请列出 Capture-recapture 方法进行缺陷预测的假设条件和相应的模型定义

1. 常见 CRC 模型定义了两个参数，即评审者发现缺陷能力 t 和缺陷的难度 h，t 是否一致以及 h 是否一致都会影响模型。一边来说，定义如下 4 个基本模型：
2. 假设 h 和 t 都一样的 M0 模型
3. 假设 h 不等而 t 都一样的 Mh 模型
4. 假设 t 不等而 h 都一样的 Mt 模型
5. 假设 t 和 h 都不等的 Mth 模型

【2018Fall】什么是软件过程的多维视角？这对软件过程的融合和定制有什么启发？

简述以下软件质量管理科学家/工程师的贡献

【2013】【2015B】【2016】Deming

1. 质量改进：提出质量改进的思想，被称为日本质量管理之父。
2. PDCA 循环：提出 PDCA 循环，被称为“戴明环”(Plan、 Do、Check、 Action)，为最基本的质量和管理工具
3. 14 条原则：
   1. 树立改进产品和服务的坚定目标，采用新的思维方法
   2. 停止依赖检验的办法获得质量
   3. 不再凭价格标签进货
   4. 坚持不懈地提高产品质量和生产率
   5. 岗位培训制度化
   6. 管理者的作用应突出强调
   7. 排除畏难情绪
   8. 打破部门和人员之间的障碍
   9. 不再给操作人员提空洞的口号
   10. 取消对操作人员规定的工作定额和指标
   11. 不再采用按年度对人员工件进行评估
   12. 创建积极的自我提高计划制度
   13. 让每个员工都投入到提高产品质量的活动中去

【2013】【2015B】【2016】Juran

1. 主编质量控制手册：《质量控制手册》为当今世界质量控制科学的“圣经”，奠定了“全面质量管理”TQM”的理论基础（Total Quality Management）
2. 提出适用性质量：
   1. 适用性质量：质量是一种适用性，即产品在使用期间能满足使用者的要求。
   2. 质量不仅仅要满足明确的需求，还要满足潜在的需求。该思想使得质量管理范围从生产过程中的控制进一步扩大到产品开发和工艺设计阶段，即挖掘用户潜在需求。
3. 提出质量三步曲：就是质量计划->质量控制->质量改进
4. 提出 Juran 质量螺旋;
5. 提出 80/20 原则，认为有 80%的质量问题是由于领导责任引起的。从而将人力与质量管理结合起来。

【2013】【2015B】【2016】Crosby

1. 提出零缺陷的概念
   1. 零缺陷：第一次就把事情做对
   2. 想要做到这一点，就需要把工作放在预防上而不是质量检验上;
2. 提出质量管理的绝对性：
   1. 质量就是符合要求，而不是“完美”
   2. 质量来自于预防，而不是检验
   3. 质量的标准是“零缺陷”，而不是可接受质量水平
   4. 质量的衡量标准是“不符合要求的代价”
3. 提出质量改进的基本要素（6C-变革 管理的六个阶段） ：
   1. 领悟（Comprehension）：理解质量真谛
   2. 承诺（commitment）：制定质量策略的决心
   3. 能力（capability）：教育与培训
   4. 沟通（communication）：成功的经验文档化、制度化
   5. 改正（correction）：预防与提高绩效
   6. 坚持（continuance）：强调质量管理成为一种工作方式
4. 发展质量成熟度的度量。

【2015B】【2016】Humphrey 软件过程之父

1. 采用 Crosby 的成熟度度量，提出了软件能力成熟度模型（CMM) ，对于软件过程管理与改进具有建设性作用。
2. 将上述的理论和实践引入软件过程。

概念解释

【2016】CI

【2016】CD/CD

【2016】Pipeline Orchestration

【2016】Container

【2016】Micro Service

【2016】A/B Testing

【2016】GitFlow

描述用途

【2016】Docker

【2016】Jenkins

【2016】JIRA

【2016】SonarQube

【2016】Git