軟體工程（Software Engineering）

文章目錄

•  

 摘要

電腦軟體在人類社會中發揮著越來越重要的作用。但是軟體技術的發展始終沒有擺脫“軟體危機”的陰影。本文著重從科學技術的方法論的角度討論了軟體工程的方法論特性：軟體工程的思想方法和設計原則；軟體工程作為技術技術方法所具有的實踐性、社會性和複雜性及其對策；軟體過程及其相關模型。

關鍵詞

方法論 軟體危機 軟體工程 軟體過程

本文1. 軟體技術方法論的重要性

近年來，電腦科學在硬體研製，軟體開發，網路通訊等分支學科和應用領域中迅速發展，電腦的應用已經滲透到人類社會的各個行業、領域、甚至千家萬戶的生活之中。隨著電腦技術的發展和電腦應用的普及，資訊社會、網路時代離我們越來越近，電腦技術在人類社會中發揮著越來越重要的作用。美國未來學家尼葛洛龐帝在其《數字化生存》一書中曾經預言，“計算不再只和電腦有關，它決定我們的生存”

由於以電腦為基礎的系統在數量、複雜程度、應用方面的增長，對無處不在的電腦軟體提出了更高的要求：更廣，以解決層出不窮的應用問題；更精，以安全可靠地完成各項任務；更簡便，以適應千家萬戶的使用普及。要達到這一目標，僅依靠的現有的思想方法是不夠的。

當前，國際幾大軟體公司已經壟斷了軟體技術的重要領域。我國軟體業要走自主創新之路，就必須掌握軟體開發的核心技術，即軟體開發的思路和方法，從而根據我國的發展需要開發有自主智慧財產權的創新軟體。軟體工程的研究是當前電腦科學的熱點領域，新的理論與實踐的成果不斷湧現。利用這些知識，學習應用、加以創新，是中國軟體產業趕超世界水平的機遇和途徑。

在軟體技術的發展道路中，方法論起著決定性的作用。正如maozedong曾經說過的：“我們的任務是過河，但是沒有橋或沒有船就不能過。不解決橋和船的問題，過河就是一句空話。不解決方案問題，任務也只是瞎說一頓。”軟體技術人員有必要站在哲學的高度、從方法論的角度，重新審視軟體開發過程中各個環節，深刻體會軟體工程和方法論的聯絡，從而改進和發展的現有的軟體工程技術，消化吸收先進的思想、方法和技術，提高軟體的品質和生產率，以適應現實世界對軟體產業新的要求。本文著重從科學技術的方法論的角度，討論了軟體工程的問題、思想、方法和新技術。

2. “軟體危機”和軟體工程

雖然未來學家們向我們展示了資訊時代的一幅美好的前景，但理想與現實之間畢竟存在著巨大的差距。電腦硬體技術遵循著“莫爾定律”加速地發展，然而軟體技術的進步一直相對緩慢，差距的增大、問題的積累形成了日益尖銳的矛盾，這就導致了“軟體危機”。

“軟體危機”的問題歸結起來有以下幾個方面：

軟體項目的規模和複雜性越來越大，由於缺乏系統有效方法，現有的開發知識、經驗和相關資料難以積累、複用，軟體系統開發的重複過程浪費了大量的人力、物力、財力和時間。

軟體開發工作缺乏有效分析手段和設計方法，計劃難以制定，經費預算常常超出，進度計劃無法遵循，開發完工的期限一再拖延。

由於通常軟體需求在開發的初期階段不夠明確、或是不能得到確切的表達，開發工作開始後，軟體人員和使用者又未能及時有效溝通，造成開發中後期需求與現實間的矛盾的集中暴露。

開發過程沒有統一的、公認的方法和技術規範，設計和實現過程的資料很不完整，使得軟體很難維護。

缺乏有效評估標準，未能在測試階段充分做好檢測工作，提交的軟體品質差，在運行中暴露出大量的問題。

“軟體危機”最突出的例子就是美國IBM公司在1963年到1966年開發的IBM360的作業系統。這一項目花了大量的人力物力，得到的軟體品質卻是非常糟糕的。根據統計，它的每個新的版本都是從前一版本找出1000多個程式錯誤而修正的結果。 “正像一隻逃亡的野獸落到泥潭中做垂死的掙紮，越是掙紮，陷得越深。最後無法逃脫滅頂的災難，……，程式設計工作正像這樣一個泥潭，……，一批批程式員被迫在泥潭中拚命掙紮，……，誰也沒有料到問題竟會陷入這樣的困境……”曆史的教訓告訴我們，沒有正確的方法，優秀的團隊和先進的技術並不能保證項目的成功。

為瞭解決“軟體危機”，許多電腦和軟體科學家參照技術過程的一般模式提出了軟體生存期概念（Life cycle）及其瀑布模型（Waterfall Model）。電腦軟體的生存周期描述了軟體孕育、誕生、成長、成熟、衰亡的生存過程：

