2021-软件质量管理-Hw-TSP 项目会议

TSP 项目的几次会议

1. 第一次会议：建立产品目标和业务目标

1. 主要目标：向开发小组介绍项目基本情况及提供必要的信息，完成对软件项目的估算和计划。
   1. 首先由产品代表和管理层代表介绍项目。
   2. 然后项目小组在TSP教练的指导下，尽可能就待开发软件多提问题，来形成对项目的充分理解。

2. 第二次会议：角色分配和小组目标定义

1. 主要目标：识别和分配项目小组的目标，并在此基础上确定小组当中各个成员的角色以及相应的指责。
   1. 由项目组长带领整个团队讨论确定，出发点：从第1次会议中提出的要求。
   2. 除了识别管理层明确提出的要求，还需要尽可能分析和识别隐含的要求。
2. TSP典型的角色，包括项目组长、计划经理、开发经理、质量经理、支持经理以及过程经理等。
   1. 详见10.5节的目标和衡量指标

3. 第三次会议：开发流程定义与策略选择

1. 主要目标：确定项目开发的方式，包括两方面的工作。
   1. 一是定义项目的开发流程。
   2. 二是确定项目开发的策略。

3.1. 定义项目的开发流程

1. 一般由过程经理带领小组成员讨论确定。
2. 在定义流程的时候，应当结合历史经验，特别是客观的历史数据，定义支持质量目标实现的开发流程。
3. 为了使得定义好的开发流程具备指导实践的价值，定义的流程应当足够详细，而且要文档化。

3.2. 确定项目开发的策略

1. 一般由项目小组共同决定的获得最终产品的方式。
2. 典型的开发策略包括开发周期的定义以及每个周期的开发内容。

4. 第四次会议：整体计划

1. 主要目标：自顶向下定义项目的整体计划和紧接着的下一阶段的详细计划。
   1. 定义的整体计划必须覆盖整个项目周期。
   2. 项目小组需要使用计划来帮助他们向管理层或者客户做出承诺。
2. 真正有参考价值的是下一阶段的详细计划，该计划持续的时间往往不会超过3个月。
3. 制定计划：
   1. 首先识别产品清单，估算产品规模和工作属性。
   2. 基于已经定义好的过程（第三次会议），制定任务计划。
   3. 结合项目团队的资源水平，估算项目的日程计划
4. 注意：项目团队往往会发现现有资料水平不足以满足管理层的所有期望，这时就需要项目小组合理地给出若干候选方案，供管理层决策。
5. 最终结果：根据第二次会议以来的既定策略，项目小组完成了估算，并形成了的项目的日程计划，展示方式为见课本119页图6-6。决定了做几个迭代周期，每个迭代周期做什么，并且需要将每个任务都指定给具体的成员。

5. 第五次会议：质量计划

1. 主要目标：基于项目小组确定的质量目标，制定相应的质量计划。
   1. 质量计划中需要明确每个阶段预计注入的缺陷数和预计消除的缺陷数。
   2. 根据推荐的Yield、PQI、A/FR等质量控制指标，为质量活动分配足够的时间资源：Yield可以根据历史数据或者一般的行业数据确定。
   3. 在TSP教练的指导下，确定每个阶段的Yield以及每个阶段缺陷注入的速率，即可大致计算出最后产品中的缺陷数。
2. 通过调整Yield和相应的活动，即可大致定义质量活动。

6. 第六次会议：个人计划以及计划平衡

1. 主要目标：确定个人计划并且协调个人资源。
   1. 分配必须参考每个软件工程师的生成效率以及资源水平。
   2. 计划匹配：每个人的资源需求（来自于分配的人物）和资源水平（预测）相匹配。
   3. 找到一个时间点，使得所有的软件工程师差不多同时完成工作：这个时间点往往是项目可以完成的最早时间。
2. 注意：
   1. 计划的平衡不是绝对的平衡，是团队成员相互支持的体现。
   2. 在平衡计划的同时，也要注意控制整个项目的节奏，同步项目主要阶段。
   3. 设计阶段和实现阶段适当地重合是可以接受的，但是如果有极为严重的重合，往往意味着个别软件工程师工作完成时间太晚。

