DSDM业务中心框架开发方法[2]

  DSDM周期有7个阶段：
  1、项目准备阶段；
  2、可行性研究阶段；
  3、业务研究阶段；
  4、功能建模阶段（迭代式）；
  5、系统设计编程阶段（迭代式）；
  6、实施阶段；
  7、项目后期；
  项目准备阶段确保启动、建立正确的项目。可行性研究阶段和业务研究阶段是顺序进行的，它们为后面的迭代、增量式的开发制定了基本规则。也就是说，在这两个阶段的工作充分完成后，才能进入后面的迭代阶段，而后续迭代阶段具体的迭代方式、迭代周期如何确定、整合，则需要视项目具体情况来定。比如：有些项目需要首先完成功能建模的全部迭代，然后再进入设计和编码阶段进行迭代，最后进入实施阶段，这种方式是顺序的，是各阶段内部独立完成迭代；有些项目将功能建模、设计和编码这两个阶段的每一次相关的活动做为一次迭代，通过不断的迭代，完成项目开发，最后进入项目实施；有些项目将功能建模、设计和编码、实施这一个过程做为一次迭代，通过不断的迭代，不断的呈现给用户满足他们需求的软件。因此，DSDM框架是极其灵活性的，在应用DSDM之前，必须要定义和评估使用DSDM的方式，在项目过程中，也可以随需而变，进行动态调整，以便能够更好的支持商业需求。DSDM“动态系统开发方法”的名称也是由此得来的吧！哈！^_^
  DSDM的可行性研究阶段主要侧重评估DSDM方法是否适用于本项目，我觉得这一点比较与众不同，因为在很多的可行性研究结果中，已经把瀑布模型默认为软件开发方法了。在可行性研究阶段需要得到一些结论“该系统技术上可行吗？”、“对当前业务流程带来的影响可接受吗？”、“DSDM是开发这个系统最好的方法吗？”......必须把这些问题弄清楚，以便确定“这样去做值得吗？”。然后需要出一份全面的可行性报告，对于风险很高的方面，还需要提供如何应对、控制风险的策略。除了可行性报告之外，还需要提供开发的框架计划（outline plan），证明预期的结果是可实现的；另外，也可以提供一个快速原型，目的是证明项目从技术上是可行的。当然，如果对业务已经有了一定程度理解，相应的技术也已经用过，那么生成原型的价值也不大，可以不需要。DSDM的哲学就是：“足够就好，无需过多！”。
  业务研究阶段主要是对业务流程进行分析和定义。首先需要开展一系列的讨论会，对业务流程及其相关信息、用户群进行定义，这些定义的结果被称做业务区定义，经过管理层同意后，需要从使用业务的用户群中选出代表参与到开发过程中。进行业务区定义时，可以采用结构化分析方法，定义主要的数据流程图；也可以采用面向对象的方法，定义重要的用户用例。对于业务区定义的功能，必须区分出是功能性需求还是非功能性需求并且划分优先级，因为DSDM是以业务为导向的，所有制定优先级的原则也必须要以业务为导向，但是也需要从技术实现需要的角度来考虑，把技术上要求先实现的功能做为高优先级。这样就可以清晰的理解需要开发的功能和它们实现的优先级，从而引导我们对系统架构的定义，系统架构定义实际上定义了软件开发、运行的平台，软件模块和接口的结构。最后，根据可行性研究阶段的开发框架计划和业务区定义可以制定出开发计划，这个开发计划应该包含功能建模阶段和设计编程阶段的开发策略、测试策略和配置管理计划。
  功能建模阶段主要是深入分析业务区定义的功能并进行细化，在分析模型的基础上构建软件模块，将创建的原型交付用户评审，经过用户评审后进一步充实和改进，这样经过不断迭代，原型逐渐演化成可工作的软件。在功能建模阶段，还会产生以下产物：
  1、带有优先级的功能：随着业务的细化，业务研究阶段定义的优先级需要调整，从而保证本次迭代中包含用户最需要的核心功能。
  2、功能性原型的评审文档：用户每次对原型评审时提出的改进建议都需要被记录下来，并需要根据这些评审结果对业务定义、建模进行修正。
  3、非功能性需求：在功能建模阶段将非功能需要也需要记录下来。（但是，这里我就有一个问题一直比较困惑，因为在前期建模阶段，主要注重了对业务流程的分析建模，和对高优先级需求的原型实现，倡导快速实现、交付用户评审，因此，这个过程一直注重功能性需求，对于性能方面关注不多，因为无法从全局考虑、并更深入的考虑 到整个系统的性能瓶颈，特别是前期架构设计若存在缺陷将导致后期出现性能隐患，这是很难解决的；另外，若前期迭代功能与后期迭代关联功能存在性能制约，也存在一定风险。因此，我觉得在这一阶段，进行建模时也必须要考虑到各种可能的性能需求的技术实现，并且也需要制定优先级，在不同的迭代中处理必要的性能需求。）