---

theme: cyanosis

前言

• 軟體的第一個時期：自己開發，自己使用 20世紀50年代，軟體伴隨著第一臺電子計算機誕生了。以寫軟體為職業的人也開始出現，他們多是經過訓練的數學家和電子工程師。大多數軟體是由使用該軟體的個人研發的，主要依靠個人程式設計技巧，沒有什麼系統的方法可循。
• 軟體的第二個時期：團隊開發，別人使用 20世紀60年代至70年代，隨著計算機的發展，軟體也開始作為一種產品被廣泛使用，出現了“軟體作坊”，小團隊合作專職為別人寫軟體，但是仍然以個人程式設計為主。
• 軟體危機 隨著軟體的數量增大，需求也日趨複雜，維護難度也越來越大，失敗的軟體專案也越來也多，原來以個人設計、開發的方式已經無法滿足，“軟體危機”就這樣開始了。1968年NATO組織的計算機學術會議上提出的“軟體危機”概括來說包含兩方面：
  1. 如何開發軟體以滿足不斷增長、日趨複雜的需求。
  2. 如何維護數量不斷膨脹的軟體產品。

概述

軟體工程是研究如何用系統化、規範化、數量化等工程原則和方法去進行軟體的開發和維護，包括兩方面： 1. 軟體開發技術：軟體開發技術包括軟體開發方法、軟體開發工具、軟體工程環境。 2. 軟體專案管理：軟體專案管理包括軟體開發計劃、成本管理、進度管理、人力資源管理、質量管理、風險管理等。 - 軟體工程的誕生 1968年秋季NATO召集了近50名一流的程式設計人員、電腦科學家和工業界巨頭，討論和制定擺脫“軟體危機”的對策，在會議上第一次提出了“軟體工程”的概念。 - 軟體工程的發展 軟體工程的不斷髮展中，人們進行了不懈的努力，這些努力大致沿著2個方向同時進行的： 1. 從管理的角度，希望軟體開發過程如建築一樣工程化： 業主提出需求->設計建築方案->施工->驗收交付 這方面最著名的成果就是提出了大家都很熟悉的“瀑布式”生命週期模型： 分析->設計->實現>執行和維護 它是在“軟體危機”後出現的第一個生命週期模型。後來，又有人針對該模型的不足，提出了原型模型、螺旋模型、噴泉模型等對“瀑布式”模型進行補充。 2. 第二個方向側重於對軟體開發過程中分析、設計的方法研究。這方面最著名的成果就是70年代風靡一時的結構化開發方法。

一句話理解軟體工程：==按照某種方法使用某種工具執行相關過程研製開發出具有良好軟體質量和費用合算的產品。== 這裡的“某種方法”即開發方法（比如結構化開發方法）、“某種工具”（比如建模工具、開發軟體等）、相關過程即為軟體的生命週期。

軟體生命週期

  軟體生命週期是軟體的產生到報廢的生命週期，把整個生命週期分為三大階段，分別為定義、軟體開發、軟體維護。使得每個階段有明確的任務，使規模大、結構複雜和管理複雜的軟體開發變的容易控制和管理。 - 定義階段：該階段的目的是為了確定總目標，通常把該階段細分為問題定義、可行性研究、需求分析3個階段。其中： - 問題定義、可行性研究階段是軟體開發方和需求方共同討論，確定軟體開發的目標及可行性。 - 需求分析階段在確定軟體開發可行的情況下，對軟體需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，它直接決定軟體專案的成敗。（具體分析過程請移步《系統分析》） - 軟體開發階段：該階段的目的是為了設計與實現，又可以分為軟體設計、編碼、測試3個階段。其中： - 軟體設計階段（概要設計、詳細設計）主要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計，資料庫設計等等。 - 軟體編碼階段是將軟體設計的結果轉換成計算機可執行的程式程式碼。 - 軟體測試階段需要經過嚴密的測試，以發現軟體在整個設計及實現過程中存在的問題並加以糾正。 - 軟體執行和維護階段：該階段是將軟體交付給使用者後，軟體生命週期中持續時間最長的階段，包括更正性維護、適應性維護、預防性維護、完善性維護，其中： - 更正性維護是診斷和修正系統中遺留的錯誤，出現錯誤後修正。 - 適應性維護是系統適應環境的變化而進行的維護工作。 - 完善性維護是軟體在使用過程中為了滿足使用者提出新的功能及效能要求而對系統進行擴充套件及改進的工作。 - 預防性維護是說應對系統進行主動的發現或分析即將可能會出現的問題，不應總是被動地等待使用者提出要求後才進行，目的是為未來的修改與調整奠定更好的基礎。

