軟件工程
| 軟件開發 |
|---|
| 核心行動 |
| 範式與模式 |
| 方法論與框架 |
| 支援行為 |
| 實踐 |
| 工具 |
| 標準與知識體系 |
軟件工程（英語：software engineering[1]），是軟件開發領域裏對工程方法的系統應用。
1968年秋季，NATO（北約）的科技委員會召集了近50名一流的編程人員、電腦科學家和工業界巨頭，討論和制定擺脫「軟件危機」的對策。在那次會議上第一次提出了軟件工程（software engineering）這個概念，研究和應用如何以系統性的、規範化的、可定量的程序化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。它涉及到程式語言、資料庫、軟件開發工具、系統平台、標準、設計模式等方面。其後的幾十年裏，各種有關軟件工程的技術、思想、方法和概念不斷被提出，軟件工程逐步發展為一門獨立的科學。
1993年，電氣電子工程師學會（IEEE）給出了一個更加綜合的定義："將系統化的、規範的、可度量的方法用於軟件的開發、執行和維護的過程，即將工程化應用於軟件開發中"。此後，IEEE多次給出軟件工程的定義。
在現代社會中，軟件應用於多個方面。典型的軟件比如有電子郵件、嵌入式系統、人機介面、辦公套件、作業系統、網頁、編譯器、資料庫、遊戲等。同時，各個行業幾乎都有電腦軟件的應用，比如工業、農業、銀行、航空、政府部門等。這些應用促進了經濟和社會的發展，提高人們的工作效率，同時提升了生活質素。
軟件工程師是對應用軟件創造軟件的人們的統稱，軟件工程師按照所處的領域不同可以分為系統分析師、系統架構師、前端和後端工程師、程式設計師、測試工程師、用戶介面設計師等等。各種軟件工程師人們俗稱程式設計師。
名稱由來與定義
[編輯]軟件危機
[編輯]1970年代和1980年代的軟件危機。在那個時代，許多軟件最後都得到了一個悲慘的結局，軟件專案開發時間大大超出了規劃的時間表。一些專案導致了財產的流失，甚至某些軟件導致了人員傷亡。同時軟件開發人員也發現軟件開發的難度越來越大。在軟件工程界被大量參照的案例是Therac-25的意外：在1985年六月到1987年一月之間，六個已知的醫療事故來自於Therac-25錯誤地超過劑量，導致患者死亡或嚴重輻射灼傷[2]。
由來
[編輯]鑒於軟件開發時所遭遇困境，北大西洋公約組織（NATO）在1968年舉辦了首次軟件工程學術會議[3]，並於會中提出「軟件工程」來界定軟件開發所需相關知識，並建議「軟件開發應該是類似工程的活動」。軟件工程自1968年正式提出至今，這段時間累積了大量的研究成果，廣泛地進行大量的技術實踐，藉由學術界和產業界的共同努力，軟件工程正逐漸發展成為一門專業學科。
定義
[編輯]關於軟件工程的定義，在GB/T11457-2006《訊息技術 軟件工程術語》中將其定義為"應用電腦科學理論和技術以及工程管理原則和方法，按預算和進度，實現滿足用戶要求的軟件產品的定義、開發、和維護的工程或進行研究的學科"。
包括：
- 創立與使用健全的工程原則，以便經濟地獲得可靠且高效率的軟件。[4]
- 應用系統化，遵從原則，可被計量的方法來發展、操作及維護軟件；也就是把工程應用到軟件上。[5]
- 與開發、管理及更新軟件產品有關的理論、方法及工具。[6]
- 一種知識或學科，目標是生產質素良好、準時交貨、符合預算，並滿足用戶所需的軟件。[7]
- 實際應用科學知識在設計、建構電腦程式，與相伴而來所產生的檔案，以及後續的操作和維護上。[8]
- 使用與系統化生產和維護軟件產品有關之技術與管理的知識，使軟件開發與修改可在有限的時間與費用下進行。[9]
- 建造由工程師團隊所開發之大型軟件系統有關的知識學科。[10]
- 對軟件分析、設計、實施及維護的一種系統化方法。[11]
- 系統化地應用工具和技術於開發以電腦為主的應用。[12]
- 軟件工程是關於設計和開發優質軟件。[13]
軟件工程的核心知識（SWEBOK）
[編輯]ACM與IEEE Computer Society聯合修定的SWEBOK[14]（Software Engineering Body of Knowledge）提到，軟件工程領域中的核心知識包括：
- 軟件需求（Software requirements）
- 軟件設計（Software design）
- 軟件建構（Software construction）
- 軟件測試（Software test）
- 軟件維護與更新（Software maintenance）
- 軟件構型管理（Software Configuration Management, SCM）
- 軟件工程管理（Software Engineering Management）
- 軟件開發過程（Software Development Process）
- 軟件工程工具與方法（Software Engineering Tools and methods）
- 軟件質素（Software Quality）
軟件工程與電腦科學
[編輯]軟件的開發到底是一門科學還是一門工程，這是一個被爭論了很久的問題。實際上，軟件開發兼有兩者的特點。但是這並不意味着它們可以被互相混淆。很多人認為軟件工程基於電腦科學和資訊科學就如傳統意義上的工程學之於物理和化學一樣。在美國，大約40%的軟件工程師具有電腦科學的學位。在世界其他地方，這個比例也差不多。他們並不一定會每天使用電腦科學方面的知識，但是他們每天都會使用軟件工程方面的知識。
| 軟件工程 | 電腦科學 | |
|---|---|---|
| 目標 | 在時間、資源、人員這3個主要限制條件下構建滿足用戶需求的軟件系統。 | 探索正確的計算和建模方法，從而改進計算方法本身。 |
| 產品 | 軟件（比如辦公套件和編譯器）。 | 演算法（比如希爾排序法）和抽象的問題（比如哲學家進餐問題）。 |
| 進度與時間表 | 軟件專案都有特定的進度與時間表 | 研究專案一般不具有設置的進度與時間表 |
| 關注點 | 軟件工程關注如何為用戶實現價值。 | 軟件理論關注的是軟件本身運行的原理，比如時間複雜度，空間複雜度，和演算法的正確性。 |
| 變化程度 | 隨着技術和用戶需求的不斷變化，軟件開發人員必須時刻調整自己的開發以適應當前的需求。同時軟件工程本身也處於不斷的發展中。 | 對於某一種特定問題的正確解決方法將永遠不會改變。 |
| 需要的其他知識 | 相關領域的知識。 | 數學。 |
| 著名的探索者和教育家 | 巴里·勃姆，戴維·帕納斯，佛瑞德·布魯克斯。 | 艾茲赫爾·戴克斯特拉，高德納，羅伯特·塔揚，彼得·斯萊特，艾倫·圖靈，姚期智。 |
| 著名的實踐者 | 約翰·巴科斯，丹·布里克林，添·柏納斯-李，林納斯·托瓦茲，理查德·馬修·斯托曼。 | 無。 |
例如彼得·麥克布林（Peter McBreen）認為，軟件工程意味着更高程度的嚴謹性與經過驗證的流程，並不適合現階段各類型的軟件開發。麥克布林在著作《Software Craftsmanship: The New Imperative》提出了所謂「craftsmanship」的說法，認為現階段軟件開發成功的關鍵因素，是開發者的技能，而不是「manufacturing」軟件的流程。
軟件工程的現況
[編輯]Capers Jones曾對美國軟件組織的績效做過評估，所得到結論是：軟件工程的專業分工不足，是造成質素低落、時程延誤、預算超支的最關鍵因素。[16]
2003年，The Standish Group年度報告指出，在他們調查的13522個專案中，有66％的軟件專案失敗、82％超出時程、48％推出時缺乏必需的功能，總計約550億美元浪費在不良的計劃、預算或軟件估算上。[17]
沒有銀彈與人月神話
[編輯]在1986年，IBM大型電腦之父佛瑞德·布魯克斯發表了他的著名論文《沒有銀彈》，在這篇著名的論文中他斷言：「在10年內無法找到解決軟件危機的靈丹妙藥」。從軟件危機被提出以來。人們一直在尋找解決它的方法。於是一系列的方法被提出並且加以應用。比如結構化程式設計，面向對象的開發，CMM，UML等等。佛瑞德·布魯克斯著名作品還有《人月神話》。
布魯克斯在《人月神話：軟件專案管理之道（The Mythical Man-Month）》提到，將沒有靈丹妙藥（silver bullet）可以一蹴而就，開發軟件的困難是內生的，只能漸進式的改善。整體環境沒有改變以前，唯一可能的解，是依靠人的素質，培養優秀的工程師。[18]
軟件工程與電腦程式設計
[編輯]軟件工程存在於各種應用中，存在於軟件開發的各個方面。而程式設計通常包含了程式設計和編碼的反覆迭代的過程，它是軟件開發的一個階段。
軟件工程力圖對軟件專案的各個方面作出指導，從軟件的可行性分析直到軟件完成以後的維護工作。軟件工程認為軟件開發與各種市場活動密切相關。比如軟件的銷售，用戶培訓，與之相關的軟件和硬件安裝等。軟件工程的方法學認為一個獨立的程式設計師不應當脫離團隊而進行開發，同時程式的編寫不能夠脫離軟件的需求，設計，以及客戶的利益。
軟件工程的發展是電腦程式設計工業化的體現。
軟件開發過程
[編輯]軟件開發過程是隨着開發技術的演化而隨之改進的。從早期的瀑布式（Waterfall）的開發模型到後來出現的螺旋式的迭代（Spiral）開發，以致最近開始興起的敏捷軟件開發（Agile），他們展示出了在不同的時代軟件產業對於開發過程的不同的認識，以及對於不同類型專案的理解方法。
注意區分軟件開發過程和軟件流程改進之間的重要區別。諸如像ISO 15504, ISO 9000, CMM, CMMI這樣的名詞闡述的是一些軟件流程改進框架，他們提供了一系列的標準和策略來指導軟件組織如何提升軟件開發過程的質素、軟件組織的能力，而不是給出具體的開發過程的定義。
方法學
[編輯]軟件工程的方法有很多方面的意義。包括專案管理，分析，設計，程式的編寫，測試和質素控制。
軟件設計方法可以區別為重量級的方法和輕量級的方法。重量級的方法中產生大量的正式文件。
著名的重量級開發方法包括ISO 9000，CMM，和統一軟件開發過程（RUP）。
輕量級的開發過程沒有對大量正式文件的要求。著名的輕量級開發方法包括極限編程（XP）和敏捷過程（Agile Processes）。
根據《新方法學》這篇文章的說法，重量級方法呈現的是一種「防禦型」的姿態。在應用「重量級方法」的軟件組織中，由於軟件專案經理不參與或者很少參與程式設計，無法從細節上把握專案進度，因而會對專案產生「恐懼感」，不得不要求程式設計師不斷撰寫很多「軟件開發文件」。而輕量級方法則呈現「進攻型」的姿態，這一點從XP方法特別強調的四個準則—「溝通、簡單、反饋和勇氣」上有所體現。目前有一些人認為，「重量級方法」適合於大型的軟件團隊（數十人以上）使用，而「輕量級方法」適合小型的軟件團隊（幾人、十幾人）使用。當然，關於重量級方法和輕量級方法的優劣存在很多爭論，而各種方法也在不斷進化中。
一些方法論者認為人們在開發中應當嚴格遵循並且實施這些方法。但是一些人並不具有實施這些方法的條件。實際上，採用何種方法開發軟件取決於很多因素，同時受到環境的制約。
軟件工程的發展方向
[編輯]「敏捷開發」（Agile Development）被認為是軟件工程的一個重要的發展。它強調軟件開發應當是能夠對未來可能出現的變化和不確定性作出全面反應的。
敏捷開發被認為是一種「輕量級」的方法。在輕量級方法中最負盛名的應該是「極限編程」（Extreme Programming，簡稱為XP）。而與輕量級方法相對應的是「重量級方法」的存在。重量級方法強調以開發過程為中心，而不是以人為中心。重量級方法的例子比如CMM/PSP/TSP。
面向方面的程式設計（Aspect Oriented Programming，簡稱AOP）被認為是近年來軟件工程的另外一個重要發展。這裏的方面指的是完成一個功能的對象和函數的集合。在這一方面相關的內容有泛型編程（Generic Programming）和模板。
分支學科
[編輯]相關學科
[編輯]系統工程
[編輯]系統工程師主要處理系統的整體需求和設計，包括硬件與人力問題。
參考文獻
[編輯]- ^ 1.0 1.1 1.2 1.3 軟體工程(Software Engineering;SE). 勤益科技大學. [2015-02-24]. （原始內容存檔於2021-01-23） （中文（臺灣））.
寫程式的難度愈來愈低，因為程式語言越來越高階，API 越來越多，開發工具越來越好用，寫程式的門檻自然就大大地降低了。想要開發出有價值的中大型系統，軟件工程就很重要了，以蓋房子來說，你可以隨便找一兩個工人用磚或木材來蓋一棟矮房，但是如果想蓋一百多層樓的101大樓，你非得有良好的工程規劃不可，軟件不也是如此？程式設計師名片上的頭銜都是工程師，雖然和建築工程師、機械工程師... 一樣都被稱為工程師，但比較起來，軟件產業的工程師卻是最不工程導向的。
- ^ An Investigation of the Therac-25 Accidents. [2005-06-05]. （原始內容存檔於2011-06-11）.
- ^ 存档副本. [2011-02-25]. （原始內容存檔於2021-04-18）.
- ^ F. L. Bauer, NATO Software Engineering Conference, 1968.
- ^ IEEE標準電腦字典，610.12，1990
- ^ I. Sommerville, Software Engineering, 7th ed.:Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2004.
- ^ S. R. Schach, Software Engineering: Asken Associates Pacific Palisades, CA, USA, 1990.
- ^ B. W. Boehm, Software Engineering Economics: Prentice Hall PTR Upper Saddle River, NJ, USA, 1981.
- ^ R. Fairley, Software Engineering Concepts: McGraw-Hill, Inc. New York, NY, USA, 1985.
- ^ C. Ghezzi, M. Jazayeri, and D. Mandrioli, Fundamentals of Software Engineering, 2nd ed.: Prentice Hall, 2002.
- ^ The Free On-Line Dictionary of Computing, http://foldoc.org/ （頁面存檔備份，存於互聯網檔案館）
- ^ S. A. Conger, The New Software Engineering: Course Technology Press United States, 1993.
- ^ S. L. Pfleeger, Software Engineering: the Production of Quality , 2nd.: Macmillan Publishing Co., Inc. Indianapolis, IN, USA, 1991.
- ^ index • IEEE Computer Society. Computer.org. 2004-02-06 [2016-04-28]. （原始內容存檔於2016-05-09）.
- ^ P. McBreen, Software Craftmanship: The New Imperative: Addsion-Wesley Professional, 2001.
- ^ C. Jones Programmer Productivity: McGraw-Hill, Inc. New York, NY, USA, 1985
- ^ Chaos Report, The Standish Group, 2003.
- ^ 布魯克斯原文：「我認為軟件困難的部份是在建立規格、設計，並驗證其構思，而不是在表達和測試其實作」
參見
[編輯]
.gif){kind=small}
外部連結
[編輯]（中文）
（英文）
- https://web.archive.org/web/20091022052322/http://www.computer.org/portal/web/swebok
- http://www.abet.org/ （頁面存檔備份，存於互聯網檔案館）
- http://www.computer.org/certification/ （頁面存檔備份，存於互聯網檔案館）
- http://systemsguide.com/GuildSite/TDM/certification.html[失效連結]
| 領域 | |||||||
|---|---|---|---|---|---|---|---|
| 概念 | |||||||
| 導向 | |||||||
| 模型 |
| ||||||
| 軟件 工程師 | |||||||
| 相關領域 | |||||||
| 分支領域 | |
|---|---|
| 過程 | |
| 概念 | |
| 工具 | |
| 相關領域 | |
