rup简谈SCRUM和轻量RUP的区别

RUP流程是什么?

RUP是Rational Unified Proces 的缩写，翻译成中文就是“统一软件过程”。

　　RUP是一个基于6个最佳开发实践的流程定义产品。

　　6个最佳开发实践 　　1、迭代始开发 　　2、需求管理 　　3、基于组建的体系架构 　　4、可视化建模 　　5、持续的质量管理 　　6、配置管理 　　RUP如何来实现6个最佳开发实践 　　1、把软件开发过程看成是多次迭代开发的过程，并且把迭代开发分成4个阶段 　　(1)Inception phase(开始阶段） 　　定义出项目目标和范围 　　(2)Elabration phase（细化阶段） 　　制定计划、定义项目基线、确定系统的体系架构 　　(3)construction phase（开发阶段） 　　主要是编码、单元测试工作，是人工最密集的阶段。

　　这个时候，虽然允许有小的需求加入进来，但是应该尽量避免大的需求变动。

　　(4)Transition phase（发布阶段） 　　将产品提交给用户适用。

包括相关的培训等内容 　　注意：每个阶段有若干次迭代组成。

　　可以看出RUP虽然是基于迭代式开发，但是在整体的4个阶段划分上还是类时与瀑布式开发的软件过程。

　　2、定义出一次迭代开发所要遵循的9个disciplines 　　(1) bussiness modeling 　　(2) requirements 　　(3)Analysis & Design 　　(4) Implementaion 　　(5) Test 　　(6) Deployment 　　(7) Project Management 　　(8) Configration & change Management 　　(9)Enviroment 　　其中前6个称为 core engineering workflows,后3个称为supporting workflows 　　在每次迭代中，我们都要经历所有的disciplines 　　其实，RUP的所定义的9个disciplines，跟瀑布式开发是向类时的。

（需求－》分析、设计－》开发－》测试－》部署） 　　四、RUP本质的揭示 　　1、RUP是风险驱动的、基于Use Case技术的、以架构为中心的、迭代的、可配置的软件开发流程。

　　2、我们可以针对RUP所规定出的流程，进行客户化定制，定制出适合自己组织的实用的软件流程。

　　因此RUP是一个流程定义平台，是一个流程框架。

统一过程RUP软件开发的优缺点是什么

RUP 具有很多长处:提高了团队生产力,在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面,针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导,并确保全体成员共享相同的知识基础。

它建立了简洁和清晰的过程结构,为开发过程提供较大的通用性。

但同时它也存在一些不足: RUP只是一个开发过程,并没有涵盖软件过程的全部 内容,例如它缺少关于软件运行和支持等方面的内容;此外,它没有支持多项目的开发结构,这在一定程度上降低了在开发组织内大范围实现重用的可能性。

可以说 RUP是一个非常好的开端,但并不完美,在实际的 应用中可以根据需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。

简谈SCRUM和轻量RUP的区别

现在我们谈敏捷方法论的时候谈scrum比较多，而水晶方法论，轻量RUP也是一种偏敏捷的方法论，在这里简单的分析下scrum和轻量rup的一些本质上的区别，仅代表个人意见。

从产生的过程来说 对于水晶方法论或轻量RUP，其产生过程始终是老的偏重的方法论的裁剪和优化，其理论支撑基础仍然是传统软件工程，因此不管如何轻量我们仍然可以看到这些方法论有比较明确的过程和阶段，产出要求，岗位角色，过程和配置管理等等基本内容。

所以是一个重过程裁剪为轻过程。

而对于scrum，这个词语最早是橄榄球里面的争球，最好引入到了软件开发中，scrum核心思想是敏捷，是借鉴外来的团队协同，敏捷，可视化多方面的经验新构建的一套方法论，是一种从无到有的创新，这套方法并不会一开始就受到传统工程哪些必备的约束，完全根据目标和价值驱动来选择关键活动和最佳实践。

从目标，假设和约束来说 对于水晶方法论或轻量RUP，其基本假设仍然是遵循一定过程可以带来好的产品，即使裁剪后仍然保留软件生命周期的影子，是重过程而弱化人，这些方法论为了适应变化对传统方法进行了调整，但是并没有碰触到传统方法的根源，工程+过程仍然是核心，可以做到适应变化，是偏被动的心态。

而对于scrum，其驱动的目标是客户和价值，是由该目标驱动我们应该如何做，所有的最佳实践也仅仅是参考，关键是满足客户目标实现产品价值。

scrum本身核心是重视人而轻过程，过程为人和产品价值服务，人+客户是核心，不仅仅可以做到适应变化，而通过自适应调整做到拥抱变化，是一种主动积极的心态。

从方法论的内容上来看 对于水晶方法论或轻量RUP，其方法论的核心是软件工程，中间兼顾少来的项目管理和过程管理的内容，所以更多的是对软件生命周期过程，阶段步骤，产出验证，角色分工，过程质量等方面的内容。

而对于项目管理本身的内容在方法论中谈及的比较少。

而对于scrum，其方法论的核心是团队管理和项目管理，然后才是软件工程。

包括看板可视化，站立会议，燃尽图，在backlog中引入的估算和任务直接分解等都属于项目管理方面的内容。

而对于需求究竟要如何做，设计要如何做？需求，设计开发有哪些明确的边界并不太在意。

scrum是期望客户目标和项目目标来驱动开发过程，而不是已经有一套软件工程方法模板再来考虑项目如何管? 从系统分析和架构设计来看 对于水晶方法论或轻量RUP，基本会保留总体架构设计的影子，或者说RUP本身就很强调以架构为核心，架构设计的概念完整性。

在高层的系统分析和建模，在轻量的RUP中有时候很难去迭代。

我们一直在讲架构包括了业务分解，业务抽取，系统分解和系统集成四个关键步骤，如果真有了这四个步骤，那么就难以实现所有业务需求按user story的全程条目化贯穿和跟踪。

而对于scrum方法论，其假设是架构设计工作也是一个迭代的过程，同时将架构设计的工作融入到已有的backlog的user story中。

这虽然有一些问题，但是真正可以实现全程的条目化估算，跟踪和执行。

这个往往是我们后面所说的可视化跟踪，集成，燃尽图实践的基础。