RUP大讲堂第二讲-业务驱动开发的原则Ver14.pdf

RUP 大讲堂( 第二讲)- 业务驱动开发的原则 北京恒讯时代信息技术有限公司 肖勇 13511008825 2 议程 背景 最佳实践介绍 适合的过程； 平衡利益相关者的关系； 团队的协同； 体现跌代的力量； 提升抽象的级别； 不断的改进质量 小结3 背景 业务更加依赖于IT 技术 软件由以技术为中心转变成为以业务为中心 软件技术目前已经具备 软件管理手段日益成熟4 背景- 随需应变的世界所面临的挑战 管理复杂 异构的环境 提高资源 的利用率 降低成本 业务流程可以 灵活应变 整合业务流程 系统和人 Build, Integrate, Extend, Modernize, Deploy5 背景-让随需应变成为现实 随需应变的业务需要一个随需应变的支撑环境 Requires Supports Enables Provides 随需应变支撑环境的特征 开发、整合、虚拟、自主 业务绩效管理 创造业务灵活性 优化 IT 架构 随需应变支撑环境 的能力 端对端业务流程6 回顾- RUP的三大中心的元素 是成功软件开发的一组原则；这些原则是RUP开发出来的 基础； 是可复用的方法模型和过程建构的框架，将熟悉的方法 融和在过程中将你自己的方法配置定义成为你自己的方 法框架并且裁减过程； 具有统一的软件方法和过程定义语言。采用统一方法架 构的元模型，用于体工软件工程方法和过程。7 最佳实践的变迁 提高过程的适应性。 平衡有竞争的涉众的优先级。 团队协作。 迭代地证明价值。 提高抽象层次。 持续关注质量。 迭代开发 。 管理需求。 使用基于组件的开发方式。 可视化模型。 持续的保证质量 。 变更控制。8 提高过程的适应性 对于软件项目而言过于复杂或者过于简单的过程都是不 适合的，需要精确，可控，而过程的裁减这需要根据不 同的因素，包含项目的规模，团队的分布，项目扩展约 束的书量以及项目所处的大的阶段 好处：生命周期的效率；开放并且诚实的沟通风险 处理方式： 跟据项目需要定义过程模型的规模； 适合的流程可以真对项目的不同的阶段可以不断的根 据项目的实际情况进行改进 根据不同的不确定性的级别平衡计划和预估9 提高过程的适应性- 过程规模选择 过度复杂的过程是没有必要而且不好的，因为这样会带 来： 过多的工作成果和细节； 更多的模型需要同步； 需要更多的外部评审。 I 建议小的团队则使用轻量级的过程， 对规模的需要扩大项目则需要更多的约束10 提高过程的适应性- 考虑流程强度的因素 传统应用升级 系统之系统 实时、嵌入式应用 严格的认证要求 简单升级 研发原型 静态Web 应用 流程控制强度 动态Web 应用 商业软件 基于构件的应用(J2EE, .Net) 需要强流程控制的情况 分布的开发团队 大型项目(多个小团队组成更大的团队) 项目干系人较多 生命周期的后期 存在外部强制的约束 标准、法律要求 合同要求 需要弱流程控制的情况 非分布的开发团队 小型的简单项目 项目干系人较少 生命周期的前期 内部设定的约束 源自Walker Royce 的基于结果的软件管理11 提高过程的适应性- 生命周期中的流程控制强度 产品 发布 弱 流程控制 (为快速适应变化而优化) 强 流程控制 (为实现高质量的产品发布而优化) 流程强度 产品质量 ( 距离发布的时间) 源自Walker Royce 的基于结果的软件管理12 提高过程的适应性- 预估以及改进 项目早期： 最小化过程的形式，便于建立， 集中精力在大的蓝图上， 解决不确定性 在项目的中后期： 增加形式化， 提供更多的管控， 增加精确的计划 持续的加强过程的改进， 在项目的结束或跌代的结束后对项目进行改进 鼓励项目成员能够找到改进的机会13 平衡有竞争的涉众的优先级 平衡利益相关者之间的利益关系， 一般情况下业务的利益相关者之间都有冲突； 其次，客户化要求和已有资产之间的冲突 好处： 按照业务和用户的需求进行应用开发的安排； 降低个性化的开发，优化业务的价值 方式： 定义，理解并且优化业务和用户的需要； 优化项目的要求，并且连接需要和软件能力； 明白我们拿些已有资产能够有比较大的作用，平衡资产复用和 用户需要的关系14 平衡有竞争的涉众的优先级- 业务和涉众需要的重要性 高效的管理软件需求： 捕捉业务过程 优化项目和软件的能力来支持业务的需要 根据对项目的理解修改相应的优先级，让客户确定你已经明 白他们的需要，可以使用以下技术手段： 用例的驱动 以用户为中心的设计 采用已经有的打包软件和已经有的资产来加快软件的开发 降低开发的成本15 平衡有竞争的涉众的优先级- 理解哪些资产是可用的 判断哪些资产你是能够使用的，然后平 衡资产复用和涉众需要 资产包含： 已经有的遗产应用， 服务， 可复用的组件， 模式16 团队协作 建立高效沟通的团队 好处： 形成组织级的生产力， 更好的衔接业务需要和说开发软件的操作 模式： 激发团队最大的发挥自己； 建立自我管理的团队，鼓励通过软件功能性的方面进行沟通； 提供高效的协同的环境； 通过集成化的环境来管理进化的工作成果和任务以提升协作和改 进； 集成业务，软件和操作的团队17 团队协作- 沟通和协同 激发个体的能量，激励团队中个人的最好表现， 人员能够真实的感知其在项目中的责任 鼓励基于软件功能沟通，推倒不同职位之间沟通的墙； 确保成员明白这个项目的使命和远景18 迭代地证明价值 采用跌代的开发方式，跌代的开发方式能够更好的适应软件的变 化，能够更好的回馈，能够降低软件开发的风险以便对开发过程进 行动态的调整 好处： 尽早降低风险，对项目有高的可预见性； 增加利益相关者之间的信任 方式： 通过交付和回馈来增加用户的价值， 通过跌代的开发以适配你的计划， 拥抱并管理变化 主动，尽早处理主要技术，业务和程序的风险19 迭代地证明价值- 交付增量价值 增量交付不断从用户方获得反馈， 将项目分成了一组跌代，每一次跌代我们履行已 部分的需求，设计，实现 每一次跌代产出可执行的工作成果，每次跌代我们 可以得到一下的反馈： 我们是否在正确的方向； 利益相关者是否满意； 我们是否需要改变功能部件的实现； 哪些功能部件需要加入一增加软件的业务价值20 迭代地证明价值- 计划调整 调整跌代过程以适应你的计划，通过跌代开发， 我们能够了解到： 我们整体的工作在哪里； 团队的进展如何； 我们是否需要为成功完成这个项目进行修正 全面的修改这个项目计划 为下一个跌代开发更细的要求21 迭代地证明价值- 管理并拥抱变化 拥抱并管理变化，软件更加复杂，通过一 轮很难得到高品质的软件； 大多数高效的应用开发方法必然需要处里 变化问题； 跌代提供了增量实现这些变化的机会22 迭代地证明价值- 尽早发现风险 尽早的将需求拽出来，包含： 技术， 业务的， 程序的 持续的评估风险标记最高的风险在 下一轮跌代中23 提升抽象的级别 提升抽象的级别，有利于降低复杂度，尽早的建立高 层次的架构 好处： 简化 降低复杂度 模式： 使用已有的资产， 用高层的工具和语言减少文档的产出； 首先聚焦在软件体系架构上， 保证体系架构具备一定的弹性，具备高的质量便于 理解并能进行复杂的控制24 提升抽象的级别- 复用已有的资产 复用已有的资产，在高层次的抽象上展开工 作降低复杂度并促进沟通如： 可复用的组件， 继承系统， 已有业务过程， 模式， 公开源码软件25 提升抽象的级别-SOA26 提升抽象的级别- 高层语言的使用 标准语言，比如统一建模语言（UML ） 快速应用语言比如EGL 设计和构建工具 组合项目管理工具使用27 提升抽象的级别- 首先处理架构性问题 首先关心架构，设计，实现，测试架构 定义高层次的板块和最重要的组件的责任和接口 设计和实现架构的机制28 持续关注质量 持续不断的质量改进，更高的质量 和更早的进度/ 质量洞察 好处： 高的质量， 早期洞察过程和质量 方式： 确定团队对质量的期待， 尽早测试， 持续的集成； 增量的， 自动化的测试29 持续关注质量- 稳固质量水准 确定团队管理着整个项目的质量，保证 软件的质量在用户的期待之上 定义质量的度量的标准；确定产品能够 达到一定的水准，质量能够重现30 持续关注质量- 尽早的持续测试31 持续关注质量- 采用自动化测试 逐步建立测试自动化来及早发现缺陷 使前期投资最小化 设计你的系统时，考虑到它将如何被测试 直接从设计模型中产生测试代码。32 总结 正如我们开始时注意到的，这些原则是从十余年前它们的原型演化 而来的，那时软件开发者的工作环境基本上是更为有限的。我们关 于软件开发的知识，以及项目成功的整体条件，都逐渐成熟并不断 扩展。今天的业务驱动的软件开发组织需要眼界更为广阔的指导， 这包括了地理分布开发，IT管理和规则服从需要，面向服务架构， 等等。 正如软件开发不是严密的科学，我们相信这些原则不应当被当作绝 对的条款，或永恒的真理，而是作为一种改进软件项目结果的指导。 这些原则还将继续演化 不是以很快的速度，但是逐渐的，随着 我们掌握更多关于哪些方法有效，哪些无效等等的经验。不变的一 点是Rational 帮助客户（他们的业务依赖于开发和部署软件）取得 成功的长期不懈的努力。33