《軟件項(xiàng)目管理》課件第3章

第3章開(kāi)發(fā)方法選擇3.1選擇技術(shù)3.2選擇過(guò)程模型3.3交付速度3.4邊做邊改模型3.5瀑布模型3.6瀑布模型的變種3.7螺旋模型3.8原型開(kāi)發(fā)3.9分類原型的其它方面3.10漸進(jìn)原型3.11增量交付

3.12階段交付3.13面向進(jìn)度的設(shè)計(jì)

3.14漸進(jìn)交付

3.15快速應(yīng)用開(kāi)發(fā)模型

3.16并發(fā)開(kāi)發(fā)模型

3.17面向開(kāi)發(fā)工具的設(shè)計(jì)

3.18動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)方法

3.19極限編程

3.20領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

3.21成品軟件

3.22管理迭代過(guò)程

3.23選擇最合適的生命周期3.24小結(jié)

3.1選擇技術(shù)

內(nèi)部軟件開(kāi)發(fā)通常意味著：

·開(kāi)發(fā)人員和用戶屬于同一組織；

·將正在考慮的應(yīng)用程序嵌入，使其成為現(xiàn)有計(jì)算機(jī)系統(tǒng)的一部分；

·要使用的方法學(xué)和技術(shù)不是由項(xiàng)目經(jīng)理來(lái)選擇，而是由組織內(nèi)部的標(biāo)準(zhǔn)來(lái)規(guī)定。但是軟件公司在為不同的外部客戶成功地實(shí)現(xiàn)的開(kāi)發(fā)項(xiàng)目中，每個(gè)項(xiàng)目使用的方法學(xué)和技術(shù)都要進(jìn)行單獨(dú)的評(píng)審。這樣就需要在項(xiàng)目分析的基礎(chǔ)上做出評(píng)價(jià)，有的組織將這類決策制定過(guò)程稱為“技術(shù)規(guī)劃”。因此即使是內(nèi)部項(xiàng)目開(kāi)發(fā)，也要考慮與先前的項(xiàng)目使用不同的方法進(jìn)行開(kāi)發(fā)的、新項(xiàng)目的具體特征。

通過(guò)對(duì)項(xiàng)目的分析以選擇最合適的方法學(xué)和技術(shù)。方法學(xué)包括像統(tǒng)一軟件開(kāi)發(fā)過(guò)程(UnifiedSoftwareDevelopmentProcess，USDP)、結(jié)構(gòu)化系統(tǒng)分析和設(shè)計(jì)方法(StructuredSystemsAnalysisandDesignMethod，SSADM)以及領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)(Domain-DrivenDesign，DDD)等，這些技術(shù)包括相應(yīng)的應(yīng)用構(gòu)造和自動(dòng)測(cè)試環(huán)境。與產(chǎn)品和活動(dòng)一樣，選擇的技術(shù)將影響：

·開(kāi)發(fā)人員的培訓(xùn)需求；

·要招聘的員工類型；

·開(kāi)發(fā)環(huán)境(包括硬件和軟件環(huán)境)；

·系統(tǒng)維護(hù)安排。

因此，要選擇某項(xiàng)技術(shù)，需要從這幾個(gè)方面，進(jìn)行詳細(xì)分析，下面將闡述如何分析項(xiàng)目以選擇合適的技術(shù)。

3.1.1識(shí)別項(xiàng)目是目的驅(qū)動(dòng)還是產(chǎn)品驅(qū)動(dòng)

要區(qū)別項(xiàng)目的目標(biāo)是為了生產(chǎn)一種產(chǎn)品，還是為了滿足一定目的。一方面，項(xiàng)目可能生產(chǎn)客戶規(guī)定的產(chǎn)品，客戶負(fù)責(zé)驗(yàn)證該產(chǎn)品；另一方面，項(xiàng)目也可能為了滿足一定的目的，有多種方法實(shí)現(xiàn)該目的，例如可以開(kāi)發(fā)一個(gè)新的信息系統(tǒng)，來(lái)改進(jìn)組織提供的服務(wù)，這時(shí)作為目的的服務(wù)標(biāo)準(zhǔn)是協(xié)議的主題，而不是特定信息系統(tǒng)的特征。

很多軟件項(xiàng)目有2個(gè)階段。第1階段是目的驅(qū)動(dòng)項(xiàng)目，以驗(yàn)證該軟件系統(tǒng)能滿足需求，是一個(gè)推薦活動(dòng)過(guò)程；第2階段實(shí)際創(chuàng)建該軟件產(chǎn)品，是產(chǎn)品驅(qū)動(dòng)項(xiàng)目，經(jīng)過(guò)第1階段的驗(yàn)證，可以進(jìn)行規(guī)模生產(chǎn)。理想情況下，項(xiàng)目經(jīng)理有明確的目的，可以盡可能自由地選擇滿足目的的方法。例如在一個(gè)剛起步的公司中目的可能是要可靠地、準(zhǔn)確地給員工支付報(bào)酬，并具有較低的管理費(fèi)用，那么就沒(méi)有必要在開(kāi)始時(shí)就使用特定的軟件解決方案，當(dāng)然可能存在例外情況。有時(shí)，項(xiàng)目的目的是不確定的或是未達(dá)成一致意見(jiàn)的主題。人們可能會(huì)遇到各種問(wèn)題，但沒(méi)有人知道如何正確地解決這些問(wèn)題。ICT(InformationCommunicationTechnology)專家可能為解決某些問(wèn)題提供幫助，但是有些問(wèn)題則需要來(lái)自其他領(lǐng)域的專家的幫助，在這種情況下可能需要考慮軟系統(tǒng)方法(SoftSystemsMethodology,SSM。軟系統(tǒng)方法是一項(xiàng)運(yùn)用系統(tǒng)思考解決非系統(tǒng)問(wèn)題的定性研究技術(shù)，主要用于解決包含大量社會(huì)的、政治的以及人為因素的問(wèn)題)。

識(shí)別項(xiàng)目是目的驅(qū)動(dòng)還是產(chǎn)品驅(qū)動(dòng)有助于選擇合適的技術(shù)。3.1.2分析其他項(xiàng)目特征

區(qū)別軟件項(xiàng)目之間的差異非常重要，因?yàn)樵谀骋画h(huán)境下適用的技術(shù)和方法，在另外的情境下就可能不適用了。了解項(xiàng)目特征便于選擇合適的技術(shù)，通常會(huì)回答下面的問(wèn)題：

要實(shí)現(xiàn)的系統(tǒng)是面向數(shù)據(jù)的還是面向過(guò)程的？面向數(shù)據(jù)的(Data-Oriented)系統(tǒng)通常指的是有實(shí)際數(shù)據(jù)庫(kù)的信息系統(tǒng)；面向過(guò)程的(Process-Oriented)系統(tǒng)指的是嵌入式控制系統(tǒng)；同時(shí)具備兩個(gè)要素的系統(tǒng)很少見(jiàn)。前者的系統(tǒng)界面是與組織的接口，例如庫(kù)存管理系統(tǒng)，是組織管理訂購(gòu)原材料的信息系統(tǒng)；后者的系統(tǒng)界面是與機(jī)器的接口，例如空調(diào)控制系統(tǒng)，控制建筑物空調(diào)設(shè)備的嵌入式系統(tǒng)；二者兼具的系統(tǒng)，例如，上面的庫(kù)存管理系統(tǒng)可以控制一個(gè)自動(dòng)化倉(cāng)庫(kù)。有人認(rèn)為OO(Object-Oriented)方法更適用于面向過(guò)程的系統(tǒng)，在這類系統(tǒng)中控制要比數(shù)據(jù)庫(kù)系統(tǒng)重要。

·要開(kāi)發(fā)的軟件是通用工具還是面向特定應(yīng)用領(lǐng)域的？通用工具的例子有電子表格或字處理程序包，特定應(yīng)用領(lǐng)域的程序包如航空公司機(jī)票預(yù)訂系統(tǒng)等。

·要實(shí)現(xiàn)的應(yīng)用程序是否是特殊類型的(已為這類應(yīng)用程序開(kāi)發(fā)了特定的工具)？例如：

·是否包含并發(fā)處理？要考慮使用適合這類系統(tǒng)的分析和設(shè)計(jì)技術(shù)。

·要?jiǎng)?chuàng)建的系統(tǒng)是不是基于知識(shí)的？專家系統(tǒng)都有規(guī)則(在應(yīng)用于某個(gè)問(wèn)題時(shí)會(huì)產(chǎn)生“專家建議”)，而且有開(kāi)發(fā)這類系統(tǒng)的特定方法和工具。

·要產(chǎn)生的系統(tǒng)大量使用計(jì)算機(jī)圖形嗎？

·要?jiǎng)?chuàng)建的系統(tǒng)是不是安全至上的？例如系統(tǒng)中的故障是否會(huì)危及人的生命？如果是，測(cè)試就非常重要。

·要?jiǎng)?chuàng)建的系統(tǒng)是用來(lái)執(zhí)行已定義好的服務(wù)還是作為一種興趣和娛樂(lè)？如果軟件用來(lái)娛樂(lè)，那么設(shè)計(jì)和評(píng)價(jià)會(huì)有別于一般的軟件產(chǎn)品。

·要運(yùn)行的系統(tǒng)的硬件/軟件環(huán)境的特點(diǎn)是什么？最終軟件要運(yùn)行的環(huán)境可以不同于其他開(kāi)發(fā)環(huán)境。嵌入式軟件可能在大型開(kāi)發(fā)機(jī)(有許多支持軟件工具，比如編譯器、調(diào)試器和靜態(tài)分析工具等)上開(kāi)發(fā)，但是軟件要下載到小型處理器上運(yùn)行。獨(dú)立的桌面應(yīng)用程序需要不同于大型機(jī)或客戶/服務(wù)器環(huán)境的方法。3.1.3識(shí)別重要的項(xiàng)目風(fēng)險(xiǎn)

項(xiàng)目開(kāi)始時(shí)，即使忽略許多影響項(xiàng)目的重要因素，管理人員還是期待有詳細(xì)描述的計(jì)劃。但是只有在仔細(xì)調(diào)查用戶需求的基礎(chǔ)上，才能估計(jì)項(xiàng)目需要多少工作量。開(kāi)始時(shí)項(xiàng)目的不確定性越大，項(xiàng)目的風(fēng)險(xiǎn)就越大。但是一旦識(shí)別了特定領(lǐng)域的不確定性，就可以采取相應(yīng)的措施來(lái)降低這些不確定性。

項(xiàng)目的不確定性與項(xiàng)目的產(chǎn)品、過(guò)程和資源有關(guān)。

·產(chǎn)品不確定性(ProductUncertainty)。對(duì)需求的理解如何？用戶可能不能確定要構(gòu)造的信息系統(tǒng)究竟要做什么。例如有些環(huán)境變化非?？欤灾劣诒砻嫔蠝?zhǔn)確和有效的需求陳述很快就過(guò)時(shí)了。

·過(guò)程不確定性(ProcessUncertainty)。要開(kāi)發(fā)的項(xiàng)目可能會(huì)使用對(duì)組織來(lái)說(shuō)完全嶄新的方法，開(kāi)發(fā)方法的任何變更都會(huì)引入不確定性。例如極限編程(XP)或新的應(yīng)用開(kāi)發(fā)環(huán)境。

資源不確定性(PesourceUncertainty)。這里主要指具有合適的能力和經(jīng)驗(yàn)的人員的可獲得性，需要的資源數(shù)越多或項(xiàng)目周期越長(zhǎng)，隱含的風(fēng)險(xiǎn)就越高。

·有些因素增加了不確定性，例如不斷地變更需求；而另一些因素增加了復(fù)雜性，例如軟件規(guī)模。因此，需要不同的策略來(lái)處理這些截然不同的風(fēng)險(xiǎn)。3.1.4考慮與實(shí)現(xiàn)有關(guān)的用戶需求

