軟件工程學概述共4學時

1、2024/3/17,1,第1章 軟件工程學概述（共4學時）,學習要求：1、了解軟件危機產生的原因和消除軟件危機的根本途徑； 2、 掌握軟件工程,軟件工程學,軟件生命周期和軟件過程的概念；3、理解軟件工程的基本原理； 4、 掌握常見的幾種開發(fā)模型(過程)；,2024/3/17,2,第1章 軟件工程學概述,1.1軟件危機 軟件危機的定義，產生原因，解決途徑1.2軟件工程 軟件工程的概念、基本原理和軟件工程方法

2、學1.3軟件的生命周期1.4軟件過程 介紹瀑布模型、快速原型模型、增量模型、螺旋模型,2024/3/17,3,第1章 軟件工程學概述,1.1 軟件危機,1、20世紀60年代中期之前 軟件規(guī)模小，編寫和應用在自己的小范圍，軟件=程序。,2、20世紀60——70年代中期 出現(xiàn)“軟件作坊”，軟件的數(shù)量急劇膨脹，軟件維護工作量和費用驚人增長，個別軟件不可維護；軟件危機出現(xiàn)。,一、軟件危機及其表現(xiàn),2024/

3、3/17,4,1、什么是軟件危機？,軟件危機是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題。（1）、如何開發(fā)軟件滿足用戶的需要。（2）、如何維護大量的已有軟件。,2、軟件危機的典型表現(xiàn),（1）、對軟件開發(fā)的成本和進度估計常常不準確。,（2）、用戶對“已完成”的軟件系統(tǒng)不滿意的現(xiàn)象常發(fā)生。,（3）、軟件產品的質量時常靠不住。,（4）、軟件常常不可維護。,,（5）、軟件沒有適當?shù)奈臋n資料。,2024/3/17,5,（6）、軟件

4、成本在計算機的系統(tǒng)總成本中所占的比列逐年上升。,（7）、軟件開發(fā)的生產率提高的速度遠遠不及計算機應用普及的速度。,,二、軟件危機產生的原因,1、軟件本身的特點有關（邏輯部件）,（1）、缺乏“可見性”，管理和控制軟件開發(fā)的過程困難。,（2）、由于是邏輯部件，所以在使用過程中不會“用壞”。,2、軟件開發(fā)與維護的方法有關,三、消除軟件危機的途徑,2024/3/17,6,1、軟件危機可以被消滅嗎？,不能消滅，因為：（1）、軟件的特點沒有改變

5、（2）、用戶的需求在不斷的增長，任何軟件從縱向來看不可能永遠滿足用戶的需要，必然要出現(xiàn)軟件危機。,2、消除軟件危機的途徑,（1）、對計算機軟件和軟件開發(fā)有一個正確的認識。,（2）、技術措施 使用實踐證明成功的技術和方法，開發(fā)和使用更好的軟件工具。,2024/3/17,7,（3）、管理措施 使用科學的方法管理和組織計算機軟件的開發(fā)。,1.2軟件工程,一、軟件工程的介紹,1、什么是軟件工程？,采用工程的概念、原理、技

6、術和方法來開發(fā)與維護軟件，把經過時間和實踐證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發(fā)出高質量的軟件并有效地維護它，這就稱為軟件工程。,2、軟件工程的特性,2024/3/17,8,（1）、軟件工程關注于大型軟件的構造,,（2）、軟件工程的中心課題是控制復雜性,（3）、軟件經常變化,（4）、注重開發(fā)軟件的效率,（5）、和諧的合作是開發(fā)軟件的關鍵,（6）、軟件必須有效地支持它的用戶的工作,（7）、在軟件工程領域中是

7、具有一種文化背景的替具有另一種文化背景的創(chuàng)造產品,二、軟件工程的基本原理,B.W.Boehm在1983的一篇論文中提出了軟件工程的7條基本原理。,2024/3/17,9,1、用分階段的生命周期計劃嚴格管理,2、堅持進行階段評審,3、實行嚴格的產品控制,4、采用現(xiàn)代程序設計技術,5、結果應能清楚地審查,6、開發(fā)小組的成員應盡量少而精,7、承認不斷改進軟件工程實踐的必要性,三、軟件工程方法學,2024/3/17,10,,1、什么是軟件工程方

8、法學？,通常把軟件生命周期過程中使用的一整套技術和方法的集合稱為軟件工程方法學，也稱范型。,2、軟件工程方法學的要素,（1）、方法 完成軟件開發(fā)的各項任務的技術方法，“怎樣做”。,（2）、工具 為運用方法而提供的軟件支撐環(huán)境。,（3）、過程 為了獲得高質量的軟件所需要完成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟。,2024/3/17,11,3、目前常用的軟件工程方法學,（1）、傳統(tǒng)方法學 又

