軟體開發流程的一些思考

1. 大型通用軟體的開發就是以品質第一的原則
 軟體在賣到幾十套的時候，品質只要過的去就可以了，但一旦軟體賣到上千套，品質就絕不能以對付了事，否則維護部門的電話就要被打爆。測試人員一般的能達到開發人員的1/3就比較合理了，如果是剛起步的公司，考慮到
 成本因素，而且大多是以開發項目為主，所以在測試上可以相對的放鬆一些，但一旦
 公司進入正軌，開發規模增大之後，一定要重視測試。測試人員、開發人員、設計人員
 都圍繞需求進行工作，需求文檔也是所有人員的主要依據，測試人員實際上起到了監督
 開發人員工作的作用，而且也為工作的績效考核提供了量化的依據.
 
2. 測試不能“教條主義”
 測試也開發一樣，也是一個實踐性的工作，一個測試人員長期在進行某產品的測試，自然
 會積累大量的經驗，這些經驗很難歸結到一些測試理論中。在一些開發不太正規的團隊中
 反倒有一些過分迷信理論的傾向，其實實際操作並沒有那麼複雜，一個ERP系統的測試主要
 就是功能測試，說白了就是游標點來點去，如果整天捧著厚厚的軟體工程書，反而把簡單的
 問題複雜化了，當然在有一定測試經驗後，回頭看看理論。理清自己的思路也是有好處的.
 
3. 所有文檔中，需求文檔最重要
 一般的，大家都是一致的對待各種文檔，需求文檔、概要設計、詳細設計、測試報告等等，
 但如果要排一個重要性的順序的話，需求文檔無疑是最重要的，在確定需求上花再多的時間
 也是值得的，其次，設計文檔也很重要，至於一般的將設計文檔分為概要和詳細兩種似乎必要性
 不大，如果是公司資訊化系統的話，設計文檔應該重點把背景商務邏輯描述清楚，有可能的話
 把SQL語句都事先寫出來，如果系統達到一定規模，應該會有大量的UI端的公用控制項，所以在設計文檔
 裡只要把介面的大致輪廓描述出來即可，另外要把輸入資料的約束說明.
 在時間分配上，一般的，需求佔1/4，設計佔1/4，編碼和測試佔1/2。而且在編碼和測試的時間段
 裡，純粹的編碼時間占的更好，測試的進行過程中往往要對代碼做反覆修改.