軟件開發(fā)模式.ppt

1、,軟件開發(fā)模式,內(nèi)容大綱,導(dǎo)論 編碼與修正模式 階段模式 瀑布模式 漸增模式 原型模式 螺旋模式 同步模式 RUP模式 第四代技術(shù) 快速應(yīng)用軟體開發(fā) 結(jié)論,導(dǎo)論,軟件開發(fā)模式是描述軟件開發(fā)過程的一系列步驟及其執(zhí)行程序。 開發(fā)的過程依循系統(tǒng)化、邏輯化的步驟進(jìn)行時(shí)，將有利于標(biāo)準(zhǔn)、規(guī)范與政策之推行和建立，而且開發(fā)過程將更有效率，更能確保品質(zhì)量，也更容易管理。 不同的開發(fā)模式，選用于不同情況的系統(tǒng)開發(fā)。,軟件開發(fā)模式,編碼與修正模式 階段模式 瀑布模式 漸增模式 雛型模式 螺旋模式 同步模式 RUP模式,各種開發(fā)模式之演進(jìn),編碼與修正模式,無方法論可言，主要包含兩個(gè)步驟： 先寫部分程序， 再修正程序中

2、之問題。,編碼與修正模式 (c.2),主要之問題： 過程中沒有規(guī)劃(plan)、分析及設(shè)計(jì)，故經(jīng)過幾次修正之后，程序代碼的邏輯變得難以理解。 無使用者需求分析與確認(rèn)，軟件雖設(shè)計(jì)得很好，但可能并不符合使用者的需求。,階段模式,具有方法論之雛型。 改善了編碼與修正模式之問題，強(qiáng)調(diào) 系統(tǒng)開發(fā)前要有規(guī)劃(plan)， 程序編碼(coding)前要有分析與設(shè)計(jì)， 系統(tǒng)上線前要有測(cè)試(testing)等。,階段模式 (c.2),階段模式 (c.3),雖已改善了編碼與修正模式之問題，但使用上仍衍生以下之問題： 不論系統(tǒng)之大小或復(fù)雜程度均需經(jīng)歷八階段， 各階段之進(jìn)行是循序的且階段間沒有回饋， 各階段均需考慮完

3、整的系統(tǒng)范圍，不可僅考慮部份系統(tǒng)， 假設(shè)使用者需求可完整且清楚的描述。,瀑布模式,開發(fā)的過程分成幾個(gè)階段，且劃分上較有彈性。 每個(gè)階段清楚定義要做那些工作及交付那些文件，使系統(tǒng)開發(fā)之工作更明確及容易掌握。 可允許階段間之回饋，若在各階段發(fā)現(xiàn)錯(cuò)誤，能盡早修正以減少系統(tǒng)修改或重做之成本。 各階段循序的執(zhí)行且僅循環(huán)一次。,瀑布模式 (c.2),當(dāng)系統(tǒng)較小或較單純，劃分的階段可能少至三個(gè)，例如分析、設(shè)計(jì)、實(shí)作(Implementation) 等階段。,瀑布模式 (c.3),瀑布模式 (c.4),若面對(duì)較大或復(fù)雜之系統(tǒng)時(shí)，其階段可再被細(xì)分成更多個(gè)階段：,瀑布模式 (c.5),瀑布模式 (c.6),瀑布模

4、式的一些問題： 假設(shè)在項(xiàng)目開始時(shí)，需求可完整且清楚描述， 所有需求在各階段均需同時(shí)考慮，且系統(tǒng)開發(fā)在一個(gè)周期內(nèi)完成， 在程序編輯前過于強(qiáng)調(diào)完整的分析與設(shè)計(jì)文件，故一但需求變更，文件需大幅修改， 程序編輯于系統(tǒng)開發(fā)周期之后段才開始，故風(fēng)險(xiǎn)較高，且失敗之成本亦較高，,瀑布模式 (c.7),(5)系統(tǒng)開發(fā)周期較長(zhǎng)且過程中使用者參與不足。,漸增模式,把需求分成幾個(gè)部分，然后將每個(gè)部分的需求之開發(fā)訂為一個(gè)開發(fā)周期，每個(gè)周期可依序或平行開發(fā)。 每個(gè)周期之階段清楚定義要做那些工作及交付那些文件， 每個(gè)周期內(nèi)，各階段循序進(jìn)行且僅循環(huán)一次。,漸增模式 (c.2),漸增模式 (c.3),特色： 系統(tǒng)被分成幾個(gè)子系

5、統(tǒng)或功能，各子系統(tǒng)可獨(dú)立依序或平行開發(fā)。 系統(tǒng)開發(fā)可由多個(gè)周期完成，每個(gè)周期均有分析設(shè)計(jì)、程序編輯及測(cè)試，每個(gè)周期完成不同版本之系統(tǒng)。 使用者參與程度高，每個(gè)周期均參與，故相較于瀑布模式，漸增模式之風(fēng)險(xiǎn)較低。,漸增模式 (c.4),漸增模式適用之情況： (1) 目標(biāo)與需求可完全與清楚描述。 (2) 預(yù)算需分期編列。 (3) 需要時(shí)間來熟悉和接受新科技。,雛型模式,此方法先針對(duì)使用者需求較清楚的部分或信息人員較能掌握之部份，依分析、設(shè)計(jì)與實(shí)施等步驟快速進(jìn)行雛型系統(tǒng)開發(fā)。 過程中，強(qiáng)調(diào)盡早以雛型系統(tǒng)做為使用者與信息人員需求溝通與學(xué)習(xí)之工具，雙方透過雛型之操作與回饋，以厘清、修改及擴(kuò)充需求，并藉以修

6、改與擴(kuò)充雛型系統(tǒng)。 上述步驟反復(fù)進(jìn)行，直到系統(tǒng)符合雙方約定為止。 雛型系統(tǒng)有時(shí)是一個(gè)：只有使用者界面，而沒有核心部分的軟件。,雛型模式(c.2),雛型模式 (c.3),主要特性與原則： 強(qiáng)調(diào)雛型之盡早開發(fā)及使用者高度的參與。 強(qiáng)調(diào)以雛型作為使用者及系統(tǒng)開發(fā)者之需求溝通與學(xué)習(xí)機(jī)制。 從需求最清楚部分著手開發(fā)雛型，并透過使用者對(duì)雛型之操作與回饋，反復(fù)修改與擴(kuò)充，每次反復(fù)之周期要盡可能縮短。,雛型模式 (c.4),其它適用情形： 當(dāng)無法立即獲得解決問題的方法。 當(dāng)軟硬件之技術(shù)與支持不確定。,雛型模式 (c.5),雛型模式的潛在問題： 系統(tǒng)文件較不完備，程序亦較難維護(hù)。短期可能較能滿足使用者需求，但長(zhǎng)

7、期而言系統(tǒng)較易失敗。 因缺乏整體之規(guī)劃、分析與設(shè)計(jì)，故較不適合于大型及多人參與之系統(tǒng)開發(fā)項(xiàng)目。,雛型模式 (c.6),有兩種常見之應(yīng)用策略： 演進(jìn)式雛型 (Evolutionary Prototyping) 用后丟棄雛型 (Rapid Throwaway Prototyping),演進(jìn)式雛型策略(c.7),將所有需求看成一個(gè)整體，從需求最清楚的部分快速的經(jīng)歷一開發(fā)周期，以完成初版雛型系統(tǒng)， 再利用該雛型與使用者溝通以確定、修改和擴(kuò)充需求，并藉以做為下一周期雛型演進(jìn)之依據(jù)， 該周期不斷的反復(fù)進(jìn)行，一直到雛型系統(tǒng)符合雙方約定為止。,演進(jìn)式雛型策略 (c.8),用后丟棄式雛型策略(c.9),以一種快

