软件工程

软件工程（英語：），是软件开发领域里对工程方法的系统应用。

商用軟體工程範例
软件开发
核心行动
范式与模式
方法论与框架
支持行为
实践
工具
标准与知识体系

1968年秋季，NATO（北約）的科技委員會召集了近50名一流的編程人員、計算機科學家和工業界巨頭，討論和制定擺脫“軟體危機”的對策。在那次會議上第一次提出了軟體工程（software engineering）這個概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。其后的几十年里，各种有关软件工程的技术、思想、方法和概念不断被提出，软件工程逐步发展为一门独立的科学。

1993年，电气电子工程师学会（IEEE）给出了一个更加综合的定义："将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中"。此后，IEEE多次给出软件工程的定义。

在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、網頁、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，提高人们的工作效率，同时提升了生活质量。

软件工程师是对应用软件创造软件的人们的统称，软件工程师按照所处的领域不同可以分为系统分析师、系统架构师、前端和后端工程師、程序员、测试工程师、用户界面设计師等等。各种软件工程师人们俗称程序员。

名稱由來與定義

軟體工程包括兩種構面：軟體開發技術和軟體專案管理。[1]

  1. 軟體開發技術：軟體開發方法學、軟體工具和軟體工程環境。[1]
  2. 軟體專案管理：軟體度量、項目估算、進度控制、人員組織、配置管理、項目計畫等。[1]

軟體危機
条目：软件危机

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%的软件工程师具有计算机科学的学位。在世界其他地方，这个比例也差不多。他们并不一定会每天使用计算机科学方面的知识，但是他们每天都会使用软件工程方面的知识。

軟體工程與電腦科學的差別[15]
軟體工程 電腦科學
目標 在時間、資源、人員這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. . 勤益科技大學. [2015-02-24]. （原始内容存档于2021-01-23） （中文（臺灣））. 寫程式的難度愈來愈低，因為程式語言越來越高階，API 越來越多，開發工具越來越好用，寫程式的門檻自然就大大地降低了。想要開發出有價值的中大型系統，軟體工程就很重要了，以蓋房子來說，你可以隨便找一兩個工人用磚或木材來蓋一棟矮房，但是如果想蓋一百多層樓的101大樓，你非得有良好的工程規劃不可，軟體不也是如此？程式設計師名片上的頭銜都是工程師，雖然和建築工程師、機械工程師... 一樣都被稱為工程師，但比較起來，軟體產業的工程師卻是最不工程導向的。
  2. . [2005-06-05]. （原始内容存档于2011-06-11）.
  3. . [2011-02-25]. （原始内容存档于2021-04-18）.
  4. F. L. Bauer, NATO Software Engineering Conference, 1968.
  5. IEEE標準電腦字典，610.12，1990
  6. I. Sommerville, Software Engineering, 7th ed.:Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2004.
  7. S. R. Schach, Software Engineering: Asken Associates Pacific Palisades, CA, USA, 1990.
  8. B. W. Boehm, Software Engineering Economics: Prentice Hall PTR Upper Saddle River, NJ, USA, 1981.
  9. R. Fairley, Software Engineering Concepts: McGraw-Hill, Inc. New York, NY, USA, 1985.
  10. C. Ghezzi, M. Jazayeri, and D. Mandrioli, Fundamentals of Software Engineering, 2nd ed.: Prentice Hall, 2002.
  11. The Free On-Line Dictionary of Computing, http://foldoc.org/ （页面存档备份，存于）
  12. S. A. Conger, The New Software Engineering: Course Technology Press United States, 1993.
  13. S. L. Pfleeger, Software Engineering: the Production of Quality , 2nd.: Macmillan Publishing Co., Inc. Indianapolis, IN, USA, 1991.
  14. . Computer.org. 2004-02-06 [2016-04-28]. （原始内容存档于2016-05-09）.
  15. P. McBreen, Software Craftmanship: The New Imperative: Addsion-Wesley Professional, 2001.
  16. C. Jones Programmer Productivity: McGraw-Hill, Inc. New York, NY, USA, 1985
  17. Chaos Report, The Standish Group, 2003.
  18. 布魯克斯原文：「我認為軟體困難的部份是在建立規格、設計，並驗證其構思，而不是在表達和測試其實作」

参见
維基學院中的相關研究或學習資源：软件工程

外部链接

（中文）

（英文）


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.