軟體開發模型

  軟體開發模型是對軟體開發過程的抽象和概括，是對開發過程各階段之間關係的描述、約束和表示，能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體專案工作的基礎。

瀑布模型

  瀑布模型將軟體生命週期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

  各活動之間有以下關係： - 上一次活動結果為本次活動的輸入。 - 利用這一次輸入實施本活動。 - 本次活動的輸出給下次活動。 - 對本次活動成果進行評審，若取得確認繼續下一項活動，否則返回前一項甚至更前項活動。

  這種模型的線性過程太理想化，已不再適合現代的軟體開發模式，幾乎被業界拋棄，其主要問題在於： - 各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量。 - 由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險。 - 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

快速原型模型

  快速原型模型是通過和客戶的交流快速建立原型，實現客戶和系統的互動，通過使用者對原型的評價，進一步細化軟體的需求，通過逐步調整原型滿足客戶的需求。

• 優點：通過與客戶的頻繁交流，任何功能一經開發就可測試，以便驗證是否符合產品需求。克服了瀑布模型的缺點，減少因需求不明確帶來的風險。
• 缺點：如果不加以控制讓使用者接觸開發中尚未穩定的功能，可能對開發人員及使用者都會產生負面影響。

螺旋模型

  螺旋模型將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合於大型複雜的系統。   螺旋模型沿著螺線進行若干次迭代，圖中的四個象限代表了以下活動： - 制定計劃：確定軟體目標，選定實施方案，弄清專案開發的限制條件。 - 風險分析：分析評估所選方案，考慮如何識別和消除風險。 - 設計實施：實施軟體設計、開發和驗證。 - 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。

噴泉模型

  噴泉模型認為軟體開發過程自下而上，週期的各階段是相互迭代和無間隙的特性。迭代是指軟體的某個部分會被重複工作多次，相關物件在每次迭代中加入漸進的軟體成分，逐步完善。無間隙指在各項活動之間無明顯邊界，如分析工作沒有完全結束就可以先進行部分設計工作。 - 優點： 1. 以使用者需求為驅動的模型，支援逐步完善需求，不要求使用者早期確定所有需求。 2. 由於各階段無間隙的特徵，各階段開發人員可以同步開發，提高開發效率，節省專案時間。 - 缺點： 1. 由於各階段無間隙的特徵，因此在開發過程中需要大量的開發人員，不利於專案的管理。 2. 要求嚴格管理文件，使得稽核的難度加大，尤其是面對可能隨時加入各種資訊、需求與資料的情況。

RUP統一過程模型

  軟體開發模型的出現是為了消除軟體危機，隨著客觀世界不斷變化，面對新情況、新問題，原有的模型將無法勝任。90年代開始，出現了一些現代軟體開發模型，如RUP、敏捷模型等。   RUP經過多年總結了商業化驗證的6條最有效的軟體開發經驗，被稱為“最佳實踐”。分別為：迭代式開發、管理需求、使用基於構件的體系結構、視覺化建模、驗證軟體質量、控制軟體變更。如圖所示，它是一個大的迭代過程：橫座標表示軟體所處的4個階段，縱座標表示軟體在每個階段的工作流。 - 初始階段：建立初步的系統模型，掌握大致使用者的需求，定義開發環境的初步方案。包括明確專案規模、評估專案風險、制定專案計劃、階段技術評審。 - 細化階段：進行詳細的系統分析、設計系統的架構，進一步細化需求。包括確定架構、制定構件階段計劃、建立支援環境、選擇構件、階段技術評審。 - 構建階段：對系統進行詳細設計，並進行編碼、測試、整合等。 - 移交階段：確定目標是否實現，是否開始另一次迭代。補充各種文件，並把系統移交給使用者。

