1. 大型通用軟體的開發就是以質量第一的原則
軟體在賣到幾十套的時候，質量只要過的去就可以了，但一旦軟體賣到上千套，質量就絕不能以對付了事，否則維護部門的**就要被打爆。測試人員一般的能達到開發人員的1/3就比較合理了，如果是剛起步的公司，考慮到
成本因素，而且大多是以開發專案為主，所以在測試上可以相對的放鬆一些，但一旦
公司進入正軌，開發規模增大之後，一定要重視測試。測試人員、開發人員、設計人員
都圍繞需求進行工作，需求文件也是所有人員的主要依據，測試人員實際上起到了監督
開發人員工作的作用，而且也為工作的績效考核提供了量化的依據.
2. 測試不能「教條主義」
測試也開發一樣，也是乙個實踐性的工作，乙個測試人員長期在進行某產品的測試，自然
會積累大量的經驗，這些經驗很難歸結到一些測試理論中。在一些開發不太正規的團隊中
反倒有一些過分迷信理論的傾向，其實實際操作並沒有那麼複雜，乙個erp系統的測試主要
就是功能測試，說白了就是游標點來點去，如果整天捧著厚厚的軟體工程書，反而把簡單的
問題複雜化了，當然在有一定測試經驗後，回頭看看理論。理清自己的思路也是有好處的.
3. 所有文件中，需求文件最重要
一般的，大家都是一致的對待各種文件，需求文件、概要設計、詳細設計、測試報告等等，
但如果要排乙個重要性的順序的話，需求文件無疑是最重要的，在確定需求上花再多的時間
也是值得的，其次，設計文件也很重要，至於一般的將設計文件分為概要和詳細兩種似乎必要性
不大，如果是企業資訊化系統的話，設計文件應該重點把後台的業務邏輯描述清楚，有可能的話
把sql語句都事先寫出來，如果系統達到一定規模，應該會有大量的ui端的公共控制項，所以在設計文件
裡只要把介面的大致輪廓描述出來即可，另外要把輸入資料的約束說明.
在時間分配上，一般的，需求佔1/4，設計佔1/4，編碼和測試佔1/2。而且在編碼和測試的時間段
裡，純粹的編碼時間佔的更好，測試的進行過程中往往要對**做反覆修改.
44 軟體開發中的一些思考
0 引言 一直以來，對自己開發的軟體並不滿意，看了很多規則性的東西，但是並不能真正理解。在具體實施的時候，往往還是選擇了比較容易實現的 自己看起來清晰的方法，結果一旦需求變更就出現諸多問題，或者在介面設計的時候感覺力不從心，對自己畫出來的醜逼介面無可奈何。姑且先把問題記錄下來，留待以後慢慢學習 體會...
軟體開發質量管理的一些思考
pmbok裡關於質量管理主要有3個過程 制定質量管理計畫 質量保證 qa 質量控制 qc 書看了5 6次，還是發現比較抽象，難以理解。實際專案中，怎樣才幹合理的考慮各種資源制約，更好的執行質量管理呢？一般的正規流程大致例如以下 需求分析 客戶評審與確認 概要設計 內部評審 具體設計 內部評審 編碼 ...
關於高校內軟體開發流程的思考
學習軟體工程的方法已經有一段時間了，深深的感覺到，乙個軟體的成功與優秀的開發流程有著必然的聯絡。近期思考了很多關於軟體開發流程方面的東西，也檢視了一些相關的文章。今天就在這裡理一理思路，一來方便自己以後檢視，二來還可以接受們的批評和指正。正因為是新手所以還有很長的學習道路要走。學校中的專案除了科研專...