軟件工程02：軟件生命週期模型

1. 工程過程

工程項目的三個基本目標：合理的進度、有限的經費、必定的質量。
對於質量目標，提出戴明環：Plan -> Do -> Check -> Act -> Plan -> ...

2. 軟件工程過程

定義：是爲了得到軟件產品，在軟件工具的支持下由軟件工程師完成的一系列軟件工程活動。
主要活動有：
(1). 軟件規格說明：規定軟件的功能及其使用限制；
(2). 軟件開發：產生知足規格說明的軟件；
(3). 軟件確認：經過有效性驗證以保證軟件可以知足客戶的要求；
(4). 軟件演進：爲了知足客戶的變動要求，軟件必須在使用過程當中進行不斷地改進。

3. 軟件生命週期

定義：指軟件產品從考慮其概念開始，到該軟件產品再也不使用爲止的整個時期，通常包括概念階段、分析與設計階段、構造階段、移交和運行階段等不一樣時期。

六個基本步驟：制定計劃、需求分析、設計、程序編碼、測試、運行維護。
設計：概要設計、詳細設計。
測試：單元測試、組裝測試。
運行維護：改正性維護、適應性維護、完善性維護。

4. 軟件生命週期模型

軟件過程模型：從一個特定角度提出的對軟件過程的歸納描述，是對軟件開發實際過程的抽象，包括構成軟件過程的各類活動、軟件工件以及參與角色等。
軟件生命週期模型是一個框架，描述從軟件需求定義直至軟件經使用後廢棄爲止，跨越整個生存期的軟件開發、運行和維護所實施的所有過程、活動和任務，同時描述生命週期不一樣階段產生的軟件工件，明確活動的執行角色等。

4.1. 瀑布模型

瀑布模型爲軟件開發和軟件維護提供了一種有效的管理模式，它在軟件開發早期爲消除非結構化軟件、下降軟件複雜度、促進軟件開發工程化方面起着顯著的做用。

特徵：
(1). 本活動的工做對象來自於上一項活動的輸出，這些輸出通常是表明該階段活動結束的里程碑式的文檔。
(2). 根據本階段的活動規程執行相應的任務。
(3). 產生本階段活動相關產出—軟件工件，做爲下一活動的輸入。
(4). 對本階段活動執行狀況進行評審。

4.2. 演化模型

第一次是試驗開發，獲得試驗性的原型產品，其目標只是在於探索可行性，弄清軟件需求；
第二次在此基礎上得到較爲滿意的軟件產品。

優勢：明確用戶需求、提升系統質量、下降開發風險。
缺點：
(1).難於管理、結構較差、技術不成熟；
(2).可能會拋棄瀑布模型的文檔控制優勢；
(3).可能會致使最後的軟件系統的系統結構較差 ；

適用範圍：需求不清楚、小型或中小型系統、開發週期短。

4.3. 增量模型

首先對系統最核心或最清晰的需求進行分析、設計、實現、測試並集成到系統中，再按優先級逐步對後續的需求進行上述工做，逐步建設成一個完整系統的開發方法。結合了瀑布模型和演化模型的優勢。

優勢：
(1).客戶能夠在第一次增量後就使用到系統的核心功能，加強了客戶使用系統的信心；
(2).項目整體失敗的風險較低，由於核心功能先開發出來，即便某一次增量失敗，核心功能的產品客戶仍然可使用。
(3).因爲增量是按照從高到低的優先級肯定的，最高優先級的功能獲得最屢次的測試，保障了系統重要功能部分的可靠性。
(4).全部增量都是在同一個體系結構指導下進行集成的，提升了系統的穩定性和可維護性。

缺點：
(1).增量粒度難以選擇；
(2).肯定全部的基本業務服務比較困難。

4.4. 噴泉模型

也稱迭代模型，認爲軟件開發過程的各個階段是相互重疊和屢次反覆的，就象噴泉同樣，水噴上去又能夠落下來，既能夠落在中間，又能夠落到底部。各個開發階段沒有特定的次序要求，徹底能夠並行進行。

優勢：提升開發效率、縮短開發週期。
缺點：難於管理。

4.5. V模型和W模型

將測試活動提早，使得瀑布模型可以駕馭風險。

4.6. 螺旋模型

主要針對大型軟件項目的開發週期長、風險高的特色。
四個象限：制定計劃、風險分析、實施工程、客戶評價。

