IT行业——轻方法与满意质量相比较[2]

　　IT行业——轻方法与满意质量相比较[2]    软件测试　

  　与此同时，重方法的倡导者争辩说，如果一个缺陷在开发阶段就被发现，那么就不应当责备引入该缺陷的个人，而应重新检查允许该缺陷发生的过程本身。但此处又有一个基本假设，也就是说，我们值得投入资源在鉴别一个过程中潜在缺陷的唯一理由是我们希望再次使用同样的过程——因为我们的下一个项目将会与上一个项目足够相似，很自然就应使用同样的过程。但是现在事物变化是如此之快，以至于完全不能保证第N+1个项目会与第N个项目有任何相似之处。因此，昨天的过程可能不得不为了明天的需求而发生实质性变化，换言之，也许只有投资于过程中的重要缺陷才是值得的，因为一些细节仅针对某个特定项目才有意义。

　　当然，仍然有一些环境需要我们继续依赖于旧的、基本的软件工程原理，在这些环境中重方法被证实依然正确。但是我们应当扪心自问，隐藏在这些原理背后的前提假定是否依然合理。对于许多今天的项目而言，一些根本性的前提假定需要加以改变，而轻方法将是具有最优性能价格比的方法。

　　可以看出，轻方法的基本思路是试图在项目范围、成本、时间和质量之间达成一种平衡，其关键是在足够的管理可见度、足够的灵活性和足够快的开发速度以完成工作之间找到这种平衡，必须严格审查你想要对项目加入或删除的控制手段的价值何在。尽管我们可以将某个公布于众的开发方法作为基础进行裁剪，但必须深入理解你要执行的每个步骤的理由，尤其在项目的初始规划阶段，就应明确定义开发方法，确保项目团队成员的参与和认可，并以满足项目的商业需求为目标。 三、满意质量框架

　　满意质量(Good Enough Quality，简记为GEQ)是与“轻”方法相呼应的新思路，同时也是一个存在很大争议和误解较深的概念，近年来受到越来越多的关注，其理论基础正在不断走向成熟，本节对其进行深入探讨。

　　满意质量的提法最初主要源自软件项目的直接参与人员，而不是那些制定软件过程或提供咨询的人士，在软件工程学术界则更是缺乏相关研究。这种情况导致了相关概念的滥用，满意质量常被用来为软件中明显存在的缺陷做辩解，甚至有人认为软件供应商在软件产品中保留错虫是一种蓄意行为甚至是聪明的策略，这无疑造成了很大误解。

　　为此，著名的软件工程专家James Bach根据自己多年的实践经验和理论基础对满意质量的原则进行了系统化定义，提出了满意质量框架，澄清了许多模糊认识。

　　满意质量框架基于以下假定：

　　1) 软件开发被迫面对一个充满复

　　2) 杂性、未知、限制、错误和不3) 完美的世界;

　　3) 截止目前人员是软件项目中最易变和最重要的元素;

　　4) 任何事情都带来成本，

　　5) 而我们所想要的总是超过我们能够支付的;

　　6) 质量在本质上是有条件的和主观的;

　　7) 为了在软件方面达到完美，

　　8) 我们不得不解决许多困难问题、达成许多折衷和解决相互冲突的价值，

　　9) 完美不会很容易或机械性地实现;

　　10) 软件工程方法仅在其设计范围和假定前提下有用。

　　基于上述假定，满意质量定义如下：

　　(1)可带来足够的利益;

　　(2)不存在致命性问题;

　　(3)所带来的利益超过问题所造成的损失;

　　(4)在当前条件下综合考虑所有因素后，进一步的改进所带来的损害大于其带来的帮助。

　　同时，提供了一个用于评估GEQ的框架，该框架包括四个GEQ元素和六个GEQ视角，它们构成了一个提示问题集，可用来帮助相互沟通，或者帮助进行产品开发、产品改进、实现更好的实践活动等。例如，当某人说“满意未必是满意”时，就可以利用受益人和关键目的两个视角来理解该悖论的真实含义并予以讨论，可以应对“对你而言的满意对我却未必”，或者“相对生存目的而言的满意在以成功为目标时却未必”，这样问题就转换成谁的价值起作用或哪个目标是真正要实现的，进而探讨可行解决方法。以下是GEQ框架的概要描述： GEQ元素(factor)

　　这里给出的四个元素是以GEQ定义为基础扩展而得到，并非严格的公式。这些元素被设计用来提醒那些忙碌的、超负荷工作的软件人士在评估软件产品质量时应思考的问题。

原文转自：http://www.ltesting.net