CMM培训总结－给初学者参考1

介绍
2003年7月7日到7月12日我参加了由深圳市政府组织的并由印度QAI公司负责的CMM2级培训。
课程的主要内容有CMM的介绍，CMM的6个KPA总的介绍，需求管理，软件策划，软件计划跟踪与监督，软件子承包管理，软件质量保证，软件配置管理。
下面结合课程内容，就自己在公司的工作经验谈点自己的简单看法，供领导参考。


正文
SW-CMM Level2培训总结
黄 飚（2003-7-15）
2003年7月7日到7月12日我参加了由深圳市政府组织的并由印度QAI公司负责的CMM2级培训。
课程的主要内容有CMM的介绍，CMM的6个KPA总的介绍，需求管理，软件策划，软件计划跟踪与监督，软件子承包管理，软件质量保证，软件配置管理。
下面结合课程内容，就自己在公司的工作经验谈点自己的简单看法，供领导参考。

CMM介绍（主要是2级） 1
软件开发难点： 1
CMM介绍 2
软件关键过程（SKPA，Key Process Areas） 2
软件需求管理： 3
软件策划： 3
软件跟踪与监督 3
软件子承包管理 3
软件质量保证 4
软件配置管理 4
CMM与公司融合方向 4
建立软件过程标准 4
建立公司技术人员库 4
建立公司软件技术产品库 4
其它一些开发过程介绍与比较 5
CMMI能力成熟度整合模式 5
IPD集成的产品开发 5
XP（extreme Programming ，Agile） 5
RUP (Rational Unified Process) 6
PSP个人软件过程 6
TSP小组软件过程 6
讨论及总结 6
参考文件： 7

CMM介绍（主要是2级）
软件开发难点：
一、 项目需求变化难于把握：客户的要求也即项目的需求往往是不明确的，也很难用统一的标准来衡量。
二、 过程难于控制：常常是直到项目快结束时才知道可否按时完成。
三、 任务难于量化、计划可行性差：软件产品较难衡量，常常是靠感觉进行。项目经理对风险缺乏充分的考虑，造成计划可行性差。
四、 版本管理混乱、项目间可继承性差：各个项目组间彼此独立，重复开发多。
五、 缺乏可共同执行的标准：公司没有统一的标准，各项目组各自为政，成员在不同项目时遵守不同的标准，导致无所适从。
综上所述，软件开发过程常常处于无序状态，较难监控。

CMM介绍

从80年代开始，美国国防部资助，SEI最先提出SW- CMM（Software Capability maturity Model）理论并在90年代正式发表，目前一般说的是1993的CMM1.1版本。

CMM是在系统性思考产物，对于任何一个关键过程KP，都是从目的(Goal),约定（Co）,活动（Activate）,能力(Ab),测量（Mea）,验证这样的模式进行流程制定。
CMM强调每个变化都需要通知相关的人。
CMM是一个把事情作对（正确的做事）的一个模型。
CMM关注的是客户满意度及质量。
CMM分五级
级别 名字 过程特征 工作组 度量 改进方向
1级 初始级 依赖于人，过程不稳定 软件开发组，项目工程组 没有进行数据收集和分析工作
2级 可重复级 定义了项目管理，软件开发和维护过程相对稳定,软件项目经理负责跟踪成本,进度和软件功能，为需求和相应的工作产品建立基线(Baseline)来标志进展，控制完整性，定义了软件项目的标准，能保证项目准确地执行它。项目的成功得到了管理层的支持。通过与转包商建立有效的供求关系。项目的成功不仅依赖于个人的能力还得到了管理层的支持，重视管理和依靠管理，重视人员的培训工作，建立了技术支持活动，并有了稳定的计划 系统测试组，软件评估组，软件质量保证组，软件配置管理组，合同管理组，文档支持组，培训组 每个项目建立资源计划。主要是关心成本，产品和进度。有相应的管理数据
3级 已定义级
4级 可管理级
5级 不断优化级

