軟體工程總結

文章目錄

• • 名稱由來與定義
  • • 軟體危機
    • 由來
    • 定義
  • 軟體工程的核心知識（SWEBOK）
  • 軟體工程與計算機科學
  • 軟體工程的現況
  • 沒有銀彈與人月神話
  • 軟體工程與計算機程式設計
  • 軟體開發過程
  • 方法學
  • 軟體工程的發展方向
• 軟體工程的最大難題
• • 一、引言
  • 二、大項目的困境
  • 三、為什麼大項目的開發效率低？
  • 四、解決方法：代碼解耦
  • 五、解決方法：團隊解耦
  • 六、團隊解耦的注意點
• 尋找軟體工程化之路

軟體工程（英語：software engineering[1]），是軟體開發領域裡對工程方法的系統應用。

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%的軟體工程師具有計算機科學的學位。在世界其他地方，這個比例也差不多。他們并不一定會每天使用計算機科學方面的知識，但是他們每天都會使用軟體工程方面的知識。

軟體工程	計算機科學
目标	在時間、資源、人員這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）和模闆。

軟體工程的最大難題

轉載于：https://www.ruanyifeng.com/blog/2021/05/scaling-problem.html

一、引言

大學有一門課程《軟體工程》，研究如何組織和管理軟體項目。

說實話，這門課不适合大學生，因為學生可能體會不到，課程到底要解決什麼問題。隻有親身參與過大項目的開發，經曆過大團隊，才能感受為什麼軟體工程很重要，又很難做對。

軟體開發有一個難題，叫做"擴充"（scaling），即怎樣服務更多的使用者。 你有10000個并發使用者，跟你有10個并發使用者，這是完全不同的概念，哪怕功能完全相同，背後的實作是完全不一樣的。并發使用者數上升一個數量級，軟體就必須重構，大量問題随之産生。

大項目的技術難度高，管理難度更高，而且大團隊的生産率往往很低，行動緩慢。 《軟體工程》就是研究，如何擴充軟體和團隊，适應大項目的需要。

國外有很多專著，研究這個問題。前些日子，我讀到一篇文章，推薦了兩本書。第一本叫做《加速：建構和擴充高性能技術組織》，第二本叫做《規模：生物，城市和公司的普遍法則》。

我看了這兩本書的介紹，覺得很有啟發，下面就做一些摘錄。

二、大項目的困境

一個典型的大型軟體項目，開發過程通常是下面這樣。

最開始的時候，它是一個小項目，開發人員就是兩三個人，甚至可能隻有一個人。産品比較簡單，功能很有限。

第一版釋出後，拿給客戶使用，反響不錯。客戶要求的新功能，能夠很快開發出來，Bug 修補也很快，因為早期客戶往往可以與開發人員直接溝通，快速回報。

公司于是決定投入更多人員，開發這個項目。團隊慢慢變大了，軟體開始變得複雜，開發速度逐漸變慢了，2.0 版花費的時間比預期要長一點。Bug 的修複難度開始增加。總之，新功能的開發日程變久了。

公司的自然反應是進一步擴充團隊。但是更多的新成員其實會降低其他人的生産率，一個普遍現象是團隊規模越大，每個人的平均生産率越低。

幾年以後，代碼逐漸老化，複雜性不斷增加，項目開始停滞不前。某些極端的情況下，軟體的維護成本變得非常高昂，并且幾乎不可能進行更改。

