【IT168 技术文章】

    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条核心实践才能算得上是在敏捷建模，但笔者认为，由于AM本身就是一种不完整的软件过程，况且AM本身必定会在行业实践中进一步得到充实，所以可以认为，在目前阶段，实践上面总结出来的四条原则即可基本反映出AM的精髓。