搶救軟體專案大作戰

軟體專案的困難
人員流動率高，是高科技製造業的痛，如果不能有效掌控軟體生命周期的每一個階段，企業將一再面臨專案失控的問題。

先做好需求分析，否則其餘免談
若不能在一開始把事情「做對」，那麼後面再多的努力都是白費，寫程式只是實作設計的過程，跳過前一階段最重要的需求分析與系統設計的過程，是捨本逐末的行為。

流程改善5步驟－沒有偉大的流程，只有適合的流程
世界上並沒有「偉大的」流程，也沒有最佳實務。企業應考量自身的條件，選擇符合實際情況的開發流程，硬套死板的理論或工具，是無法複製他人的成功。

XP訴求以最佳智慧做出客戶最想要的東西
XP強調溝通、簡單、回饋與決心這四個價值觀，重視客戶在開發過程中的角色，透過充分的溝通與健全的測試程式，才能無懼改變，開發出最符合客戶需求的產品。

實作案例 XP讓鼎新EasyFlow GP放膽改變 為了找到適合的方法論，改善軟體開發的品質，EasyFlow GP開發團隊歷經半年的摸索期，幾乎一整年沒有可以展示的東西。現在證實，當初的堅持發揮強大的正面價值，鼎新ERP II也參考EasyFlow GP撰寫測試程式。

RUP有助於專案的控管
二維的RUP架構，共有9個工作流程與4個開發階段，在每個工作流程中，依據不同的角色，均有明確的工作、活動、步驟與產出，有助於管理者對專案的監控與管理。

實作案例 以RUP開發出口信用狀轉開／轉讓系統 資策會資訊工程研究所從2005年開始導入Rational的工具，出口信用狀轉開／轉讓系統是所內完整落實RUP開發方法論的先例，未來將推展至全所，希望有機會實現軟體工廠的可能。

CMMI提供檢驗與改善流程品質的參考
美國國防部為了改善頻頻採用不良軟體的情況，推出CMMI作為評估軟體廠商開發成熟度的模組，企業可以CMMI檢驗自身軟體開發流程成熟度等級，並作為改善的依據。

導入案例 通過CMMI Level 5評鑑，凌群累積持續改善的力量 一次被退貨的經驗，學到測試的方法，從測試開始，引發對品質重視，因此逐步引導出各種步驟與細節。

挑戰《人月神話》－印度的軟體代工
身為企業的委外夥伴，印度的軟體代工提供可以立即派上用場的大量人力與管理能力，可以符合領導型的企業全程訂製及短期開發的需求。

委外案例 東森購物ET1委外印度 時程高達1000人月的ET1上線了，開發其間包含著印度與臺灣之間不同文化的磨合，語言隔閡並 沒有造成很大的障礙，反倒是印度的工作文化，給臺灣上了一堂震撼教育。

軟體專案的困難

南亞科技資訊部課經理曾鴻志表示：「制定流程並不難，但真正的落實流程卻有很多的問題存在。」

南亞科技所有的應用系統包括ERP都是自行建置，資訊部門針對各部門的需求，皆會設法實作成為一套自動化系統，以便加速工作效率。南亞科技資訊部課經理曾鴻志表示：「早期系統開發流程與制度，充滿了『英雄主義』。」常常是一個人包辦系統分析、設計、開發、部署與維護的工作，沒有留下文件與記錄，所有的知識都在人的腦子裏。

當人員離職後，系統維護的困難度就相對提高。接手的人在沒有文件的協助下，只能解讀前人的程式碼，「這是哪個豬頭寫的？」是最常聽到的一句話，然而，就算重新改寫，就不會有下一個「豬頭」嗎？

南亞科技的高層逐步思考著制度與流程的改善方法，於是參考軟體廠商的作法，在2004年開始著手評估CMMI。對南亞而言，沒有評鑑的需求，而且導入CMMI的成本頗高，因此南亞傾向採用CMMI的精神，便於2005年組成跨部門的「流程改善小組」，每周定期開會檢討。

曾鴻志負責需求管理領域的流程，發現制定流程並不難，但真正的落實流程卻有很多的問題。因為對於工程師而言，填寫文件與表單，是很繁瑣的工作。為了落實CMMI的精神，南亞科技決定導入微軟的Visual Studio Team System，選擇MSF（Microsoft Solution Framework）中的MSF for CMMI Process Improvement流程，並加以調教，希望透過自動化工具降低工作負擔。

專案關乎競爭力
這樣一個追求軟體開發流程改善的例子，在同業中持續發酵，因為人員流動率高，是高科技製造業的痛，如果不能有效掌控軟體生命周期的每一個階段，企業將一再面臨專案失控的問題。企業或多或少都有軟體自製的需求，在國外，資訊服務（也就是專案開發）的比重，約是套裝產品的20倍；而國內根據MIC的統計套裝產品與專案開發的比例也有4:6的差距。

鼎新電腦技術總顧問周忠信分析：「套裝產品主要解決自動化的問題，專案開發的系統卻往往是營運的致勝關鍵。」電子郵件、文書處理甚至定型化的ERP系統，主要應付日常工作，提高工作效率與管理能力；但更多攸關核心競爭力的需求，是套裝產品無法滿足，必須透過客製化，甚至全程訂製，才能符合企業獨特的要求。

軟體本身的變化—
然而經過數十年的演進，軟體專案的成功率依然不高，其實軟體本身的變化也是原因之一，軟體從數百行至數千行，進展到數萬行乃至數十萬行程式碼的規模。而作業環境從簡單的批次作業，變成了複雜的多工、分時、分散式運算。當軟、硬體環境變得更大、更複雜時，軟體的發展流程也越來越複雜，從前小而簡單的開發方式，再也無法應付當前的需求。

中山大學資訊管理系教授鄭炳強認為，我們必須認清軟體開發工作具有以下本質上的困難：

● 複雜性－軟體要解決的問題，所牽涉的運算邏輯是一種人為、抽象的智能活動，多半是複雜的。

● 協同性－在大型軟體環境中，子系統之間的介面必須協同一致，但由於時間與環境的演變，維持一致性是十分困難的。

● 變易性－軟體所應用的環境，常是人、法規、硬體與應用領域各項因素融合而成，而這些因素皆會快速變化。

● 不可見性－尚未完成的軟體，即使利用圖像化的說明，也難以充分表達，使得溝通上面臨極大的問題。

人的影響—
除了軟體本身的變化與困難，更重要的因素是軟體開發是高度依賴「人」的活動，人不像機器可以長時間維持一貫的工作品質，所以人的素質、心情以及異動都會對專案造成影響。

專案可以承受幾輛卡車？
當一個專案換到第3個負責人的時候，我們還能期待他能清楚了解狀況嗎？因此如何降低人員異動對專案的影響，各式開發方法論皆提出因應的對策。

XP衡量專案健康指標之一的「卡車數量」理論：如果有一輛卡車撞死一個團隊成員，對專案的影響有多大？專案又可以承受幾輛卡車呢？雖然論調有些恐怖，不過XP的對策是強調搭檔編程（Pair Programming），並且要頻繁地更換搭檔（Switch Pair），力求所有的成員都可以共同維護專案的每一個部分，以降低對人的依賴性，那麼才不用擔心「卡車」可能的影響！這與企業管理強調的職務輪調是相同的概念。

而RUP的設計將軟體開發畫分不同的角色，每個工作流程皆有明確應執行的工作項目，每個工作項目又細分各種活動（Activity）與相對的產出（Artifact），再細看每個活動，也都包含詳細的執行步驟。當每個人只需專注於自身扮演角色所應處理的工作，在轉交給下一個人的時候，有明確定義應輸出/輸入的文件與程式，所以只要接續的人員，具有相同的背景知識，看得懂負責部分UML圖與文件，就可以快速參與工作，所以對專案的衝擊比較小。

鄭炳強提出了另一個觀點，他認為優良人才的流失，是專案最大的失敗，一個人力經常流動的團隊，不可能會有好的成效，因此應該盡量減少開發階段人力的中途離開。

專案要做到不依賴人，勢必需要大量的文件或自動化的工具，但文件與工具比人更不可靠，且需要付出額外的成本，所以比較好的策略，是盡量規畫良好的工作環境，讓人願意留下來。

流程的幫助—
事實上，流程是自然存在的。只要「人」開始「工作」，便啟動了一個流程，只不過，流程可能是混亂或變動的。「軟體工程」這個名詞已經問世38年了，開發方法論從前只是課本上的專有名詞，到現在已逐漸在軟體界發酵，而工程化的第一步，就是制訂標準化的流程。

沒有標準便無法可管
沒有事先的規畫、沒有固定的步驟、想到什麼就做什麼，雖然作法彈性，然而卻存在以下缺點：

● 任意刪改的危險：「哪個豬頭改了程式？」在不知情的狀況下，程式被別人修改，表示控管的流程出現問題。未經評估與審核的程式更動，可能牽一髮而動全身，引發一連串的錯誤。

● 自由心證的進度管理：專案負責人對於軟體開發的進度，若來自於是成員的自由心證，那麼覺得大概完成多少就說多少，擔心績效不佳就有可能出現虛報的情況，那麼所謂的「進度」，很可能只是美好的假象。

● 驚人的溝通成本：為了掌握真實的進度與狀況，不斷地確認與溝通，將有開不完的無效會議。

● 無法累積經驗：企業有不少制度或規定是因應過去曾經遭遇的問題，才衍生的特殊設計。若智慧與經驗是累積在特定人的腦袋裏，沒有標準化的制度與文件，企業便沒有累積與改善的依據。

