軟件工程與實(shí)踐

軟件工程與實(shí)踐第一頁，共三十頁，2022年，8月28日2.3軟件開發(fā)模型2.3.1瀑布模型將軟件生命周期劃分為制定計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編寫、軟件測(cè)試和運(yùn)行維護(hù)等六個(gè)基本活動(dòng)，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級(jí)下落。

第二頁，共三十頁，2022年，8月28日2.3.2螺旋模型

螺旋模型沿著螺線進(jìn)行若干次迭代，圖2-5中的四個(gè)象限代表了以下活動(dòng).螺旋模型沿著螺線旋轉(zhuǎn)，每個(gè)螺旋推進(jìn)的過程都是漸進(jìn)的實(shí)現(xiàn)過程，整個(gè)過程的實(shí)現(xiàn)，按照”制定計(jì)劃、風(fēng)險(xiǎn)分析、實(shí)施工程和客戶評(píng)估”四個(gè)步驟循環(huán)實(shí)施。（1）制定計(jì)劃：確定軟件目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件。定義資源、進(jìn)度及其他相關(guān)項(xiàng)目信息所需要的任務(wù)，以調(diào)整項(xiàng)目的目標(biāo)和改善系統(tǒng)實(shí)施的效率。

（2）風(fēng)險(xiǎn)分析：分析評(píng)估所選方案，考慮如何識(shí)別和消除風(fēng)險(xiǎn)。從風(fēng)險(xiǎn)角度分析方案的開發(fā)策略，努力排除各種潛在的風(fēng)險(xiǎn)，有時(shí)需要通過建造原型來完成。如果某些風(fēng)險(xiǎn)不能排除，該方案立即終止，否則啟動(dòng)下一個(gè)開發(fā)步驟?；谏鲜瞿繕?biāo)，評(píng)估技術(shù)及管理的風(fēng)險(xiǎn)，以決定如何實(shí)施項(xiàng)目。

（3）實(shí)施工程：實(shí)施軟件開發(fā)和驗(yàn)證。包括系統(tǒng)需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編程、單元測(cè)試、系統(tǒng)測(cè)試和驗(yàn)證測(cè)試等項(xiàng)目具體實(shí)施的各種任務(wù)。

(4）客戶評(píng)估：評(píng)價(jià)開發(fā)工作，提出修正建議，制定下一步計(jì)劃。

第三頁，共三十頁，2022年，8月28日第四頁，共三十頁，2022年，8月28日螺旋模型的缺點(diǎn)是：(1)它可能難以使用戶相信演化方法是可控的；（2）瀑布模型要求在軟件開發(fā)的初期就完全確定軟件的需求，這在很多情況下往往是無法實(shí)現(xiàn)的。螺旋模型加入了瀑布模型所忽略的風(fēng)險(xiǎn)分析，從而彌補(bǔ)了瀑布模型的不足。螺旋模型也有一定的限制條件，這些限制條件是：1）螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)分析，但要求許多客戶接受和相信這種分析，并做出相關(guān)反應(yīng)是不容易的，因此，這種模型往往適應(yīng)于內(nèi)部的大規(guī)模軟件開發(fā)。2）如果執(zhí)行風(fēng)險(xiǎn)分析將大大影響項(xiàng)目的利潤(rùn)，那么進(jìn)行風(fēng)險(xiǎn)分析毫無意義，因此，螺旋模型只適合于大規(guī)模軟件項(xiàng)目。3）軟件開發(fā)人員應(yīng)該擅長(zhǎng)尋找可能的風(fēng)險(xiǎn)，準(zhǔn)確地分析風(fēng)險(xiǎn)，否則將會(huì)帶來更大的風(fēng)險(xiǎn)。

第五頁，共三十頁，2022年，8月28日2.3.3增量模型

增量模型和瀑布模型之間的本質(zhì)區(qū)別是：瀑布模型屬于整體開發(fā)模型，它規(guī)定在開始下一個(gè)階段的工作之前，必須完成前一階段的所有細(xì)節(jié)。而增量模型屬于非整體開發(fā)模型，它推遲某些階段或所有階段中的細(xì)節(jié)，從而較早的產(chǎn)生工作軟件。增量模型是在項(xiàng)目的開發(fā)過程中以一系列的增量方式開發(fā)系統(tǒng)。增量方式包括增量開發(fā)和增量提交。

