过程改进方法与实践案例ch17-电子设备产品生产企业的改进实施.pptVIP

主题 17.1 需 求 工 程 17.2 配 置 管 理 17.2.1 识别配置项 17.2.2 建立配置库 17.2.3 变更管理 17.2.4 配置状态报告 17.3 评 审 工 作 17.4 测 试 工 作 17.5 改进的实施 17.5.1 准备实施 17.5.2 试点工作 17.5.3 推行中的问题分析与解决 17.5.4 改进建议的收集 17.6 实施效果分析 需 求 工 程 需求是产品开发的源头。需求若出现问题，将导致后续工作大量返工，所以需求工作的优劣对产品影响最大。它就像一条河流，如果源头被污染了，那么整条河流也就被污染了。 需求层次图 配 置 管 理 配置项识别 配置库建立 变更管理 状态报告 识别配置项 首先，由CMO(Configuration Management Officer)根据公司的《配置项清单》进行配置项识别，该《配置项清单》是根据过程标准中各过程域中的输出而制定的一份各项目通用的文件清单，项目的CMO在识别配置项时，在此基础上根据项目情况进行增减和调整。 建立配置库 开发库为项目组成员的共享工作平台，每个人一个目录，项目成员平时就在自己的目录下工作，拥有完全的读写权限，可以随意修改和删除目录或文件。 集成库为项目的开发空间，存放项目日常进展中一切工作成果和资料。只有项目经理拥有完全的读写权限，其他项目成员只拥有读权限。 基线库是项目团队的阶段性交付件存放库，在项目里程碑计划，到达某一个里程碑时，将之前所有的项目成果进行综合性的检查，根据基线计划进行基线审计。 基线审计包括物理审计和功能审计。 物理审计主要对工作产品的完整性和一致性进行检查，即对照基线计划检查项目工作交付件是否齐全、各文件之间的版本是否匹配； 功能审计主要检查工作产品是否都经过评审、评审中所发现的缺陷是否都已关闭、根据需求跟踪矩阵检查工作产品各功能是否都已实现。 项目成员没有基线库的修改权限，任何对已基线的工作产品的变更，必须由项目成员向CCB提出变更申请，由CCB进行影响评估，变更申请被批准后，由CMO开放修改权限才能进行变更。 产品库是项目最终产品的存放库，是项目团队递交给公司和客户的最终交付件存放目录。 每次产品发布产品库中新增一个目录，存放所发布的产品包、发布记录、各产品之间的关联关系、产品演变的描述文档。 变更管理 版本标识规则是文件版本和基线版本的标识方案。 配置状态报告 配置状态报告主要对项目的基线和变更情况进行报告，尤其是各变更对项目的影响进行分析。 配置状态报告主要包括： 配置项列表 读写权限记录 基线变更清单 变更申请清单 变更处理状态 文件规模变化折线图 变更次数散点图 各变更对项目影响的帕累托图 各基线变更次数饼图 变更日期的折线图等。 配置状态报告通过对配置项的属性进行统计和分析，为项目管理提供信息支持。 评 审 工 作 缺陷越早发现和移除，发现和修复缺陷的成本越小。在项目的进展中尽早发现缺陷，可以有效降低项目的工作量，缩短研发周期。如果一个需求阶段引入的缺陷在产品发布后才发现其缺陷，修复成本可能是在需求阶段修复成本的1000倍 。 评审比测试的优势 发现缺陷的效率更高， 评审所需要投入的工作量远远小于测试所需投入的工作量，而根据实践证明，在相同时间内，评审能比测试发现更多的缺陷。 评审相比测试更易操作 测试往往需要搭建测试平台、准备测试数据和脚本，有的测试还需要编写特定的桩和驱动代码来辅助测试，有的还需要特定的测试环境和工具，而评审却不需要。 更能发现深层次的缺陷 例如一些隐藏很深的逻辑错误，测试可能很难发现，发现之后也很难定位，但是，评审可以轻松发现。 评审所能发现的缺陷类型比测试更广 例如一些易用性、可维护性等类型的缺陷，测试是很难发现的。 评审的层次 技术评审。在项目各关键点上，由公司的专家和管理层出面对项目团队的工作成果进行的检查工作，是一个跨专业的综合性评审工作，其花费的人力和时间最多，检查最为严格。不能通过评审的话，项目不能继续进行下去，需要停下来纠正。一般技术评审会邀请公司资深的专家参加，技术评审一般持续7个工作日左右。 正规检视。工作产品开发完成后，在该工作产品的专业小组范围内进行的评审工作，其主要目的是查找缺陷、收集改善建议，是在小组范围内对个人工作成果进行的一次正规的检查。一般持续两个小时左右。 走读。一种非正式的评审，主要目的是收集改善建议。其形式比较随意，机动性高。 评审的方式 缺陷程度和类别 评审结论 评审结论包括： 通过：没有遗留缺陷，或者遗留缺陷可以在短时间内顺利解决，暂时不解决并不会影响下一步活动的启动 有条件通过：存在遗留缺陷。遗留缺陷能否解决，存在一定的不确定性，但对下一步活动的启动影响不大，需要对其进行跟踪。