CMMI、RUP、Agile（Scrum）、软件工程之结构化方法与面向对象方法

CMMI,Capability Maturity Model Integration，偏向于组织级协作的过程框架，强调组织内所有项目应该遵从的相关协定和标准。而底层工作人员很少感觉到CMMI的存在，是因为这些CMMI的规则与约定是驾凌于单个项目管理与实现之上的，在执行具体项目的时候容易（常）被模糊稀释化（这里不论效果好坏或是管理责任的问题）。

RUP，Ratianal Unified Process，统一软件开发过程，是面向对象分析设计的软件工程方法论，逻辑上可以理解为一个贯穿软件项目生命周期的过程框架。个人认为它相对与组织级别的CMMI，RUP更偏向于项目级。书上把CMMI和RUP做为并列关系看待的两种重型软件工程方法，但个人认为RUP更聚焦，聚焦于具体开发项目，例如执行哪种开发流程模型是RUP的讨论点，而CMMI则默认瀑布模型。

Agile，敏捷开发,其实是一个过程家族（方法集合），而FDD、XP、Scrum等等则是敏捷家族的具体方法论和过程子集。

所以说，CMMI和Agile不是一个层面的事物，拿CMMI和RUP会更有可比性。另外说明，它们拥有一点重要而相同的地方在于它们的核心思想都是演进evolution，即持续改进。

CMMI更注重流程管理，比如订立的里程碑，评审点等等，是一个很流程化的东西，需要项目计划，质量保证计划，按照软件瀑布式展开，也就是，需求，设计，研发，测试，上线的这种流程。每个流程都会产出文档，会有评审会。也就是说，是一步一步的走。实际中CMMI这种流程控制的，都是大项目，有明确的时间周期，而且周期较长，有明确的需求，分析的够透彻，需求不随意变更。也就是有

CMMI以完善流程为主要手段，敏捷完善个人，改善文化为主要手段 
-CMMI以管理，流程为本，敏捷以人为本 
-CMMI实施，执行及其不灵活，难度大；敏捷轻量级，灵活适应，需要有经验的辅导 
-CMMI被老板喜欢；敏捷被一线的工程技术人员喜欢

CMMI和敏捷是两种流派，CMMI注重过程和文档，敏捷注重代码本身、程序员的能力和团队沟通协作。

CMMI比较适合于软件外包，起源于美国国防部给软件公司下订单时，为了保证交付质量和进度，需要对软件公司进行一个摸底评估，因此卡梅隆大学就做了一个CMM用来评估软件公司的成熟度模型，后来演化为CMMI。在国内，因为软件外包的兴起，有些外包采购方也要求软件公司过CMMI，所以国内软件公司兴起了一股过CMMI的高潮。有些大型软件公司也通过CMMI来衡量自己的软件开发能力。

而敏捷起源于一些国外黑客和NB程序员群体，在2001年这些牛人们搞了一个聚会，发布了有名的四句敏捷宣言。除了敏捷宣言，还有11条敏捷实践原则。

CMMI的开发模型，一般以瀑布为主，也有螺旋和快速原型等经典的软件工程开发模式。敏捷开发模型基本都是迭代，迭代周期一般从1周到1个月。不是迭代，你都不好意思说你用的是敏捷开发。

工具方面，CMMI和敏捷的工具很多是共通的，不过敏捷相对更“极端”一点（参考极限编程，XP，这是敏捷主要的技术实践基础）。比如CMMI有同行评审，而敏捷提倡结对编程，实际上是时刻都在做同行评审。CMMI有版本配置管理，敏捷提倡持续集成，即每一次代码checkin都会引发一次构建、代码检查、自动测试、看板更新、邮件推送甚至是版本自动部署。CMMI有版本发布里程碑，而敏捷提倡持续交付，即每时每刻，在服务器上的版本都是可交付的。

从应用范围来说，CMMI适合于外包和大规模团队的分工协作，是一种重量级的过程，属于集团军作战；敏捷适合一个完整的小团队，属于特种部队作战。现在国内外互联网公司采用敏捷开发模式很多，因为用户需求变更频繁，版本更新换代快，必须快速响应。有很多大型软件公司也尝试使用敏捷开发方式，毕竟现在都在搞项目化运作，大公司小团队是趋势。

 

CMMI是得到明确定义的，最新版本是V1.3，包括了开发、服务和采购三大部分。
Agile并没有得到明确定义，可以从理念、思想层面来看待Agile，比如拥抱变化，注重沟通；也可以从具体实践来看待敏捷，比如计划扑克，迭代计划，持续集成；也可以从流派来看Agile，比如Scrum，XP，DSDM，FDD，ASD，Agile Crystal，还可以从团队管理角度来看Agile，还有其它方面。
Agile是丰富多彩的。
所以两者不能简单比较。需要明确在那个层面上来看待这些问题。

 

CMMI是一个最佳实践集，它提供一个框架。而敏捷可看做实践挂到CMMI框架中

Agile宣言:

1. 项目成员及交互胜过流程和工具。
2. 与客户的协作胜过协约谈判。
3. 交付的工作软件胜过文档。
4. 响应改变胜过按部就班。

建议把Scrum分成两部分，1是Scrum流程，比如计划会议、每日会议、燃尽图、回顾、用户故事、扑克估算等等，2是Scrum团队，三个典型的角色

我来分享点拙见。分别在通信行业和互联网行业实践过几年的Scrum，有一些体会。
首先，敏捷被很多人和团队视为对传统项目管理的否决，视为不要流程，不要规则的依据。项目管理本身是一门高深的，非常有价值的学问。不懂项目管理的人做敏捷常常做成野鸡流程。