9、稱為生命周期方法學或結構化范型。,（2）、面向對象方法學 它是以數(shù)據(jù)為主線，把數(shù)據(jù)和對數(shù)據(jù)的操作緊密地結合起來的方法學。 A、把對象作為唯一的軟件結構 B、把所有對象劃分成類 C、按照父類與子類的關系，把相關類組成一個層次結構的系統(tǒng) D、對象之間只能通過發(fā)送消息相互聯(lián)系,2024/3/17,12,1.3軟件生命周期,一、軟件生命周期,1、什么是軟件生命周期？,軟件從定義、開發(fā)、使用和維護，直到最終被廢

10、棄，所經歷的漫長的時期稱為軟件的生命周期。,2、軟件生命周期的若干階段,（1）、軟件定義時期 A、問題定義回答系統(tǒng)“要解決的問題是什么”。 B、可行性研究回答“對上面確定的問題是否有行得通的解決辦法”。,2024/3/17,13,C、需求分析 確定“為了解決這個問題，目標系統(tǒng)必須做什么”，即目標系統(tǒng)應該有那些功能。,（2）、開發(fā)時期,A、總體設計 解決“怎樣實現(xiàn)目標系統(tǒng)？”。B、詳細

11、設計 解決“應該怎樣具體實現(xiàn)目標系統(tǒng)？”。C、編碼和單元測試 寫出正確、易理解和維護的程序模塊。,2024/3/17,14,D、綜合測試 通過各種類型的測試使軟件達到預定的要求。,（3）、運行維護期 使軟件持久滿足用戶的需要直到廢棄。 改正性維護：改正系統(tǒng)中存在的錯誤。 適應性維護：使軟件適應軟硬件環(huán)境的變化。 完善性維護：根據(jù)用戶要求使軟件更加完善。

12、 預防性維護：為將來的維護活動預先做準備。,2024/3/17,15,1.4軟件過程,軟件過程是近十年來人們關注的焦點。軟件過程是為開發(fā)高質量軟件所需要完成的任務的框架。軟件工程是有創(chuàng)造力、有知識的人在定義好的、成熟的軟件過程框架中進行的。,2024/3/17,16,軟件過程,軟件過程層次圖,質量焦點,過程,方法,工具,2024/3/17,17,軟件過程,軟件過程提供了一個框架，在該框架下可以建立一個軟件開發(fā)的綜合計劃：若干框架活動

13、適用于所有軟件項目，而不在乎其規(guī)模和復雜性。若干不同任務的集合----每一個集合都由任務、里程碑、交付物以及質量保證點組成----使得框架活動適應于不同軟件項目的特征和項目組的需求。若干保護性活動----如軟件質量保證、軟件配置管理、測試與度量----它們貫穿于整個過程模型之中。保護性活動獨立于任何一個框架活動，且貫穿于整個過程之中。,2024/3/17,18,軟件過程,,,,,,,里程碑、交付物,SQA點,公共過程框架,框架活動,

14、保護性活動,任務集合,工作任務,2024/3/17,19,軟件過程,軟件過程可分為三大類：基本過程類：是構成軟件生存周期主要部分的那些過程，包括獲取、供應、開發(fā)、操作、維護等過程。支持過程類：可穿插到基本過程中提供支持的一系列過程，包括文檔開發(fā)、配置管理、質量保證、驗證、確認、聯(lián)合評審、審計、問題解決等過程。組織過程類：一個組織用來建立、實施一種基礎結構、并不斷改進該基礎結構的過程，包括管理、基礎、改進、培訓等過程。,2024/3

15、/17,20,軟件過程模型,軟件過程模型是軟件開發(fā)的指導思想和全局性框架，軟件過程模型的提出和發(fā)展反映了人們對軟件過程的某種認識觀，體現(xiàn)了人們對軟件過程認識的提高和飛躍。,2024/3/17,21,什么是過程？,軟件工程中的目標就是開發(fā)和維護軟件及相關產品,2024/3/17,22,當前主流的軟件過程,CMMRUPMSFXP,2024/3/17,23,過程鐵三角,過程：把各部分集成在一起 －－CMM,2024/3/17,24,

16、軟件過程,了解軟件過程掌握軟件過程模型: 瀑布模型、原型模型、增量模型、迭代模型了解RUP了解XP,2024/3/17,25,過程,過程就是針對某一給定目標的一系列運作步驟，[IEEE-STD-610] 是在過程環(huán)境下的一系列有序活動。所謂活動（Activity）就是過程對象一次狀態(tài)改變，也叫過程步(Step)。活動起始態(tài)和活動結果態(tài)表征了活動的進行。可以說一切事物的發(fā)生、發(fā)展、消亡都離不開過程，都寓于過程之中。,2024/3/

