RUP大讲堂-02-业务驱动开发的原则

RUP大讲堂(第二讲)-业务驱动开发的原则2议程ƒ背景ƒ最佳实践介绍适合的过程；平衡利益相关者的关系；团队的协同；体现跌代的力量；提升抽象的级别；不断的改进质量ƒ小结3背景ƒ业务更加依赖于IT技术ƒ软件由以技术为中心转变成为以业务为中心ƒ软件技术目前已经具备ƒ软件管理手段日益成熟4背景-随需应变的世界所面临的挑战管理复杂异构的环境提高资源的利用率降低成本业务流程可以灵活应变整合业务流程系统和人Build,Integrate,Extend,Modernize,Deploy5背景-让随需应变成为现实随需应变的业务需要一个随需应变的支撑环境RequiresSupportsEnablesProvides随需应变支撑环境的特征开发、整合、虚拟、自主业务绩效管理创造业务灵活性优化IT架构随需应变支撑环境的能力端对端业务流程6回顾-RUP的三大中心的元素ƒ是成功软件开发的一组原则；这些原则是RUP开发出来的基础；ƒ是可复用的方法模型和过程建构的框架，将熟悉的方法融和在过程中将你自己的方法配置定义成为你自己的方法框架并且裁减过程；ƒ具有统一的软件方法和过程定义语言。采用统一方法架构的元模型，用于体工软件工程方法和过程。7最佳实践的变迁ƒ提高过程的适应性。ƒ平衡有竞争的涉众的优先级。ƒ团队协作。ƒ迭代地证明价值。ƒ提高抽象层次。ƒ持续关注质量。ƒ迭代开发。ƒ管理需求。ƒ使用基于组件的开发方式。ƒ可视化模型。ƒ持续的保证质量。ƒ变更控制。8提高过程的适应性ƒ对于软件项目而言过于复杂或者过于简单的过程都是不适合的，需要精确，可控，而过程的裁减这需要根据不同的因素，包含项目的规模，团队的分布，项目扩展约束的书量以及项目所处的大的阶段ƒ好处：生命周期的效率；开放并且诚实的沟通风险ƒ处理方式：跟据项目需要定义过程模型的规模；适合的流程可以真对项目的不同的阶段可以不断的根据项目的实际情况进行改进根据不同的不确定性的级别平衡计划和预估9提高过程的适应性-过程规模选择ƒ过度复杂的过程是没有必要而且不好的，因为这样会带来：过多的工作成果和细节；更多的模型需要同步；需要更多的外部评审。ƒI建议小的团队则使用轻量级的过程，ƒ对规模的需要扩大项目则需要更多的约束10提高过程的适应性-考虑流程强度的因素传统应用升级系统之系统实时、嵌入式应用严格的认证要求简单升级研发原型静态Web应用流程控制强度动态Web应用商业软件基于构件的应用(J2EE,.Net)需要强流程控制的情况分布的开发团队大型项目(多个小团队组成更大的团队)项目干系人较多生命周期的后期存在外部强制的约束标准、法律要求合同要求需要弱流程控制的情况非分布的开发团队小型的简单项目项目干系人较少生命周期的前期内部设定的约束－－源自WalkerRoyce的《基于结果的软件管理》11提高过程的适应性-生命周期中的流程控制强度产品发布弱流程控制(为快速适应变化而优化)强流程控制(为实现高质量的产品发布而优化)流程强度Î产品质量(距离发布的时间)－－源自WalkerRoyce的《基于结果的软件管理》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