软件关键过程（SKPA，Key Process Areas）
所谓关键过程领域指一系列相互关联的操作活动，这些活动反映了一个软件组织改进软件过程时必须集中注意力的地方。
过程分类等级 管理方面 组织方面 工程方面
优化级 技术改革管理过程变更管理 缺陷预防
可管理级 定量过程管理 软件质量管理
已定义级 集成软件管理组间协调 组织过程焦点组织过程定义培训程序 软件产品工程同级评审
可重复级 需求管理软件项目计划软件项目跟踪与监控软件转包合同管理软件质量保证软件配置管理
初始级 无序过程

下面根据培训的课程主要谈一下可重复级(2级)的KP及体会。

软件需求管理：
主要是需求需要受控，文档化，经过相关的人评审。需求主要指商业性需求（时间，成本），技术性需求，验收准则。
体会：公司立项没有强调验收准则，使得有些项目需求一变再变或项目没有很好的收尾。
建议公司每个项目在立项时，制定客户代表，由客户代表进行验收，并作为项目结束的唯一依据。并且客户代表的工作列为年度考核的重要指标。
建议公司在管理文件中对重大需求变更进行受控变更，并在ISO文件里进行描述。

软件策划：
主要是从软件规模估计，估计成本，工作量，确定资源特别是关键性资源。
体会：CMM非常重视量化。从软件需求的功能点估计，代码行估计，再利用公司的数据得出相应的估计。网上有一些工具可以方便的使用，也可以用EXCEL进行计算。

软件跟踪与监督
主要是跟踪软件的进度，并且发生变化时及时进解决及变跟。
体会：往往我们在项目立项时，都会花一定的时间进行计划，但在项目的进展过程中，却对项目的计划没有做及时的调整，或觉得计划总是做不准，（计划不如变化快）。对于一个段期的项目，可能问题不大，但对于超过半年的项目，计划不做调整，项目组对自己的任务进展不容易有整体把握，另外影响公司高层对实际情况的判断。
公司目前正在推行project,我觉得就是把这项工作落到实处，我建议公司可以进一步推广到普通的开发工程师及有管理职责的人员，月初由直接上级发放project格式的任务，下级接受任务后进细化到工作日，并提交，每周（或两周）进行更新，月底进行总结论。让大家明确任务，增加沟通。
以上构成公司的项目管理文化的一部分。并由公司资料室（或人力资源部门）分门别类按人进行保存（如果是纯人力做，工作量比较大，等将来有了工具支持再考虑）。
软件子承包管理
主要是软件子承包商的管理，需求，进度，成本等。
体会：公司基本上所有的开发都是自己做，华为等公司，会把一些开发外包。
主要是软件开人力密集的工作。
公司可以在一些领域进行外包的实验，如测试，编码，一些模块或外包整个软件项目等，但因为目前公司软件人力的开销不是很大，又涉及到知识产权的问题，好像不是很合适进行，再说国内医疗设备公司还没有这种模式。
但我们可以重视对商业化或个人可靠的技术的采购或合作。

软件质量保证
不用我强调，质量是企业的生命。
体会：要明确软件质量的可测试性，否则对用户言，不可见的质量等于没有。还是强调量化。并且质量人员要独立于项目经理之外，如测试人员。

软件配置管理
保证软件开发环境及需求，代码，文档的可控性，也是保证交给用户一致的产品，另一方面也可以对项目组的开发在统一的环境下进行。
可以推广版本控制程序。