軟體工程沒有銀彈
從採訪的案例中，不難發現流程標準化，改變原本的工作習慣，或多或少都會引起反彈。為降低習慣改變的衝擊，專家們建議從簡單做起。各式新穎的方法論與學說，如雨後春筍般出現，皆有相當吸引人的論調，但很有可能言過其實，軟體工程著名的暢銷書《人月神話》強調：「軟體工程沒有銀彈。」軟體開發至今仍困難重重的成因複雜，並不存在一帖見效的良方。

因此鄭炳強強調：「在評估方法論時，應先了解它的缺點與限制。」在大家盲目追求物件導向、多層式架構（N-Tier）時，鄭炳強最常問的便是：「你知道物件導向的缺點嗎？」、「你知道N-Tier架構的缺點嗎？」我們可以看到許多一窩蜂流行的後遺症。同樣的，任何工具與方法論皆有其強項與罩門，如果選錯了方法或工具，小心未蒙其利，先受其害！

與其革命，不如改善
每個企業的規模、文化、人員素質、專案特性與開發團隊的成熟度都不同，所以沒有足以一體適用的流程可以套用。如周忠信所言：「沒有多偉大的流程，確認習慣的流程就好。」企業並不是沒有流程，只是可能沒有「固定」發生的順序，或者存在一些缺失，因此需要的只是調整與補強。

一次革命性的變革衝擊過大，反而不易成功；基於既有的習慣尋求改善，漸進式的改變比較接受。因為痛苦的流程便不是好的流程，好的流程是無感的，如果可以丟掉所有的規章，讓制度融入企業成為文化與習慣的一部分，就是成功的流程。

3年 vs. 3個1年的經驗
在調適的過程中，面對成員的反彈，寶發科技總經理胡佑長表示：「如果覺得寫文件很浪費時間，表示寫文件的時間還不夠多。」以敷衍的心態寫文件，確實是很浪費時間；但若了解寫文件不是製造麻煩，而是為了避免未來更多的麻煩，就會花更多的心力與時間認真寫文件。

不過，在感受到寫文件留下記錄的好處前，仍需搭配稽核的手段，並有人擔任循循善誘的角色。以南亞科技為例，曾鴻志除了一再強調流程與文件的好處，並從個人競爭力的角度與員工分析他的看法：「在一家公司工作3年，你希望累積3年的經驗，還是3個1年的經驗？」如果還是以過去的方式開發系統，未來員工尋求新東家時，並沒有特別可以與他人競爭的優勢。

離岸委外的選擇—
委外開發也是軟體專案的選項之一，境內的委外是大家所熟悉的類型，考量的因素不離廠商的技術、服務品質、價格與存續性。當國內的委外費用因為人力成本的影響而墊高，人力便宜的大陸或印度成了另一種可能性。

接下一頁印度委外模式挑戰人月神話
東森購物委外印度開發虛擬購物平臺ET1，帶回很多值得探討的寶貴經驗，印度精細的工作切割，使他們顛覆了《人月神話》「在一個延遲的專案裏再加派人手，只會讓專案更延遲」的說法。事實上，《人月神話》的說法至少在臺灣是正確的論點。

松凌科技技術總監李日貴便曾經目睹客戶的一個上仟萬的委外專案，廠商在延遲的情況下，不斷地加派人手，然而溝通的代價抵消了人力增加的好處，致使延遲的情況更加嚴重。

東富資訊總經理許世杰以營建業舉例，他認為印度軟體開發的分工方式，是依綁鋼筋、灌漿、水電、挑磚、刷油漆等專業分工，所以工程延遲，依照目前的進度加派人手，10個人與20個人綁鋼筋的速度，理所當然可以倍數成長。工人依監工的指示，照藍圖施工，不會質疑設計師的想法。

而臺灣的作法，是一群人負責客廳、一群人負責房間、另一群人負責廚房與浴室，每個人都會綁鋼筋、灌漿、水電、挑磚、刷油漆，但進度落後時，加派人手就存在許多交接、協同合作與溝通的問題，所以新人在「進入狀況」之前，必須「晾」在旁邊觀摩一段時間，所以產值是零。也因為搞不清楚狀況，所以常常反問為什麼要這樣、為什麼要那樣。

印度的分工方式，延伸的好處，是讓工程師有機會針對自身的專業持續累積經驗，例如設計報表的工程師，從各種專案經驗中，累積了許多報表樣式的範本，投入新的專案時便可以迅速套用，減少重工（Rework）加速工作效率。以印度軟體服務公司Wipro為例，每年都提撥15～20%的淨利，用於整理在過去專案中開發的元件，以利重複利用。

大陸委外屬於協同合作
印度軟體工程師的工作型態，類似生產線的作業員，不斷重複類似的動作，許世杰認為：「文化的關聯大於收入的影響，同樣的模式移植到同樣人力便宜的大陸，未必行得通。」在我們訪問凌群電腦的時候，談到凌群電腦集團於大陸成立的凌安電腦，其業務正是承接臺灣委外的專案或人力，細問凌安電腦的委外模式，確實與印度大不相同，印證了許世杰的說法。

凌安電腦是以工作「階段」切割，例如臺灣負責設計、大陸負責開發；或者臺灣開發系統、大陸協助測試。從許世杰的觀點分析，這樣的模式確實較符合大中華地區注重個人價值的民族特性。

領導型企業的核心系統適合委外印度
至於離岸委外該選擇印度還是大陸呢？根據我們的分析，領導型的企業，或者產品型的軟體適合委外印度。領導型的企業是產業的龍頭，最熟稔該領域的核心競爭力，例如東森購物不但產業性質特殊，而且是臺灣電視購物領域的第一把交椅，不可能有廠商或現成的產品，比東森更了解電視購物的領域知識，所以選擇專案開發才能完全貼近需求。

而攸關核心競爭力的系統，必須是短期製程，許世杰強調：「當一個專案的期程大於2年，其失敗的機率將大幅提高。」市場瞬息萬變，2年前的需求很可能已經不符合現實的情況，所以專案必須投入大量的人力在2年之內完成。此類領導型企業的專案，便適合尋求印度大量且專業的人力與分工能力。

此外，周忠信表示：「委外印度適合產品類型的軟體開發。」因為產品的功能固定，而專案型的軟體必須因應市場而變動，但印度的軟體代工在專案結束後，人力便徹出臺灣，鞭長莫及的情況下，不可能因應需求經常性變動的專案。專案後續的維護，便是必須考量的問題，除非企業有能力接手處理，否則維護工作將成燙手山芋，這也正是接手維護東森購物ET1系統的東富資訊，未來將面臨的考驗。

訴求降低人力成本，可放眼大陸
大陸的委外對企業而言，可視為資訊團隊的「分身」，只要做好安全的控管，臺灣與大陸便可以運用各自的優勢，分工合作協助企業建置e化系統。例如臺灣負責分析與設計，開發與測試的工作，委外由大陸較便宜的人力，便可降低成本，專注心力於更重要的事情。
目前已有企業以長期合作的方式，與對岸的資訊公司簽約，將資訊部門一定比例的工作，委外大陸完成，以降低臺灣的人力成本。

整體解決方案的陷阱
許世杰認為，臺灣資訊廠商喜歡強調整體解決方案（Total Solution），正是委外賺不到錢的原因。長榮航空電算本部應用程式部經理侯憲裕則分享他們委外的兩個經驗，一個是上仟萬的專案委外IBM；另一個預算規模較小的專案，則委外一家臺灣資訊服務廠商開發。IBM評估專案時，便言明哪些需求可以完成，哪些功能有困難；而臺商則是什麼都「OK沒問題」。

結果，是IBM在期限內結案，而且加入了部分原先保守評估無法提供的功能；而臺商負責的專案，不但延遲交付，而且不同於剛開始打包票的態度，有些功能是無法完成的。整體解決方案的概念，確實讓資訊廠商吃足苦頭，企業也必須體認：只會說「Yes」的廠商，其承諾令人質疑。

先做好需求分析，否則其餘免談

研究與開發CMM與PSP（Personal Software Process）的Watts Humphrey曾說：「在客戶催促的時候，大部分的工程師就會下意識地做他擅長的事情－Coding。」但若不能在一開始把事情「做對」，後面再多的努力都是白費。

寫程式只是實作設計的過程，跳過前一階段最重要的需求分析與系統設計的過程，是捨本逐末的行為。軟體開發就像開車，若未確認目的地的方向，便一路往前衝，或者抱著且戰且走的心態，便可能多走冤枉路。

IT工程師不如水泥工？先反求諸己
在建築業確認藍圖之後，便依圖施工，客戶不會說：「你先蓋給我看，不喜歡再拆掉重蓋。」但軟體領域，使用者卻有可能隨時在推翻之前的想法。

當水泥工表示：「水泥需要3天才會乾。」大家不會質疑水泥工的說法；但是軟體專案卻經常面臨客戶縮短工時的不合理要求。

IT工程師的專業不如水泥工嗎？目前軟體業正流行CMMI，廠商在努力調整體質的同時，卻也常抱怨：「廠商已經進步到Level 3了；而客戶卻還在Level 0。」對於客戶不合理的要求，或者想法改來改去的善變心態，寶發科技總經理胡佑長認同：「好的需求管理是甲乙雙方共同努力的結果。」（甲方：軟體購買者；乙方：資訊服務廠商）目前政府在大力推動CMMI-AM（Acquisition Module；籌獲模組）便是針對甲方的訓練，希望提升客戶端採購軟體應具備的相關能力。

不過，甲方的改變需要很長的時間，所以胡佑長提出更積極的建議：「乙方可以教育甲方。」甲方不了解軟體開發的「學問」，所以並不明白改變可能造成的影響，如果乙方有很好的流程，或可以提供量化的數據，便有機會說服甲方配合。

