CMMI+L2标准体系详解

CMMI L2标准体系详解序：一个处于“无序化”生产的软件公司，要进行过程改进，首要是改进什么呢？做任何事情都需要计划，做软件开发这样复杂的工作更加需要计划，所以2级中有项目计划(PP)以及项目计划跟踪与控制(PMC)两个PA，分别对指定计划以及计划的执行给出了详细的标准。

人是会死的，需求是会变的。

需求变更是每个软件公司最头疼的问题，需求变更也是导致项目进度拖延、成本高涨的主要原因。

如何管理好需求呢？需求管理(RM)给出了详细的指引。

软件生产越来越复杂，有时候我们需要采购一些组件，用于项目中。

另外一个方面，纯软件的项目比例也慢慢缩小，很多软件是基于一定的硬件的，而不少硬件也是需要采购的。

如何采购到合适的软硬件，如何保证采购工作不影响项目成功呢？供应商协议管理(SAM)会给你一个解答。

软件是比较难进行量化管理的，但作为公司的管理者，总会想知道成本、进度、缺陷方面的一些数据，以了解项目的情况。

CMMI2级，已经对度量提出了要求，详细情况见度量(MA)这个PA。

如何保证软件生产过程中各类工作产品协调一致，配置管理(CM)会给出指导。

如何保证每个工作产品以及生产工作产品的过程是遵照规定执行的呢？产品与过程质量保证(PPQA)有明确的指引。

CMMI L2级一共有以下PA：1)项目计划(PP)2)项目计划跟踪与控制(PMC)3)需求管理(RM)4)供应商协议管理(SAM)5)度量(MA)6)配置管理(CM)7)产品与过程质量保证(PPQA)每个PA有什么乾坤呢？我们会详细向大家阐述。

目录一章：需求管理(Requirements Management) (2)二章：项目计划(Project Planning) (4)三章：项目跟踪和控制(Project Monitoring and Control) (6)四章：供应商协议(Supplier Agreement Management) (8)五章：过程与产品质量保证(Process and Product Quality Assurance) (9)六章：配置管理(Configuration Management) (10)七章：度量(Measurement and Analysis) (13)一章：需求管理(Requirements Management)人是会死的，需求是会变的。

相信大家都经历了很多需求变更的痛苦，项目被拖延，成本高涨，十有七八是需求管理没有做好导致的。

有哪一些需求管理方面的常见问题呢，这里列举一下：1.因为项目进度赶等原因，在很多需求还没有明确情况下，便开始开发的工作。

2.开始客户只能提出模糊的需求，客户喜欢先让你做个东西给他看，然后他才可能逐渐提出真正的需求，而需求调研人员，对此没有什么好的处理办法。

3.客户以种种原因不签需求，项目组在不签需求的情况下，便开始开发工作。

4.客户不承认之前提出来的需求，项目组又不能得失客户，项目成员苦不堪言。

5.需求经常变化，无法控制。

6.设计、代码与需求不对应，特别是需求变更时，不知道应该修改哪部分，也不知道会有哪些影响。

......这方面的问题可真是“罄竹难书”了，需求管理这个PA提供了能解决以上大部分问题的最佳实践。

RM(Requirements Management)只有一个Specific Goals:Manage RequirementsRequirements are managed and inconsistencies with project plans and workproducts are identified.中文大意是：管理需求并且识别出需求与项目计划、工作产品不一致的地方。

这句话有两层意思：1.需求要被管理，被管理的意思又有两层：一是需求要被确认，二是要控制需求变更2.需求要用来指导下游的工作产品，如：计划、设计、测试等下面简单介绍一下这个Specific Goals下的5个Specific Practice：第一个SP是：理解需求。

开发者应该理解客户的需求，如果这点做不到，后面的工作是没有意义的。

所以，那种在没有理解需求的情况下，就仓促开发的做法是不合适的。

当然，如果想通过做原型来获取需求不在此列，另外，大家也千万不要误解，在没有完全理解需求前一定不能开展开发工作，如果部分需求已经掌握，有部分需求还没有掌握，那也是可以先开展已掌握部分需求的设计、编码工作的，这时需要考虑没有确定部分的需求对这些工作可能带来的影响。

这个SP的英文原文是：Develop an understanding with the requirements providers on the meaning of the requirements.第二个SP是：确认需求，就是要和客户签署需求。

我想大家都非常理解这点的重要性，但大家可能会说，说得容易，客户就是不签，咋办？客户不签需求，主要是两方面的原因：1)客户不确定需求。

中国组织过程改进网2)客户担心签了需求后，他就不好变了。

