2008年8月31日

Big Bang! 軟體開發的黑箱作業

受足夠訓練的專業程式設計師,能夠依照需求完成軟體開發,但往往只侷限於需求已經相當明確、規格已經確認的專案,很小的專案有機會在一開始就確定這些方向,即使有改遍通常也不會太大,因此程式設計者很容易就習慣了Big Bang!方式的軟體開發,即接到一個專案後就開始埋首寫程式,直到專案交付或約定測試的日子到了,才把完成的軟體給客戶使用。

這麼做確實省了開發時間,也較不會打擾客戶,節省了些成本,而結果即使有些需要修改,只要再多個幾天時間就能完成。

然而,這樣的軟體開發過程如同黑箱作業,對客戶來說,丟進去一個需求,只能期待著產出也能幸運地符合預期。

對於大型專案,或是需求很難在第一時間就溝通清楚、可能經常變動,或是客戶自己也還沒弄清楚真正的需求是什麼,這些情況會使得黑箱作業產生很高的風險。如果做出來的成品不是客戶想要的,那麼就造成了時間、成本的浪費,也會失去客戶的信任,甚至會有更多嚴重的後果。

學習傳統的系統分析與設計時,往往都會有種分析非常重要、分析沒做好前不能設計及撰寫程式、開發過程中分析佔大部份的時間,這種說法有部份的道理,因為沒有透過明確的需求分析確認,沒辦法實作出正確的程式。但實際上設計軟體很難實行這樣的理論,困難之處就在於一開始根本不可能將一切需求都訂清楚,很多時候客戶必須在看到一些雛型後,才會弄清楚真正需要什麼,許多時候需求是隨著專案開發時間的進行,會不斷變動或出現新需求。

假設我們排除其他狀況,讓專案一開始時,就先使用60%的時間和客戶溝通好需求,明確訂出系統各項規格,再交付給程式開發團隊用剩餘40%時間完成實作。這麼做似乎相當理想,因為先做好分析、才寫好程式,但實際上很可能陷入了前述的黑箱作業,因為在40%的實作時程中,是禁不起需求的變動而重頭再進行分析,時間已經變得很有限、而分析成本又是那麼地高。

先分析、再設計、然後才撰寫程式、測試除錯,這個過程沒問題,但必須把整個專案開發時程切割為多個iteration,在每個iteration中進行這樣的流程,每個iteration完成後都會產出一些可以被測試的功能,客戶也能夠看到一些雛型而對需求更加明確,並將意見回饋加入下一個iteration階段,經過多次iteration階段的循環,最後的產出就能夠更貼近客戶的需求。

而配合實現Test-driven的做法,每次撰寫程式前,就先完成測試程式碼,這些測試必須檢驗我們設計好的程式是否能由預定輸入產生預期的輸出,既然寫程式有bug是必然,先寫好測試就能幫助我們完成能產生正確結果(至少在某些條件下)的功能。在每個iteration最好都能夠把UnitTest完成,將能夠幫助我們在操作介面完整實作前,就先測試最重要的企業邏輯是否能如預期運作。

沒有留言:

張貼留言

lyhcode by lyhcode
歡迎轉載,請務必註明出處!