【IT168 技术文章】

    DSDM是什么？

　  DSDM（动态系统开发方法，也称业务中心框架开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效的进行系统开发。我们可以把DSDM看成一种控制框架，重点在于快速交付、并补充如何应用这些控制的指导原则的框架。

    DSDM描述了在快速开发以业务为中心的环境中包含的各个方面——项目管理、预估、原型建立、时光盒法、配置管理、测试、质量保证、角色和职责、项目组结构、工具环境、风险管理、可维护性、重用、以及供应商和购买者之间的关系。

    DSDM的基本观点是，任何事情都不可能一次性的圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为准。实施的思路是，在时间进度和可用资源预先固定的情况下，力争的最大化满足业务需求（传统方法一般是需求固定，时间和资源可变），交付所需要的系统。对于交付的系统，必须达到足够的稳定程度以在实际环境中运行；对于业务方面的某些紧急需求，也要求能够在短时间内得到满足，然后在以后迭代阶段中对功能进行进一步完善。

    DSDM的历史背景

  　20世纪90年代，IT业为了弄清楚应用程序开发的流程并归纳出避免失败的方法，进行了一系列的尝试。1994年，英国国内来自各个工业领域不同规模企业里的信息系统工作人员，以及来自IT行业中的一些大公司的顾问和项目经理聚集在一起，形成了一个非赢利性的联盟。该联盟专注于理解应用程序开发过程中的非常好的实践方法，并尝试建立一种独立于任何工具的、公开的、公认的方法。DSDM联盟提供了一个过程，这个过程能够在可控的项目环境中，在满足紧迫时间的约束下，建立和维护系统。DSDM联盟创立之初有17名会员。现在联盟已经有上千名会员，在全球范围内有多个社团：英国、北美、比荷卢经济联盟、丹麦、法国和瑞典。社团式的发展，是DSDM与其他一些敏捷型方法的不同，它有专门的组织支持，有手册，培训课程，认证程序等。在英国，由于在各种规模的软件组织中的成功，DSDM已经成为应用的最为广泛的快速软件开发方法。

    DSDM一直处于改进和变化之中，其重点内容通过会员的反馈不断修改、更新，以适应当今市场的变化。在2001年，DSDM联盟发布了以业务为中心的开发框架DSDM4.1版本，并将DSDM应用到更多的项目中——数据仓库、组件开发、原形业务法，在框架中都增加了这些内容。

    DSDM过程

  　DSDM开发过程被形象的称做“三张比萨和一块奶酪”

    DSDM周期有7个阶段：

  　1、项目准备阶段；
  　2、可行性研究阶段；
  　3、业务研究阶段；
  　4、功能建模阶段（迭代式）；
  　5、系统设计编程阶段（迭代式）；
  　6、实施阶段；
  　7、项目后期；

　  项目准备阶段确保启动、建立正确的项目。可行性研究阶段和业务研究阶段是顺序进行的，它们为后面的迭代、增量式的开发制定了基本规则。也就是说，在这两个阶段的工作充分完成后，才能进入后面的迭代阶段，而后续迭代阶段具体的迭代方式、迭代周期如何确定、整合，则需要视项目具体情况来定。比如：有些项目需要首先完成功能建模的全部迭代，然后再进入设计和编码阶段进行迭代，最后进入实施阶段，这种方式是顺序的，是各阶段内部独立完成迭代；有些项目将功能建模、设计和编码这两个阶段的每一次相关的活动做为一次迭代，通过不断的迭代，完成项目开发，最后进入项目实施；有些项目将功能建模、设计和编码、实施这一个过程做为一次迭代，通过不断的迭代，不断的呈现给用户满足他们需求的软件。因此，DSDM框架是极其灵活性的，在应用DSDM之前，必须要定义和评估使用DSDM的方式，在项目过程中，也可以随需而变，进行动态调整，以便能够更好的支持商业需求。DSDM“动态系统开发方法”的名称也是由此得来的吧！哈！^_^

