今天有人问我PPB和PPM，我发现我还真的不知道，上网查了一下~~~~

统计思维的基础和公理
　　所有的产品开发和服务都是由一系列相互关联的过程组成。所有的过程都是动态和可变的，理解了这些变化是基于事实管理和系统改进的基础。而统计学思维的核心就是理解过去，控制现在和预测未来。
　　在CMMI中过程被定义为一系列能够被识别和在实践中执行的活动。但是过程要能够最终产出产品和服务，不可避免要涉及到人，材料，设备，工具等一系列的要素。
　　关于产品和服务的性能所涉及到的实际的过程表现，必须在做起决定之前进行充分的理解。回答以下问题有利于我们找出实际的过程表现:

　　1.什么是正常的和固有的过程偏差?

　　2.哪些固有的误差来源于异常的偏差?

　　3.造成异常偏差的根源是什么?

　　统计学提供了我们需要的方法和工具，来度量和分析过程行为，得出结论并执行后续的改进步骤。在OPP中我们首先需要建立过程能力基线PPB，PPB的建立首先要要确定组织的目标，找出影响组织目标的关键子过程，然后收集子过程的数据进行分析。而PPB的作用仅仅是理解过去和控制现在，为了预测未来我们必须要建立PPM过程性能模型。有了PPM我们就可以根据项目的基础信息和模型来预测项目的进度，成本和质量情况。可以使用的模型的类型主要有:

　　1.基本的统计和预测模型

　　2.蒙特卡洛模拟和优化模型(what-if分析等)

　　3.过程模拟模型

　　4.系统动态模型(基于实时的反馈)

　　5.概率模型(根据概率论而不是统计来进行预测)

　　6.可靠性成长模型(通过失败数据测试来预测未来失败情况)

　　如何使用PPB和PPM去选择过程和一个指标来进行改进。假设组织的目标的改进产品的质量，希望把现场缺陷密度DD(Defect Density) <0.4个/KLOC。而这个目标在我们原来发布的产品和版本中很多都没有达到，组织希望对此进行改进。为了达到这个目标，需要遵循以下步骤进行改进:

　　1.建立影响DD的评价准则(贡献度，潜在变革，潜在成本和风险)。

　　2.识别影响DD的影响因子(通过回归分析确定RV,DC和QC三个贡献因子)。

　　3.建立回归分析模型(DD = 389 + 2.12RV + 5.32DC -24.1QC)。

　　4.通过建立的评价准则评价因子(可使用蒙特卡洛模拟或敏感性分析)

　　建立了PPM后就需要考虑如何去改进影响因子以达到我们需要的质量目标，对于RV,DC和QC组织都可能已经有相应的过程能力基线数据，比如DC的上下限为(15,30)，均值为20。根据对多个项目的历史数据分析，可以知道DC大致的概率分布曲线。然后我们根据蒙特卡洛模拟可以得出DD的概率值(比如90%的置信区间下的DD的值为0.42)。
　　有了这些数据我们可以看到，现在的实际情况是无法达到我们的改进目标的，因此我们准备对DC进行改进，将DC的上下限范围进行缩小，并减小DC的均值。究竟要改进到多少，我们就可以进行what-if分析，通过模型可以得出结论是将DC均值减小为18,上下限为(12,25)的时候可以达到目标要求。

    与软件质量密切相关的因素有很多：软件工程方法、需求管理、配置管理、测试、同行评审。

    开展同行评审的步骤有：1、计划同行评审并编写计划文档；2、依据文档化规程实施同行评审；3、记录同行评审的实施和结果数据。

    同行评审在CMMI中有着重要的意义，其目的是尽早地和有效地从软件工作产品中消除缺陷。它是通过工作产品作者的同行对软件工作产品的系统化检查，来识别产品的缺陷和其中需要进行更改的地方。什么是缺陷呢？缺陷是在生产软件工作产品中的错误，它违背了工作产品的规格说明书或工作产品必须遵守的标准。

    如果缺陷存在于某个工作产品则会产生错误的结果，含糊或者不清楚，遗漏规格说明书中要求的特性，包含了规格说明书中不需要的额外的特性。

    怎么样描述缺陷呢？通常缺陷从以下几个方面进行描述：

    1、来源：在开发过程中的哪里产生了缺陷？

    2、种类：是什么类型的缺陷？

    3、严重性：缺陷的影响程度有多大？

    缺陷的来源：客户需求分析、软件需求分析、概要设计、详细设计、编码、开发测试计划、用户文档

    缺陷分类：遗漏Missing、错误Wrong、多余Extra、模糊/不清楚的Ambiguous/Unclear、违背标准Standards Violation、未知的Unknown

    选择合适的评审方法：

    1、基于风险：工作产品包含缺陷的可能性、缺陷发生可能造成的负面影响

    2、有错误倾向（Error-Prone）的模块：有425个模块中，客户报告的缺陷中有58%集中在31个模块中、20-80原则

    3、产生原因：时间压力过大、培训不够或经验不足、需求蔓延导致大量变更