CMM与公司融合方向
公司推行ISO9000的标准涉及到从原材料供应到产品销售的每一个环节。CMM侧重于软件开发和改进过程。
根据CMM是一特别重视过程的产物，强调组织保证，对于软件开发的需求，项目管理，质量保证，设计，测试，配置管理有不同的分工，强调的是技能的专业化，人员的职业化，从而对于一般的专业软件开发团队来说，如果没有一定的规模是很难完整地按照CMM的过程来实施的。特别是公司的软件开发队伍都在各项目组里，没有工作或利益上的关系，等价于3-5杆枪的地步，没有形成有效的交流及组织保证。
所以我认为公司在统一考虑开发政策的情况下，可以根据软件的特点，主要是领域知识+软件技术，又因为公司大都是在做医疗影像设备软件，因而如何提高软件技术的交流或形成软件产品或模块重用，避免重复开发，可以是作为公司中长期发展考虑的一个方向。
建立软件过程标准
公司在ISO设计与控制里有关开发制定了不少标准，但对于软件开发具体的过程控制却比较少，也没有可以具体指导的操作文件。期间XX写过一个草稿，但有关该文件的状态不是很清楚（没有发布在公司ISO文件里），我们可以在XX的文件基础上建立软件开发的模板，并在开发过程中不断改进。
项目组的特点决定了项目组成员过程的短期效应，建议公司在软件管理方面做一些简单的量化管理，比如在这两年开发过程中的软件规模的统计，软件开发时间的统计，从而得出一个公司软件开发生产率的数据，从而指导今后的软件项目的估计与公司成本估计。
建立公司技术人员库
在一个项目完了以后记录工作成果，工作技能，以后新项目成立后就可以从中找到合适的人员，并且在项目遇到困难时可以从数据库找到做过类似的资源从而快速的解决问题，另一方面也激励开发人员在公司建立良好的记录，也创造一个公平的环境，也方便公司制定开发人员的人力资源政策。
建立公司软件技术产品库
在一个项目完了以后记录工作成果，模块，主要的技术特点，以后的新项目可以根据该库查找到类似的模块，从公司申请重用，从而降低技术风险，
另一方面节省开发时间。


当然想法还有很多，不便展开。因为现在的组织架构及组织利益，有些事情的推动是很难的，也会触动一些部门的利益及工作方式，这就需要公司领导根据公司发展的目标进行取舍，毕竟不管白猫，黑猫，能抓老鼠就是好猫。
其它一些开发过程介绍与比较
CMMI能力成熟度整合模式
CMMI的全称是Capability Maturity Model Integration，即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。现在业界使用的CMMI最新模型是2002年发布的1.1版本系列，如CMMI-SE/SW/IPPD/SS，CMMI-SE/SW/IPPD，CMMI-SE/SW，CMMI-SW等。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或者多个单一学科的模型实现一个组织的集成化过程改进。在CMMI的初步研制中集成了三个特殊的过程改进模型：软件（SW-CMM）、系统工程（EIA/IS 731）以及集成化产品和过程开发（IPD CMM）；从长期考虑，CMMI产品开发群组建立了一个自动的、可扩充的框架，以便于以后将其他一些学科的过程改进模型也逐步添加到CMMI产品集中。
CMM和瀑布思想相联系，而CMMI和叠代思想联系得更紧密。

IPD集成的产品开发
IPD是Integrated Product Development 的缩写，即“集成的产品开发”，是新产品开发管理的一种模式，它逐渐兴起于上个世纪的西方企业。蓝色巨人IBM公司的重新崛起在很大程度上得益于IPD的推行，IPD使IBM的多项研发指标得到了重大改善，如：新产品上市周期的大幅度缩短、研发资源浪费比率的显著下降等。对于IT行业，IPD作为新产品开发管理模式堪称最佳实践的典范。深圳华为公司也实施了该系统。
IPD的关键要素包括：跨部门的团队、结构化的流程、一流的子流程（如：项目计划与监控、数据管理、共用模块、技术管理、管道管理等）、基于平衡记分卡的考核体系、IT支持等。
核心思想主要有：把新产品开发作为投资决策，并通过预算来管理项目，基于市场来定义新产品开发的目标，协调高效的项目团队，大量采用并行工程，结构化与非结构化之间的合理平衡。
IPD是企业级、更宏观的体系，强调研发活动要基于市场进行，并保证最终开发成果的商业成效，CMM是产品（软件）开发活动中的细部流程，保证软件按软件需求被无差错地开发出来，相比之下，CMM更多的是质量保证体系。因此，企业在实施IPD时，其中的软件过程可以用CMM规范来加以定义，或者说，可以将CMM集成在IPD体系中，尤其是CMM 2级与3级的标准。