景華管理顧問資深經理李吟敏認為：「甲方是需要被教育的，但是怪罪甲方是單方面不負責任的行為。」需求的導出與確認是一門學問，臺灣從學校到企業，這方面下的功夫都太少。在國外的大學，需求分析稱之為「Business Analysis」是兩個學期的課程，每周都出一個題目，學生要學習分析與拆解，並提交完整的報告。

瞎子摸象才導致事倍功半
中山大學資訊管理系教授鄭炳強與學生開會時，都會要求學生記錄會議內容，整理成正式的文件；無獨有偶的，李家同也曾提到要求博幼基金會的小朋友看偵探小說，看完後寫出破案關鍵。會議記錄與讀書心得，都是釐清重點的訓練。使用者對於需求的表達是零散的，導出完整而正確的需求結構，是資訊人員應該具備的專業能力。

鄭炳強強調：「需求分析不只是資料搜集的工作。」純粹資料搜集的結果，就是一項需求對應一個功能，但若理解需求背後是解決何種問題，那麼也許只要10個功能就可以滿足100項需求。「報表」或「功能」只是滿足需求的「手段」而非目的，如果沒有了解背後的意義，就如同瞎子摸象，透過局部的印象，拼裝架構零散的系統，不僅事倍功半，而且開發出四不像的系統。

需求頻繁改變，很可能是因為始終沒有「搔到癢處」，需求分析不只是知道功能該如何運作（How），更要知道為什麼要這樣做（Why），才不會反客為主，被客戶牽著鼻子走。掌握領域知識（Domain Knowledge），贏得客戶的信任，就能主導專案的走向。所有的需求回溯到源頭，該掌握的是產業的精髓，知道客戶的痛才能對症下藥，否則頭痛醫頭、腳痛醫腳，只是治標不治本，才會如此的勞民又傷財。

e化若是競爭力的關鍵，改變是合理的
恆變是IT界唯一不變的現象，事前縝密的需求分析，可以避免大部分使用者說錯，或者開發者意會錯，所導致誤差的情況；然而另一個難解的問題是「Ｉ will know it,when I see it.」當使用者真正看到系統時，才能確認是不是自己想要的，或者又衍生出更好的想法。

鼎新電腦技術總顧問周忠信表示：「軟體界應該認清『變』是合理的現象。」如果e化是協助企業獲利的機制，那麼市場在變，沒道理要求客戶不能變。

若改變是必然的，那麼該著眼的是變更管理，以及讓客戶了解軟體開發的過程，認知修改的時間與金錢具體成本。軟體工程師的說服力不及水泥工，會被討價還價的原因，某種程度是因為軟體開發的過程比較抽象，是看不到也摸不到的。

新的需求引發額外的費用比較容易理解，而需求的修改就必須定義出變更的複雜性與影響的範圍，若能提出具體量化的數據或分析，使用者對於付費或延期交付的接受度便會提高。

流程改善5步驟－沒有偉大的流程，只有適合的流程

專家觀點

鄭炳強 ●國立中山大學資管系教授 ●臺灣軟體工程學會理事 ●高雄醫學大學資訊處顧問 “在選擇開發的方法與工具之前，一定要先了解它的缺點與限制。”

周忠信 ●東海大學資訊工程系教授 ●臺灣軟體工程學會理事 ●鼎新電腦技術總顧問 “簡單就是美。簡單才能輕易融入成為公司的文化。如果需要重新學習很多的知識、面臨大範圍的習慣改變，可能引發很大的痛苦與反彈。”

胡佑長 ●美國SEI授權臺灣首位CMMI主任評鑑員 ●寶發科技總經理 “不要迷信最佳實務。流程改善應該考量企業的規模、文化、專案的性質、人員素質、開發方式及開發團隊的成熟度等，尤其開發團隊的成熟度最為關鍵。”

David Anderson ●微軟總部參與MSF設計的Visual Enterprise Studio部門流程架構師 “流程應該像汽車的引擎，發動之後就自動運行。”

軟體開發流程的學派林立，從輕量級的如XP、SCRUM、FDD到重量級的RUP有多種選擇。不過，所有知名的理論，都找得到成功案例與和失敗教材，企業應考量自身的規模、文化、人員素質、開發方式及開發團隊的成熟度，選擇適合的流程，並允許保留調適的空間，硬套死板的理論或僵硬的工具，其實無法複製他人成功的經驗。

標準化是為了強化控管
軟體專案不能沒有管理，而管理必須透過計畫與流程落實。專案初期制訂的計畫都很理想，但是經過長時間的演變，實際情況往往與計畫脫勾。

制訂標準化的流程，開發階段的所有活動，便可區分為「進行中」、「完成」、「停滯」或「延遲」等各種狀態，其實與Workflow的概念類似，透明化的資訊，幫助管理者掌握實際的進展，便可有效地追蹤與管理分析、設計、開發、測試等各項活動執行的情況。

「制度」會帶來相對的「限制」，不過，寶發科技總經理胡佑長：「企業越希望靈活，就越需要制訂流程。」流程與靈活並不衝突，如果流程無法因應改變，表示流程過於死板而需要改善。

選擇方法論前，先了解缺點與限制
軟體開發的方法論很多，每一種都有令人嚮往的好處。不過，中山大學資訊管理系教授鄭炳強認為：「在選擇方法與工具之前，一定要先了解它的缺點與限制。」例如採用XP的前提，是擁有實力堅強的開發團隊；RUP不適合無法以使用案例（Use Case）描述需求的專案。若選擇了錯誤的方法，會為專案帶來無窮的困擾。

任何方法論找得到失敗的案例，微軟總部Visual Enterprise Studio部門流程架構師David Anderson分享在過去參與新加坡銀行開發信用貸款系統的經驗，在David加入前，原先採用RUP方法論，耗時3年產生3,500頁的文件，客戶最常說的一句話是：「Show me Something to eat!」除了成堆文件之外，客戶希望看到實際的東西，最終專案宣告失敗。David接手後，丟掉數以噸計的文件，採用敏捷的FDD（Feature Driven Development，特性驅動開發）方法論，結果出奇成功地在期限與預算內結案。

這表示敏捷的流程比較好嗎？在微軟舉辦的企業軟體工程高峰會中，便有使用者詢問，他們採用XP方法論，初期很順利，但開發到一定規模之後，逐漸面臨重構的困難，導致進度持續延宕。

再看看目前臺灣軟體界興起的CMMI全民運動，似乎為臺灣軟體開發流程品質找到了改善的契機，但若軟體廠商以通過「評鑑」為目標，實際開發專案仍以老方法做事情，大家也可以共同檢視品質改善的成果。

步驟１：考量自身的特質
成功的案例值得參考，失敗的教材不代表理論本身有問題，而是應該依據專案性質的不同，調整或混合應用成為真正適合的開發流程，並允許團隊在執行過程中，做必要的彈性修改。胡佑長認為：「流程改善應該考量企業的規模、文化、專案的性質、人員素質、開發方式及開發團隊的成熟度等，尤其開發團隊的成熟度最為關鍵。」

此外，胡佑長強調：「不要迷信最佳實務。」流程改善工程，大家都希望尋求參考的「範本」，然而並沒有「一體適用」或所謂的「最佳實務」存在，流程是需要量身訂作的。

凌群電腦研發二處經理鄧大宇，以3次參與導入CMMI的經驗分析：「即使同一集團的不同企業體，流程也有很大的差異。」凌安電腦是凌群電腦集團於大陸投資的子公司，鄧大宇協助凌安電腦導入CMMI Level 3時，曾以凌群電腦的流程提供參考，最終卻修改了60%以上的內容。

步驟2：尋找改善的目標
與其硬套別人的學說或理論，不如基於既有習慣的開發流程，調適成為標準化的步驟，再參考其他方法論的作法，補強自身脆弱的環節，就可以形成一個量身訂作的最佳流程。

至於什麼是脆弱的環節，鄭炳強認為：「如果某些問題一再發生，就需特別針對重複出現的問題，設計因應的流程。」軟體開發最常發生的問題，是層出不窮、無法預期的臭蟲（Bug），凌群電腦長達10年的品質改善工程，便是起因於臭蟲，進而開始學習測試的方法，建立專責的測試單位與測試流程，由測試又引發一連串對品質各環節的重視。

周忠信認為：「管理者可以從想『看』什麼，作為思考流程的出發點。」敏捷的流程，注重溝通與互動，文件與控管相對較少；如果希望掌握工作的細節，流程的設計必定複雜，那麼RUP或許是不錯的選擇。

此外，專案與產品導向的軟體，開發的流程是不同的。資訊單位面對主管今天提出需求，明天就希望看到成果的要求，從「服務」的角度思考，流程的設計與產品導向的流程絕對是不同的。

步驟3：從簡單開始
從資策會工程研究所的案例分析，導入RUP需要對架構與概念有一定程度的了解，因為專案負責人李至霓對RUP與Java均有相當程度的了解，再加上團隊成員人數少且實力平均，所以李至霓在每個階段，都親自示範一個功能的實作，工程師就可以跟著依樣畫葫蘆產出其他功能的實作。

但是對於剛開始改善流程的企業，周忠信建議：「簡單就是美。」簡單才能輕易融入成為公司的文化。如果需要重新學習很多的知識、面臨大範圍的習慣改變，可能引發很大的痛苦與反彈。

David Anderson表示：「流程應該像汽車的引擎，發動之後就自動運行。」好的流程是無感的，觸發以後便自然推動每個環節的進行。

步驟4：先訂流程，再選工具
鄭炳強建議：「從簡單流程的開始，初期甚至不需要電腦工具。」利用人工化的流程，觀察初期的使用情況，並做必要的調整，待專案團隊達成共識，流程發揮效益後，再考慮自動化，提升工作的效率。