項(xiàng)目計(jì)劃人員要保證假設(shè)或約束不會(huì)影響項(xiàng)目目標(biāo)，例如開(kāi)發(fā)校園管理系統(tǒng)的確切的規(guī)格說(shuō)明。但是有時(shí)這類約束不可避免，比如整個(gè)組織要求使用相同的程序包來(lái)確保兼容性。

客戶組織通常會(huì)規(guī)定軟件承包商必須采用的標(biāo)準(zhǔn)。例如，軟件供應(yīng)商要通過(guò)ISO9000或CMMI認(rèn)證，這會(huì)影響項(xiàng)目的實(shí)施方法。3.1.5選擇生命周期方法

選擇項(xiàng)目所使用的開(kāi)發(fā)方法學(xué)和生命周期方法會(huì)受到前面問(wèn)題的影響。對(duì)很多軟件開(kāi)發(fā)人員來(lái)說(shuō)方法的選擇很明顯，使用過(guò)去用過(guò)的方法需要注意當(dāng)前項(xiàng)目與以前項(xiàng)目的異同，并及時(shí)做出調(diào)整。但是如果開(kāi)發(fā)者開(kāi)發(fā)過(guò)去沒(méi)有接觸過(guò)的項(xiàng)目，就很有必要研究該項(xiàng)目中要用到的典型方法，這有助于選擇最佳解決方案進(jìn)行軟件開(kāi)發(fā)實(shí)踐。下面是典型系統(tǒng)的解決方案：

·控制系統(tǒng)(ControlSystem)實(shí)時(shí)系統(tǒng)需要使用合適的方法學(xué)來(lái)實(shí)現(xiàn)，具有并發(fā)處理的實(shí)時(shí)系統(tǒng)可能要使用諸如Petri網(wǎng)的技術(shù)。

·信息系統(tǒng)(InformationSystem)類似地，信息系統(tǒng)需要諸如SSADM或信息工程這樣與環(huán)境類型相稱的方法學(xué)。SSADM特別適合于有大量的開(kāi)發(fā)人員需要協(xié)同工作的項(xiàng)目，該方法詳細(xì)規(guī)定了每步需要的活動(dòng)和產(chǎn)品。因此開(kāi)發(fā)組成員要確切地知道期望的是什么。

·通用工具(GeneralTool)如果軟件是針對(duì)通用市場(chǎng)的，而不是針對(duì)特定的應(yīng)用領(lǐng)域或用戶的，就需要考慮諸如SSADM這樣的方法學(xué)。該方法的制定者做出了有特定用戶存在的假設(shè)，該方法的有些部分還假設(shè)要分析已有的文檔來(lái)產(chǎn)生新的基于計(jì)算機(jī)系統(tǒng)的邏輯特征。

·專用技術(shù)(SpecializedTechnique)例如已經(jīng)發(fā)明了專家系統(tǒng)外殼和基于邏輯的程序設(shè)計(jì)語(yǔ)言來(lái)促進(jìn)基于知識(shí)系統(tǒng)的開(kāi)發(fā)。類似地，許多專用技術(shù)和工具可用于輔助基于圖形系統(tǒng)的開(kāi)發(fā)。

·硬件環(huán)境(HardwareEnvironment)系統(tǒng)要在硬件上運(yùn)行的環(huán)境會(huì)制約實(shí)現(xiàn)該系統(tǒng)的方法。例如快速響應(yīng)時(shí)間或計(jì)算機(jī)內(nèi)存受限的需求可能意味著只能使用低級(jí)編程語(yǔ)言。

·安全至上的系統(tǒng)(Safety-criticalSystem)在安全性和可靠性至關(guān)重要的情況下使用諸如Z或VDM之類表示法的形式化規(guī)格說(shuō)明的額外費(fèi)用被證明是適用的。實(shí)際上，關(guān)鍵的系統(tǒng)要考慮讓獨(dú)立的小組并行開(kāi)發(fā)具有相同功能系統(tǒng)的費(fèi)用。然后可運(yùn)行的系統(tǒng)要并行運(yùn)行并不斷進(jìn)行交叉檢測(cè)，這稱為n版本編程。

·不準(zhǔn)確的需求(ImpreciseRequirement)不確定性或新穎的硬件、軟件平臺(tái)意味著應(yīng)該考慮原型開(kāi)發(fā)方法。如果系統(tǒng)要在其上實(shí)現(xiàn)的環(huán)境是快速變化的，就特別需要考慮使用增量式交付。如果用戶有與項(xiàng)目有關(guān)的不確定的目的，也可以考慮使用軟系統(tǒng)方法。3.1.6技術(shù)計(jì)劃

通過(guò)項(xiàng)目分析提出要使用的實(shí)際技術(shù)需求，這些需求包括額外的活動(dòng)、軟件或硬件的獲取或特定人員的培訓(xùn)等。所有這些都隱含著一定的成本，應(yīng)該正式地記錄下來(lái)。

軟件公司可能會(huì)產(chǎn)生初步的技術(shù)計(jì)劃來(lái)幫助準(zhǔn)備合同的投標(biāo)。有時(shí)將計(jì)劃展示給客戶，以便解釋投標(biāo)價(jià)格的依據(jù)，并使客戶對(duì)要使用方法的合理性留下深刻的印象。技術(shù)計(jì)劃主要包含下面內(nèi)容，如圖3.1所示。圖3.1技術(shù)計(jì)劃內(nèi)容清單(將這些技術(shù)內(nèi)容展示給客戶，以便解釋投標(biāo)價(jià)格的依據(jù)，使客戶對(duì)要使用方法的合理性留下深刻的印象) 3.2選擇過(guò)程模型

軟件開(kāi)發(fā)過(guò)程模型(SoftwareDevelopmentProcessModel)是指軟件開(kāi)發(fā)全部過(guò)程、活動(dòng)和任務(wù)的框架。軟件開(kāi)發(fā)包括需求、分析、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試等階段，有時(shí)也包括維護(hù)階段。軟件開(kāi)發(fā)過(guò)程模型能清晰、直觀地表達(dá)軟件開(kāi)發(fā)全過(guò)程，明確定義要完成的主要活動(dòng)和任務(wù)，用來(lái)作為軟件項(xiàng)目工作的基礎(chǔ)。對(duì)于不同的軟件系統(tǒng)，可以采用不同的開(kāi)發(fā)方法，使用不同的程序設(shè)計(jì)語(yǔ)言以及各種不同技能的人員參與工作，運(yùn)用不同的管理方法和手段，并允許采用不同的軟件工具和不同的軟件工程環(huán)境。最早出現(xiàn)的軟件開(kāi)發(fā)模型是1970年WinstonRoyce提出的瀑布模型。該模型給出了固定的順序，將生存期活動(dòng)從上一個(gè)階段向下一個(gè)階段逐級(jí)過(guò)渡，如同流水下瀉，最終得到所開(kāi)發(fā)的軟件產(chǎn)品，從而投入使用。但是瀑布模型存在著缺乏靈活性、無(wú)法通過(guò)并發(fā)活動(dòng)澄清本來(lái)不夠確切的需求等缺點(diǎn)。典型的開(kāi)發(fā)模型有：瀑布模型(WaterfallModel)、漸增模型/演化/迭代(Incrementalmodel)、原型模型(PrototypeModel)、螺旋模型(SpiralModel)、噴泉模型(FountainModel)、智能模型(IntelligentModel)、混合模型(HybridModel)等，下面會(huì)介紹相關(guān)的模型。

計(jì)劃的主要任務(wù)是選擇開(kāi)發(fā)方法并把其嵌入到過(guò)程模型中。

3.3交付速度

在軟件開(kāi)發(fā)中客戶更關(guān)心以較低的成本快速交付業(yè)務(wù)應(yīng)用程序，應(yīng)對(duì)的方法是快速應(yīng)用開(kāi)發(fā)(RapidApplicationDevelopment,RAD)，RAD強(qiáng)調(diào)快速產(chǎn)生供用戶評(píng)價(jià)的軟件原型。

RAD方法不但使用一些傳統(tǒng)開(kāi)發(fā)的基本要素(如邏輯數(shù)據(jù)結(jié)構(gòu)圖)，而且采用聯(lián)合應(yīng)用開(kāi)發(fā)(JointApplicationDevelopment,JAD)研討會(huì)策略。在研討會(huì)中開(kāi)發(fā)人員和用戶一起工作，例如3～5天，標(biāo)識(shí)和認(rèn)可完全文檔化的業(yè)務(wù)需求，研討會(huì)通常在遠(yuǎn)離常規(guī)的業(yè)務(wù)和開(kāi)發(fā)環(huán)境的凈室(不受外部干擾的會(huì)議室，配備有合適的白板和其他輔助溝通的設(shè)備)中進(jìn)行，這些條件的好處是可加速溝通和磋商，不像傳統(tǒng)方法那樣要花幾周或幾個(gè)月的時(shí)間。在組織JAD會(huì)議之前，需要對(duì)項(xiàng)目范圍定義，以及對(duì)包含訪談關(guān)鍵人員、創(chuàng)建初始數(shù)據(jù)和過(guò)程模型在內(nèi)的初步工作進(jìn)行計(jì)劃和執(zhí)行，JAD會(huì)議的結(jié)果可以使用非常傳統(tǒng)的方法來(lái)實(shí)現(xiàn)。

另一種加速交付的方法是減少交付內(nèi)容，可以將大的項(xiàng)目分解成小的增量來(lái)實(shí)現(xiàn)，每個(gè)增量都快速交付一部分可用的功能。

在軟件項(xiàng)目中存在兩種競(jìng)爭(zhēng)壓力。一是盡可能快速并廉價(jià)地完成工作，二是確保最終產(chǎn)品的結(jié)構(gòu)是健壯的并能滿足變化的需要。具體如何開(kāi)發(fā)軟件項(xiàng)目，不同的過(guò)程模型在交付速度和軟件質(zhì)量方面的表現(xiàn)也各不相同。

3.4邊做邊改模型

邊做邊改模型(Build-and-FixModel)比較常見(jiàn)，曾被說(shuō)成是地獄式編程(Code-like-HellProgramming)，也稱為編碼修正(Code-and-Fix)模型。如果沒(méi)有項(xiàng)目計(jì)劃，也沒(méi)有選擇其他生命周期模型，配上一個(gè)簡(jiǎn)略的進(jìn)度表，也許就不自覺(jué)地進(jìn)行編碼，然后修改。當(dāng)使用邊做邊改模型的時(shí)候，一般從一個(gè)大致的想法開(kāi)始工作(可能有一個(gè)正式的規(guī)范，也可能沒(méi)有)隨著客戶的需要一次又一次地不斷修改軟件。在這個(gè)模型中開(kāi)發(fā)人員拿到項(xiàng)目立即根據(jù)需求編寫(xiě)程序，調(diào)試通過(guò)后生成軟件的第一個(gè)版本。在提供給用戶使用后如果程序出現(xiàn)錯(cuò)誤，或用戶提出新的要求，開(kāi)發(fā)人員重新修改代碼，直到用戶滿意為止。圖3.2說(shuō)明了這種過(guò)程。圖3.2邊做邊改模型(邊做邊改模型是一種不規(guī)范的模型，比較帶見(jiàn)的原因是因?yàn)樗?jiǎn)單，但是不能起到很好的作用)邊做邊改模型有兩個(gè)好處：第一，不需要什么成本。不需要在除了純粹編碼工作以外的項(xiàng)目計(jì)劃、文檔編制、質(zhì)量保證、標(biāo)準(zhǔn)實(shí)施或任何其他活動(dòng)中花費(fèi)時(shí)間，直接進(jìn)入編碼階段，能立即展示進(jìn)展情況；第二，只需要極少的專業(yè)知識(shí)。寫(xiě)過(guò)計(jì)算機(jī)程序的人都非常熟悉邊做邊改模型，任何人都能使用它。