　  DSDM的可行性研究阶段主要侧重评估DSDM方法是否适用于本项目，我觉得这一点比较与众不同，因为在很多的可行性研究结果中，已经把瀑布模型默认为软件开发方法了。在可行性研究阶段需要得到一些结论“该系统技术上可行吗？”、“对当前业务流程带来的影响可接受吗？”、“DSDM是开发这个系统最好的方法吗？”......必须把这些问题弄清楚，以便确定“这样去做值得吗？”。然后需要出一份全面的可行性报告，对于风险很高的方面，还需要提供如何应对、控制风险的策略。除了可行性报告之外，还需要提供开发的框架计划（outline plan），证明预期的结果是可实现的；另外，也可以提供一个快速原型，目的是证明项目从技术上是可行的。当然，如果对业务已经有了一定程度理解，相应的技术也已经用过，那么生成原型的价值也不大，可以不需要。DSDM的哲学就是：“足够就好，无需过多！”。

  　业务研究阶段主要是对业务流程进行分析和定义。首先需要开展一系列的讨论会，对业务流程及其相关信息、用户群进行定义，这些定义的结果被称做业务区定义，经过管理层同意后，需要从使用业务的用户群中选出代表参与到开发过程中。进行业务区定义时，可以采用结构化分析方法，定义主要的数据流程图；也可以采用面向对象的方法，定义重要的用户用例。对于业务区定义的功能，必须区分出是功能性需求还是非功能性需求并且划分优先级，因为DSDM是以业务为导向的，所有制定优先级的原则也必须要以业务为导向，但是也需要从技术实现需要的角度来考虑，把技术上要求先实现的功能做为高优先级。这样就可以清晰的理解需要开发的功能和它们实现的优先级，从而引导我们对系统架构的定义，系统架构定义实际上定义了软件开发、运行的平台，软件模块和接口的结构。最后，根据可行性研究阶段的开发框架计划和业务区定义可以制定出开发计划，这个开发计划应该包含功能建模阶段和设计编程阶段的开发策略、测试策略和配置管理计划。

  　功能建模阶段主要是深入分析业务区定义的功能并进行细化，在分析模型的基础上构建软件模块，将创建的原型交付用户评审，经过用户评审后进一步充实和改进，这样经过不断迭代，原型逐渐演化成可工作的软件。在功能建模阶段，还会产生以下产物：

  　1、带有优先级的功能：随着业务的细化，业务研究阶段定义的优先级需要调整，从而保证本次迭代中包含用户最需要的核心功能。
  　2、功能性原型的评审文档：用户每次对原型评审时提出的改进建议都需要被记录下来，并需要根据这些评审结果对业务定义、建模进行修正。
  　3、非功能性需求：在功能建模阶段将非功能需要也需要记录下来。（但是，这里我就有一个问题一直比较困惑，因为在前期建模阶段，主要注重了对业务流程的分析建模，和对高优先级需求的原型实现，倡导快速实现、交付用户评审，因此，这个过程一直注重功能性需求，对于性能方面关注不多，因为无法从全局考虑、并更深入的考虑 到整个系统的性能瓶颈，特别是前期架构设计若存在缺陷将导致后期出现性能隐患，这是很难解决的；另外，若前期迭代功能与后期迭代关联功能存在性能制约，也存在一定风险。因此，我觉得在这一阶段，进行建模时也必须要考虑到各种可能的性能需求的技术实现，并且也需要制定优先级，在不同的迭代中处理必要的性能需求。）
  　4、实施计划：在功能建模阶段，就应该规划这一阶段的实施计划了。包括：业务方案的准备，培训用户的计划，各种知识、技能的准备。

    设计编程阶段主要根据功能建模的标准建造实际系统并通过测试。这里的测试和瀑布模型的测试是不同的，它不是一项单独活动，测试应该是贯穿于整个功能建模和设计编码过程的。

　  实施阶段主要是培训用户，完成系统从开发环境向运行环境的交接，然后评估这一阶段哪些需求做完了，下一阶段需要做哪些工作。我觉得有时候开发环境（包括测试环境）不可能完全模拟用户运行环境，因此在系统移交过程中，也可能会出现一些实施问题；另外，在这个阶段，部分隐藏的系统性能问题也可能会暴露出来，也需要关注。

　  项目后期评审当前使用的方案并评估是否达到预期的效果。

  　DSDM的基本原则

    DSDM方法建立在9条原则之上，而且在实施过程中，这9条缺一不可。

    原则1：用户必须持续参与
　
    DSDM过程中，用户持续参与的概念是：在整个DSDM生命周期中，有一些专业用户会一直对开发组提供支持和参与。能够随时解决开发组对业务流程的各种问题，使工作进展顺畅，同时用户也会对原型进行验收，提出各种建议和想法。

　  原则2：必须授予DSDM团队制定决策的权利
　
    DSDM鼓励管理层将权利下放，团队成员都应该得到授权。为了使项目快速进行，团队成员必须能够对他们的工作迅速做出决定，以保证项目能够如期交付。当出现问题时团队成员应该能做出决定，如下是一些常见的决定：
　
    需求的实际含义。
　
    从功能、可用性考虑开发中产生的中间产品是否可接受。

    工作进程中需求的优先级制定。

    修改技术细节。

  　尽管DSDM不鼓励团队在出现问题时，逐层向上级反馈，但是也提供了这种问题的处理途径。

  　可以看出，同为敏捷方法，DSDM方法与SCRUM方法的项目管理思路，特别是对团队授权和对项目过程问题的处理机制还是存在很大差别的，SCRUM方法强调团队成员反馈问题，并且对于开发组不能解决的问题，必须逐层反馈，获取高层的指导，并且支持高层领导参与项目的SCRUM 　Meeting，强调迅速向上级反馈，上级迅速做出决定。而DSDM方法中，团队成员已经被授权直接做出决定了。

　  原则3：注重产品的经常交付

    经常交付产品，能够让外部人员检查团队内部所做出的决定是否可以接受。这样，项目就能够得到控制。这里说的产品是不仅仅是软件，还包括数据模型。产品的经常交付能够反映项目当前的进度，也能够衡量项目是否沿着正确的方向在进行。

　  原则4：满足业务用户用途是接受交付品的主要依据

    开发人员不必沉溺于完美的解决方案之中，耽误项目时间。在受限的时间内，实现业务利益最大化的交付品才是最重要的。

  　原则5：迭代和增量式开发对得到正确的业务解决方案是必不可少的
　
    采用迭代开发的方法，能够使业务流程逐步进化，使系统不断朝着满足业务需求的方向前进。

　  原则6：开发过程的所有变化可逆

  　采用迭代和增量式开发过程中，很可能会碰到走错的情况，此时需要回退到一个已知的可靠的点上。

　  原则7：在高层次上制定需求的基线

  　在业务研究中所得出的需求必须在高层次上达成一致。接下来在迭代过程中再得到详细的需求。

　  原则8：测试自始至终贯穿于开发周期之中

  　开发人员完成一个模块的开发后，自己会进行单元测试。当模块集成到现有系统后，测试人员需要执行集成测试。另外，回归测试在DSDM中占有很重要的地位。

  　原则9：所有项目涉众间的通力合作是不可获缺的

　  何时使用DSDM？

  　对于具有以下特性的应用，DSDM特别适合：
　  1、交互式、功能通过用户界面体现。
　  2、有清晰的用户群。
　  3、没有复杂计算。
　  4、如果是大型应用，可以分解成小的功能部件。
　  5、有时间限制。
　  6、需求不清楚或不确定