CMMi RUP XP相关

     CMMi是个超重量级的模型，Rational Unified Process (RUP)是一个重量级的软件过程，而极限编程(eXtreme Programming )则是轻量级开发过程的典型代表，但无论何种过程模型，其终极目标皆是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。CMMi总结了软件工程领域数十年的经验教训，其中定义的关键域，关键操作，关键产品输出对于任何一个软件开发团队都具有指导意义，尤其CMMi已然成为衡量开发团队成熟度的一个硬性的通行的指针。但从CMMi的实施要求和实施成本考虑，国内大多数软件开发团队或公司恐怕没有能力完全遵照CMMi的定义来构建自身的软件过程。在这种情况下，RUP和XP对于确保软件质量、降低开发维护成本、提高客户满意度、提升开发团队整体素质等诸多方面，其实是很好的选择。个体软件过程(PSP)当然也是可供每个项目经理、软件工程师认真学习实践的指南，但就个体而言，难以实现精确的量化管理，而且个体的目标与团队的目标通常是存在冲突的，这样便更需要在软件系统产品开发过程中，以整体的力量弥补个体的不足。

      对于所有的关键开发活动，RUP为每个团队成员提供了使用准则、参考模板、工具指导，并以此形成所有团队成员的的共同知识基础。而通过对相同知识基础的理解，无论进行需求分析、设计、测试项目管理或配置管理，均能确保全体成员共享相同的知识、过程和开发软件的视图。RUP的关键点在于6方面：
1.采用迭代式而非瀑布式的开发方法
2.强化需求分析管理，准确地描述用户需求
3.使用基于Component的体系结构
4.充分利用可视化软件建模工具
5.既要提出验证软件质量的标准，也要在适当的时机进行验证
6.严格控制软件的变更，缩减变更的影响范围，同时能够追溯每一次变更

    而从XP的角度考察，XP认定的核心价值在于4方面：
1.沟通：一个项目之所以出问题，必定缘于沟通不力。一些重要的事情该说却没有说或者说错了，那么其结果可想而知。
2.简化：在做每一项工作之前，都应该问自己：“怎么做才是最简单的？”
3.反馈：每个成员都希望自己提出的疑问得到回复，而且是尽快的回复。每个人都需牢记：冷漠是团队协作的敌人。
4.勇气：是否每个工程师都愿意和经理讨论自己的一个设想？是否每个系统分析员都甘心面对客户的冷脸？是否每个工程师进入陌生领域时都是信心百倍呢？勇气是沟通、简化、反馈的基石。

    XP似乎更像是在教导我们如何工作如何生活，事实上XP以上述4个核心价值为基础，提出了具有可操作性的实践方法。对于这些实践方法，软件界的讨论研究已经汗牛充栋，此处也不再赘述。但一个有意义的话题是，如何将XP的核心价值融入RUP呢？换句话说，RUP与XP并非完全相互排斥的方法论，在软件开发实践中，二者是完全可以实现某种程度的互补。

    RUP起源于被IBM收购的Rational，而Rational正是现代OOA&D思想的重要起源地，因此，可以理解为何RUP强调将重点放在分析与设计等前期工作，为何强调使用基于Component的体系结构。“Plan for the future，and design for reuse”是RUP的一条基本准则。然而XP则强调每个团队成员需要做好当天的工作（无论是编码、测试、还是与项目经理交流），并相信团队成员有足够的能力和灵活性以应对未来的变化。这种信任，不是缘于盲目自大，与RUP一样，XP也要构建所有成员共同的知识基础、共同的Vision，并通过学习和培训建立成员的自信心，通过小规模低成本的快速开发验证自己的设想。如果每个成员都能像休斯顿火箭队的Battier那样意志坚定地说：“I can play！”，那么即便没有“Impossible is nothing”那般的霸气，也足以有勇气完成沟通、简化、反馈，完成RUP中定义的所有任务。

 

cmm/cmmi 与 agile 的区别主要有：

1、CMM更注重质量，Agile更注重生产率

错。

