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

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

  　1. 评估产品的利益鉴别——对于产品的受益人而 言具有什么已知利益或潜在利益?

　　可能性——假设产品正如所设计的那样工作， 受益人有多大可能性会认识到每个利益?

　　影响——对受益人而 言， 每个利益的期望程度如何?

　　个体重要程度——从个体考虑， 哪些利益是完全不 可替代的?

　　整体利益——作为一个整体且假设没有问题， 是否具有足够的利益以满足受益人?

　　2. 评估产品的问题鉴别——对于产品的受益人而 言具有什么已知问题或潜在问题?

　　可能性——受益人有多大可能性会发现每个问题?

　　影响——对受益人而 言， 每个问题的破坏程度如何?是否可以继续工作?

　　个体重要程度——从个体考虑， 哪些问题是完全不 可接受的?

　　整体问题——所有问题叠加在一起会怎样?是否有太多的非关键问题?

　　3. 评估产品质量整体质量——根据GEQ视角， 利益是否看来超值于问题?

　　安全/完美边际值——如果需要或想要使利益超值于问题， 那么至少需要投入多少?

　　4. 评估改进产品的后勤问题策略——有哪些策略可用于改进产品?

　　能力——具备 实现这些策略的能力吗?知道如何做吗?

　　成本——改进工作需要多少成本或存在什么麻烦?是否充分利用了资源?

　　进度——能否立即开始或稍 后再改进?能否在可接受的时间范围内实现改进工作?

　　利益——改进效果明确吗?有附加利益吗(如更好的士气)?

　　问题——改进工作会有多大可能带来负面影响(例如， 引入错虫、损伤士气、占用其他项目资源)?

　　GEQ视角(perspective)

　　上述GEQ元素是必要条件而不是充分条件。为了执行可靠的评估，还必须同时从六个关键视角来检查每个元素：1. 受益人——哪些人关于质量的意见起作用?(例如，2. 项目团队、客户、商会、法院等)

　　3. 关键目的——什么是必须达到的?(例如，4. 即时生存、利润、市场份额、客户满意度等)

　　5. 时间尺度——质量改进成果的时间敏感性如何?(例如，6. 立即、近期、长期、某个关键事件之后等)

　　7. 替代物——本产品与替代物相比如何?(例如，8. 竞争对手的产品、服9. 务或解决方案)

　　10. 失败结果——如果质量比GEQ稍11. 差一些会怎样?是否需要对突发事件进行规划?

　　12. 评估质量——评估本身的可信度如何?是否令人满意?

　　显然，满意质量决不等同于平庸，它强调的是理性的选择，而不是强制性行为。如果按照GEQ框架分析后认为某个软件已经达到满意质量，那么进一步的改进将意味着资源投入得不到足够的回报。如果我们发现自己正处于这样一种境地时，就应当认真找寻一下其背后的强制性理由何在。对于GEQ方法的强大推动来自于市场驱动型软件的爆炸性增长，软件公司对于巨额股票市值的憧憬导致公司致力于寻找最短途径以更快地推出更好、更便宜的软件，他们愿意承担风险，而且很难容忍传统意义上的所谓良好实践，许多传统的软件管理观点在应用到市场驱动软件项目时常常不适用或显得过于呆板。可以看出，GEQ方法与“轻”方法殊途同归，无论是高可靠性要求的软件开发还是高娱乐性要求的软件开发，都可以利用其指导开发工作。无论称其为GEQ，或其他什么称谓如经济性、实用主义、功利主义等，基本思想都是一致的，即我们的行为应受理性指导，而不是强制。

　　随着GEQ思想的持续发展，我们思考的质量，而不是遵循形式方法的质量，将成为问题所在，而形式方法及其背后的权威将被重新审视，这也正是许多权威将GEQ视为危险思想的原因。

　　四、快速应用开发

　　以上从基本原理入手对于新兴的“轻”方法和满意质量框架进行了讨论，本节则以近年来被广泛应用的快速应用开发(RAD)方法作为具体实例加以探讨，为加深对于这些新思想的理解提供帮助。

　　RAD方法与原型方法有很多相似之处。原型开发可以使用户看到系统的不同设计方案，尤其当用户需求不确定时。一般情况下，原型仅用于提供演示。不过，一旦最终版本原型功能正确，文档齐全，且被正确构造，则可以将其用作最终产品。当原型被用作产品时，所有的遗留问题都必须已经解决，软件应符合需求说明书、设计文档和测试文档。与原型法不同的是，RAD每次交付的是用户在实际业务中应用的系统，而不仅仅是一个演示模型。

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