一位資深企劃歸納的結論,覺得很有啟發性.
三層能夠強化軟體品質的方向
Ａ．概念性的授課．
目標最廣但最不明確，影響最不即時，聽者還沒有遇到適合的時機前，
最無法體會．但因為受眾最多，從組織的觀點來看，單位成本最低．
這個方法通常受到公司人資或非技術人員所歡迎及採用．
Ｂ．開發期的監察．
協助分析規格及風險，協助檢查實作上的異常(code review)．
雖然在功能及時間上都能靠近現場，但無法保證真正地看到問題。
因為必須監及造兩端都花費成本，有一定程度對時程的衝擊．(pair programming)
這個方法比較受到開發者的歡迎．
Ｃ．以使用者角度在產品面來檢驗．
對品質提升影響最明確．但是會需要有專業人事事先安排好測試計畫．
因為測試計畫只針對很明確的範圍（新規格），影響範圍卻是最小．
測試計畫不能重用的可能性相當高．因此常常會有成本沉沒的現象．
通常是直接的管理者會採用的方法．