8、而粗糙(Quick and Dirty)的方式建立雛型，以促使使用者能夠盡快藉由與雛型之互動(dòng)來決定需求項(xiàng)目，或信息人員藉以研發(fā)問題之解決方法與信息科技之應(yīng)用。 應(yīng)用該策略開發(fā)之雛型，不需考慮系統(tǒng)之運(yùn)用效率、可維護(hù)性與容錯(cuò)能力等。,用后丟棄式雛型策略(c.10),雛型丟棄之原因，如 開發(fā)工具不同， 操作系統(tǒng)不兼容， 設(shè)計(jì)方法不兼容， ,用后丟棄式雛型策略(c.11),僅實(shí)施在風(fēng)險(xiǎn)程度最高的地方，例如需求或解決問題之知識(shí)、概念與信息科技整合最不清楚的情況。因?yàn)殡r型之丟棄也意味著成本的浪費(fèi)。 其它情況則盡可能的采用演進(jìn)式雛型策略。,螺旋模式,導(dǎo)入項(xiàng)目管理的概念與方法，為一風(fēng)險(xiǎn)導(dǎo)向的模式。 由三個(gè)步驟

9、形成一周期： (1) 找出系統(tǒng)的目標(biāo)、可行之實(shí)施方案與限制。 (2) 依目標(biāo)與限制評(píng)估方案，解決風(fēng)險(xiǎn)。 (3) 并由剩下之相關(guān)風(fēng)險(xiǎn)，決定該步驟該如何進(jìn)行。 此周期反復(fù)進(jìn)行，直到系統(tǒng)開發(fā)完成為止。,螺旋模式 (c.2),螺旋模式 (c.3),步驟一、找出系統(tǒng)的目標(biāo)、可行之實(shí)施方案與限制 (1) 找出系統(tǒng)的目標(biāo) 系統(tǒng)目標(biāo)之評(píng)核因素很多，例如系統(tǒng)的績(jī)效、功能與容忍改變之能力等。 (2) 找出系統(tǒng)之實(shí)施方案 系統(tǒng)實(shí)施方案會(huì)因問題而異，例如找出之方案有設(shè)計(jì)A、設(shè)計(jì)B、重用、購(gòu)買等。 (3) 實(shí)施方案之限制 實(shí)施方案之限制可能為項(xiàng)目之成本、時(shí)程、系統(tǒng)接口等。,螺旋模式 (c.4),步驟二、依目標(biāo)與限制評(píng)估

10、方案，解決風(fēng)險(xiǎn) 主要是找出各方案之不確定處，并設(shè)法解決，其步驟如下： (1) 找出項(xiàng)目風(fēng)險(xiǎn)之重要來源。 (2) 解決風(fēng)險(xiǎn)來源： 可用雛型、模擬、標(biāo)竿 (Benchmarking)、參考點(diǎn)檢查 (Reference Checking)、問卷、分析模式、上述之綜合或其它技術(shù)以解決風(fēng)險(xiǎn)。,螺旋模式 (c.5),步驟三、由剩下之風(fēng)險(xiǎn)決定該步驟 若系統(tǒng)的績(jī)效或使用者接口風(fēng)險(xiǎn)將強(qiáng)力影響程序開發(fā)或內(nèi)部接口控制，則此步驟可能是采取演進(jìn)式雛型。 若該雛型使用性佳且夠強(qiáng)韌（Robust），足以當(dāng)做未來系統(tǒng)發(fā)展之基礎(chǔ)，則往后將是一系列的雛型演進(jìn)。 假如先前之雛型努力已解決了所有的績(jī)效或使用者接口之風(fēng)險(xiǎn)，則此一步將遵