根據景華科技顧問協助軟體公司導入CMMI的經驗，第一階段設計流程、表單與控管機制，經過不斷地討論、試行與調整，找出最適合也最有效益的流程。在流程逐漸固定，也看出改善的效益後，才會選擇工具來搭配流程，享受自動化的好處。

屈就工具制訂流程是本末倒置的作法，一開始就自動化，套用僵硬的流程，只會造成困擾。企業應該先定義流程，然後選擇適合的工具，讓工具配合流程的需求，才不會限制了流程的可能性。

步驟5：持續改善
改善是持續的過程，企業發現新的問題時，再針對問題改善流程，才能強化應變的能力。所以流程絕非不是一陳不變，就像CMMI不是通過評鑑就結束。

凌群電腦在CMMI評鑑的前兩天，仍然在修改流程，評鑑過後又立即擬定了新的改善計畫。當你對企業軟體開發流程的強弱環節瞭若指掌時，可以變化的花樣就多了。XP訴求以最佳智慧做出客戶最想要的東西

導入XP（eXtreme Programming，極限製程）的第一步就是拿起扳手與螺絲起子，動手拆隔板，因為XP強調的溝通、簡單、回饋與決心這4個價值觀，以及12項實務，主要精神說穿了就是貫徹「溝通」兩字。

XP是以少數人力在短時間開發系統的方式，適合2～12人的開發團隊，特別適合應用在需求經常改變的領域，因為需求的不確定性，所以相當重視客戶在開發過程所扮演的角色。管理者、客戶及開發人員對XP而言，都是專案的成員，必須透過充分的溝通與回饋，讓每個成員了解目前的版本能否滿足需求。

12項實務貫穿XP的核心精神－溝通
仔細研究XP，會發現以下12項實務多數只是為了達到充分溝通的手段：

1. 客戶駐廠：為方便隨時隨地的溝通，因此客戶必須駐廠，即時地回饋意見，並確認目前的版本能否符合需求。

2. 系統隱喻：XP並沒有系統分析師（SA）、系統設計師（SD）與程式開發人員等區別，每個人都扮演SA、SD和程式開發者的角色，直接跳過需求分析的階段，藉由客戶駐點面對面溝通的方式，取得第一手的需求，並直接做給客戶看，目的是為了做出符合客戶真正想要的東西。

而隱喻是為了讓客戶與開發者以共通的語言，確保彼此的溝通沒有誤解。以實際的比喻或故事，取代冗長而難以理解的文件，比喻可以與IT無關。例如說明授權機制可以舉實際生活的例子說明：一棟房子有很多層樓，每一層又很多房間，而某人的鑰匙只能開啟9樓A室的房間。總之盡量以易於了解的方式，表達需要的功能。

3. 通盤規畫：透過使用案例（User Story）發掘與評估需求，並在卡片（Story Card）寫上對需求的描述，讓開發者得以根據客戶的描述切割工作量，並確保在穩定的周期內，發布新的版本。

4. 小階段發行：依據Story Card切割工作，分階段發行新版本，而且必須是可執行的版本。

5. 簡單設計：今天的需求可能明天就改變，預留彈性反而是包袱，而且環境與技術都會改變，因此不去預想未來可能的功能，盡可能保持符合需求的最簡單版本。

6. 測試先行：XP的創始者Kent Beck提出的測試哲學，包括單元測試與整合測試。單元測試由開發者在撰寫系統程式前先寫測試程式，所以專案應有25~50%的時間是開發測試程式；而整合測試才是由測試人員負責。

7. 編程標準化：包括命名原則、編碼風格、函數、類別設計、繼承、運算符號等，設定一致的表現方式，提高程式的可讀性，將有助於改善軟體品質、提高開發效率並簡化維護工作。

8. 重構：在每個小階段發行、每個往覆式（Iteration）的周期後，甚至是每天下班前都可以執行一次重構，以保持程式碼的乾淨、簡單且具表達性。

9. 搭檔編程：兩個人共同開發一隻程式，一個人寫程式，另一個人看程式，檢視是否有錯誤或可改進的地方。兩人經常互換角色，這麼做的目的，是藉由充分的溝通與交流提升團隊整體的能力。

10. 共同維護：搭檔編程的搭檔關係，也需要經常替換（Switch Pair），讓每個人都可以維護系統的每個部分。

11. 持續整合：在開發期間，每一組搭檔可以隨時在測試過後，將程式簽入整合至系統，並諮詢其他搭檔執行所有測試，所以XP一天可能建構系統好幾次。

12. 每周40工時：為避免精疲力盡，XP希望以持久穩定的步調，維持高品質的工作效率，不借用明天的精力，強求在今天多完成一些工作，因此XP不允許團隊超時工作。唯一可以超時工作的例外，是發行前的最後一周，做最後的衝刺。

測試驅動的開發流程
XP之類的敏捷開發方法論，其輕巧特質，頗受開發者認同，然而大家著眼於其簡單設計與靈活因應需求改變的主張，卻往往忽略XP是測試驅動（Test Driven）的開發方法論，「測試」是必要的條件，若未撰寫測試程式，便不算是XP。

需求恆變是許多專案團隊抱怨的問題，然而XP的建議是擁抱改變，測試案例的目的，就是為了因應改變。以XP的經驗來看，透過錄製使用者介面的操作劇情，所執行的測試太過脆弱，系統底層很多功能與使用者介面無關，可能導致測試的漏洞，而建置健全的測試案例將使專案無懼改變。

未著手寫程式前，如何寫測試「程式」的程式？事實上，寫測試程式本身就是在進行系統的細部設計，寫測試程式前，必須決定Class（類別）的命名、參數為何、功能為何等。從測試的角度分析，叫用者（Caller）的觀點將多於開發者觀點，有助於設計更彈性、易用及簡潔的系統。

而先寫程式再寫測試的問題，在於開發完成後，團隊往往會缺乏動力，而且可能因為遺漏，使得有些程式沒有測試到，或者也可能將測試寫得太複雜。

強調不拘型式的文件
XP的「文件無用論」廣受IT界爭議：一個沒有文件的專案，後續的維護性令人質疑。其實XP有文件，而且是不拘型式的文件，以「Story Card」說故事打比方、畫UML圖、拍下白板上畫好架構的圖，甚至手繪的各種圖或文，都可以是文件的一種。

更重要的是，軟體會變，文件會過時，所以最好的文件是程式碼。為了讓程式擁有像文件一樣的可讀性，所以必須落實編程標準化，以同樣的風格撰寫程式，才能降低對文件的依賴性。

XP實作案例－XP讓鼎新EasyFlow GP放膽改變

鼎新電腦商務整合事業群內容管理部副理許權璽：「有了齊備的測試案例，不用擔心專案失控，就算失控，也知道火會燒到幾樓。」

在一次BPM的採訪中，鼎新電腦商務整合事業群內容管理部副理許權璽談到他們採用XP（eXtreme Programming，極限製程）開發方法論，筆者印象深刻的，是他有感而發的一席話：「因為建置了完備的測試程式，我永遠不用擔心修改程式是否會導致未知的風險。」他自信的神情讓我相信，XP真的對EasyFlow GP帶來關鍵的正面價值。

開啟程式設計師的文藝復興
許權璽強調：「軟體開發最痛苦的問題，就是訂定7月1日出貨，到了6月30日仍沒有把握再幾天可以出貨。」到了最後的整合階段，仍可能因為程式之間互相影響而發生問題。因此EasyFlow決定改版時，開發團隊希望改進開發方式，以終結軟體開發長久以來的宿命。

在前半年的摸索期，原先的ASP技術團隊，除了改學Java物件導向分析與設計方式，更廣泛地研究RUP、XP及MSF等開發方法論，希望可以找出強化軟體品質的方法。

許權璽看到《Software Development》雜誌一篇關於Symantec採用XP後士氣提高，對於準時交付更有信心的報導，因此決定深入了解XP。

在研究XP的過程中，許權璽剛開始從Amazon買書，不久之後發現天瓏書局也可買到原文書，現在已經買得到中文翻譯本了。原來XP此類輕量級的方法論，已逐漸變成顯學，甚至有人稱XP是「程式設計師的文藝復興」。

成員反彈，老闆質疑
研究XP的另一個原因，是看中XP嚴謹的測試方法，剛開始大家並不清楚XP所謂的「自動化測試」怎麼做，在了解必須撰寫測試程式時，引起很大的反彈。成員的反彈不是沒有原因，因為寫測試程式不難，最麻煩的是要建立各種情境需要測試的資料，所以耗費的時間是開發系統程式的3倍。

由於很長一段時間沒有可以展示的成果，鼎新執行副總裁黃錦祿發出質疑：「以前EasyFlow改版只要3個月，為什麼EasyFlow GP半年還看不到東西？」雖然鼎新高層支持軟體品質的提升，但當競爭產品在市場上持續地開疆闢土，而自家產品卻遲遲沒有動靜，其壓力之大可想而之。

許權璽表示：「拋開物件導向，純粹只是轉換技術平臺，3到6個月完成一套產品是非常有機會的。」但EasyFlow GP從開發方法論、流程領域的知識及分析設計的方法，都是從頭來過，所以花費將近1年的時間，才有雛型可以展示。為了答覆高層的問題，許權璽特別準備簡報，說明過去軟體開發面臨的問題及XP的主張，最後由技術總顧問周忠信參與輔導，每兩周審查一次進度。

XP的核心是溝通
許權璽實踐的心得認為XP的最主要的精神在溝通，因此到目前為止EasyFlow GP團隊仍持續每天一次「Stand Up」的會議，成員簡單說明今天的進度，並交換彼此的心得。

