《軟件工程-理論、方法與實踐》課件第2章

第2章軟件過程2.1軟件過程概述2.2軟件過程模型2.3Rational統(tǒng)一過程2.4敏捷開發(fā)過程2.5面向方面的軟件開發(fā)本章小結習題

2.1軟件過程概述

軟件過程具有以下一些特征：

(1)過程描述了所有的主要活動。

(2)過程在一定限制下使用資源、產生中間和最終的產品。

(3)過程由以某種方式連接的子過程構成，活動以一定的順序組織。

(4)每個過程活動都有入口和出口準則以便確立活動的開始和結束。

(5)每個過程都有達到活動目標的相關指導原則。軟件過程可概括為三類：基本過程類、支持過程類和組織過程類。

基本過程類包括需求獲取和定義過程、設計過程、實現過程、驗證過程和維護過程；支持過程類包括文檔過程、配置管理過程、質量保證過程、聯合評審過程、審計過程等；組織過程類包括基礎設施過程、改進過程以及培訓過程。

2.2軟件過程模型

軟件開發(fā)過程也被稱作為軟件生命周期，因為它描述了一個軟件產品從建立概念到實現、交付、使用、維護的過程。

軟件過程模型是對軟件開發(fā)過程的抽象描述。模型一般來說是對實際過程的簡化，過程模型通常包括軟件活動、軟件產品和人員的角色等。盡管從不同的角度可以構造很多不同的軟件過程模型，但一般來說，有一些通用的軟件開發(fā)模式和模型。2.2.1瀑布模型

瀑布模型是被廣泛認可的第一個軟件工程模型。在模型中，過程的主要活動按需求分析和定義、系統(tǒng)和軟件設計、編碼和單元測試、集成和系統(tǒng)測試、運行和維護幾個階段順序展開，瀑布模型的這幾個活動階段與軟件生存期相吻合，模型示意如圖2.1所示。圖2.1瀑布模型

1．需求分析和定義

需求分析和定義階段著重回答“軟件要解決什么問題?”。這個階段，通過咨詢用戶和與用戶商討準確地分析和定義系統(tǒng)的功能、限制和目標，分析和定義的結果被詳細地用需求規(guī)格說明來描述。需求分析和定義是軟件過程的早期階段活動，若需求定義不準確將會造成所交付的軟件存在嚴重的問題，并會為軟件的修改付出很大的代價。

2．系統(tǒng)和軟件設計

設計階段需要回答“系統(tǒng)應該如何實現?”這個問題，因此設計階段主要是要根據需求劃分系統(tǒng)的組件，包括建立系統(tǒng)總體結構(又稱為概要設計或初步設計)和確立構成系統(tǒng)的組件的細節(jié)(又稱詳細設計)。

3．編碼和單元測試

編碼和單元測試階段又稱為實現階段。實現階段通過采用適合的程序設計語言，編碼完成軟件的設計，形成系統(tǒng)的程序集合。單元模塊的測試通常在本階段內完成。

4．集成和系統(tǒng)測試

這個階段對已通過單元測試的程序單元進行集成和測試，以保證整個系統(tǒng)可以滿足用戶的需求。在測試完成后系統(tǒng)可以被交付給用戶。

5．運行和維護

軟件交付后并不意味著開發(fā)機構完成了所有的開發(fā)任務，一般來說，運行和維護是軟件生存期中最長的一個階段。軟件的本質特性決定了軟件交付后不可避免地會遭遇變更，維護涉及對未被發(fā)現的錯誤的糾正和對用戶提出的新需求的完善。2.2.2演化式開發(fā)模型

很多時候，軟件開發(fā)的初期并不能準確、全面地發(fā)掘出軟件的需求，軟件的開發(fā)只能從并非準確的需求描述開始。演化式開發(fā)的主要思想是：首先經過概要的分析構建一個初始的系統(tǒng)(原型)，將原型提交給用戶評價，根據反饋信息改進系統(tǒng)形成新的原型(中間系統(tǒng))，重復這個過程直至系統(tǒng)可以滿足用戶的需要而產生最終可交付的系統(tǒng)。圖2.2為演化式開發(fā)模型。圖2.2演化式開發(fā)模型演化式開發(fā)過程中包含著并行的、循環(huán)的需求分析、開發(fā)和驗證等活動。一般來說有兩種類型的演化式開發(fā)過程，即探索式開發(fā)和拋棄式開發(fā)。

探索式開發(fā)：通過與用戶一起工作，探索需求逐步開發(fā)直至交付一個最終的系統(tǒng)。通常開發(fā)從理解系統(tǒng)的部分需求開始，通過加入用戶提出的新的需求不斷改進系統(tǒng)。

拋棄式開發(fā)：主要目標是幫助更好地理解用戶的需求和進行準確的需求定義。一旦系統(tǒng)真正的需求被確立，原型即被拋棄。通常適用于需求難以導出的項目。2.2.3形式化變換模型

