华为CMM实施杂记

 

华为CMM实施杂记

1.相关背景

CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。

 

能力等级	特点	关键过程
第一级基本级	软件过程是混乱无序的,对过程几乎没有定义,成功依靠的是个人的才能和经验,管理方式属于反应式
第二级重复级	建立了基本的项目管理来跟踪进度.费用和功能特征,制定了必要的项目管理,能够利用以前类似的项目应用取得成功	需求管理,项目计划,项目跟踪和监控,软件子合同管理,软件配置管理,软件质量保障
第三级确定级	已经将软件管理和过程文档化,标准化,同时综合成该组织的标准软件过程,所有的软件开发都使用该标准软件过程	组织过程定义,组织过程焦点,培训大纲,软机集成管理,软件产品工程,组织协调,专家审评
第四级管理级	收集软件过程和产品质量的详细度量,对软件过程和产品质量有定量的理解和控制	定量的软件过程管理和产品质量管理
第五级优化级	软件过程的量化反馈和新的思想和技术促进过程的不断改进	缺陷预防,过程变更管理和技术变更管理

1.初始级
        初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。

2.可重复级
        根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐进化和成熟。第二级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

3.定义级
        在第二级仅定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出与项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。

4.管理级
        第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正变成为一种工业生产活动。

5.优化级
        第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果一个企业达到了这一级，那么表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。       

 