對(duì)于一些非常小的、開(kāi)發(fā)完以后會(huì)很快丟棄的軟件，例如一些小的驗(yàn)證程序、壽命很短的示例或要丟棄的原型，邊做邊改模型有一定的優(yōu)勢(shì)。對(duì)于稍微大一點(diǎn)的項(xiàng)目，采用邊做邊改模型是很危險(xiǎn)的。雖然不需要什么成本，但是也不提供評(píng)估項(xiàng)目進(jìn)展情況的手段。如果干了3/4的工作才發(fā)現(xiàn)設(shè)計(jì)時(shí)就走錯(cuò)了路，那就別無(wú)選擇，只能全部重做。使用其他模型可以及早發(fā)現(xiàn)這種根本性的錯(cuò)誤，減少修改工作的成本。所以除非是無(wú)足輕重的小程序，這種生命周期模型在快速開(kāi)發(fā)項(xiàng)目中毫無(wú)用處。 3.5瀑布模型

瀑布生命周期模型是所有生命周期模型的原型，是其他生命周期模型的基礎(chǔ)。在瀑布模型中項(xiàng)目從始至終按照一定的步驟從初始的軟件概念進(jìn)展到系統(tǒng)測(cè)試。項(xiàng)目在每個(gè)階段結(jié)束時(shí)進(jìn)行檢查，以判斷是否可以開(kāi)始下一階段的工作。例如從需求分析到構(gòu)架設(shè)計(jì)。如果檢查的結(jié)果是項(xiàng)目還沒(méi)有準(zhǔn)備好進(jìn)入下一階段，那么就停留在當(dāng)前階段，直到當(dāng)前階段的工作完成為止。

瀑布模型是文檔驅(qū)動(dòng)的，主要工作成果是將一個(gè)階段的文檔傳遞到下一個(gè)階段。在純瀑布模型中，各階段不連續(xù)也不重疊。圖3.3說(shuō)明純瀑布模型是如何工作的。圖3.3純瀑布模型(瀑布模型是最著名的生命周期模型，在某些情況下提供了很快的開(kāi)發(fā)速度)純瀑布模型能夠降低計(jì)劃管理費(fèi)用，可以預(yù)先完成所有計(jì)劃。設(shè)計(jì)之前瀑布模型不提供有形的軟件成果，只有到軟件集成時(shí)，才得到可執(zhí)行的軟件。熟悉的人都明白：文檔提供了貫穿生命周期進(jìn)展過(guò)程的充分說(shuō)明。

當(dāng)有明確的產(chǎn)品定義和很容易理解的技術(shù)解決方案時(shí)，純瀑布模型特別合適。在這種情況下，瀑布模型可以及早發(fā)現(xiàn)問(wèn)題，降低項(xiàng)目的階段成本，提供開(kāi)發(fā)者渴望的穩(wěn)定需求。如果要對(duì)定義得很好的版本進(jìn)行維護(hù)或?qū)a(chǎn)品移植到一個(gè)新的平臺(tái)上，瀑布生命周期模型是快速開(kāi)發(fā)的恰當(dāng)選擇。對(duì)容易理解但很復(fù)雜的項(xiàng)目，采用純瀑布模型比較合適，這樣就可以用順序的方法處理復(fù)雜的問(wèn)題。在質(zhì)量需求高于成本需求和進(jìn)度需求的時(shí)候，其表現(xiàn)尤為出色。這樣的項(xiàng)目在進(jìn)展過(guò)程中基本不會(huì)產(chǎn)生需求變更，因此純瀑布模型就避免了一個(gè)常見(jiàn)的、巨大的潛在錯(cuò)誤源。

當(dāng)開(kāi)發(fā)隊(duì)伍的技術(shù)力量比較弱或缺乏經(jīng)驗(yàn)的時(shí)候，瀑布模型很合適，它為項(xiàng)目提供了一種節(jié)省開(kāi)支、減少浪費(fèi)的方法。

純瀑布模型的缺點(diǎn)是在項(xiàng)目開(kāi)始的時(shí)候、在設(shè)計(jì)工作完成前和在代碼寫(xiě)出來(lái)之前很難充分地描述需求。因此，瀑布模型最主要的問(wèn)題是缺乏靈活性。必須在項(xiàng)目開(kāi)始時(shí)定義全部需求，這恰恰是最難的，也許在開(kāi)始軟件開(kāi)發(fā)工作前就已經(jīng)花了幾個(gè)月甚至幾年。對(duì)于現(xiàn)代商業(yè)需求，獎(jiǎng)勵(lì)常常會(huì)頒發(fā)給在項(xiàng)目結(jié)束時(shí)實(shí)現(xiàn)最主要功能的開(kāi)發(fā)者。正如微軟的RogerSherman指出項(xiàng)目開(kāi)始時(shí)確定的最終目標(biāo)常常無(wú)法達(dá)到，只能在有限的時(shí)間和資源下盡可能地提高可能性。有人抱怨瀑布模型不允許返回去改正錯(cuò)誤，這不完全對(duì)。如圖3.3所示，允許回去，但是很困難。這就是瀑布模型的另一種表現(xiàn)形式—鮭魚(yú)生命周期模型，如圖3.4所示。

允許逆流而上，結(jié)果可能是死路一條！在構(gòu)架設(shè)計(jì)的最后階段，需要做幾件事，說(shuō)明正在完成的工作，如進(jìn)行設(shè)計(jì)檢查、在正式的構(gòu)架設(shè)計(jì)文檔上簽字等。如果在編碼和調(diào)試階段發(fā)現(xiàn)一個(gè)構(gòu)架設(shè)計(jì)的缺陷，很難逆流而上地進(jìn)行構(gòu)架改變。圖3.4瀑布模型的另外一種形式——鮭魚(yú)生命周期模型(返回不是不可能，只是很困難)瀑布生命周期模型有明顯的弱點(diǎn)。例如如果某些工具、方法和活動(dòng)跨越了瀑布模型的幾個(gè)階段，就很難適應(yīng)瀑布模型不連續(xù)階段的特性。對(duì)需要快速開(kāi)發(fā)的項(xiàng)目，瀑布模型會(huì)導(dǎo)致過(guò)多的文檔。如果保留靈活性，更新文檔會(huì)成為一項(xiàng)專門(mén)的工作。在開(kāi)發(fā)過(guò)程中使用瀑布模型能看到的東西很少，直到后期階段才能看到，這會(huì)給人一種開(kāi)發(fā)速度緩慢的印象，用戶喜歡看到實(shí)在的東西以保證項(xiàng)目能準(zhǔn)時(shí)完成。

因此純瀑布模型的缺點(diǎn)是其在面對(duì)要求快速開(kāi)發(fā)的項(xiàng)目時(shí)捉襟見(jiàn)肘，即便在項(xiàng)目中的優(yōu)勢(shì)大于弱點(diǎn)，而有時(shí)候經(jīng)過(guò)修改的瀑布模型則表現(xiàn)得更出色。 3.6瀑布模型的變種

3.6.1生魚(yú)片模型

PeterDeGrace把瀑布模型的一種改進(jìn)叫做“生魚(yú)片(Sashimi)模型”，是一種允許階段重疊的瀑布模型，名字來(lái)源于日本硬件開(kāi)發(fā)模型(富土通—施樂(lè))。圖3.5表示了生魚(yú)片模型的基本原理。

傳統(tǒng)的瀑布模型在階段結(jié)束時(shí)，通過(guò)檢查就進(jìn)入下個(gè)階段，否則繼續(xù)該階段，階段間存在最低限度的重疊，生魚(yú)片模型則建議大幅度的重疊。例如，在系統(tǒng)分析完成之前可以進(jìn)行構(gòu)架設(shè)計(jì)和部分詳細(xì)設(shè)計(jì)。對(duì)很多項(xiàng)目來(lái)說(shuō)，生魚(yú)片模型是一種合理的方法，將注意力集中在開(kāi)發(fā)過(guò)程中要干什么，但是，它不太適合嚴(yán)格的、連續(xù)的開(kāi)發(fā)計(jì)劃。圖3.5生魚(yú)片模型(將瀑布模型的各個(gè)階段重疊以克服其中的某些弱點(diǎn)，但產(chǎn)生了新問(wèn)題)純瀑布模型中，任意兩個(gè)階段交接時(shí)，完整的文檔從一個(gè)團(tuán)隊(duì)交給另一個(gè)完全隔離的團(tuán)隊(duì)。問(wèn)題是“為什么要這樣做？”，如果實(shí)施軟件需求、系統(tǒng)分析、構(gòu)架設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼和測(cè)試等階段的是同一組開(kāi)發(fā)人員，實(shí)際上就不需要那么多文檔，這樣，就可以采用修正后的瀑布模型，以充分減少文檔需求。

生魚(yú)片模型也有問(wèn)題，由于階段重疊，里程碑很不明確，難以進(jìn)行精確地過(guò)程跟蹤。并行執(zhí)行的活動(dòng)可能導(dǎo)致無(wú)效的溝通、錯(cuò)誤的想法以及低下的效率。如果做一個(gè)小的、定義的很好的項(xiàng)目，該模型是非常有效的模型。3.6.2包含子項(xiàng)目的瀑布模型

從快速開(kāi)發(fā)的觀點(diǎn)來(lái)看，純瀑布模型的另一個(gè)問(wèn)題是必須在全部完成構(gòu)架設(shè)計(jì)后才能開(kāi)始詳細(xì)設(shè)計(jì)，而在詳細(xì)設(shè)計(jì)全部完成后才能進(jìn)行編碼和測(cè)試。實(shí)際工作中系統(tǒng)的某些部分可能在設(shè)計(jì)上有獨(dú)特的地方，而且有些部分以前可能做過(guò)很多次，沒(méi)有什么特別的，為什么僅僅因?yàn)樵诘却粋€(gè)困難部分的設(shè)計(jì)而延遲容易執(zhí)行部分的設(shè)計(jì)呢？如果構(gòu)架把系統(tǒng)分成幾個(gè)邏輯上相對(duì)獨(dú)立的子系統(tǒng)，就允許拆分項(xiàng)目，每個(gè)子項(xiàng)目就可以按自己的步調(diào)走。圖3.6說(shuō)明了這種模型的基本結(jié)構(gòu)。圖3.6包含子項(xiàng)目的瀑布模型(仔細(xì)地計(jì)劃以允許并行地執(zhí)行瀑布模型的任務(wù))3.6.3可以降低風(fēng)險(xiǎn)的瀑布模型

瀑布模型的另一個(gè)弱點(diǎn)是要求在開(kāi)始構(gòu)架設(shè)計(jì)之前，完整地定義需求。雖然看起來(lái)很有道理，但在實(shí)際工作中是比較困難的。因此稍微改變一下瀑布模型，即在瀑布模型的頂端引入降低風(fēng)險(xiǎn)的螺旋(Spiral)以便處理需求風(fēng)險(xiǎn)。也可以先開(kāi)發(fā)一個(gè)用戶界面原型，或采用系統(tǒng)故事板(SystemStoryBoard)，引導(dǎo)用戶提出需求，記錄用戶與原系統(tǒng)的交互操作情況，或采用其他獲取用戶需求的方式。

圖3.7表明了能夠降低風(fēng)險(xiǎn)的瀑布模型。軟件需求、系統(tǒng)分析和構(gòu)架設(shè)計(jì)用陰影表示，以指出它們是在降低風(fēng)險(xiǎn)階段而不是在瀑布階段。圖3.7可以降低風(fēng)險(xiǎn)的瀑布模型(為了克服瀑布模型的風(fēng)險(xiǎn)問(wèn)題，可以在使用瀑布模型的時(shí)候，對(duì)需求、分析和構(gòu)架設(shè)計(jì)階段采用降低風(fēng)險(xiǎn)的螺旋模型)降低風(fēng)險(xiǎn)模型并不局限在需求和分析階段，也可以用它降低構(gòu)架風(fēng)險(xiǎn)或項(xiàng)目的其他任何風(fēng)險(xiǎn)。如果項(xiàng)目要開(kāi)發(fā)一個(gè)高風(fēng)險(xiǎn)的系統(tǒng)內(nèi)核，在交付項(xiàng)目前，就可以通過(guò)一個(gè)風(fēng)險(xiǎn)降低周期來(lái)進(jìn)行開(kāi)發(fā)。

