51Testing软件测试论坛

标题: CMM培训总结【转】－给初学者参考 [打印本页]

作者: 我想我是海 时间: 2004-5-17 22:00
标题: CMM培训总结【转】－给初学者参考
介绍
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级的标准。

作者: 我想我是海 时间: 2004-5-17 22:01
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方法及应用>>
<<极限编程实践>>
<<小组软件开发过程>>
<<个人软件开发过程>>

作者: ch0806 时间: 2004-9-24 15:01
请问这位大侠是做过程改善的吗，我对这方面很感兴趣，很想做这方面的工作。希望你能指教。
我看过好多这方面的东东，但还是不知道从那方面入手。

作者: freemail 时间: 2004-10-4 12:01
标题: CMM是成熟之路
CMM是软件成熟的可靠选择，是改善软件研发过程的良好助手。不过，CMM是实践支之路，没有实践就没有CMM。
另外，CMM的关键是KPA，掌握了各个KPA，就掌握了CMM。而且CMM的各个级别不是孤立的，各个级别的KPA都是可以相互混用的，根据企业实际情况，任意选择，不要居于形式。
欢迎大家同我交流...

作者: 喝醉的女孩 时间: 2007-4-27 12:40
标题: 基于基线化的迭代开发和风险管理策略
cmmi 项目研发项目管理亚远景

