1、實(shí)驗(yàn)：軟件開發(fā)過(guò)程模型1、實(shí)驗(yàn)?zāi)康模簩W(xué)習(xí)各種軟件開發(fā)過(guò)程模型。2、實(shí)驗(yàn)內(nèi)容：在網(wǎng)上搜索資料，總結(jié)一份軟件開發(fā)過(guò)程模型的報(bào)告，并論述：假如你身為項(xiàng)目經(jīng)理， 你選擇哪一種軟件開發(fā)過(guò)程？為什么？瀑布模型：優(yōu)點(diǎn)：通過(guò)設(shè)置里程碑，明確每階段的任務(wù)與目標(biāo)，可為每階段制定開發(fā)計(jì)劃，進(jìn)行成本預(yù) 算，組織開發(fā)力量，通過(guò)階段評(píng)審，將開發(fā)過(guò)程納入正確軌道，嚴(yán)格的計(jì)劃性保證軟件 產(chǎn)品的按時(shí)交付。缺點(diǎn)：缺乏靈活性，不能適應(yīng)用戶需求的改變；開始階段的小錯(cuò)誤被逐級(jí)放大，可能導(dǎo)致 軟件產(chǎn)品報(bào)廢。原型模型：優(yōu)點(diǎn)：開發(fā)者與用戶充分交流，可以澄清模糊需求，需求定義比其他模型好得多；開發(fā)過(guò) 程與用戶培訓(xùn)過(guò)程同步；為用戶需求的改變提供

2、了充分的余地;開發(fā)風(fēng)險(xiǎn)低，產(chǎn)品柔性好； 開發(fā)費(fèi)用低，時(shí)間短；系統(tǒng)易維護(hù)，對(duì)用戶更友好缺點(diǎn)：產(chǎn)品原型在一定程度上限制了開發(fā)人員的創(chuàng)新；原型過(guò)快收斂于需求集合，而忽略了 一些基本點(diǎn);資源規(guī)劃和管理較為困難，隨時(shí)更新文檔也帶來(lái)麻煩；只注意原型是否滿意， 忽略了原型環(huán)境與用戶環(huán)境的差異螺旋模型：優(yōu)點(diǎn)：螺旋模型是將瀑布模型與快速原型模型結(jié)合起來(lái)。強(qiáng)調(diào)了其他模型所忽視的風(fēng)險(xiǎn) 分析。每一次螺旋包括4個(gè)步驟：制定計(jì)劃、風(fēng)險(xiǎn)分析、實(shí)施工程、客戶評(píng)估。缺點(diǎn)：強(qiáng)調(diào)風(fēng)險(xiǎn)分析，但要求許多客戶接受并相信這種分析，是不容易的。敏捷開發(fā)模型：優(yōu)點(diǎn)：短周期開發(fā)。增量開發(fā)。由程序員和測(cè)試人員編寫的自動(dòng)化測(cè)試來(lái)監(jiān)控開發(fā) 進(jìn)度。通過(guò)

3、口頭溝通、測(cè)試和源代碼來(lái)交流系統(tǒng)的結(jié)構(gòu)和意圖。編寫代碼之前先寫測(cè) 試代碼。也叫做測(cè)試先行。缺點(diǎn)：團(tuán)隊(duì)的組建較難，人員素質(zhì)要求較高。對(duì)測(cè)試員要求完全掌握各種腳本語(yǔ)言編 程，會(huì)單元測(cè)試?？焖僭湍Ｐ停≧apid Prototype Model）優(yōu)點(diǎn)：建造一個(gè)快速原型，實(shí)現(xiàn)客戶或未來(lái)的用戶與系統(tǒng)的交互，用戶或客戶對(duì)原型進(jìn)行評(píng) 價(jià)，進(jìn)一步細(xì)化待開發(fā)軟件的需求。通過(guò)逐步調(diào)整原型使其滿足客戶的要求，開發(fā)人員可以 確定客戶的真正需求是什么；開發(fā)客戶滿意的軟件產(chǎn)品?？焖僭头椒梢钥朔俨寄Ｐ偷?缺點(diǎn)，減少由于軟件需求不明確帶來(lái)的開發(fā)風(fēng)險(xiǎn)，具有顯著的效果。缺點(diǎn)：（1）客戶與開發(fā)者對(duì)原型理解不同；（2）準(zhǔn)確的原

4、型設(shè)計(jì)比較困難;（3）不利于開 發(fā)人員的創(chuàng)新。增量模型（Incremental Model）又稱演化模型。優(yōu)點(diǎn)：（1）采用增量模型的優(yōu)點(diǎn)是人員分配靈活，剛開始不用投入大量人力資源；（2）如果 核心產(chǎn)品很受歡迎，則可增加人力實(shí)現(xiàn)下一個(gè)增量；（3）可先發(fā)布部分功能給客戶，對(duì)客戶 起到鎮(zhèn)靜劑的作用。缺點(diǎn)：（1）并行開發(fā)構(gòu)件有可能遇到不能集成的風(fēng)險(xiǎn)，軟件必須具備開放式的體系結(jié)構(gòu)；（2） 增量模型的靈活性可以使其適應(yīng)這種變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很 容易退化為邊做邊改模型，從而是軟件過(guò)程的控制失去整體性。噴泉模型（fountain model）（也稱面向?qū)ο蟮纳嫫谀Ｐ?，OO模型）優(yōu)