第六頁，共三十頁，2022年，8月28日增量模型也存在以下缺陷：

（1）

由于各個(gè)構(gòu)件是逐漸并入已有的軟件體系結(jié)構(gòu)中的，所以加入構(gòu)件必須不破壞已構(gòu)造好的系統(tǒng)部分，這需要軟件具備開放式的體系結(jié)構(gòu)。

（2）

在開發(fā)過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應(yīng)這種變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而是軟件過程的控制失去整體性。第七頁，共三十頁，2022年，8月28日第八頁，共三十頁，2022年，8月28日2.3.4噴泉模型

該模型表明軟件刻畫活動(dòng)需要多次重復(fù)。例如，在編碼之前，（實(shí)踐之后），再次進(jìn)行分析和設(shè)計(jì)，其間添加有關(guān)功能，使系統(tǒng)得以演化。同時(shí)，該模型還表明活動(dòng)之間沒有明顯的間隙，例如在分析和設(shè)計(jì)之間沒有明顯的界限。第九頁，共三十頁，2022年，8月28日第十頁，共三十頁，2022年，8月28日2.3.5RAD模型RAD模型包含如下幾個(gè)開發(fā)階段(1)業(yè)務(wù)建模：業(yè)務(wù)活動(dòng)中的信息流被模型化。通過回答以下問題來實(shí)現(xiàn)：什么信息驅(qū)動(dòng)業(yè)務(wù)流程？生成什么信息？誰生成該信息？該信息流往何處？誰處理它？(2)數(shù)據(jù)建模：業(yè)務(wù)建模階段定義的一部分信息流被細(xì)化，形成一系列支持該業(yè)務(wù)所需的數(shù)據(jù)對(duì)象。標(biāo)識(shí)出每個(gè)對(duì)象的屬性，并定義這些對(duì)象間的關(guān)系。(3)處理建模：數(shù)據(jù)建模階段定義的數(shù)據(jù)對(duì)象變換成要完成一個(gè)業(yè)務(wù)功能所需的信息流。創(chuàng)建處理描述以便增加、修改、刪除或獲取某個(gè)數(shù)據(jù)對(duì)象。(4)應(yīng)用生成：RAD過程不是采用傳統(tǒng)的第三代程序設(shè)計(jì)語言來創(chuàng)建軟件，而是使用4GL技術(shù)或軟件自動(dòng)化生成輔助工具，復(fù)用已有的程序構(gòu)件(如果可能的話）或是創(chuàng)建可復(fù)用的構(gòu)件(如果需要的話)。(5)測(cè)試及反復(fù)：因?yàn)镽AD過程強(qiáng)調(diào)復(fù)用，許多程序構(gòu)件已經(jīng)是測(cè)試過的，這減少了測(cè)試時(shí)間。但新構(gòu)件必須測(cè)試，所有接口也必須測(cè)到。第十一頁，共三十頁，2022年，8月28日第十二頁，共三十頁，2022年，8月28日

RAD模型還有一種改進(jìn)型（見圖2-9），將”編碼”從V字型的頂點(diǎn)移到左側(cè)，和單元測(cè)試對(duì)應(yīng)，從而構(gòu)成水平的對(duì)應(yīng)關(guān)系。（1）從水平對(duì)應(yīng)關(guān)系看左邊是設(shè)計(jì)和分析，右邊是驗(yàn)證和測(cè)試。右邊是對(duì)左邊結(jié)果的檢驗(yàn)，即對(duì)設(shè)計(jì)和分析的結(jié)果進(jìn)行測(cè)試，以確認(rèn)是否滿足用戶的需求。(2)從圖形看RAD模型避免了瀑布模型所帶來的誤區(qū)——軟件測(cè)試是在代碼完成之后進(jìn)行。RAD模型說明軟件測(cè)試的工作很早就可以開始了，項(xiàng)目一啟動(dòng)，軟件測(cè)試的工作也就啟動(dòng)了。（3）從垂直方向看水平虛線上部表明，其需求分析、功能設(shè)計(jì)和驗(yàn)收測(cè)試等主要工作是面向用戶，要和用戶進(jìn)行充分的溝通和交流，或者是和用戶一起完成。水平虛線下部的大部分工作，相對(duì)來說，都是技術(shù)工作，在開發(fā)組織內(nèi)部進(jìn)行，由工程師完成。第十三頁，共三十頁，2022年，8月28日?qǐng)D2-9RAD改進(jìn)型第十四頁，共三十頁，2022年，8月28日2.3.6迭代式模型

