開發(fā)一個項目，簡單的說經過調研、開發(fā)、測試、維護四個大體的階段。每個階段的開發(fā)時間不一。筆者主要從事紫金橋組態(tài)軟件的項目應用開發(fā)工作，對組態(tài)軟件項目開發(fā)各階段的時間安排小談下自己的看法。這里筆者提出“4321”的說法，也就是說40%的時間調研，30%的時間開發(fā)，20%的時間測試，10%的時間維護，這里所說的“時間”也可以理解為工作量。之所以這么安排時間，原因如下所述。

一。40%調研

      從某種意義上說，組態(tài)軟件是個半成品，需要用戶在這個基礎之上進行二次開發(fā)。組態(tài)軟件已經提供了諸如報表、曲線、歷史保存、動畫連接等常用的功能模塊，用戶可以便捷的在這個基礎之上開發(fā)出自己所需要的監(jiān)控系統(tǒng)。組態(tài)軟件模塊式的開發(fā)環(huán)境雖然極大地方便了用戶的需求，另一方面，組態(tài)軟件的功能也是相對固定的，難以直接滿足用戶的一些特殊的需求

      此外，從整個監(jiān)控系統(tǒng)而言，組態(tài)軟件處于上位機的位置，需要PLC、模塊、板卡、儀表等硬件設備才能搭建一個完整的系統(tǒng)。對于一個系統(tǒng)，初期往往有多種通信搭配方案，串口級聯(lián)、以太網、GPRS、數傳電臺、無線射頻等等。而且很多時候，在使用組態(tài)軟件開發(fā)的人員，不一定是最終用戶，而是系統(tǒng)集成商等，這里就面臨一個雙方溝通的問題。只有充分溝通了，才能確定用戶的需求組態(tài)軟件能否實現，選擇哪些下位的硬件，確定具體的通信方式等。如果開始調研不夠認真、明晰，后期的開發(fā)從開始就可能出現了偏差，或者項目快結束了才發(fā)現有重大隱患。比如筆者曾接觸的一個項目，這個項目是監(jiān)控生產線的設備，設計者想通過組態(tài)軟件監(jiān)控生產線上的5個PLC，通信距離大概一百多米。初步決定采用1個485串口級聯(lián)的方式通信，而且已經完成了布線的工作，485串口在一兩百米內級聯(lián)5個plc，技術上沒有什么問題。可是筆者和該項目的最終用戶進一步溝通后，發(fā)現用戶對現場監(jiān)控的響應時間要求不低，在1秒以內。顯然，通過1個485串口通信級聯(lián)5個plc是實現不了這個要求的。或采用多個串口，少級聯(lián)設備，或更換通信模塊，采用以太網通信等方式都可以提高通信速度，達到用戶的要求。很多時候最終用戶不一定了解組態(tài)軟件的各方面特性，甚至不一定了解他們自己的具體要求，邊做邊改邊提要求的情況很常見。只有在前期的調研清晰了，才可以最大可能的避免項目后期的重大修改。

二。30%開發(fā)

      由于組態(tài)軟件本身模塊化的開發(fā)方式，一般而言，一個普通的項目開發(fā)時間不會太長，工作量相對不算太多。當然，很多時候，項目的開發(fā)進度還受到下面硬件設備進展等多種情況的影響，并不單獨取決于軟件本身。這里主要是指具體開發(fā)的有效時間。有人可能會奇怪為何開發(fā)的時間要少于調研的時間，這里要說明的是，充分的調研可以在開發(fā)之前就形成了一個明晰的開發(fā)思路，對加快項目的開發(fā)時間大有幫助。如果前期調研不充分，邊開發(fā)邊調研，那么開發(fā)的周期會拖很長的。

三。20%測試

      這里筆者把測試單獨提出來，而且給了比較多的時間。是因為筆者所接觸的不少最終比較失敗的項目，不是調研不充分，也并不是開發(fā)的不好，而是細節(jié)總不到位，總是有些地方不穩(wěn)定，有些地方不可靠，反復修改，修改好了這里，其他地方又壞了。用戶不滿意，不愿意付款，開發(fā)者覺得很辛苦，覺得用戶挑剔，維護的工作量太大，雙方陷入到扯皮的境地，項目也就相對比較失敗了。之所以出現這個情況，主要原因是項目開發(fā)完后，急于驗收，認為驗收完了也就OK了，項目沒有經過嚴格的測試。開發(fā)一個項目不難，但是開發(fā)一個比較穩(wěn)定可靠，健壯性強的項目是不容易的。嚴格的測試是保證一個項目少出問題的關鍵環(huán)節(jié)之一。很多時候，開發(fā)者都只是考慮到了項目正常時的情況，對于用戶一些非常規(guī)操作或現場的一些特殊情況的處理沒有考慮周全，導致項目看起來很好，實際運行之后漏洞百出，維護起來痛苦不堪。項目開發(fā)的時侯一般都會邊做邊測試的，這里所說的測試更多是指項目初步完成后的系統(tǒng)測試。關于測試方法，很多文章都有說明，什么單元測試、集成測試、白盒測試、黑盒測試等等，不足而一，這里不再贅述。沒有經過嚴格測試的項目，往往都存在著或大或小的漏洞。

四。10%維護

      可能很多朋友早就想說了，“10%的時間維護，太少了，項目有太多的時間用于維護了！”。的確，很多項目的確大量的工作用在了后期的維護，這里筆者認為，如何真的用了大量的時間認真調研，項目開發(fā)后認真測試了，當項目真正維護起來的時候，一般工作量不會太大的。之所以后期維護比較難做，很多問題出在之前的調研和測試中，導致了維護工作量的增大。當然，這里的“維護”，并不包含軟件的后期升級服務等，另一方面用戶自身的技術支持力量也影響著維護的工作量。

     總之，這里所說的“4321”時間安排也是個大概，并不是每個項目都要按照這個時間安排做，比如開發(fā)者對流程很熟悉可能前期的調研時間就少些。這里提到“4321”是為了強調一定要重視調研和測試，真正的開發(fā)工作占整個項目的工作量中并不算太多的。很多項目的開發(fā)實際走的是“1315”，也就是簡單的調研，著急的開發(fā)，開發(fā)完了也沒有進行嚴格測試，匆匆驗收，最終把大量的時間用在了后期維護上。用戶不滿意，也難以再繼續(xù)合作。根據實際情況合理的安排項目各步驟地時間，不僅可以減少項目的總體開發(fā)時間，更重要的是可以滿足用戶的真正要求，實現合作共贏。成功的項目，不僅可以實現客戶的需求，更重要在于帶來了持續(xù)的合作。