待续......

 

    CMMI推进过程是一个长期而艰辛的工作，最终目标就是提高产品质量，有效提升生产效率。但是在实现这些目标之前，首先要确保人员接受这些思想，才能为推进工作开辟道路。
    理论上讲，凡是对软件工程有深刻理解的人都希望推行CMMI，特别是产品经理们，他们更加希望通过软件成熟度集成模型来减轻其工作压力。在实际工作中，顶着巨大的产品出货压力，CMMI推行初期不论是产品经理和研发人员都是顾不上过程规范的，更谈不上静下心来和QA谈如何改进质量的问题，因为在他们看来迫在眉睫的事情就是：出货。然而，越是不愿意停下来理清质量问题，越是得继续在一团乱麻中追赶schedule。因此，我觉得要解决这些问题就应该推进CMMI过程改进的同时提高人员的质量意识。

    怎样提高人员的质量意识呢？

    一个人的意识在很大层面上将直接影响着随之而来的行为活动，并对其活动结果产生重大的改变。意识伴随着我们一路同行，并不时提醒我们对工作的严谨、对生活的憧憬、对需求的渴望……那么究竟什么是“意识”呢？意识是人的头脑对于客观物质世界的反映，是感觉、思维等各种心理过程的总和，是人们内心活动的一种过程。意识的高低体现在人们的一切活动之中，意识越高则对活动结果的影响越积极。企业要发展，产品质量要提升，离不开对人的意识教育和培训。从现代质量管理的角度来看，意识就是一种内化的心理活动标准，是人们对显性行为的一种评价方式。因此，要提高企业的产品质量，则首先要从提高员工的“质量意识”开始。
    质量的发展经历了一个漫长的过程，从“质量检验”到“统计质量控制”再到“全面质量管理”，人们对质量的认识从上世纪五六十年代“好的质量”到八十年代的“符合要求”再到21世纪的“顾客满意”都充分说明了一个问题，质量越来越被人们所重视，其重要性在市场竞争中得到了证实，并且将是未来市场竞争的关注焦点。质量已走出狭义的范围，延伸到更广阔的空间，如：服务质量、工作质量、学习质量、直至人们的生活质量等等。正如质量管理大师朱兰博士提出的“即将到来的世纪是质量的世纪”一样，质量无所不在。这一发展趋势再次说明了，市场的竞争将以“质量竞争”为前提，因而如何提升产品质量又再次成为质量管理的一大课题。此外，从“人、技术和管理”的三大质量管理要素及“人、机、料、法、环”等质量问题分析来看，“人”都处于主导地位，起着决定性的作用。因此对企业员工的质量意识提升就显得更为重要。
     企业员工质量意识的提升可从多个方面进行，如企业文化、管理的标准化、标准的执行、工作行为及教育培训等等。但它需要企业全体员工的参与，特别是高层管理人员的加入，因为高层管理人员的关注将明确企业对质量的重视程度，他们的身体力行将告诉所有员工质量的提高势在必行，同时也告诉所有员工领导的态度与决心。对于质量意识的管理，我们不能简单地停留在只喊口号或不加度量的定性概念层面上，而没有评价、没有检查。如果没有一套有效的监督、检查和评价体系，只凭一贯的思想教育、宣传来进行质量意识的提升，将难以避免其工作的盲目性以及实际操作的无序性。在多少次的质量投诉与质量问题的发生中，我们都得到了深刻的教训，也清醒地认识到提高质量意识的重要性。但我们的管理人员、管理干部有没有认真思考过这一问题，要如何进行控制与改善！笔者认为，要完成任何一件事情、任何一项工作，首先其目的必须十分明确；其次要达到什么样的效果，要如何去做；最后完成情况如何，并及时总结补充存在的不足，再进入下一循环。因此，质量意识的提升要让所有参与人员明白其目的是什么，在一段时期内要达到什么样的目标，具体要如何去操作，并且在出现问题时会受到什么样的处罚，取得成绩时受到什么样的奖励。要使质量意识的优劣与员工切身利益挂钩，使所有员工在工作中能不时的感觉到工作的压力与动力，从而尽量保证任何细微的产品缺陷都不流入下道工序，进而增强其可操作性。
     为了防止实际操作的执行不力情况，管理人员要定时与不定时地进行监督、检查。对于表现优秀的员工要及时进行表扬与奖励，对于存在不足的员工要进行工作指导，对于存在不执行或执行不力的员工进行处罚，真正做到奖罚分明。让所有员工在质量管理四项基本原则（质量的定义即符合要求，质量系统的核心在于预防，工作标准是零缺陷，质量是用不符合要求的代价来衡量）的指引下实现质量意识的真正提高。
     质量意识的管理就是让无形的质量意识与有形的工作质量结合起来，让模糊的质量意识与员工的绩效结合起来，让质量意识的管理体制起到实质性的作用，最终为企业的发展培育出有高质量意识的员工，进而为产品质量的提升打下坚实的基础。

   算算从今年4月CMMI项目开案到现在我作QA工作有4个多月时间了，一直有心写一些心得体会来记录自己的成长历程，今天终于下定决心

   我们公司是做个人消费电子产品，研发中心的项目永远在追赶市场，出货大过天。虽然是出货很紧急的消费电子，但是质量仍然很重要，因为质量塑造品牌，客户就是上帝！！

   我们公司在硬件生产方面还是很牛的，去年10月份才成立了这第一家软件研发中心，而我就是这个新生的软件研发中心的质量和测试部门的一名新人。在过去的4个月中，我加入到推进软件成熟度集成的工作中，的确是一个挑战。

   过程质量和低bug率共同决定了产品的质量，而我们QA就是保证软件过程质量的这样一个职位。虽然过程质量不能在短期内给公司来带明显的经济效益，但却能够提供一个长期的可持续发展的机制保证公司不断成熟成长，最终实现所有项目过程和行为可量化可控制，有经验可循。

   今天，我被安排整理QA的工作内容列表，一是为了结合公司实际明晰QA的工作内容；二是为了量化QA的工作，更好的统计QA绩效。这个工作我正好适合，因为我平时都有做工作笔记的习惯，于是我就将我的工作笔记进行了简单的整理，列出QA工作内容：（工作经验有限，一定存在漏洞和问题，请各位指导）

