中國的企業特別講責任。對於軟體產品的質量責任，在IT企業裡一直是一個“剪不斷，理還亂”的話題。我常常看到、感受到在一個軟體產品或系統的工作鏈上，所有的上下游角色都急急忙忙地工作著，可是有一天，有個BUG，我們且叫它“壞孩子”吧，被發現了，大家於是就開始了關於這個“孩子”的來源之爭：這是程式碼問題！”----“不，這是設計問題！”-----“不不，這是需求的問題！”。另外，你也許還聽說過其他一些關於軟體質量責任的看法，比如：“質量是測試出來的。”“質量是設計出來的。”等等八仙觀點。
工業時代的全面質量管理，在美國和日本的推動下，為我們消費者帶來了無數的精良產品和美的享受。同時，也建立了責任分明的企業質量文化。進入資訊時代後，TQM等質量管理理論和方法也被引入，但似乎對資訊科技產品無能為力，無法落實。我們手裡的質量大棒找不到了對手。顯而易見的原因是，軟體產品的不可見性和動態性導致了它的“相對不可觀測性”。同時，軟體質量管理活動和工程活動的結合不足也是非常重要的原因。當然，我們看到了這20年來軟體質量管理的新理論、新變化。我們在軟體測試領域，不斷地推進，從黑盒測試到白盒測試，從手工測試到自動化測試。等等。這些進步，改善了我們程式碼植入錯誤的狀況。然而，設計依然不能被全面測試，需求依然不能被全面驗證。問題沒有被根本解決。我們依然達不到象對待工業品那樣清晰地管理軟體產品質量！

沒有哪個環節能被完整度量的時候，質量就是每個環節的責任！當沒有人能對質量獨立負責的時候，質量就是大家的責任！所以我說，BUG這個壞孩子，是大家的孩子！
這樣的認識基礎，必然決定了軟體質量全員責任。全員責任又帶來了一系列棘手的問題：責任劃分的困惑和責任推脫。最後，產生了模糊的企業質量文化。就比如第一段裡的那些八仙觀點。另外，軟體公司裡的質量管理部和測試部“偉大的職責和尷尬的地位”也說明了這一點。（這裡我要強調的一點是：質量管理問題沒有被很好地解決，並不妨礙一些好的產品的問世。）
這裡，我試著提出一種軟體專案質量管理模型。這個模型幫助我們有效分解責任鏈，說明軟體工程活動的責任分配，並描述軟體質量的責任衰減梯度。同時，這個模型也有助於提高我們的工程能力。該模型如下圖：

模型的解釋如下：
（1）4個象限分別代表4個質量責任區間或質量責任環節，分別是：需求開發人員的質量區間，架構師的質量區間，詳細設計人員的質量區間，程式設計開發人員的質量區間。
（2）沿順時針方向（圖中灰度降低方向），質量責任逐步衰減（降低）。因此，需求開發人員的質量責任最大，程式設計開發人員的質量責任最小。這個觀點可能會被許多同仁反對。但是，我依然這樣認為的原因有兩點：一是上游的工作對下游工作影響性大，所以上游的工作責任也就應該大，就像河水治理一樣，要重點關注源頭和上游的水質汙染。二是從事上游工作的人才成本高，所以責任也應該大。比如說現在的許多業務專家的待遇特別高。
（3）本模型以架構驅動的開發模型為基礎模型，所以，強調架構質量對軟體系統的全域性性影響。

（4）“測試”沒有被作為一個工程過程對待。因為，新的開發觀點，如CMMI等，認為，測試是一個質量控制和保證手段，屬於產品和需求的驗證工作；同時，測試越來越被早期執行，它甚至貫穿整個專案生命週期。
（5）軟體質量目標由需求決定。在設計和開發階段，質量目標被分解和實現。同時，缺陷從一開始變被“人為地”引入。因此，缺陷管理是質量管理的一箇中心工作，只要缺陷的開啟和不斷地關閉，才能促進軟體質量的完善。
（6）專案過程質量其實代表的是軟體開發的“工藝”，這是工程能力的一個主要方面。過程質量控制和保證可以使用傳統的質量管理技術和方法。現在中國掌握了很多西方高新技術理論，但是我們並不能消化這些理論製造出好的產品，其原因就是我們沒有好的工藝，工藝代表了實踐的經驗，不可逾越。聽說，全國熱火朝天在建的高鐵的車輪就是這樣的情況。所以，我們需要過程改進，需要EPG，來長期地構建軟體企業的質量文化。從這個意義上講，專案過程質量是關聯專案質量和組織質量體系的連線點。過程質量的另外一個價值就是，消弱公司對工程師的嚴重依賴，降低組織能力和員工能力的耦合度。
（7）產品質量有了明晰的度量方法，度量時間提前。早期如何度量軟體的質量看上去似乎是一個偽命題，因為早期軟體並沒有產生。但是在早期，軟體的質量缺陷卻已經開始被埋入了。我們就通過埋入缺陷的程度來度量軟體質量吧。同時，可以採取技術評審和測試等手段控制質量。
總結一下，該模型說明了質量問題的變化趨勢和質量責任接力棒的傳遞過程。有關質量技術及其實施有效性等問題：如技術評審的有效性、測試效率等問題，以後闡述。
歡迎討論！

轉載於:https://blog.51cto.com/yangruosong/425638