4.7. 原型方法

原型：模擬某種最終產品的原始模型。
原型方法：在得到一組基本需求後，經過快速分析構造出一個小型的軟件系統原型，知足用戶的基本要求。用戶經過使用原型系統，提出修改意見，從而減小用戶與開發人員對系統需求的誤解，使需求儘量準確。主要用於明確需求，但也能夠用於軟件開發的其餘階段。

種類：
(1). 廢棄策略（探索型、實驗型）
(2). 追加策略（進化型）

適用侷限性：
(1). 大型系統
(2). 大量運算、邏輯性較強的程序模塊
(3). 原有應用的業務流程、信息流程混亂的狀況

存在的問題：
(1). 文檔容易被忽略
(2). 創建原型的許多工做會被浪費
(3). 項目難以規劃和管理

4.8. RUP

定義：一種軟件工程過程框架，是一個基於面向對象的程序開發方法論。
敏捷模型：是概括總結出來的一些敏捷建模價值觀、原則和實踐等組成的，它是快速軟件開發的一種思想表明。

四個順序階段：初始階段、細化階段、構造階段、交付階段。
每一個階段結束於一個主要的里程碑，並在階段結尾執行一次評估以肯定這個階段的目標是否已經知足。若是評估結果使人滿意的話，能夠容許項目進入下一個階段。

4.8.1. 初始階段

目標：經過業務場景瞭解業務並肯定項目的邊界。包括項目的驗收規範、風險評估、所需資源估計、階段計劃等。
要肯定項目邊界，需識別全部與系統交互的外部實體，主要包括識別外部角色、識別全部用例並詳細描述一些重要的用例。
里程碑：軟件目標里程碑。包括一些重要的文檔（遠景。用例模型、風險評估等）。

4.8.2. 細化階段

目標：分析問題領域，創建適合需求的軟件體系結構基礎，編制項目計劃，完成項目中技術要求高、風險大的關鍵需求的開發。
里程碑：體系結構里程碑。包括一些重要的文檔（風險分析。軟件體系結構基線等）。

4.8.3. 構造階段

目標：將全部剩餘的技術構件和穩定業務需求功能開發出來，並集成爲產品，全部功能被詳細測試。
里程碑：運行能力里程碑。包括可運行的軟件產品、用戶手冊等。

4.8.4. 移交階段

重點：確保軟件對最終用戶是可用的。
能夠跨越幾回迭代，包括爲發佈作準備的產品測試，基於用戶反饋的少許調整。
里程碑：產品發佈里程碑。要肯定最終目標是否實現。

RUP的特色：以用例爲驅動，軟件體系結構爲核心，應用迭代及增量的新型軟件生命週期模型。

核心活動：
6個核心過程工做流：業務建模、需求、分析和設計、實現、測試、部署。
3個核心支持工做流：配置和變動管理、項目管理、環境。

最佳實踐，適應性開發：小步驟、快速反饋和調整。

4.9. 極限編程

XP是一種輕量級的軟件開發方法，是一種以實踐爲基礎的軟件工程過程和思想。
它使用快速的反饋，大量而迅速的交流，通過保證的測試來最大限度的知足用戶的需求。
XP強調用戶滿意，開發人員能夠對需求的變化做出快速的反應。

4.10. 構建組裝模型

利用模塊化思想將整個系統模塊化，並在必定構件模型的支持下複用構件庫中軟件構件，經過組裝高效率、高質量地構造軟件系統。構件組裝模型本質上是演化的，開發過程是迭代的。

優勢：
(1). 充分利用軟件複用，提升了軟件開發的效率。
(2). 容許多個項目同時開發，下降了費用，提升了可維護性，可實現分步提交軟件產品。

缺點：
(1). 缺少通用的構件組裝結構標準，風險較大；
(2). 構件可重用性和系統高效性之間不易協調；
(3). 因爲過度依賴於構件，構件質量影響着最終產品的質量。

4.11. 快速應用開發模型（RAD）

是一個增量型的軟件開發過程模型，強調極短的開發週期。
缺點：
(1). 並不是全部應用都適合採用RAD
(2). 因爲時間約束，開發人員和客戶必須在較短的時間內完成一系列的需求分析，溝通配合不當都會致使應用RAD模型的失敗
(3). RAD適合於管理信息系統的開發，對於其餘類型的應用系統，如技術風險較高、與外圍系統的互操做性較高等，不太合適