显然，满意质量决不等同于平庸，它强调的是理性的选择，而不是强制性行为。如果按照GEQ框架分析后认为某个软件已经达到满意质量，那么进一步的改进将意味着资源投入得不到足够的回报。如果我们发现自己正处于这样一种境地时，就应当认真找寻一下其背后的强制性理由何在。对于GEQ方法的强大推动来自于市场驱动型软件的爆炸性增长，软件公司对于巨额股票市值的憧憬导致公司致力于寻找最短途径以更快地推出更好、更便宜的软件，他们愿意承担风险，而且很难容忍传统意义上的所谓良好实践，许多传统的软件管理观点在应用到市场驱动软件项目时常常不适用或显得过于呆板。可以看出，GEQ方法与“轻”方法殊途同归，无论是高可靠性要求的软件开发还是高娱乐性要求的软件开发，都可以利用其指导开发工作。无论称其为GEQ，或其他什么称谓如经济性、实用主义、功利主义等，基本思想都是一致的，即我们的行为应受理性指导，而不是强制。
随着GEQ思想的持续发展，我们思考的质量，而不是遵循形式方法的质量，将成为问题所在，而形式方法及其背后的权威将被重新审视，这也正是许多权威将GEQ视为危险思想的原因。
四、快速应用开发
以上从基本原理入手对于新兴的“轻”方法和满意质量框架进行了讨论，本节则以近年来被广泛应用的快速应用开发（RAD）方法作为具体实例加以探讨，为加深对于这些新思想的理解提供帮助。
RAD方法与原型方法有很多相似之处。原型开发可以使用户看到系统的不同设计方案，尤其当用户需求不确定时。一般情况下，原型仅用于提供演示。不过，一旦最终版本原型功能正确，文档齐全，且被正确构造，则可以将其用作最终产品。当原型被用作产品时，所有的遗留问题都必须已经解决，软件应符合需求说明书、设计文档和测试文档。与原型法不同的是，RAD每次交付的是用户在实际业务中应用的系统，而不仅仅是一个演示模型。
在接受项目定单以后，通过在产品开发时间、费用和质量三者间达成折衷从而快速地移交产品。RAD方法采用递增式产品交付，通过用户在每一开发循环周期中的反馈信息来确定下次循环的方向。由于市场需求很难预计，因此RAD循环将无限持续下去直至系统被淘汰。一个典型的RAD开发循环周期是每月推出一个系统的新版本，有时会缩短到每星期甚至每天。不过开发周期越短则开发过程就会越不稳定，也越容易失控。RAD方法通常建立在以下基础上：
所有目标 的明确定义（需要做什么）和解决方案的指 导说明（怎样去做）。
将解决具体问题的任务（怎样去做）交给个人。
项目领导者以教练方式代替细节管理， 从一开始就让各员工担负较大责任（仅当有迹象表明员工不 能按时交付时领导再出面解决）。
团队中的各角色都应预先明确， 这样每一项任务的完成交付都至少和一位员工的责任对应。但在项目开发的中途， 当实际工作量高于或低于预期的工作量时， 可以改变员工角色或任务。
领导者本身具备 编程能力但可以不 进行编码工作。
顾客积极参与：顾客是否支持该项目的结果、设计等？你需要确定谁是顾客：谁影响和作出决定？
开发团队积极参与：团队各成员认可各项需求和时间期限吗？
范围控制：保证当前和以后各阶段的估计值不 会过于脱离实际。
实际应用中，RAD方法一般以进度和费用作为独立参数来调整策略，步骤如下：
1. 客户确定他们所能承受的最长开发时间和费用。
2. 开发人员估计满足所有功能所需的开发时间和费用。
3. 如果开发人员估计的开发时间和费用同4. 客户所能承受的时间和费用相差无几，5. 那么就可以进行项目开发了。否则：
6. 客户划分项目所需功能的优先级。
7. 如果开发时间超出或费用不8. 够时，9. 项目开发者会在系统开发中摒弃那些低优先级的功能特性。
10. 项目开发者先建立起系统的核心功能，11. 然后按照优先级由高到低的顺序实现新的功能，12. 直到开发超时或费用超支。
在使用RAD方法时，可利用以下技巧来提高开发效率和质量：
在每次开发之前，确定一个明确的开发计划，包括初始需求的建立，总体目标，项目范围，成功标准，采用的RAD工具和开发方法。
在每次开发之前，简要描述出每个开发周期中所需实现的功能模块。制定出在前一两个开发周期中所需实现的功能特性是非常重要的，这包括确定实现具有高优先级的基础功能或关键功能，预测实现目标和潜在风险。
在每次开发之前，回顾需要在此阶段实现或修改的每个功能，判断它们是否同项目所要实现的目标一致。区分哪些功能是在这个阶段中必须要实现的，哪些仅仅是希望实现的。
使用那些经验丰富的、受人敬重的测试人员。
保证设计者和开发者密切联系，并使测试人员尽可能参与到开发过程中。
要求设计者和开发者完成各自的单元测试和适当的集成测试。
确定开发过程的安全警戒点，例如，当开发过程中未解决的问题超过了预计值时，应安排额外的时间进行 产品修正，直到错误数量大大减少。
尽可能利用和调整已有测试工具，如回归测试平台、已有测试用例等。
使用成熟的调试工具和自动化的测试工具以加速开发进程。
使客户和最终用户最大程度地参与容量测试，请用户在日常工作中尽可能地并行使用该系统，并与上次开发周期交付的版本进行前后对比。
对需求和产品范围的任何改变应慎重分析，测试人员应对所提出的改变可能产生的影响做出评价，并在证明是正当的情况下有权予以否决。
提醒用户可能存在错误，培训他们怎样认识和报告错误，怎样在这些错误下工作。
应用程序的每一次循环开发都应在版本控制下进行。
不允许未经过最小测试的新版本发布。根据用户反映、操作风险、故障等级、与上一版本相比最新改动的地方等因素来确定最小测试需求。
必要时，如果为了满足有时间期限的下一次升级，可以考虑在准备发布之前删掉漏洞多的功能部分。
如果最新功能证明包含一个漏洞，则要提供给用户一个返回原版本的机制。
应用软件通过反复的修正，会变得更稳定。或者至少特定功能或子系统会比其他部分更早些趋向稳定，作为系统稳定的部分，可使用自动测试工具进行更完全的测试。
发布升级版本后不必对用户所发现的小漏洞感到不安。这对于首次运行是很自然的问题，而且通常还将会有使用户抱怨的地方。用户应当理解软件升级的原因完全是因为新生事物很少有完全正确的。应强调团队合作。
通过探测或预测程序中可能发生错误的地方而避免关键点任务的失败。
通过原型、标准、一致性检查等减少走回头路，利用风险预测技术来避免各种缺陷和风险。
文章来源于领测软件测试网 https://www.ltesting.net/