Agile 至少与 CMM 一样注重质量，只不过它采取了更为轻便的、成本更低的方式来保证质量。生产率并不是 Agile 追求的主要目标，只是一个迭代轻量过程的副产品。

正确的说法是：

Agile 与 CMM/CMMI 都非常注重质量，差别在于一种是轻量方法，另一种是重量方法，分别有各自适用的项目开发环境。

2、CMM强调过程的可观测性，Agile强调可观测的结果（可运行软件）

大致对。

3、CMM注重管理和过程，Agile注重技术和效率

错。

Agile 不但包含敏捷工程技术，也包含敏捷管理和敏捷过程。Agile 至少与 CMM 一样注重管理和过程，区别在于 Agile 采用的是一种更为轻便、灵活、高效的方式。

难道一定要采用重型方法，制定大量的细节行为规范，编写大量的文档，采集大量的数据，才叫管理和过程？轻型方法就不能做好软件研发的管理和过程？显然，这没有道理。

在 Agile 支持者眼中，对于他们所从事的项目开发环境，Agile 是远比 CMM 更为有效、先进和成熟的方式方法。

认为只有 CMM 注重管理、过程和质量，而 Agile 不注重管理、过程和质量，显然是一种错误的偏见。

正确的说法是：

CMM/CMMI 与 Agile 是两种不同的软件研发管理和过程体系，区别在于前者重量，后者轻量；Agile 包含了更多具体、实用的软件工程技术方法，而 CMM/CMMI 提供了更多以数学统计为基础的过程管理和质量控制技术方法。在适用条件下，轻量过程通常会带来了更高的开发效率。

 

 

 

 Rational Unified Process（简称RUP）是一套软件工程过程【1】。RUP本质是风险驱动的、基于Use Case技术的、以架构为中心的、迭代的、可配置的软件开发流程。 可以针对RUP所规定出的流程，进行客户化定制，定制出适合自己组织的实用的软件流程。 因此RUP是一个流程定义平台，是一个流程框架【2】。RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)【3】这些核心工作流有点像CMMI里的关键过程域,不过CMMI里的关键过程域比这多。CMM是一个软件过程改进模型.RUP、XP是项目的开发方法，按照RUP来做，你的项目可能可以达到CMM的一定级别，但是这仅仅可以针对一个或几个项目，而非组织性的行为.CMM本身需要融合在一个软件组织的体系当中，也就是说软件组织的各级、各层、各个组织部分,甚至个人需要在软件过程、软件过程的不同阶段能够以成熟规范的方式来协调和运作，由此获得最佳的项目成果【4】。

     XP（eXtreme Programming)极限编程，这是一个颇有争议的软件开发方法。如果去搜索相关资料，会发现有人很推崇，有人很反对。XP是一个轻量级的、灵巧的软件开发方法.它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法.它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程【5】。XP有它的适用范围，在一个小型的团队开发有限集成和独立的软件产品事有效的。如果在大型团队和复杂集成中应用可能会带来混乱。同样，XP与CMMI的关系，如同RUP和CMMI的关系，RUP、XP都是项目的开发方法，CMMI没有限制用什么方法。CMMI的范畴要比RUP和XP更广