立项准备阶段：（QA准备介入项目）

1)      与高层成员有一次交流，了解高层对该项目质量所寄予的期望和指导；

2)      QA提前与项目主要成员认识，相互了解；

3)      在可行性分析阶段学习和熟悉项目业务；

4)      确认并确保项目经理已经掌握足够的项目信息：包括项目成员，难度，项目压力，该项目和其他项目的关系，自主力度，资源分配……

5)      从项目经理处获得上述项目信息；

6)      确认和确保项目经理根据所收集的项目信息进行预估和分析：项目类型分类，项目生命周期类型定义，人员经验和意愿情况分析，资源情况分析；

7)      与项目经理讨论关于项目情况和预期达到的品质标准，启动并确保项目经理拟定了项目周会的方式和时间；

8)      确认和确保项目经理已经对项目风险进行了充分的识别、分析和提供解决方案；

9)      收集项目过程类培训需求，对相关人员进行培训；

10)   从模板基线库挑选和准备相应过程文档模板，并保证其正确性；

11)   立项报告完成后，得到里程碑，根据对项目的了解分析和检查其合理性；

需求设计阶段：（QA正式介入项目）

12)   检查项目经理在进入需求设计阶段一个工作日内填写了项目文档列表；

13)   定期检查里程碑和项目文档列表的吻合度；

