軟件工程概述 | 軟件工程1

軟件工程概述

軟件危機

是指在計算機軟件的開發和維護過程當中所碰見的一系列嚴重問題。

具體問題:

• 對軟件開發成本和進度估計不許
• 用戶對已完成的軟件系統不滿意
• 軟件產品質量靠不住
• 軟件不可維護
• 軟件沒有適當的文檔資料
• 軟件成本逐年上升
• 軟件生產速度跟不上計算機應用普及速度

軟件工程

軟件工程就是指導計算機軟件開發和維護的一門工程學科。

具體定義

• 把系統、規範的、可度量的途徑應用於軟件開發、運行和維護過程，也就是把工程應用於軟件；
• 研究一中提到的途徑。

軟件工程的基本原理

• 用分階段的生命週期計劃嚴格管理
• 堅持進行階段評審
• 實行嚴格的產品控制
• 採用現代程序設計技術
• 結果應能清楚的審查
• 開發小組的人員應該少而精
• 認可不斷改進軟件工程實踐的必要性

軟件工程方法學

包含三個要素：方法、工具和過程

傳統方法學

面向對象方法學

• 把對象做爲融合了數據及在數據上的操做行爲統一的軟件構件
• 把全部的對象都劃分爲類
• 按照父類和子類的關係，把若干個相關類組成一個層次結構的系統。
• 對象彼此間僅能經過發送消息互相聯繫。

軟件生命週期

三個週期、八個階段

軟件定義、軟件開發、運行維護

軟件定義

• 問題定義
• 可行性研究
• 需求分析

軟件開發

• 整體設計
• 詳細設計
• 編碼和單元測試
• 綜合測試

前兩個稱爲系統設計，後倆稱爲系統實現

運行維護

• 運行維護

軟件過程

軟件過程是爲了得到高質量軟件所須要完成的一系列任務的框架，它規定類完成各項任務的工做步驟
一般使用生命週期模型簡潔地描述軟件過程

瀑布模型

特色：順序性、依賴性

瀑布模型（Waterfall Model） 是一個軟件生命週期模型，開發過程是經過設計一系列階段順序展開的，從系統需求分析開始直到產品發佈和維護，項目開發進程從一個階段「流動」到下一個階段，這也是瀑布模型名稱的由來。

核心思想

瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協做，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

優缺點

優勢

可強迫開發人員採用規範的方法（如結構化技術）；嚴格地規定了每一個階段必須提交的文檔；要求每一個階段交出的全部產品都必須通過質量保證小組的仔細驗證。

缺點

瀑布模型是由文檔驅動，在可運行的軟件產品交付給用戶以前，用戶只能經過文檔來了解產品是什麼樣的。瀑布模型幾乎徹底依賴於書面的規格說明，極可能致使最終開發出的軟件產品不能真正知足用戶的須要。也不適合需求模糊的系統。

分類

傳統瀑布模型

特色

(1) 階段間具備順序性和依賴性

必須等前一階段的工做完成以後，才能開始後一階段的工做。前一階段的輸出文檔就是後一階段的輸入文檔。

(2) 推遲實現的觀點

清楚的區分邏輯設計與物理設計，儘量推程序的物理實現，是由於編碼以前階段的工做沒作或作得不紮實，過早地考慮進行程序實現，每每致使大量返工，有時甚至發生沒法彌補的問題，帶來災難性的後果。實踐也代表，對於規模較大的軟件項目來講，每每編碼開始得越早最終完成開發工做所須要的時間反而越長。

(3) 質量保證的觀點

每一個階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。

每一個階段結束前都要對所完成的文檔進行評審，以便儘早發現問題，改正錯誤。

加入迭代過程的瀑布模型

緣由：

傳統的瀑布模型過於理想化，人在工做過程當中不可能不犯錯誤。

特色：

當後面階段發現前面階段的錯誤時，須要沿圖中左側的反饋線返回前面的階段，修正前面階段的產品以後再回來繼續完成後面階段的任務。

快速原型模型

快速原型模型（Rapid prototype）是須要迅速建造一個能夠運行的軟件原型 ，以便理解和澄清問題，使開發人員與用戶達成共識，最終在肯定的客戶需求基礎上開發客戶滿意的軟件產品。

核心思想

快速原型模型是快速創建一個能反映用戶主要需求的原型系統（prototype），讓用戶在計算機上試用它，經過實踐來了解目標系統的概貌。一般，用戶在試用原型系統以後會提出許多修改意見，開發人員按照用戶的意見快速地修改原型系統，而後再次請用戶試用。一旦用戶認爲這個原型系統確實能作到他們所須要的工做。開發人員即可據此書寫規格說明文檔，根據這份文檔開發出的軟件能夠知足用戶的真實需求。

優缺點

優勢

快速原型模型是不帶反饋環的，軟件產品的開發基本上是按線性順序進行的。

原型系統已經經過與用戶交互而獲得驗證，據此產生的規格說明正確地描述了用戶需求，所以，在開發過程的後續階段不會由於發現了規格說明文檔的錯誤而進行較大的返工。

開發人員經過創建原型系統已經學到了許多東西（至少知道了「系統不該該作什麼，以及怎麼不去作不應作的事情」），所以，在設計和編碼階段發生錯誤的可能性也比較小，這天然減小了在後續階段須要改正前面階段所犯錯誤的可能性。

缺點

快速創建起來的系統結構加上連續的修改可能會致使產品質量低下。使用這個模型的前提是要有一個展現性的產品原型，所以在必定程度上可能會限制開發人員的創新。

增量模型

增量模型也稱爲漸增模型，把軟件產品做爲一些列的增量構件來設計、編碼、集成和測試。每一個構件由多個相互做用的模塊構成，而且可以完成特定的功能。分解時惟一必須遵照的約束條件是，當把新構件集成到現有軟件中時，所造成的產品必須是可測試的。

