在第二個版本的實現中，重新實現了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.幫助系統的問題。幫助系統一開始采用一個個單獨分散的靜態頁面。出于性能的考慮和部門負責考慮。幫助系統不斷改進中，過程缺乏組織性，文件的命名規則隨意，存儲位置隨意，造成了管理的混亂。直接的后果是頁面的入口混亂和各自引用關系混亂。
在幫助系統的第二版，從靜態頁面轉成動態頁面。采取統一分類和命名規則，并統一了入口。同時采取分級管理引用關系，適度冗余。雖然減低了運行性能。但提高了開發效率和可維護性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