剛開始許權璽以為測試是XP的重點，實際了解XP的精神後，發現測試的目的是為了支持「改變」，XP適合需求不明確的專案，以致必須持續溝通、通盤規畫及小階段發行。基於完整的測試案例作為基礎建設，開發團隊就可以放膽修改程式。EasyFlow GP團隊利用JUnit，每天下班前自動執行一次所有的測試案例，並發送電子郵件提供測試報告。

理想與現實的差距
回顧XP的12項實務，許權璽認為自己仍有改進的空間，例如善用隱喻做得不夠徹底，搭檔編程及轉換搭檔難以落實，只有開發初期試行過搭檔編程，以致共同維護仍有困難，而40工時是大家最希望落實的一項實務，卻仍難避免加班的情況。從XP的角度來分析，這些都是專案不健康的指標。

XP強調先寫測試程式，是因為產品程式寫完後，開發人員心情難免鬆懈，寫測試程式的意願與動力將大幅降低，再者可能發生遺漏沒有測到的部分，或者測試程式寫得太複雜。不過，在沒有產品程式的情況下，只能撰寫概略的測試框架，細部的測試仍需等待產品程式產出才能實際撰寫，再加上面對時程的壓力，所以EasyFlow GP則調整為測試「後」行。

許權璽相信若徹底落實XP的4個價值觀和12項實務，對軟體開發絕對有很大的正面價值，未來若有機會開發新的專案，確實很想嚐試完整的XP方法論。不過XP的實務執行上確實有許多障礙，以搭檔編程為例，兩個人寫一隻程式，一個人寫，而另一個人坐在旁邊看，從企業管理者的角度，很自然地會質疑這樣的工作效率，直覺認為兩個人各自寫程式生產力將是兩倍。

與其猛K理論，不如參考實例
理想化的理論落實到現實環境，難免遭遇嚴苛的考驗，臺灣對於XP仍處於紙上談兵的階段，但國外已有廣泛的實作案例，許多XP的擁護者很樂於分享實作的經驗。

因此許權璽建議對XP有興趣的專案經理，應該多上網至XP的討論區參考別人的作法，雖然Kent Beck是XP的創始者，但後續有許多人一起運作，才形成完整的方法論及實務經驗，而且一直到現在都還持續地改進。

XP不適合時程壓力大的專案
從軟體開發的類型分析，許權璽認為軟體產品的開發時程壓力比較小，絕對有機會實現XP的方法論；然而專案的時程壓力大，因此很多理念容易被犧牲。

事實上這是軟體產業仍未成熟的象徵，在硬體產業，測試是理所當然的工作，甚至產品本身是一個標案，測試則是另一個標案，「測試」本身就足以形成一個具龐大經濟規模的產業。但目前的軟體產業尚未走到這樣的階段，客戶往往「又要馬兒好，又要馬兒不吃草」，資訊廠商在時程被壓縮的情況之下，搭檔編程和測試先行只能被犧牲，而準時交付的優先權，永遠排在品質控管的前面。

測試齊備，無懼改變
XP的經驗在鼎新是有留下影響性的，ERP II也參考EasyFlow的作法，撰寫測試案例。

許權璽引用國外的案例心得：「採用XP，最高興的不是準時交貨或者品質提升，而是任何成員的離開，對團隊都沒有影響。」從客戶的角度只能看到產品的功能與執行效能，就算對品質的穩固性有些微感受，但多數是沒有感覺的。

對專案團隊而言，雖然建置測試程式與測試資料耗費很多的時間，然而EasyFlow GP的品質大幅提升，更重要的是維護性很高，任何程度的改寫，都不用擔心系統發生失控的情況。許權璽笑說：「就算失控，也知道火會燒到幾樓。」

RUP有助於專案的控管

有別於瀑布式開發從分析、設計、開發、測試到上線，單一縱向的開發流程，RUP（Rational Unified Process）開發方法論還有第二個面向，橫軸以生命周期的角度，將軟體開發分為初始（Inception）、細化（Elaboration）、建構（Configuration）及交付（Transition）等4個發展階段，因此RUP是二維的開發流程。
剖析縱、橫切面，主要呈現RUP的4個重要的精神：使用案例驅動（Use Case Driven）、以架構為核心（Architecture Centric）、往覆與漸進（Iteration & Incremental）及以模組為基礎（Model Based）。

9個工作流程
縱向的RUP開發流程，羅列軟體專案中應具備的心法（Disciplines），共分為9個工作流程（Workflow），前6項是核心流程，後3項是屬於支持性管理流程：

● 商業建模（Business Modeling）：商業建模通常應用在初次接觸的領域專案，利用商業建模中的各種活動與步驟，熟悉領域知識（Domain Knowledge）。對於熟悉的領域，這是可以省略的工作。

● 需求分析（Requirements）：建立需求模組，繪製使用案例圖（Use Case Diagram），是未來分析、設計、實作與測試的基礎，其重要性不容忽視。

● 分析與設計（Analysis & Design）：根據需求分析所繪製的使用案例圖，導出分析模組與設計模組。分析模組用以描述系統的功能與作用，而設計模組中的類別圖（Class Diagram）已經可以據以產生程式框架。

● 實作（Implementation）：根據前一階段產出的類別圖，填入與商業邏輯程式，成為可執行的功能。

● 測試（Test）：測試工作同樣必須基於使用案例，導出測試案例。RUP採用的自動化測試，錄製測試案例，測試案例可分為基本的正常流程及例外狀況，一旦發現系統有其他的錯誤時，再針對錯誤錄製測試案例。

● 部署（Deployment）：包括軟體的封裝、安裝與驗收。

● 建構與變更管理（Configuration & Change Management）：主要是版本控管與變更管理。

● 專案管理（Project Management）：包括專案的計畫、監控、風險評估及人員的管理。

● 環境配置（Environment）：系統的軟、硬體配置，及手冊與教育訓練的規畫。

以上工作流程，在軟體生命周期的不同階段，占有不同程度的比重，例如初始階段以需求分析為主、細化階段則分析與設計的工作居多，建構階段實作的比重吃重，而交付階段偏重建構與變更管理。

軟體生命周期的四階段
從軟體生命周期的角度，共分為初始、細化、建構及交付等4個階段，每個階段又可畫分多個往覆式（Iteration）開發流程，以漸進的方式，在系統基礎架構上逐步構築出完整的功能。

● 初始階段：藉由訪談探索需求，形成需求模組，畫出使用案例，而後續各階段的設計、開發與測試，都將根基於需求模組的使用案例，認知有誤將導致未來付出很大的修正成本，所以這個階段具有重要的意義。

● 細化階段：RUP強調以架構為核心，根據初始階段的使用案例，找出足以驗證系統架構的核心需求，再視規模切割成適當的往覆周期完成。在每個往覆中完成的核心功能，均包括分析、設計、實作與測試等完整的開發步驟，提交給使用者可以執行的系統，以確認設計無誤。

● 建構階段：漸進是RUP的核心精神，在細化階段確認系統的架構與核心功能後，建構階段即根據基本的架構，大量複製前一階段的設計，逐步累進增加系統功能。

● 交付階段：在前面幾個周期中，經由數次的往覆式流程，已經提交使用者數個可執行的版本，這個階段主要是根據使用者的回饋，進行少量的調整、設定與安裝，因為主要的問題，應該在早期階段已經解決。

除了定義軟體開發應具備的工作流程，RUP更以生命周期的角度，切割成工作4個階段。在每個階段有不同的工作重點，並可切割成多個往覆式流程，以遞增的方式，逐步構建出完整的軟體系統。

4個核心精神
從縱向的開發流程分析，RUP是一連串建構模組的過程，從需求模組導出設計模組、開發模組及測試模組。而所有的設計，均根源於初始階段需求模組的使用案例。由此看出，開發流程的核心精神是「以模組為基礎」及「使用案例驅動」。

而橫向以軟體生命周期的角度來看，RUP為避免瀑布式開發，單向一次性的流程的缺點，在於若驗收時才發現產品不符合期待，將付出慘痛的代價。因此最重要的就是在細化階段，開發核心功能，以驗證系統架構設計的正確性，到了建構階段，便以系統架構作為大量複製的基礎。

而且生命周期的每個階段，都可以切分成多個往覆式流程，每次都設計一點、實作一點、測試一點與交付一點，達到「早期發現，早期修正」的目的，以降低專案的風險，這便是「以架構為核心」、「往覆與漸進」的精神。

精準分工利於管理
RUP的架構非常龐大，縱向的9個工作流程，各自皆有明確應執行的工作項目，每個工作項目又細分各種活動（Activity）與相對的產出（Artifact），再細看每個活動，也都包含詳細的執行步驟。
當每個人只需專注於自身扮演角色所應處理的工作，在轉交給下一個人的時候，也明確定義應輸出/輸入的文件與程式，軟體產業的發展便有可能類似硬體產業，形成軟體工廠加速生產。

雖然「軟體工廠」的想法，現階段看來仍很遙遠，不過精細的分工及明確定義的步驟與產出，確實有助於管理者清楚掌握專案的進度與執行的情況。即使專案延遲或失敗，也會清楚明白是哪一個環節發生問題。

RUP實作案例－以RUP開發出口信用狀轉開／轉讓系統

資策會工程研究所經理李至霓：「若完全遵照RUP的程序，清楚切割成員的角色與工作，相信可以大幅降低人員異動的衝擊。」

資策會資訊工程研究所（以下簡稱資工所）於2005年正式全面導入IBM Rational工具，希望藉由嚴謹的RUP（Rational Unified Process）開發方法論，增加專案的掌握程度，以降低軟體開發的風險。

資工所經理李至霓帶領4人開發團隊，為某金控開發以Java技術為基礎的出口信用狀轉開／轉讓系統，是所內率先完整落實RUP方法論的專案，資工所希望以此試行，作為下一階段全所導入RUP的參考。

