敏捷建模对统一过程的改造实践.pdfVIP

敏捷建模对统一过程的改造实践 作者：金洁羽 1.绪论 优良的软件过程可以为开发高质量的软件提供有效的实践方案。随着软件开发复杂性的 日益增强及软件行业规范化管理经验的逐渐积累，通过依托某种软件过程在开发中产生恰当 制品、科学有效地控制开发节奏与步骤，从而合理调配与使用开发资源、满足开发愿景，已 经成为提高软件生产率、确保如期按质地提交软件成果的重要途径，而这一观念也正被越来 越多的软件开发公司所认同和采用。 2.软件过程和敏捷建模 经典软件工程理论所阐述的软件过程，特别是瀑布模型，由于其较强的理想化环境条件 假设，所以如果在实际软件开发项目中采用，往往会与实际情况产生较大脱节，使得实施效 果大打折扣，故而往往只以具有理论参考意义的面孔出现。而当前在业界，既有完整理论， 又有较强可操作性的软件过程，则以统一过程（theUnifiedProcess,简称UP）和极限编程 （theeXtremeProgramming,简称XP）最为令人瞩目。 2.1 统一过程与极限编程及其思想观念 2.1.1UP 与XP 的特征 统一过程作为一种重量级的指导性的软件过程，其基本特征体现在用例驱动、以架构为 中心、迭代和增量开发等几方面。根据对统一过程生命周期的不同划分方法，统一过程还分 为企业统一过程（EUP）、Rational统一过程（RUP）等不同子类型。而极限编程则不同于统 一过程，它在本质上属于更为敏捷的一种软件过程，并由一系列简单却互为补充的实践所组 成。 2.1.2 统一过程的优势 虽然比较XP 而言，UP 更为传统一些，其过程控制灵活度也相对较弱，但由于这种软件 过程非常适用于复杂、需求多变、开发难度大的情况，同时也可以根据项目特点进行适当裁 剪，所以仍然被许多软件企业所广泛采用。特别是，对于一些在软件过程控制方面依据UP 原则已经形成较为固定模式、同时又注重以各阶段的指定制品控制开发节奏的公司而言，如 何在保持UP基本方法的前提下，提高UP项目开发的敏捷性则是一个非常现实而重要的课题。 2.2 以敏捷建模改造统一过程的可行性 2.1.3 敏捷建模与统一过程在实践中的内在联系 事实上，敏捷建模（AgileModeling，简称AM）所倡导的一系列实践中有许多做法与UP 的实践是不谋而合的，有的还加强或改进了UP 的某些实践。比如： UP 和AM 都强调“项目关系人积极参与”的重要意义，甚至允许项目关系人参与建模。 UP 和AM 都强调“用代码验证”、“并行创建多个模型”。即使是UP，在必要情况下也 可调整决定同时执行源于不同规程的活动。 UP 和AM 都遵循“增量建模”的实践，但AM 通过减小增量的幅度，改善了UP 的迭代实 践。 AM “有危害时才更新模型”的实践改进了UP 及时同步各阶段不同制品的要求。 AM “使用合适的制品”的实践改进了UP 对UML 建模制品的过分依赖。 AM “集体所有”的实践改进了UP 项目中有关配置管理的观念，通过营造开放、交流的 团队文化，使所有项目成员都能访问和修改各自想处理的制品，包括模型和文档。 AM “使用最简单的工具”的实践拓展了UP 只注重使用CASE 工具的局限。 2.1.4 实践敏捷建模的主要原则 与UP、XP 相比，AM 本身则是一种基于实践的、不完整的、有序与混乱并存的软件过程。 通常，软件的开发可将UP、XP 等作为基础软件过程，用AM 增强这些更加完整的软件过程。 AM 的概念吸收了敏捷开发联盟（AgileSoftwareDevelopmentAlliance）所倡导的若干 原则（限于篇幅，这些条款将不在文中详述），并形成了自己的一系列原则与实践。纵观 AM 论坛发起人ScottW.Ambler 所提出的涉及AM 的11 条核心原则和13 条核心实践，笔者认 为，体现AM 精髓的原则主要集中在如下几个方面： (1）明确最终目标：即软件本身才是应当确保的工作目标； (2）快速迭代反馈：明确各阶段问题焦点，快速修订前一阶段过程中的制品，并推回后 一阶段； (3）多种模型建模：即要勇于突破传统软件过程所规定的建模工具的约束，根据效果特 点采用适用的建模模型描述软件； (4）简化工作过程：任何阶段都要以最简单的解决方案来达至工作目标，不要追求形式、 不要过度构建软件。 虽然按照Ambler 的观点，必须完全执行所有11 条核心原则和13 条核心实践才能算得 上是