3.7螺旋模型

螺旋模型是B.W.Boehm于1988年提出，是一種以風(fēng)險(xiǎn)為導(dǎo)向的生命周期模型，它把一個(gè)軟件項(xiàng)目分解成一個(gè)個(gè)小項(xiàng)目，標(biāo)識(shí)出每個(gè)小項(xiàng)目的一個(gè)或多個(gè)主要風(fēng)險(xiǎn)因素，直到確定所有的主要風(fēng)險(xiǎn)為止?！帮L(fēng)險(xiǎn)”可能是沒(méi)有理解清楚需求或構(gòu)架、潛在的性能問(wèn)題、根本性的技術(shù)問(wèn)題等。在確定所有的主要風(fēng)險(xiǎn)因素后，螺旋模型就像瀑布模型一樣終止。圖3.8說(shuō)明了螺旋模型，是個(gè)復(fù)雜的圖形，值得研究。螺旋模型的基本思路是從一個(gè)小范圍的關(guān)鍵中心地帶開(kāi)始尋找風(fēng)險(xiǎn)因素，制定風(fēng)險(xiǎn)控制計(jì)劃，并交付給下一步驟，如此迭代，每次選代都把項(xiàng)目擴(kuò)展到一個(gè)更大的規(guī)模。等到完成一個(gè)螺旋，檢查并確認(rèn)之后，再開(kāi)始進(jìn)入下一螺旋。圖3.8螺旋模型(在螺旋模型中，項(xiàng)目范圍逐漸遞增展開(kāi)。項(xiàng)目范圍展開(kāi)的前提是風(fēng)險(xiǎn)降低到下一步擴(kuò)展部分的可接受的水平)每次迭代都包括下面六個(gè)步驟：

(1)確定目標(biāo)、備選方案和約束條件；

(2)識(shí)別并解決風(fēng)險(xiǎn)；

(3)評(píng)估備選方案；

(4)開(kāi)發(fā)本次迭代要交付的內(nèi)容，并檢查其正確性；

(5)規(guī)劃下一次迭代過(guò)程；

(6)交付給下一步驟，開(kāi)始新的迭代過(guò)程(如果想繼續(xù)的話)。

在螺旋模型中越早期的迭代過(guò)程成本越低，這樣當(dāng)發(fā)現(xiàn)項(xiàng)目不可行時(shí)所消耗的成本最低。因此，計(jì)劃概念比需求分析的代價(jià)低，需求分析比開(kāi)發(fā)設(shè)計(jì)、集成和測(cè)試的代價(jià)低。螺旋有精確的四個(gè)環(huán)并不重要，同樣嚴(yán)格地執(zhí)行上述六個(gè)步驟也不重要，雖然那是很好的工作順序，也應(yīng)該根據(jù)項(xiàng)目的實(shí)際需求調(diào)整螺旋的每次迭代過(guò)程。

螺旋模型最重要的優(yōu)勢(shì)是隨著成本的增加，風(fēng)險(xiǎn)程度隨之降低。時(shí)間和資金花得越多，風(fēng)險(xiǎn)越小，這正是快速開(kāi)發(fā)項(xiàng)目所需要的。

螺旋模型提供至少和傳統(tǒng)的瀑布模型一樣多的管理控制。在每次迭代過(guò)程結(jié)束時(shí)都設(shè)置了檢查點(diǎn)，因?yàn)槟Ｐ褪秋L(fēng)險(xiǎn)導(dǎo)向的，可以預(yù)知任何無(wú)法逾越的風(fēng)險(xiǎn)。如果項(xiàng)目因?yàn)榧夹g(shù)和其他原因無(wú)法完成，就可以及早發(fā)現(xiàn)，而且不會(huì)增加太多的成本。螺旋模型有一定的限制條件，具體如下：

(1)螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)分析，但要求許多客戶接受和相信這種分析并做出相關(guān)反應(yīng)是不容易的，因此這種模型往往適應(yīng)于內(nèi)部的大規(guī)模軟件開(kāi)發(fā)；

(2)如果執(zhí)行風(fēng)險(xiǎn)分析將大大影響項(xiàng)目的利潤(rùn)，那么進(jìn)行風(fēng)險(xiǎn)分析毫無(wú)意義，因此螺旋模型只適合于大規(guī)模軟件項(xiàng)目；

(3)軟件開(kāi)發(fā)人員應(yīng)該擅長(zhǎng)尋找可能的風(fēng)險(xiǎn)，并準(zhǔn)確地分析風(fēng)險(xiǎn)，否則將會(huì)帶來(lái)更大的風(fēng)險(xiǎn)。因此螺旋模型的缺陷是比較復(fù)雜，需要有責(zé)任心、專注和管理方面的知識(shí)。通過(guò)確定目標(biāo)和可驗(yàn)證的里程碑來(lái)決定是否準(zhǔn)備在“螺旋”上再加一層是比較困難的。在有些項(xiàng)目中如果產(chǎn)品開(kāi)發(fā)的目標(biāo)明確、風(fēng)險(xiǎn)適中，就沒(méi)有必要采用螺旋模型來(lái)進(jìn)行風(fēng)險(xiǎn)管理。 3.8原型開(kāi)發(fā)

原型是已規(guī)劃系統(tǒng)的一個(gè)或多個(gè)方面的工作模型。建立原型的主要原因是為了解決在產(chǎn)品開(kāi)發(fā)的早期階段的不確定性，利用這些不確定性來(lái)判斷系統(tǒng)中哪一部分需要建立原型和希望從用戶對(duì)原型的評(píng)價(jià)中獲得什么。原型可以使他們的想象更具體化，有助于說(shuō)明和糾正這些不確定性，總的來(lái)說(shuō)通過(guò)原型法可以很好的減少項(xiàng)目風(fēng)險(xiǎn)。用快速而又經(jīng)濟(jì)的方法來(lái)構(gòu)建和測(cè)試原型，以檢驗(yàn)各種設(shè)想。圖3.9給出了軟件開(kāi)發(fā)中使用原型的一些方法。圖3.9軟件開(kāi)發(fā)中使用原型的可能方法(建立原型可以解決在產(chǎn)品開(kāi)發(fā)的早期階段不確定的問(wèn)題，原型有助于說(shuō)明和糾正這些不確定性，可以用快速而又經(jīng)濟(jì)的方法來(lái)構(gòu)建和測(cè)試原型，以檢驗(yàn)各種設(shè)想)原型可以分為水平和垂直的原型：

·水平原型。也叫做“行為原型”(BehavioralPrototype)。用來(lái)探索預(yù)期系統(tǒng)的一些特定行為，并達(dá)到細(xì)化需求的目的。當(dāng)用戶在考慮原型中所提出的功能能否使他們完成各自的業(yè)務(wù)時(shí)，原型使用戶所探討的問(wèn)題更加具體化。它更多從業(yè)務(wù)需求著手，應(yīng)用在需求階段。

·垂直原型(VerticalPrototype)。也叫做結(jié)構(gòu)化原型或概念的證明，實(shí)現(xiàn)了一部分應(yīng)用功能。當(dāng)預(yù)期實(shí)現(xiàn)階段可能存在技術(shù)風(fēng)險(xiǎn)時(shí)可以開(kāi)發(fā)一個(gè)垂直原型。垂直原型通常用在生產(chǎn)運(yùn)行環(huán)境中的生產(chǎn)工具構(gòu)造，使其結(jié)果一目了然(更有意義)。比起在軟件的需求開(kāi)發(fā)階段，垂直原型更常用于軟件的設(shè)計(jì)階段以減少風(fēng)險(xiǎn)。原型又可以分為拋棄型或進(jìn)化型：

·拋棄型原型。只用來(lái)檢驗(yàn)?zāi)承┫敕?，而后在真正開(kāi)始開(kāi)發(fā)可運(yùn)行的系統(tǒng)時(shí)將其拋棄。由于在開(kāi)發(fā)階段最終將拋棄這些原型，所以不需要花太大力氣去建立原型。原型可使用不同的軟件環(huán)境來(lái)開(kāi)發(fā)(如桌面應(yīng)用程序構(gòu)造工具，而不用像開(kāi)發(fā)最終系統(tǒng)那樣使用過(guò)程編程語(yǔ)言，機(jī)器效率對(duì)最終系統(tǒng)來(lái)說(shuō)是重要的)，甚至可以在不同的硬件平臺(tái)上開(kāi)發(fā)。

·進(jìn)化型原型。開(kāi)發(fā)并修改原型，直到它最終成為可運(yùn)行的系統(tǒng)。這種情況下必須仔細(xì)考慮用于開(kāi)發(fā)軟件的標(biāo)準(zhǔn)。進(jìn)化型原型是在已經(jīng)清楚地定義了需求的情況下，作為產(chǎn)品的部分實(shí)現(xiàn)，為開(kāi)發(fā)漸進(jìn)式產(chǎn)品提供了堅(jiān)實(shí)的開(kāi)發(fā)基礎(chǔ)。與拋棄型原型的快速、粗略的特點(diǎn)相比，進(jìn)化型原型一開(kāi)始就必須具有健壯性和產(chǎn)品質(zhì)量級(jí)的代碼。一個(gè)進(jìn)化型原型必須設(shè)計(jì)為易于升級(jí)和優(yōu)化的，要達(dá)到進(jìn)化型原型的質(zhì)量要求并沒(méi)有捷徑。進(jìn)化型原型一般在處理構(gòu)架時(shí)會(huì)采用。原型技術(shù)對(duì)軟件項(xiàng)目的促進(jìn)作用很明顯。使用原型可以帶來(lái)下面的好處：

·改進(jìn)溝通。盡管用戶確實(shí)閱讀了系統(tǒng)規(guī)格說(shuō)明，但他們可能并不知道系統(tǒng)實(shí)際上是如何工作的。

·改進(jìn)用戶參與。用戶可以更主動(dòng)地參與新系統(tǒng)的設(shè)計(jì)決策。

·澄清部分已知的需求。在沒(méi)有現(xiàn)成的系統(tǒng)可模仿的情況下用戶可以通過(guò)試驗(yàn)原型更好地理解什么對(duì)他們是有用的。

·驗(yàn)證規(guī)格說(shuō)明的一致性和完整性。試圖在計(jì)算機(jī)上實(shí)現(xiàn)規(guī)格說(shuō)明的任何辦法都可能發(fā)生歧義和遺漏。例如簡(jiǎn)易的電子表格可以檢查計(jì)算是否已得到了正確的結(jié)果，這是一種檢驗(yàn)規(guī)格說(shuō)明的方法。

·減少文檔的需要。由于可以檢查工作原型，因此減少了對(duì)詳細(xì)需求文檔的需要。

·降低維護(hù)成本。如果沒(méi)有原型階段，用戶不能有效地提出修改建議，那么就很可能在將來(lái)提出對(duì)可運(yùn)行系統(tǒng)的變更。

·特征約束。如果使用應(yīng)用程序構(gòu)造工具，原型就具有該工具很容易實(shí)現(xiàn)的特征，而基于書(shū)面的設(shè)計(jì)可能帶來(lái)實(shí)現(xiàn)費(fèi)用昂貴的特征。

·

產(chǎn)生期望的結(jié)果。與測(cè)試用例有關(guān)的問(wèn)題一般不是創(chuàng)建測(cè)試輸入，而是得到準(zhǔn)確的期望結(jié)果，原型有助于做到這一點(diǎn)。但是，軟件原型開(kāi)發(fā)并不是沒(méi)有缺點(diǎn)和危險(xiǎn)，主要體現(xiàn)在以下方面：

