【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、实施计划：在功能建模阶段，就应该规划这一阶段的实施计划了。包括：业务方案的准备，培训用户的计划，各种知识、技能的准备。