14)   确保各成员会用文档模板，请他们按照里程碑定义准备需要的文档；

15)   项目详细时间表出来前按照里程碑的时间定期检查文档完成情况和评审过程实施情况；

16)   定期收集整理项目组所使用的模板情况，多少是标准模板？多少是试运行模板？

17)   指导项目组走模板维护流程；

18)   协助指导并评审相关职能部门所产生的流程

19)   按照评审过程指南，抽查评审效率，及时发现评审过程问题并指导；

20)   收集项目数据：如文档工作量，评审工作量，人数，时间等；

21)   需求文档评审QA必需参加，并且根据Spec check list进行评估，确保下游顺利交接；

22)   需求文档评审通过后，请各成员根据需求估计工作量，并出附属计划；

23)   工作量估计粒度适度，充分沟通保证项目成员主动接受该任务；

24)   完成QA计划，和项目经理讨论具体对那些过程需要进行质量评估，项目经理在组织项目组实施过程的时候就可以通知QA参加。QA计划中需要定义在过程产生的几个工作日内进行QA的审计和评估工作。

25)   确保和保证项目经理集成所有附属计划；

26)   确保项目经理在项目进行过程中实时更新和跟踪风险管理任务；

27)   QA在审计和评审过程中，发现不符合项和预警内容，需及时highlight，保证高层及时了解项目进展；

28)   参加pre kick-off会议，检查和确认当前状态符合kick-off要求；

29)   确认在pre kick-off完成的两个工作日内进行项目kick-off；

Design&Coding阶段：

30)   需求文档评审通过，立即提前了解并确定HLD设计模式，单份文档还是多份文档？设计模式？

31)   在需求文档评审通过的5~6个工作日内，检查HLD设计完成情况和评审过程；

32)   在需求文档评审通过的5~6个工作日内，检查TCS设计完成情况和评审过程；

33)   检查TC完成情况和评审过程；

34)   定期审计评审过程，评估评审方式的实用性，指导评审过程；

35)   定期抽查文档完成情况（需求文档定稿版、HLD、TP、TCS），抽查文档质量；

36)   定期抽查项目组内部各成员所掌握的文档一致性；

37)   收集需求和设计变更次数，抽查变更过程与标准化流程吻合度；

38)   定期核对开发组、测试组的Schedule，要求细化到3天以内，保证项目经理及时发现延迟并分析原因；

39)   参加项目周会，从QA视角评估本周状态，并及时收集项目状态；

40)   QA在审计和评审过程中，发现不符合项和预警内容，需及时上报，保证高层及时了解项目进展；

Alpha & Beta 阶段：

41)   定期检查测试流程和标准化流程的吻合度；

42)   定期检查debug流程和标准化流程的吻合度；

43)   定期检查debug状态；

44)   定期检查TR，并分析其与项目质量目标的吻合度；

45)   定期检查项目release流程按照标准化流程进行；

46)   发现严重质量缺陷及时发起Pending；

Deliver阶段：

47)   完成QA summery report；

48)   整理项目度量数据，为过程改进提供建议；

49)   参加项目summery report；

50)   收集整理项目文档、模板、流程、经验；