17、17,26,過程的一般定義,,2024/3/17,27,煮蛋的啟示,2024/3/17,28,軟件過程,軟件過程是將用戶的需求轉化成有效的軟件解決方案的一系列活動。許多軟件組織無法正確定義和控制這一過程，但這恰恰是組織改進的關鍵。,2024/3/17,29,軟件過程(Cont.),過程的好壞由結果狀態(tài)與預期狀態(tài)的差異決定，也就是目標成果質量的好壞。規(guī)程（Procedure）是人們對客觀事物運動規(guī)律 的理解和掌握，使規(guī)范了的過程。軟

18、件過程是為了獲得高質量軟件產品所需要完 成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟。軟件過程必須科學、合理，才能開發(fā)出高質量 的軟件產品。,2024/3/17,30,軟件過程(Cont.),軟件過程又稱軟件生存周期過程，是軟件生存周期內為達到一定目標而必須實施的一系列相關過程的集合。早期：立項、需求分析、設計、編碼、測試、交付、維護、退役,2024/3/17,31,軟件過程(Cont.),項目計劃就是安排實際

19、的過程，制作項目計劃首先要定義過程。項目計劃是某個軟件過程模型的實例。軟件過程是人類制作產物的一系列活動，而過去的軟件工程師把產物和人分離，只研究產品過程及其質量，假定人力、物力資源是無限大、無限好?，F(xiàn)在認識到面對實際資源實施軟件過程學，求相對最佳質量才是有效的。,2024/3/17,32,軟件過程(Cont.),現(xiàn)在的軟件生命周期過程包括：早期：立項、需求分析、設計、編碼、測試、交付、維護、退役又加入了：管

20、理各種活動、質量保證環(huán)境基礎設施配置、文檔管理等。,2024/3/17,33,軟件開發(fā)—問題的循環(huán)解決過程,狀態(tài)描述問題定義技術開發(fā)方案綜述,2024/3/17,34,軟件開發(fā)過程,為開發(fā)小組的活動順序提供向導詳細說明那些制品將被開發(fā)，以及什么時候開發(fā)指導每一個開發(fā)人員和整個開發(fā)組的工作為監(jiān)控和度量項目的產品和活動提供準則,2024/3/17,35,軟件工程 — 方法學,傳統(tǒng)方法學面向對象的方法學,2024/3/17

21、,36,傳統(tǒng)方法學(生命周期方法學),仍然是使用十分廣泛的軟件工程方法學。采用結構化技術來完成軟件開發(fā)的各項任務，并使用適當?shù)能浖ぞ呋蜍浖こ汰h(huán)境來支持結構化技術的運用。從上而下，順序地完成軟件開發(fā)的各階段任務。,2024/3/17,37,軟件過程模型,瀑布模型（Waterfall）原型模型（Prototype）增量模型（Incremental）螺旋模型（Spiral）迭代模型（Iterative）,2024/3/17,3

22、8,瀑布模型(線性順序模型),瀑布式模型包含以下活動：系統(tǒng)/信息工程和建模軟件需求分析設計代碼生成測試維護,2024/3/17,39,基本概念,軟件生存期（過程）模型： 軟件生存期是軟件產品或系統(tǒng)一系列相關活動的全周期。從形成概念開始，經過研制，交付使用，在使用中不斷增補修訂，直到最后被淘汰，讓位于新的軟件產品的過程。對軟件生存期的不同劃分，形成了不同的軟件生存期模型。,2024/3/17,40,軟件

23、工程的傳統(tǒng)途徑—生命周期方法學,生命周期方法學的基本內容 從時間角度對軟件開發(fā)和維護的復雜問題進行分解，把軟件生命的漫長周 期依次劃分為若干個階段，每個階段有相對獨立的任務，然后逐步完成每個階 段的任務。 生命周期方法學的應用方法 從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發(fā)；前一個階段任 務的完成是后一個階段工作的前提和基礎，而后一個階段任務通常是使前一階 段提出的解法更進一步的具體化，

24、加進了更多的實現(xiàn)細節(jié)。 階段過渡方法 每一個階段的開始和結束都有嚴格標準，前一階段結束的標準是后一階段工作 開始的標準。 技術審查和管理復審?；靖拍?文檔及其作用。生命周期各階段的基本任務 問題定義→可行性研究→ 需求分析→ 總體設計（概要設計） → 詳細設計→ 編碼和單元測試→ 綜合測試→ 軟件維護。,,,,軟件工程（生命周期各階段的基本任務）,問題定義,可行性研究

