欢迎来到天天文库
浏览记录
ID:43824479
大小:1.07 MB
页数:40页
时间:2019-10-15
《过程改进方法与实践案例 978-7-302-23431-9 第三部分--实践案例 ch17-电子设备产品生产企业的改进实施》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库。
1、Chapter17.电子设备产品生产企业的改进实施主题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实施效果分析需求工程需求是产品开发的源头。需求若出现问题,将导致后续工作大量返工,所以需求工作的优劣对产品影响最大。它就像一条河流,如果源头被污染了,那么整条河流也就被污染了。需求层次图$APPEA
2、LS是对客户需求进行分析和细化的一种方法。$APPEALS是一个缩写词,与购买标准的八个方面相关:$价格(Price),A可获得性(Availability),P包装(Packaging),P性能(Performance),E易用性(Ease-of-use),A保证(Assurances),L生命周期成本(Lifecyclecosts),S社会接受度(Socialacceptance)。配置管理配置项识别配置库建立变更管理状态报告识别配置项首先,由CMO(ConfigurationManagementOfficer)根据公司的
3、《配置项清单》进行配置项识别,该《配置项清单》是根据过程标准中各过程域中的输出而制定的一份各项目通用的文件清单,项目的CMO在识别配置项时,在此基础上根据项目情况进行增减和调整。文件类型命名规则举例项目组工作成果项目ID+“_”+文档名PC_软件需求规格说明书.doc会议纪要项目ID+“_”+会议纪要+“(”+日期+“)”PC_会议记录(20060310).doc项目周报项目ID+“_”+项目周报+“(”+第x周+“)”PC_项目周报(第1周).doc个人工作产品项目ID+“_”+文档名+“(”+姓名+“)”PC_缺陷报告(张
4、三).doc注:文档名、姓名全部用中文名,括号用英文括号,日期格式为“yyyymmdd”。建立配置库开发库为项目组成员的共享工作平台,每个人一个目录,项目成员平时就在自己的目录下工作,拥有完全的读写权限,可以随意修改和删除目录或文件。集成库为项目的开发空间,存放项目日常进展中一切工作成果和资料。只有项目经理拥有完全的读写权限,其他项目成员只拥有读权限。基线库是项目团队的阶段性交付件存放库,在项目里程碑计划,到达某一个里程碑时,将之前所有的项目成果进行综合性的检查,根据基线计划进行基线审计。基线审计包括物理审计和功能审计。物理审
5、计主要对工作产品的完整性和一致性进行检查,即对照基线计划检查项目工作交付件是否齐全、各文件之间的版本是否匹配;功能审计主要检查工作产品是否都经过评审、评审中所发现的缺陷是否都已关闭、根据需求跟踪矩阵检查工作产品各功能是否都已实现。项目成员没有基线库的修改权限,任何对已基线的工作产品的变更,必须由项目成员向CCB提出变更申请,由CCB进行影响评估,变更申请被批准后,由CMO开放修改权限才能进行变更。产品库是项目最终产品的存放库,是项目团队递交给公司和客户的最终交付件存放目录。每次产品发布产品库中新增一个目录,存放所发布的产品包、
6、发布记录、各产品之间的关联关系、产品演变的描述文档。变更管理版本标识规则是文件版本和基线版本的标识方案。文件类型命名规则说明文件版本X.Y.ZX是项目组对外的版本号,表示项目组发布的版本,项目每一次发布X自动增加1。Y是项目组内的版本号,每次项目组评审后Y+1。Z是个人的版本号,每次更新Z+1。基线版本里程碑名+“_”+X每次基线变更后X+1。变更申请表申请人申请日期变更类型变更文件变更原因变更内容变更影响的文件计划文档代码数据库变更对项目的影响工作量进度成本质量结论配置状态报告配置状态报告主要对项目的基线和变更情况进行报告,
7、尤其是各变更对项目的影响进行分析。配置状态报告主要包括:配置项列表读写权限记录基线变更清单变更申请清单变更处理状态文件规模变化折线图变更次数散点图各变更对项目影响的帕累托图各基线变更次数饼图变更日期的折线图等。配置状态报告通过对配置项的属性进行统计和分析,为项目管理提供信息支持。评审工作缺陷越早发现和移除,发现和修复缺陷的成本越小。在项目的进展中尽早发现缺陷,可以有效降低项目的工作量,缩短研发周期。如果一个需求阶段引入的缺陷在产品发布后才发现其缺陷,修复成本可能是在需求阶段修复成本的1000倍。缺陷修复成本图评审比测试的优势发
8、现缺陷的效率更高,评审所需要投入的工作量远远小于测试所需投入的工作量,而根据实践证明,在相同时间内,评审能比测试发现更多的缺陷。评审相比测试更易操作测试往往需要搭建测试平台、准备测试数据和脚本,有的测试还需要编写特定的桩和驱动代码来辅助测试,有的还需要特定的测试环境和工具,而
此文档下载收益归作者所有