先執行裁切與分工
RUP需要經由適度的裁切，才能符合個別專案的特質，而在出口信用狀轉開／轉讓系統專案中，縱向開發流程的分配，裁切了商業建模的步驟，主要執行需求分析、分析與設計、實作、測試等工作流程，後續部署、管理與環境建置等支援性的流程，則由客戶處理。

橫向則依據RUP的軟體生命周期4階段切割，資策會負責初始（Inception）與細化（Elaboration）階段，建構與交付階段的工作將移交客戶接手。

由需求驅動一連串建模的過程
初始階段約一個多月的時間，由1個人負責與客戶訪談並蒐集需求，開發小組根據使用者的需求，建構需求模組並畫出使用案例圖（Use Case Diagram）。

李至霓表示：「RUP是一連串建構模組的過程。」軟體開發的分析、設計、實作與測試階段的模組，均根基於初始階段的需求模組與使用案例。此即RUP所謂的「以模組為基礎（Model Based）」與「使用案例驅動（Use Case Driven）」。

在細化階段，資工所根據使用案例，導出類別圖（Class Diagram）與各種使用情境的循序圖（Sequence Diagram）。類別圖可分為分析類別（Analysis Class）與一個設計類別（Design Class），而一個使用案例圖，將對應出一個分析類別與一個設計類別。

分析類別與設計類別的差異，在於分析模組從分析的角度，更清楚地描述使用者的需求；而設計模組的類別圖，則改以軟體設計的觀點，將系統的功能描述轉化為實際的類別（Class）與方法（Method），透過自動化工具，可直接根據設計類別產生程式碼框架。

以核心功能驗證系統架構
在細化階段架構系統的核心功能時，以2個往覆（Iteration）式流程分批完成。李至霓強調：「『核心』功能未必是『重要』的功能」。核心功能應用的層面，必須能夠最廣泛地驗證系統的軟、硬體架構，以確認系統架構設計無誤。

「以架構為核心（Architecture Centric）」是RUP的核心精神之一，在細化階段利用核心功能驗證架構設計的正確性，才能避免到了建構或交付階段再調整架構，將付出龐大的修改成本。每個往覆都完整落實分析、設計、實作與測試等工作流程，產出的版本都是可執行的完成品，以便讓客戶提前看到系統的部分面貌，並確認功能正確性。

錄製情境讓測試自動化
系統的測試工作，必須先擬定測試計畫，同樣是基於使用案例導出測試案例，測試案例可分為正常操作情況的基本流程（Basic Flow），與輸入或操作錯誤導致的例外狀況流程（Alternative）。資工所根據系統各項作業的新增、刪除、修改等基本流程，交叉搭配各種例外狀況，總共導出25種使用情境（Scenario），未來若發現其他程式臭蟲，可再針對特定錯誤，新增測試案例。

擬定測試的各種「劇本」後，搭配Rational的TestManager，錄製各種操作情境。RUP的自動化測試，是指利用自動化工具例如TestManager，可指定測試案例，驗證單一情境的正確性；或選定特定功能，執行所有相關的測試情境；也可點選測試計畫，針對系統執行整合測試。

在系統演化的過程中，開發下一個版本前，應先完整測試所有的功能，後續增加新功能時，也應新增相應的測試案例，才能有效確保系統正確性。

測試的過程TestManager將提供完整記錄，並產生兼具圖表與文字的報表，包括成功、失敗及警告等各種類型的詳細內容。自動化測試可驗證系統的功能與效能，若要針對系統程式層級的個別物件測試正確性，情境測試則無法滿足需求，必須搭配JUnit撰寫測試程式，才能執行此類的單元測試。

有效降低人員異動的衝擊
雖然李至霓沒有遭遇成員離職的情況，不過，程式開發的工作，曾移交給南區的工程師協助，後來又由原來的團隊成員接手，在這轉折的過程中，並沒有發生很大的問題。

過去專案所有的知識都在工程師的腦袋裏，所以人員異動對專案的衝擊很大。但是在RUP的架構下，每一項工作皆有固定的產入與產出，所以交接工作，有明確應該交付的文件、UML圖或程式。只要接手的人具有相同的技術背景，可以看得懂RUP的文件與UML圖，就有能力接續工作。李至霓強調：「人員的離職對專案一定會造成影響，但若完全遵照RUP的程序，相信可以大幅降低衝擊。」

落實RUP，工具不可少
RUP絕對不能單靠紙上談兵，李至霓認為：「採用RUP需要觀念與環境的配合。」完整了解RUP的架構及理念以外，也需要搭配自動化的工具才能具體落實。資工所2005年導入全套IBM Rational工具，並先由少數專案開始試行，目前也正有幾個專案在試行與調整，下一階段將推廣至全所，完整落實RUP的作法。

少數專案採用RUP，其實效果並不明顯，若能整個單位落實RUP方法論，便有可能發揮綜效，藉由清楚的專業分工，實現軟體工廠的想法。

客戶技術的落差才是真正的考驗
由於資工所在細化階段，已建立系統的基本架構與核心功能，移交給客戶後，資訊人員只需根據基本的架構，複製類似的設計，即可不斷累加各式功能。

金控體系面對老舊的COBOL核心系統，必須有逐步汰換的計畫，然而以目前資訊人員對Java的熟悉程度，及系統轉換的風險衡量，需要長遠的規畫。出口信用狀轉開／轉讓系統便是金控與資工所合作，以Java物件導向技術，改寫核心系統的先期導入計畫，在專案啟動之前，資工所已針對資訊部人員提供物件導向與Java相關技術的教育訓練。

然而由於Java的高門檻，李至霓認為等到系統移交回客戶時，問題將會真正浮現，實際面對觀念的驗證，即使資訊人員己經上過課，仍需要一段摸索期。所以雖然目前專案看似順利，但面對雙方技術落差，系統交付後才是考驗的開始。

CMMI提供檢驗與改善流程品質的參考

CMMI（The Capability Maturity Model Integration，能力成熟度整合模型）是由負責國防採購、技術及後勤事務的美國國防部助理部長辦公室所贊助，主要是為了改善採購過程中，頻繁採用不合格軟體的情況，發展出來的一種評估軟體開發流程成熟度的方法。

「能力度」與「成熟度」兩種表述方式
CMMI有連續式與階段式兩種表述，兩者的差別在於：連續式表述採用「能力度等級」衡量流程改善；階段式表述則著重組織整體的「成熟度等級」。企業可依需求選擇適合的表述方法：

連續式表述：
連續式表述允許企業選擇改善的順序，以流程領域（例如專案監控、風險管理、需求管理等）為基準，可選擇單一或多個流程領域，分別評鑑能力。能力度共分為6個等級（0~5），可利用能力剖析圖，比對各流程領域的能力度差異，作為選擇未來改善標的的參考，例如針對需求管理流程領域強化，以符合企業的目標。

事實上，連續式表述較能貼近企業的需求，根據組織的現況，選擇需要或期望加強的部分。不過由於CMMI的評鑑是逐次付費，而且甲方（軟體採購者）多以「成熟度」作為衡量的標準，因此基於商業考量，連續式表述較不受廠商青睞。

階段式表述：
成熟度等級是目前較普遍採用的評鑑方法，共有5個成熟度等級（1~5），每個成熟度等級包含一組事先定義的流程領域，提供階段式的流程改善建議順序。例如第2級包括需求管理、專案規畫、專案監控、供應商協議管理、度量與分析、流程和產品品質保證與建構管理等流程領域。要通過第2級評鑑，必須上述流程領域的能力，均達到一定的水準，才算具備第2級的成熟度。

所以，成熟度等級是一組經過定義的漸進式流程改善指標，達到每一個成熟度等級，表示組織流程的某個重要部分，已經建立穩固的基礎。成熟度等級的差別如下：

● 成熟度第1級（Initial，初始級）：不需評鑑。許多未經改善的開發團隊，均存在第1級的初始狀態。流程通常是不固定的，組織的成功完全仰賴成員的能力與英雄主義，而不是一套經過驗證的流程。主要特徵包括：過度承諾、在緊急關頭放棄流程，以及無法複製成功經驗。

● 成熟度第2級（Managed，管理級）：個別的專案已具有固定的流程，需求、流程、產品與服務是可被管理的，在管理者定義的時間點，可以了解工作的狀況與服務交付的情況。

● 成熟度第3級（Defined，定義級）：在成熟度第2級時，某個流程在不同的案例之間可能有差異，到了第3級，整個組織所有執行的流程都是一致的。

● 成熟度第4級（Quantitatively Managed，量化管理級）：建立品質和流程績效的量化目標，作為管理流程時的準則，使用統計與量化技術，控制對整體流程績效有重大影響的子流程。相較於第3級，僅能預測流程品質，第4級以統計和量化技術控制流程，可預測流程績效，並專注於克服特殊原因造成的流程變異。

● 成熟度第5級（Optimizing，最佳化級）：經由漸進的改善，成熟度第5級專注於克服共同原因導致的流程變異，力求改善流程或降低成本達成企業預期的目標。

設定目標卻不提供方法
CMMI規範了良好的流程應有的特徵，提供企業量測軟體開發流程成熟度的參考，並可作為改善的依據。

近幾年來，CMMI儼然成為臺灣軟體界的全民運動，廠商若是以評鑑為目的，而忽略改善的初衷，認證將流於形式，評鑑過後，真正的軟體開發流程依然故我的話，便失去評鑑的意義。

導入CMMI案例－通過CMMI Level 5評鑑，凌群累積持續改善的力量

凌群電腦研發二處處長陳志忠表示：「改善不會因為評鑑而結束，要求只會越來越嚴苛。」