RAD快速應用開發

  RAD是基於構件的開發模型，其目的是為了快速實現軟體的開發，在確定需求後選擇一些現有的構件進行組裝、設計、修改等，達到快速開發。其分為以下幾個階段： - 規劃階段：使用者、開發人員、管理人員確定業務需求、專案範圍、系統需求等，稽核後進入下一階段。 - 設計階段：獲取需求的細節，構建原型。 - 實現階段：編碼、單元測試、系統測試。 - 執行階段：資料準備、使用者培訓。

軟體能力成熟度模型CMM

   軟體能力成熟度模型（Capability Maturity Model ，簡稱CMM）是一種對軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述形成的標準，用於評價軟體機構的軟體過程能力成熟度的模型。分為5個等級： - 初始級：未加定義的隨意過程，軟體的過程是無秩序的，有時甚至是混亂的。軟體的過程定義幾乎處於無章法和步驟可循的狀態。 - 可重複級：規則化和紀律化的過程，軟體過程已經定義了基本的專案管理過程，對專案的成本、進度和功能特性進行跟蹤，對類似的專案有章可循並能重複以往的成功。 已定義級：用於管理的軟體過程均已文件化、標準化，並形成了整個軟體組織的標準軟體過程。全部專案均可採用此軟體過程進行操作。 已管理級：已管理級是可預測過程，軟體過程和產品質量有詳細的度量標準。軟體過程和產品質量得到定量的認識和控制。 優化級：持續改進的過程，通過對新概念、新技術等方面進行定量分析，不斷的、持續的對過程進行改進。

軟體開發方法

  軟體開發方法是對軟體開發過程中分析、設計兩個階段的方法論以及研究成果。從70年代發展至今誕生了不同類別的開發方法，對於不同需求的系統使用不同的開發方法。 - 開發方法按照開發風範有： - 自頂向下：將一個大問題劃分多個小的問題，逐一解決。每個問題都有一個模組去解決，且每個問題包括抽象步驟和具體步驟。 - 自底向上：根據系統功能要求，從具體的器件、邏輯部件或相似的系統開始，憑藉設計者熟練的技巧和豐富的經驗對其進行連線、修改和擴大，構成所要求的一個系統。 - 開發方法按照性質有： - 形式化：基於嚴密的、數學上的形式機制的系統研究方法。 - 非形式化：各種開發模型。

結構化開發方法

  結構化方法由結構化分析、結構化設計、結構化程式設計構成，它是一種面向資料流的開發方法。結構化方法總的指導思想是自頂向下、逐層分解。其特徵為： - 開發目標清晰：保持與客戶溝通，明確系統的功能需求，確定系統的邊界，讓客戶瞭解工作進展、校準工作方向。 - 開發工作階段化：每個階段完成後進行評審，便於專案管理與控制。 - 開發文件規範化：每個階段完成後按照要求完成相應的文件，保證系統維護工作的便利。 - 設計方法結構化：自頂向下分解，進行分析與設計。根據設計要求編寫各功能模組，自底向上實現。

  ==其缺點是：開發週期長，難以適應需求變化。==

  結構化分析是根據分解和抽象的原則，按照系統中資料處理的流程，用資料流圖建立系統功能模型，從而完成需求分析工作。結構化分析結果由以下幾部分組成： - 資料流圖：便於使用者理解、分析系統資料流程的圖形工具。 - 資料字典：對資料流圖中的資料流、加工及其他資料項加以描述。 - 加工邏輯的描述：利用結構化語言、判定表和判定樹對加工邏輯進行描述。 - 補充材料

  結構化設計是根據模組獨立性準則、 軟體結構優化準則將資料流圖轉換成軟體的體系結構，用軟體結構圖來建立系統的物理模型，實現系統的概要設計。   結構化程式設計使用3種基本控制結構構造程式，任何程式都可以由順序、選擇和 重複3種基本控制結構構造。

