[軟體工程] 作業一_軟體專案失敗案例分析
Q: 請提出軟體專案在開發過程中遇到的問題，以及可能可以處理的方法。-- From 中正大學 熊博安教授 實驗室
A:
由於本人的工作經驗都是圍繞在硬體開發為主，所以針對軟體專案就從網路上去尋找素材，這次的主題是甲骨文與奧勒岡州政府的軟體專案失敗案例。
專案結果：在2012年9月，奧勒岡州政府決定建造「健康保險交易入口網站」(ORHIX)，預計在2013年10月讓申請者可以使用。但是一直到2014年3月，網頁仍尚未完成，且所有ORHIX的申請者只能透過紙本申請。
失敗原因/改善方針：
失敗原因一：PO(Purchase
Order)內容描述不明確
Figure1: PO value不匹配 合約中明確指出，在T&M(時間和材料)合約的基礎下提供0.35億美元給甲骨文公司作為「協助」奧勒岡州政府建立ORHIX系統，但是經由合約中規定的計算方式，PO明顯有被低估的嫌疑(參照Figure1)。0.35億是由118,447小時的服務時數計算而來，但是利用PO中的labor rate和預估時數表來計算，實際PO價格應該為0.34億美元，整整需少付95萬美元給甲骨文。
改善方針一：
合約中應該將專案項目明確列舉，並標示將相對應的金額，避免模糊不清的狀況。如此案例中的PO與計算出的支付金額不同，導致合約有低估的嫌疑。
失敗原因二：合約形式採用T&M而非fixed-price
因為合約是以T&M的形式，等同於把所有的風險都壓在甲骨文身上，必須在時間內完成奧勒岡州政府的專案。合約中可以明顯看出，甲骨文扮演的角色都是以「輔助」為主，有大量的「assist」字眼出現(參照Figure2)，必須順從於奧勒岡州政府或是所謂的SI(系統整合商)。合理的方式應該要把給甲骨文的合約形式變成fixed-price。
改善方針二：
專案中的SOW多次強調甲骨文公司以「協助」的角色完成項目，但是卻又以T&M合約的形式，把專案責任轉嫁到甲骨文公司身上，造成權責分配不公正的情形。合約上的描述，應該清楚定義某公司需要完成軟體項目，而非以灰色地帶的「協助」字眼帶過。合約形式應以fixed-price，在固定的預算下完成有限的項目，讓project scope有明顯的界定，不會無限大的擴增。
失敗原因三：缺乏充分的專案規劃與管理
奧勒岡州政府雇用Maximus負責每月ORHIX專案的稽核，報告中顯示好幾個項目都是在高風險的狀況下，甚至在專案規劃初期就已經指出眾多問題。弔詭的是，進行稽核的單位CMS和FirstData確認專案的監督小組並沒有重視Maximus的品質管理表(參照Figure３)。
改善方針三：
專案的風險管理需要定期管控，藉由風險管控表，可以把資源投入在高風險的項目上，讓整個專案成員都有一致性的目標，而非推諉塞責。成員間也需要不定時的溝通協調，當技術面發生問題或是客戶需求不明時，應該要將問題提出，如果沒有人願意處理時，必須把問題上傳到上層階級，讓利益關係人有所了解與警覺，才不會讓專案進度藏有許多不定時炸彈，不知道在哪一刻會爆炸。
留言
張貼留言