編輯部2010-10-071min0

[IT NOW] 軟體開發與維護的天秤

無論軟體規模的大小,軟體專案從無到有的開發,到實作測試,以致軟體上線後的運行維護,可以視為一個軟體發展的生命週期。而我們常常以為,一個軟體的生命週期,開發的部分佔了絕大多數,也因此,一直以來有許多的研究在探討,使用什麼樣的軟體開發方法,可以有效率的開發軟體,來避免開發流程冗長以及失敗。
無論軟體規模的大小,軟體專案從無到有的開發,到實作測試,以致軟體上線後的運行維護,可以視為一個軟體發展的生命週期。而我們常常以為,一個軟體的生命週期,開發的部分佔了絕大多數,也因此,一直以來有許多的研究在探討,使用什麼樣的軟體開發方法,可以有效率的開發軟體,來避免開發流程冗長以及失敗。
在軟體專案的進程中,實作的經驗告訴我們,往往忽略了當軟體真正上線運行後,後續的維護工作,其實這時候真正的挑戰才剛要開始。因此,我們從探討軟體開發的生命週期,進而用實例來討論軟體的開發與後續的維護工作,來比較彼此花費的工時。

從無到有並不是最艱難的部分

當一個新的構想(Concept)出現時,必須從蒐集資料、確立目標範疇開始,當評估其可行性後,隨即一個軟體專案的成立,便可著手開始準備規劃(Planning)的工作。在有限的時間、資源與人力的限制下,我們不可能無限期的放任軟體開發。因此,我們必須先做系統分析,在專案的範疇下,瞭解使用者的需求與其作業流程,進而評估專案時程與所需的人力資源。
開發的過程中,需求訪談決定了後續軟體開發的成敗。而使用者因人而異,有的人可以明確告知需求,有的需求隨時在變,甚至搞不清楚他到底要的是什麼。大多數的情況,不可能一次就把所有的需求明白列出,而必須經過多次的蒐集資料、討論、驗證的模式下,找出真正需求與作業流程。若使用者搞不清楚他自己要什麼,而軟體就直接進行程式撰寫的流程,爾後被廢棄或不堪用的機會極高。
確認了需求後,便可進行程式的撰寫。對於各項需求與功能,安排時程依序完成。此階段,常遇到的問題,除了本身程式撰寫時遇到的困難,可能需要找替代的方案實行,另一方面,也會面臨需求不明確,或是實行上的細節不清楚,而需回頭與使用者討論再進行修改。

避免迴圈式的交付測試

當程式撰寫到達一個段落,除了本身開發者進行的測試之外,在系統上線前,也必須交由使用者先行測試。此時除了程式本身的Bug之外,另一個可能發生的狀況就是使用者功能不好用,而這很主觀,因為每個人的操作習慣不同,操作方式也不同。一般來說,這個階段的時間,常常花在修正功能或是使用者介面(UI)上,系統規劃需求分析程式撰寫系統測試系統上線進入維護階段需求流程圖時間成本??www.networkmagazine.com.tw 29IT NOW來滿足大部分人的習慣。但這階段必須注意的是,有時候增加許多檢查機制或UI時,往往又會造成使用上的不便,導致使用者希望回覆成原本的樣子,所以在修改前,需告知使用者修改後可能發生的狀況,儘量避免迴圈式的修改需求。

不要輕忽保固維護成本

當軟體完成測試階段,正式上線之後,即開始進入軟體生命週期的維護階段。大部分的人會覺得此時已經大功告成,接下來應該就輕鬆許多。其實不然,買硬體有所謂的保固期,而軟體當然也是。當上線之後,便正式進入維護的階段,可能是本身的程式有Bug在測試期間沒有被發現,也可能是突發的系統硬體造成問題,可能會影響系統運作,必須及時解決,總之,舉凡上線後的大小問題,都應該在維護階段替使用者解決,以期系統的正常運作。
但若當初開發時過於複雜,或是系統撰寫時不夠嚴謹或模組化,維護的時候,很可能會發現光是解決這些問題,會比預期要多很多的時間。

開發與維護的工時比較

1.開發工時>維護工時
一開始瞭解得越詳細,後續維護時,修改的比例可以降低很多。以先前開發軟體的經驗,在與使用者溝通作需求訪談時,需看專案的複雜度,一般來說,大約需要專案時程1/6的時間和使用者溝通,瞭解運作過程和他們的需求。使用者的想法可能天馬行空,但必須藉由系統開發者的經驗告知,何者可行、何者不可行,藉以界定系統開發的範疇。
而在系統規劃與程式開發的階段, 大約需要專案時程2 / 3 時間。在程式撰寫時必須注意「可靠性」、「可維護性」、「易讀性」、「嚴謹性」,如果此階段做得好,後續維護時的複雜度就不會太高。軟體從測試到上線,也需要約專案時程的1/6的時間,有些情況測試時間可能延長,端看使用者測試狀況而定。
而上線之後的維護工作,在系統上線後的一年內,因為使用者的需求而修改功能、因系統化而新增加的需求、資料統整、系統改版等,到整個系統穩定,約又花了原本專案時程的1/2以上的時間(也就是上限後再加1/2的時間)。這已是大部分的軟體的開發工時與維護工時中最理想的情況了,這種情況約莫佔了20%比例。
2.開發工時<維護工時
緊急的時候,我們必須在極短的時間內,開發出一個「可用的系統」(或是使用者本身能提供的資訊非常少的情況下要完成一個系統),這時要想瞭解的需求,其實非常有限,使用者未必能在需求訪談期間內,提供他的想法,這種任務通常是快速做出一個可以運作的軟體,然後再來慢慢修。在這樣不嚴謹的情況下做出來的軟體,後續付出的代價會相當大。
(作 / 交通大學資訊技術服務中心許銜書、計算機與網路中心校務資訊組副組長尤淑芬)
(……未完,其餘內容詳見網路資訊雜誌第226期2010年9月號)
關於我們

自1990年創刊UXmaster雜誌,1991年獲得美國LAN Magazine獨家授權中文版,2006年獲得CMP Network Computing授權,2009年合併CMP Network Magazine獨家授權中文版,2014年轉型為《網路資訊》雜誌網站,為台灣中小企業協助技術領導者落實企業策略,了解網路規劃及應用,為企業網路應用、管理、MIS、IT人員必備之專業雜誌網站。


與我們聯絡

加入《網路資訊》雜誌社群

© Copyright 2017 本站版權所有,禁止任意轉載 網路資訊雜誌 / 心動傳媒股份有限公司 聯絡電話:+886 2 29432416