迭代模型是RUP（統(tǒng)一軟件開發(fā)過程)推薦的周期模型。在RUP中，迭代被定義為：迭代包括產(chǎn)生產(chǎn)品發(fā)布（穩(wěn)定、可執(zhí)行的產(chǎn)品版本）的全部開發(fā)活動(dòng)和要使用該發(fā)布必需的所有其他外圍元素。所以，在某種程度上，迭代開發(fā)是一次完整地重復(fù)所有工作流程的過程：需求工作流程、分析設(shè)計(jì)工作流程、實(shí)施工作流程和測(cè)試工作流程。第十五頁，共三十頁，2022年，8月28日第十六頁，共三十頁，2022年，8月28日迭代過程具有以下優(yōu)點(diǎn)：

1）降低了在一個(gè)增量上的開支風(fēng)險(xiǎn)。如果開發(fā)人員重復(fù)某個(gè)迭代，那么損失只是這一個(gè)有問題的迭代的花費(fèi)。

2）降低了產(chǎn)品進(jìn)入市場(chǎng)的風(fēng)險(xiǎn)。通過在開發(fā)早期就確定風(fēng)險(xiǎn)，可以盡早來解決這個(gè)風(fēng)險(xiǎn)，而不至于在開發(fā)后期匆匆忙忙。

3）加快了整個(gè)開發(fā)工作的進(jìn)度。因?yàn)殚_發(fā)人員清楚問題的焦點(diǎn)所在，他們的工作會(huì)更有效率。

4）容易適應(yīng)需求的變化。

