软件开发的家园,编程爱好者的天地.
&&|&&&&|&&
如何评价软件的质量
时间: 07:40
我们常说某某软件好用，某软件功能全、结构合理、层次分明。这些表述很含糊，用来评价软件质量不够确切，不能作为企业选购软件的依据。对于企业来说，开发单位按照企业的需求，开发一个应用软件系统，按期完成并移交使用，系统正确执行用户规定的功能，仅仅满足这些是远远不够的。因为企业在引进一套软件过程中，常常会出现如下问题：
定制的软件可能难于理解，难于修改，在维护期间，企业的维护费用大幅度增加；
企业对外购的软件质量存在怀疑，企业评价软件质量没有恰当的指标，对软件可靠性和功能性指标了解不足；
商缺乏历史数据作为指南，所有关于进度和成本的估算都是粗略的。因为没有切实的生产率指标，没有过去关于过程的数据，企业无法精确评价开发商的工作质量。
　　为此，有必要先了解软件的质量评价体系。美国的B.W.Ｂoehm和R.Brown 先后提出了三层次的评价度量模型：软件质量要素、准则、度量。随后G.Mruine提出了自己的软件质量度量SQM技术，波音公司在过程中采用了SQM技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。
第一层是软件质量要素，软件质量可分解成六个要素，这六个要素是软件的基本特征：
　　1. 功能性：软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。
　　2. 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度。可靠性对某些软件是重要的质量要求，它除了反映软件满足用户需求正常运行的程度，且反映了在故障发生时能继续运行的程度。
　　3. 易使用性：对于一个软件，用户学习、操作、准备输入和理解输出时，所做努力的程度。易使用性反映了与用户的友善性，即用户在使用本软件时是否方便。
　　4. 效率：在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。效率反映了在完成功能要求时，有没有浪费资源，此外＂资?这个术语有比较广泛的含义，它包括了内存、外存的使用，通道能力及处理时间。
　　5. 可维修性：在一个可运行软件中，为了满足用户需求、环境改变或软件错误发生时，进行相应修改所做的努力程度。可维修性反映了在用户需求改变或软件环境发生变更时，对软件系统进行相应修改的容易程度。一个易于维护的软件系统也是一个易理解、易测试和易修改的软件，以便纠正或增加新的功能，或允许在不同软件环境上进行操作。
　　6. 可移植性：从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。
　　第二层是评价准则，可分成22点。包括精确性（在计算和输出时所需精度的软件属性）；健壮性（在发生意外时，能继续执行和恢复系统的软件属性）；安全性（防止软件受到意外或蓄意的存取、使用、修改、毁坏或泄密的软件属性）；以及通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、产品文件完备性。评价准则的一定组合将反映某一软件质量要素，软件质量要素与评价准则间的关系如下图：
　　第三层是度量：根据软件的需求分析、概要设计、详细设计、实现、组装测试、确认测试和维护与使用七个阶段，制定了针对每一个阶段的问卷表，以此实现过程的质量控制。对于企业来说，不管是定制，还是外购软件后的二次开发，了解和监控过程每一个环节的进展情况、产品水平都是至关重要的，因为软件质量的高低，很大程度上取决于用户的参与程度。
对我有帮助
对我没帮助
以下留言只代表网友个人观点，不代表本站观点.966,690 三月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
什么是“成功项目”：谈谈软件的价值
什么是“成功项目”：谈谈软件的价值
日. 估计阅读时间:
不到一分钟
相关厂商内容
相关赞助商
QCon北京-18日，北京&国家会议中心，
有两个软件项目（姑且称之为&项目 A&和&项目 B&），它们在开始时的预算都是 50 个人月，时间是 5 个月。
项目 A 在 5 个月后完工，耗费成本 50 人月
项目 B 在 6 个月后完工，耗费成本 70 人月
在软件圈子里摸爬滚打多年的读者们对这个故事一定有自己的判断&&而且我可以大致猜出是什么样的判断。不过先别着急，我们还有另一个故事。
有两个软件项目（仍然姑且称之为&项目 A&和&项目 B&），它们在开始时的计划都是交付 200 项功能。
项目 A 在项目结束时一次性交付了最初计划的 200 项功能，但客户发现其中大约 30 项功能没有太大用处，而另外 30 项有用的功能要等到下一个项目才能实现。
项目 B 在第一个月结束时交付了第一个版本，此后每两周交付一个新的版本。在项目进行的过程中，客户进行了一次业务调整，加入了 90 项新的功能，并搁置了 50 项用处不大的功能。最终该项目交付了 240 项功能。
聪明的读者大概注意到了，前后两个故事讲的是同一回事，同样的两个项目。现在我的问题来了：请问哪个项目是更成功的项目？
这个问题并不容易回答&&实际上它没有标准答案。站在很多软件企业的立场上，项目 A 是一个理想的成功项目：按时间、按成本完成预先约定的任务。请注意，我用了&理想的&这个词，稍后我还会解释这个有趣的词，因为实际上的软件项目往往没有那么理想。
而如果换一个角度，站在客户的立场上呢？也许付钱购买软件的客户会有一些不同的想法。项目 B 从开始之后一个月便交付了第一个可工作的版本，从那时起客户就开始使用这个软件的部分功能，并且不断地把自己使用的感受反馈给开发团队。在真实的业务运营过程中，客户甚至发现了一种新的盈利模式，并进行了一次大规模的业务调整，这次调整的结果也直观地体现在软件项目中。虽然项目B的整体交付速率低于项目 A，但它提供的所有功能都是客户真正需要的，它们为客户提供实实在在的价值&&更不用说，客户提前好几个月就开始使用这个软件。
实际上，这是一篇关于软件价值的文章。和&成功项目&一样，对于&软件的价值&，不同的人也会有不同的定义。不过作为付钱购买软件的客户，他对于软件价值的定义是一目了然的：他能够从使用软件中创造多少价值，软件能够为他的业务提供多少价值，这就是软件的价值。或者说得更简明一点：
软件价值源自使用
这正是为什么很多客户青睐&项目 B&的原因&&我并不打算声称所有客户都有同样的观点，稍后我也会举出反例，但至少支持这一观点的客户不在少数。因为他们处在一个残酷而快速变化的商业环境中：他们的供应商在变化，他们的客户在变化，他们所处的经济环境和政策环境也在变化。这一切的变化迫使他们的业务也要随之变化。更要命的是，今天这个经济全球化的时代是一个&快鱼吃慢鱼&的时代，客户迫切希望新的软件系统为他们带来竞争优势&&哪怕这个软件系统尚未完成，只要能够投入使用。最后，客户对于新的软件系统究竟应该是什么样子并没有百分之百的把握，他们的想法往往要在真正使用软件之后才会浮现成型。几方面的因素加在一起，使得这些客户更愿意尽快开始使用软件、提出反馈、并不断完善软件，而不是提出一组需求、然后坐等几个月之后原封不动地拿到这些功能。
一个真实的案例
在 ThoughtWorks 的一个项目中，开发者们在项目开始之后一个月内就发布了第一个版本&&只有一些简单的数据采集功能。在发布展示会上，发生了这样的对话&&
开发者：这是我们的第一个功能。我们从文本文件、Excel 数据表和遗留数据库采集数据，现在我们的数据库中有这些数据&&（展示数据库结构）
客户：唔&&有意思。要是你能做这样一个查询（写出查询要求），得到的结果可能会有用。
开发者：可是我们的界面上没有地方做这样的查询操作。
客户：啊，我不需要操作界面，只要每天深夜做一次查询，把报表发到我的信箱就可以了。
开发者：这样吗&&另一个问题是，这需要花我们几天时间。
客户：不要紧，把别的任务往后放几天好了，我很想看到这份报表。
开发者：那好吧，下周我们就会开始提供这个报表。
猜猜结果怎么样？一周之后客户就开始每天接收这份报表，并根据报表内容做一些分析和决策。仅仅几个月之后，这份报表给客户带来的收益就已经超过了整个项目的投资&&这时项目其他部分的开发甚至还没有完成。
想想这个客户会怎么定义一个&成功的软件项目&？好吧，也许这个项目超过了预期的时间，也许投入了更多的人力，但这些并不意味着&项目失败&&&只是付出更高的成本。关键在于，他投入的这些成本能够带来多大的收益，他的投资回报率是否划算。对于这个客户而言，如果项目能够随时给他提供可用的、能够创造最大价值的软件，能够随时让&&就像故事中提到的&&这种有价值的想法得以实现，这就是一个成功的项目。
所以，亲爱的读者，请你忘记本文标题上出现的&敏捷&二字，我们在这里所说的不是别的，就是一种为客户创造最大化价值的软件开发方法。这样的方法有很多种，但它们有一个共同的特点：尽快、尽可能频繁地交付可以工作的软件，让客户尽快开始使用软件，从使用中创造价值、厘清思路、提出反馈。仍然以 ThoughtWorks 的项目为例，这些项目通常在启动开发阶段之后一个月内就会发布第一个版本，随后每一周或每两周发布一个新版本&&每个版本都是一个可以工作的软件，每个版本都比前一个版本具有更丰富的功能，并且每个版本都包含客户认为迄今为止最有价值的那些功能。用软件开发的&黑话&，&开发下一个版本&的过程叫做&迭代&，这些开发方法最大的共同点就是&迭代式开发&&&不是一股脑地交付全部功能，而是每次增加一点、渐进地交付最有价值的功能。
软件开发的梦想与真实
回到文章开始处的两个故事。我曾经说过，对于很多软件企业而言，项目 A 是一个&理想的&成功项目。那么，是什么让情况变得不那么理想？
答案是一个所有软件开发者耳熟能详的词：需求变更。在真实的项目中，客户通常不会等到最后一天再照单全收整个项目，因为他知道自己的业务正在发生变化。这时需求变更就出现了，伴随着来回的扯皮和讨价还价。更糟的是，大量的需求变更发生在项目晚期&&因为直到这时客户才真正看到、使用到这个软件，他的很多想法才真正浮现成型。随着这种&最后一分钟的需求变更&，项目超期、超出预算也就成了家常便饭。能够像项目A这样完工交付的，实在是凤毛麟角的幸运儿。
为了对付需求变更这个噩梦，软件开发者们还发明了另一个词：变更控制。这个有趣的词暗示着：需求变更是一种&不好&的东西，是需要&控制&的东西。然而站在客户的角度上想想，他在亲身使用了软件之后提出的要求，难道不是最有价值的东西吗？把这种真正创造业务价值的要求&控制&起来，难道是合理的吗？
在前面我也暗示过，并非所有的客户都一定青睐迭代式开发。那么，哪些软件项目不一定需要迭代式开发呢？从整篇文章的内容不难看出，如果客户的业务绝对不会变化，如果客户的需求巨细靡遗非常明确，如果客户不需要尽快开始使用软件以便收回成本，那么迭代式开发对他的帮助就会小得多。不过，如果读者认真思考的话，这样的例子也许并不多&&也许比你最初认为的要少得多。一个很好的例子是&神州六号&火箭使用的计算机控制系统。还有多少这样的例子？读者不妨试着自己想想。
如果我足够幸运的话，也许一些读者已经被这篇文章吊起了胃口：既然有这么好的软件开发方法，既然它能够为我们创造更大的价值，那还等什么呢，我们马上就动手吧。事情不会那么简单。为了让迭代式开发能够成为现实，为了确保尽快、尽可能频繁地交付，为了确保每次交付的都是最有价值的功能，我们&&包括软件开发者、软件企业和客户&&需要很多的改变。这里既有职责与权利的划分，也有开发过程和团队的重组，还有技术层面的实践指导。这些正是敏捷方法学所涵盖的内容。缺少了这些东西，&为客户创造最大价值&就只能成为一句空话。在后续的文章里，我们将结合 ThoughtWorks 的实践经验，逐步介绍敏捷方法的方方面面。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
软件价值源自使用
能否介绍一下，敏捷在产品研发中的经验？
Cao BaoZhen
交流最重要
Hailong Zhang
Re: 能否介绍一下，敏捷在产品研发中的经验？
Xiong Jeff
有个问题想交流一下
Re: 有个问题想交流一下
商务上的问题
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。}