Software Engineering

軟體工程(Software Engineering，簡稱為SE)是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及到程序設計語言，資料庫，軟體開發工具，系統平台，標準，設計模式等方面。

在現代社會中，軟體應用於多個方面。典型的軟體比如有電子郵件，嵌入式系統，人機界面，辦公套件，操作系統，編譯器，資料庫，遊戲等。同時，各個行業幾乎都有計算機軟體的應用，比如工業，農業，銀行，航空，政府部門等。這些應用促進了經濟和社會的發展，使得人們的工作更加高效，同時提高了生活質量。

軟體工程師是對應用軟體創造軟體的人們的統稱，軟體工程師按照所處的領域不同可以分為系統分析員，軟體設計師，系統架構師，程序員，測試員等等。人們也常常用程序員來泛指各種軟體工程師。

軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。

(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。

(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。

(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。

概念：應需而生

軟體工程是一類工程。工程是將理論和知識應用於實踐的科學。就軟體工程而言，它借鑒了傳統工程的原則和方法，以求高效地開發高質量軟體。其中應用了計算機科學、數學和管理科學。計算機科學和數學用於構造模型與演演算法，工程科學用於制定規範、設計范型、評估成本及確定權衡，管理科學用於計劃、資源、質量和成本的管理。

軟體工程這一概念，主要是針對20世紀60年代“軟體危機”而提出的。它首次出現在1968年NATO（北大西洋公約組織）會議上。自這一概念提出以來，圍繞軟體項目，開展了有關開發模型、方法以及支持工具的研究。其主要成果有：提出了瀑布模型，開發了一些結構化程序設計語言（例如PASCAL語言，Ada語言）、結構化方法等。並且圍繞項目管理提出了費用估算、文檔複審等方法和工具。綜觀60年代末至80年代初，其主要特徵是，前期著重研究系統實現技術，後期開始強調開發管理和軟體質量。

70年代初，自“軟體工廠”這一概念提出以來，主要圍繞軟體過程以及軟體復用，開展了有關軟體生產技術和軟體生產管理的研究與實踐。其主要成果有：提出了應用廣泛的面向對象語言以及相關的面向對象方法，大力開展了計算機輔助軟體工程的研究與實踐。尤其是近幾年來，針對軟體復用及軟體生產，軟體構件技術以及軟體質量控制技術、質量保證技術得到了廣泛的應用。目前各個軟體企業都十分重視資質認證，並想通過這些工作進行企業管理和技術的提升。軟體工程所涉及的要素可概括如下：

根據這一框架，可以看出：軟體工程涉及了軟體工程的目標、軟體工程原則和軟體工程活動。

目標：我的眼裡只有“產品”

軟體工程的主要目標是：生產具有正確性、可用性以及開銷合宜的產品。正確性意指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜性是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多問題有待解決，它們形成了對過程、過程模型及工程方法選取的約束。

軟體工程活動是“生產一個最終滿足需求且達到工程目標的軟體產品所需要的步驟”。主要包括需求、設計、實現、確認以及支持等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體體系結構，包括子系統、模塊以及相關層次的說明、每一模塊介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。支持活動包括修改和完善。伴隨以上活動，還有管理過程、支持過程、培訓過程等。

框架：四項基本原則是基石

軟體工程圍繞工程設計、工程支持以及工程管理，提出了以下四項基本原則：

第一，選取適宜開發范型。該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其他因素之間是相互制約、相互影響的，經常需要權衡。因此，必須認識需求定義的易變性，採用適宜的開發范型予以控制，以保證軟體產品滿足用戶的要求。

第二，採用合適的設計方法。在軟體設計中，通常要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。

第三，提供高質量的工程支持。“工欲善其事，必先利其器”。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。

第四，重視開發過程的管理。軟體工程的管理，直接影響可用資源的有效利用，生產滿足目標的軟體產品，提高軟體組織的生產能力等問題。因此，僅當軟體過程得以有效管理時，才能實現有效的軟體工程。

這一軟體工程框架告訴我們，軟體工程的目標是可用性、正確性和合算性；實施一個軟體工程要選取適宜的開發范型，要採用合適的設計方法，要提供高質量的工程支撐，要實行開發過程的有效管理；軟體工程活動主要包括需求、設計、實現、確認和支持等活動，每一活動可根據特定的軟體工程，採用合適的開發范型、設計方法、支持過程以及過程管理。根據軟體工程這一框架，軟體工程學科的研究內容主要包括：軟體開發范型、軟體開發方法、軟體過程、軟體工具、軟體開發環境、計算機輔助軟體工程(CASE) 及軟體經濟學等。

作用：高效開發高質量軟體

自從軟體工程概念提出以來，經過30多年的研究與實踐，雖然“軟體危機”沒得到徹底解??進步。尤其應該指出的是，自80年代中期，美國工業界和政府部門開始認識到，在軟體開發中，最關鍵的問題是軟體開發組織不能很好地定義和管理其軟體過程，從而使一些好的開發方法和技術都起不到所期望的作用。也就是說，在沒有很好定義和管理軟體過程的軟體開發中，開發組織不可能在好的軟體方法和工具中獲益。

根據調查，中國的現狀幾乎和美國10多年前的情況一樣，軟體開發過程沒有明確規定，文檔不完整，也不規範，軟體項目的成功往往歸功於軟體開發組的一些傑出個人或小組的努力。這種依賴於個別人員上的成功並不能為全組織的軟體生產率和質量的提高奠定有效的基礎，只有通過建立全組織的過程改善，採用嚴格的軟體工程方法和管理，並且堅持不懈地付諸實踐，才能取得全組織的軟體過程能力的不斷提高。

這一事實告訴我們，只有堅持軟體工程的四條基本原則，既重視軟體技術的應用，又重視軟體工程的支持和管理，並在實踐中貫徹實施，才能高效地開發出高質量的軟體。

自從1968年提出“軟體工程”這一術語以來，研究軟體工程的專家學者們陸續 提出了100多條關於軟體工程的準則或信條。美國著名的軟體工程專家 Boehm 綜合這些專家的意見，並總結了TRW公司多年的開發軟體的經驗，於1983年提出了軟體工程的七條基本原理。

Boehm 認為，著七條原理是確保軟體產品質量和開發效率的原理的最小集合。

它們是相互獨立的，是缺一不可的最小集合；同時，它們又是相當完備的。

人們當然不能用數學方法嚴格證明它們是一個完備的集合，但是可以證明，在此之前已經提出的100多條軟體工程準則都可以有這七條原理的任意組合蘊含或派生。

下面簡要介紹軟體工程的七條原理：

1 用分階段的生命周期計劃嚴格管理

這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗項目是由於計劃不周而造成的。在軟體開發與維護的漫長生命周期中，需要完成許多性質各異的工作。這條原理意味著，應該把軟體生命周期分成若干階段，並相應制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發和維護進行管理。 Boehm 認為，在整個軟體生命周期中應指定並嚴格執行6類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產品控制計劃、驗證計劃、運行維護計劃。

2 堅持進行階段評審

統計結果顯示：大部分錯誤是在編碼之前造成的，大約佔63%; <2> 錯誤發現的越晚，改正它要付出的代價就越大，要差2到3個數量級。因此，軟體的質量保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便儘早發現錯誤。

3 實行嚴格的產品控制

開發人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要採用科學的產品控制技術來順應這種要求。也就是要採用變動控制，又叫基準配置管理。當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟體的一致性。

4 採納現代程序設計技術

從六、七時年代的結構化軟體開發技術，到最近的面向對象技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大似氣力。採用先進的技術即可以提高軟體開發的效率，又可以減少軟體維護的成本。

5 結果應能清楚地審查

軟體是一種看不見、摸不著的邏輯產品。軟體開發小組的工作進展情況可見性差，難於評價和管理。為更好地進行管理，應根據軟體開發的總目標及完成期限，盡量明確地規定開發小組的責任和產品標準，從而使所得到的標準能清楚地審查。

6 開發小組的人員應少而精

開發人員的素質和數量是影響軟體質量和開發效率的重要因素，應該少而精。

這一條基於兩點原因：高素質開發人員的效率比低素質開發人員的效率要高几倍到幾十倍，開發工作中犯的錯誤也要少的多；當開發小組為N人時，可能的通訊通道為N(N-1)/2, 可見隨著人數N的增大，通訊開銷將急劇增大。

7 承認不斷改進軟體工程實踐的必要性

遵從上述六條基本原理，就能夠較好地實現軟體的工程化生產。但是，它們只是對現有的經驗的總結和歸納，並不能保證趕上技術不斷前進發展的步伐。因此，Boehm提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條原理。根據這條原理，不僅要積極採納新的軟體開發技術，還要注意不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計。這些數據既可以用來評估新的 軟體技術的效果，也可以用來指明必須著重注意的問題和應該優先進行研究的工具和技術。

面向方面的編程（Aspect Oriented Programming，簡稱AOP）被認為是近年來軟體工程的另外一個重要發展。這裡的方面指的是完成一個功能的對象和函數的集合。在這一方面相關的內容有泛型編程（Generic Programming）和模板。

參考

胡崑山，《中國軟體產業發展現狀與人才需求》，2003年9月1日， http://software.ccidnet.com/pub/article/c372_a62973_p1.html

軟體工程的目標是提高軟體的質量與生產率，最終實現軟體的工業化生產。質量是軟體需求方最關心的問題，用戶即使不圖物美價廉，也要求個貨真價實。生產率是軟體供應方最關心的問題，老闆和員工都想用更少的時間掙更多的錢。質量與生產率之間有著內在的聯繫，高生產率必須以質量合格為前提。如果質量不合格，對供需雙方都是壞事情。從短期效益看，追求高質量會延長軟體開發時間並且增大費用，似乎降低了生產率。從長期效益看，高質量將保證軟體開發的全過程更加規範流暢，大大降低了軟體的維護代價，實質上是提高了生產率，同時可獲得很好的信譽。質量與生產率之間不存在根本的對立，好的軟體工程方法可以同時提高質量與生產率。

軟體供需雙方的代表能在餐桌上談笑風生，歸功於第一線開發人員的辛勤工作。質量與生產率的提高就指望程序員與程序經理。對開發人員而言，如果非得在質量與??生產率第二。這是因為：（1）質量直接體現在軟體的每段程序中，高質量自然是開發人員的技術追求，也是職業道德的要求。（2）高質量對所有的用戶都有價值，而高生產率只對開發方有意義。（3）如果一開始就追求高生產率，容易使人急功近利，留下隱患。寧可進度慢些，也要保證每個環節的質量，以圖長遠利益。

軟體的質量因素很多，如正確性，性能、可靠性、容錯性、易用性、靈活性、可擴充性、可理解性、可維護性等等。有些因素相互重疊，有些則相抵觸，真要提高質量可不容易啊！

軟體工程的主要環節有：人員管理、項目管理、可行性與需求分析、系統設計、程序設計、測試、維護等，如圖1.1所示。

軟體工程模型建議用一定的流程將各個環節連接起來，並可用規範的方式操作全過程，如同工廠的生產線。常見的軟體工程模型有：線性模型（圖1.2），漸增式模型（圖1.3），螺旋模型，快速原型模型，形式化描述模型等等【Pressmam 1999, Sommerville 1992】。

最早出現的軟體工程模型是線性模型（又稱瀑布模型）。線性模型太理想化，太單純，已不再適合現代的軟體開發模式，幾乎被業界拋棄。偶而被人提起，都屬於被貶對象，未被留一絲惋惜。但我們應該認識到，“線性”是人們最容易掌握並能熟練應用的思想方法。當人們碰到一個複雜的“非線性”問題時，總是千方百計地將其分解或轉化為一系列簡單的線性問題，然後逐個解決。一個軟體系統的整體可能是複雜的，而單個子程序總是簡單的，可以用線性的方式來實現，否則幹活就太累了。線性是一種簡潔，簡潔就是美。當我們領會了線性的精神，就不要再呆板地套用線性模型的外表，而應該用活它。例如漸增式模型實質就是分段的線性模型，如圖1.3所示。螺旋模型則是接連的彎曲了的線性模型。在其它模型中都能夠找到線性模型的影子。

套用固定的模型不是程序員的聰明之舉。比如“程序設計”與“測試”之間的關係，習慣上總以為程序設計在先，測試在後，如圖1.4（a）所示。而對於一些複雜的程序，將測試分為同步測試與總測試更有效，如圖1.4（b）所示。

不論是什麼軟體工程模型，總是少不了圖1.1中的各個環節。本書擗開具體的軟體工程模型，順序講述人員管理、項目管理、可行性與需求分析、系統設計、程序設計、測試，以及維護與再生工程。其中程序設計部分以C++/C語言為例。

軟體體系結構表示了一個軟體系統的高層結構，主要特點有：1）軟體系統結構是一個高層次上的抽象，它並不涉及具體的系統結構（比如B/S還是C/S），也不關心具體的實現。2）軟體體系結構必須支持系統所要求的功能，在設計軟體體系結構的時候，必須考慮系統的動態行為。3）在設計軟體體系結構的時候，必須考慮有現有系統的兼容性、安全性和可靠性。同時還要考慮系統以後的擴展性和伸縮性。所以有時候必須在多個不同方向的目標中進行決策。

當前已經有一些關於規範化軟體體系結構，比如：ISO的開放系統互聯模型、X Window系統等等。軟體系統的結構通常被定義為兩個部分：一個是計算部件。另一個就是部件之間的交互。如果把軟體系統看成一幅圖的話，計算部件就是其中的節點，而部件之間的交互就是節點之間的弧線。部件之間的連接可以被認為是一種連接器，比如過程調用、事件廣播、資料庫查詢等等。正確的體系結構設計是軟體系統成功的關鍵。

我們理解了軟體工程的重要性以後，我們沒有相應的工具，我們也很難很好的完成一個系統。在需求分析和設計階段，我們需要什麼樣的工具呢？

當然最好是基於UML的CASE工具。當前比較流行的就是Rose，它是一個很好的分析和建立對象和對象關係的工具。在具體編碼的時候，我們需要版本控制工具，MS的SourceSafe就是一個很好的版本管理工具和項目管理工具。具體的開發工具當然很多，但是如果你是一個對VC侵淫了多年的程序員，你一定會選擇它，因為它會讓你感到什麼是真正的面向對象的編程，而你在用VB，PowerBuilder，Delphi時很少會有同樣的感受。至於資料庫模式構建，我一向是採用Sybase的S-Design，更好的工具就不知道了。

另外需要注意的是，我們需要建立文檔編寫的若干模板，以便開發人員按照這個模板編寫規範的技術和說明文檔。幫助文檔可以用微軟的HTML Help Workshop(hhw.exe)製作，你也可以編譯成.chm格式，它打包了文本和圖形，只有一個文件，使用和分發比較方便。最後，如果開發人員不是集中在一個地方的話，最好建立一個郵件列表，開發人員可以通過郵件系統討論開發中的各項事宜。

國外大的軟體公司和機構一直在研究軟體開發方法這個概念性的東西，而且也提出了很多實際的開發方法，比如：生命周期法、原型化方法、面向對象方法等等。下面介紹幾種流行的開發方法：

1、結構化方法

結構化開發方法是由E.Yourdon 和 L.L.Constantine 提出的，即所謂的SASD 方 法，也可稱為面向功能的軟體開發方法或面向數據流的軟體開發方法。Yourdon方法是80年代 使用最廣泛的軟體開發方法。它首先用結構化分析（SA）對軟體進行需求分析，然後用結構化設計（SD）方法進行總體設計，最後是結構化編程（SP）。它給出了兩類典型的軟體結構（變換型和事務型）使軟體開發的成功率大大提高。

2、面向數據結構的軟體開發方法

jackson方法是最典型的面向數據結構的軟體開發方法，Jackson方法把問題分解為可由三種基本結構形式表示的各部分的層次結構。三種基本的結構形式就是順序、選擇和重複。三種數據結構可以進行組合，形成複雜的結構體系。這一方法從目標系統的輸入、輸出數據結構入手，導出程序框架結構，再補充其它細節，就可得到完整的程序結構圖。這一方法對輸入、輸出數據結構明確的中小型系統特別有效，如商業應用中的文件表格處理。該方法也可與其它方法結合，用於模塊的詳細設計。

3、面向問題的分析法

PAM（Problem Analysis Method）是80年代末由日立公司提出的一種軟體開發方法。它的基本思想是考慮到輸入、輸出數據結構，指導系統的分解，在系統分析指導下逐步綜 合。這一方法的具體步驟是：從輸入、輸出數據結構導出基本處理框；分析這些處理框之間的先後關係；按先後關係逐步綜合處理框，直到畫出整個系統的PAD圖。這一方法本質上是綜合的自底向上的方法，但在逐步綜合之前已進行了有目的的分解，這個目的就是充分考慮系統的輸入、輸出數據結構。PAM方法的另一個優點是使用PAD圖。這是一種二維樹形結構圖，是到目前為止最好的詳細設計表示方法之一。當然由於在輸入、輸出數據結構與整個系統之間同樣存在著鴻溝，這一方法仍只適用於中小型問題。

4、原型化方法

產生原型化方法的原因很多，主要隨著我們系統開發經驗的增多，我們也發現並非所有的需求都能夠預先定義而且反覆修改是不可避免的。當然能夠採用原型化方法是因為開發工具的快速發展，比如用VB，DELPHI等工具我們可以迅速的開發出一個可以讓用戶看的見、摸的著的系統框架，這樣，對於計算機不是很熟悉的用戶就可以根據這個樣板提出自己的需求。

開發原型化系統一般由以下幾個階段：

（1）確定用戶需求

（2）開發原始模型

（3）徵求用戶對初始原型的改進意見

（4）修改原型。

原型化開發比較適合於用戶需求不清、業務理論不確定、需求經常變化的情況。當系統規模不是很大也不太複雜時採用該方法是比較好的。

5、面向對象的軟體開發方法

當前計算機業界最流行的幾個單詞就是分散式、并行和面向對象這幾個術語。由此可以看到面向對象這個概念在當前計算機業界的地位。比如當前流行的兩大面向對象技術DCOM和CORBA就是例子。當然我們實際用到的還是面向對象的編程語言，比如C++。不可否認，面向對象技術是軟體技術的一次革命，在軟體開發史上具有里程碑的意義。

隨著OOP（面向對象編程）向OOD（面向對象設計）和OOA（面向對象分析）的發展，最終形成面向對象的軟體開發方法OMT (Object Modeling Technique）。這是一種自底向上和自頂向下相結合的方法，而且它以對象建模為基礎，從而不僅考慮了輸入、輸出數據結構，實際上也包含了所有對象的數據結構。所以OMT徹底實現了PAM沒有完全實現的目標。不僅如此，OO技術在需求分析、可維護性和可靠性這三個軟體開發的關鍵環節和質量指標上有了實質性的突破，基本地解決了在這些方面存在的嚴重問題。

綜上所述，面向對象系統採用了自底向上的歸納、自頂向下的分解的方法，它通過對對象模型的建立，能夠真正建立基於用戶的需求，而且系統的可維護性大大改善。當前業界關於面向對象建模的標準是UML（Unified Modeling Language）。

這裡我們需要談一下微軟的MSF（Microsoft Solutions Framework）的框架，它簡單的把系統設計分成三個階段：概念設計、邏輯設計和物理設計。概念設計階段就是從用戶的角度出發可以得到多少個對象，並且以對象為主體，畫出業務框架。邏輯設計階段就是對概念設計階段的對象進行再分析、細分、整合、刪除。並建立各個對象的方法屬性以及對象之間的關係。而物理設計實際上就是要確定我們實際需要的組件、服務和採用的框架結構、具體的編程語言等。MCF整個結構比較清楚是基於對象開發的一個比較好的可操作的框架系統。

6、可視化開發方法

其實可視化開發並不能單獨的作為一種開發方法，更加貼切的說可以認為它是一種輔助工具，比如用過SYBASE的S-Design的人都知道，用這個工具可以進行顯示的圖形化的資料庫模式的建立，並可以導入到不同的資料庫中去。當然用過S-Design的人不一定很多，但用過VB，DELPHI，C++ Builder等開發工具的人一定不少，實際上你就是在使用可視化開發工具。

當然，不可否認的是，你只是在編程這個環節上用了可視化，而不是在系統分析和系統設計這個高層次上用了可視化的方法。實際上，建立系統分析和系統設計的可視化工具是一個很好的賣點，國外有很多工具都致力於這方面產品的設計。比如Business Object就是一個非常好的資料庫可視化分析工具。

可視化開發使我們把注意力集中在業務邏輯和業務流程上，用戶界面可以用可視化工具方便的構成。通過操作界面元素，諸如菜單、按鈕、對話框、編輯框、單選框、複選框、列表框和滾動條等，由可視開發工具自動生成應用軟體。

作為軟體開發人員的一個通病是在項目初期的時候，就喜歡談論實現的細節，並且樂此不疲。我們更喜歡討論如何用靈活而簡短的代碼來實現一個特定的功能，而忽略了對整個系統架構的考慮。所以作為一個開發人員，尤其是一個有經驗的開發人員，應該把自己從代碼中解脫出來，更多的時候在我們的腦子裡甚至暫時要放棄去考慮如何實現的問題，而從項目或產品的總體去考慮一個軟體產品。

以下是我個人的一些經驗：

1．考慮整??分析人員，不僅要從技術的角度來考慮問題，而且還要從市場的角度去考慮問題。也就是說我們同時需要考慮我們產品的用戶群是誰，當我們產品投放到市場上的時候，是否具有生命力。比如即使我們採用最好的技術實現了一個單進程的操作系統，其市場前景也一定是不容樂觀的。

2．從用戶的角度來考慮問題。比如一些操作對於開發人員來講是非常顯而易見的問題。但是對於一般的用戶來說可能就非常難於掌握，也就是說，有時候，我們不得不在靈活性和易用性方面進行折中。另外，在功能實現上，我們也需要進行綜合考慮，儘管一些功能十分強大，但是如果用戶幾乎不怎麼使用它的話，就不一定在產品的第一版的時候就推出。從用戶的角度考慮，也就是說用戶認可的才是好的，並不是開發人員覺的好才好。

3．從技術的角度考慮問題。雖然技術絕對不是唯一重要的，但是技術一定是非常重要的，是成功的必要環節。在產品設計的時候，必須考慮採用先進的技術和先進的體系結構。比如，如果可以採用多線程進行程序中各個部分并行處理的話，就最好採用多線程處理。在Windows下開發的時候，能夠把功能封裝成一個單獨的COM構件就不作成一個簡單的DLL或者是以源代碼存在的函數庫或者是對象。比如能夠在B/S結構下運行並且不影響系統功能的話就不一定要在C/S下實現。

4．合理進行模塊的分割。從多層模型角度來講，一般系統可以分成用戶層、業務層和資料庫層三部分。當然每以部分都還可以進行細分。所以在系統實現設計的時候，盡量進行各個部分的分割並建立各個部分之間進行交互的標準。並且在實際開發的時候，確實有需要的話再進行重新調整。這樣就可以保證各個部分齊頭並進，開發人員也可以各施其職。

5．人員的組織和調度。這裡很重要的一點是到考慮人員的特長，有的人喜歡做界面，有的人喜歡做核心。如果有可能要根據人員的具體的情況進行具體的配置。同時要保證每一個開發人員在開發的時候首先完成需要和其他人員進行交互的部分，並且對自己的項目進度以及其他開發人員的進度有一個清晰的了解，保證不同部分的開發人員能夠經常進行交流。

6．開發過程中文檔的編寫。在開發過程中會碰到各種各樣的問題和困難，當然還有各種各樣的創意和新的思路。應該把這些東西都記錄下來並進行及時整理，對於困難和問題，如果不能短時間解決的，可以考慮採用其他的技術替代，並在事後做專門的研究。對於各種創意，可以根據進度計劃安排考慮是在本版本中實現還是在下一版本中實現。

7．充分考慮實施時可能遇到的問題。開發是一回事情，用戶真正能夠使用好它又是另外一回事情。比如在MIS系統開發中，最簡單的一個問題就是用戶如果數據輸入錯誤的時候，如何進行操作。在以流程方式工作的時候，如何讓用戶理解自己在流程中的位置和作用，如何讓用戶真正利用計算機進行協作也是成敗的關鍵。

以上是我個人的一點體會，實際上，作為一個軟體開發人員，我也喜歡看到問題就坐在計算機前面直接編碼，但是我確實認為軟體工程對於我們系統開發的指導作用是巨大的。作為軟體工程的擁戴者，下面我簡單結合自己的開發經歷介紹基於軟體工程的開發方法、編程規範和工具使用等方面的問題。

國外很多項目的開發都是基於一些圖形化的東西來做的，他們的目的是盡量少寫代碼甚至不寫代碼。代碼能夠通過圖形化的方式自動生成，這樣的一個好處就是如果用戶的需求變化或者業務邏輯發生變化，我們需要做的就是對圖形表示的調整，然後重新自動生成代碼，這也就是國外開發很注重對項目的概念和邏輯分析的原因。

他們的重點是把業務規則和需求用圖形化的方式表現出來，然後通過CASE工具自動生成代碼。所以當國人還在不停的開發一個又一個的MIS工具的時候，國外已經把很多精力放到了CASE工具的製作上。

我們很多公司人員忙著寫具體業務過程的相關代碼，而國外很多都把精力放到對不同應用，不同行業的模型的建立和共性的提取上。所以，他們做出來的東西就相對具有很強的靈活性和擴展性，而我們是用戶的需求稍微有一點變化，就要忙著改代碼，甚至改體系結構。

另外，因為他們注重模型的建立，所以在建立其他應用的時候，能夠借鑒原先的模型，在高層次上做調整和優化，同時能夠有效的提取原有系統中可以被使用的部分。所以我們應該從以代碼為核心的軟體開發模式轉化到以模型為中心的、基於CASE的開發上來。

關於協作與個人英雄主義

社會進步的一個很明顯的現象就是社會分工越來越細，軟體的開發也不例外。為什麼在軟體開發的今天已經不能出現象裘伯君這樣的軟體英雄的原因也在這裡，單憑個人之力，我們也許窮盡有生之年也開發不出象Windows這樣的操作系統。

因為，當前軟體行業的壁壘無非就是兩個，一個就是以技術創新取勝，你模仿的了其中的界面，但是你沒有辦法實現其中的核心功能。結果是你只能購買其技術核心，而你作一些邊角工作。不舉別的例子，比如VB這樣的開發工具，其核心部分是它和第三方提供的COM控制項或者是DLL函數庫，你所做的就是一個整合的工作。

第二個就是以細緻取勝，也就是說功能很多而且做的很精緻，即使技術本身不是很複雜，你真要想做出一個這樣的東西來沒有一兩年的工夫是不可能的。而真等你做出來了，它的新版本也早已經推出。真正能夠在市面上叫得想、經得起考驗得產品都是具有這兩方面的特點。

這兩方面的特點決定了你一個人絕對是不可能勝任的，也許你可以獨立的完成技術創新，但是你絕對不可能一個人實現所有這些紛繁複雜的功能。所以，這個時代需要創新的英雄，也更需要人與人之間的協作。

當今的軟體發展已經不是一個人可以包打天下的年代。軟體開發的管理、系統體系結構的設計、模塊之間的銜接、核心演演算法的實現、靈活界面的制定、軟體再開發介面的實現都需要專門的人來做。而把這些有效的集成顯然就需要有效的利用軟體工程的思想和方法。所以，真正的軟體英雄絕對不再是寫著別人看不懂代碼的程序員，而是整個體系結構的分析、設計、標準制定、協調人員。

有一點大家可以達成共識的就是，如果一個象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在傳送數據流的時候對數據進行了自己定義的格式化，結果伺服器端數據發送模塊只好重寫)，而且其中關於一個介面雙方的理解不同，然後又返工重新修改。最後到系統基本完成的時候沒有一份較正式的文檔。然後因為有人畢業離開這個項目，然後他編寫的模塊需要升級，新的接收的人不得不花很多時間去閱讀他的源代碼。

所以在開發小項目的時候也必須要建立合理的模式：而所謂合理的模式就是軟體工程告訴我們的在開發一個項目的時候所需要的五步曲：獲取需求、需求分析、設計、編碼、測試。

1．理解用戶真正的需求。在進入正式開發之前，必須先從用戶處獲取準確的需求。在這上面花費相當時間是很必要的。

我們軟體項目可以大致分為專用軟體和通用軟體兩大類。對於專用軟體，一般用戶對於軟體要完成哪些功能已經有了一個比較清楚的輪廓，而且往往在開發合同中已經大致地規定了。

但是，開發合同上規定的只是一個大概的框架，在進入開發之前必須與用戶進行比較具體的交流和討論，了解清楚用戶心目中的產品究竟是什麼樣子，這裡最好就採用原型化的方法作出一個簡單的框架給用戶看。

對於通用軟體，在開發之前必須做一定的市場調查工作，一方面是從經濟效益考慮，調查產品的潛在市場有多大，一方面是從技術的角度，了解清楚潛在用戶對軟體的各種技術上的要求，另一方面是確定我們軟體的定位，即我們軟體具體是為哪一些用戶群體服務的。然後對該群體用戶現有硬體配置，軟體配置，網路使用情況，資料庫使用情況，計算機熟悉程度做一定的調研，根據調查的統計結果決定即將開發的軟體的一些技術指標。

2．需求分析。需求分析需要做的事情有：高層構思、確立系統目標、劃分業務領域、現行業務分析、建立業務模型(Enterprise Model)、信息需求分析、用戶視圖規範化、數據元素標準化與一致性控制。

在了解用戶的需求之後，將需求用一種模型來表示，就是需求分析，一般我們可以面向對象的方法，通過分析用戶需求，用類、類之間的各種關係來表示整個系統。

為了討論軟體運行的流程，可以採用UML的Use Case圖。在系統分析的時候需要明確應用域（application domain）的範圍，然後明確我們系統需要做什麼。同時我們需要決定用什麼方法來完成需求的獲取，這在很大程度上影響了需求分析的做法。

例如可以採用Use Case來表示用戶需求，那麼從各種序列圖中選出相互交互的各個實體，就是一個個類。另外分析需要與設計過程相銜接。分析過程的內容是用對象和對象之間的關係來表示整個系統和系統的流程的，並不設計具體實現，如採用什麼編程語言，在什麼操作系統平台上運行等等。這些具體實現是在設計階段來完成的。

面向對象方法的優點是分析、設計、編碼過程表示法統一，能比較好的銜接。現在很多CASE工具並不區分分析和設計的階段。但是，這並不意味著開發就可以對分析和設計不加區分，如何用好輔助設計(case)工具還是開發人員的事情。

3．設計過程。設計階段的工作包括對分析模型進行必要的修改，同時可能需要對某些類結構做一些修改，確定用戶表示層(也就是通俗所說的界面定義)、用戶服務層、業務邏輯層、資料庫服務層和具體資料庫所需要做的工作。同時需要確定使用的體系結構（比如B/S還是C/S）和開發工具（如VB，VC，VI，C++ Builder，DELPHI，PowerBuiler等等）

4．編碼。進入編碼工作之後，依然可能會發現前面分析或設計階段的某些錯誤，這時應返回到前面的階段進行必要的修改。同時在編碼前規定編碼的風格並在開發過程中保持一致的風格。

5．測試。測試是系統投入使用前最關鍵的一個步驟。即使是小項目也應該嚴格地進行測試。就實際上就是一個把錯誤留給自己還是留給客戶的問題。

最後，我們知道軟體項目主要是由開發人員完成的，所以對人員的合理安排和配置也很重要，一般在開發過程中，需要有一位項目負責人，負責分析、設計和協調的工作。另外需要幾個程序員完成不同層的代碼（比如用戶服務層、業務邏輯層、資料庫服務層等等）。

同時需要有一個文檔整理人員隨時整理系統開發過程中相關的文檔。如果條件可能的話，要配置一個測試工程師，專門進行代碼的測試工作，當然如果條件不允許的話，也可以由開發人員交叉測試。這裡需要注意的是，對於項目負責人而言，協調幾個人的工作比自己完成一段編碼更重要。

由於協調上出了漏洞，可能導致很大的問題，所以項目負責人必須隨時監控各開發人員的工作，包括內容是否與要求發生偏差，進度是否滯后等等。同時必須給每個開發人員明確的任務書。具體開發時每個開發人員必須非常明確自己的任務，這些任務應該採用明確的文檔來表示。每個開發人員需要清楚自己所做的工作在整個系統中處於什麼地位，這樣就有可能會發現設計模型中的漏洞，避免了各人的代碼編寫完畢之後又要修改的後果。

很多國內搞計算機的專家都認為：國內的軟體研發過程，個人色彩比較濃。過分地依靠個人無法形成產業規模，而沒有規模就談不上產業化了。

不管怎麼樣，我們大家還是先要來看一看國內軟體廠商到底提供給我們多少有震撼力的軟體產品，從技術和利潤的角度講，軟體系統最核心的部分還是操作系統、編譯系統然後就是開發平台之類??、遊戲開發、企業應用、網站建設、殺毒、網路工具等等。

操作系統以中科院為中心，做了一個COSIX，這個本質上是一個UNIX系統，UNIX最初的源代碼是公開的，儘管COSIX是一個被稱為中國的操作系統並是UNIX系列的（IX就代表UNIX系列），但是其中到底有多少獨創的技術成分我們暫時還不知道，但有一點可以肯定，它現在的市場覆蓋率絕對不大，而且能否在上面運行各種各樣的編譯系統、資料庫、群件和應用系統可能還需要進一步測試。然後就是對硬體平台的支持也需要進一步完善。

然後就是轟轟烈烈的Linux系統，Linux是遵守GNU標準的操作系統，中國有很多家公司推出了自己的Linux並且還有漢化的Linux，這就有比較疑惑的一點，為什麼不在Linux上構架一個類似UNICODE這樣的東西，而只做漢化這麼本地化的產品呢？不知道是眼光還是市場的問題了。

MIS系統、財務軟體是中國軟體行業的重頭戲，它們徹底的暴露了中國軟體開發無序和重複低效勞動的一面。教育軟體在某一種層面上看就是電子題庫，當然也有優點，比如加入了多媒體教學（可視化程度不錯）和所謂寓教於樂的特點，但是從本質上說還是題庫。殺毒軟體據說是中國軟體的驕傲，由中國權威機構評測是達到了世界領先水平，但是好象還沒有得到國際權威機構的認可。遊戲軟體就不用提了，國內業界能夠流行的遊戲軟體成功的秘訣眾所周知，不是技術和創意，實在是歸功於我們悠久的歷史。字處理軟體和排版軟體客觀的說國內的也做的不錯，但是從系統的擴展性和體系結構上說和MS和Adobe相比，差距也放在那裡。其實這種現狀的原因很簡單，一個是我們缺少創新的能力，另一個就是我們欠缺軟體工程的概念，系統開發前期的需求分析、設計沒有做好或者做的不夠好。

當然，我們很少懷疑自己的技術能力，我們很多時候認為這是地理環境和經濟環境的原因造成了中國軟體業現在的局面。當然中國軟體開發人員絕對可以算是優秀的，但是想想我們軟體行業龍頭企業到底有多少有技術創新和專利技術呢？姑且不論這個，實際上把一個操作系統分解開來，比如文件系統、進程管理和調度、IO調度等等，也許我們可以實現其中某一塊的內容，但是如何把它們合理的整合起來絕對是一個涉及到軟體工程的問題。

作為一個開發人員，我們已經習慣了自己那一套編程模式，而且我們的這種習慣也不自覺的影響著新的開發人員。所以在頭腦中建立一個軟體工程的作用，從某種角度上講，要比會幾種開發語言、幾個編程技巧實在是重要的多。

舉一個例子來說，我們也許可以寫MFC中的幾個類或者是用自己的類擴展MFC，但是我們又有幾個人真正去認真分析和考慮MFC架構的設計和原理呢？捫心自問，我們又有多少人能夠設計出MFC這樣的框架系統呢？下面就我們的題目談一些相關的話題。

毋庸質疑的是，計算機的發展和人類的歷史相比甚至和其他很多科技產品相比都是非常短的，從第一台計算機的研製成功到現在也沒有百年的歷史，但是計算機及其相關技術的發展卻絕對可以說是最快的。拋開硬體的發展（硬體的發展基本上是按照摩爾定律來的，每18個月，機器的速度性能都要提高一倍），單從軟體的發展來說，從體系結構來講，我們經歷了從主機結構到文件伺服器結構，從客戶伺服器系統到基於Internet的伺服器瀏覽器結構的體系結構的變化。從編碼的角度來講，我們經歷了從最開始的機器代碼到彙編代碼，從高級程序語言到人工智慧語言，從專用的程序設計語言到通用的程序設計語言。從開發工具來講，我們經歷了從分離的開發工具（有代碼編輯器，中間代碼生成器和連接器）到集成的開發系統，從最簡單的單行命令式調試器到方便靈活的多功能的調試器。

但是，今天所有的軟體廠商和軟體開發人員依然會想起當年的黑人人權運動領袖馬丁？路德？金曾經說過的一句名言我有一個夢想。是的，所有的開發人員依然懷著夢想，希望能夠有一個萬能的系統開發的框架和方法，只要我們沿著這個框架，我們將能開發出適合所有領域的應用系統，於是，我們在念書的時候把這個希望投到了一門課上，這麼課就是軟體工程。但是當我們在學完這門課的時候，我們依然沒有找到這麼一個框架甚至連接近這麼一個框架的東西也沒有碰到。

不管我們認為軟體工程可能是多麼的虛無，但是所有學工科並且有邏輯頭腦的人都堅信理論對實踐的指導意義，因為有了愛因斯坦及其許多偉大的科學家關於能量和質量方面的理論以後，我們才造出了原子彈。但是，遺憾的是軟體工程並不是一個具體的理論，它更象一門抽象的科學。軟體工程是一種方法論，而不是一種具體的摸的著，看的見的產品。它告訴我們在設計一個系統的時候，我們需要進行可行性研究、計劃制訂、需求分析、系統設計、編碼、測試、維護等等。並且對這些過程中應該做什麼提出了一個指導性的東西。但是沒有任何專家和標準委員會保證只要按照這些標準，我們的系統肯定會順利完成。而且事實上，軟體開發針對的領域是如此之多並不沒有一種對所有領域適用的萬能框架。

不管認為軟體工程已經到了非常成熟的階段還是認為軟體工程依然是一個搞不懂的黑箱子，軟體工程確實已經經歷了三個不同的階段。第一個階段是軟體結構化生產階段，以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試為特徵。從80年代中期，軟體生產開始進入以過程為中心的第二階段，以提出過程成熟模型CMM、個體軟體過程PSP和群組軟體過程TSP為標誌。第三個階段就是以軟體過程、面向對象和構件重用三把斧頭出現的軟體工業化生產階段。

言歸正傳，我們還是回到我們的文章標題上來，我們在開發的時候是兵馬未動、糧草先行還是摸著石子過河。兵馬未動、糧草先行當然意味著我們在開發的時候先不忙著編寫代碼做程序，我們先要制訂一個關於開發的方法。這點就象元數據（metadata）的概念，元數據並不定義數據，它是對數據的說明，也就是通常所說的關於數據的數據。我們設計的時候也是這樣，定義開發的標準，如何進行開發、怎樣開發。摸著石子過河就意味著我們先不管什麼理論，方法，科學的問題，我們先動手做起來，如果做的也算成功的話，那就可以按照這種模式來，實際上，在任何事情的最初，我們都是這樣。從辨證唯物主義者的觀點來說，就是從實踐中來，然後升華到理論，再用理論來指導實踐。記得一個笑話說：外國人搞軟體工程是在一個黑屋子裡面抓黑貓，不過到現在還是沒有抓住，而中國人是在一個黑屋子裡面，而裡面連貓都沒有，然後有人說，我已經抓到貓了。這個笑話一方面是說明直到現在，軟體工程還是一個在繼續探索、發展的過程，另一個側面也說明中國搞軟體工程摸不著邊的局面。

實際上，不管有沒有軟體工程，不管是否存在一個萬能的框架系統，我們的應用系統還是要做，各種各樣的軟體還是要開發。說到底，軟體系統是因為有需求才存在的。有了應用域才有了軟體存在的意義。很多時候，我們可以看到國外有各種各樣的軟體和創新，而我們沒有，我們更多的是模仿和一些重複的功能相近的軟體的原因就是因為我們沒有這方面的需求，這也正解釋了為什麼ERP系統能在國外開展的很好，而在國內失敗多於成功的原因。一方面當然是因為我們的企業按照市場經濟發展的時間還不長，另一方面是我們的企業確實也沒有這方面的需求。

“敏捷開發”（Agile Development）被認為是軟體工程的一個重要的發展。它強調軟體開發應當是能夠對未來可能出現的變化和不確定性作出全面反應的。

敏捷開發被認為是一種“輕量級”的方法。在輕量級方法中最負盛名的應該是“極限編程”（Extreme Programming，簡稱為XP）。而與輕量級方法相對應的是“重量級方法”的存在。重量級方法強調以開發過程為中心，而不是以人為中心。重量級方法的例子比如CMM/PSP/TSP。