·用戶可能曲解原型的作用。例如他們可能期望原型與可運(yùn)行的系統(tǒng)一樣有嚴(yán)格的輸入確認(rèn)或很快的響應(yīng)速度，即使這不是預(yù)期的。

·可能缺乏項(xiàng)目標(biāo)準(zhǔn)。進(jìn)化型原型可能只是草率的“編寫(xiě)完并看看發(fā)生什么”的方法。

·可能缺乏控制。如果驅(qū)動(dòng)力是用戶愛(ài)好試驗(yàn)新事物，那么要控制原型開(kāi)發(fā)的周期是很困難的。

·額外的費(fèi)用。構(gòu)建和使用原型要花額外的費(fèi)用，但是不應(yīng)該過(guò)高估計(jì)，因?yàn)闊o(wú)論用什么方法都要承擔(dān)許多分析和設(shè)計(jì)任務(wù)。

·機(jī)器效率。盡管通過(guò)原型開(kāi)發(fā)構(gòu)建的系統(tǒng)易于滿足用戶的需要，但是從機(jī)器效率的角度來(lái)講它可能不如用常規(guī)的方法開(kāi)發(fā)的系統(tǒng)。

·與開(kāi)發(fā)人員密切接近。原型開(kāi)發(fā)意味著開(kāi)發(fā)人員在場(chǎng)地上要鄰近用戶。一種趨勢(shì)是發(fā)達(dá)國(guó)家的組織以較低的成本將軟件開(kāi)發(fā)轉(zhuǎn)移到發(fā)展中國(guó)家，如印度、中國(guó)等，原型開(kāi)發(fā)可能阻礙這種趨勢(shì)。 3.9分類原型的其它方面

3.9.1要從原型中學(xué)到什么

原型開(kāi)發(fā)最重要的目的是需要了解不確定的領(lǐng)域。因此重要的是要在開(kāi)始時(shí)確定要從原型中學(xué)到什么。

計(jì)算機(jī)領(lǐng)域的學(xué)生經(jīng)常認(rèn)為他們要編寫(xiě)的作為畢業(yè)設(shè)計(jì)項(xiàng)目的一部分軟件不可能被實(shí)際的用戶安全地使用，因而他們稱這樣的軟件為“原型”。但是如果是實(shí)際的原型，他們應(yīng)該：

·詳細(xì)說(shuō)明希望從原型中學(xué)到什么；

·計(jì)劃如何評(píng)價(jià)原型；

·報(bào)告實(shí)際從原型中學(xué)到了什么。在試驗(yàn)項(xiàng)目中使用原型，可以用于發(fā)現(xiàn)新的開(kāi)發(fā)技術(shù)。開(kāi)發(fā)方法可能是眾所周知的，但應(yīng)用程序的不確定性是本質(zhì)的。

不同的項(xiàng)目在不同的階段有不確定性。因此原型可在不同的階段使用。例如原型可以用在需求收集階段來(lái)弄清楚似是而非和變幻莫測(cè)的需求；另外，原型可能用在設(shè)計(jì)階段來(lái)檢驗(yàn)用戶瀏覽一系列輸入屏幕的能力。3.9.2原型要做到什么程度

對(duì)整個(gè)應(yīng)用程序進(jìn)行原型化是很少見(jiàn)的。原型開(kāi)發(fā)通常只是模仿目標(biāo)應(yīng)用程序的某些方面。例如：

·實(shí)驗(yàn)?zāi)Ｐ汀Ｒ苍S模仿的輸入屏幕要在工作站上顯示給用戶看，而且這樣的屏幕實(shí)際上是不能使用的，例如嵌入式開(kāi)發(fā)中的界面設(shè)計(jì)。

·模仿交互。例如用戶輸入請(qǐng)求來(lái)訪問(wèn)記錄，而系統(tǒng)顯示記錄的細(xì)節(jié)，但顯示的記錄總是一樣的，而且不是對(duì)數(shù)據(jù)庫(kù)進(jìn)行訪問(wèn)。

·部分工作模型：

◆縱向的。有一些但不是所有的特征徹底進(jìn)行原型化。

◆橫向的。所有的特征都要原型化，但不詳細(xì)進(jìn)行(也許輸入沒(méi)有完全驗(yàn)證)。3.9.3哪些要進(jìn)行原型化

·人機(jī)界面。對(duì)商業(yè)應(yīng)用程序來(lái)講，需求一般要在早期階段處理，因此原型往往局限于為操作員提供交互操作上。這時(shí)原型的表現(xiàn)方式應(yīng)該盡可能與可運(yùn)行的系統(tǒng)保持一致。

·系統(tǒng)的功能性。這里并不知道系統(tǒng)內(nèi)部運(yùn)行的準(zhǔn)確方式，例如正在開(kāi)發(fā)的某些現(xiàn)實(shí)世界的計(jì)算機(jī)模型。除非模仿現(xiàn)實(shí)世界的行為令人滿意，否則使用的算法可能需要反復(fù)調(diào)整，以達(dá)到預(yù)期的效果。3.9.4在原型開(kāi)發(fā)期間控制變更

原型開(kāi)發(fā)的主要問(wèn)題是遵循用戶提出的建議來(lái)控制對(duì)原型的變更。下面的方法把變更歸為三種類型之一：

·表面的(約占變更的35%)。主要是對(duì)屏幕布局的簡(jiǎn)單變更。它們是：

(1)已實(shí)現(xiàn)的；

(2)已記錄的。

·局部的(約占變更的60%)。主要包括屏幕處理方法的變更，但不影響系統(tǒng)的其他部分。它們是：

(1)已實(shí)現(xiàn)的；

(2)已記錄的；

(3)已備份的，必要時(shí)在后期階段可以刪除；

(4)已追溯審查的。

·全局的(約占變更的5%)。這些變更會(huì)影響多個(gè)部分的處理。毫無(wú)疑問(wèn)這里的變更在實(shí)現(xiàn)之前是設(shè)計(jì)評(píng)審的主題，是關(guān)注的焦點(diǎn)。

3.10漸進(jìn)原型

漸進(jìn)原型是從基本需求開(kāi)始項(xiàng)目開(kāi)發(fā)的一種生命周期模型，通常從最明顯的方面開(kāi)始向用戶展示完成的部分，然后根據(jù)用戶的反饋信息繼續(xù)開(kāi)發(fā)原型，并重復(fù)這一過(guò)程，直到用戶認(rèn)為原型已經(jīng)“足夠好”為止，然后結(jié)束開(kāi)發(fā)工作，并交付作為最終產(chǎn)品的原型。圖3.10描述了該過(guò)程。

在需求變化很快，用戶很難提出明確的需求，在開(kāi)發(fā)人員和用戶都不知道怎么才好的時(shí)候，當(dāng)開(kāi)發(fā)人員對(duì)最佳的構(gòu)架或算法沒(méi)有把握的時(shí)候，漸進(jìn)原型特別有用。漸進(jìn)原型主要的缺點(diǎn)是：開(kāi)發(fā)人員不可能在開(kāi)始的時(shí)候知道開(kāi)發(fā)一個(gè)令人滿意的產(chǎn)品要花多長(zhǎng)時(shí)間，甚至不知道究竟要反復(fù)多少次。不過(guò)由于用戶能看見(jiàn)項(xiàng)目進(jìn)展情況，對(duì)什么時(shí)候能最終得到產(chǎn)品不至于緊張，所以實(shí)際上缺點(diǎn)有所減輕。另外采用漸進(jìn)原型有可能陷入“保持原型，直到延時(shí)、超支，并聲稱會(huì)做完”的困境中。

漸進(jìn)原型的另一個(gè)缺點(diǎn)是該方法很容易成為采用邊做邊改模型的借口。真正的漸進(jìn)原型，包括真正的需求分析、設(shè)計(jì)和可維護(hù)的代碼，與采用傳統(tǒng)的方法相比，可能會(huì)覺(jué)得每次重復(fù)時(shí)實(shí)際的進(jìn)展較小。圖3.10漸進(jìn)原型模型(采用漸進(jìn)原型，應(yīng)從設(shè)計(jì)和實(shí)現(xiàn)原型程序中最明顯的部分開(kāi)始，然后增添、精煉原型，直到完成所有的工作，原型演化為最終可交付的軟件)

3.11增量交付

增量交付將應(yīng)用程序分解為小的構(gòu)件，然后按順序?qū)崿F(xiàn)和交付構(gòu)件。每個(gè)要交付的構(gòu)件應(yīng)該給用戶帶來(lái)一些效益。圖3.11描述了該方法的基本思想。

時(shí)間盒(TimeBoxing)通常用于增量式方法。增量交付隨著交付時(shí)間的限制不同，它的表現(xiàn)形式不同，例如階段交付、面向進(jìn)度的設(shè)計(jì)等。圖3.11有目的的增量交付(增量交付將應(yīng)用程序分解為小的構(gòu)件，然后按順序?qū)崿F(xiàn)和交付構(gòu)件)3.11.1優(yōu)點(diǎn)

下面是該方法的一些優(yōu)點(diǎn)：

·早期增量得到的反饋可用來(lái)改進(jìn)后面的階段。

·由于構(gòu)件設(shè)計(jì)與其實(shí)現(xiàn)之間的時(shí)間跨度較短，因此減少了需求變更的可能性。

·與常規(guī)的方法相比，用戶在早期就能得到效益。

·一些有用構(gòu)件的早期交付改進(jìn)了現(xiàn)金流，因?yàn)樵缙诰湍艿玫揭恍┩顿Y回報(bào)。

·劃分為較小型的子項(xiàng)目，更易于控制和管理。

·“鍍金”(即對(duì)不需要的和事實(shí)上不使用的特征的要求)是不太重要的，因?yàn)橛脩糁烙纱说玫降男б媸俏⒉蛔愕赖?。如果一個(gè)特征不在當(dāng)前增量中，那么可以包含在下一個(gè)增量中。

·如果突然出現(xiàn)更多緊急的工作，那么項(xiàng)目可以臨時(shí)放棄。

·增強(qiáng)了開(kāi)發(fā)人員的工作成就感，能短時(shí)間地、定期地看到自己的勞動(dòng)果實(shí)。3.11.2缺點(diǎn)

另一方面，該方法有以下缺點(diǎn)：

·軟件變更量，也就是說(shuō)后面的增量可能要求修改早期的增量。

·程序員在大型系統(tǒng)上工作，可能要比在一系列小型項(xiàng)目上工作有更高的效率。

