关闭

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

发表于:2008-9-19 17:16

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:网络转载

  1. 绪论

  优良的软件过程可以为开发高质量的软件提供有效的实践方案。随着软件开发复杂性的日益增强及软件行业规范化管理经验的逐渐积累,通过依托某种软件过程在开发中产生恰当制品、科学有效地控制开发节奏与步骤,从而合理调配与使用开发资源、满足开发愿景,已经成为提高软件生产率、确保如期按质地提交软件成果的重要途径,而这一观念也正被越来越多的软件开发公司所认同和采用。

  2. 软件过程和敏捷建模

  经典软件工程理论所阐述的软件过程,特别是瀑布模型,由于其较强的理想化环境条件假设,所以如果在实际软件开发项目中采用,往往会与实际情况产生较大脱节,使得实施效果大打折扣,故而往往只以具有理论参考意义的面孔出现。而当前在业界,既有完整理论,又有较强可操作性的软件过程,则以统一过程(the Unified Process,简称UP)和极限编程(the eXtreme Programming,简称XP)最为令人瞩目。

  2.1 统一过程与极限编程及其思想观念

  2.1.1 UP与XP的特征

  统一过程作为一种重量级的指导性的软件过程,其基本特征体现在用例驱动、以架构为中心、迭代和增量开发等几方面。根据对统一过程生命周期的不同划分方法,统一过程还分为企业统一过程(EUP)、Rational统一过程(RUP)等不同子类型。而极限编程则不同于统一过程,它在本质上属于更为敏捷的一种软件过程,并由一系列简单却互为补充的实践所组成。

  2.1.2 统一过程的优势

  虽然比较XP而言,UP更为传统一些,其过程控制灵活度也相对较弱,但由于这种软件过程非常适用于复杂、需求多变、开发难度大的情况,同时也可以根据项目特点进行适当裁剪,所以仍然被许多软件企业所广泛采用。特别是,对于一些在软件过程控制方面依据UP原则已经形成较为固定模式、同时又注重以各阶段的指定制品控制开发节奏的公司而言,如何在保持UP基本方法的前提下,提高UP项目开发的敏捷性则是一个非常现实而重要的课题。

  2.2 以敏捷建模改造统一过程的可行性

  2.1.3 敏捷建模与统一过程在实践中的内在联系

  事实上,敏捷建模(Agile Modeling,简称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的概念吸收了敏捷开发联盟(Agile Software Development Alliance)所倡导的若干原则(限于篇幅,这些条款将不在文中详述),并形成了自己的一系列原则与实践。纵观AM论坛发起人Scott W. Ambler所提出的涉及AM的11条核心原则和13条核心实践,笔者认为,体现AM精髓的原则主要集中在如下几个方面:

    (1)明确最终目标:即软件本身才是应当确保的工作目标;

    (2)快速迭代反馈:明确各阶段问题焦点,快速修订前一阶段过程中的制品,并推回后一阶段;

    (3)多种模型建模:即要勇于突破传统软件过程所规定的建模工具的约束,根据效果特点采用适用的建模模型描述软件;

    (4)简化工作过程:任何阶段都要以最简单的解决方案来达至工作目标,不要追求形式、不要过度构建软件。

  虽然按照Ambler的观点,必须完全执行所有11条核心原则和13条核心实践才能算得上是在敏捷建模,但笔者认为,由于AM本身就是一种不完整的软件过程,况且AM本身必定会在行业实践中进一步得到充实,所以可以认为,在目前阶段,实践上面总结出来的四条原则即可基本反映出AM的精髓。

  3. 太原同城系统开发中的敏捷建模实践

  在上述方针的指导下,可以利用敏捷建模对统一过程施行改造。以下将以山西省太原市人民银行同城票据清算系统v2.0(以下简称“太原同城系统”)为例,说明应用AM原则与实践在改造一个UP开发项目过程中的一些体会。

  3.1太原同城清算系统介绍

  3.1.1开发背景

  太原同城系统是在金融体制改革的形势下,由北京市泰通电子技术公司承担开发的,在太原市辖区范围内建设的一个连接该市各个商业银行和与人民银行清算中心的票据实时清算系统。通过实时处理贷记、借记票据交换业务,可以改变传统的票据手工交换方式,以电子流代替票据流,使资金可即时抵用,为各商业银行提供统一、快捷、安全、可靠的资金清算渠道,也为人民银行提供了监控资金流量与流向的现代化手段。

41/41234>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号