某些安全性、可靠性要求很高的軟件系統(tǒng)，可以采用形式轉化模型來開發(fā)。在形式化變換模型中，開發(fā)過程實際上是一個數學變換過程，系統(tǒng)的需求定義是一個用數學語言描述的形式化定義，傳統(tǒng)的設計、實現和單元測試過程被形式化變換過程所取代，軟件的開發(fā)過程是通過一系列的數學變換將形式化的需求定義轉換成可執(zhí)行程序的過程。圖2.3和圖2.4反映了該過程。變換過程的每一步都會將形式化模型轉換成更詳細、更具體的數學表達直到轉換成等價的程序。圖2.3形式化開發(fā)過程圖2.4形式化變換過程2.2.4面向復用的開發(fā)

面向復用的開發(fā)模型如圖2.5所示。開發(fā)人員在確定需求的基礎上，尋找可以符合要求的已有組件，這些組件可以是可購買到的通用組件，也可以是自身機構已開發(fā)成功的組件。之后應對獲得的組件信息進行分析，在此基礎上適當修改需求以適應組件，然后根據設計和選用的體系結構框架及選擇的組件進行系統(tǒng)集成和測試。面向復用的開發(fā)模式區(qū)別于其他開發(fā)過程的主要地方是組件分析、需求調整、面向復用的設計以及開發(fā)和集成活動。圖2.5面向復用的開發(fā)模式

(1)組件分析：根據需求定義尋找合適的組件。在很多情況下，不一定存在和所期望的功能十分一致的組件，更多情況下找到的組件僅能提供單一或部分所需要的功能。

(2)需求調整：這個階段根據搜索到的組件信息對需求進行進一步的分析，調整部分需求以利于采用合適的組件開發(fā)。

(3)面向復用的設計：這個階段的主要任務是根據可復用的組件設計系統(tǒng)的結構或復用已有的系統(tǒng)框架，同時對于沒有有效組件可利用的軟件部分要進行設計。

(4)開發(fā)和集成：集成組件、開發(fā)無法復用的軟件部分。2.2.5增量開發(fā)

瀑布模型由于需求的改變會造成系統(tǒng)的修改代價較大，演化式開發(fā)會帶來系統(tǒng)結構上的缺陷和程序維護上的困難，增量開發(fā)則可以平衡這兩種開發(fā)模式帶來的問題。

增量開發(fā)模式由Mills提出，其主要內容是將系統(tǒng)的需求定義、設計和實現分解成若干增量，依次開發(fā)和交付，以減少開發(fā)過程中的返工，也可以讓用戶體驗先期交付的系統(tǒng)，然后提出更準確、詳細的需求。圖2.6為增量開發(fā)模型。圖2.6增量開發(fā)模型增量開發(fā)的優(yōu)勢在于：系統(tǒng)較早交付的增量通常能滿足一些關鍵的需求，因此客戶不必等到整個系統(tǒng)交付就可以使用系統(tǒng)中較早交付的部分。同時增量開發(fā)模式需求的定義可以分階段展開，客戶從早期交付的增量部分體驗系統(tǒng)有助于后期增量需求的獲取，因此，增量模型可以靈活地適應需求的變化，從而降低整個工程的開發(fā)風險。增量開發(fā)模式也存在缺陷，有些情況下將系統(tǒng)功能映射成適當大小的增量并不是很容易的，增量需求的逐步定義也讓找出所有增量公共部分的需求有些困難，增量模型靈活適應需求變化的特性也會容易退化成邊做邊改的模式，從而使軟件過程容易失去控制。Beck1999年提出的極限編程是增量式開發(fā)的一種變化形式。2.2.6螺旋模型

螺旋模型是由BarryBoehm在1988年正式提出的，它將瀑布模型和快速原型模型結合起來，其過程活動不是按順序進行而是以螺旋式展開，強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統(tǒng)。螺旋模型如圖2.7所示。圖2.7螺旋模型螺旋開發(fā)模式將軟件過程分成若干個循環(huán)階段，每個循環(huán)分成四個部分活動：

(1)目標確立：確立本階段的目標、可選方案和約束條件。

(2)風險分析：分析工程風險，開展降低風險的活動。

(3)開發(fā)驗證：設計、編碼和驗證系統(tǒng)。

(4)評審和規(guī)劃：對項目進行評審，決策是否要開展下一個循環(huán)周期。使用螺旋模型有一定的局限性：

(1)螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，并做出相關反應是不容易的，畢竟影響軟件的因素復雜。另外風險分析需要一定的代價，如果軟件預算不充裕，風險分析較難實行。因此，這種模型往往適用于內部的大規(guī)模軟件開發(fā)。

(2)如果執(zhí)行風險分析大大影響項目的利潤，那么進行風險分析毫無意義，因此，螺旋模型只適合于大規(guī)模軟件項目。