11、循基本的瀑布模式，亦可適當(dāng)?shù)男揎椧哉蠞u增模式。,螺旋模式 (c.6),特色與應(yīng)用原則： 在高風(fēng)險(xiǎn)部分之設(shè)計(jì)尚未穩(wěn)定前，規(guī)格之發(fā)展不需要一致、詳盡或正式，以避免不必要之設(shè)計(jì)修改。 在開發(fā)之任一階段，螺旋模式可選擇整合雛型模式以降低風(fēng)險(xiǎn)。 不同周期，可能采用不同的開發(fā)模式。 當(dāng)更吸引人之方案被找出，或新風(fēng)險(xiǎn)需被解決時(shí)，可整合重做或回到前面之階段。,螺旋模式 (c.7),包含了現(xiàn)有模式之大部分優(yōu)點(diǎn)，其風(fēng)險(xiǎn)導(dǎo)向之方法解決了許多模式之問題。在某些條件下，螺旋模式相當(dāng)于某一現(xiàn)有之模式。例如： (1) 若項(xiàng)目在系統(tǒng)的績(jī)效或使用者接口需求方面屬于低風(fēng)險(xiǎn)，且在預(yù)算及時(shí)程控制方面屬于高風(fēng)險(xiǎn)，則這些風(fēng)險(xiǎn)之考慮會(huì)使

12、螺旋模式之執(zhí)行相當(dāng)于瀑布模式或漸增模式。 (2)若項(xiàng)目在預(yù)算及時(shí)程控制、大型系統(tǒng)之整合或需求變動(dòng)方面之風(fēng)險(xiǎn)較低，且在系統(tǒng)的績(jī)效、使用者接口或使用者決策支持需求方面之風(fēng)險(xiǎn)較高，則這些風(fēng)險(xiǎn)之考慮會(huì)使螺旋模式之執(zhí)行類似于雛型模式。,同步模式,主要是為了縮短系統(tǒng)開發(fā)時(shí)間，加速版本之更新，因應(yīng)商業(yè)軟件包的市場(chǎng)競(jìng)爭(zhēng)。 適用情形： 需求可明確與完整的描述。 有足夠的人力參與。 團(tuán)隊(duì)間有良好的溝通、信息交換與項(xiàng)目管理。,同步模式(c.2),優(yōu)點(diǎn)： 開發(fā)時(shí)間的縮短可提高產(chǎn)品的競(jìng)爭(zhēng)力。 缺點(diǎn)： 緊湊的步驟及頻繁的信息溝通，使得項(xiàng)目管理的復(fù)雜度大幅提高，人力成本也相對(duì)提高。 若沒有輔以良好的工具及管理方法，則不易達(dá)

13、成目標(biāo)。,同步模式(c.3),基于三個(gè)主要的構(gòu)想來達(dá)到時(shí)程縮短的目標(biāo)： 多個(gè)團(tuán)隊(duì)同時(shí)開發(fā)。這種多組人同時(shí)工作的方式稱為活動(dòng)同步（Activity Concurrency）。,同步模式 (c.4),同步模式(c.5),信息同步。不同團(tuán)隊(duì)的信息互相交流與共享稱為信息同步（Information Concurrency）。 信息同步有三個(gè)技巧： (1) 向前傳遞(Front Loading) (2) 向后傳遞(Flying) (3) 建立有效的信息交換網(wǎng)絡(luò)及群體工作的支持環(huán)境 整合性的管理系統(tǒng)。同步開發(fā)方法的管理方法比一般的系統(tǒng)開發(fā)復(fù)雜，必須開發(fā)一個(gè)管理系統(tǒng)以協(xié)調(diào)人員、資源、過程和產(chǎn)品間復(fù)雜的互動(dòng)關(guān)

14、系。,同步模式 (c.6),同步模式 (c.7),RUP 模式,RUP (Rational Unified Process) 模式于1998由Ivar Jacobson、Grady Booch和James Rumbaugh提出。 以架構(gòu)為中心(Architecture-Centric)的開發(fā)模式。 結(jié)合螺旋模式的概念，以反復(fù)式(Iterative)與漸增式(Incremental)的軟件開發(fā)原理進(jìn)行軟件開發(fā)。 反復(fù)式意指重復(fù)用相同的的一系列操作或步驟以進(jìn)行軟件開發(fā)。 漸增式意指每一次在軟件產(chǎn)品上新增工功能、模塊、組件或子系統(tǒng)等。,RUP 模式(c.2),每一次的反復(fù)需產(chǎn)出一個(gè)可運(yùn)作的系統(tǒng)版本，

