介绍
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级的标准。
XP（extreme Programming ，Agile）
针对以CMM为代表的重载软件过程（还有RUP，ISO9000等，意味着软件组织在过程定义、维护、度量、质量保证上投入大量的资源，实现这样的开发过程是复杂的、高成本的），敏捷过程表明了完全不同的立场，宣称好的开发过程应该可以在保证质量的前提下，做到文档、度量适度，很容易适应变化并迅速做出自我调整，实现企业效益的最大化
XP认为：随着软件技术的发展，尤其是面向对象技术的普遍采用，软件修改的成本现在远远向下偏离于Boehm曲线，甚至并不会随时间增长而增加，所以软件开发可以不必要事先计划、事先设计，完全可以在变化到来的时候再作出适当的反应，这样的开发模式才是高效的。
XP的十二个实践：1. 现场客户（On-site Customer，2. 计划博弈（Planning Game），3. 系统隐喻（System Metaphor）4. 简化设计（Simple Design）5. 集体拥有代码（Collective Code Ownership）6. 结对编程（Pair Programming）7. 测试驱动（Test-driven）8. 小型发布（Small Releases）9. 重构（Refactoring）11. 每周40小时工作制（40-hour Weeks）12. 代码规范（Coding Standards）。
有人以为，XP目前在中国可能有两类企业能适用，一是创业型企业，另一类可以在实施CMM2，3级或达到相当的能力之后再推行XP。
RUP (Rational Unified Process)
RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。
RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。商业建模(Business Modeling), 需求(Requirements), 分析和设计(Analysis & Design), 实现(Implementation), 测试(Test), 部署(Deployment), 配置和变更管理(Configuration & Change Management), 项目管理(Project Management), 环境(Environment),
RUP的迭代开发模式
RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统
PSP个人软件过程
能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过PSP学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用PSP，从而有助于CMM目标的实现。
TSP小组软件过程
结合了CMM的管理方法和PSP的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项目的管理，向组织展示如何应用CMM的原则和PSP的技能去生产高质量的产品。
讨论及总结
不管是CMM, 还是rup、XP，（或是IPD，ISO），PSP,TSP实践是检验真理的唯一标准。我们只有在工程中实践这些方法，才能知道其优缺点，才能对其进行改进。现代软件工程不论何种方法学，对影响软件实践的三个基本要素已基本达到共识：那就是：人、技术、和过程。各个流派主要分歧在于对各个要素强调的程度不同。比如，CMM和rup主要强调的过程，认为只有具有好的过程才能生产出稳定质量的软件，并且达到CMM3后，可确保在整个组织内软件质量。但Agile流派强调的是人，认为人才是创造的源泉，只有人与人之间的充分交流（包括与用户的交流和开发着之间的交流）才是解决许多问题的关键。他们用一系列方法如增量开发、重构、测试先行、结对开发等等来保证软件的质量，比较适合小型团队，和创业型公司，他们称自己为轻型过程。对于中国的企业，应采用何种方法，我个人同意一种观点就是：一开始采用一种实用的轻量级的方法学，随着规模的扩大和对质量要求的增加，再增加过程的力度。
参考文件：
QAI 培训教材 www.qaiindia.com
<<统一软件开发过程>>
<<软件能力成熟度模型CMM方法及应用>>
<<极限编程实践>>
<<小组软件开发过程>>
<<个人软件开发过程>>
本文地址：http://com.8s8s.com/it/it37036.htm