7. 第七次会议：风险评估。

1. 主要目标：指定风险控制计划。
   1. 充分讨论实现计划所面临的风险。
   2. 就风险的可能行和影响范围进行评估，制定合适的风险缓解措施。

8. 第八次会议：准备向管理层汇报计划

9. 第九次会议：向管理层汇报计划内容

1. 向管理层展示将如何进行项目开发，并且争取获得管理层对项目计划的认可和支持。

10. 可以参考的课本内容

1. 课本2.3-2.4 PROBE 估算内容：
   1. 各个步骤的任务
      1. 定义需求：规划出产品的范围。
      2. 概要设计：递归逐步求精，终止条件：划分到对估算结果有较大把握的粒度或者划分到有可以参考的历史数据。
      3. 规模估算：参考历史数据中的规模数据或者估算者能所做的最好猜测，估算待开发的产品的规模。
      4. 资源估算：资源主要指人力资源，单位是人月、人天或人时。
      5. 日程计划：
         1. 根据整个开发小组的资源水平，讲这些资源需求映射到一个实际的日程计划上来。
         2. 注意软件工程师提供的有效工作时间往往远低于预期，不要太乐观的估计。
      6. 开发产品
   2. 执行步骤
      1. 概要设计
      2. 代理识别：是PROBE方法中的代理。
         1. 代理与软件开发所需资源有着很好的相关性。
         2. 代理在项目的早期便于估算者建立直观的概念。
         3. Eg. 类的类型、数量、规模，方法，例程、数据库表格。
      3. 估算并调整程序规模：由于外代码的存在，PSP中使用线性回归对估算的结果进行调整，使得估算结果尽可能的准确。
      4. 估算并调整资源：对于项目所需资源的估算也是由代理规模通过线性回归的方法进行调整计算。
      5. 计算预测区间：在调整后的估算结果之后，还需要对估算结果进行评价，通常采用的方法就是计算预测区间，最后得到估算的上限UPI和下限LPI。
   3. 注意事项
      1. 整理历史数据
         1. 简单方法：排序对应即可。
         2. 正态分布法：人们认为程序的规模是成正态分布的：计算均值和标准差即可，当时事实证明往往不是。
         3. 对数正态分布法
            1. 首先计算自然对数，然后计算自然对数的均值M和标准差。
            2. 然后按照正态分布得到每一个值，再取反对数。
      2. 处理有限的历史数据
         1. 估算规模：首先猜测，然后按线性回归计算。
         2. 估算时间：首先猜测，然后按线性回归计算。
      3. 避免极端数据导致的高相关性。
2. 质量指标（3.3.2）
   1. Yield：
      1. 度量每个阶段在消除缺陷方面的效率，是一种事后的质量控制手段，除非发现所有的缺陷，否则很难非常精准的计算。
      2. Phase Yield = 100 * (某阶段发现的缺陷个数) / (某阶段注入的缺陷个数 + 进入该阶段前遗留的缺陷个数)
      3. 有资料表明，有一个缺陷被发现，就有一个缺陷没有被发现。
   2. A/FR 质检失效比：A/FR = PSP 质检成本 / PSP 失效成本，值越大说明质量越高，然而过高可能是由于进行过量的评审，期望是2.0
   3. PQI(Process Quality Index，过程质量指标)：PQI是5个指标的乘积（5个指标会被定义为0.0-1.0之间的范围)
      1. 设计质量（设计时间应大于编码时间）
      2. 设计评审质量（设计评审时间应大于设计时间的50%）
      3. 代码评审质量（代码评审时间应大于编码时间的50%）
      4. 代码质量：代码的编译缺陷密度应当小于10个/千行。
      5. 程序质量：代码的单元测试密度应当小于5个/千行。
   4. 评审速度：200行/小时
   5. DRL