对于原因一，解决办法就是大家需要把SP1理解需求做好，如何把需求理解做好，更详细的内容可以参考3级的需求开发(RD)，这里先不详细解说。

对于原因二，要消除客户的顾虑，首先签署需求不是单方面的约束，其实也是对开发方的约束，就是说我们要承诺做出这样的一个东西，如果做不出来，客户可以追究我们的责任，另外一个方面，要跟客户说清楚，需求是可以变的，现在签署只是标志着当前的一个工作里程碑，当前签订的需求，是我们后续工作的一个基准。

大家可能又会问如果只能确定一部分需求，客户还是不愿意签，咋办？那就先签确定部分的需求呗！这个SP 的英文原文是：Obtain commitment to the requirements from the project participants.第三个SP 是：管理需求变更。

需求不是不可以变，只不过需要管理。

客户今天说改这，明天改那，后天又不算数，咋办？怎样才算管理需求变更呢？1.要充分理解客户提出来的需求变更，深究其原因，不能客户一说变就变，超过一半的客户变更要求，其实都是不合理的，或者是有其它更好的替代办法的。

2.客户提出来的变更要求，要书面记录，并让客户确认，和客户讨论需求变更过程来往的邮件要保存好，和客户面谈、聊电话后，要发邮件总结当此会谈达成的要点共识，总之就是要有书面记录。

3.客户提出来的需求变更，要分析所有的影响，包括增加多少的工作量，需要修改或者增加哪些设计文档代码等，可能会引发什么风险等。

所有这些要列出清单，反馈给客户，让客户确认。

4.如果需求变更导致项目成本和进度变化太大，超出可承受范围，则需要高层领导出面，和客户协商调整费用。

这个SP 的英文原文是：Manage changes to the requirements as they evolve during the project.第四个SP 是：维护需求的双向跟踪。

需求是用来指导后续工作的，所以需求与计划、设计、编码、测试等后续工作都需要维护好对应的关系，这个工作与第三个SP 是关系密切的，如果这个关系没有维护好，那么SP1.3也不可能做好。

这样是不是双向跟踪就能做好呢？不是，双向跟踪的意思不是由A 能找到B，由B 又能找到A 就叫双向跟踪。

双向跟踪是只纵向和横向跟踪，前面提到的只是纵向跟踪，纵向跟踪的意思是上下游工作产品之间的跟踪关系。

而横向跟踪指的是需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等。

其中一个需求变化了，有可能影响另外一些需求，其中一个设计变了也可能影响另外一些设计。

所以，这个双向跟踪网络，将会是一个很强的网络，任何一点发生变化，能找出全部受牵连的地方。

这个SP 的英文原文是：Maintain bidirectional traceability among the requirements and the project plans and work products.第五个SP 是：识别出需求与下游工作产品不一致的地方。

这里有两层意思：1.需求变更时，利用双向跟踪表找出需要修改的地方，并用跟踪表来发现不一致的地方并调整。

Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2008For Evaluation Only.2.编写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品的时候，要注意要与需求保持一致。

这个SP的英文原文是：Identify inconsistencies between the project plans and work products and the requirements.二章：项目计划(Project Planning)大家都明白这样的一个道理：做事情要有计划，有一个不成熟的计划总比没有计划要好，软件开发这么复杂的活动，更加需要计划。

那么应该怎样做好一个计划呢？如果对项目的范围、规模、性质、任务、工作量、费用等都不了解的情况下，是不可能做出计划的，所以做好计划的第一步就是要把这些东西搞清楚。

PP这个PA的第一个Specific Goals，中文大意是：建立和维护用于项目计划的各类参数的估算，英文原文是：Estimates of project planning parameters are established and maintained.下面我们再详细看看，到底做计划之前，需要搞清楚什么东西？SP1.1：Estimate the Scope of the Project.估计项目的范围，如项目的目标、任务、工作产品等。

这里通常就是指WBS(top-level work breakdown structure)，试想一下，我们做计划之前不是常常要先对任务进行分解吗？SP1.2:Establish Estimates of Work Product and Task Atrributes.估计工作产品及任务的属性。

做计划的时，我们会先列出这个项目要产生的工作产品，以及这个项目要完成的任务等，然后我们需要分析这些任务、工作产品的规模、工作量、复杂度、代码行数等所谓的属性。

CMMI 并没有规定一定要分析什么属性，具体由企业自己来选择适合自己需要分析的属性。

在CMM模型的时候，项目计划这个PA硬性规定了需要分析的几大属性，CMMI模型中已经改进，不再强制要求。

分析这些属性的目的是对任务、工作产品等更加了解，以便于做好计划。

SP1.3Define the project life-cycle phases upon which to scope the planning effort.定义项目生命周期。