25、,需求分析,總體設計,詳細設計,編碼與單元測試,綜合測試,軟件維護,,,,,,,,,,,,,,,,,,,,,,,,,,,,,要解決的問題是什么？,問題性質、工程目標和規(guī)模的報告,分析員：實際用戶+負責人,是否有解決辦法？,分析員,高層邏輯模型，準確和具體的工程規(guī)模和目標，成本/效益分析等可行性報告,為了解決的問題，目標系統(tǒng)必須做什么？準確確定系統(tǒng)的功能,系統(tǒng)的邏輯模型（數(shù)據(jù)流圖+數(shù)據(jù)字典+簡要算法）,,,如何解決這些問題,模塊劃分軟件

26、結構,如何具體地實現(xiàn)系統(tǒng)：每個模塊的流程圖（程序的詳細規(guī)格說明）,,通過各種類型的測試，使軟件達到預定的要求,,寫出正確的容易理解和容易維護的程序模塊,,通過各種必要的維護活動使系統(tǒng)持久地滿足用戶的需要,,生命周期法各階段的工作小結,生命周期法各階段的工作小結,2024/3/17,44,“生命周期法”的特點,階段具有順序性和依賴性推遲實現(xiàn)的觀點質量保證的觀點每個階段都必須完成規(guī)定的文檔每個階段結束前都要對所完成的文檔進行評審，

27、以便盡早發(fā)現(xiàn)問題，改正錯誤。,2024/3/17,45,軟件工程——瀑布模型,瀑布模型,問題定義,特點：1） 階段間具有順序性和依賴性 2） 推遲實現(xiàn)的觀點 3） 質量保證的觀點。,可行性研究,需求分析,總體設計,詳細設計,編碼與單元測試,綜合測試,軟件維護,,,,,,,,,,,,,,,,,,,,,,,,,,,,,軟件定義時期,,,,,軟件開發(fā)時期,,,,軟件維護時期,,,,2024/3/

28、17,46,軟件開發(fā)過程模型,瀑布模型的特征從上一項活動中接受該項活動的工作對象，作為輸入。利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，作為輸出傳給下一項活動對該項活動實施的工作進行評審。若其工作得到確認，則繼續(xù)下一項活動。,2024/3/17,47,瀑布模型 — 特點,文檔驅動的模型 階段間具有順序性和依賴性推遲實現(xiàn)的觀點質量保證的觀點,2024/3/17,48,思考？？？？,傳統(tǒng)瀑布模型存在什么問題？,

29、2024/3/17,49,傳統(tǒng)的瀑布模型 — 存在什么問題？？？,傳統(tǒng)的瀑布模型過于理想化了，事實上，人在工作過程中不可能不犯錯誤。 在設計階段可能發(fā)生規(guī)格說明文檔中的錯誤。 而設計上的缺陷或錯誤可能在實現(xiàn)過程中顯現(xiàn)出 來。 在綜合測試階段將發(fā)現(xiàn)需求分析、設計或編碼階段 的許多錯誤。,2024/3/17,50,,Tom Gilb：　“假如你不積極地解決你項目中存在的風險，它們就會積極地解決掉你”瀑布方法會掩飾項

30、目中真正的風險，當你太晚發(fā)現(xiàn)它們時已無濟于事。,2024/3/17,51,瀑布模型 — 問題,實際項目很少按照該模型給出的順序進行用戶常常難以清楚地給出所有需求用戶必須有耐心開發(fā)者常常被不必要地耽擱,2024/3/17,52,軟件開發(fā)過程模型,瀑布模型的缺點：從認識論角度看，人的認識是一個多次反復循環(huán)的過程，不可能一次完成。但瀑布模型中劃分的幾個階段，沒有反映出這種認識過程的反復性。軟件開發(fā)是一個知識密集型的開發(fā)活動，需要相互

31、合作完成，但瀑布模型沒有體現(xiàn)這一點。,2024/3/17,53,瀑布模型 — 實際的瀑布模型,需求分析,驗證,規(guī)格說明,驗證,設計,驗證,編碼,測試,綜合測試,維護,,,,,,,,,,,,,,變化的需求,驗證,,,,,,,,,,,2024/3/17,54,軟件開發(fā)過程模型,具有維護循環(huán)的軟件生存期的瀑布模型,2024/3/17,55,軟件開發(fā)過程模型——原型模型,基本思想在獲取一組基本的需求定義后，利用高級軟件工具的可開發(fā)環(huán)境，快速地

32、建立一個目標系統(tǒng)的最初版本，并把它交給用戶試用、補充和修改，再進行新的版本開發(fā)。反復進行這個過程，直到得出系統(tǒng)的“精確解”，即用戶滿意為止。經過這樣一個反復補充和修改的過程，應用系統(tǒng)的“最初版本”就逐步演變?yōu)橄到y(tǒng)的“最終版本”。,2024/3/17,56,原型模型,快速建立起來的可以在計算機上運行的程序，他所能完成的功能往往是最終產品能完成的功能的一個子集。,2024/3/17,57,原型模型 — 適用情況,用戶定義了一組一般性目標，但

