Answers.md

Answers.md

1. 请解释过程度量项定义时应当注意到的方面（或根据 GQM 方法），并且据此评价 PSP 基本度量元的合理之处。

   • GQM 方法：Goal、Question、Metric（目标、问题、度量标准）。从管理的目标出发，将目标归纳、分解为度量的指标，并把这些指标提炼成可以测量的值，是一种科学的、系统的思考问题的方式。
   • PSP 基本度量项：时间、缺陷、规模、日程
   • 时间日志、缺陷日志
   • 过程度量标准
     • 选择的规模度量方式必须反映开发成本
     • 选择的度量方式必须精确
     • 选择的度量方式必须能用自动化方法来统计
     • 选择的度量方式必须有助于早期规划
   • 度量方式：LOC（Line Of Codes）
     • 物理行
     • 逻辑行

2. 请解释需求开发中客户需求和产品需求的差别，并设计一个流程来完成需求开发的工作。

   • 客户需求：描述客户的期望
   • 产品需求：描述开发团队所提供的解决方案
   • 流程：
     1. 需求获取：诱导用户提出需求，积极识别额外需求
     2. 需求汇总：整理需求，解决冲突和缺失的需求
     3. 需求验证：对用户需求进行分析和确认，保证符合预期
     4. 需求文档制作：满足用户和开发者对初始规定有个共同的了解

3. 请解释设计的层次的概念和意义，并解释如何将 PSP 4 个设计模板应用在不同的设计层次之中。

   • 设计的层次：

     • 系统需求定义
     • 系统规格说明
     • 系统高层设计
     • 子系统规格说明
     • 子系统高层设计
     • 模块规格说明
     • 模块高层设计
     • 模块详细设计

   • PSP 四个模板：

     • 操作规格模板（Operational Specification Template，简称 OST）：外界的交互，用于测试场景
     • 功能规格模板（Functional Specification Template，简称 FST）：对外的接口，包含了继承，消除二义性
     • 状态规格模板（State Specification Template，简称 SST）：精确定义状态转换
     • 逻辑规格模板（Logical Specification Template，简称 LST）：描述系统内部逻辑

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

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

   • Yield 指标用以度量每个阶段在消除缺陷方面的效率
   • A/FR = PSP 质检成本 / PSP 失效成本。期望值 2.0。过高的 A/FR 意味着过多的评审
   • PQI：通过适当的处理将五个指标定义为 0.0-1.0 之间的某个数值，PQI 值是这五个数的乘积，范围也是 0.0-1.0。PQI 值大于 0.4 时组件的质量往往比较高。PQI 较低时，检查数据，发现某一方面较低，进行改进。
     • 设计质量：设计的时间应该大于编码的时间
     • 设计评审质量：设计评审的时间应该大于设计时间的 50%
     • 代码评审质量：代码评审时间应该大于编码时间的 50%
     • 代码质量：代码的编译缺陷密度应当小于 10 个/千行
     • 程序质量：代码单元测试缺陷密度应当小于 5 个/千行
   • Review Rate：高质量的评审又需要软件工程师投入足够的时间进行评审
   • DRL（缺陷消除效率比）：不同缺陷消除手段消除缺陷的效率（相对于单元测试）

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

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

   • 如果只有强有力的规范而缺乏敏捷，将导致官僚作风，进而停滞不前；缺乏规范的敏捷则如同一个新创公司在盈利之前的不负责任的狂热。敏捷过程与规范过程各有自己的特点和优点，在本质上和在实际项目中，敏捷与规范是可以平衡的。
   • 敏捷与规范，软件开发中看似对立的两个属性，实际上相得益彰。计划驱动的开发人员必须敏捷，敏捷开发人员必须规范。成功的关键在于找到两者的平衡点。这个平衡点随项目所处的环境以及所涉及的风险而变化。仅凭一腔热情径直地采用极端方法的开发人员，必须学会如何根据实际情况恰当地平衡敏捷与规范。
   • 改善方法：
     1. 评估项目的环境风险、敏捷风险和计划驱动风险。如果评估中具有不确定因素，就通过原型、数据收集和分析来获取所需的信息。
     2. 评估风险 a. 如果敏捷风险高于计划驱动风险，就启用基于风险的计划驱动方法。 b. 如果计划驱动风险高于敏捷风险，就启用基于风险的敏捷方法。
     3. 如果应用的一部分满足 2a，其他部分满足 2b，就通过架构把敏捷部分封装起来，在敏捷部分启用基于风险的敏捷方法，在其他地方启用基于风险的计划驱动方法。
     4. 通过集成单独的风险降低计划建立项目的总体策略。
     5. 对进度和风险和机遇进行监控，在合适时重新调整平衡和过程。