(3)軟件開發(fā)人員應具備發(fā)現潛在風險的能力，可以較準確地分析風險，否則將會帶來更大的風險。

2.3Rational統(tǒng)一過程

Rational統(tǒng)一過程RUP(RationalUnifiedProcess)是基于UML的一種現代軟件開發(fā)過程模型。這是一種混合過程模型，融合了一些通用過程元素。Rational統(tǒng)一過程強調開發(fā)和維護模型，采用UML作為系統(tǒng)模型的描述語言，UML的使用使其具有豐富的語義表達。

Rational統(tǒng)一過程經過了許多年的成熟期并反映了許多人和公司的集體經驗。圖2.8是其發(fā)展歷程示意圖。圖2.8Rational統(tǒng)一過程示意圖

Rational統(tǒng)一過程中的軟件生命周期在時間上被分解為四個連續(xù)的階段，分別是：初始階段(Inception)、細化階段(Elaboration)、構造階段(Construction)和交付階段(Transition)，如圖2.9所示。橫軸代表了制定開發(fā)過程的時間，體現了過程的動態(tài)結構，縱軸表現了過程的靜態(tài)結構。每個階段結束于一個主要的里程碑(MajorMilestone)，每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執(zhí)行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。圖2.9Rational統(tǒng)一過程模型

2.4敏捷開發(fā)過程

敏捷開發(fā)是由業(yè)界專家針對企業(yè)現狀提出的，讓軟件開發(fā)團隊具有快速工作、響應變化能力的價值觀和原則。這些專家認為：

●“個體和交互”勝過“過程和工具”。

●“可以工作的軟件”勝過“面面俱到的文檔”。

●“客戶合作”勝過“合同談判”。

●“響應變化”勝過“遵循計劃”。敏捷開發(fā)包括一系列的方法，主流的有如下七種：

(1)?XP(極限編程)的思想源自KentBeck和WardCunningham在軟件項目中的合作經歷。

(2)?SCRUM是一種迭代的增量化過程，用于產品開發(fā)或工作管理。

(3)?CrystalMethods(水晶方法系列)由AlistairCockburn在20世紀90年代末提出。

(4)?FDD(Feature-DrivenDevelopment，特性驅動開發(fā))由PeterCoad、JeffdeLuca、EricLefebvre共同開發(fā)，是一套針對中小型軟件開發(fā)項目的開發(fā)模式。

(5)?ASD(AdaptiveSoftwareDevelopment，自適應軟件開發(fā))由JimHighsmith在1999年正式提出。

(6)?DSDM(動態(tài)系統(tǒng)開發(fā)方法)是眾多敏捷開發(fā)方法中的一種，倡導以業(yè)務為核心，快速而有效地進行系統(tǒng)開發(fā)。

(7)輕量型RUP其實是個過程的框架，它可以包容許多不同類型的過程，主張以敏捷型方式來使用RUP。敏捷開發(fā)的模型，如圖2.10所示。圖中的兩個圓圈表示不同的視角上的敏捷實踐，包括開發(fā)者視角和項目管理者的視角，下面從內向外依次介紹。圖2.10敏捷開發(fā)過程模型

(1)測試驅動開發(fā)(Test-DrivenDevelopment)是敏捷開發(fā)的最重要的部分。

(2)持續(xù)集成(ContinuousIntegration)。

(3)配對編程(Pair-Programming)。

(4)站立會議(StandUp)。

(5)小版本發(fā)布(FrequentReleases)。

(6)文檔最小化(MinimalDocumentation)。

(7)聚焦協(xié)作(CollaborativeFocus)表現為代碼共享，在敏捷開發(fā)中，代碼是歸團隊所有而不是歸某些人，每個人都有權利獲得系統(tǒng)任何一部分的代碼，然后修改它。

(8)現場客戶(CustomerEngagement)。

(9)自動測試(AutomatedTesting)。

(10)可調整計劃(AdaptivePlanning)。

2.5面向方面的軟件開發(fā)

橫切關注點(CrosscuttingConcern)：理解橫切關注點的一個好途徑是用例子來說明。圖2.11是一個簡單的圖形編輯器(FigureEditor)的Aspect和類模塊的示意。圖2.11圖形編輯器中的方面橫切關注點圖中每個方法必須實現這個橫切關注點。如果只使用面向對象的設計方法，所實現的橫切關注點就會分散在系統(tǒng)各處，如圖2.11所示。AOP的主要思想是將這些橫切關注點抽象為方面Aspect，在一個方面模塊中實現顯示更新，在系統(tǒng)的其他地方無須考慮任何實現，僅在系統(tǒng)編譯或運行時，由編織器Weaver將方面Aspect“織入”代碼中，如圖2.12所示。圖2.12AOP實現本章小結

軟件開發(fā)需要有效地過程活動，不同的軟件過程以不同的方式組織軟件活動。軟件過程的抽象可以