第十七頁，共三十頁，2022年，8月28日2.4快速原型開發(fā)軟件原型化方法是指，在獲得一組基本需求說明后，經(jīng)過快速分析構(gòu)造出一個(gè)小型的軟件系統(tǒng)（原型系統(tǒng)），滿足用戶的基本要求。用戶試用該原型系統(tǒng)，從中得到感受和啟發(fā)，并對(duì)該原型系統(tǒng)做出反映和評(píng)價(jià)，然后開發(fā)者根據(jù)用戶的意見對(duì)原型加以改進(jìn)。隨著不斷地實(shí)驗(yàn)、糾錯(cuò)、使用、評(píng)價(jià)和修改，不斷獲得新的原型版本。如此反復(fù)，逐步減少分析和通信中的誤解，彌補(bǔ)不足，進(jìn)一步確定各種需求細(xì)節(jié)，適應(yīng)需求的變更，從而提高最終產(chǎn)品的質(zhì)量。第十八頁，共三十頁，2022年，8月28日2.4.2．軟件原型的分類1.廢棄型也稱為快速建立需求規(guī)格原型RSP法。先構(gòu)造一個(gè)功能簡(jiǎn)單而且質(zhì)量要求不高的模型系統(tǒng)，針對(duì)這個(gè)模型系統(tǒng)反復(fù)進(jìn)行分析修改，從而形成較好設(shè)計(jì)思想。2.追加型也稱為快速建立漸進(jìn)原型RCP法。采用循環(huán)漸進(jìn)的開發(fā)方式，對(duì)系統(tǒng)模型作連續(xù)精化，即先構(gòu)造一個(gè)功能簡(jiǎn)單而且質(zhì)量要求不高的模型系統(tǒng)，作為最終系統(tǒng)的核心，將系統(tǒng)需要具備的性質(zhì)逐步添加上去，通過不斷地?cái)U(kuò)充修改，逐步追加新的要求，直至所有性質(zhì)全部滿足，此時(shí)的原型模型也就是最終的產(chǎn)品。第十九頁，共三十頁，2022年，8月28日2.4.3.原型軟件的周期1．原型分析原型分析是指在分析者和用戶的緊密配合下，快速確定軟件系統(tǒng)的基本要求。根據(jù)原型所要體現(xiàn)的特性（或總體結(jié)構(gòu)、處理功能，模擬性能、界面形式等），描述基本需求規(guī)格說明，以滿足開發(fā)原型的需要。當(dāng)在分析階段使用原型化方法時(shí)，必須從系統(tǒng)結(jié)構(gòu)、邏輯結(jié)構(gòu)、用戶特征、應(yīng)用約束、項(xiàng)目管理和項(xiàng)目環(huán)境等多方面來考慮，以決定是否采用原型化方法。第二十頁，共三十頁，2022年，8月28日2．原型構(gòu)造在原型分析的基礎(chǔ)上，根據(jù)基本需求規(guī)格說明，忽略細(xì)節(jié)，只考慮主要特性，快速構(gòu)造一個(gè)可運(yùn)行的系統(tǒng)。為此需要強(qiáng)有力的軟件工具的支持。第二十一頁，共三十頁，2022年，8月28日第二十二頁，共三十頁，2022年，8月28日3．原型運(yùn)行與評(píng)價(jià)原型運(yùn)行與評(píng)價(jià)階段是軟件開發(fā)人員與用戶頻繁通訊、發(fā)現(xiàn)問題、消除誤解的重要階段。其目的是驗(yàn)證原型的正確程度，進(jìn)而開發(fā)新的并修改原有的需求。第二十三頁，共三十頁，2022年，8月28日4．原型修正對(duì)于原型系統(tǒng)，一定要根據(jù)修改意見進(jìn)行修正。如果原型運(yùn)行的結(jié)果沒能滿足需求規(guī)格說明中的需求，那么就反映出對(duì)需求規(guī)格說明存在著不一致的理解或?qū)崿F(xiàn)方案不夠合理。若因?yàn)閲?yán)重的理解錯(cuò)誤而使正常操作的原型與用戶要求相違背時(shí)，就有可能產(chǎn)出廢品，因此應(yīng)當(dāng)立即放棄。第二十四頁，共三十頁，2022年，8月28日5．判定原型完成如果原型經(jīng)過修正或和改進(jìn)，獲得了參與者的一致認(rèn)可，那么原型開發(fā)的迭代過程可以結(jié)束。為此，應(yīng)判斷有關(guān)應(yīng)用的實(shí)質(zhì)是否已經(jīng)掌握，迭代周期是否可以結(jié)束等。判定的結(jié)果有兩個(gè)不同的轉(zhuǎn)向：一個(gè)是繼續(xù)迭代驗(yàn)證；另一個(gè)是進(jìn)行詳細(xì)說明，比如將需求轉(zhuǎn)化為報(bào)表，給出統(tǒng)計(jì)數(shù)字等。對(duì)于那些不能通過模型進(jìn)行說明的成分，如果必要，須提供說明，并利用屏幕等進(jìn)行討論和確定。第二十五頁，共三十頁，2022年，8月28日

6．判定原型效果考察用戶新加入的需求信息和細(xì)部說明信息，看其對(duì)模型效果有何影響？是否會(huì)影響模塊的有效性？如果使模型效果受到影響，甚至導(dǎo)致模型實(shí)效，則要進(jìn)行修正和改進(jìn)。7．整理原型和提供文檔整理原型的目的是為進(jìn)一步開發(fā)提供依據(jù)。原型的初期需求模型是一個(gè)自動(dòng)的文檔。第二十六頁，共三十頁，2022年，8月28日2.4.4快速原型的優(yōu)點(diǎn)1、增進(jìn)了軟件開發(fā)人員和用戶對(duì)系統(tǒng)需求的理解，便于將用戶模糊的功能需求明確化。2、為用戶提供了一種強(qiáng)有力的學(xué)習(xí)手段。3、易于確定系統(tǒng)的性能，是理解和確認(rèn)軟件需求規(guī)格說明的良好工具。4、按照快速建立漸進(jìn)原型（RCP）法建立的原型即為最終的產(chǎn)品。第二十七頁，共三十頁，2022年，8月28日2.5常用開發(fā)模型比較分析（1）瀑布模型不滿足客戶的需求。（2）快速原型模型關(guān)注滿足客戶需求，可能導(dǎo)致系統(tǒng)設(shè)計(jì)差