7. 请举例说明验证和确认的区别和联系。

   • 区别：
     • 验证（Verification）为了确保选定的工作产品与事先指定给该工作产品的需求一致。关注是否与需求规格一致。
     • 确认（Validation）则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确，主要关注客户需求。关注是否能帮助用户解决实际问题。
   • 联系
     • 都是为了提升最终产品的质量而采取的措施。

8. 应对风险的典型策略有哪些？请举例说明。

   • 风险转嫁：通过某种安排，在放弃部分利益的同时，将部分的项目风险转嫁到其他的团队或者组织，如外包。
   • 风险解决：采取一些有效措施，使得风险的来源不再存在，如针对项目的技术风险，采取技术调研或引进技术专家所说的。
   • 风险缓解：容忍风险的存在，采取一些措施监控风险，不然其对项目最终目标的实现造成负面影响。规避、降低、控制风险发生的可能性或者降低风险发生时遭受的损失程度。

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

   • 项目的质量计划中应当确定需要开展的质量保证活动。
   • 典型的质量保证活动包括个人评审、团队评审、单元测试、集成测试、系统测试以及验收测试等。
   • 在质量计划中需要解决的关键的问题是开展哪些活动，以及这些活动开展的程度，如时间、人数和目标分别是什么。
   • 确立风险计划。在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目产生的负面影响。

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

    • 使用缺陷管理代替质量管理。
    • 采用评审和测试方法来发现和消除缺陷。
    • 高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷。

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

    • 使用缺陷管理代替质量管理。
    • 采用评审和测试方法来发现和消除缺陷。
    • 高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷。

12. 合理的计划过程是怎样的？请解释为了开发一个让项目相关干系人充分信任的计划，应当注意到哪些方面？

    • 使用工作分解结构（WBS）来将项目按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
      • 它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。WBS 处于计划过程的中心，是控制项目范围以及制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。
      • 检查标准：
        • 最底层要素不能重复，即任何一个工作包应该在 WBS 中的一个地方且只应该在 WBS 中的一个地方出现。
        • 所有要素必须清晰完整定义，即相应的数据词典必须完整定义。
        • 最底层要素必须有定义清晰的责任人，可以支持成本估算和进度安排。
        • 最底层的要素是实现目标的成分必要条件，即项目的工作范围得到完整体现。
      • 提供了范围管理
    • 选择相应的开发策略：明确组件的获得方式和顺序
    • 选择合适的生命周期模型：V？增量型开发？小周期多次交付？
    • 制定任务计划和日程计划
    • 制定质量计划：包括了评审和测试
    • 制定风险计划

13. 请罗列集成测试的典型策略，并且解释不同集成测试策略的优缺点。

    • 大爆炸集成策略：该策略将所有已经完成的组件放在一起，进行一次集成。是需要的测试用例最少，每个用例测试次数最少的一种方式。然而，这需要所有带集成的产品组件都具有较高的质量水平，否则，难以定位缺陷位置的缺点会使得该策略消耗很多测试时间。而且，系统越复杂、规模越大，该问题越突出。
    • 逐一添加集成策略：采取一次添加一个组件的方式进行集成。优点在于很容易定位缺陷的位置，特别在产品组件质量不高的情况下，每次集成之前都有着坚实的质量基础。但是缺点也很突出，需要的测试用例最多，大量的回归测试会消耗很多时间。
    • 集簇集成策略：把具有相似功能或者有关联的模块优先进行集成，形成可以工作的组件，然后以组件为单位继续进行较高层次的集成。可以尽早获得一些可以工作的组件，有利于其他组件测试工作的开展。缺点是过于关注个别组件，缺乏系统的整体观，不能尽早发现系统级的缺陷。
    • 扁平化集成策略：优先集成高层的部件，然后逐步将各个组件、模块的真正实现加入系统。这种方式可以尽早发现系统层面的缺陷。缺点是，为了确保完成系统，需要大量地打桩，即提供一些直接提供返回值的伪实现。这种测试方法往往不能覆盖整个系统应该处理的多种状态。