5、點(diǎn)：噴泉模型不像瀑布模型那樣，需要分析活動(dòng)結(jié)束后才開始設(shè)計(jì)活動(dòng)，設(shè)計(jì)活動(dòng)結(jié)束后 才開始編碼活動(dòng)。該模型的各個(gè)階段沒有明顯的界限，開發(fā)人員可以同步進(jìn)行開發(fā)。其優(yōu)點(diǎn) 是可以提高軟件項(xiàng)目開發(fā)效率，節(jié)省開發(fā)時(shí)間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過(guò)程。缺點(diǎn)：由于噴泉模型在各個(gè)開發(fā)階段是重疊的，因此在開發(fā)過(guò)程中需要大量的開發(fā)人員，因 此不利于項(xiàng)目的管理。此外這種模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對(duì) 可能隨時(shí)加入各種信息、需求與資料的情況。智能模型（四代技術(shù)（4GL）優(yōu)點(diǎn)：用戶界面極端友好，即使沒有受過(guò)訓(xùn)練的非專業(yè)程序員，也能用它編寫程序；它是一 種聲明式、交互式和非過(guò)程性編程語(yǔ)言。4GL還具有高效

6、的程序代碼、智能缺省假設(shè)、完 備的數(shù)據(jù)庫(kù)和應(yīng)用程序生成器。缺點(diǎn)：僅限于事務(wù)信息系統(tǒng)的中、小型應(yīng)用程序的開發(fā)?；旌夏Ｐ停╤ybrid model）優(yōu)點(diǎn)：給企業(yè)管理者和開發(fā)者提供了一個(gè)舞臺(tái)，是每個(gè)模型的長(zhǎng)處得到發(fā)揮。缺點(diǎn)：對(duì)企業(yè)的管理和技術(shù)都提出了更高的要求。RUP模型優(yōu)點(diǎn)：RUP是建立在非常優(yōu)秀的軟件工程原則基礎(chǔ)上的，例如迭代，需求驅(qū)動(dòng)，基于結(jié)構(gòu) 化的過(guò)程開發(fā)。RUP提供了幾個(gè)方法，例如每一次迭代產(chǎn)生一個(gè)工作原型，在每一個(gè)階段的 結(jié)束決定項(xiàng)目是否繼續(xù)，這些方法提供了對(duì)開發(fā)過(guò)程的非常直觀的管理。rational公司已 經(jīng)并將繼續(xù)對(duì)RUP進(jìn)行開發(fā)，使這個(gè)基于html的軟件工程能夠被裁減以適合你的組織

7、的實(shí) 際需要。缺點(diǎn)：RUP僅僅包含了開發(fā)過(guò)程。它沒有完全覆蓋軟件過(guò)程，從圖1能夠明顯看出，它丟 失了維護(hù)和技術(shù)支持這兩個(gè)重要的階段。RUP不支持組織內(nèi)的多項(xiàng)目開發(fā)，導(dǎo)致組織內(nèi)的 大范圍的重用無(wú)法實(shí)現(xiàn)。RUP缺少開發(fā)商的支持。你能自動(dòng)完成軟件過(guò)程的每一個(gè)方面?rational提供了所有的工具供你選擇，例如是否有rational help desk或者rational persistence modeling 4. RUP在度量管理，重用管理，人員管理和測(cè)試上有缺陷10.IPD模型優(yōu)點(diǎn)：非常適合于復(fù)雜的大型開發(fā)項(xiàng)目，尤其涉及到軟硬件結(jié)合的項(xiàng)目。小。從整個(gè)產(chǎn)品角 度出發(fā)，流程綜合考慮了從系統(tǒng)工程、研

8、發(fā)(硬件、軟件、結(jié)構(gòu)工業(yè)設(shè)計(jì)、測(cè)試、資料開發(fā) 等)、制造、財(cái)務(wù)到市場(chǎng)、采購(gòu)、技術(shù)支援等所有流程。是一個(gè)端到端的流程。IPD流程是一個(gè)階段性模型，具有瀑布模型的影子。該模型通過(guò)使用全面而又復(fù)雜的流程來(lái) 把一個(gè)龐大而又復(fù)雜的系統(tǒng)進(jìn)行分解并降低風(fēng)險(xiǎn)。一定程度上，該模型是通過(guò)流程成本來(lái)提 高整個(gè)產(chǎn)品的質(zhì)量并獲得市場(chǎng)的占有。缺點(diǎn):該模型通過(guò)使用全面而又復(fù)雜的流程，由于該流程沒有定義如何進(jìn)行流程回退的機(jī)制， 因此對(duì)于需求經(jīng)常變動(dòng)的項(xiàng)目該流程就顯得不大適合了。并且對(duì)于一些小的項(xiàng)目，也不是非 常適合使用該流程。論述：我認(rèn)為RUP(Rational Unified Process)模型測(cè)試模型在軟件開發(fā)過(guò)程是比較好的一種開發(fā) 模型。原因:1.它是一個(gè)面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程。它描述了一系列相關(guān)的軟件工程流程， 它們具有相同的結(jié)構(gòu)，即相同的流程構(gòu)架。RUP為在開發(fā)組織中分配任務(wù)和職責(zé)提供了一種規(guī)范方法，其目標(biāo)是確保在可預(yù)計(jì)的時(shí)間 安排和預(yù)算內(nèi)開發(fā)出滿足最終用戶需求的高品質(zhì)的軟件。RUP具有兩個(gè)軸，一個(gè)軸是時(shí)間軸，這是動(dòng)態(tài)的。另一個(gè)軸是工作流軸，這是靜態(tài)的。在時(shí)間軸上，RUP劃分了四個(gè)階段：初始階段、細(xì)化階段、構(gòu)造階段和發(fā)布階段。每個(gè)階 段都使用了迭代的概念。在工作流軸上，RUP設(shè)計(jì)了六個(gè)核心工作流程和三個(gè)核心支撐工作流程，核心工作流軸包 括：業(yè)務(wù)建模工作