導入CMMI並不是凌群電腦一開始設定的目標，故事應該從10年前一次被退貨的經驗說起，後續才衍生出一連串導入ISO、IEEE及CMMI的發展，這其實是一段摸索品質改善方法的漫長歷程。

從10年前開始思索改善的方法
1996年凌群自行研發的COBOL程式產生器「APG」成功行銷日本，然而不出一個月的時間，日商便要求退貨。凌群電腦研發二處處長陳志忠前往日本了解原因，客戶拿出厚厚一疊文件，內容包括詳細的測試計畫、程序及案例，並附上臭蟲（Bug）清單，經過他們初步測試，發現20多個臭蟲。凌群吸收日本的方法實際測試後，最後總共修正了約莫500個臭蟲。

在10年以前，凌群對「軟體工程」的全貌是模糊的，過去完全以自己的方式開發與測試，日本的當頭棒喝，促使凌群思索正規化的方法。

ISO 9001建立品質管理機制
1998年凌群成立「品質保證部」專注於測試工作，1999年，凌群決定採用國際標準ISO 9001，通盤思考軟體開發流程改善的方法，品質保證部轉為品質保證與產品測試，企圖在軟體生命周期的每個階段，制定嚴謹的作業程序、表單與規範。

然而以全公司800人的規模推動ISO 9001，僅是制定統一的命名原則，就耗費超過半年的時間，最後決定鎖定研發部門先行，力求每人每日的工作都有書面化的指引。

書面化的制度難以徹底落實，於是在2000年建置一套自動化的品質管理系統。但是，習慣的改變總會引起反彈，自動化的系統改變了既有工作模式，原本填寫紙本表單，改成電腦輸入；以前印出畫面大筆一揮，圈出有問題的部分即可，現在必須用電腦抓圖，並想辦法「畫圈」。

就這樣約莫試行了半年，一場無預警的停電，導致久未關機的系統在瞬間斷電的影響下，必須送修3天，測試人員反而覺得：「沒有系統怎麼工作？」陳志忠發現只要能突破舊有的習慣，養成新的文化，任何事都是有可能的。

CMMI符合漸進式改善的目標
在摸索的過程中，凌群也曾經參考RUP開發方法論，然而凌群不是完全沒有制度的公司，若拋棄過去的基礎，建置全新的流程，反而是風險比較高的作法。制度應該是持續調整與改善的過程，因此對凌群而言，CMMI與ISO此類提供改善的指引與目標，卻沒有限定的細則，漸進式地誘導過程，反而較能契合凌群的目標。

由於ISO並非針對IT產業的標準，準則過於泛用，因此開始思索IEEE與CMMI等IT產業的標準。2004年決定導入CMMI Level 3，希望建立組織一致的流程，凌群電腦研發二處經理鄧大宇是凌群第一個接受CMMI訓練的員工，也是流程改善小組（SEPG，Software Engineering Process Group）的當然成員。

寫文件的目的，是為了避免未來的麻煩
導入CMMI面臨的第一個困難是寫文件，導入ISO 9001與CMMI，讓文件化的工作越來越吃重，對工程師而言，寫文件是痛苦的。不過，陳志忠認為：「一切要從效益看回來。」剛開始是「一個口令，一個動作」，並需要搭配稽核的手段，對於認真執行者給予獎勵。

經過一段時間的推行，工程師從實際的專案中，發現設計的考量更周延、責任歸屬更明確等好處，體會到寫文件「不是增加麻煩，而是避免未來可能引發的更多麻煩」，便自動自發地寫文件。

制度要系統化才能落實

凌群電腦研發二處經理鄧大宇笑稱自己在凌群已經當了10年的「管家婆」。

對鄧大宇而言，最耗費時間與精力的是教育訓練，針對專案管理、建構管理、需求管理、軟體測試、品質稽核、技術審查與度量與統計分析等不同角色分別訓練。然而幾天的課程絕對是不夠的。鄧大宇揶揄自己在凌群已經當了10年的「管家婆」，必須扮演時時提醒、諄諄教誨與循循善誘的角色。

不過，陳志忠強調：「制度絕對不是寫在紙上，一定要系統化才能落實。」凌群隨著ISO與CMMI推導制度的過程，有了另一個想法：要有系統與制度配合，而且系統要能隨制度的改變彈性調整。

於是凌群因應CMMI開發了一套SDPM（Software Development Process Master）系統，整合管理與程式開發介面，工程師可在單一系統中，取得工作清單，並在點選後直接開啟開發介面與相對的程式，不但提升效率工作，也不會有第二套體制外的工作流程。

凌群為落實CMMI而開發的SDPM，現在已成為推廣CMMI的產品。

評鑑小組是公司寶貴的資產
鄧大宇參與凌群CMMI Level 3、Level 5評鑑，並協助大陸子公司凌安電腦通過Level 3，所以前後總共經歷3次評鑑，過程雖然辛苦卻很有收獲。鄧大宇回顧印象最深刻的，是第一次評鑑CMMI Level 3：「通過評鑑並沒有興奮感，反而是評鑑的過程收獲很多。」原本獨立看待的各個流程領域，在2個月的時間，串連起所有的精髓，與原先認知的CMMI差異很大。

這是鄧大宇從推導ISO一路走來，從來沒有過的興奮，被指派加入CMMI評鑑小組，大家都覺得是苦差事，確實很辛苦，竟然也是收獲最多、感受最深刻的一次。

陳志忠透露：「CMMI Level 3的評鑑小組成員是指定的，但準備推導CMMI Level 5時，竟然有人報名參加。」這是凌群始料未及的效應，當大家發現參與CMMI Level 3的評鑑小組獲益良多，有進取心的員工紛紛躍躍欲試。

事實上，評鑑小組成員是公司寶貴的資產，因為參與導入CMMI與評鑑的過程中，他們學習到正規的稽核方法，也一同參與文件審核與口頭審查的過程，評鑑期間，已經完整掌握公司的強弱環節，將是企業未來品質改善的最佳操刀者。

改善不會因評鑑而結束
通過CMMI Level 3及Level 5評鑑，對於凌群內部員工與客戶而言，其實沒有立即明顯的感受，因為改善是已經持續10年的過程。而客戶不會因為通過評鑑，才忽然發現凌群開發軟體的方法不同，或品質有立即明顯的提升。

事實上，目前凌群的制度融合了ISO、CMMI與IEEE，比CMMI更嚴謹，CMMI中並沒有定義系統分析文件的格式，而IEEE中有清楚的規範。鄧大宇也不諱言：「評鑑的前兩天，還在改流程。」而且評鑑通過的隔周，鄧大宇又接手下一個流程改善的計畫，陳志忠表示：「改善不會因為評鑑而結束，要求只會越來越嚴苛」。

CMMI Level 5的效益，凌群現在沒有特別的感受，因為Level 5是根據量化數據尋求最佳化的方法，需要長時間的累積才會看到成果，累積的時間越長，可以調適的依據與方向就越明確，所以通過評鑑只是最佳化的開始。

挑戰《人月神話》－印度的軟體代工

東富資訊總經理許世杰負責執行東森購物ET1的專案，從TCS帶回豐富的委外印度經驗，已經衍然成為臺灣軟體專案委外印度的最佳代言人，從他口中我們得知委外的條件與限制，並了解國內軟體產業整體解決方案（Total Solution）模式，必須有專業的領域知識（Domain Knowledge）為背書才有可能成功。

印度雄厚的人力，足以大幅提升人月產值
如果企業的需求或產業類型特殊，無法採用套裝產品快速組裝，也不似ERP之類的應用，可透過產品經由某種程度的客製化，即足以應付需求。面對此類需要全程訂製開發、規模與範圍又相當龐大，且受限於短期製程的軟體專案，唯有提高人力才能縮短工時。

臺灣資訊服務廠商的規模，在一個專案中投入數十人的資源，風險過高，因此這類的專案便可考慮離岸委外，尋求國外大型軟體服務業者的協助，借重印度、東歐或中國大陸軟體工程的能力，在短時間內打造全新的資訊平臺。

若強調領域知識，便高度依賴經驗
印度就是因應此類需求，趁勢而起，建立了成長迅速的軟體代工產業。在東森購物的案例中，我們發現TCS可以隨時調派工程師加速專案的進度。然而這與《人月神話》強調的「在延遲的專案中加派人力，只會使專案更加延遲」的經驗相違背。

許世杰分析，《人月神話》的理論之所以成立，是因為美國與臺灣在軟體開發領域，管理與分工的方式與印度有很大的不同。以臺灣來看，軟體開發強調領域知識，高度依賴「經驗」，經驗越豐富、在專案中工作越久的人，產出的效能越好，而新人無法立刻派上用場。

若以建築業的工作對比，臺灣的模式是一組人負責蓋客廳、一組人負責蓋房間、另一組人負責蓋廚房與浴室。所以每個人都要「十八般武藝樣樣精通」，師父帶領徒弟完成所有的工作。若加派人手，必須有先期的教育訓練，協助了解前因後果、系統的設計理念與目前的進度，才能逐漸銜接工作。

印度以建築業的模式，成功經營軟體代工
印度思考的分工模式，是盡量與領域知識無關，以強化調度人員的能力。工程師只要有固定工作模式與訓練，檢視局部的文件後，不需要了解前因、後果，就可以立即加入工作。四人幫提出的「Design Pattern」，其實就是採用建築業的用語，就是希望模仿建築業的方式加速軟體開發。

印度的軟體分工類似營造場，以綁鋼筋、灌漿、水電或鋪磚等專長分工，工程延宕時，加派目前進度需要的技術人手，即可立即加速產能，10個人與20個人綁鋼筋的進度當然是不同的。新人只要依設計圖或工頭的指示，即可馬上參與工作。

