• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

Introduction to CMMI培训总结报告2

发布: 2007-5-14 14:17 | 作者: 罗耀秋 | 来源: blog | 查看: 124次 | 进入软件测试论坛讨论

领测软件测试网

  1、 二三级的区别

  就阶段上来讲,三级抽取了二级每个项目的公共要求è 标准的过程定义+裁减指南

  二级中项目的过程定义取决于改项目,三级则是由EPG来具体提供建议。EPG 团队中专长工程过程和组织级过程的人负责自己那块的裁剪偏差。

  三级才有OPF,因为二级后总结出了有权威的人去负责,这些并不是高层能替代的。也就是说二级没有必要有EPG。

  2、 连续式和阶段式浅辨

  成熟度等级给组织提供了一个改进方向,这点上stage比continues更有优势。特别是组织自己也不明确改进方向,如不知道先做什么,后做什么的情况下

  continues可以一个PA一个PA的去做,而staged则不可以,是一些固定设置的组合

  两者的评估结果都能达到组织的商业目标

  对某个过程域,提供的内容基本一致,只不过实现的方式不一样

  连续式有6个等级,从CL0到CL5,而阶段是只有一个è因为阶段式是看不到能力等级的,阶段式只有ML1~5

  3、 SG和GG

  SG不是能力——要做什么事,不是能力

  GG才是能力——做了什么事,如何做才是能力

  GG1è能力1,GG2è能力2

  也就是说:“我做成了这件事,这并不代表我有能力;我每次总能做成这样的事,这才代表我很有能力”。

  4、IDEAL模型的 过程改进

  I—初始;D-诊断;E-建立;A-执行;L-学习。

  基于诊断的发掘问题(D),基于总结经验教训的过程改进(L)

  2级QA和项目组都处于摸索阶段,实际上,QA和EPG都要高于 项目经理的经验,QA要有能力知道项目经理完成过程活动。

  某些公司实行EPG、QA和PM轮岗制度。

  5、 POLICY

  体系文件的架构:POLICY/过程/规程&指南/模板表单

  每个PA都要由Policy

  我们公司的Policy写在哪里呢?

  6、 过程域、过程描述和过程定义

  过程域不是过程描述,也不是过程定义:因为没有形成必须怎么怎么,也没有形成先后次序

  也就是说,过程域不管你怎么做,怎么做,是组织的过程定义的事情。

   CMM的Activity对应CMMI的SP

  另外,CMM没有common future映射的GP

  如果规模与工作量无关,就没有必要去估计规模:如 审计,维护,应该侧重估计重用率并分析时间的关系。要分析规模是否给你带来直接的工作量?即估计一个折扣值,因为这个时候影响计划工作量的已经不仅仅是规模。

  在PP中我问及Plan for Data Management的Data含义时,老师讲估算的文档也算是data。

  8、  当谈到为什么要把measurement and analysis单独列为一个PA时候,老师提到,CMM中只有度量数据,没有度量过程与度量能力。我们可以从每个PA的GP2.8中查找需要度量的对象,从这个PA中找到具体的度量方法。也就阐明了为什么有GP2.8还要有这个PA的关系。

  9、 目前公司内部度量和计划过程的一些误区

  a、管理好计划,必须管理好开始时间,因为不管理好开始时间,很难保证结束时间

  b、缺陷率是按月进行的,意义不大,也不合理,应该是按照里程碑和版本去划分进行比较

  c、应该从使用数据度量结果的人的角度入手,选择度量数据与度量方法。Eg:评审报告给质量人员看,缺陷密度是可以的,但如果给总工看,则是关注发现了那些缺陷

  d、在计划变更前不要改计划:即在调整前的计划和现在的计划都要保留,并且应该从趋势图上分析怎么赶上原计划的

  e、不要随意延期,要注意分析:承诺的事情要努力的去做,然后提前告诉人家可能的变更,然后再更改计划

  10、关于PPQA

  如何评价过程:观察流程的入口条件、观察过程中间的事情是否都做了,QA要了解过程中间哪个点是关键点,哪个点是易犯错误的点

  如何评价工作产品及服务:主要是insight的方式去观察服务,如服务态度、客户问题响应、用户手册的友好性、用户手册给客户做 培训了没有,对于产品则关注标准化和规范化的内容。

  组织的OT做得比较差,因为没人评估,没有执行这块的QA职能人员。从而,应该有组织级的和项目级的QA存在。

  NC即使解决了也要记录在案。

  11、关于CM

  一个CR带动多个CI,建议拆分成多个CR,每个CR只关联一个CI

   SCM人员是项目组内部的人员,应该有外部一个专门的人员去检查CM规范的人(如功能审计和物理审计)(即有的公司SCM是项目组兼职,而公司的CM人员则是检查各项目的SCM执行情况并提供专业技术支持。因为 配置管理与功能关系密切,可能业务领域的人更容易把其做好)

  12、CMMI和CMM在CM上的区别

  CMM的CM是项目的CM

  CMMI的CM是所有的CM,不关是项目的还是组织上的。如每个PA的GP2.6

  (e.g.:过程能力基线、过程定义基线、过程改进基线)

  13、区别三个重要的词

  Measure——度量源,度量的实体(e.g.:102行的“行”),或者说度量项目

  Measurement——一系列的相关度量结果(如方法、工具结果)

  Measure Value——具体的值(e.g.:102行的“102”)

  14、组织过程的一些概念

  EPG的三大块:   过程资产——给项目组提供标准

  过程数据库:给项目组用(过程数据库不是过程资产)

  过程改进计划:指导自己的工作

  15、IPM中的一个上下文关系图关于Stakeholder和Relevant Stakeholder的疑问

  PP讲stakeholder,而IPPD讲Relevant Stakeholder,所以更具体了。

  这里整个是讲Relevant Stakeholder,但在右边方框的小圆圈却是提出了stakeholder,我的看法是:引入这个方框的是Integrated Plans,也就是说,这个方框中站立的角度是各个子项目,对于子项目来说,原来对于IPM是内部的约束,到了这个里面就变成了各个子项目的外部约束了,所以变成stakeholder了。如“站在GSM系统上看和站在BTS的角度看问题”。

  当时老师有点在这个问题上兜圈子,答复含混。

  16、关于“ 风险时间框架”

  在讲到风险管理的时候,老师讲到了一点点新的东西,在定义风险参数的时候,加了一项“风险时间框架”。风险时间框架的含义是给你一个采取行动措施的时机,从此Risk由二维变成三维了(概念、影响、时间框架)——具体可参见《持续风险管理一书》

  17、在RM里面的这个上下文关系图中我认为少了一个M&C的关联PA

  有PP进入,肯定有M&C进行管理。因为风险管理是一个持续的过程。
  老师建议去SEI的网站上去提一个培训教材的“CR”。

  18、DAR的一些重要概念

  进入DAR的一定是项目经理或项目组内部解决不了的,如高风险的、高费用的

  所以评估时候有的企业确实找不出需要DAR的东西,但为了评估却必须要凑一个DAR的实例,这个真是有点矛盾

  这个PA的上下文关系图入口为Other PAs,也就是说它是其他PA所不能解决的问题而提出来的。

  19、ML4和前面ML2、3的关系

  成熟度等级4提供了一些基本概念,一些detail的事情在前面的PA中都已经提供

  不增加过程定义,但修订改进原有过程定义,更强调量化的控制

  提出控制计划并按照计划去实施控制,过程被度量了并且基于过程的度量数据去管理自己

  二、三级也有threshold(阀值),但是来自于Voice of Customer,是拍脑袋的结果,而不是statistical和quantitative methoud

  到了第四级变成了Voice Of Process:基于过去的表现和过去的质量,可以预测未来过程的表现、产品质量和服务质量

  这个时候项目组的定义过程中开始带有质量目标

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网