·GradyBooch認(rèn)為：“對(duì)于“需求驅(qū)動(dòng)”的項(xiàng)目(等價(jià)于增量交付)來(lái)講，有時(shí)會(huì)破壞概念上的完整性，因?yàn)槌丝赡茈[含含糊的需求之外，幾乎沒(méi)有什么動(dòng)機(jī)來(lái)處理可伸縮性、可擴(kuò)充性、可移植性或可重用性?！盉ooch還認(rèn)為：“大量分散的功能可能會(huì)導(dǎo)致沒(méi)有公共的基礎(chǔ)設(shè)施。”3.11.3增量交付計(jì)劃

每個(gè)要交付給用戶的增量特征和順序必須在開(kāi)始時(shí)就策劃好。這個(gè)過(guò)程類似于戰(zhàn)略規(guī)劃，但要更詳細(xì)一些。要注意用戶應(yīng)用程序的增量，而不是整個(gè)應(yīng)用程序。增量計(jì)劃的基本組成是系統(tǒng)目的、開(kāi)放的技術(shù)計(jì)劃和增量。3.11.4系統(tǒng)目標(biāo)

項(xiàng)目計(jì)劃人員要有明確的目標(biāo)，但如何滿足這些目標(biāo)則應(yīng)該盡可能自由。然后將總體目標(biāo)擴(kuò)展為更明確的功能目標(biāo)和質(zhì)量目標(biāo)。目標(biāo)包括：

·想要實(shí)現(xiàn)的目標(biāo)；

·系統(tǒng)要做的工作；

·實(shí)現(xiàn)這些目標(biāo)的計(jì)算機(jī)和非計(jì)算機(jī)功能。另外可度量的質(zhì)量特性應(yīng)該定義成可靠性、響應(yīng)時(shí)間和安全性等。如果這樣定義了，那么這種以質(zhì)量需求為中心的做法，多少能滿足GradyBooch所關(guān)心的事項(xiàng)，即在增量中過(guò)于關(guān)注功能需求可能導(dǎo)致忽視質(zhì)量需求。它還反映了TomGilb所關(guān)心的事項(xiàng)，即系統(tǒng)開(kāi)發(fā)人員看到的總是以客戶代理的身份努力實(shí)現(xiàn)客戶的目標(biāo)。在應(yīng)用程序不斷變化的環(huán)境中某些需求會(huì)隨著項(xiàng)目的進(jìn)展而變化，但目標(biāo)不會(huì)變。3.11.5開(kāi)放的技術(shù)計(jì)劃

如果要使系統(tǒng)能夠應(yīng)付不斷增加的新構(gòu)件，則系統(tǒng)必須是可擴(kuò)充、可移植和可維護(hù)的。這至少要求使用：

·標(biāo)準(zhǔn)的高級(jí)語(yǔ)言；

·標(biāo)準(zhǔn)的操作系統(tǒng)；

·小模塊；

·可變的參數(shù)，例如組織及其部門(mén)的名稱、費(fèi)用比率等，應(yīng)該保存在不用程序員干預(yù)就能修改的參數(shù)文件中；

·標(biāo)準(zhǔn)的數(shù)據(jù)庫(kù)管理系統(tǒng)。

毫無(wú)疑問(wèn)：這些都是現(xiàn)代軟件開(kāi)發(fā)環(huán)境所期望的。3.11.6增量

定義了總體目標(biāo)和制定好開(kāi)放的技術(shù)計(jì)劃后，下一階段是使用下面的指南來(lái)計(jì)劃增量：

·這一步通常應(yīng)該占總項(xiàng)目的1%～5%；

·應(yīng)該包括非計(jì)算機(jī)步驟；

·理想情況下，每個(gè)增量不超過(guò)一個(gè)月，最壞情況下也不應(yīng)多于三個(gè)月；

·每個(gè)增量應(yīng)該給用戶帶來(lái)一些價(jià)值；

·每個(gè)增量在物理上依賴于其他增量。哪些步驟應(yīng)該優(yōu)先完成？有些步驟因物理依賴性而必須先做，而其他步驟可以是任何順序?？梢允褂脙r(jià)值-成本比(如表3-1所示)來(lái)確定增量開(kāi)發(fā)的順序。讓用戶用1～10個(gè)等級(jí)來(lái)評(píng)定每個(gè)增量的價(jià)值，開(kāi)發(fā)人員還可用0～10的得分來(lái)評(píng)定開(kāi)發(fā)每個(gè)增量的成本。這可能是很粗略的，但人們通常并不希望更準(zhǔn)確。然后將評(píng)定的價(jià)值除以評(píng)定的成本就可以得到對(duì)每個(gè)增量相對(duì)的“資金價(jià)值”的評(píng)定。表3-1價(jià)值-成本比的等級(jí)3.11.7增量示例

TomGilb描述了一個(gè)項(xiàng)目。在該項(xiàng)目中，一家軟件公司要與瑞典政府商談一兩個(gè)月交付時(shí)間的固定價(jià)格合同，以便提供一個(gè)系統(tǒng)來(lái)支持圖形制作。后來(lái)才發(fā)現(xiàn)，基于投標(biāo)的估計(jì)初始工作量大概是實(shí)際工作量的一半。

項(xiàng)目重新做了計(jì)劃，將它分成10個(gè)增量，每個(gè)增量提供一些客戶要使用的功能。最后一個(gè)增量在合同交付期之后的三個(gè)月才可用?？蛻魧?duì)此并沒(méi)有感到不高興，因?yàn)樵撓到y(tǒng)最重要的部分實(shí)際上早期就已經(jīng)交付了。

可參考下面的案例：考勤應(yīng)用系統(tǒng)—迭代增量式開(kāi)發(fā)。

3.12階段交付

階段交付模型可以持續(xù)地在確定的階段向用戶展示軟件。和漸進(jìn)原型不同的是在階段交付的時(shí)候，開(kāi)發(fā)人員明確地知道下一步要完成什么工作。階段交付的特點(diǎn)是不會(huì)在項(xiàng)目結(jié)束的時(shí)候一下交付全部軟件，而是在項(xiàng)目整個(gè)開(kāi)發(fā)過(guò)程中持續(xù)不斷地交付階段性成果(這種模型以“增量實(shí)現(xiàn)”而聞名)。圖3.12表明了階段交付模型的工作流程。圖3.12階段交付模型(階段交付避免了瀑布模型的問(wèn)題，即除非全部完成，系統(tǒng)沒(méi)有任何一部分是可用的。一旦設(shè)計(jì)完成，就可以分階段逐步實(shí)現(xiàn)和交付成果)如圖3.12所示，對(duì)于要構(gòu)建的軟件，如果采用階段交付模型，首先需要獲取軟件需求、系統(tǒng)分析、構(gòu)架設(shè)計(jì)等階段，然后分幾個(gè)階段進(jìn)行詳細(xì)設(shè)計(jì)、編碼和測(cè)試。

階段交付的主要優(yōu)點(diǎn)是在項(xiàng)目結(jié)束交付100%的產(chǎn)品前，分階段把有用的功能交到用戶手中。如果仔細(xì)地規(guī)劃了每個(gè)階段，就可以盡可能早地交付給用戶最重要的功能，使用戶盡早使用軟件。

階段交付在項(xiàng)目中提供明確的階段進(jìn)展標(biāo)志，其價(jià)值在于可以把進(jìn)度的壓力控制在一個(gè)可管理的水平上。階段交付的主要缺點(diǎn)是：如果管理層和技術(shù)層缺乏仔細(xì)的規(guī)劃，工作就無(wú)法進(jìn)行。使用階段交付模型需要注意的問(wèn)題是：在管理層，確保所規(guī)劃的階段對(duì)用戶非常有意義，而且在工作安排上要保證項(xiàng)目開(kāi)發(fā)人員能及時(shí)地在階段的最后期限完成工作；在技術(shù)層，確保考慮了不同產(chǎn)品組成部分的技術(shù)依賴，一個(gè)常犯的錯(cuò)誤是把一個(gè)組件的開(kāi)發(fā)推遲到第四階段，而沒(méi)想到的是在第二階段沒(méi)有該組件就不能繼續(xù)工作。

3.13面向進(jìn)度的設(shè)計(jì)

面向進(jìn)度的設(shè)計(jì)(DesigntoSchedule)生命周期模型類似于階段交付生命周期模型，二者的相同之處是都在連續(xù)的階段規(guī)劃開(kāi)發(fā)產(chǎn)品；不同之處是面向進(jìn)度的設(shè)計(jì)生命周期模型在開(kāi)始的時(shí)候不必知道究竟能達(dá)到什么樣的預(yù)定目標(biāo)。項(xiàng)目可能規(guī)劃了五個(gè)階段，但是因?yàn)闊o(wú)法改變的最后期限的限制，僅僅完成了三個(gè)階段，如圖3.13所示。圖3.13面向進(jìn)度的設(shè)計(jì)模型(和階段交付類似，當(dāng)系統(tǒng)有一個(gè)無(wú)法改變的交付期限或費(fèi)用的時(shí)候，面向進(jìn)度的設(shè)計(jì)是很有用的)該生命周期模型是確保能按照一個(gè)確定的日期發(fā)布產(chǎn)品的可行策略。如果為了內(nèi)部交付，年末或其他不可改變的日期必須及時(shí)地交付軟件，該策略可以保證到時(shí)能交付一些成果。例如MicrosoftWindows操作系統(tǒng)包括了一些“小應(yīng)用程序”：寫(xiě)字板、記事本、畫(huà)筆和紅心大戰(zhàn)等。Microsoft可以為小應(yīng)用程序采用面向進(jìn)度的設(shè)計(jì)來(lái)避免在總體上耽誤了Windows系統(tǒng)的開(kāi)發(fā)。

如圖3.13所示，該生命周期模型的一個(gè)關(guān)鍵是按優(yōu)先級(jí)劃分系統(tǒng)特性，規(guī)劃開(kāi)發(fā)階段，保證前面的階段包括高優(yōu)先級(jí)的特性，而將低優(yōu)先級(jí)的特性放在后面階段。該方法的最大缺點(diǎn)是如果開(kāi)發(fā)人員不明白所有的階段，就會(huì)浪費(fèi)時(shí)間去開(kāi)發(fā)構(gòu)架和設(shè)計(jì)不必要的特性。如果不把時(shí)間消耗在很多不必要的特性上，就能擠出時(shí)間去做一兩個(gè)需要的特性。

是否使用面向進(jìn)度的設(shè)計(jì)取決于開(kāi)發(fā)人員對(duì)自己安排工作的能力是否有足夠的信心。如果能確保達(dá)到進(jìn)度目標(biāo)，這就是一個(gè)低效率的方法；如果不那么自信，用面向進(jìn)度的設(shè)計(jì)模型就很有用。

3.14漸進(jìn)交付

漸進(jìn)交付是結(jié)合了漸進(jìn)原型和階段交付兩種模型的生命周期模型。開(kāi)發(fā)者將開(kāi)發(fā)產(chǎn)品的一個(gè)版本展示給用戶，然后根據(jù)用戶的反饋改進(jìn)產(chǎn)品。漸進(jìn)交付和漸進(jìn)原型有多少類似取決于要滿足用戶需求的程度。如果要滿足用戶的絕大部分需求，漸進(jìn)交付和漸進(jìn)原型差不多。如果要滿足少量的用戶需求，漸進(jìn)交付就和階段交付差不多。圖3.14表明了該方法的工作過(guò)程。圖3.14漸進(jìn)交付模型(該模型結(jié)合了階段交付便于控制和漸進(jìn)原型比較靈活的優(yōu)點(diǎn)，通過(guò)調(diào)整，可以滿足對(duì)控制和靈活性的需求)漸進(jìn)原型和漸進(jìn)交付的最大不同不在于基本方法，而在于著重點(diǎn)。在漸進(jìn)原型中，最初強(qiáng)調(diào)的是系統(tǒng)看見(jiàn)的樣子，然后回來(lái)堵住系統(tǒng)上的漏洞。在漸進(jìn)交付中，最初的重點(diǎn)是系統(tǒng)核心，包括了不太可能因?yàn)橛脩舴答佉庖?jiàn)而改變的底層系統(tǒng)的功能。 3.15快速應(yīng)用開(kāi)發(fā)模型

