關鍵字：uml 有一點大家可以達成共識的就是，如果一個象Windows這樣的操作系統，不進行全面的規劃，不采用軟件工程的思想和方法，是絕對搞不出來的。
Windows的成功不在于它在進程管理和調度，文件系統、內存管理、界面設計等方面有多少成功的創新，它的成功最大的一點就是把所有的技術能夠合理的整合起來，并集中到一個Window操作系統特有的框架結構中去。
更為重要的是，Windows的每一項技術創新都能夠有效的整合到Windows框架中去，比如COM、XML等技術，通過ActiveX、DCOM等技術使Windows從桌面操作系統發展成為一個基于網絡的操作系統。
OLE2技術把整個Office中相關的軟件進行了有效的整合，顯然，這里我們可以把Office的設計和WPS的設計進行比較，客觀的講，WPS對中國用戶來說實在也是一個很好的產品。但是從整個系統設計概念上來講，Office顯然要比WPS高一個層次，它能夠把WORD，EXCEL，POWERPOINT，ACCESS有效的整合在一起，使我們所有辦公相關的文檔、圖表、數據庫、演示變成了一個一體化的東西。而且通過宏調用，用戶可以自己定制用戶界面并編制適當的模板，單是這個二次開發功能就不是WPS現在所能及項背的，當然限于當前用戶的水平還很少有人使用二次開發的功能。
從微軟產品系列可以看到軟件工程的作用，微軟的所有產品都有一個整體的框架結構，比如Office軟件，通過OLE技術進行有效的通訊和聯系。比如Visual系列開發工具，提供了相似的開發界面使用戶學會一種開發工具以后能夠很容易的學習其他的開發工具。比如SQL SERVER和ACCESS，盡管它們適用的范圍不同，但是它們表現給用戶的界面，特別是在查詢和分析上表現了高度的一致性。
更值得一提的是，因為設計結構的合理性，因為在開發前期作了很多分析和調研，考慮了擴展性和伸縮性，微軟的系列產品能夠很快的利用新的技術并采用統一的結構形式表現出來。比如當網絡成為計算機發展的主流的時候，幾乎微軟所有的工具都能夠快速的支持基于網絡的開發和應用。
相比之下，我們國內很多公司的產品很少具有連續性，往往是新的一個產品完全重起爐灶，和老的產品沒有半點關系。這就是我們在設計產品的時候，沒有很好的進行抽象和概念、邏輯設計，造成的結果是從舊的產品中提取不出一些有用的、共性的東西為后來的產品所使用。
當然，很多開發人員從心里也承認一個大的系統確實需要軟件工程的依托，但是一個小的工程項目是否就可以倉促上馬呢？答案是否定的。所謂麻雀碎小，五臟俱全。無論是大項目、還是小項目。它們作為一個項目，都需要有一個需求分析、系統結構建立、設計、編碼、測試等階段。這是任何一個項目都不可缺少的。
往往可以看到很多大公司的IT部門的人員都在不停的作各種各樣的報表，當各個部門提出一種新類型的報表的時候，就從數據庫中提取相應的數據并畫出業務人員所需要的樣式結構，很少是提供了一個通用的模板，當然提供高層API接口進行這種操作的就更少了。這樣不可避免的使開發人員陷入一些瑣碎的報表編制工作。而造成這個局面的很重要的一個原因就是沒有在系統開發的前期進行很好的調研、需求分析和系統體系結構的設計。
這里就我們開發過的一些小型軟件項目來談一些開發的總結和體會，一般來說，小型軟件項目功能比較單一，而且模塊與模塊之間的銜接不是很多，同時對開發周期要求比較短。
小項目雖然看起來比較簡單，所以很多開發人員容易犯一些錯誤，記得我們在開發一個基于Internet的有償服務系統的時候，有三個開發人員：一個負責前端界面的編寫，一個負責數據通訊協議和實現（基于TCP基礎上的應用協議），一個負責對數據庫數據的查詢、整理和提取。我們在開發的時候沒有認真地進行項目實際前途和工作量的估計。沒有認真地估計項目難度，比如對于通訊中多用戶并發訪問時的多線程問題和緩存處理問題，用戶批量請求處理的實現復雜度問題等等。三個人之間的接口也是在開發中休息的時候，口頭定義一下。結果發現有不嚴密的地方(比如在通訊服務器端是用VC編寫的，開發人員是通過stream來傳送數據的，客戶端是用Delphi編寫，在接收數據的時候發現數據不準確，后來研究發現VC利用CSocket在傳送數據流的時候對數據進行了自己定義的格式化，結果服務器端數據發送模塊只好重寫)，而且其中關于一個接口雙方的理解不同，然后又返工重新修改。最后到系統基本完成的時候沒有一份較正式的文檔。然后因為有人畢業離開這個項目，然后他編寫的模塊需要升級，新的接收的人不得不花很多時間去閱讀他的源代碼。
所以在開發小項目的時候也必須要建立合理的模式：而所謂合理的模式就是軟件工程告訴我們的在開發一個項目的時候所需要的五步曲：獲取需求、需求分析、設計、編碼、測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
