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

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

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

  　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、需求不清楚或不确定