软件开发过程(CMMI/RUP/XP/MSF)是与非

 经 常看到和听到大家在争论敏捷过程、RUP和CMM 哪个软件开发过程更好或者哪个过程不好，各自都有理由、争论得不亦乐乎......实际上，没有十全十美的过程，也不存在更好的过程。关键是什么样的过程适合自己（的组织），适合自己的过程才是好的过程。更重要的是，适合自己的过程需要时间积累、需要不断实践，对已定义的过程进行剪裁、补充和完善，才会建立最适合自己的软件开发过程。

       引用Alistair Cockburn的一句话 “不同的项目需要不同的方法论，一个项目的最佳过程是这个项目所能负担的最小过程。”， 这说明，对一个组织，往往有几种方法并存，而对不同类型的项目，采用不同的方法。选择一个合适的生命周期模型对于任何软件项目的成功都是至关重要的。大量项目严重拖延、产品迟迟不能交付，究其根本原因往往是与错误运用了生命周期模型有关，这其中就包括存在明显缺陷的瀑布模型所引起的误区，虽然70年代提出的瀑布模型多年来一直被我们的软件工程教育奉为经典来传授，实践上瀑布模型往往会将软件过程引入歧途。与之不同是，新的过程方法论，不论轻型、重型， 还是XP、RUP或者TSP，无一例外地都主张采用能显著减少风险的迭代演进式生命周期模型，强调迭代。但过分强调迭代，可能会忽视需求分析和定义、忽视设计，在后期不断改动，使软件开发的不良成本（返工、修正缺陷等）大大增加，增加了企业成本。

   例如，越来越多的人在讨论、推崇敏捷过程、极限编程(XP)，实际也是有问题的，虽然敏捷过程、极限编程适合Web的开发、适合免费的Web服务、适合永远的Beta版本，其中也有许多思想也确实值得应用，如持续集成、重构、强调测试等，但也存在其它问题，如结队编程、计划博弈、代码集体所有等。极限编程只适合小型团队、适合开源社区等，而不适合大型软件企业；在软件开发过程的全局上，更适合采用统一过程（RUP）、微软软件开发框架（MSF），而在局部、细节，吸收敏捷思想。有位美国朋友告诉我，XP可能昙花一现。不管他说得对否，当软件作为成熟的产业，肯定是不会允许完全像“XP”这种做法的。

   由于篇幅和时间有限，在这里，可以将目前的流行的过程模式进行一个对比分析，大家就会对不同的软件过程的优缺点，一目了然。

项目	CMM/CMMI	RUP	MSF	XP
周期	螺旋模型。	演进式迭代周期，过程框架	瀑布模型和螺旋模型的结合	演进式迭代周期。软件开发方法学
核心	过程改进	架构、迭代	里程碑、迭代	以代码为中心。
范围	需求严格而极少变化的项目。	适合不同类型的项目	适合不同类型的项目	进度紧、需求不稳定的小项目、小型发布和小团队
组织	个人（PSP）、团队（TSP）和组织的3个层次，组间协作、培训	跨团队协作	强调产品的愿景，6种基本角色	以团队为基础，小团队、团队成员能力相当
技术	传统结构化方法	面向对象技术	综合技术	面向对象技术
管理	侧重于过程的定义、度量和改进。一切用数字和文档说话。	从组织角度出发，侧重于过程建模、部署。	业务建模、部署、过程管理等概念。	侧重于具体的过程执行和开发技术，计划设计。
活动	通过过程域来定义活动	整个团队在整个过程中关注质量	项目管理、风险管理和就绪管理	以人为本，如每周40小时工作制、结对编程
实践	各类级别的关键实践。 重视关键基础设施。	满足了CMM 2-3 级KPA 的要求，而基本上没有涉及CMM 4-5 级的KPA	代码复审、版本管理方法、文档管理、人员招聘、重测试和重风险管理等。	编码和设计活动融为一体，弱化了架构。 用例、单元测试、迭代开发和分层的架构。
其它	通用性强，但复杂、高成本。	强调风险驱动，以保障可用产品的持续性交付为前提，尽量减少不必要的过程工件，使度量、文档最小化以获得弹性和应变能力。	提供了一系列指南，用于规划企业的基础技术设施，流程化商业的运作过程，并鼓励重用性。	拥抱变化，强调人性化、简单、沟通。尽量减少文档。 个体和交互胜过过程和工具。

    
    概括起来, 不存在一种通用的或一成不变的 适合软件开发和维护所有项目的软件过程模型。在组织软件过程中，存在不同的企业文化和业务环境、不同的层次和规模、不同的架构和产品类型、不同的资源和能力等因素制约，需要根据不同的项目、不同时期来选择和运用不同的过程模型和方法。不断吸收已有过程的思想，不断探索、不断实践，最终慢慢形成适合自己的自我定义的过程。

经过实践检验和积累的、自我定义的软件过程才是最好的过程。