在第二个版本的实现中，重新实现了DTD，加入了大量的关键字同时也消除了verbose，大量的缩小了XML大小，从4000多行减低到900多行。不仅减低了内存使用，提高执行效率;也提高了开发效率，基本只要一天就可以完成一个映射文件。同时对BA部门和ST部门的反应也快了。
案例B：脚本的问题。产品在web层提供了脚本支持，出于方便开发的目的。但是没有对脚本的环境限制，脚本可以做系统程序的大部分工作。导致开发人员偷懒，在web层混入了大量业务逻辑代码。最终造成业务逻辑分散而不可控制。
2) 组织结构对技术，开发效率和应变能力的影响。
案例A.部门的分工问题。开发部门根据不同的职责，分成A，B和C等数个小组。大部分开发中互不相干。但也有时候，需要跨组的支持，比如B要实现某个需求，需要A在一定条件在记录一个或多个信息。因为每个开发人员各自负责一部分工作，导致跨组沟通的困难。同时由于整个开发部采取任务绩效，有时间压力，加上只是一个小的要求。于是在A人员的同意下，B人员直接在A代码中写入业务逻辑。每次都是这样的小改动，不断的发展后，代码开发变凌乱。
案例B.开发的历史问题，当某个开发人员写下的代码，有是问题的，接手开发人员由于文档不全以及没有测试用例，不愿意承担变化的代价，选择小修小补，这个小修小补有可能和有问题的代码混杂，导致更大的代码。
3) 过程对开发效率和应变能力，以及组织的影响
案例A.过程的问题。开发部门的上下游部门BA部门和ST部门的合作关系。ST部门的绩效考核,考核基于发现错误的数量，导致ST为了完成任务，提出一些非正常性要求。PM部门出于部门的方便通常提出一些实现难度比较大要求。开发部门本身又存在时间压力，导致一些需求的实现本应在低一层的代码中实现的，却在高层用蹩足的方式实现。
案例B.帮助系统的问题。帮助系统一开始采用一个个单独分散的静态页面。出于性能的考虑和部门负责考虑。帮助系统不断改进中，过程缺乏组织性，文件的命名规则随意，存储位置随意，造成了管理的混乱。直接的后果是页面的入口混乱和各自引用关系混乱。
在帮助系统的第二版，从静态页面转成动态页面。采取统一分类和命名规则，并统一了入口。同时采取分级管理引用关系，适度冗余。虽然减低了运行性能。但提高了开发效率和可维护性。
文章来源于领测软件测试网 https://www.ltesting.net/
