來源： http://blog.csdn.net/kongdong/

作者： fasiondog

重讀《軟件構架實踐》第一章，里面舉了這樣一個例子：

試想一下，如果把對某個系統的需求分析文檔分別交給兩個在不同組織工作的設計師，結果會如何？這兩個設計師是給出一個構架，還是給出兩個不同的構架呢？

答案是：一般情況下，會給出兩個不同的構架。這一結果立刻就可以證明系統需求決定構架的觀點是錯誤的。

這個問題可以這樣表述：

問題：為什么“需求不能決定構架”？

“是”的解決方案：答案已經在上面的例子中進行了描述，我們需要尋找其它影響構架生成的因素，于是演變成下面的圖，結論是：是的，需求不能決定構架，而是各種因素（如環境、組織結構等等）共同影響了構架。

“非”的解決方案：沿著上面的方式回歸證明“需求能夠決定構架”，解決手段——擴大“需求”定義，需求包括了：功能需求、性能需求、環境需求、組織約束、其它設計約束等等。現在再看：喔，原來“需求”決定“構架”！ 如下圖所示：（注：這里這樣思索的結論顯然是不正確的，這里引入此思路，僅僅是為了沿著同樣的思路引入對“過程決定質量”的遐思。）

聯想：“過程決定質量”

“過程決定質量”這是每一個 QA 幾乎都被要求當作金科玉律般堅定不可動搖的信仰，可是困惑的疑云總是揮之不去，并不能因為其如同毛主席語錄般的指示而消逝。 But why ？

問題：為什么“過程不能決定質量”？

“是”的解決方案：尋找其它影響質量的因素，于是演變成下面的圖，結論是：是的，過程不能決定質量，而是各種因素共同影響了質量。所以，此時“質量鐵三角”出現了：“過程、技術、人”共同決定產品質量。（《 2004 年質量專業綜合知識（中級）》中對過程的定義：“一組將輸入轉化為輸出的相互關聯或相互作用的活動”。過程由輸入、實施活動和輸出三個環節組成。）

“非”的解決方案：我們的目的——堅信“過程決定質量”！所以，我們需要擴展原有“過程”定義，讓其同時包含“原有的過程定義、技術、人”。從這一點出發，下面的定義仍然略顯單薄，至少對于技術（或方法）方面沒有體現：

“過程——一個工作比較復雜，我們將它分解為一系列活動，給出每個活動的時機、輸入、角色、輸出，并將活動串起來，最終達到工作的目標。”（來源于公司同事的定義，加入了人的因素：角色）

或許這樣表述更為合適：

“過程——一個工作比較復雜，我們將它分解為一系列活動，給出每個活動的時機、輸入、參與的角色、輸出以及相應的技術或方法，并將活動串起來，最終達到工作的目標。”

因此：過程決定質量！

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=608728