最終，這個項目成為技術債務，等待被新項目替換。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-n2utsTlK-1660326005941)(https://cdn.beekka.com/blogimg/asset/202105/bg2021050819.jpg)]

三、為什麼大項目的開發效率低？

大項目就像一頭大象，讓人望而生畏。可是一旦需要奔跑，大象就會步履蹒跚，被獵犬遠遠甩在後頭。它快不起來的原因有兩個。

（1）代碼複雜度

随着代碼量的增長，單個開發者想要了解整個代碼庫，變得越來越困難。如果團隊超過五個人，每個人負責一個功能，那麼單個人幾乎不可能追蹤系統的所有工作進度。

當你中途加入團隊，整個項目是一個緊密耦合的大型系統，你又不了解系統的每一個工作細節。這時，你就不太敢修改以前的代碼，因為不知道随之而來的全部影響。

你不真正了解系統，也就不會感到自己是代碼的主人。你會很猶豫要不要重構，過時的代碼開始累積，技術債務就這樣出現了。長此以往，開發變得越來越不愉快和令人無法滿意，最終導緻人才流失。後面接手的新人，更難于重構那些遺留下來的代碼。

（2）團隊原因

随着團隊成員的增加，交流成本開始指數式上升。如果整個團隊有 n 個程式員，為了了解其他人的工作，你需要跟 n - 1 個人逐一交流（口頭或者書面），那麼整個團隊的交流路徑總數就是 n * (n - 1) / 2。這意味着，交流成本的增長速度是人員增長速度的平方，團隊人數越多，協同的難度就越大。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-5yGPhOiI-1660326005942)(https://cdn.beekka.com/blogimg/asset/202105/bg2021050822.jpg)]

大團隊保持扁平化管理，也會越來越困難，必須拆分成較小的群體。這時，對等的交流會被自上而下的交流所取代。團隊成員會感覺，自己從平等的利益相關者，轉變為普通的從業人員，工作動機受到了影響，責任感和主人翁意識都會淡漠。

管理層為了解決問題，會嘗試組建新團隊和新的管理架構。但是，不管怎麼做，大型組織都很難保持所有成員的積極參與。

四、解決方法：代碼解耦

大項目的開發效率不高，把這個問題歸咎于程式員的技術水準低和管理不善，都是沒用的。 根本原因是軟體規模的增長，必然使得代碼和團隊變得笨重。 除非很早就認識到問題的根據，采取緩解對策，否則前面描述的情況，遲早都會出現。

解決這個問題，要從代碼和團隊兩方面着手。

代碼層面的解決方法是，将軟體解耦，拆分成元件或者子產品，防止各個部分緊密地耦合在一起。每個元件和子產品，都可以獨立開發，通過公開的接口被其它部分調用。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-b1IbVWHX-1660326005943)(https://cdn.beekka.com/blogimg/asset/202105/bg2021050824.jpg)]

這樣的話，就大大減輕了開發者的負擔，隻需要負責自己的代碼即可，不需要關心其他部分的實作。每個部分都可以單獨重構，不擔心影響到其他部分。

五、解決方法：團隊解耦

除了代碼解耦，團隊層面也需要解耦，要把人員分開。

這可以參考網際網路的架構。網際網路是迄今為止最成功的大型軟體解耦執行個體，它之是以能夠擴充，是因為它由一個個獨立的節點組成。為了防止節點之間互相依賴，各個節點都遵循以下規則。

• 遵守公開的通信協定。
• 不需要了解其它節點的内部實作，就可以與之通信。
• 節點之間不直接共享狀态，隻通過通信交換資料。
• 每個節點單獨開發和部署。

大團隊也應該遵循類似的原則，進行解耦。

• 每個子團隊都可以獨立運作，不依賴外部人員。
• 子團隊内部的運作，不需要被外部知道。
• 子團隊之間的協調，應該按照公開的協定和規則，最好能夠自動完成，避免私下協商。

六、團隊解耦的注意點

團隊解耦有一些注意點。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-I9z5rNAl-1660326005943)(https://cdn.beekka.com/blogimg/asset/202105/bg2021050825.jpg)]

（1）子團隊的人數不宜過多，每個子團隊最好不要超過5個人。

（2）子團隊應該是一個小型的全功能軟體開發組織。

很多大團隊按照人員角色分組，比如架構組、開發組、DBA 組、測試組、工程組等等，這是錯誤的。這樣完全沒有解耦，還是瀑布式流程，各組之間依然互相依賴，工作時必須與别組單獨協商。而且，可能會産生利益沖突，比如，開發組希望盡快傳遞，而測試組希望多一點時間測試。

正确做法是按照軟體的業務功能分組，每組負責一個全流程的軟體大功能，設計、編碼、測試、部署、支援等人員都在同一組。這樣才能做到解耦，以及獨立的傳遞和重構。每組内部使用什麼工具、如何實作某個功能，都是自己決定，各組之間不需要共享内部細節，也不依賴别組的工作。

（3）大團隊應該保障子團隊的自主權，按照子團隊提供的功能和商業價值，進行資源配置設定。

（4）軟體架構師的角色很重要。

軟體架構師的關注點，不應該是團隊使用的工具和技術，而是各種服務與整個系統運作狀況之間的協定和通信，保證代碼和團隊可以正确解耦。

（5）代碼解耦和團隊解耦的關系。

理想情況下，代碼解耦與團隊解耦保持一緻，形成一對一的關系，一個子團隊負責一個獨立的子產品。實際運作中，一個子團隊負責幾個子產品也可以，但是一個子產品不能由多個子團隊來參與。

（6）通信（子產品之間的、子團隊之間的）盡量規範化，争取做到過程簡單、文檔充分，最好有規範的 API，這樣無需任何人員交流，就能建立通信。

尋找軟體工程化之路

轉載于：https://zhuanlan.zhihu.com/p/371723195

工程，這兩個字不知出于何處，但凡與之扯上關系，則表示得規規矩矩做事，按照科學的辦法來搞。

近日圖書館逛，偶然看到一套搞橋梁工程的老前輩寫的文集，周遊一遍，感受頗深，橋梁設計事關人命，必須依賴科學方法進行設計，施工，是以必要的設計圖紙，建造方法一個也不能少，否則失去工程的意義，草台班子搭橋也叫工程嗎？

又聞有句話：結果與過程的關系，有過程沒結果是放屁，有結果沒過程是垃圾。要做好事，做成事，必須講究過程與結果，隻有按照工程化的思想做事才能有好的結果，誠然不按照此也能做成事，但做成與做好，産品與精品絕不是一個字的差異，其可能比人與狗的差異還大吧。

又問：努力重要還是選擇重要？我覺得是努力的選擇重要，選擇确定方向，否則逆風而行，南轅北轍，再多的努力都是白費力氣，選擇對方向并不意味着成功指日可待，不努力去實踐會慢慢喪失機遇，機遇可得不可求，稍縱即逝，它不會等你準備好了再給你，機不可失，是以努力與選擇缺一不可。

扯這麼多與軟體工程化有何關系？

自覺已搞軟體多年，但始終與軟體工程化相距甚遠，設計20%時間，編碼80%時間，期間需求不停變化，做的身心俱疲。

我理想的軟體開發，一定是工程化的軟體開發，首先是精心的軟體設計，合理的編碼開發，可測試，可擴充，軟體才能好用。

近日看到canjs文檔，自覺其是按照工程化的思維去做的，人家首先提出一個軟體方面的挑戰：創新與穩定的沖突性。

大家都知道軟體開發的技術日新月異，層出不窮的新技術逐漸淘汰老技術，在這種環境如何保持軟體的穩定還能再創新不落後？微軟的産品穩定性就很差，比如silverlight,WPF，WCF等，常常追求創新卻幹一段時間不幹了，把别人丢在那不管了，又要别人學習新技術，但該軟體試圖平衡這種沖突。

它是怎麼做的呢？首先split to pieces，拆分成很小的塊，然後再對不同的塊進行assemble，組合，這樣的好處是

1，小塊的複用性很好；

2，可按照需求進行不同組合；

3，每個小塊都有自己的版本，不斷往前更新，推陳出新；

3，如果某些小塊不合時宜或者落後于時代可以棄用，減少軟體失效成本，也可以開發用新小塊，與時俱進，這樣來進行軟體疊代更新。

4，注重測試，由于每個小塊很小，很容易測試，這樣就規避了應用過大內建測試帶了的風險。

5，注重生成腳手架，這樣規範了項目結構，便于批量化生産。

6，注重使用者可定制，使用者可以自定義，便于擴充。

還有很多可以借鑒的地方，就不再贅述，其創始人從全球最大的IT咨詢公司—埃森哲出來，應該對于軟體工程化有自己的主見與想法。

看得出軟體做的很努力，但這麼一個有這好思想的軟體不火，就是我說的選擇大于努力吧（也許有人說你說的xx都有，好吧，正如上所述産品與精品的差別，或者我孤陋寡聞），目前vue,react,angular三大馬車之光芒掩飾其珍，但其軟體工程化的思想值得借鑒。

看到這裡的兄弟姐妹們，如果你也有這一方面的思考，可以私信我一起探讨，說不定哪一天可以一起開源個項目，共創軟體工程化開發的一片天。