来源：www.cmmcn.com
基于基线化的迭代开发和风险管理策略
亚远景科技项目研发管理专题系列（1）
作者：杨俊庞丽
IPMS（Integrated Project Management System），是一个为上海贝尔阿尔卡特某移动事业部门定制化开发的多系统集成项目管理系统，其目标是通过对该部门整个开发管理工具环境的集成来达到对项目的实时跟踪和管理，以及数据的采集和度量。然而，一个客观事实是，国内大量的中小型项目中的绝大多数都存在着需求不明确性的问题，伴随而来的是大量需求变更所带来的开发风险。那么面对这样的客观事实，是否意味着项目经理根本无法应对这样的问题呢？真正优秀的项目经理又会如何挑战需求不明确和需求变更所带来的开发风险呢？
[案例背景]
背景描述1: 随着阿尔卡特与朗讯科技的合并，该移动事业部门也将与原两家公司的多个部门进行合并。合并后的新部门将采用全新的产品线定义，并实施新的项目管理流程。在这样的情况下，以前的IPMS系统已经无法满足该事业部门对项目的流程管理，IPMS系统三期开发势在必行。
背景描述2: IPMS系统作为一个集成化的管理系统与众多功能强大的软件系统集成，其中包括ClearQuest，一个强大的事务状态管理软件。原先IPMS与ClearQuest通过一组ClearQuest软件预先定义的API进行数据通讯。
[提出问题]
由于合并的时间过于仓促，以及部门之间的项目数据定义和管理流程的不同，导致IPMS三期开发的需求极不明确，整合后的新部门内部还在为部门的项目管理的流程定义和系统可能的功能修改争论不休，在这样的情况下，项目进展十分缓慢。
IPMS三期的第一个迭代中有这样一个非功能性需求，即ClearQuest的版本升级，随之而来的一个风险便是，伴随着ClearQuest的版本升级，没有人知道原版本中与IPMS数据通讯的API接口是否可以向下兼容。
[解决方案]
　1．基于现实的问题，即该事业部门确实无法在很短的时间内协调和构思出统一的系统需求，以及部门希望尽快将部分功能使用起来的愿望，项目组采取了基于需求基线化管理的迭代开发。项目组采用了合适的开发步骤，首先基于目前的需求不稳定性项目组决定了以一个月为开发的迭代周期；然后在策划期提取出一组客户的高端需求，通过对需求的简要分析和工作量估算，并依据一组参数（比如重要性，紧急程度和需求的稳定程度）规划出一个月内（一次迭代期）的项目需求；对这些需求建立基线，一旦需求的基线确立，那么在这个迭代周期内的需求应该是稳定的；最后项目组在一个迭代周期内，通过依据CMMI的流程对系统进行三期开发。
通过这样的方式，能够尽可能的降低需求不明确所带来的开发风险，增强需求的可管理性，但是如果在迭代内部发生了需求的变更又该如何处理呢？
2．项目组通过对风险可能的发生时间点和阀值的控制，来管理风险的危机。
项目组首先识别出了ClearQuest升级后的API兼容性风险；同时，通过讨论，项目组确定了这个风险可能转化为问题的时间点，即一旦完成三期对项目注册功能的修改后，必须在测试时确定IPMS中注册的项目数据是否可以正确的被保存入ClearQuest中，我们可称那个时间点为A时间点；当项目的开发活动快到达A时间点之前，项目组安排人力对新版本ClearQuest中的相同API进行了简单的功能原型测试，测试结果表明确实存在兼容性问题；项目组立刻决定修改项目计划，并在原先的风险预留的时间段内增加了对API兼容性问题的处理事务，从而解决了ClearQuest版本升级可能导致的系统无法正常注册项目的重大问题，使得项目得以平稳开发。
[案例评析]
在软件项目开发过程中，对于开发模型的选择，需要在项目定义过程中明确。CMMI V1.2 For dev中，过程域IPM的SP1.1 Establish the Project’s Defined Process有明确要求。在上述案例中，提到的迭代式开发模型为众多开发模型中的一种，而在项目中具体要使用哪种模型可从组织项目定义过程中进行选择。软件开发模型通常有以下几种：瀑布型，迭代型，原型等，具体选择何种，需要视项目的特点而定；上述案例的主要特点是需求的不稳定性，选择迭代式开发模型无疑是一种较好的选择。可以看到，上文中有提到“基线化”一词，有实施CMMI的企业或参加过CMMI过程改进活动的个人对这个词一定不陌生。CMMI模型中，要求对过程的产出物进行配置管理。过程域CM中，SP1.3 Create or release baselines 要求建立并发布基线。基线是经过评审并通过的一系列产出物，基线建立以后，后续的开发工作需以此作为基础。上述案例中，之所以提出基线化一词，意在强调阶段性地需求需要经过评审并确定之后，以此指导后续开发工作。此外，越来越多的人关注软件项目开发过程中风险管理环节。风险管理过程是用于识别潜在的问题，并策划应对策略，在需要时实施相应动作以消除不利影响。在CMMI模型中，有专门一个PA对风险管理进行描述和要求。上述案例中，正是识别到由于ClearQuest升级而带来的API不兼容性风险，并针对于风险采取了利用阀值控制等措施。软件开发过程中，我们会遇到各种各样的风险，而且这些风险一旦发生，会给项目的顺利进行带来严重威胁，因此在项目计划时，就要制定一个严密的风险管理计划，并且对于风险情况进行严格的跟踪，这样才可能把风险对项目所带来的影响降低，至最小。
[有关亚远景团队]
　　　亚远景科技有限公司不仅具有经验丰富，兢兢业业工作的咨询团队，在企业中更存在一股强大的开发力量。在进行软件开发过程中，开发人员经常会遇到各种各样的非具体技术解决上的有关流程等问题向咨询顾问寻求解决方案，这样，既可以保证软件开发项目的顺利进行，也方便咨询顾问进一步了解当前软件开发的一切相关问题，从而达到互助互利，共同进步的目的，其工作模式在业界受到广泛好评与一致认可。

作者: venus1813 时间: 2007-4-27 15:03
谢谢啦

作者: venus1813 时间: 2007-4-27 15:06
谢谢啦

作者: yeziqingqing 时间: 2007-5-10 14:25
了解一下！谢谢！

作者: andrewchou 时间: 2007-7-31 13:29
谢谢楼主分享

作者: wangstand123 时间: 2007-8-8 09:19
顶！！

作者: wangstand123 时间: 2007-8-8 09:20
2级不是7个PA么？？还有一个PPQA呢？

作者: wangstand123 时间: 2007-8-8 09:23
看错了sdlkfj1 ，还差一个度量和分析

作者: imqjzf 时间: 2007-8-10 19:21
学习中

作者: poi0110 时间: 2007-8-11 09:59
3ks

作者: miaomn2 时间: 2007-8-28 14:47
非常感谢

作者: zwpeager2006 时间: 2007-8-30 22:47
thank you !

作者: tgbangbang 时间: 2007-8-31 13:05
写的真好

作者: changlang530 时间: 2007-9-3 10:53
感谢

作者: yangsiyu 时间: 2007-9-4 09:43
不错

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)