15、并在每一個(gè)反復(fù)周期評(píng)估風(fēng)險(xiǎn)，以盡早發(fā)現(xiàn)問題。 不需假設(shè)項(xiàng)目開始時(shí)，使用者需求可完整且清楚描述。 可由動(dòng)態(tài)與靜態(tài)兩個(gè)構(gòu)面來說明系統(tǒng)開發(fā)項(xiàng)目之實(shí)施階段與核心工作。,RUP 模式(c.3),動(dòng)態(tài)構(gòu)面把軟件開發(fā)依序分成四個(gè)主要階段：初始、詳述、建構(gòu)與轉(zhuǎn)移。 這四個(gè)階段構(gòu)成一個(gè)周期，周期可反復(fù)進(jìn)行，每個(gè)周期內(nèi)之各階段也可以視情況反復(fù)進(jìn)行。 靜態(tài)構(gòu)面主要表達(dá)成九個(gè)核心工作流程(Workflows)或過程(Processes)： 有六項(xiàng)屬于軟件工程工作：企業(yè)模型、需求、分析與設(shè)計(jì)、實(shí)作、測(cè)試、配置(Deployment) 三項(xiàng)屬于管理支持工作：項(xiàng)目管理、組態(tài)管理與變動(dòng)管理、環(huán)境,RUP 模式(c.4),第四

16、代技術(shù)*,第四代技術(shù)(4th Generation Techniques, 4GT)指的是輸入圖形(diagrams)或特殊語言，可以自動(dòng)產(chǎn)生原始程序代碼的技術(shù)。 圖形(diagrams)或特殊語言主要是用來描述軟件的特性與行為，4GT根據(jù)這些描述來產(chǎn)生原始程序代碼。 這些輸入就是所謂的第四代語言(4GL)。,第四代技術(shù)(c.2),采用4GT開發(fā)軟件，還是要經(jīng)過分析、設(shè)計(jì)、編碼、測(cè)試、維護(hù)等階段。 采用4GT開發(fā)的方式，必須使得軟件易于維護(hù)。 使用4GT開發(fā)小型軟件，有時(shí)可直接從需求擷取的階段跳到實(shí)施(Implementation)的階段。 若和組件開發(fā)方式合用，4GT可能便變成軟件開發(fā)的主要

17、方法。,第四代技術(shù)(c.3),優(yōu)點(diǎn) 支持者聲稱可加快開發(fā)的速度，提升生產(chǎn)力。 缺點(diǎn) 反對(duì)者聲稱4GT的工具不比程序語言簡(jiǎn)單， 產(chǎn)生的原始程序代碼執(zhí)行效率差， 4GT產(chǎn)生的大型軟件，其維護(hù)仍然是個(gè)問題。,快速應(yīng)用軟件開發(fā)*,快速應(yīng)用軟件開發(fā) (Rapid Application Development, RAD)強(qiáng)調(diào)以極短時(shí)間(約60-90天)完成軟件的開發(fā)。 程序的產(chǎn)生盡可能使用組件開發(fā)方式及第四代技術(shù)縮短開發(fā)時(shí)間。 主要用于開發(fā)需求可完整且清楚描述的信息系統(tǒng)。 分?jǐn)?shù)個(gè)周期平行開發(fā)，每一周期由一個(gè)團(tuán)隊(duì)完成一功能組(模塊)。,快速應(yīng)用軟件開發(fā)(c.2),一個(gè)周期包含： 商業(yè)塑模(business modeling) 資料塑模(data modeling) 處理塑模(processing modeling) 程序的產(chǎn)生(ap