您有关于问题域、需求、解决方案的体系结构以及解决方案的单独组件、大量相互关联的模型。
所有规范文档引用模型，并且被模型引用。
所有的设计和代码都派生自模型。
所有的评估和计划表都给予模型的元素。
所有的测试计划和测试案例都派生自模型。
所有的终端用户文档都根据模型而定制。
所有项目认为产物的状态反应在模型中。
记着在一年多前的，那个时候我所在的公司来了一位新技术总监，他所给老板的承诺是6个月完成13个模块的ERP系统，他所用的办法完全是符合模型驱动开发的思想，虽然他所使用的技术不先进，不新颖，而且对于开发他了解的也不多，但是他的模型驱动和过程管理的确赢得了我对他的尊敬，也让我学到了很多东西。
他大概用去了6个月中一半的时间在做分析，生成了大量的模型文档及甲方最终用户的确认审核，给每一位开发人员都带来了信心，真正的信心（4个开发），后来的开发过程就显得无比的简单和顺畅，因为大多的问题已经在开发之前得到了答复和解决，那时是我第一次体验模型驱动开发的魅力。
还有很实际的面向对象程序设计和我认为很朴实的CSLA.Net框架。
当然模型驱动开发想要推广开还是非常有困难的，当然这也是我总结的缺点
1.对于模型本身是一种沟通工具，而现在很多开发人员，产品经理，领域专家，公司负责及甲方对这些模型并不熟悉，理解的程度都不一样，所以这种模型的方式往往会成为沟通的障碍
2.所以想推广，首先也是，必须是在技术部门统一这个思想，这就需要培训，很多公司不理解这有多重要。
3.他的成功还得益于配合，总监并不去负责开发，完全不，所以必须有一个非常理解此套开发方式的开发经理带领开发，否则他也无法达到那么好的效果，要知道，如果我按这个路子去实施开发，没有人协助，开发管理两个都做，不仅自己很累，结果还会很糟糕。
4.在开发的过程中有一个缺点就是模型过于冗余，太多，每个功能都要做整套图形我认为可以适当的根据情况调整一下，因为很多图形都时序一致，只是接口不同，做出来不一定看。
5.我的确真真正正的感受到了，透过模型去分析上面所列出这些过程的好处，但也要看到他的缺点，因地制宜的去做。
所以当有一天你在一家公司准备实施这套方案的时候，一定要有老板对你的信任，耐心和你自己的自信，在此之后我再没有遇到一家公司有比这更强大的模型驱动过程管理方式，印象很深刻，100%的微软技术。