快速應(yīng)用開(kāi)發(fā)(RapidApplicationDevelop，RAD)模型也是一個(gè)增量型的軟件開(kāi)發(fā)過(guò)程模型，它強(qiáng)調(diào)極短的開(kāi)發(fā)周期。該模型是瀑布模型的一個(gè)“高速”變種，通過(guò)大量使用可復(fù)用構(gòu)件，采用基于構(gòu)件的建造方法來(lái)贏得快速開(kāi)發(fā)。如果正確地理解了需求，而且約束了項(xiàng)目的范圍，利用這種模型可以很快創(chuàng)建出功能完善的信息系統(tǒng)。其流程從業(yè)務(wù)建模開(kāi)始，隨后是數(shù)據(jù)建模、過(guò)程建模、應(yīng)用生成、測(cè)試及反復(fù)。圖3.15表明了快速應(yīng)用開(kāi)發(fā)模型的工作過(guò)程。圖3.15快速應(yīng)用開(kāi)發(fā)模型(該模型是瀑布模型的一個(gè)“高速”變種，通過(guò)大量使用可復(fù)用構(gòu)件贏得快速開(kāi)發(fā))與瀑布模型相比，快速應(yīng)用開(kāi)發(fā)模型不是采用傳統(tǒng)的第3代程序設(shè)計(jì)語(yǔ)言來(lái)構(gòu)造軟件，而是采用基于構(gòu)件的開(kāi)發(fā)方法，復(fù)用已有的程序結(jié)構(gòu)(如果可能)或使用可復(fù)用構(gòu)件和/或創(chuàng)建可復(fù)用的構(gòu)件(如果需要)。在所有情況下均使用自動(dòng)化工具輔助軟件創(chuàng)建。很顯然，加在一個(gè)RAD模型項(xiàng)目上的時(shí)間約束需要“一個(gè)可伸縮的范圍”，如果一個(gè)業(yè)務(wù)能夠模塊化，而且其中每個(gè)主要功能均可以在不到3個(gè)月的時(shí)間內(nèi)完成，那么就可以使用RAD方法。每個(gè)主要功能可由一個(gè)單獨(dú)的RAD組來(lái)實(shí)現(xiàn)，最后集成起來(lái)構(gòu)成一個(gè)整體。

RAD模型大量使用可復(fù)用構(gòu)件以加快開(kāi)發(fā)速度，對(duì)信息系統(tǒng)的開(kāi)發(fā)特別有效。但是與其他軟件過(guò)程模型一樣，RAD方法有下面的缺陷：

(1)并非所有應(yīng)用都適合RAD。RAD模型對(duì)模塊化要求比較高，如果有哪個(gè)功能不能模塊化，那么構(gòu)造RAD所需要的構(gòu)件就會(huì)有問(wèn)題。如果高性能是一個(gè)指標(biāo)且該指標(biāo)必須通過(guò)調(diào)整接口使其適應(yīng)系統(tǒng)構(gòu)件才能獲得，那么RAD方法也可能并不奏效。

(2)開(kāi)發(fā)人員和客戶必須在很短的時(shí)間內(nèi)完成一系列的需求分析，任何一方配合不當(dāng)都會(huì)導(dǎo)致RAD項(xiàng)目失敗。

(3)?RAD只能用于信息系統(tǒng)開(kāi)發(fā)，不適合技術(shù)風(fēng)險(xiǎn)很高的情況。當(dāng)一個(gè)新應(yīng)用要采用很多新技術(shù)或當(dāng)新軟件要求與已有的計(jì)算機(jī)程序的高互操作性時(shí)，這種情況就會(huì)發(fā)生。

3.16并發(fā)開(kāi)發(fā)模型

并發(fā)開(kāi)發(fā)模型也稱為“并發(fā)工程”，關(guān)注多個(gè)任務(wù)的并發(fā)執(zhí)行，表示為一系列的主要技術(shù)活動(dòng)、任務(wù)及其相關(guān)狀態(tài)。并發(fā)開(kāi)發(fā)模型由客戶要求、管理決策、結(jié)果評(píng)審驅(qū)動(dòng)，不是將軟件工程活動(dòng)限定為一個(gè)順序的事件序列，而是定義一個(gè)活動(dòng)網(wǎng)絡(luò)，網(wǎng)絡(luò)上的每個(gè)活動(dòng)均可與其他活動(dòng)同時(shí)發(fā)生。這種模型可以提供項(xiàng)目當(dāng)前狀態(tài)的準(zhǔn)確視圖。并發(fā)開(kāi)發(fā)模型的每個(gè)活動(dòng)在不同的狀態(tài)之間的轉(zhuǎn)換，如圖3.16所示。圖3.16并發(fā)開(kāi)發(fā)模型活動(dòng)的狀態(tài)圖(并發(fā)開(kāi)發(fā)模型由客戶要求、管理決策、結(jié)果評(píng)審驅(qū)動(dòng)，定義一個(gè)活動(dòng)網(wǎng)絡(luò)，每個(gè)活動(dòng)均可與其他活動(dòng)同時(shí)發(fā)生，每個(gè)活動(dòng)在不同的狀態(tài)之間轉(zhuǎn)換)并發(fā)開(kāi)發(fā)模型定義了一系列事件，對(duì)于每個(gè)軟件開(kāi)發(fā)活動(dòng)，它們觸發(fā)一個(gè)狀態(tài)到另一個(gè)狀態(tài)的變遷。當(dāng)它應(yīng)用于客戶機(jī)／服務(wù)器系統(tǒng)時(shí)，并發(fā)開(kāi)發(fā)模型在兩維上定義活動(dòng)，即一個(gè)系統(tǒng)維和一個(gè)構(gòu)件維，其并發(fā)性通過(guò)下面兩種方式得到：

(1)系統(tǒng)維和構(gòu)件維活動(dòng)同時(shí)發(fā)生，可以使用面向狀態(tài)的方法進(jìn)行建模。

(2)典型的客戶/服務(wù)器應(yīng)用通過(guò)多個(gè)構(gòu)件來(lái)實(shí)現(xiàn)，其中的每個(gè)構(gòu)件都可以并發(fā)設(shè)計(jì)并實(shí)現(xiàn)。項(xiàng)目管理者根本不可能了解項(xiàng)目的狀態(tài)，因而需要使用比較簡(jiǎn)單的模型來(lái)追蹤非常復(fù)雜的項(xiàng)目活動(dòng)，并發(fā)開(kāi)發(fā)模型就試圖根據(jù)傳統(tǒng)生命周期的主要階段來(lái)追蹤項(xiàng)目的狀態(tài)。并發(fā)開(kāi)發(fā)模型使用狀態(tài)圖(表示一個(gè)加工狀態(tài))來(lái)表示與一個(gè)特定事件(如在開(kāi)發(fā)后期需求的一個(gè)修改)相關(guān)的活動(dòng)之間存在的并發(fā)關(guān)系，但它不能捕獲到一個(gè)項(xiàng)目中所有軟件開(kāi)發(fā)和管理活動(dòng)的大量并發(fā)。大多數(shù)軟件并發(fā)開(kāi)發(fā)模型均為時(shí)間驅(qū)動(dòng)，越到模型的后端，就越到開(kāi)發(fā)過(guò)程的后一階段，而一個(gè)并發(fā)開(kāi)發(fā)模型是由用戶要求、管理決策和結(jié)果復(fù)審驅(qū)動(dòng)的。并發(fā)開(kāi)發(fā)模型在軟件開(kāi)發(fā)全過(guò)程活動(dòng)的并行化打破了傳統(tǒng)軟件開(kāi)發(fā)的各階段分割封閉的觀念，強(qiáng)調(diào)開(kāi)發(fā)團(tuán)隊(duì)人員之間的協(xié)作，注重分析和設(shè)計(jì)等前期開(kāi)發(fā)工作，從而避免不必要的返工。并發(fā)開(kāi)發(fā)模型的優(yōu)點(diǎn)是可用于所有類型的軟件開(kāi)發(fā)，對(duì)客戶／服務(wù)器結(jié)構(gòu)更加有效，可以隨時(shí)查閱到開(kāi)發(fā)的狀態(tài)。 3.17面向開(kāi)發(fā)工具的設(shè)計(jì)

隨著完整的應(yīng)用系統(tǒng)框架、可視化編程環(huán)境、豐富的數(shù)據(jù)庫(kù)編程環(huán)境等開(kāi)發(fā)工具的發(fā)展完善，開(kāi)發(fā)工具更靈活、更強(qiáng)大，可以采用面向開(kāi)發(fā)工具的設(shè)計(jì)模型的項(xiàng)目越來(lái)越多。

面向開(kāi)發(fā)工具的設(shè)計(jì)模型隱含的意思是在現(xiàn)有軟件工具直接支持的情況下增強(qiáng)產(chǎn)品的功能，如果工具不支持，就放棄該功能。

如圖3.17所示，采用該模型的結(jié)果是無(wú)法實(shí)現(xiàn)理想中要包括的全部功能。不過(guò)如果認(rèn)真地選擇工具，就可以實(shí)現(xiàn)想要的絕大部分功能。當(dāng)時(shí)間成為約束條件時(shí)，采用本模型實(shí)際上可以比采用其他模型能實(shí)現(xiàn)更完整的功能，但是這些功能是工具最容易實(shí)現(xiàn)的，而不一定是最想要的。圖3.17面向開(kāi)發(fā)工具設(shè)計(jì)模型的產(chǎn)品概念(面向開(kāi)發(fā)工具的設(shè)計(jì)可以提供快速的開(kāi)發(fā)速度，但是與其他生命周期模型相比，受工具的限制，只提供了較少的對(duì)產(chǎn)品功能的控制)該模型可以和其他靈活的生命周期模型結(jié)合在一起使用。例如可以采用初始階段的螺旋來(lái)判斷現(xiàn)有軟件工具的能力，確定核心需求和面向開(kāi)發(fā)工具的設(shè)計(jì)是否有用；可以采用面向開(kāi)發(fā)工具的設(shè)計(jì)方法去實(shí)現(xiàn)一個(gè)臨時(shí)的原型，試驗(yàn)是否可以通過(guò)工具很容易地實(shí)現(xiàn)系統(tǒng)，然后采用其他生命周期模型實(shí)現(xiàn)真正的軟件；也可以將面向開(kāi)發(fā)工具的設(shè)計(jì)和階段交付、漸進(jìn)交付、面向進(jìn)度的設(shè)計(jì)合起來(lái)使用。面向開(kāi)發(fā)工具設(shè)計(jì)的主要缺點(diǎn)：會(huì)失去對(duì)產(chǎn)品的控制，不能實(shí)現(xiàn)想要的所有特性，而且也不能準(zhǔn)確地實(shí)現(xiàn)其他想要的特性，更加依賴商用軟件廠商的產(chǎn)品策略和運(yùn)行的穩(wěn)定情況。如果只是實(shí)現(xiàn)一個(gè)隨便用用的小程序，倒不成問(wèn)題，但是如果完成的程序是打算要用上幾年的，那么提供工具的廠商會(huì)潛在地成為產(chǎn)品鏈上的薄弱環(huán)節(jié)。 3.18動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)方法

近來(lái)人們已經(jīng)對(duì)結(jié)構(gòu)化系統(tǒng)分析與設(shè)計(jì)方法(SSADM)失去了興趣，部分原因是認(rèn)為它過(guò)于呆板和墨守成規(guī)。相反地，迭代和增量式方法引起了人們更大的興趣。結(jié)果出現(xiàn)了動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)方法(DynamicSystemsDevelopmentMethod,DSDM)。

該方法有下面9個(gè)核心的實(shí)踐。

(1)用戶主動(dòng)參與是勢(shì)在必行的；

(2)?DSDM組應(yīng)該得到授權(quán)以便做出決策；

(3)重點(diǎn)是經(jīng)常交付產(chǎn)品；

(4)滿足業(yè)務(wù)目標(biāo)是可交付產(chǎn)品驗(yàn)收的基本準(zhǔn)則；

(5)迭代式和增量式交付是達(dá)成準(zhǔn)確的業(yè)務(wù)解決方案所必需的；

(6)開(kāi)發(fā)期間的所有變更都是可逆的；

(7)需求要在較高層次上基線化；

(8)測(cè)試要集成到整個(gè)生命周期中；

(9)所有項(xiàng)目相關(guān)人員之間的合作和協(xié)作方法是基本的。

圖3.18概括了這些做法。各種功能之間的箭頭說(shuō)明這些活動(dòng)的順序是非常靈活和可重復(fù)的。圖3.18DSDM過(guò)程模型(以9個(gè)核心的實(shí)踐為基礎(chǔ)，采用迭代和增量交付的方式，實(shí)現(xiàn)需要的功能)

