技术开发 频道

轻方法与满意质量——市场驱动的软件工程实践

    三、满意质量框架

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

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

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

    1) 软件开发被迫面对一个充满复2) 杂性、未知、限制、错误和不3) 完美的世界;

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

    5) 任何事情都带来成本,6) 而7) 我们所想要的总是超过我们能够支付的;

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

    9) 为了在软件方面达到完美,10) 我们不11) 得不12) 解决许多困难问题、达成许多折衷和解决相互冲突的价值,13) 完美不14) 会很容易或机械性地实现;

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

    基于上述假定,满意质量定义如下:(1)可带来足够的利益;(2)不存在致命性问题;(3)所带来的利益超过问题所造成的损失;(4)在当前条件下综合考虑所有因素后,进一步的改进所带来的损害大于其带来的帮助。同时,提供了一个用于评估GEQ的框架,该框架包括四个GEQ元素和六个GEQ视角,它们构成了一个提示问题集,可用来帮助相互沟通,或者帮助进行产品开发、产品改进、实现更好的实践活动等。例如,当某人说“满意未必是满意”时,就可以利用受益人和关键目的两个视角来理解该悖论的真实含义并予以讨论,可以应对“对你而言的满意对我却未必”,或者“相对生存目的而言的满意在以成功为目标时却未必”,这样问题就转换成谁的价值起作用或哪个目标是真正要实现的,进而探讨可行解决方法。以下是GEQ框架的概要描述:

    GEQ元素(factor)

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

    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视为危险思想的原因。

0
相关文章