優勢

能在較短期內向用戶提交可完成一些有用的工做的產品。

逐步增長產品功能可使用戶有較充裕的時間學習和適應新產品，從而減小一個全新的軟件可能給客戶組織帶來的衝擊。

缺點

使用增量模型的困難是，在把每一個新的增量構件集成到現有軟件體系結構中時，必須不破壞原來已經開發出的產品，軟件體系結構必須是開放的，相比其餘的開發模型須要更精心的設計。

從某種意義上說，增量模型自己是自相矛盾的。它一方面要求開發人員把軟件看作一個總體，另外一方面又要求開發人員把軟件看作構件序列，每一個構件本質上都獨立於另外一個構件。所以須要項目管理人員對全局把握的水平較高。

螺旋模型

特色：瀑布模型（系統化）+快速原型（迭代過程）+風險分析。

螺旋模型（Spiral Model）的基本思想是，使用原型及其餘方法來儘可能下降風險。理解這種模型的一個簡單方法，是把它看作在每一個階段以前都增長了風險分析過程的快速原型模型。

一個螺旋式週期：

肯定目標，選擇方案，選定完成目標的策略

風險角度分析該策略

啓動一個開發階段

評價前一步的結果，計劃下一輪的工做

優缺點

優勢

對可選方案和約束條件的強調有利於已有軟件的重用，也有助於把軟件質量做爲軟件開發的一個重要目標。

減小了多個測試（浪費資金）或測試不足（產品故障多）所帶來的風險。

更重要的是，在螺旋模型中維護只是模型的另外一個週期，在維護和開發之間並無本質區別。

螺旋模型主要適用於內部開發的大規模軟件項目。

缺點

螺旋模型的主要優點在於，它是風險驅動的。除非軟件開發人員具備豐富的風險評估經驗和這方面的專門知識，不然將出現真正的風險：當項目實際上正在走向災難時，開發人員可能還認爲一切正常。

噴泉模型

優缺點

優勢

噴泉模型不像瀑布模型那樣,須要分析活動結束後纔開始設計活動,設計活動結束後纔開始編碼活動.該模型的各個階段沒有明顯的界限,開發人員能夠同步進行開發.其優勢是能夠提升軟件項目開發效率,節省開發時間,適應於面向對象的軟件開發過程.

缺點

因爲噴泉模型在各個開發階段是重疊的,所以在開發過程當中須要大量的開發人員,所以不利於項目的管理.此外這種模型要求嚴格管理文檔,使得審覈的難度加大,尤爲是面對可能隨時加入各類信息、需求與資料的狀況.

Rational統一過程

RUP總結了通過多年商業化驗證的6條最有效的軟件開發經驗，這些經驗稱爲「最佳實踐」

最佳實踐

• 迭代式開發
• 管理需求
• 使用基於構件的體系結構
• 可視化建模
• 驗證軟件質量
• 控制軟件變動

核心概念

• 角色：RUP預先定義了許多角色，角色描述了在項目開發中，一我的或者一個開發團隊的工做職能與任務。
• 活動：它是一個有明確功能的獨立模塊，反映了系統的某個功能。
• 工件：是在活動進行過程當中產生、建立或修改的一段信息，同時也是項目開發的文檔資料。
• 此外，與這些核心概念相關的內容還有檢查點、模板、工做指南、報告、工具指南等。

三大特色

RUP最重要的它有三大特色：

1）軟件開發是一個迭代過程

2）軟件開發是由Use Case驅動的

3）軟件開發是以架構設計（Architectural Design）爲中心的

迭代模型

RUP強調軟件開發是一個迭代模型(Iterative Model)，它定義了四個階段(Phase)：初始(Inception)、細化(Elaboration)、構造(Construction)、交付(Transition)。其中每一個階段都有可能經歷以上所提到的從商務需求分析開始的各個步驟，只是每一個步驟的高峯期會發生在相應的階段，例如開發實現的高峯期是發生在構造階段。實際上這樣的一個開發方法論是一個二維模型，這種迭代模型的實如今很大程度上提供了及早發現隱患和錯誤的機會，所以被現代大型信息技術項目所採用。

用例驅動

RUP的另外一大特徵是用例驅動。用例是RUP方法論中一個很是重要的概念。簡單地說，一個用例就是系統的一個功能。在系統分析和系統設計中，用例被用來將一個複雜的龐大系統分割、定義成一個個小的單元，這個小的單元就是用例。而後以每一個小的單元爲對象進行開發。按照RUP過程模型的描述，用例貫穿整個軟件開發的生命週期。在需求分析中，客戶或用戶對用例進行描述，在系統分佈和系統設計過程當中，設計師對用例進行分析，在開發實現過程當中，開發編程人員對用例進行實現，在測試過程當中，測試人員對用例進行檢驗。 [2]

以架構爲中心

RUP的第三大特徵是它強調軟件開發是以構架爲中心的。構架設計(ArchitecturalDesign)是系統設計的一個重要組成部分。

敏捷過程與極限編程

敏捷過程

客戶和價值驅動的模型

四個簡單的價值觀聲明組成

• 個體和交互賽過過程和工具
• 能夠工做的軟件賽過面面俱到的文檔
• 客戶合做賽過合同談判
• 響應變化賽過遵循計劃

極限編程

極限編程是敏捷過程當中最有名的一個

極限編程的有效實踐

• 客戶做爲開發團隊的成員
• 使用用戶素材
• 短交付週期
• 驗收測試
• 結對編程
• 測試驅動開發
• 集體全部
• 持續集成
• 可持續的開發速度
• 開放的工做空間
• 及時調整計劃
• 簡單的設計
• 重構
• 使用隱喻