3. 努力做到缺陷预防
4. 评审检查表：Pareto分布图（3.3.1）
5. 软件设计过程框架：课本 4.2 图4-2
6. 需求开发
   1. 需求分类
      1. 客户需求：客户的期望。
      2. 产品需求：开发团队所提供的解决方案。
      3. 产品组建需求：描述的是组成产品的各个组件的需求规格。
   2. 需求开发步骤
      1. 需求获取
      2. 需求验证
      3. 确认需求
   3. 结果：需求规格文档：课本5.1.3-5.1.5
7. 团队设计
   1. 团队智慧：合理分工。
   2. 设计标准：命名规范、接口标准、系统出错信息、设计表示标准
   3. 复用性考虑
   4. 可测试性考虑
   5. 可用性考虑
   6. 设计的文档化，5.2.6 表5-2
8. 实现策略
   1. 评审的考虑：设计采取的基本策略是自顶向下、逐层精化，考虑是否需要对实现结果进行评审。
   2. 服用策略：每日站会
   3. 可测试性：与测试计划保持一致。
9. 集成策略选择
   1. 大爆炸集成策略
   2. 逐一添加集成策略
   3. 集簇集成策略
   4. 扁平化集成策略
10. 验证与确认
11. 工作分解结果：使用WBS，课本6.1
12. 生命周期模型选择：课本6.3
13. 日程计划原理和方法：使用挣值分析方法
14. 质量计划原理和方法
15. 风险计划
    1. 尽早且积极地识别风险，制定项目风险管理计划。
    2. 风险管理同时考虑有关成本、进度、绩效及其他风险的内部及外部来源。
    3. 主要分为风险识别和风险应对
       1. 风险识别：不必说明每一个可能事件，而是从风险发生的可能性以及风险演变为成为问题的影响程度来综合考虑。
          1. 识别方法
             1. 检查WBS的每个组件以找出相应的风险。
             2. 使用定义好的风险分类表来评估风险。
             3. 与类似项目比较来审查风险管理。
             4. 检查设计规格和协议书需求
          2. 风险识别活动（详见6.6.1）
             1. 识别与成本、进度及绩效相关的风险；检查成本、进度以及绩效风险对项目目标的影响程度。
             2. 审查可能影响项目的环境因素：恶劣天气、自然灾害、电信故障等
             3. 将审查项目工作分解结果中的所有组件作为风险识别的一部分。
             4. 将审查项目计划的所有组成部分作为识别活动的一部分。
             5. 记录风险的内容、条件及可能的结果：标准的格式记录。
             6. 识别每一风险相关的干系人。
             7. 利用已定义的风险系数，评估已识别出的风险。
             8. 依照定义的风险类别，将风险分类并分组。
             9. 排列风险的优先级。
          3. 风险应对（6.6.2）：应对已经识别的风险，常见的策略有
             1. 风险转嫁
             2. 风险解决
             3. 风险缓解
16. 管理
    1. 配置管理（9.1）
    2. 度量与分析（9.2）

11. 报告结构

1. 项目概述
   1. 项目背景：文本描述
   2. 项目特征：特征的相关描述（可以细化为项目目标）
   3. 项目开发策略：例如，以DevOps与精益思想为指导，采用Scrum方法作为过程框架，并在具体时间中采用Kanban方法（辅以XP方法）
      1. DevOps
      2. Scrum
      3. XP
      4. Kanban
   4. 项目人员。
   5. 参考资料。
2. 开发方法介绍：过程设计原理（Scrum）
   1. Scrum方法简介
   2. Scrum方法流程
3. 项目开发过程
   1. 流程图
   2. 需求分析与需求验证
      1. 用户故事获取
      2. 产品需求列表
      3. 确定迭代需求的内容与优先级
      4. 需求协商和验证。
   3. 编码与每日站会：使用燃尽图（可以用挣值分析）
   4. 评审与测试
      1. 个人测试与评审。
      2. 小组评审。
      3. 自动化工具
      4. 演示会议
   5. 持续集成、部署和交付：使用云原生技术。
      1. 持续集成
      2. 持续交付
      3. 持续部署
4. 项目实践举例