定義內涵
定義
軟體工程軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都 分別給出了自己認可的定義：
BarryBoehm：運用現代科學技術知識來設計並構造電腦程式及為開發、運行和維護這些程式所必需的相關檔案資料。
IEEE：在軟體工程術語彙編中的定義：軟體工程是：1.將系統化的、嚴格約束的、可量化的方法套用於軟體的開發、運行和維護，即將工程化套用於軟體；2.在1中所述方法的研究
FritzBauer：在NATO會議上給出的定義：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。
《計算機科學技術百科全書》：軟體工程是套用計算機科學、數學、邏輯學及管理科學等原理，開發軟體的工程。軟體工程借鑑傳統工程的原則、方法，以提高質量、降低成本和改進算法。其中，計算機科學、數學用於構建模型與算法，工程科學用於制定規範、設計范型(paradigm)、評估成本及確定權衡，管理科學用於計畫、資源、質量、成本等管理。
比較認可的一種定義認為：軟體工程是研究和套用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。
ISO 9000對軟體工程過程的定義是：軟體工程過程是輸入轉化為輸出的一組彼此相關的資源和活動。
其它定義：1．運行時，能夠提供所要求功能和性能的指令或電腦程式集合。2．程式能夠滿意地處理信息的數據結構。3．描述程式功能需求以及程式如何操作和使用所要求的文檔。以開發語言作為描述語言，可以認為：軟體=程式+數據+文檔。
內涵
一、軟體工程過程是指為獲得軟體產品，在軟體工具的支持下由軟體工程師完成的一系列軟體工程活動，包括以下四個方面：
1、P（Plan）——軟體規格說明。規定軟體的功能及其運行時的限制。
2、D（DO）——軟體開發。開發出滿足規格說明的軟體。
3、C（Check）——軟體確認。確認開發的軟體能夠滿足用戶的需求。
4、A（Action）——軟體演進。軟體在運行過程中不斷改進以滿足客戶新的需求。
二、從軟體開發的觀點看，它就是使用適當的資源（包括人員，軟硬體資源，時間等），為開發軟體進行的一組開發活動，在活動結束時輸入（即用戶的需求）轉化為輸出（最終符合用戶需求的軟體產品）。
三個階段：定義階段：可行性研究初步項目計畫、需求分析；開發階段：概要設計、詳細設計、實現、測試；運行和維護階段：運行、維護、廢棄
原則：1、抽象；2、信息隱蔽；3、模組化；4、局部化；5、確定性；6，一致性；7、完備性；8、可驗證性
基本內容
軟體工程原理、軟體工程過程、軟體工程方法、軟體工程模型、軟體工程管理、軟體工程度量、軟體工程環境、軟體工程套用、軟體工程開發使用。著名軟體工程專家B.Boehm綜合有關專家和學者的意見並總結了多年來開發軟體的經驗，於1983年在一篇論文中提出了軟體工程的七條基本原理：
（1）用分階段的生存周期計畫進行嚴格的管理。
（2）堅持進行階段評審。
（3）實行嚴格的產品控制。
（4）採用現代程式設計技術。
（5）軟體工程結果應能清楚地審查。
（6）開發小組的人員應該少而精。
（7）承認不斷改進軟體工程實踐的必要性。
發展過程
軟體是由電腦程式和程式設計的概念發展演化而來的，是在程式和程式設計發展到一定規模並且逐步商品化的過程中形成的。軟體開發經歷了程式設計階段、軟體設計階段和軟體工程階段的演變過程。
程式設計階段
程式設計階段出現在1946年～1955年。此階段的特點是：尚無軟體的概念，程式設計主要圍繞硬體進行開發，規模很小，工具簡單，無明確分工（開發者和用戶），程式設計追求節省空間和編程技巧，無文檔資料（除程式清單外），主要用於科學計算。
軟體設計階段
軟體工程軟體設計階段出現在1956年～1970年。此階段的特點是：硬體環境相對穩定，出現了“軟體作坊”的開發組 織形式。開始廣泛使用產品軟體（可購買），從而建立了軟體的概念。隨著計算機技術的發展和計算機套用的日益普及，軟體系統的規模越來越龐大，高級程式語言層出不窮，套用領域不斷拓寬，開發者和用戶有了明確的分工，社會對軟體的需求量劇增。但軟體開發技術沒有重大突破，軟體產品的質量不高，生產效率低下，從而導致了“軟體危機”的產生。
軟體工程階段
自1970年起，軟體開發進入了軟體工程階段。由於“軟體危機”的產生，迫使人們不得不研究、改變軟體開發的技術手段和管理方法。從此軟體產生進入了軟體工程時代。此階段的特點是：硬體已向巨型化、微型化、網路化和智慧型化四個方向發展，資料庫技術已成熟並廣泛套用，第三代、第四代語言出現；第一代軟體技術：結構化程式設計在數值計算領域取得優異成績；第二代軟體技術：軟體測試技術、方法、原理用於軟體生產過程；第三代軟體技術：處理需求定義技術用於軟體需求分析和描述。
未來
在Internet平台上進一步整合資源，形成巨型的、高效的、可信的虛擬環境，使所有資源能夠高效、可信地為所有用戶服務，成為軟體技術的研究熱點之一。
軟體工程領域的主要研究熱點是軟體復用和軟體構件技術，它們被視為是解決“軟體危機”的一條現實可行的途徑，是軟體工業化生產的必由之路。而且軟體工程會朝著開放性計算的方向發展，朝著可以確定行業基礎框架、指導行業發展和技術融合的“開放計算”。
目標
軟體工程的目標是：在給定成本、進度的前提下，開發出具有適用性、有效性、可修改性、可靠性、可理解性、可維護性、可重用性、可移植性、可追蹤性、可互操作性和滿足用戶需求的軟體產品。追求這些目標有助於提高軟體產品的質量和開發效率，減少維護的困難。
（1） 適用性：軟體在不同的系統約束條件下，使用戶需求得到滿足的難易程度。
（2） 有效性：軟體系統能最有效的利用計算機的時間和空間資源。各種軟體無不把系統的時/空開銷作為衡量軟體質量的一項重要技術指標。很多場合，在追求時間有效性和空間有效性時會發生矛盾，這時不得不犧牲時間有效性換取空間有效性或犧牲空間有效性換取時間有效性。時/空折衷是經常採用的技巧。
（3） 可修改性：允許對系統進行修改而不增加原系統的複雜性。它支持軟體的調試和維護，是一個難以達到的目標。
（4） 可靠性：能防止因概念、設計和結構等方面的不完善造成的軟體系統失效，具有挽回因操作不當造成軟體系統失效的能力。
（5） 可理解性：系統具有清晰的結構，能直接反映問題的需求。可理解性有助於控制系統軟體複雜性，並支持軟體的維護、移植或重用。
（6） 可維護性：軟體交付使用後，能夠對它進行修改，以改正潛伏的錯誤，改進性能和其它屬性，使軟體產品適應環境的變化等。軟體維護費用在軟體開發費用中占有很大的比重。可維護性是軟體工程中一項十分重要的目標。
（7） 可重用性：把概念或功能相對獨立的一個或一組相關模組定義為一個軟部件。可組裝在系統的任何位置，降低工作量。
（8） 可移植性：軟體從一個計算機系統或環境搬到另一個計算機系統或環境的難易程度。
（9） 可追蹤性：根據軟體需求對軟體設計、程式進行正向追蹤，或根據軟體設計、程式對軟體需求的逆向追蹤的能力。
（10） 可互操作性：多個軟體元素相互通信並協同完成任務的能力。
研究領域
軟體架構
軟體設計方法
軟體領域建模
軟體工程決策支持
軟體工程教育
軟體測試技術
自動化的軟體設計和合成
基於組件的軟體工程
計算機支持的協同工作
程式語言和軟體工程
計算機網路
信息與通信安全
計算機圖形學與人機互動
多媒體技術套用
人工智慧與識別
嵌入式軟體與套用
自動控制
分散式計算與格線計算
雲計算技術
存儲技術
資料庫技術研究
計算機輔助設計與套用技術
大數據分析與處理
原理
自從1968年提出“軟體工程”這一術語以來，研究軟體工程的專家學者們陸續提出了100多條關於軟體工程的準則或信條。美國著名的軟體工程專家巴利·玻姆（Barry Boehm）綜合這些專家的意見，並總結了美國天合公司（TRW）多年的開發軟體的經驗，於1983年提出了軟體工程的七條基本原理。
![軟體工程[學科]](/img/5/271/nBnauM3XwUTM4cjMyIjM5UjM2UTM1QDN5MjM5ADMwAjMwUzLyIzL2AzLt92YucmbvRWdo5Cd0FmLyE2LvoDc0RHa.jpg)
軟體工程[學科]玻姆認為，這七條原理是確保軟體產品質量和開發效率的原理的最小集合。它們是相互獨立的，是缺一不可的最小集合；同時，它們又是相當完備的。 人們當然不能用數學方法嚴格證明它們是一個完備的集合，但是可以證明，在此之前已經提出的100多條軟體工程準則都可以有這七條原理的任意組合蘊含或派生。
下面簡要介紹軟體工程的七條原理：
用分階段的生命周期計畫嚴格管理
這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗項目是由於計畫不周而造成的。在軟體開發與維護的漫長生命周期中，需要完成許多性質各異的工作。這條原理意味著，應該把軟體生命周期分成若干階段，並相應制定出切實可行的計畫，然後嚴格按照計畫對軟體的開發和維護進行管理。
玻姆認為，在整個軟體生命周期中應指定並嚴格執行6類計畫：
項目概要計畫、
里程碑計畫、
項目控制計畫、
產品控制計畫、
驗證計畫、
運行維護計畫。
堅持進行階段評審
統計結果顯示：大部分錯誤是在編碼之前造成的，大約占63%錯誤發現的越晚，改正它要付出的代價就越大，要差2到3個數量級。 因此，軟體的質量保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便儘早發現錯誤。
實行嚴格的產品控制
開發人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要採用科學的產品控制技術來順應這種要求。也就是要採用變動控制，又叫基準配置管理。當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟體的一致性。
採納現代程式設計技術
從六、七十年代的結構化軟體開發技術，到最近的面向對象技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大於氣力。採用先進的技術既可以提高軟體開發的效率，又可以減少軟體維護的成本。
結果應能清楚地審查
軟體是一種看不見、摸不著的邏輯產品。軟體開發小組的工作進展情況可見性差，難於評價和管理。為更好地進行管理，應根據軟體開發的總目標及完成期限，儘量明確地規定開發小組的責任和產品標準，從而使所得到的標準能清楚地審查。
開發小組的人員應少而精
開發人員的素質和數量是影響軟體質量和開發效率的重要因素，應該少而精。 這一條基於兩點原因：高素質開發人員的效率比低素質開發人員的效率要高几倍到幾十倍，開發工作中犯的錯誤也要少的多；當開發小組為N人時，可能的通信信道為N(N-1)/2, 可見隨著人數N的增大，通訊開銷將急劇增大。
承認不斷改進軟體工程實踐的必要性
遵從上述六條基本原理，就能夠較好地實現軟體的工程化生產。但是，它們只是對現有的經驗的總結和歸納，並不能保證趕上技術不斷前進發展的步伐。因此，玻姆提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條原理。根據這條原理，不僅要積極採納新的軟體開發技術，還要注意不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計。這些數據既可以用來評估新的軟體技術的效果，也可以用來指明必須著重注意的問題和應該優先進行研究的工具和技術。
結構
軟體體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連線構件。處理構件負責對數據進行加工，數據構件是被加工的信息，連線構件把體系結構的不同部分組組合連線起來。這一定義注重區分處理構件、數據構件和連線構件，這一方法在其他的定義和方法中基本上得到保持。
軟體體系結構表示了一個軟體系統的高層結構，主要特點有：
1）軟體系統結構是一個高層次上的抽象，它並不涉及具體的系統結構（比如B/S還是C/S），也不關心具體的實現。
2）軟體體系結構必須支持系統所要求的功能，在設計軟體體系結構的時候，必須考慮系統的動態行為。
3）在設計軟體體系結構的時候，必須考慮有現有系統的兼容性、安全性和可靠性。同時還要考慮系統以後的擴展性和伸縮性。所以有時候必須在多個不同方向的目標中進行決策。
軟體體系結構貫穿於軟體研發的整個生命周期內，具有重要的影響。這主要從以下三個方面來進行考察：利益相關人員之間的交流，系統設計的前期決策，可傳遞的系統級抽象。
當前已經有一些關於規範化軟體體系結構，比如：ISO的開放系統互聯模型、X Window系統等等。
方法
國外大的軟體公司和機構一直在研究軟體開發方法這個概念性的東西，而且也提出了很多實際的開發方法，比如：生命周期法、原型化方法、面向對象方法等等。下面介紹幾種流行的開發方法：
結構化方法
結構化開發方法是由E.Yourdon 和 L.L.Constantine 提出的，即所謂的SASD 方 法， 也可稱為面向功能的軟體開發方法或面向數據流的軟體開發方法。
Yourdon方法是80年代 使用最廣泛的軟體開發方法。它首先用結構化分析（SA）對軟體進行需求分析，然後用結構化設計（SD）方法進行總體設計，最後是結構化編程（SP）。它給出了兩類典型的軟體結構（變換型和事務型）使軟體開發的成功率大大提高。
面向數據結構的軟體開發方法
![軟體工程[學科]](/img/b/ec9/nBnauM3X2gTOxIDO5kDMwEjM2UTM1QDN5MjM5ADMwAjMwUzL5AzL2EzLt92YucmbvRWdo5Cd0FmLxE2LvoDc0RHa.jpg)
軟體工程[學科]Jackson方法是最典型的面向數據結構的軟體開發方法，Jackson方法把問題分解為可由三種基本結構形式表示的各部分的層次結構。三種基本的結構形式就是順序、選擇和重複。三種數據結構可以進行組合，形成複雜的結構體系。這一方法從目標系統的輸入、輸出數據結構入手，導出程式框架結構，再 補充其它細節，就可得到完整的程式結構圖。這一方法對輸入、輸出數據結構明確的中小型系統特別有效，如商業套用中的檔案表格處理。該方法也可與其它方法結合，用於模組的詳細設計。
面向問題的分析法
軟體工程需求分析PAM（Problem Analysis Method）是80年代末由日立公司提出的一種軟體開發方法。 它的基本思想是考慮到輸入、輸出數據結構，指導系統的分解，在系統分析指導下逐步綜 合。這一方法的具體步驟是：從輸入、輸出數據結構導出基本處理框；分析這些處理框之間的先後關係；按先後關係逐步綜合處理框，直到畫出整個系 統的PAD圖。這一方法本質上是綜合的自底向上的方法，但在逐步綜合之前已進行了有目的的分解，這個目的就是充分考慮系統的輸入、輸出數據結構。PAM方法的另一個優點是使用PAD圖。這是一種二維樹形結構圖，是到目前為止最好的詳細設計表示方法之一。當然由於在輸入、輸出數據結構與整個系統之間同樣存在著鴻溝，這一方法仍只適用於中小型問題。
原型化方法
產生原型化方法的原因很多，主要隨著我們系統開發經驗的增多，我們也發現並非所有的需求都能夠預先定義而且反覆修改是不可避免的。當然能夠採用原型化方法是因為開發工具的快速發展，比如用VB，DELPHI等工具我們可以迅速的開發出一個可以讓用戶看的見、摸的著的系統框架，這樣，對於計算機不是很熟悉的用戶就可以根據這個樣板提出自己的需求。
開發方法
軟體工程的方法有很多方面的意義。包括專案管理，分析，設計，程式的編寫，測試和質量控制。
軟體設計方法可以區別為重量級的方法和輕量級的方法。重量級的方法中產生大量的正式文檔。
著名的重量級開發方法包括ISO9000，CMM，和統一軟體開發過程（RUP）。
輕量級的開發過過程沒有對大量正式文檔的要求。著名的輕量級開發方法包括極限編程（XP）和敏捷流程（AgileProcesses）。
軟體需求
軟體需求包括 3 個不同的層次――業務需求、用戶需求和功能需求。
除此之外，每個系統還有各種非功能需求。
業務需求（ Business requirement ）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場行銷部門或產品策劃部門。業務需求描述了組織為什麼要開發一個系統，即組織希望達到的目標。使用前景和範圍（ vision and scope ）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（ project charter 或 market requirement ）文檔。
用戶需求（ user requirement ）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件――回響表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什麼。
功能需求（ functional requirement ）規定開發人員必須在產品中實現的軟體功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（ behavioral requirement ），因為習慣上總是用“應該”對其進行描述：“系統應該傳送電子郵件來通知用戶已接受其預定”。功能需求描述是開發人員需要實現什麼。
系統需求（ system requirement ）用於描述包含多個子系統的產品（即系統）的頂級需求。系統可以只包含軟體系統，也可以既包含軟體又包含硬體子系統。人也可以是系統的一部分，因此某些系統功能可能要由人來承擔。
業務規則包括企業方針、政府條例、工業標準、會計準則和計算方法等。業務規劃本身並非軟體需求，因為它們不屬於任何特定軟體系統的範圍。然而，業務規則常常會限制誰能夠執行某些特定用例，或者規定系統為符合相關規則必須實現某些特定功能。有時，功能中特定的質量屬性（通過功能實現）也源於業務規則。所以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。
功能需求記錄在軟體需求說明書（ SRS ）中。 SRS 完整地描述了軟體系統的預期特性。 SRS 我們一般把它當作文檔，其實， SRS 還可以是包含需求信息的資料庫或電子表格；或者是存儲在商業需求管理工具中的信息；而對於小型項目，甚至可能是一疊索引卡片。開發、測試、質量保證、項目管理和其他相關的項目功能都要用到 SRS。
除了功能需求外， SRS 中還包含非功能需求，包括性能指標和對質量屬性的描述。
質量屬性（ quality attribute ）對產品的功能描述作了補充，它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用戶或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實現的約束。
約束（ constraint ）限制了開發人員設計和構建系統時的選擇範圍。
行業需求：企業在招聘軟體測試人員時主要看中應聘者的項目經驗、邏輯思維能力、一定的技術能力和綜合素質，而對學歷、年齡、性別、工作經驗等的要求較低，相對於IT行業其他職位而言，軟體測試的入行更加容易。
工程與科學
軟體的開發到底是一門科學還是一門工程，這是一個被爭論了很久的問題。實際上，軟體開發兼有兩者的特點。但是這並不意味著它們可以被互相混淆。很多人認為軟體工程基於計算機科學和信息科學就如傳統意義上的工程學之於物理和化學一樣。在美國，大約40%的軟體工程師具有計算機科學的學位。在世界其他地方，這個比例也差不多。他們並不一定會每天使用計算機科學方面的知識，但是他們每天都會使用軟體工程方面的知識。
| 軟體工程 | 計算機科學 | |
| 目標 | 在時間、資源、人員的限制條件下構建滿足用戶需求的軟體系統。 | 探索正確的計算和建模方法，從而改進計算方法本身。 |
| 進度與時間表 | 軟體專案都有特定的進度與時間表 | 研究專案一般不具有設定的進度與時間表 |
| 產品 | 軟體（比如辦公包和編譯器）。 | 算法（比如希爾排序法）和抽象的問題（比如哲學家進餐問題）。 |
| 關注點 | 軟體工程關注如何為用戶實現價值。 | 軟體理論關注的是軟體本身運行的原理，比如時間複雜度。 |
| 變化程度 | 隨著技術和用戶需求的不斷變化，須時刻調整以適應當前的需求。 | 對於某一種特定問題的正確解決方法將永遠不會改變。 |
| 需要的其他知識 | 相關領域的知識。 | 數學。 |
| 著名的探索者和教育家 | Barry Boehm， David Parnas 等 | Edsger Dijkstra， 高德納 等 |
| 著名的實踐者 | John Backus， 蒂姆·伯納斯-李 等 | 無。 |
軟體工程專業
簡介
軟體工程專業是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及到程式設計語言，資料庫，軟體開發工具，系統平台，標準，設計模式等方面。在現代社會中，軟體套用於多個方面。典型的軟體比如有電子郵件，嵌入式系統，人機界面，辦公套件，作業系統，編譯器，資料庫，遊戲等。同時，各個行業幾乎都有計算機軟體的套用，比如工業，農業，銀行，航空，政府部門等。這些套用促進了經濟和社會的發展，使得人們的工作更加高效，同時提高了生活質量。
學科地位
軟體工程學科是計算學科的分支，計算學科中理論、抽象、設計等三個學科形態，綁定、大問題的複雜性、概念和形式模型、一致性和完備性、效率、演化、抽象層次、按空間排序、按時間排序、重用、安全性、折衷與決策等十二個基本概念，數學方法、系統科學方法在軟體工程學科中占有重要地位。此外，軟體工程還十分重視管理過程，以提高軟體產品的質量、降低開發成本、保證工程按時完成。系統性、規範性、可度量性也是軟體工程非常關注的。
軟體工程學科的理論基礎是數學、計算機科學。軟體工程的研究和實踐涉及人力、技術、資金、進度的綜合管理，是開展最最佳化生產活動的過程；軟體工程必須劃分系統的邊界，給出系統的解決方案。因此，軟體工程的相關學科有計算機科學與技術、數學、計算機工程、管理學、系統工程和人類工程學等。
就業崗位
Java方向：JAVA初級程式設計師、JAVA計算程式設計師 、 JAVA工程師 、J2EE系統工程師等。
.Net方向： .Net程式設計師網站開發工程師 .Net工程師等。
其它方向： 簡單的管理信息系統開發和維護人員 、網頁製作和客戶端腳本程式編寫人員 、初級資料庫管理和維護人員 、資料庫開發工程師 、系統分析設計工程 、軟體項目配置管理員 、文檔編寫工程師。
