|
软件工程
软件工程（英語：software engineering[1]），是软件开发领域里对工程方法的系统应用。 1968年秋季，NATO（北約）的科技委員會召集了近50名一流的編程人員、計算機科學家和工業界巨頭，討論和制定擺脫“軟體危機”的對策。在那次會議上第一次提出了軟體工程（software engineering）這個概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。其后的几十年里，各种有关软件工程的技术、思想、方法和概念不断被提出，软件工程逐步发展为一门独立的科学。 1993年，电气电子工程师学会（IEEE）给出了一个更加综合的定义："将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中"。此后，IEEE多次给出软件工程的定义。 在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、網頁、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，提高人们的工作效率，同时提升了生活质量。 软件工程师是对应用软件创造软件的人们的统称，软件工程师按照所处的领域不同可以分为系统分析师、系统架构师、前端和后端工程師、程序员、测试工程师、用户界面设计師等等。各种软件工程师人们俗称程序员。 名稱由來與定義軟體危機1970年代和1980年代的軟體危機。在那个时代，許多軟體最后都得到了一个悲惨的结局，软件项目开发时间大大超出了规划的时间表。一些项目导致了財產的流失，甚至某些软件导致了人员伤亡。同时软件开发人员也发现軟體开发的难度越来越大。在軟體工程界被大量引用的案例是Therac-25的意外：在1985年六月到1987年一月之間，六個已知的醫療事故來自於Therac-25錯誤地超過劑量，導致患者死亡或嚴重輻射灼傷[2]。 由來鑒於軟體開發時所遭遇困境，北大西洋公約組織（NATO）在1968年舉辦了首次軟體工程學術會議[3]，並於會中提出「軟體工程」來界定軟體開發所需相關知識，並建議「軟體開發應該是類似工程的活動」。軟體工程自1968年正式提出至今，這段時間累積了大量的研究成果，廣泛地進行大量的技術實踐，藉由學術界和產業界的共同努力，軟體工程正逐漸發展成為一門專業學科。 定義
包括：
軟體工程的核心知識（SWEBOK）ACM與IEEE Computer Society聯合修定的SWEBOK[14]（Software Engineering Body of Knowledge）提到，軟體工程領域中的核心知識包括：
软件工程与计算机科学软件的开发到底是一门科学还是一门工程，这是一个被争论了很久的问题。实际上，软件开发兼有两者的特点。但是这并不意味着它们可以被互相混淆。很多人认为软件工程基于计算机科学和信息科学就如传统意义上的工程学之于物理和化学一样。在美国，大约40%的软件工程师具有计算机科学的学位。在世界其他地方，这个比例也差不多。他们并不一定会每天使用计算机科学方面的知识，但是他们每天都会使用软件工程方面的知识。
例如彼得·麦克布林（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）和模板。 分支學科相關學科系統工程系统工程師主要處理系統的整體需求和設計，包括硬體與人力問題。 参考文献
参见外部链接（中文） （英文）
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
.gif){kind=small}
