《《軟件工程基礎》第2章-軟件開發(fā)過程.ppt》由會員分享，可在線閱讀，更多相關《《軟件工程基礎》第2章-軟件開發(fā)過程.ppt（37頁珍藏版）》請在裝配圖網上搜索。

1 38 第2章軟件開發(fā)過程 2 1軟件過程2 2常見的軟件過程模型2 3軟件過程的新發(fā)展 2 38 第2章軟件開發(fā)過程 2 1軟件過程2 1 1軟件過程的概念與理論基礎2 1 2軟件過程討論的主要內容2 2常見的軟件過程模型2 3軟件過程的新發(fā)展 3 38 2 1 1軟件過程的概念與理論基礎 軟件過程的概念軟件過程模型的理論基礎 4 38 軟件過程的概念 軟件過程是為了獲得高質量軟件所需要完成的一系列任務的框架 它規(guī)定了完成各項任務的工作步驟 在完成開發(fā)任務時必須進行一系列開發(fā)活動 并且使用適當?shù)馁Y源 在過程結束時將把輸入轉化為輸出 因此 ISO9000把過程定義為 使用資源將輸入轉化為輸出的活動所構成的系統(tǒng) 過程定義了運用方法的順序 應該交付的文檔資料 為保證軟件質量和協(xié)調變化所需要采取的管理措施 以及標志軟件開發(fā)各個階段任務完成的里程碑 5 38 軟件過程模型及理論基礎 通常使用生命周期模型簡潔地描述軟件過程 建立軟件開發(fā)過程模型的理論基礎是軟件生命周期理論和相關的軟件工程原則 因此 軟件過程模型又稱軟件生命周期模型 SoftwareLifeCycleModel 其核心思想主張把軟件過程劃分成若干個階段 每個階段所包含的活動內容和性質具有 高內聚 低藕合 的特征 這樣有助于簡化問題 有助于驗證階段性的工作成果 有助于對軟件工程的施工與管理 生命周期模型規(guī)定了把生命周期劃分成哪些階段及各個階段的執(zhí)行順序 因此 也稱為過程模型 軟件過程模型是對軟件開發(fā)活動進行有效地組織 協(xié)調 管理與控制的一種策略過程模型化是為了便于理解和操作 6 38 SoftwareLifeCycleModel 7 38 2 1 2軟件過程討論的主要內容 軟件過程討論的主要內容包括軟件過程模型 項目軟件過程定義 軟件過程裁剪 軟件過程改進及軟件能力成熟度的評價等內容 軟件過程模型給出了適合不同軟件項目的軟件過程活動組織的參考框架 對不同的軟件組織來講 典型軟件過程模型僅僅是理論參考框架 為了不斷提高軟件能力 軟件組織 企業(yè)與團隊 應該不斷積累經驗 針對不同的軟件項目和軟件組織自身的特點 在軟件過程定義 軟件過程裁剪 軟件過程改進等方面不斷努力和提高 軟件能力成熟度模型 CMM 是對一個軟件組織的軟件能力成熟度進行評價的框架模型 它同時對軟件組織不斷提高軟件能力具有的一定的促進作用 8 38 2 2常見的軟件過程模型 軟件過程包括軟件開發(fā)過程和軟件維護過程 實踐中 人們基于軟件工程方法論和軟件項目特點總結出了不同的軟件過程模型 好的過程模型吸收了成功的軟件工程經驗和有效的軟件工程原則 因此參考軟件過程模型框架組織軟件項目有利于提高工作效率 把握開發(fā)質量 總體上可以提高軟件項目的成功率 為獲得高質量的軟件產品 軟件過程必須科學 有效 沒有一個適用于所有軟件項目的任務集合 因此 科學 有效的軟件過程應該定義一組適合于所承擔的項目特點的任務集合 通常 一個任務集合包括一組軟件工程任務 里程碑和應該交付的產品 9 38 典型的過程模型 實際的軟件開發(fā)活動中 應該項目的特點來劃分階段 但是 下面講述典型的軟件過程模型時并不是針對某個特定項目講的 因此只能使用 通用的 階段劃分方法 由于瀑布模型與快速原型模型的主要區(qū)別是獲取用戶需求的方法不同 因此 下面在介紹生命周期模型時把 規(guī)格說明 作為一個階段獨立出來 此外 問題定義和可行性研究的主要任務都是概括地了解用戶的需求 為了簡潔地描述軟件過程 把它們都歸并到需求分析中去了 同樣 為了簡潔起見 把總體設計和詳細設計合并在一起稱為 設計 10 38 1 4 1瀑布模型 在20世紀80年代之前 瀑布模型一直是惟一被廣泛采用的生命周期模型 現(xiàn)在它仍然是軟件工程中應用得最廣泛的過程模型 傳統(tǒng)軟件工程方法學的軟件過程 基本上可以用瀑布模型來描述 圖1 2所示為傳統(tǒng)的瀑布模型 按照傳統(tǒng)的瀑布模型開發(fā)軟件 有下述的幾個特點 11 38 圖1 2傳統(tǒng)的瀑布模型 12 38 1 階段間具有順序性和依賴性這個特點有兩重含義 必須等前一階段的工作完成之后 才能開始后一階段的工作 前一階段的輸出文檔就是后一階段的輸入文檔 因此 只有前一階段的輸出文檔正確 后一階段的工作才能獲得正確的結果 2 推遲實現(xiàn)的觀點對于規(guī)模較大的軟件項目來說 往往編碼開始得越早最終完成開發(fā)工作所需要的時間反而越長 這是因為 前面階段的工作沒做或做得不扎實 過早地考慮進行程序實現(xiàn) 往往導致大量返工 有時甚至發(fā)生無法彌補的問題 帶來災難性后果 13 38 瀑布模型在編碼之前設置了系統(tǒng)分析與系統(tǒng)設計的各個階段 分析與設計階段的基本任務規(guī)定 在這兩個階段主要考慮目標系統(tǒng)的邏輯模型 不涉及軟件的物理實現(xiàn) 清楚地區(qū)分邏輯設計與物理設計 盡可能推遲程序的物理實現(xiàn) 是按照瀑布模型開發(fā)軟件的一條重要的指導思想 3 質量保證的觀點軟件工程的基本目標是優(yōu)質 高產 為了保證所開發(fā)的軟件的質量 在瀑布模型的每個階段都應堅持兩個重要做法 14 38 1 每個階段都必須完成規(guī)定的文檔 沒有交出合格的文檔就是沒有完成該階段的任務 完整 準確的合格文檔不僅是軟件開發(fā)時期各類人員之間相互通信的媒介 也是運行時期對軟件進行維護的重要依據 2 每個階段結束前都要對所完成的文檔進行評審 以便盡早發(fā)現(xiàn)問題 改正錯誤 事實上 越是早期階段犯下的錯誤 暴露出來的時間就越晚 排除故障改正錯誤所需付出的代價也越高 因此 及時審查 是保證軟件質量 降低軟件成本的重要措施 15 38 傳統(tǒng)的瀑布模型過于理想化了 事實上 人在工作過程中不可能不犯錯誤 在設計階段可能發(fā)現(xiàn)規(guī)格說明文檔中的錯誤 而設計上的缺陷或錯誤可能在實現(xiàn)過程中顯現(xiàn)出來 在綜合測試階段將發(fā)現(xiàn)需求分析 設計或編碼階段的許多錯誤 因此 實際的瀑布模型是帶 反饋環(huán) 的 如圖1 3所示 圖中實線箭頭表示開發(fā)過程 虛線箭頭表示維護過程 當在后面階段發(fā)現(xiàn)前面階段的錯誤時 需要沿圖中左側的反饋線返回前面的階段 修正前面階段的產品之后再回來繼續(xù)完成后面階段的任務 16 38 圖1 3實際的瀑布模型 17 38 瀑布模型有許多優(yōu)點 可強迫開發(fā)人員采用規(guī)范的方法 例如 結構化技術 嚴格地規(guī)定了每個階段必須提交的文檔 要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證 各個階段產生的文檔是維護軟件產品時必不可少的 沒有文檔的軟件幾乎是不可能維護的 遵守瀑布模型的文檔約束 將使軟件維護變得比較容易一些 由于絕大部分軟件預算都花費在軟件維護上 因此 使軟件變得比較容易維護就能顯著降低軟件預算 可以說 瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅動的模型 18 38 但是 瀑布模型是由文檔驅動的 這個事實也是它的一個主要缺點 在可運行的軟件產品交付給用戶之前 用戶只能通過文檔來了解產品是什么樣的 但是 僅僅通過寫在紙上的靜態(tài)的規(guī)格說明 很難全面正確地認識動態(tài)的軟件產品 而且事實證明 一旦一個用戶開始使用一個軟件 在他的頭腦中關于該軟件應該做什么的想法就會或多或少地發(fā)生變化 這就使得最初提出的需求變得不完全適用了 事實上 要求用戶不經過實踐就提出完整準確的需求 在許多情況下都是不切實際的 總之 由于瀑布模型幾乎完全依賴于書面的規(guī)格說明 很可能導致最終開發(fā)出的軟件產品不能真正滿足用戶的需要 19 38 1 4 2快速原型模型 所謂快速原型是快速建立起來的可以在計算機上運行的程序 它所能完成的功能往往是最終產品能完成的功能的一個子集 如圖1 4所示 圖中實線箭頭表示開發(fā)過程 虛線箭頭表示維護過程 快速原型模型的第一步是快速建立一個能反映用戶主要需求的原型系統(tǒng) 讓用戶在計算機上試用它 通過實踐來了解目標系統(tǒng)的概貌 20 38 通常 用戶試用原型系統(tǒng)之后會提出許多修改意見 開發(fā)人員按照用戶的意見快速地修改原型系統(tǒng) 然后再次請用戶試用 一旦用戶認為這個原型系統(tǒng)確實能做他們所需要的工作 開發(fā)人員便可據此書寫規(guī)格說明文檔 根據這份文檔開發(fā)出的軟件可以滿足用戶的真實需求 從圖1 4可以看出 快速原型模型是不帶反饋環(huán)的 這正是這種過程模型的主要優(yōu)點 軟件產品的開發(fā)基本上是線性順序進行的 能做到基本上線性順序開發(fā)的主要原因如下 21 38 圖1 4快速原型模型 22 38 1 原型系統(tǒng)已經通過與用戶交互而得到驗證 據此產生的規(guī)格說明文檔正確地描述了用戶需求 因此 在開發(fā)過程的后續(xù)階段不會因為發(fā)現(xiàn)了規(guī)格說明文檔的錯誤而進行較大的返工 2 開發(fā)人員通過建立原型系統(tǒng)已經學到了許多東西 至少知道了 系統(tǒng)不應該做什么 以及怎樣不去做不該做的事情 因此 在設計和編碼階段發(fā)生錯誤的可能性也比較小 這自然減少了在后續(xù)階段需要改正前面階段所犯錯誤的可能性 軟件產品一旦交付給用戶使用之后 維護便開始了 根據所需完成的維護工作種類的不同 可能需要返回到需求分析 規(guī)格說明 設計或編碼等不同階段 如圖1 4中虛線箭頭所示 23 38 快速原型的本質是 快速 開發(fā)人員應該盡可能快地建造出原型系統(tǒng) 以加速軟件開發(fā)過程 節(jié)約軟件開發(fā)成本 原型的用途是獲知用戶的真正需求 一旦需求確定了 原型將被拋棄 因此 原型系統(tǒng)的內部結構并不重要 重要的是 必須迅速地構建原型然后根據用戶意見迅速地修改原型 UNIXShell和超文本都是廣泛使用的快速原型語言 最近的趨勢是 廣泛地使用第四代語言 4GL 構建快速原型 當快速原型的某個部分是利用軟件工具由計算機自動生成的時候 可以把這部分用到最終的軟件產品中 24 38 1 4 3增量模型 增量模型也稱為漸增模型 如圖1 5所示 使用增量模型開發(fā)軟件時 把軟件產品作為一系列的增量構件來設計 編碼 集成和測試 每個構件由多個相互作用的模塊構成 并且能夠完成特定的功能 使用增量模型時 第一個增量構件往往實現(xiàn)軟件的基本需求 提供最核心的功能 第二個增量構件提供更完善的編輯和文檔生成功能 第三個增量構件實現(xiàn)拼寫和語法檢查功能 第四個增量構件完成高級的頁面排版功能 25 38 把軟件產品分解成增量構件時 應該使構件的規(guī)模適中 規(guī)模過大或過小都不好 最佳分解方法因軟件產品特點和開發(fā)人員的習慣而異 分解時惟一必須遵守的約束條件是 當把新構件集成到現(xiàn)有軟件中時 所形成的產品必須是可測試的 采用瀑布模型或快速原型模型開發(fā)軟件時 目標都是一次就把一個滿足所有需求的產品提交給用戶 增量模型則與之相反 它分批地逐步向用戶提交產品 整個軟件產品被分解成許多個增量構件 開發(fā)人員一個構件接一個構件地向用戶提交產品 從第一個構件交付之日起 用戶就能做一些有用的工作 顯然 能在較短時間內向用戶提交可完成部分工作的產品 是增量模型的一個優(yōu)點 26 38 圖1 5增量模型 27 38 增量模型的另一個優(yōu)點是 逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品 從而減少一個全新的軟件可能給客戶組織帶來的沖擊 使用增量模型的困難是 在把每個新的增量構件集成到現(xiàn)有軟件體系結構中時 必須不破壞原來已經開發(fā)出的產品 此外 必須把軟件的體系結構設計得便于按這種方式進行擴充 向現(xiàn)有產品中加入新構件的過程必須簡單 方便 也就是說 軟件體系結構必須是開放的 但是 從長遠觀點看 具有開放結構的軟件擁有真正的優(yōu)勢 這樣的軟件的可維護性明顯好于封閉結構的軟件 28 38 因此 盡管采用增量模型比采用瀑布模型和快速原型模型需要更精心的設計 但在設計階段多付出的勞動將在維護階段獲得回報 如果一個設計非常靈活而且足夠開放 足以支持增量模型 那么 這樣的設計將允許在不破壞產品的情況下進行維護 事實上 使用增量模型時開發(fā)軟件和擴充軟件功能 完善性維護 并沒有本質區(qū)別 都是向現(xiàn)有產品中加入新構件的過程 29 38 從某種意義上說 增量模型本身是自相矛盾的 它一方面要求開發(fā)人員把軟件看作一個整體 另一方面又要求開發(fā)人員把軟件看作構件序列 每個構件本質上都獨立于另一個構件 除非開發(fā)人員有足夠的技術能力協(xié)調好這一明顯的矛盾 否則用增量模型開發(fā)出的產品可能并不令人滿意 30 38 圖1 5所示的增量模型表明 必須在開始實現(xiàn)各個構件之前就全部完成需求分析 規(guī)格說明和概要設計的工作 由于在開始構建第一個構件之前已經有了總體設計 因此風險較小 圖1 6描繪了一種風險更大的增量模型 一旦確定了用戶需求之后 就著手擬定第一個構件的規(guī)格說明文檔 完成后規(guī)格說明組將轉向第二個構件的規(guī)格說明 與此同時設計組開始設計第一個構件 用這種方式開發(fā)軟件 不同的構件將并行地構建 因此有可能加快工程進度 但是 使用這種方法將冒構件無法集成到一起的風險 除非密切地監(jiān)控整個開發(fā)過程 否則整個工程可能毀于一旦 31 38 圖1 6風險更大的增量模型 32 38 1 4 4螺旋模型 軟件風險是任何軟件開發(fā)項目中都普遍存在的實際問題 項目越大 軟件越復雜 承擔該項目所冒的風險也越大 軟件風險可能在不同程度上損害軟件開發(fā)過程和軟件產品質量 因此 在軟件開發(fā)過程中必須及時識別和分析風險 并且采取適當措施以消除或減少風險的危害 33 38 構建原型是一種能使某些類型的風險降至最低的方法 正如1 4 2節(jié)所述 為了降低交付給用戶的產品不能滿足用戶需要的風險 一種行之有效的方法是在需求分析階段快速地構建一個原型 在后續(xù)的階段中也可以通過構造適當?shù)脑蛠斫档湍承┘夹g風險 當然 原型并不能 包治百病 對于某些類型的風險 原型方法是無能為力的 螺旋模型的基本思想是 使用原型及其他方法來盡量降低風險 理解這種模型的一個簡便方法 是把它看作在每個階段之前都增加了風險分析過程的快速原型模型 如圖1 7所示 完整的螺旋模型如圖1 8所示 34 38 圖1 7簡化的螺旋模型 35 38 圖1 8完整的螺旋模型 36 38 螺旋模型有許多優(yōu)點 對可選方案和約束條件的強調有利于已有軟件的重用 也有助于把軟件質量作為軟件開發(fā)的一個重要目標 減少了過多測試 浪費資金 或測試不足 產品故障多 所帶來的風險 更重要的是 在螺旋模型中維護只是模型的另一個周期 在維護和開發(fā)之間并沒有本質區(qū)別 螺旋模型主要適用于內部開發(fā)的大規(guī)模軟件項目 如果進行風險分析的費用接近整個項目的經費預算 則風險分析是不可行的 事實上 項目越大 風險也越大 因此 進行風險分析的必要性也越大 此外 只有內部開發(fā)的項目 才能在風險過大時方便地中止項目 37 38 螺旋模型的主要優(yōu)勢在于 它是風險驅動的 但是 這也可能是它的一個弱點 除非軟件開發(fā)人員具有豐富的風險評估經驗和這方面的專門知識 否則將出現(xiàn)真正的風險 當項目實際上正在走向災難時 開發(fā)人員可能還認為一切正常