Scrum的精华有两点，第一是短迭代，第二是自组织。
短迭代让团队可以形成节奏感，并在每个迭代后有机会进行回归，并在下一个迭代中提高。相比传统的瀑布流程，因为缺乏这样的反馈机制，团队的改进相对困难。
自组织的目的是让团队对目标进行自我承诺，激发团队最大的能量以达成目标。这是在公司这种权威组织中实行的小规模民主激励。对于自尊心较强的工程师团队，相当有效。不过也有缺点，那就是团队自我意识可能过强，导致跨团队合作出现问题。

但如果仅仅实现这两点，Scrum的结果可能是非常糟糕的。特别是短迭代造成两个负面后果：
第一，短迭代倾向于产生短期设计，在将来的迭代中需要经常重写。
第二，短迭代导致没有时间进行全面的回归测试，导致bug数量上升。

为了有效的解决这两个问题，Scrum必须伴随一些关键的工程实践。
第一，最重要的，是测试自动化。无论是单元测试还是功能测试，都是在短迭代下保证质量的重要，甚至是唯一手段。
第二，重构。有了自动化测试，敏捷团队应该勇敢的不断重构代码，消除技术债务
第三，持续集成。有了自动化测试，持续集成可以在最短的时间内报告问题，并要求团队将CI的错误作为最高优先级立即处理。

所以可以看出来，自动化测试是scrum最重要的实践之一。一个没有自动化测试的组织，采用scrum虽然也可以受益，但达不到“高绩效团队”的水准。

来源：https://blog.csdn.net/joeyon1985/article/details/42268583

软件工程之结构化方法与面向对象方法

　　结构化方法包括结构化分析(Structured Analysis，简称SA)、结构化设计(Structured Design，简称SD)和结构化程序设计(Structured Program Design，简称SP)三部分内容。相应地，面向对象方法包括面向对象分析(Object-Oriented Analysis，简称OOA)、面向对象设计(Object—Oriented Design，简称OOD)和面向对象程序语言(Object-Oriented Program Design，简称OOP)。两种软件开发方法从起源、思想、分析、设计，到程序设计、扩展重用、应用等各个方面有着许多的联系和区别，下文我将对于本期的这块学习做一点总结也作为我复习的一种方式吧。

　　（一）从分析上看

　　建立模型是为了更好地理解要模拟的现实世界，是软件开发方法的核心问题。在结构化方法中，使用SA构建系统的环境模型和逻辑模型，实现模型的主要工具有数据字典(DD)、ER图和数据流图(DFD)。数据字典是一个包含所有系统数据元素定义的仓库；ER图描述了数据之间的属性及联系；数据流图是描述信息流和数据从输入到输出变换，并展示系统和外部的接口、数据的输入和输出以及数据的存储的应用图形技术[1]。SA的前提条件是需求分析，建模过程是迭代分解需求、不断细化应用的过程，即数据流图的分解从顶层图开始，按照每个加工对应一个子图的分解原则，逐层分解为0层图、1层图等。

　　面向对象方法使用OOA定义类，对现实世界建模。OOA的主要任务是要在问题域上构建具有主题层、对象层、结构层、属性层和服务层的OOA模型，实现模型的主要工具有用例图(Use-Case)和类图(Class Diagram)。用例图从用户角度描述系统功能，并指出各功能的操作者，是对需求分析的整理；类图定义了类的组成（属性和服务）、类的结构和类间的关系，确定并划分系统中的类。经过OOA，系统的静态模型建立起来。

　　相对于结构化方法使用DD、ER图和DFD分别描述数据和功能（尽管二者存在相互参考），面向对象方法中，无论是用例图还是类图，数据和功能的描述总是并行的。

　　（二）从设计上看

　　在结构化方法中，使用SD构建系统的行为和功能模型，实现模型的主要工具有模块结构图(SC)和程序流程图。模块结构图说明了系统的模块的划分、模块的功能、模块间的数据传递及调用关系。根据数据流图，我们能够映射出相应的软件的上层模块结构；结合数据流图，我们可以逐步分解上层模块，设计出中、下层模块；对于得到的全部模块，我们需要设计模块基本的内部结构和外部接口及对模块结构进行优化。进一步，则是针对每一个模块设计程序流程图，整理优化，归纳算法。SD依然是对项目系统的进一步分解求精的过程，把模型从逻辑级，细化到模块级，再细化到程序级。

　　而OOD不只是对OOA的细化，更主要的，构建了系统的动态模型，实现模型的主要工具有交互图(Sequence Diagram)、状态图(State Diagram)、活动图(Activity Diagram)。和模块相比，对象最大的不同是具有“活性”，突出表现在对象具有状态和对象间能够通讯。交互图描述对象间的交互关系，显示对象之间的动态合作关系，强调对象之间消息发送的时间顺序；状态图描述对象的所有可能状态，以及事件发生时状态的转移条件；活动图描述为满足用例要求所进行的活动以及活动间的约束关系，用于识别并行活动，以提高系统效率[2]。

　　从设计方面，我们可以比较明显地看出结构化和面向对象的区别。结构化方法的核心是程序，从分析到设计，其实是从抽象到具体，从模糊到清晰地实现程序的过程；而面向对象方法的核心是功能，分析的是对象，设计的是行为，程序设计和系统设计相对分离。

结构化方法和面向对象方法的比较

见另一篇文章

https://www.cnblogs.com/maya389069192/p/6166238.html