通讯软件业务复杂、规模庞大、技术更新快、市场需求变化更快，所以华为研发基本采用的是IBM的IPD-CMM方法(Integrated Product Development, 集成产品开发简称IPD）。在公司68000人中48%是研发人员。

 

PCB（组织过程能力基线）:产品线的质量管理部会定期统计各个研发团队的抽样项目过程数据,这些数据包括代码生产率/CMM各开发阶段过程中的缺陷基线/相关交付电子件的参考规模等.每个开发团队的这些数据都是会有差异的, 比如平台的代码生产率由于软件结构较为稳定可能生产率就比较高, 现场定制开发团队的由于经常受需求变更的影响,代码生产率就可能比较低.

代码生产率指的是这个开发团队每人每天能”写”多少行的代码,通常在30~50之间.别看这个数据很低,它实际包括你围绕这些代码的分析设计/文档输出/测试用例准备/代码实现/测试等工作量.PM可以参考这个代码生产率合理争取或安排项目进度

缺陷基线通常指的是描述每个阶段活动中根据代码量或规模应该从评审或测试中发现的问题数.比如PCB中描述SRS文档缺陷率是1个/每页,代码编写阶段缺陷率是16个/K,那就意味着项目中SRS文档规模如果有50页,那么评审活动就应该在50页的文档中发现50个一般级别以上的问题.

电子件参考规模指的是电子件应该根据代码量对应的电子件应该有的规模.比如PCB给出STC(系统测试用例)的参考规模是30个/K,即意味着如果你有1K的代码开发工作就应该针对这这些代码应该写30个左右的STC。

Review评审：由PM组织相关人员对各个阶段的交付件（文档或代码）进行评审，并输出检视意见。Review评审是项目质量控制的一个很重要手段。通俗的说该活动就是让本人和其他专家对自己的工作产品进行了解和检查。通常的评审方法如下

1.       作者自检后，将工作产品和评审意见反馈表单发给评审计划中对应的专家

2.       作者和评审专家检查工作产品，提出检视意见，并填写检视意见反馈表单

3.       作者综合各评审专家意见，召开评审会议

4.       作者和评审专家讨论评审意见，是接受还是拒绝或者继续讨论，拒绝需要给出拒绝理由

5.       作者对接受的评审意见进行返工

6.       评审专家对返工的部分进行检查

 

度量：度量也是一个涉及到项目成败的重要领域。主要的度量活动包括项目人员工时投入、交付件评审缺陷率统计、代码规模统计、项目进度偏差统计。

 

 

2.CMM基本实施流程

（1）      研发部门组成结构

部门领导主要有PDT/TDT（产品开发团队）经理、开发代表、维护经理。PDT/TDT经理主要负责整个部门的管理工作。维护经理主要负责网上版本的维护支持工作。开发代表主要负责的软件开发的领导和管理工作。

    开发团队分为系统组和开发组（开发组里又细分为几个开发小组）。系统组主要是由有多年开发工作经验、能力强的SE（系统工程师）组成。系统组的主要职责是做产品开发的前期分析、预研、需求答复、架构设计、开发组技术指导等要求较高、影响较大的工作。开发组主要专注于CMM开发活动。

（2）      CMM项目开发的相关角色

RDPDT:开发代表，开发团队领导。负责项目资源支持和监管。

SE:系统工程师，指导项目组开发,类似于高级工程师,属于项目组外围支持人员

QA:质量保证师，质量管理部人员,监督项目是否按照CMM流程运行,属于项目组外围支持人员。

TC:测试协调员, 参与测试计划和测试用例评审,测试部人员,属于项目组外围支持人员。

TDC：资料协调员，资料组成员,属于项目组外围支持人员。

 

PM:项目经理，项目的第一负责人，项目运行的中枢。

SWE:软件工程师，开发实现的主体。

CMO:配置管理员, 通常由SWE兼任。

MC:度量协调员, 通常由SWE兼任。

（3）      项目的启动

根据市场或相关部门间版本配套需求，首先经过系统组的前期分析和架构设计（实际也是经过了SE-CMM流程：场景分析、功能分析、功能设计等环节）输出SOW（工作任务书）文档，下发到开发组，开发代表任命项目经理PM和主要的项目小组成员，项目小组需要对sow进行评审，SE根据评审意见修改，最后经过开发代表和PM的批准生效。开发代表向上级申请项目ID启动项目，项目ID申请成功后，项目即启动。

（4）      CMM开发流程

首先进入的是PPL（项目计划）阶段。PPL阶段主要是PM在项目小组成员的支持下开展以下活动：

a.项目组评审SOW

b.代码估计：采用专家法或delphi法进行代码估计。专家法主要是由对某个特性开发有相当经验的专家直接给出代码估计值。Dephi法估计主要如下：

协调人（一般为PM）主持会议
1、各专家使用统一的估算假设（包括代码量估计标准，估计结果接受偏差范围）,进行第一轮估算（针对每个估计点给出最低值，最高值，最可能值）
2、统计第一轮各专家估算结果（不公开专家姓名）
3、讨论分歧，一般控制在15~20分钟内
4、各专家修正估算
5、重复上述步骤，直至4轮，或分歧范围小，或会议指定时间到，或专家都不想改变自己的观点
6、确定估算结果，可取平均值、中值、乐观值、悲观值或一个范围
7、结果取得共识，获得审批

 

c. PHB软件生命周期模型：对软件开发活动模型的选取。比如PM认为HLD概要设计可以不要，即可在标准的模型的去除该阶段，当然这个模型的选取需要得到QA和开发代表的批准。

d.PPL、WBS文档输出：PPL项目计划书详细说明了开发活动各个阶段的时间点/质量目标/代码等交付件规模/人员角色分工/资源需求/依赖条件/评审计划/培训计划等项目关键计划。WBS工作任务分解主要是说明小组人员各自承担的各个功能点以及各阶段活动中详细的时间进度

e.CMP、RMP、TS、DPP文档输出：CMP配置管理计划书说明的是代码或文档的配置管理，比如配置库位置、相关文档名字、源代码申请、测试用例以及需求点编号方案等。RMP风险管理计划：列出本项目进行中的可能出现的风险、风险的预防和应急措施。TS测试策略描述项目测试阶段需要的资源支持以及测试方案等。DPP缺陷预防说明书：根据项目情况以及以往项目经验需要对可能出现的一些缺陷进行干预活动。

 

PPL阶段的这些文档都是要经过评审和批准的。

 

PPL阶段结束后要开开工会议，开工会议邀请到跟项目相关的所有人员参加，由PM介绍项目的整体情况以及一些关键计划。

 

开工会后项目即进入比较实质的V字型流程的开发流程中：

 

SRS(STP、STC)                    ST

     /                                     /

       /                                  /

HLD(ITP、ITC)           IT

          /                              /

            /                          /

    LLD(UTP、UTC)  UT

                 /                  /

                   /               /

                    /             /

                       CODE

 

SRS需求分析阶段：该阶段主要是让开发人员详细的对需求进行分析，主要的交付件是需求说明文档和系统测试用例，活动如下：

      SWE分析清楚各自的需求是什么，主要是输入、处理、输出

     输出SRS文档

     评审SRS文档

     修改SRS文档

     输出STP文档

     评审STP文档

      修改STP文档

需求跟踪矩阵

     根源分析（可选）

     代码重估计

     更新项目计划和相关文档

发布配置状态报告

     阶段结束会议

     QA审计

 

HLD概要设计阶段：

     与SRS基本类型，如下有不同

     输出的是HLD和ITP：HLD重要的是描述模块间的设计关系和接口

     代码重估计是可选

LLD详细设计阶段：

     输出的是LLD和UTP：LLD细化到类和主要函数实现，文档中可用伪代码写作。

     代码重估计必须

 

Code：编码阶段

     一般编码时间较短。一般达到编译通过，基本功能可用即可。代码需要符合编程规范、经过PC-Lint/代码覆盖率测试等

 

UT：单元测试

      根据LLD阶段输出的UTC进行测试，UTC可补充修改

 

IT：集成测试

      根据HLD阶段输出的ITC进行测试，ITC可补充修改

 

ST：系统测试

根据SRS阶段输出的STC进行测试，STC可补充修改

 

BBIT构建模块集成和测试

      模块间的集成和测试：比如这个项目中的功能是和另外一个项目中的业务功能耦合在一起的时候，就需要进行BBIT测试。

 

关闭转测试

     发布，转测试部测试。测试部经过三轮的测试后，对外发布。

 

需求变更：

在项目开发过程需求变化是很难避免的，如果变化影响较大这个时候就需要提出需求变化方填写需求变更说明书。变更说明书需要经过CCB变更控制委员会的批准。PM需要及时根据需求变更调整项目计划或进行一定的规避措施，减少对项目进度和质量的冲击。

 

例外报告

每个阶段活动或由于团队以外的突发事件影响可能出现项目进度偏差、代码规模偏差、缺陷率偏差、工作量投入偏差等偏差较大的情况。PM需要分析这个偏差数据，找出引发这些偏差的根源，并指定应对措施，需要向QA和开发代表输出例外报告，例外报告需要经过QA批准。

 

培训活动

每个项目都要根据项目实际情况指定本项目开发活动中需要进行必要的培训活动

 

项目小组成员及时填写timsheet

Timesheet是度量项目小组成员投入情况的重要收集手段。如果数据填写真实，PM可以从中发现一些引发项目异常的诱因。MC需要及时督促和收集工时投入情况（当然还包括评审意见以及缺陷数据）

 

每个阶段QA都需要审计，只有QA审计通过了，项目才能进入下一阶段。

 

PM都需要发布阶段结束报告和阶段结束会议

 

3.总结

在项目开发过程中，每个小组成员不是孤立的，互相之间经常需要讨论和参与他人的检视工作。小组成员需要诚实记录自己的工作投入和缺陷情况，发现不可控的问题需要及时向PM或其他成员反馈或求助。

 

整个CMM各阶段活动中发现的缺陷率应该是逐渐收敛的过程。应该争取将缺陷及早或尽力在项目前期暴露，这样后期的返工成本就比较低。

 

CMM的核心是度量和评审

度量是实行项目量化管理的基础，在项目各个阶段都有很多度量活动：工作量投入统计、缺陷率统计、代码统计、进度统计等。有了这些度量PM才能及时了解到项目进行是否符合正常轨迹，才能及时采取措施。同时本项目的度量数据有可能会影响到PCB中的数据。而PCB中的数据同时又影响到下一个项目的计划和实施。

评审是质量保证的重要手段：CMM流程的一个重要目的就是质量可控。如果从SRS－>ST都是由本人负责评审或者根本不评审，那么这种走CMM流程就不可能及时或更多的发现问题。