在營造業中，決定機能的是建築師，許世杰並提出一個值得省思現象：「在建築業，工人不會詢問建築師為什麼要這樣做；但軟體產業的工程師質疑系統設計，卻是常見且合理的現象。」在印度，軟體的功能由具領域知識的顧問或設計師決定，但對建造的工程師而言，不管系統是針對何種產業或應用，使用的技術是一樣的。例如專責設計報表的工程師，工作的內容就是根據內容與格式產出報表，工程師甚至已累積了各種類型的範本，可以視情況套用以加速生產。

因為精細分工，重複性高，再搭配標準的編程規範，所以印度軟體產業允許的創意程度比較低。工程師不會埋怨這樣的工作單調或沒有成就感，許世杰認為：「文化的關聯大於收入的影響，同樣的模式移植到同樣人力便宜的大陸，卻未必行得通。」因為民族性使然，臺灣、中國大陸與美國，較重視個人的價值。而印度剛好適合這樣的委外模式，且擁有很好的英語與數理邏輯能力，所以能在軟體代工市場做出成績。

產業熟悉度不高的專案，適合整體解決方案
相較之下，臺灣的軟體公司喜歡強調提供整體解決方案，客戶也被教育將委外視為一種「買賣」。既然是「買」一套系統，就要「能用」。「能用」是非常主觀的定義，委外的需求在設計與開發的當時是合乎使用的；但在準備上線的同時，當年的需求就未必符合現在「能用」的定義。

只要廠商不具明顯優勢，臺灣的軟體產業即成為買方市場，由於雙方對文件都不夠重視，以致於驗收時沒有具體依循的憑據，當使用者認為功能不足，廠商沒有反駁的立場，也只好改到滿意為止。許世杰點出：「這就是臺灣的軟體委外不會賺錢的原因。」

許世杰分析臺灣軟體委外成功的案例：「大多存在於廠商的領域知識比企業豐富的情況。」例如金融單位初次導入消費性金融系統、電信業導入電信軟體，甚至東森購物初次導入韓國的電視購物系統時，國外的顧問均宣稱在相關產業擁有多年經驗。

當買方尚處於學習的階段，買賣的過程是經驗的移轉，也就不得不照單全收。這類賣方比買方更清楚產業運作模式的情況，以整體解決方案模式提供的專案，系統成功上線的機率很高。

離岸委外適合領導型企業
當廠商面對具領導地位的產業龍頭，掌握該領域核心競爭力、知道怎麼運作才是最好，那麼買方就具有明顯優勢，軟體公司是沒有能力提供整體解決方案的。

以此分析來看，領導型廠商的大型專案系統便很適合離岸委外的模式，因為企業本身擁有最佳的領域知識，缺乏的只是開發的人力，如果能借重國外便宜的人力與管理的能力，有助於在有限的時間內開發量身訂作的大型系統。

許世杰強調：「委外與自己找印度或大陸便宜的工程師來工作，兩者有很大的差別。」因為我們未必有成熟的「分工」與「管理」的能力，可使上百個工程師立刻派上用場，因此，東森購物借重的，是印度大型軟體服務公司管理的長才。

東森購物ET1委外印度

東富資訊總經理許世杰表示：「語言是原先預期的障礙，後來發現工作文化的不同才是關鍵的影響因素。」

東森新一代的購物虛擬通路資訊管理平臺ET1，委外印度最大的軟體服務公司TCS（Tata Consultancy Services）開發，總共動員TCS超過100名專屬工程師，在兩年內開發300多萬行程式。今年7月17日ET1正式上線，高達1000人月的開發時程，其間包含著印度與臺灣之間不同文化的磨合，當初大家預期的語言隔閡，並沒有造成很大的障礙，反倒是印度的工作文化，給臺灣人上了一堂震撼教育。

耗資兩億的ET1，獲得經濟部技術處指導，成為示範性計畫，獲得上仟萬的補助，希望建立國內e化的典範，作為大型企業離岸（Offshoring）委外的參考指標。整合多媒體通路管理、客戶關係管理、訂單與帳務管理及供應鏈與物流管理四大模組的ET1，在TCS退出東森購物後，維運工作將由東森集團的東富資訊接手，這也許是另一個挑戰的開始。

時程緊湊，臺商無法承接
「為什麼找印度軟體廠商？」是東富資訊總經理許世杰最常被問到的問題，事實上ET1的承包分為兩個階段，第一階段遴選廠商，第二階段才真正的進行細部的分析、設計與開發。

在第一階段由6家提案廠商中選出2家，參與為期半年的需求分析，當時有臺灣的廠商與TCS競爭，東森購物初步估計至少需要750人月才能完成，並希望在12~14個月完成，那麼平均起來廠商必須投入約60個人力於ET1。由於人力需求過高，對於臺灣的廠商而言風險過高。

本地駐點，印度開發
印度的軟體代工是以本地駐點（On-Site）與印度開發的模式進行。臺灣有一組TCS的工程師負責搜集需求，傳回總公司由印度開發；完成的產品交付臺灣的TCS工程師安裝、測試並請東森購物驗收。

東森購物也有一組約7位工程師派駐在印度的TCS，待了約半年的時間，同步接收臺灣傳達的需求並與TCS一同審查文件，系統完工後進行初步的測試。這樣設計的目的是想藉由雙向確認，避免認知上的差異。

這是印度普遍的委外模式，東富資訊軟體開發二部經理陳繼誠駐點印度期間，也看到許多國家的工程師，同樣是駐點在印度確認產品與需求的相符性。

採用RUP方法論，分3個開發往覆完成
TCS採用RUP方法論，共分為3個往覆式開發流程（Iteration）分批完成，先開發核心的功能讓東森購物確認，再陸續補足其餘的部分，達到「及早發現，及早治療」的目的，以降低專案的風險。

往覆式開發流程並不是印度的專利，他們的專業在於利用生產線的概念分工，隨時可增派人手加速生產。憑藉充沛的人力，3個往覆由三組人馬分頭進行，而且時間相互重疊，在第一個往覆（Iteration）的成品產出前，第二個往覆已經啟動，第二個往覆進行的同時，第三個往覆的計畫也開始執行。

而且第一個往覆產出的功能即使後續有所調整，仍能與第二往覆產品的功能順利銜接。TCS藉由人力調配，以及系統切割得當得以加速開時程的優勢下，可以在客戶要求的期限內完成產品。

不同的工作文化，衝擊比語言還大
與TCS合作可以預期的是語言上的障礙，TCS甚至派一位工程師在臺灣的師範大學學習中文，以降低溝通的困難。經過長時間的合作之後，許世杰發現：「真正問題不是語言，而是工作文化。」臺灣與印度對於撰寫文件的認知，及遵循標準的嚴謹程度，有很大的差異，這也是影響ET1專案後來增加至1000人月的關鍵因素。

需求分析是經由多次的會議才能確認，根據多次會議記錄的結果，將整理成正式的需求分析文件，文件經由雙方簽字認可，TCS才會開始動工，根據文件設計、開發與測試，然後交給東森購物驗收，這些過程中有大量的文件產出。

但是由於對文件的嚴肅性不夠，以致於到了驗收的階段，發現功能有些許遺漏，再要求TCS補齊功能時，雙方回頭調閱過去的記錄，發現會議記錄有提到，但正式的需求分析文件並沒有記錄。對TCS而言，文件沒有提到的功能，即表示沒有這項需求。而後續新增這項功能，就是啟動一個需求變更的流程，必須增加費用。

文件沒有，系統就沒有
在東森購物之前，臺灣早有其他委外印度的案例，許世杰分析後來臺灣與印度的合作熱潮退燒的重要原因就在於：「完成的系統少了許多功能，以至於無法上線使用。」臺灣的業主與臺灣軟體服務業合作時，功能不符合需求就修改到符合要求為止，但這一套與印度合作時是行不通的。

印度的合作模式是文件上沒有的需求，除非追加預算，否則只能買到功能不足、無法使用的系統。所幸東森購物的高層對於ET1相當支持，也理解臺灣軟體產業的問題，因此同意追加時間與費用，完成真正符合東森購物的ET1。

ET1志在行銷國際
東森購物最初引進韓國的電視購物系統，與TC1所使用的技術不同，由於系統上線後必須由東富資訊接手維護，因此，在ET1專案開始時，資訊人員便參與整個設計與開發的過程。從第二階段選定TCS開始，便與TCS的工程師及東森的使用者一同談需求、檢視文件，並了解TCS的開發過程，最後TCS提供Code Review的課程，詳細說明程式邏輯，讓東森的資訊團隊取得白箱（White Box）的產品與技術，可以完全了解ET1的設計結構與邏輯。

東森購物的資訊人員並建置了練習版的ET1環境，依據自己設定的新需求嚐試開發新功能，然後測試能否正確地執行，這些模擬練習是為了確保在TCS的人員徹離東森購物後，可以自行處理ET1的維運工作。

7月上線到現在，ET1已可穩定運作，從訂單的角度分析，9成以上的單量都是正確的，剩餘的問題多是舊資料本身格式不正確所導致，陳繼誠坦言：「接手到現在，仍處於學習的階段。」面對使用者提出各式各樣的疑難雜症，例如操作的不熟悉、無法處理的狀況、舊資料轉換的問題等，仍需學習TCS管理的流程。

ET1除了可以提供客戶更好的服務，東森購物懷抱更大的野心，早在兩年半前即預計終究要與別的國家合作，不論是西進大陸或南進東南亞，東森購物未來將把完整的電視購物經驗，包含背後支撐銷售、服務、物流與金流最重要的IT系統，包裝成完成的方案，以「整廠輸出」的概念行銷海外。