摘要
- 文章編號：20050901
- 投稿日期：2005/08/25
- 作者： 張騉翔
- 備註：
隨著資訊系統的發展，越來越多的軟體工程方法提出來以協助資訊系統順利發展，例如Extreme
Programming、CMMI…等；目前軟體工程方法大體上可分為兩大類，一類是瀑布式（Waterfall）的開發方式，另一類是回合式
（Iteration）的開發方式，它們之間最主要的差異在於瀑布式的開發方式是將所有的需求及施工規格確定後，再進行資訊系統的建置，而回合式
（Iteration）的開發方式則是假設使用者本身對於資訊系統的需求也不是很清楚，只有大概的輪廓，所以主張利用雛型系統的方式來搜集需求，在瞭解了
初步的需求後，先建置雛型系統，建置完後再利用雛型系統與使用者討論，再搜尋更詳細的需求，然後再修改雛型系統以使其更接近最後完工的成品。
瀑布式或回合式的方法沒有誰好誰壞，若是較簡單的系統，可能採用瀑布式的方法較適合；對於大型的系統，較無法立即規劃出所有的細節，可能採用回合式的方法較適合。
然而，不管是哪種開發方式，很重要的是要能讓行政流程的驗收、付款要能夠搭配資訊系統開發流程，否則會使得資訊系統開發流程只是空談，舉例而言若是客戶採
用一次驗收及付款的方式，然而資訊系統的開發方式卻採用回合式的方式，需要階段規劃及建置，此時將無法得到客戶相對應的配合。底下我們以使用案例的方式來
表達欲將資訊系統委外的委任者對於資訊系統委外可能的預算編列方式：
名稱：委託資訊服務-系統分析、規劃、建置、及維護
撰寫者：尤黎明
使用情境：
設計範圍：委任者(學校或教育主管單位)
/白箱
目標等級： 目標摘要(最高)
主要參與者：
關係人與利益：
事先條件：
最小事後保證：
成功事後保證：
觸發事件：
主要成功情節：
1.委任者決定資訊系統發展以第一類方式編列預算。
2.委任者辦理招標。
3.委任者辦理決標。
4.委任者辦理履約管理。
5.委任者辦理驗收。
6.委任者辦理付款。
擴充情節：
1b. 委任者決定資訊系統發展以第二類方式編列預算：
1c. 委任者決定資訊系統發展以第三類方式編列預算：
技術與資料變異情形清單：
發生頻率：
備註：
1.第一類預算方式：把整體系統發展之需求分析、規劃與建置編入同一項預算案，一次委外。
2.第二類預算方式：把整體系統發展之需求分析與規劃編入一項預算案，委外驗收後，根據需求分析與規劃結果，將系統建置編入另一項預算案委外。
3.第三類預算方式：把整體系統發展之需求分析與規劃編入同一項預算案，一次委外，分階段施工驗收。根需求分析與規劃之各段結果，分別編列系統建置預算，分案委外。
4.以上各類預算方式，包括系統保固若干年。保固期之後，把各年度系統維護編入各年度預算案，分年分案委外。 |
在上面的使用案例中，對於資訊系統委外的預算方式最主要分為三種，第一種是「把整體系統發展之需求分析、規劃與建置編入同一項預算案，一次委外」，
這樣的預算方式較適合「瀑布式的開發方式」，然而這種預算的編列方式可能會有一缺點，亦即規劃與建置為同一團隊，團隊在規劃時可能會少規劃，讓在建置階段
能輕鬆些。
第二種是「把整體系統發展之需求分析與規劃編入一項預算案，委外驗收後，根據需求分析與規劃結果，將系統建置編入另一項預算案委外」，此種預算方式也算是
屬於「瀑布式的開發方式」，然而不一樣的地方在於此種方式編列了兩階段的預算，第一階段用來做「需求分析與規劃」，第二階段用來做「建置」；這樣的好處是
第一階段的團隊可與第二階段的團隊可以為不同的人，在第一階段的團隊可專注於「需求分析與規劃」而不需考量到後續的建置問題，也就不會有第一種預算編列方
式提到的為了讓「建置」階段輕鬆點就在「需求分析與規劃」階段時少分析些；然而運用此種預算編列的方式要注意的是「需求分析與規劃」階段的成果需能為「建
置」階段所參考，否則若「需求分析與規劃」不完整的話，將會使「建置」階段的團隊困惱，因為還需做「需求分析與規劃」的工作。
第三種是「把整體系統發展之需求分析與規劃編入同一項預算案，一次委外，分階段施工驗收。根需求分析與規劃之各段結果，分別編列系統建置預算，分案委
外。」此種預算編列方式能搭配「回合式的開發方式」，假設資訊系統的需求是一直變動的，並且需求也很難一次確認；「需求分析與規劃」及「建置」是平行進行
的，兩者都可再分成多個階段，當某階段的「需求分析與規劃」完成後，即可進行「建置」，也同時再進行下階段的「需求分析與規劃」。
|