DSDM鼓勵(lì)使用時(shí)間盒，典型的時(shí)間盒是2～6周，在時(shí)間間隔內(nèi)使參與者重點(diǎn)關(guān)注實(shí)際需要的功能。要想滿足時(shí)間盒規(guī)定的最終期限，可能將不重要的特征推遲到后面的增量去實(shí)現(xiàn)(甚至完全刪掉)。

可以將需求分配到不同增量來(lái)實(shí)現(xiàn)，這意味著如果要成功地控制項(xiàng)目，那么項(xiàng)目計(jì)劃就需要經(jīng)常更新。

3.19極限編程

談到極限編程(ExtremeProgramming,XP)，必然會(huì)聯(lián)想到KentBeck。極限編程起源于與Beck相關(guān)聯(lián)的ChryslerC3工資單項(xiàng)目。極限編程是上面已經(jīng)探討的許多RAD和DSDM原理的進(jìn)一步發(fā)展。在某些方面，極限編程可以看成是“超級(jí)程序員”描述他們對(duì)編碼世界的想法。它屬于一組類似的方法學(xué)，包括JimHighsmith的適應(yīng)性軟件開(kāi)發(fā)(AdaptiveSoftwareDevelopment,ASD)和AlistairCockburn的水晶燈(CrystalLight,CL)方法，這些方法統(tǒng)稱為敏捷方法(AgileMethod,AM)。

基于敏捷的核心思想和價(jià)值目標(biāo)，極限編程要求項(xiàng)目團(tuán)隊(duì)遵循13個(gè)核心實(shí)踐，如圖3.19所示。圖3.19極限編程(由13個(gè)核心的實(shí)踐組成，XP方法擁抱變化，強(qiáng)調(diào)團(tuán)隊(duì)合作，通過(guò)測(cè)試獲得客戶反饋，總是爭(zhēng)取盡可能早地將軟件交付給客戶)在軟件項(xiàng)目中存在的一個(gè)普遍問(wèn)題是交流。項(xiàng)目規(guī)模越大，問(wèn)題就越嚴(yán)重。當(dāng)然大項(xiàng)目意味著更多的人一起交流。由于項(xiàng)目的完成時(shí)間長(zhǎng)，必須對(duì)項(xiàng)目最初階段產(chǎn)生的信息進(jìn)行記錄，以便可以在項(xiàng)目后面的階段獲得，這很容易導(dǎo)致信息的不完整或過(guò)期。解決該問(wèn)題的一種方案是將交流正式化、結(jié)構(gòu)化，另外一種替代方法是減少交流的信息和信息保留的時(shí)間。可能的情況下交流直接在兩個(gè)感興趣的部分之間進(jìn)行，輸出結(jié)果立即合并到軟件和測(cè)試中，從而使按照需求進(jìn)行的開(kāi)發(fā)能夠快速地得到反饋結(jié)果。所以客戶代表實(shí)際上是團(tuán)隊(duì)的一部分，在適當(dāng)?shù)臅r(shí)候解釋需求。用戶的需求寫(xiě)在卡片上，包括各種描述軟件需求特征的“故事板”，然后開(kāi)發(fā)人員和客戶代表協(xié)商這些需求的開(kāi)發(fā)順序。類似于DSDM，極限編程倡導(dǎo)者主張應(yīng)用程序應(yīng)該在花幾周時(shí)間就能完成的工作軟件的增量中編寫(xiě)。如果有什么區(qū)別的話，它比DSDM更進(jìn)一步，在理想情況下每個(gè)增量只花1～3周時(shí)間，那么客戶在任何階段都可以提出對(duì)軟件功能的改進(jìn)。

在這些增量中，新的需求以很快的頻率增加到整個(gè)產(chǎn)品中，并且立即進(jìn)行集成測(cè)試。如果在新的軟件構(gòu)件版本中發(fā)現(xiàn)了一個(gè)錯(cuò)誤，那么錯(cuò)誤修復(fù)以后，將立刻反饋給上一個(gè)版本。

XP方法的產(chǎn)生是因?yàn)殡y以管理的需求變化，XP方法的建立同時(shí)也是為了解決軟件開(kāi)發(fā)項(xiàng)目中的風(fēng)險(xiǎn)問(wèn)題。XP方法是為小團(tuán)體開(kāi)發(fā)建立的，在2～10個(gè)人之間，因此XP方法不適用大團(tuán)體的開(kāi)發(fā)項(xiàng)目。而且在需求經(jīng)常動(dòng)態(tài)變化或具有高風(fēng)險(xiǎn)的項(xiàng)目中，XP方法在小團(tuán)體開(kāi)發(fā)中的作用要遠(yuǎn)遠(yuǎn)高于在大團(tuán)體開(kāi)發(fā)中的作用。

3.20領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)是由EricEvans在《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》一書(shū)中提出，實(shí)質(zhì)上是一種由內(nèi)而外的設(shè)計(jì)方法，俗話說(shuō)的先中間(模型和服務(wù))后兩邊(界面、數(shù)據(jù)庫(kù)以及集成)。

一個(gè)看上去正確的模型不代表該模型能夠直接轉(zhuǎn)換成代碼，而且模型的實(shí)現(xiàn)有可能會(huì)違背某些軟件設(shè)計(jì)原則。那么應(yīng)該如何實(shí)現(xiàn)從模型到代碼的轉(zhuǎn)換，讓代碼具有可擴(kuò)展性、可維護(hù)性、高性能等指標(biāo)呢？另外如實(shí)反映領(lǐng)域的模型可能會(huì)導(dǎo)致對(duì)象持久化的一系列問(wèn)題，或?qū)е虏豢山邮艿男阅軉?wèn)題，對(duì)此又該怎么做呢？解決的方法是緊密關(guān)聯(lián)領(lǐng)域建模和設(shè)計(jì)，將領(lǐng)域模型和軟件編碼的實(shí)現(xiàn)捆綁在一起，模型在構(gòu)建時(shí)就考慮到軟件設(shè)計(jì)和實(shí)現(xiàn)。開(kāi)發(fā)人員要參與到建模的過(guò)程中來(lái)。主要的想法是選擇一個(gè)恰當(dāng)?shù)哪Ｐ?，這樣設(shè)計(jì)過(guò)程會(huì)很順暢，而且代碼和模型緊密關(guān)聯(lián)會(huì)讓代碼更有意義。有了開(kāi)發(fā)人員的參與就會(huì)有反饋，能保證模型的實(shí)現(xiàn)。如果其中某處有錯(cuò)誤，在早期就會(huì)標(biāo)識(shí)出來(lái)，問(wèn)題也會(huì)容易修正。編碼的人會(huì)很好地了解模型，會(huì)感覺(jué)自己有責(zé)任保持模型的完整性，會(huì)意識(shí)到對(duì)代碼的一個(gè)變更其實(shí)就隱含著對(duì)模型的變更，另外如果哪里的代碼不能表現(xiàn)原始模型的話，他們會(huì)重構(gòu)代碼。如果分析人員從實(shí)現(xiàn)過(guò)程中分離出去，他會(huì)不再關(guān)心開(kāi)發(fā)過(guò)程中引入的局限性，最終結(jié)果是模型不再實(shí)用。任何技術(shù)人員想對(duì)模型做出貢獻(xiàn)必須花費(fèi)一些時(shí)間來(lái)接觸代碼，無(wú)論他在項(xiàng)目中擔(dān)負(fù)的是什么角色，任何一個(gè)負(fù)責(zé)修改代碼的人都必須學(xué)會(huì)用代碼表現(xiàn)模型，每位開(kāi)發(fā)人員都必須參與到一定級(jí)別的領(lǐng)域討論中并和領(lǐng)域?qū)＜衣?lián)絡(luò)。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)分為以下兩個(gè)階段：

·以一種領(lǐng)域?qū)＜摇⒃O(shè)計(jì)人員、開(kāi)發(fā)人員都能理解的“通用語(yǔ)言”作為相互交流的工具，在交流的過(guò)程中不斷發(fā)現(xiàn)一些主要的領(lǐng)域概念，然后將這些概念設(shè)計(jì)成一個(gè)領(lǐng)域模型；

·由領(lǐng)域模型驅(qū)動(dòng)軟件設(shè)計(jì)，用代碼來(lái)實(shí)現(xiàn)該領(lǐng)域模型。

由此可見(jiàn)：領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心是建立領(lǐng)域模型，領(lǐng)域模型在軟件構(gòu)架中處于核心地位，是軟件中最有價(jià)值和最具競(jìng)爭(zhēng)力的部分。軟件開(kāi)發(fā)過(guò)程中必須以建立領(lǐng)域模型為中心。

3.21成品軟件

在開(kāi)始開(kāi)發(fā)一個(gè)新系統(tǒng)的時(shí)候常常被忽略的選擇就是可以直接購(gòu)買(mǎi)軟件。盡管成品軟件不能夠滿足所有的需求，但是還是有下面幾個(gè)明顯的優(yōu)點(diǎn)。

首先成品軟件可以立即使用。從購(gòu)買(mǎi)軟件到交付自己開(kāi)發(fā)軟件之間的這段時(shí)間，用戶至少能增長(zhǎng)一些有價(jià)值的能力。隨著時(shí)間推移，成品軟件也可能會(huì)進(jìn)一步修改以便更加適應(yīng)用戶需要。而且定制的軟件和理想的軟件不會(huì)完全符合。將定制的軟件和成品軟件進(jìn)行比較類似于將實(shí)際放在貨架上的軟件和理想中的定制軟件相比較。當(dāng)自己開(kāi)發(fā)軟件的時(shí)候，得去設(shè)計(jì)、考慮成本和進(jìn)度，而且實(shí)際上為用戶定制的軟件可能不會(huì)如預(yù)想中的那么完美。如果僅僅交付了理想產(chǎn)品的75%，那么和成品軟件相比又能好到哪里去呢？(這種觀點(diǎn)同樣適用于面向開(kāi)發(fā)工具的設(shè)計(jì)模型。)

3.22管理迭代過(guò)程

Booch認(rèn)為開(kāi)發(fā)有兩個(gè)層次：宏過(guò)程(MacroProcess)和微過(guò)程(MicroProccss)。宏過(guò)程與瀑布過(guò)程模型密切相關(guān)，在這個(gè)層次必須協(xié)調(diào)各種專家組執(zhí)行的一系列活動(dòng)。需要確定未來(lái)的某些日期，即主要活動(dòng)何時(shí)將完成，以便知道何時(shí)讓員工做后續(xù)的活動(dòng)。在宏過(guò)程內(nèi)包含微過(guò)程活動(dòng)，這些活動(dòng)可能涉及迭代的工作，系統(tǒng)測(cè)試總是一次。圖3.20描繪了連續(xù)的宏過(guò)程如何受到迭代微過(guò)程的影響。對(duì)于迭代的微過(guò)程，需要在宏過(guò)程層次中用時(shí)間盒進(jìn)行控制。圖3.20包括三個(gè)迭代微過(guò)程的宏過(guò)程(宏過(guò)程受迭代微過(guò)程影響，迭代微過(guò)程需要在宏過(guò)程層次用時(shí)間盒進(jìn)行控制)可能出現(xiàn)宏過(guò)程本身需要迭代的情況。一個(gè)復(fù)雜系統(tǒng)的原型可能要用兩三個(gè)連續(xù)的版本來(lái)產(chǎn)生，每個(gè)版本要花幾個(gè)月時(shí)間來(lái)創(chuàng)建和評(píng)價(jià)。在這些情況下每個(gè)迭代本身可以當(dāng)成一個(gè)項(xiàng)目來(lái)處理。

3.23選擇最合適的生命周期

盡管項(xiàng)目都需要盡快地開(kāi)發(fā)出來(lái)，但是不同的項(xiàng)目有不同的需求。這里討論了10余種軟件生命周期模型以及它們的變種和組合，以便提供一個(gè)較為全面的選擇。那么哪個(gè)最合適呢？

沒(méi)有任何事情像“快速