面向物件開發方法

  面向物件開發方法將面向物件的思想應用於軟體開發過程中，指導開發活動，是建立在“物件”概念基礎上的方法學，簡稱OO( Object-Oriented)方法。由面向物件分析(OOA)、面向物件設計(OOD)、面向物件程式設計(OOP)構成。   面向物件開發方法發展歷程 | 名稱 | 描述 | |--|--| | Coad/Yourdon方法 | 強調OOA和OOD採用完全一致的概念和表示法，使兩者不需要轉換 | | Booch方法 | 開發模型包括靜態模型和動態模型，靜態模型分為邏輯模型（類圖、物件圖）和物理模型（模組圖、程序圖），用來描述系統的構成和結構。動態模型包括狀態圖和順序圖，用來描述物件的狀態及互動過程 | | OMT方法 | 使用了建模的思想，採用物件模型（物件圖）、動態模型（狀態圖）和功能模型（資料流圖）來建立應用模型 | | OOSE方法 | 使用用例取代了DFD進行需求分析和建立功能模型 |

  面向物件分析是確定需求或者業務的角度，按照面向物件的思想來分析業務。以用例驅動進行建模（UML建模工具）分析出功能模型（用例圖）、動態模型（狀態圖、順序圖、活動圖）、物件模型（類圖）。   面向物件設計是對分析階段的模型進行細化並延伸，額外產出架構圖、包圖等。

構件化開發方法

  構件化是指軟體體系結構可重組以及軟體成分可以複用的開發方法，基於構件的軟體開發是解決複雜環境下軟體規模與複雜性的一種手段，可以提高軟體的開發效率和質量。構件通過連線件連線在一起，其特徵是可獨立部署的單元、作為第三方的組裝單元、沒有外部可見狀態。 - 構件的獲取 1. 從現有構件中獲取、直接使用或做適應的修改得到可複用的構件。 2. 通過遺留工程，將具有潛在複用價值的構件提取出來，得到可複用的構件。 3. 從市場購買現成的構件。 4. 開發新的符合需求的構件。 - 構件的分類 - 關鍵字分類：將應用領域的概念從抽象到具體的順序逐次分解為樹形或有向無迴路圖結構，每個概念用一個關鍵字描述。 - 刻面分類：用於刻畫構件特徵的“刻面”，每個麵包含若干概念，這些概念描述構件在刻面上的特徵。 - 超文字分類：所有構件必須輔以詳細的功能或行為說明文件。檢索者在閱讀文件的過程中可以任意跳轉到相關構件或概念的文件。 - 構件的複用方法 1. 檢索與提取構件 2. 理解與評價構件 3. 修改構件 4. 組裝構件 - 構件的檢索方法 - 關鍵字檢索：系統在圖形使用者介面上將構件庫的關鍵字以樹形結構展現，複用者通過對樹形結構逐級預覽，尋找需要的關鍵字並提取相應的構件。 - 刻面檢索：基於刻面分類法，由3步構成，分別是構造查詢、檢索構件和對構件進行排序。 - 超文字檢索：複用者給出數個關鍵字，系統在構件說明文件進行精準或模糊匹配，匹配成功後向複用者列出響應的構件說明。

面向服務開發方法

  在構件化基礎上產生的思想，對於跨構件的功能呼叫，採用介面的形式暴露出來，進一步將介面的定義與實現進行解耦，催生了面向服務開發方法。其有3個抽象級別： - 操作：單個邏輯單元的事務，包含特定的結構化介面，並返回結構化響應。 - 服務：操作的邏輯分組。 - 業務流程：為實現特定業務目標而執行一組長期執行的活動。

  在面向服務開發的過程中，存在多個服務，通常複雜的IT環境中的服務層都同時使用了多種技術，而實現不同技術的服務之間的互聯性障礙給應用整合帶來了極大的困難，這時候引入了服務匯流排（ESB）。ESB支援異構環境中的服務、訊息，以及基於事件的互動，並且具有適當的服務級別和可管理性。ESB的功能主要體現在通訊、服務互動、應用整合、服務質量、安全性以及管理和監控等方面。 - 通訊：ESB能夠支援訊息路由/定址，支援多種通訊技術、通訊協議(如JMS、HTTP)，支援釋出/訂閱的通訊模式，能夠處理請求/響應、同步以及非同步的訊息傳遞方式，並且要求以可靠的方式傳遞訊息。 - 服務互動：ESB上所釋出的服務是以當前標準的Web服務描述語言(WSDL)來定義Web服務的，並且ESB上通常配備有服務目錄和發現機制。 - 服務質量：整合不同系統的同時，必須考慮服務質量方面的問題，如事務性和訊息傳遞的可靠性。 - 安全性：對於關鍵的Web服務，ESB需要以加密的方式進行訊息傳遞，並且必須驗證訪問者的許可權。