14. 自主团队有哪些特点？为什么说这样的团队可以满足软件开发对团队的要求？

    • 特点：
      • 自行定义项目的目标
      • 自行决定团队组成形式以及成员的角色
      • 自行决定项目的开发策略
      • 自行定义项目的开发过程
      • 自行制定项目的开发计划
      • 自行度量、管理和控制项目工作
    • 原因：
      • 在软件开发中，自主团队使利益与所进行的开发相联系，从而促使的团队在项目管理中加强自我管理，进行合理的计划和开发。
      • 自主型团队更熟悉项目过程的每个阶段，可以去更准确地获取需求、定义边界，同时更能适应项目中可能存在的需求变更，便于整个项目的运作
      • 自主团队的外部环境良好，在启动和开发阶段都获得管理层支持，相应地，项目小组应当体现出已经尽最大的可能在满足管理层的需求的工作态度，制定合理的开发计划，为取得高质量的工作而努力，这样良好的项目结构有利于项目中心开发和管理。

15. 马斯洛的人的需求层次理论描述的需求层次有几个？这样的分层对软件开发有什么启发？

    • 第一层：生理需求
    • 第二层：安全感
    • 第三层：爱和归属感
    • 第四层：获得尊敬
    • 第五层：自我实现
    • 启发：
      • 用于激励团队成员，承诺文化的建立与团队激励。
      • 建立承诺文化，利用软件工程师希望得到别人尊重的心理，鼓励他们合理承诺并努力满足承诺，从而得到别人的尊重。
      • 归属感：团队形式的承诺更有几率作用。共同履行承诺。

16. 介绍解释 Deming、Crosby 和 Juran 三位质量大师的主要贡献，以及对软件过程和项目管理的借鉴意义。

    • Deming：
      • 质量改进
      • PDCA 循环：Plan, Do, Check, Action
      • 十四点原则
    • Crosby：
      • 提出了「零缺陷」的概念
      • 质量管理的绝对性
        • 质量是符合要求，而不是完美
        • 质量来自于预防而不是检验
        • 质量的标准是「零缺陷」，而不是可接受的质量水平
        • 质量的衡量标准是「不符合要求的代价」
      • 质量改进的基本要素 - 变革管理的六个阶段：
        • Comprehension 领悟
        • Commitment 承诺
        • Capability 能力
        • Communication 沟通
        • Correction 改正
        • Continuance 坚持
    • Juran：
      • 奠定全面质量管理（TQM）的理论基础
      • 质量三步曲：计划，控制，改进
      • 朱兰质量螺旋
      • 80/20 原则：只有 20% 来自基层操作人员，而恰恰有 80% 的质量问题是由于领导责任所引起的。

17. 谈谈对项目结算的认识，简要解释应用 PROBE 估算的优缺点。

    • 优点：适用于对规模和进度进行估算，采用了较为科学的分类和计算方法，正确的使用能够保证估算结果较为精确。
    • 缺点：严重依赖历史数据，需要不断地积累，估算结果与个体联系较为紧密。

18. 解释配置管理中的配置项和产品基线概念，设计一个流程对在单元测试以后纳入配置库的代码，修改集成测试中的若干错误后，如何控制变更。

    • 配置项：配置管理当中作为单独实体进行管理和控制的工作产品集合。
    • 基线：基线是配置项持续演进的稳定基础。发布一个基线包括该基线所有的配置项以及这些配置项的最新变更，因为，可以将基线作为接下来工作的基础。
    • 控制变更：
      • 发布和创建一个基线（针对单元测试以后）
      • 需要变更的时候提出变更请求
      • 审议变更请求
      • 追踪变更请求
      • 控制配置项变更