引用：
軟件質量得控制牽涉到很多變量。關鍵是在每個步驟都需要管理和控制。需要規范化整個軟件開發過程。
1、需求得時候做需求評審。但是怎樣引導客戶來提出確切得需求，就需要很好得溝通技巧，在客戶需求了解得前提下，針對開發項目所做得技術需求，應該進行評審。
2、概要設計時體系結構的評審、多次討論。并保證足夠的時間和精力來充分討論所做的概要設計是否真正滿足需求。不能以進度太緊等借口將概要做的馬馬乎乎，直接開始代碼編寫。（這也是以前做項目時最常犯的毛病。）項目經理必須有膽量有信心頂住老板的壓力，很多BOSS衡量進度就會問，你編了幾行代碼了？怎么還在這里什么都沒做？
3、詳細設計盡可能統一、規范。編碼時要有統一的編碼規則。命名規則等約束。即使天才程序員也應遵循適當的規范。否則大家以后在維護天才的代碼的同時，肯定會在心里大罵。
4、測試要在需求和設計階段就開始，不能等到編碼結束再進行。再編碼過程中的單元測試應得到重視，程序員之間的交換測試可以取得一定的效果。發現問題越早，麻煩越少。
5、對重要的功能實現代碼做CODEREVIEW。為避免流于形式，在會前要充分協調，作好準備。
6、版本控制。需求變動控制。適當地使用工具進行版本和需求變更的控制。避免后期版本混亂，做無用功。
7、當然還有文檔，要做就做規范，做踏實。應付檢查和交差的文檔不做也罷，浪費時間而已。文檔太難控制的話，在編碼時作好注釋也可作為一種方法。
而現實中是：
1、產品中沒有白盒測試的概念，從最底層代碼開始，經過多年的修改，已經是千瘡百孔。具體一個函數有多少隱含的問題要進行測試、統計一下。
2、代碼不進行重構，公司領導不重視重構，導致代碼腐爛很嚴重。很簡單的事實，一個配置變量在多處進行維護著 ，一旦進行修改，就要去修改很多處。再加上模塊充斥著幾千行的類和幾千行的文件。最大的一個類triadapter達到了16258行，welldatamanager 17055行，類使用起來倒是很方便，要數據相關的東西，你只要找welldatamanager就好了，然后你就在幾萬行的代碼中徘徊吧。其他的代碼重復、過度依賴等等問題就更多了。
3、黑盒測試力度不夠。七八個人編碼，兩個人進行測試。并且隨著時間長了，固定的兩個人對軟件產生了習慣性，導致很多地方測試不到。
4、沒有規范的軟件開發流程。軟件設計、測試用例編寫
5、測試時間不足，軟件發布前一周還在進行軟件功能的開發。
6、需求不穩定。需求反復修改帶來的問題。比如繪制刻度的時候，現實垂直畫、后來水平畫、再后來還是垂直畫