33、不能標識出詳細的輸入、處理及輸出需求；開發(fā)者可能不能確定算法的有效性、操作系統(tǒng)的適應性或人機交互的形式；……原型模型可能是最好的選擇,2024/3/17,58,原型模型(Cont.),原型模型從需求收集開始。 開發(fā)者和用戶在一起定義軟件的總體目標，標識出已知的需求，并規(guī)劃出進一步定義的區(qū)域。然后是“快速設計”，快速設計集中于軟件那些對用戶可見部分的表示。“快速設計”導致原型的建造。 原型由用戶評估，并進一步精化待開發(fā)軟件的

34、需求，逐步調整原型使其滿足客戶的要求。同時開發(fā)者對將要做的事情有更好的理解， 這個過程是迭代的。,2024/3/17,59,原型模型(Cont.),快速原型,驗證,規(guī)格說明,驗證,設計,驗證,編碼,測試,綜合測試,維護,,,,,,變化的需求,驗證,,,,,,,,,,,維護過程,,,,,,開發(fā)過程,,,,,,2024/3/17,60,原型模型—存在的問題,用戶似乎看到的是軟件的工作版本，其實……開發(fā)者常常需要實現(xiàn)上的折衷，以使原型能夠盡

35、快工作,2024/3/17,61,原型模型,在“需求分析”、“原型設計”兩個階段中，開發(fā)者和用戶一起為想象中的系統(tǒng)的某些主要部分定義需求和規(guī)格說明，并由開發(fā)者在規(guī)格說明級用原型描述語言構造一個系統(tǒng)原型，它代表了部分系統(tǒng)，包括那些為滿足用戶需求的必要屬性。該原型可用來幫助分析和設計工作，而不是一個軟件產品。,2024/3/17,62,原型模型,在演示原型期間，用戶可以根據(jù)他所期望的系統(tǒng)行為來評價原型的實際行為。如果原型不能滿意地運行，用戶

36、能立刻找出問題和不可接受的地方，并與開發(fā)者重新定義需求。該過程一直持續(xù)到用戶認為該原型能成功地體現(xiàn)想象中的系統(tǒng)的主要部分功能為止。在這期間，用戶和開發(fā)者都不要為程序算法或設計技巧等枝節(jié)問題分心，而是要確定開發(fā)者是否理解了用戶的意思，同時試驗實現(xiàn)它們的若干方法。,2024/3/17,63,原型模型特征,原型特征軟件原型是軟件的最初版本，以最少的費用、最短的時間開發(fā)出的、以反映最后軟件的主要特征的系統(tǒng)。它具有以下特征：(1)它是一個可實

37、際運行的系統(tǒng)。,2024/3/17,64,原型模型特征,(2)它沒有固定的生存期。一種極端是扔掉原型（以最簡便方式大量借用已有軟件，做出最后產品的模型，證實產品設想是成功的，但產品中并不使用）；另一種極端是最終產品的一部分即增量原型（先做出最終產品的核心部分，逐步增加補充模塊），演進原型居于其中（每一版本扔掉一點，增加一點，逐步完善至最終產品）。,2024/3/17,65,原型模型特征,(3)從需求分析到最終產品都可作原型，即可為不同目

38、標作原型。(4)它必須快速、廉價。(5)它是迭代過程的集成部分，即每次經用戶評價后修改、運行，不斷重復雙方認可。,2024/3/17,66,原型模型評價,原型法的評價優(yōu)點1.原型法在得到良好的需求定義上比傳統(tǒng)生存周期法好得多，可處理模糊需求，開發(fā)者和用戶可充分通信。2.原型系統(tǒng)可作為培訓環(huán)境，有利于用戶培訓和開發(fā)同步，開發(fā)過程也是學習過程。3.原型給用戶以機會更改心中原先設想的、不盡合理的最終系統(tǒng)。4.原型可低風險開發(fā)柔性

39、較大的計算機系統(tǒng)。5.原型增加使系統(tǒng)更易維護、對用戶更友好的機會。6.原型使總的開發(fā)費用降低，時間縮短。,2024/3/17,67,缺點1.“模型效應”或“管中窺豹”。對于開發(fā)者不熟悉的領域把次要部分當作主要框架，做出不切題的原型。2.原型迭代不收斂于開發(fā)者預先的目標。即每次更改，為了消除錯誤，次要部分越來越大，“淹沒”了主要部分。3.原型過快收斂于需求集合，而忽略了一些基本點。4.資源規(guī)劃和管理較為困難，隨時更新文檔也帶來