制定計劃：確定要開發軟體系統的總目標，給出它的功能、效能、可靠性以及介面等方面的要求；研究完成該項軟體任務的可行性，探討解決問題的可能方案；制定完成開發工作單位的實施計劃，連同可行性研究報告，提交管理部門審查。

需求分析：對待開發軟體提出的需求進行分析並給出詳細的定義。編寫出軟體需求說明書及初步的使用者手冊，提交管理機構評審。

軟體設計：把已確定了的各項需求轉換成一個相應的體繫結構。進而對每個模組要完成的工作進行具體的描述。編寫設計說明書，提交評審。

程式編製：把軟體設計轉換成電腦可以接受的程式碼。

軟體測試：在設計測試案例的基礎上檢驗軟體的各個組成部分。

運行維護：已交付的軟體投入正式使用，並在運行過程中進行適當的維護。

由於引入了軟體工程的思想，把其它工程技術研究和開發領域中行之有效知識和方法運用到軟體開發工作中來，提出了按工程化的原則和方法組織軟體開發工作的解決思路和具體方法。軟體工程在一定程度上緩解了“軟體危機” 。但美國軟體學家F.Brooks在其論文中指出，人們至今尚未找到象神話中能夠制服“狼人”（軟體危機的本質問題）的銀彈，雖然問題得到緩解，但危機並沒有消除。

3. 軟體工程的方法論

在近年的研究中，軟體工程進一步發展出軟體過程的概念，軟體工程需要研究“如何做”的軟體方法，也要研究支撐的軟體工具和軟體環境，軟體過程則是研究如何綜合軟體方法和軟體工具。為了更好地發展和改進軟體工程技術，我們有必要從方法論的各個角度分析軟體工程的方法、工具和過程，從而有的放矢地改進軟體工程中各個過程的思想、方法、模式和規則。

a. 軟體工程的發展性

和其他技術方法一樣，軟體技術經曆了由簡單到複雜，由低級到進階，由以經驗為基礎到以科學為基礎的曆史過程。工程技術人員自覺或不自覺地實踐著這一轉化。回顧這段發展曆史，能給予對軟體技術的本質特性的把握一些有益的啟示，有助於推動軟體技術的發展和進步。

軟體技術的發展階段可以分為以下三個階段：程式設計階段，約為50至60年代；程式系統階段，約為60至70年代；軟體工程階段，約為70年代以後。幾十年來最根本的變化體現在觀念轉變中：程式從按個人意圖創造的“藝術品”轉變為能被廣大使用者接受的工程化產品；軟體從滿足自己的需要的自給自足的生產方式轉變到要在市場中流通以滿足廣大使用者的需要；軟體工作的範圍從只考慮程式的編寫擴充到涉及整個軟體生存周期。

隨著軟體技術，尤其是物件導向技術（OO）的發展，軟體工程提出了以下新的思想方法和設計原則：

抽象：抽取事物最基本的特性和行為，忽略非基本的細節。採用分層次抽象，自頂向下、逐層細化的辦法控制軟體開發過程的複雜性。

資訊隱蔽：將模組設計成“黑箱”，實現的細節隱藏在模組內部，不讓模組的使用者直接存取，使用與實現分離的原則。

模組化：通過對象、類等模組化手段實現資訊隱蔽和抽象，有助於表示複雜的系統。

局部化：在一個物理模組內集中邏輯上相互關聯的電腦資源，保證模組之間具有鬆散的耦合，模組內部具有較強的內聚。這有助於控制解的複雜性。

確定性：軟體開發過程中所有概念的表達應是確定的、無歧義性的、規範的。

一致性：整個軟體系統（包括程式、文檔和資料）的各個模組應使用一致的概念、符號和術語。

完備性：軟體系統不丟失任何重要成分，可以完全實現系統所要求功能的程度。為了保證系統的完備性，在軟體過程中需要嚴格的技術評審。

可驗證性：開發大型的軟體系統需要對系統自頂向下、逐層分解。系統分解應遵循系統易於檢查、測試、評審的原則，以確保系統的正確性。

軟體技術的實踐經驗告訴我們，分解是解決複雜問題的有效途徑。軟體問題的分解一般都體現出整體和部分的加性和方式 “一個複合體能夠通過把原來分離的要素集合攏來的方法一步一步的建立起來；反之，複合體的特徵能夠完全分解為各個分離要素的特徵”。所以在遵循上述設計原則下的問題分解能達到較好的效果。

軟體技術的發展曆史還啟示我們，沒有一成不變的方法，沒有絕對適用的開發模式，隨著軟體技術的研究和發展，必然存在著新的、更實用的分析模型、設計思想和開發技術。

b. 軟體工程的技術性

