在軟體工程的參考書上，所列的各種軟體開發生命週期模式，好像沒有一種適用於政府委外開發案。通常在RFP只會列各階段交付項目，看起來可以採waterfall模式來對應，偏偏政府委外案的需求確認作業總是一再延宕，這並不符合waterfall模式需求明確的前提要求，若採其他漸增式、反覆式，甚至於螺旋式或RUP，在時間上好像都不太允許。若說是採雛型模式，又該如何對應各階段交付文件? 不知各位先進針對這問題有何高見?

傳統式的開發方法，常常是用waterfall模型比較多，故先決條件當然是要將需求寫清楚。但是，因為對於這些政府非軟體工程專業人員來說，提需求是困難的，更不用說是寫出明確的需求。在二、三十年前有人提出雛型法的概念，也在學校的教育中，傳達給學生們，乃至於政府部門的人員，因為這個方法看起來對政府部門的承辦人員來說可以舒解很多壓力，至少在RFP階段，不太需要傷太多腦筋，甚至於拿別人的需求來"先頂一下"，等到等了專案中再說。專案開始，先要求廠商儘快地做出雛型來後，以便藉以找出自己真正的需求，然後再就雛型修修改改以獲得政府部門要的產品。這個看來很美好，因此，政府部門人員多數都這麼做事。但問題在於，政府部門從來沒有考慮過，雛型法適用的開發環境，就算目前談到Agile Engineering也是一樣，要放在現行契約的專案環境，可行性都不高，註定都會失敗。因為，根本無法在契約期限內完成驗收，除非放水，或者甲乙雙方先達成一定的默契，將專案期程一直延續到保固期結束，也就是在保固期期間，還在增修功能，甚至於默許廠商可以再承包維護案，然後在維護案裡繼續把未完的工作完成。當然要以雛型法或是Agile Engineering執行專案，還是可以從契約條款的訂定做一些調整的。例如，縮小需求的範圍，然後在契約裡設定可以早期讓專案廢掉的條文，即出問題或有困難時，可以早期把專案停掉。當然，該付給廠商的錢還是得付。只是，對於政府部門而言，各項預算相互排擠，故系統發展及維護的預算編列不易，發包後又有預算執行績效的壓力，要訂定這種契約，真正走雛型法或Agile Engineering，除非是極高層的政府單位，或者是扮演考評者的單位外，是不太可能訂出這種契約的。

雛型法開發模型的文件如何產生的問題，首先應該是先了解，我們為什麼要寫文件？雛型法是一個籠統的說法，其中還包括不同層級的雛型，例如，系統雛型、子系統雛型、功能雛型等等，而其產生的順序通常是由上而下的，也就是先有全系統雛型，接下來是子系統雛型，然後才是功能雛型，愈高階的雛型，不會一開始就可以看到"實際"的東西，且應該都是書面化的，最多用一些hyperlink方式去將子系統的關係串起來，但是心急的客戶希望看到的 "雛型"是一個已經可以執行的完整系統，也不太care你的文件到底寫了什麼，但，這是不對的。雛型法原本就是希望儘快的能夠給客戶看到概念及可能的操作，以便確認需求，因此，配合雛型的製作，各階層的需求文件與設計文件，都還是可以隨著雛型發展的進程產生，做各層級雛型的時候，就把所得到的結果記錄下來，在展示雛型的時候確立，然後給客戶確認。問題在於，客戶除了很急之外，就算給了雛型，並不保證確認的需求就不會再改，而這樣的問題，其實不管你採用什麼開發方法，通通都會遭遇到，所以，在專案中，文件總給人一種聊備一格的感覺，但是，客戶這麼覺得，開發者可不能這麼想，反而是要累積這些文件，確認過的，有客戶簽字的東西，這些文件，不論是系統發展上有用，不得已要上法庭時也很有用。(協會已經協助過法院做過這樣的工程爭議鑑定工作，沒有文件，等於沒有證據，就會被當成什麼都沒有做)

個人認為這些所謂對應的文件，就是看雛型的層級，來撰寫該層級的文件。但這些都還是脫離不了需求文件與設計文件。而測試文件也是一樣，依層級會有系統測試、整合測試、功能測試或單元測試的文件，配合各層級雛型的產生而產出。

這些情況就算採用Agile Engineering亦然，就算結合Scrum來做軟體發展的Agile Project Management，也不會有太大的差異。Scrum雖然是在一個Sprint內有一些要實作的backlog，但是，基本的架構(系統架構)還是得在專案開始的時候確立，在執行期間，Scrum只管管理上的一些作法，但工程上卻沒有去律定發展的過程與活動，以及就工程的執行應該有的產出，所以，有關於Agile Engineering下，對於工程應該有那些產出，或許CMMI或是ISO/IEC 12207、ISO/IEC 15289等文件，可以提供一些指導。

----------------
引文: