“过程决定质量”论之证明

<meta name="GENERATOR" content="OpenOffice.org 2.0 (Linux)"> <meta name="CREATED" content="20060224;19403400"> <meta name="CHANGED" content="20060224;20383500"> <style type="text/css"> <!-- @page { size: 21cm 29.7cm; margin: 2cm } P { margin-bottom: 0.21cm } --></style> <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"> <meta name="GENERATOR" content="OpenOffice.org 2.0 (Linux)"> <meta name="CREATED" content="20060224;19403400"> <meta name="CHANGED" content="20060224;20383500"> <style type="text/css"> <!-- @page { size: 21cm 29.7cm; margin: 2cm } P { margin-bottom: 0.21cm } --> </style>

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

作者：fasiondog

重读《软件构架实践》第一章，里面举了这样一个例子：

试想一下，如果把对某个系统的需求分析文档分别交给两个在不同组织工作的设计师，结果会如何？这两个设计师是给出一个构架，还是给出两个不同的构架呢？

答案是：一般情况下，会给出两个不同的构架。这一结果立刻就可以证明系统需求决定构架的观点是错误的。

这个问题可以这样表述：

问题：为什么“需求不能决定构架”？

“是”的解决方案：答案已经在上面的例子中进行了描述，我们需要寻找其它影响构架生成的因素，于是演变成下面的图，结论是：是的，需求不能决定构架，而是各种因素（如环境、组织结构等等）共同影响了构架。

“非”的解决方案：沿着上面的方式回归证明“需求能够决定构架”，解决手段——扩大“需求”定义，需求包括了：功能需求、性能需求、环境需求、组织约束、其它设计约束等等。现在再看：喔，原来“需求”决定“构架”！ 如下图所示：（注：这里这样思索的结论显然是不正确的，这里引入此思路，仅仅是为了沿着同样的思路引入对“过程决定质量”的遐思。）

联想：“过程决定质量”

“过程决定质量”这是每一个QA几乎都被要求当作金科玉律般坚定不可动摇的信仰，可是困惑的疑云总是挥之不去，并不能因为其如同语录般的指示而消逝。But why？

问题：为什么“过程不能决定质量”？

“是”的解决方案：寻找其它影响质量的因素，于是演变成下面的图，结论是：是的，过程不能决定质量，而是各种因素共同影响了质量。所以，此时“质量铁三角”出现了：“过程、技术、人”共同决定产品质量。（《2004年质量专业综合知识（中级）》中对过程的定义：“一组将输入转化为输出的相互关联或相互作用的活动”。过程由输入、实施活动和输出三个环节组成。）

“非”的解决方案：我们的目的——坚信“过程决定质量”！所以，我们需要扩展原有“过程”定义，让其同时包含“原有的过程定义、技术、人”。从这一点出发，下面的定义仍然略显单薄，至少对于技术（或方法）方面没有体现：

“过程——一个工作比较复杂，我们将它分解为一系列活动，给出每个活动的时机、输入、角色、输出，并将活动串起来，最终达到工作的目标。”（来源于公司同事的定义，加入了人的因素：角色）

或许这样表述更为合适：

“过程——一个工作比较复杂，我们将它分解为一系列活动，给出每个活动的时机、输入、参与的角色、输出以及相应的技术或方法，并将活动串起来，最终达到工作的目标。”

因此：过程决定质量！