40、麻煩。5.長期在原型環(huán)境上開發(fā)，只注意得到滿意的原型，容易“遺忘”用戶環(huán)境和原型環(huán)境的差異。,原型模型評價,2024/3/17,68,適用范圍：原型開發(fā)可以應用于軟件生存周期的不同階段，也可以替代生存期的部分或全部階段，具體可以用于以下領域：1.輔助分析和確定用戶需求的任務。2.作為軟件設計的一種工具。例如：研究系統(tǒng)設計的可行性和適應性。3.作為一種解決不確定性的工具。例如：研究一種新技術的效果，逐步使其適應預定的環(huán)境。4.作

41、為一種實驗工具。5.充作同步培訓工具。6.“一次性”的應用。例如寫一個能運行的程序，一旦得到答案，該程序將不再使用。7.作為軟件維護的輔助工具。特別是在用戶需求不穩(wěn)定，維護工作量很大的情況下，要求大量的重新設計工作。,原型模型評價,2024/3/17,69,增量模型,融合了瀑布模型的基本成分和原型的迭代特征。采用隨著日程時間的進展而交錯的線性序列。,2024/3/17,70,增量模型(Cont.),需求分析,驗證,規(guī)格說明,驗證,

42、設計,驗證,維護,,,,,,,,,,,,,,針對每個構件完成詳細設計、編碼和集成，經測試后交付給用戶,,,2024/3/17,71,增量模型 (Cont.),分析,分析,分析,分析,設計,設計,設計,設計,編碼,編碼,編碼,編碼,測試,測試,測試,測試,,增量1,,增量2,增量3,增量4,,,,,,,,,,,,,2024/3/17,72,增量模型 (Cont.),增量模型融合了瀑布模型的基本成分和原型的迭代特性。例如，使用增量模型開

43、發(fā)字處理軟件基本的文件管理、編輯和文檔生成功能。更完善的編輯和文檔生成能力。實現(xiàn)拼寫和文法檢查功能。完成高級的頁面布局功能。,2024/3/17,73,增量模型 (Cont.),第一個增量往往是核心產品每一個增量均發(fā)布一個可操作產品早期的增量是最終產品的“可拆卸”版本,2024/3/17,74,軟件開發(fā)過程模型,噴泉模型噴泉模型認為軟件生命周期的各個階段是相互重疊和多次反復的。主要用于面向對象方法中,2024/3/17,

44、75,軟件開發(fā)過程模型——螺旋模型,在原型基礎上，進行多次原型反復并增加風險評估，形成螺旋模型。,2024/3/17,76,軟件開發(fā)過程模型——螺旋模型,2024/3/17,77,軟件開發(fā)過程模型——螺旋模型,2024/3/17,78,螺旋模型分析在螺旋模型結構中，維護只是螺旋模型的另一個周期，在維護和開發(fā)之間本質上并沒有區(qū)別，從而解決了做太多測試或未作足夠測試所帶來的風險。適用條件內部的大規(guī)模軟件的開發(fā)，不太適合合同軟件。一般

45、只適用于大規(guī)模軟件的開發(fā),軟件開發(fā)過程模型——螺旋模型,2024/3/17,79,迭代模型,建立在Barry Boehm 的螺旋模型基礎上的。,2024/3/17,80,迭代模型(Cont.),2024/3/17,81,迭代模型(Cont.),Each iteration results in an executable release.,2024/3/17,82,,2024/3/17,83,,Time,,,Risk,Waterfall

46、 Risk,,Risk Profiles,2024/3/17,84,特點,這種方法可以在生命周期早期強制性的確定項目中存在的風險。這種方法是一個連續(xù)地發(fā)現(xiàn)、創(chuàng)造和實現(xiàn)的過程。在每個迭代過程中，促使開發(fā)小組以一種循環(huán)的、可預測的方式驅動項目制品的生產和制作。,2024/3/17,85,提供解決方案：,在生命周期的早期，這種方法可以及時地發(fā)現(xiàn)一些嚴重的需求理解錯誤，此時還可能修正這些錯誤。允許并鼓勵用戶反饋信息，以明確系統(tǒng)的真實需求。

47、這種方法使開發(fā)小組重視項目中最關鍵的問題，而屏蔽掉那些使他們遠離項目真實風險的問題。不斷地迭代測試能夠給出項目狀況的客觀評價。,2024/3/17,86,提供解決方案: (Cont.),盡早地發(fā)現(xiàn)需求、設計和實現(xiàn)中的不一致。在整個項目生命周期中更加平均地分配開發(fā)組的工作量，特別是測試小組的工作量。開發(fā)組可以不斷打在開發(fā)中進行學習從而改進過程。在整個生命周期中，項目相關人員可以通過具體證據(jù)了解項目狀況。,2024/3/17,87