快速原型法

   原型法與結構化方法對立，結構化方法在系統開發初期必須明確系統的功能，確定系統邊界，原型法則是根據使用者的初步需求利用系統工具快速建立系統模型與使用者交流。 - 按照實現功能劃分 - 水平原型：行為原型，用於介面。細化需求但未實現功能。 - 垂直原型：結構化原型，用於複雜演算法的實現，實現部分功能。 - 按照最終結果劃分 - 拋棄式：探索式原型，解決需求的不確定性，與使用者需求不一致時直接拋棄。 - 演化式：逐步演化成最終系統，用於易於升級和優化的系統。

敏捷開發方法

   敏捷開發方法是一種應對快速變化的需求的一種軟體開發能力，相對於“非敏捷”，其思想是：小步快走、以人為本，與客戶緊密協作、面對面溝通，減少不必要的文件、儘早釋出增量功能、小而自主的開發團隊，適用於規模小的專案。 - xp極限程式設計 極限程式設計是一個輕量級的、靈巧的軟體開發方法；同時它也是一個非常嚴謹和周密的方法，通常採用測試先行的方式執行。 - 為什麼稱為“Extreme”（極限）？“Extreme”（極限）是指，對比傳統的專案開發方式，XP強調把它列出的每個方法和思想做到極限、做到最好；其它所不提倡的，XP則一概忽略（如開發前期的整體設計等）。一個嚴格實施XP的專案，其開發過程應該是平穩的、高效的和快速的，能夠做到一週40小時工作制而不拖延專案進度。由以下幾點保證： - 在更短的週期內，更早地提供具體、持續的反饋資訊。 - 在迭代的進行計劃編制，首先在最開始迅速生成一個總體計劃，然後在整個專案開發過程中不斷的發展它。 - 依賴於自動測試程式來監控開發進度，並及早地捕獲缺陷。 - 依賴於口頭交流、測試和源程式進行溝通。 - 倡導持續的演化式設計。 - 依賴於開發團隊內部的緊密協作。 - 儘可能達到程式設計師短期利益和專案長期利益的平衡。 - 核心價值觀是：溝通、簡單、反饋和勇氣；即任何一個軟體專案都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇於實事求是。 - Scrum爭求並列 Scrum 是一個用於開發和維護複雜產品的框架 ，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代週期組成，一個短的迭代週期稱為一個Sprint，每個Sprint的建議長度是2到4周。迭代週期工作： - 高優先順序的需求驅動：使用Product Backlog來管理需求，在開發需求的時候，從Backlog最上層的高優先順序的需求開始開發。 - 執行Sprint：只要有足夠1-2個Sprint開發的細化了的高優先順序的需求，我們就可以啟動Sprint了。 - 每日檢視和調整：每個開發團隊成員都應該參與每日站會，一起檢驗Sprint目標的進展情況，跟進當天的工作情況調整計劃。 - 梳理產品列表：每個Sprint都需要花一些時間來準備下一個Sprint，主要用來梳理產品列表，包括PBI的建立和細化、估算和排列優先順序順序。 - 檢視和調整產品與過程：每個Sprint結束後，開發團隊都要參加兩個檢視和調整的活動，即Sprint評審會議（Sprint Review Meeting）和 Sprint回顧會議（Sprint Retrospective Meeting）。 - Cockburn水晶方法 水晶方法遵循敏捷方法思想，保證了產品開發的進度，較好的滿足了客戶的需求，使開發過程順利實施。但在產品開發過程中，不能運用單一的敏捷方法，應該要根據專案的具體情況，借鑑多種方法，取長補短，形成新的敏捷思維（不同專案，不同策略）。