軟件工程學(xué)概述共4學(xué)時

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45、只適用于大規(guī)模軟件的開發(fā),軟件開發(fā)過程模型——螺旋模型,2024/3/17,79,迭代模型,建立在Barry Boehm 的螺旋模型基礎(chǔ)上的。,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,特點,這種方法可以在生命周期早期強制性的確定項目中存在的風(fēng)險。這種方法是一個連續(xù)地發(fā)現(xiàn)、創(chuàng)造和實現(xiàn)的過程。在每個迭代過程中，促使開發(fā)小組以一種循環(huán)的、可預(yù)測的方式驅(qū)動項目制品的生產(chǎn)和制作。,2024/3/17,85,提供解決方案：,在生命周期的早期，這種方法可以及時地發(fā)現(xiàn)一些嚴(yán)重的需求理解錯誤，此時還可能修正這些錯誤。允許并鼓勵用戶反饋信息，以明確系統(tǒng)的真實需求。

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

48、,Review: 軟件過程模型,瀑布模型原型模型增量模型螺旋模型迭代模型,2024/3/17,88,軟件開發(fā)問題的癥狀,對于最終用戶的需要理解得不夠精確對需求的改變束手無策程序塊不兼容軟件不易維護(hù)或不易擴(kuò)展對項目嚴(yán)重缺陷的發(fā)現(xiàn)較晚軟件質(zhì)量低劣軟件性能令人無法接受開發(fā)組的人員按各自的方式進(jìn)行開發(fā)，如果有人改變可部分軟件，將很難進(jìn)行重組一個不可靠的構(gòu)造和發(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,失敗原因,特別的需求管理模糊和不精確的交流脆弱的構(gòu)架過度復(fù)雜未檢測出需求、設(shè)計和實現(xiàn)之間的不一致測試的不足對于項目狀況的評估過于主觀未解決存在的風(fēng)險無法控制變化的產(chǎn)生和傳播自動控制不足,2024/3/17,91,RUP,現(xiàn)在軟件產(chǎn)業(yè)界普遍認(rèn)為，開發(fā)復(fù)雜軟件項目必須采用基于UML的、以構(gòu)架為中心、用例驅(qū)動與風(fēng)險驅(qū)動相結(jié)合的迭代式增

51、量開發(fā)過程，他是世界公認(rèn)的開發(fā)復(fù)雜軟件項目的最好過程，已經(jīng)成為軟件界的“圣經(jīng)”。這一開發(fā)過程目前已經(jīng)穩(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ā)組織用以分配與管理任務(wù)和職責(zé)的一種規(guī)范化方法。

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

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

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

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

56、ss framework), 這個框架可以被改造和擴(kuò)展以適應(yīng)采納此方法的組織。,軟件過程也是軟件設(shè)計、開發(fā)、交付和維護(hù),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è)務(wù)工程,配置和,變更管理,

57、,,需求學(xué)院,,Booch 方法,,OMT,UML 0.8,SQA 過程,UML 1.1,數(shù)據(jù)工程,UI 設(shè)計,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ā)人員盡可能少地依賴那些“不可描述的經(jīng)驗”。他詳細(xì)給出了每個階段參與該過程的各種焦色，然后表示在過程中，該角色創(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ā),基于風(fēng)險前驅(qū)的原則，漸進(jìn)地展開分析、設(shè)計及其相關(guān)活動，每個迭代都會提供一次驗證和調(diào)整模型機(jī)會，推動軟件質(zhì)量的提升。,2024/3/17,117,RUP 二維過程結(jié)構(gòu),,,沿時間軸的組織結(jié)構(gòu),沿內(nèi)容軸的組織結(jié)構(gòu),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ī)劃與評估判斷架構(gòu)中關(guān)鍵風(fēng)險的經(jīng)驗高效率的驗證和評價手段多工種之間的頻繁溝通多版本工作產(chǎn)品的管理,2024/3/17,123,基礎(chǔ)保障,核心人員必要的管理與技術(shù)經(jīng)驗自動化的驗證和評價工具團(tuán)隊成

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大師提出的。大師在經(jīng)歷傳統(tǒng)軟件開發(fā)的痛苦之后，希望能夠找到一種優(yōu)秀的軟件

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

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

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

65、andards) 測試驅(qū)動(Test-driven) 重構(gòu)（Refactoring） 持續(xù)集成(Continuous integration) 小發(fā)行版(Small releases) 現(xiàn)場客戶(On-site customer) 集體代碼所有權(quán)(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 側(cè)重于具體的過程和開發(fā)技術(shù)，而CMM 更關(guān)注組織和管理上的問題 XP 缺少的一個重要內(nèi)容是“institutionalization” --Mark Paulk, SEI,2024/3/17,137,XP vs. RUP,2