目前對軟體這一名詞公認的看法是：“軟體是電腦系統中與硬體相互依存的另一部分，它是包括程式，資料及其相關文檔的完整集合。其中，程式是按事先設計的功能和效能要求執行的指令序列；資料是使程式能正常操縱資訊的資料結構；文檔是與程式開發，維護和使用有關的圖文材料。”。軟體的定義包含了目前對軟體技術外延的理解：所有的技術手段、途徑和行為方式都是在程式、資料和文檔的集合上的可操作的規則或模式。從方法論的角度分析軟體問題，就必須考慮軟體各要素作為技術方法所具有的特性。

實踐性：軟體工程的方法必須包含嚴格意義上的實踐操作規則或模式，而不是限於理論和空談。“符號是深入到現實背後的自然實在裡去的方法的一個必不可少的部分”。軟體工程必須採用合適的符號體系，八十年代末以來，隨著物件導向技術成為研究的熱點，出現了幾十種支援軟體開發的物件導向方法。整合模組化語言UML（Unified Modeling Language）結合了Booch, OMT 和Jacobson等方法的優點，統一了符號體系，並從其它的方法和工程實踐中吸收了許多經過實際檢驗的概念和技術，成為對象管理集團（OMG）物件導向方法的標準。

社會性：軟體工程的方法要關注社會因素，考慮機構、體制及管理方式等問題，甚至涉及到人的觀念和人們的心理。針對這一領域，美國卡耐基-梅隆大學軟體工程研究所（SEI）提出了軟體機構的能力成熟度等級模型CMM，CMM共分五級：初始級、可重複級、以定義級、已管理級、最佳化級。CMM從人員、機構、體制及管理等眾多角度為軟體機構定義了可操作的分級實施和評估標準。

複雜性：軟體本身是複雜的，軟體的複雜性可能來自它所反映的實際問題的複雜性，也可能來自程式邏輯結構的複雜性。軟體工程的方法要考慮到如何綜合應用領域的知識，如何?領域工程。

c. 軟體工程的系統性

由於現在使用的電腦的理論基礎是圖靈於1937年提出的圖靈機模型和相應的馮-諾依曼體繫結構。圖靈機的想法是把問題轉化為一步一步按規則執行的機械求解過程，各種電腦語言也不過都是這種思想下的某種形式語言。因此軟體開發的過程實質上就是程式員們對客觀世界問題域的形式化的過程。程式員們先建立問題的電腦語言表達，最後進行計算獲得結果。由於對馮-諾依曼電腦的實現過程（順序執行）和人們認識表達過程（不斷反覆，逐步深化）間存在巨大鴻溝，加上程式員把目光都集中在如何?、如何編程上。認識的偏頗和思維的慣性導致導致對軟體工程過程支援不足。例如，傳統的瀑布模型以項目的階段評審和文檔控製為手段對整個開發過程進行指導，但缺乏靈活性，沒有考慮到項目的評估和演化。

作為一種工程設計，必須對整個軟體工程過程（Software Engineering Process）採用系統方法考慮其全過程。借鑒系統論“戴明迴圈法”的思路，軟體工程過程包含四種基本的過程活動以及軟體生存期模型：

P (Plan) ：軟體規格說明。規定軟體的功能及其啟動並執行限制；

D (Do) ：軟體開發。產生滿足規格說明的軟體；

C (Check) ：軟體確認。確認軟體能夠完成客戶提出的要求；

A (Action) ：軟體演化。為滿足客戶的變更要求，軟體必須在使用的過程中演化。

演化模型：考慮到項目開發的初始階段人們對軟體的需求認識常常不夠清晰，因而使得開發項目難以一次成功，出現返工再開發在所難免。因此，可以先做實驗開發，探索可行性，弄清軟體需求；然後在此基礎上獲得較為滿意的軟體產品。通常把第一次得到的實驗性產品稱為“原型”。

螺旋模型：對於複雜的大型軟體，開發一個原型往往達不到要求。螺旋模型將瀑布模型與演化模型結合起來，並且加入兩種模型均忽略了的風險分析。螺旋模型沿著“戴明迴圈法”的迴圈螺線旋轉，沿螺線自內向外每旋轉一圈便開發出更為完善的一個新的軟體版本。

噴泉模型：噴泉模型對軟體複用和生存周期中多項開發活動的整合提供了支援，主要支援物件導向的開發方法。系統某個部分常常重複工作多次，相關功能在每次迭代中隨之加入演化的系統。在開發活動，即分析、設計和編碼之間不存在明顯的邊界。

智能模型：基於知識的軟體開發模型，它綜合了上述若干模型，並把專家系統結合在一起。該模型應用基於規則的系統，採用歸約和推理機制，協助軟體人員完成開發工作，並使維護在系統規格說明一級進行。

演化模型，螺旋模型、噴泉模型、智能模型的進步之處在雩都考慮了人們認識表達過程的反覆特性，借鑒了系統論的系統方法，較好地支援了項目的評估和演化，並針對應用的特點組織了軟體生存期的各個環節。

參考: http://it.icxo.com/htmlnews/2004/08/03/282654.htm