48、,Review: 軟件過程模型,瀑布模型原型模型增量模型螺旋模型迭代模型,2024/3/17,88,軟件開發(fā)問題的癥狀,對于最終用戶的需要理解得不夠精確對需求的改變束手無策程序塊不兼容軟件不易維護或不易擴展對項目嚴重缺陷的發(fā)現(xiàn)較晚軟件質量低劣軟件性能令人無法接受開發(fā)組的人員按各自的方式進行開發(fā)，如果有人改變可部分軟件，將很難進行重組一個不可靠的構造和發(fā)布過程,2024/3/17,89,Symptoms of SW

49、 Development Problems,User or business needs not metRequirements churnModules don’t integrateHard to maintainLate discovery of flawsPoor quality or end-user experiencePoor performance under loadNo coordinated team

50、 effortBuild-and-release issues,2024/3/17,90,失敗原因,特別的需求管理模糊和不精確的交流脆弱的構架過度復雜未檢測出需求、設計和實現(xiàn)之間的不一致測試的不足對于項目狀況的評估過于主觀未解決存在的風險無法控制變化的產生和傳播自動控制不足,2024/3/17,91,RUP,現(xiàn)在軟件產業(yè)界普遍認為，開發(fā)復雜軟件項目必須采用基于UML的、以構架為中心、用例驅動與風險驅動相結合的迭代式增

51、量開發(fā)過程，他是世界公認的開發(fā)復雜軟件項目的最好過程，已經成為軟件界的“圣經”。這一開發(fā)過程目前已經穩(wěn)定、成熟。這就是：,2024/3/17,92,RUP,RUP—Rational Unified Process,2024/3/17,93,Rational Unified Process—RUP,Rational 統(tǒng)一過程是由Rational 軟件公司開發(fā)和營銷的一種軟件工程過程，是開發(fā)組織用以分配與管理任務和職責的一種規(guī)范化方法。

52、這個過程的目的是在預定的進度和預算范圍內，開發(fā)出滿足最終用戶需要的高質量軟件。,2024/3/17,94,RUP捕獲的6項最佳商業(yè)實踐,被證明是解決軟件開發(fā)過程中根本問題的方法,2024/3/17,95,最佳軟件開發(fā)實踐 Best Practices,迭代地開發(fā)軟件 Develop Iteratively管理需求 Manage Requirements應用基于構件的構架 Use Component Architectures

53、為軟件建立可視化的模型 Model Visually (UML) 不斷地驗證軟件質量 Continuously Verify Quality控制軟件的變更 Manage Change,2024/3/17,96,RUP的目標,按照預先制定的時間計劃和經費預算，開發(fā)出高質量的軟件產品以滿足最終用戶的需求,2024/3/17,97,RUP是什么？,是一種軟件工程過程是一個過程產品有自己的過程框架捕獲了現(xiàn)代軟件開發(fā)中的最佳實踐,

54、2024/3/17,98,RUP的三大特點,用例驅動以架構為中心迭代和增量開發(fā),2024/3/17,99,用例驅動,用Use Case作為劃分問題的組織單元，分析和設計活動的局部粒度都遵循這一劃分原則。Use Case的定義反映可系統(tǒng)外部要素根據(jù)特定目標使用擬建系統(tǒng)的狀況，能確保問題的局部劃分粒度適當，保持了全局與局部的平衡。,2024/3/17,100,,2024/3/17,101,RUP的整體架構,2024/3/17,102,R

55、UP的迭代模型,2024/3/17,103,RUP的關鍵概念,2024/3/17,104,RUP,RUP將這些最佳實踐活動以一種適當?shù)男问浇Y合起來，從而適應了廣泛的項目和開發(fā)組織。,RUP 是一個過程產品(process product)。Rational (IBM) 軟件公司開發(fā)并維護著這個產品，并將其與Rational 軟件公司自己的一系列軟件開發(fā)工具集成。,2024/3/17,105,RUP,RUP 有自己的過程框架 (proce

56、ss framework), 這個框架可以被改造和擴展以適應采納此方法的組織。,軟件過程也是軟件設計、開發(fā)、交付和維護,2024/3/17,106,RUP —簡要歷史,RUP 2000,RUP 5.5,RUP 5.0,ROP 4.1,ROP 4.0,Rational 方法,Objective 過程3.8,,,,,,,200019991998199719961995,,實時,ROOM,,業(yè)務工程,配置和,變更管理,

