【系統分析】資訊系統開發模式

一、編碼與修正模式
二、階段模式
三、瀑布模式(Water Fall Model)
四、漸進模式(incremental model)
五、雛型方法(Prototyping)
六、螺旋模式
七、同步模式
八、Rational統一流程模式(Rational Unified Process)

解說：


一、編碼與修正模式

最早使用的模式，並無方法論可言。

主要包含兩個步驟：1.先寫部份程式2.再修正程式中的問題。

主要問題是：1.沒有規劃及設計，且後續的維護困難且成本很高。

2.過程中無使用者需求分析與確認。故不符合使用者需求。

先編碼，再考慮需求、設計、測試與維護

經過幾次之修正後，程式碼的邏輯變得難以理解，以致於後續之維護很困難且成本很高

二、階段模式

已有方法論的雛型。

強調系統開發前要有規劃，程式編輯時要有分析與設計，系統上線時要有測試。

但仍有下列的問題

1.      不論系統大小複雜都需八個階段(較沒有彈性)

2.      各階段進行是循序的且各階段間沒有回饋

3.      各階段需考量完整的範圍

4.      假設需求可完整且清楚描述

三、瀑布模式(Water Fall Model)

是一種符合邏輯的模式，也隱含重要的管理意義。

將系統開發的過程分成「幾」個階段，且每個階段清楚定義該做哪些工作及交付哪些文件，各階段循序執行且僅循環一次。

例如：分析、設計、實施。

在各階段間發現錯誤可允許階段間的回饋可減少系統修改重做的成本(比階段模式有彈性)。

各階段明確定義該做的事，使系統開發的工作更明確更容易掌握。適用於低風險的專案。

但仍有下列的問題

1.      專案開始時，需求可完全且清楚地描述。

2.      所有需求在各階段需同時考量，且系統開發在一個週期內完成。

3.      在程式編輯前過於強調完整的分析與設計文件，故一但需求變更，文件就需大幅修改

4.      系統開發週期較長且過程中使用者參與不足

5.      程式編輯於系統開發週期的後段才開始，故風險較高，相對的失敗的成本也會較高。

四、漸進模式(incremental model)

漸增模式是一種系統開發方法，該方法把需求分成「幾」個部分，然後依漸增開發計畫將每個「部分需求」之開發訂為一個開發週期，每個週期可依序或平行開發。每個週期之階段清楚定義要做哪些工作及交付哪些文件，每個階段循序進行且僅循環一次。系統之分析與設計採「由上而下」之方式。

與瀑布模式大部份相同只有下列不同之處：

1.      系統被分成幾個子系統或功能，各子系統可獨立依序開發。

2.      系統開發可由多個週期完成。

3.      故風險較低相對的失敗成本也較低。

五、雛型方法(Prototyping)

針對使用者需求較清楚的部分或資訊人員較能掌握之部分，依分析、設計與實施等步驟快速開發雛型。開發過程中，強調盡早以雛型作為使用者與資訊人員需求溝通與學習之工具，雙方透過雛型之操作與回饋，以釐清、修改及擴充需求，並藉以修改與擴充雛型。

適用於需求改變可能發生於整個專案生命期間、客戶能高度參與、應用領域不熟悉高風險等情況的專案，不適用於具有固定的需求與實際技術上沒有困難的專案。

1.      強調雛型快速開發及使用者高度的參與。

2.      強調以雛型作為使用者及系統開發者的需求溝通與學習機制。

3.      從需求最清楚的部分開發雛型，必透過使用者對雛型的操作與回饋反覆的時間盡可能的縮短。

潛在問題：

1.      因為強調一雛型演進代替完整的分析與設計，故系統文件較不完備，程式可能較難維設，短期而言可能滿足使用者需求，長期而言系統較易失敗。

2.      缺少整體的規劃、分析與設計，故不適用於大型及多人參與的系統開發專案。

六、螺旋模式

1、找出系統的目標、可行之實施方案與限制

2、依目標與限制評估方案
3、由剩下之相關風險決定下一步驟該如何進行。
形成一個週期。
重要特色，每個週期之結束需由與系統有關之主要人員或組織來檢討系統績效

1. 在高風險部分的設計尚未穩定前，規格的發展不需要一致詳盡或正式，以避免不必要的設計修改。

2. 在開發的任一階段，可選擇整合雛型模式來降低風險
3. 當找出更吸引人的方案或新風險需被解決時，螺旋模式整合重做或回到的階段。
它包容現有軟體流程模式的大部份優點，其風險導向的方法解決了許多系統開發模式所存在的問題。

七、同步模式

同步工程的目的在於縮短產品開發時，以提高市場競爭力。同步模式基於多個團隊同時開發的構想高縮短開發時間。
基於
1.多個團隊同時開發
2.資訊同步
3.整合性的管理系統
三個構想來達到時程縮短的目標。

優點是開發時間的縮短可提高產品的競爭力

缺點是緊凑的步驟頻繁的資訊溝通，使專案管理的複雜度提高相對人力成本也較高。若沒有良好的工具及管理方法，則不易達成目標。

八、Rational統一流程模式(Rational Unified Process)

結合螺旋模式的概念，以反覆與漸增的軟體發展原理進行軟體開發，每一次的反覆需產出一個可運作的系統版本，並在每一個反覆週期評估風險，以盡早發現問題。

可分為動態與靜態兩個構面。

比較分析表：

模式	瀑布模式	階段模式	雛型模式	螺旋模式	同步模式	RUP模式
提出者	Royce 1970	Benington 1956	Bally 1977	Mills1986 Boehm1988	Aoyama 1993	Jacobson 1998
優點	1.建立嚴謹、標準的發展程序。 2.清楚的階段分，易於分工及責任歸屬。 3.符合模組化的觀念。	1.已具有系統開發階段。 2.強調系統開發前要有規劃。	1.可以充分瞭解使用者的需求 2.允許使用者隨時改變需求 3.協助使用者發現新的需求 4.快速的系統發展，降低風險	1.每一個演進層次皆進行風險分析。 2.它利用雛型模式作為降低風險的方法。 3.它保持了瀑布模式中，系統化且循序前進的優點。	1.開發時間的縮短可提高產品的競爭力。	清楚定義系統發展的階段與核心工作流程,強調盡早處理風險問題,快速開發出一個系統的初始版本,並反覆進行
缺點	1.因以循序性的方式進行階段轉移，導至系統在沒開發完成前，看不到成果。 2.某一階段工作無法如期完成時，將導至後續階段的所有工作停頓	1.不管系統大小,都要經過八個階段。 2.系統沒有彈性,階段間沒有回饋。	1.因工作雛型不斷的修改，且缺少文件製作的管理，故不易維護。 2.缺少有效的設計評估準則。 3.因缺少嚴謹的分析與設計	1.進化的過程不容易控制。 2.需要很多風險評估的專業知識。 3.並不像瀑布模式及雛型模式廣泛被運用。	1.緊湊的步驟及資訊溝通的頻繁，使得專案管理的複雜度大大提高。 2.人力成本亦相對提高。 3.若沒有良好的工具及管理方法，則不易達成目標。	1.在每一個反覆週期都需經過風險評估。 2.系統發展的年代比較晚。