57、,,需求學院,,Booch 方法,,OMT,UML 0.8,SQA 過程,UML 1.1,數(shù)據(jù)工程,UI 設計,UML 1.2,基于WEB的開發(fā),,UML1.3,,,,,,,,,2024/3/17,107,誰在使用RUP?,電信業(yè)Ericsson、Alcatel、MCI 交通、航空、國防Lockheed-Martin、British Aerospace制造業(yè)Xerox、Volvo、Intel金融業(yè)Visa、Merrill

58、Lynch、Schwab 系統(tǒng)集成業(yè)Ernst & Young、Oracle、Deloitte & Touche,2024/3/17,108,RUP,RUP核心是解決可操作性問題，幫助開發(fā)人員盡可能少地依賴那些“不可描述的經驗”。他詳細給出了每個階段參與該過程的各種焦色，然后表示在過程中，該角色創(chuàng)建的制品。,,2024/3/17,109,Rational Unified Process 的主要工件，及這些工件間的信息

59、流,2024/3/17,110,2024/3/17,111,2024/3/17,112,2024/3/17,113,2024/3/17,114,2024/3/17,115,2024/3/17,116,增量和迭代開發(fā),基于風險前驅的原則，漸進地展開分析、設計及其相關活動，每個迭代都會提供一次驗證和調整模型機會，推動軟件質量的提升。,2024/3/17,117,RUP 二維過程結構,,,沿時間軸的組織結構,沿內容軸的組織結構,2024/3/

60、17,118,RUP的生命開發(fā)周期,2024/3/17,119,RUP的生命開發(fā)周期,2024/3/17,120,RUP的生命開發(fā)周期,2024/3/17,121,RUP的生命開發(fā)周期,2024/3/17,122,主要困難,多層次持續(xù)的規(guī)劃與評估判斷架構中關鍵風險的經驗高效率的驗證和評價手段多工種之間的頻繁溝通多版本工作產品的管理,2024/3/17,123,基礎保障,核心人員必要的管理與技術經驗自動化的驗證和評價工具團隊成

61、員之間有高效的溝通工具軟件配置與變更管理工具,2024/3/17,124,RUP 的裁減,RUP 僅僅是一個通用的過程框架，需要根據(jù)實際情況裁減。,2024/3/17,125,A Process is not Enough to Build a System,2024/3/17,126,XP,XP（Extreme Programming），它是由Kent Beck大師提出的。大師在經歷傳統(tǒng)軟件開發(fā)的痛苦之后，希望能夠找到一種優(yōu)秀的軟件

62、開發(fā)方法。大師總結了大量的軟件的成功和失敗的因素之后，提出了改進軟件開發(fā)方法的四個要素：溝通（communication）、簡單化（simplicity）、反饋（feedback）、勇氣（courage）。這形成了XP的核心價值觀。在經歷了數(shù)年的發(fā)展，XP在軟件開發(fā)的各方面都發(fā)展出了眾多的方法來支持軟件開發(fā)。,2024/3/17,127,XP是什么？,敏捷方法的代表。Kent Beck在他的開篇之作《Extreme Programmi

63、ng Explained – Embrace Change》中提出－97年一種高度動態(tài)的過程，它通過非常短的迭代周期來應對軟件開發(fā)中的變化強調有效測試和演化設計――fowler,2024/3/17,128,XP的目標,在規(guī)定的時間生產出滿足客戶需要的軟件,2024/3/17,129,什么時候需要XP？,需求不明確、變化快高風險：在特定的時間內，面對一個相當難開發(fā)的系統(tǒng) 中小型團隊（人數(shù)不超過10 個）,2024/3/17,130

64、,XP的系統(tǒng)隱喻,,2024/3/17,131,XP體現(xiàn)四個價值目標,溝通（communication）簡化（simlicity）反饋（feedback）勇氣（courage）,2024/3/17,132,XP的12個核心實踐,規(guī)劃策略(Planning game) 系統(tǒng)隱喻(System Metaphor) 簡單設計(Simple design) 配對編程(pair programming) 編碼標準(Coding st

65、andards) 測試驅動(Test-driven) 重構（Refactoring） 持續(xù)集成(Continuous integration) 小發(fā)行版(Small releases) 現(xiàn)場客戶(On-site customer) 集體代碼所有權(Collective ownership) 一周40小時 (40-hour week),2024/3/17,133,實踐之間的互相支持,2024/3/17,134,XP項目的狀態(tài)

66、圖,2024/3/17,135,XP的計劃/反饋循環(huán),,2024/3/17,136,從CMM角度看XP,XP部分滿足或大部分滿足了CMM 2-3 級KPA 的要求，而基本上沒有涉及CMM 4-5 級的KPAXP 側重于具體的過程和開發(fā)技術，而CMM 更關注組織和管理上的問題 XP 缺少的一個重要內容是“institutionalization” --Mark Paulk, SEI,2024/3/17,137,XP vs. RUP,2