软件质量的商业价值(zz)

　业领导人常常将软件质量视 为一种奢侈－－如果有必要的话，为了更多的功能、更快速的开发或者更低的成本，其可以被牺牲。然而，在实践中，如果软件开发组织对质量有一个坚定的承诺， 实际上可以加快开发，减少成本，并更容易地增加新的特性。开发出低质量软件的组织，无论是为了内部使用还是为了销售，总是会逐渐变糟，在“已完成”产品的 缺陷修复上花费时间和金钱要比从一开始就修复缺陷多出很多倍。相反，一个从开始就加强产品质量的组织，是有远见和创新精神的；可以将其资源用于追逐新的机 会。交付质量也是对市场的一个有力区分，市场中的高质量软件将更具竞争力。

　　当你回过头来评估你的组织中的软件开发工作的全面状况时，你看到了什么？有没有关注在质量上？这种关注在哪些地方比较固定，在哪些地方比较松懈？事实上，质量不是一件事情；它就是质量。它意味着，应当在你的过程中关注每一个步骤。理解这个，是创建一个真正成功的应用软件交付过程的关键。

　　但是你从哪里开始呢？尽管要求更好质量的下意识反应就是扩大测试团队，但是这可能不是最好的方法。作为替代，你可以开始将你的组织中的思维倾向转到关注质量上，这种努力需要来自最高管理层的支持。本文将讨论把对质量的关注投入到一个组织中所带来的益处，同样也将讨论用以支持此关键变革你可以采取的步骤和可以使用的IBM工具。

　　定义质量

　 　对于任何一个组织，定义什么是你理解的质量含意是重要的第一步。软件开发组织经常按照一种不精确的、概括的质量观念来运转，并且容忍了大多数工程学科不 能允许的缺陷。相反，一种所有团队成员都可以理解和接受的质量的可靠定义，会促进对细节的完全性和关注。在商业应用软件领域中，我们可以根据目标受众：软 件用户来最好地定义质量。关注质量的开发组织知道，一个“质量合格的”软件一定比仅仅提供正确而不完全的结果付出更多的努力。应用软件满足涉众的需求吗？ 它可用吗？安全吗？可升级吗？可靠吗？容易维护吗？容易扩展吗？监控简单吗？

　　James Juran 的定义提供了一个好的出发点：质量是“适于使用的”。 Juran 还说，一个产品除非既增加了消费者又增加了生产商的价值，否则就不是高质量的。

　 　与略有不同的是，质量包括增加的价值加上对细节的关注。一个豪华汽车和一个入门级汽车都可以将你从A点带到B点。但是豪华汽车提供的特性和性能，远远超 过了基本的运输功能：可用性，安全性，舒适性，可靠性，等等。产品质量也反映了产品背后的过程。在软件世界中，一个高质量的过程可以使开发组织避免失去返 工、重新分解和重新编写软件的时间。这些组织可以产生更加创新的和更具创造性的产品，因为他们有更多的时间来思考增加价值和质量细节。

　　完成质量结果需要在整个开发、集成和测试过程中应用一个高质量的过程。同样，这可以很好地应用到其它项目中，包括封装的或自产的应用软件，升级的开发工作，以及扩展、集成和现代化遗留的应用软件（见图1）。

图1：所有软件开发方式都要求对质量的关注。

　　关注质量的商业利益

　　正如Juran的定义所暗示的，不仅是顾客受益于对高质量的关注。价值质量更具有响应和创新的能力的业务，增加了他们的企业竞争力，并极大地减少了他们的开发和所有权的成本。让我们进一步看一下这些利益。

质量带来响应力和创新

　　成功的组织认识到持续创新和竞争差别的重要性，这要求对经常变更的商业前景做出快速的响应。软件的灵活性和可塑性使组织能够做出这种快速的响 应，并且将软件开发奉为一个核心业务过程的组织将快速地走到群体的前列。然而，软件的最大优点也是使得它变得脆弱的地方。对应用软件的一个小的变更可以带 来一次缺陷，从而降低整个系统，并且削弱业务。明白这一点，软件开发团队有时会采取一种“稍后再修复它”的心理；他们会带着他们知道有缺陷的产品继续前进 －－这是没有其它工程学科会允许的随意性。

　　当 IBM 的 Global CEO Study 2004 2 接见全球450多个CEO，讨论他们当前的战略问题、目标和关注点时，他们将“响应力”列为他们的第一个目标，紧接下来的是“新的，差异性产品”，“运作 效率”，以及“改进的商业模型”。这些目标都是与IBM的随需应变（On Demand）商业模型一致的：在今天的环境中，业务需要快速而有效地创新、作出反应，以与竞争对手有所变化和差异。如果一个组织的内部软件系统有缺陷， 或者如果产品开发团队经常在努力修复去年发布版本的问题，那么业务就不可能达到这些目标。

　　要成功地在随需应变的世界中运转，业务必须在开发和维护它们依靠的软件系统时，对质量保持激光似的关注；质量系统使得业务快速地反应、适应和部署新的解决方案，并且维持一种竞争优势。

　　质量是一种差异

　　作为一门学科，软件开发的质量标准远低于其它工程学科的质量标准。管理人员和开发人员都善于使他们产品的缺点合理：他们说，他们提供的功能是“ 比没有更好”，或者“比以前的系统更好”，并且万一系统崩溃了，还可以用手工来代替。但是建筑工程师会用类似的方式来解释一个建筑物倒塌的原因吗？如果一 个控制仪表板在飞行中发生故障，航空工程师会只是耸耸肩吗？要有效地支持一个业务，软件工程师也必须转到零缺陷方针。

　　更高质量的软件能在市场上对公司产生什么差别呢？考虑一下十九世纪六十年代末期和七十年代的汽车工业。日本汽车制造商采取了一个严格的质量保证 （QA）程序，并且立即得到了生产高效的、良好设计的可靠汽车的声誉。这种上好的质量使他们的产品脱颖而出，并提高了（汽车）工业的质量基线。这也让日本 的汽车制造商进行更进一步地创新，包括在燃料功效、安全性和制造过程方面，这些都是他们的竞争者要追赶的地方。

　　同样地，当任何产业中的任何公司生产更高质量的软件时，要么是为了内部使用，要么是为了外部销售－－同时提高了门槛。一个组织的内部人力资源、 财务和客户关系管理系统的质量会影响到公司的业绩，这比外部销售的产品更难以量化，但业务效果是同等重要的。事实上，高质量的内部系统可以是一种业务差 异。IT 组织通常购买应用软件用于自动化普通的业务功能，并只构建仅仅用于他们的业务的软件和系统。如果那些单独的系统也是高质量的，那么业务将会具有相对于它的 竞争者的优势。

　　质量是免费的（几乎）

　　由美国商业部门的国家标准和技术机构（NIST）委托的一项研究发现，软件缺陷使美国经济每年付出近600 亿美金的成本。研究也发现，大约百分之八十的软件资金都被软件开发人员确定和纠正缺陷消耗掉了。在另一项研究中，Standish 组织报告，每年被取消的软件开发项目花费了组织550亿美金。很明显，糟糕的软件质量－－和糟糕的软件开发过程－－是商业利益率的最大消耗。

　　导致高成本低质量的结果根据根本原因而不同。例如，低质量问题领域分析－－和从而产生的低质量需求－－会导致没有计划的和高昂成本的返工。直到 最后一刻不可避免地通过测试来确认质量，既延长了进度，也扩大了预算。并且如果顾客不能访问你的系统或业务不能进行工作，那么由可靠性或性能问题引起的运 作停工就会招致机会成本。其它根本原因包括：一个与员工工作不一致的定义糟糕的过程；没有或有限的构架和代码QA；有限的部署后的追踪和评估。

　　但是什么是高质量的成本呢？专家Philip Crosby强调质量是免费的。理论上，一个软件开发组织有这些特点：

　　一个团队成员没有异议的定义明确的过程。

　　将注意力集中在增加价值的特性、细节和跨生命周期的质量上的团队成员。

　　经常评价最终用户的反馈以确保产品线的更新和满意的顾客的管理人员。

　　尽管使一个组织有效运转的无形事物－－良好的管理，有效的人员配备，一致的过程，等等－－要求在管理时间、计划和培训方面有先期投资，但它们不会招致额外的财务费用。

　　一个通常的关于质量的误解是，你可以换掉它来改善开发速度，减少成本，或增加功能。太多的人实际上相信Meskimen的半开玩笑的质量定则： “没有时间正确的做它，但是总有时间做完它”。然而，实际上，大多数的组织发现，相反的是对的。最后，正是改善的质量使得团队能够按时，以较低的成本和更 多的特性交付更多的项目。一个持续保证质量的开发团队第一次就做对了。如果你在整个开发过程中消除缺陷，你也消除了稍后需要查找和修复那些缺陷的时间和成 本。

　　从上至下驱动质量

　　持续保证质量要求承诺和贡献，这是从商业领导高层至下驱动的。尽管你的方法论不需要与组织改进方法论一样正式，例如六西格玛（Six Sigma）或全面质量管理（Total Quality Management），但是它要求与更正式的方法论所需要的同样的领导和组织复杂事务的管理能力。 6 质量改进本质上是一种思维习惯问题；当来自上层的管理人员在整个组织慢慢灌输质量文化时，质量就会渗透到每个项目中。

　　在这样一种文化中，工作会给管理人员提供极大的好处。他们不再必须考虑带有已知缺陷的发货产品的后果。并且，促使产生质量的严格过程、团队责任 心和目标矩阵也创建了可预言性。与不断地重新确定项目范围并且仍然错过期限不同，团队可以精确地确定范围、估算和确定时间，并且舒适地承诺按时和按照规格 说明的交付。

用正确的过程和平台实现质量

　　建立一种面向质量的思维习惯是最高管理层的职责，但这需要软件开发组织采用并执行此思维习惯。IT必须包括正确的过程和工件，并寻求正确的指导或培训，以产生管理、客户和最终用户正在寻找的结果。

　　在RUP流程中支撑质量的战略和IBM工具

　　IBM提供一个完整的方案以帮助开发团队构建更高质量的软件：IBM软件开发平台。这个开放和标准的平台包括IBM软件的许多工具，包括IBM Rational统一过程，或RUP。这种自动化过程指导使软件开发的最佳实践具体化，这些最佳实践包括迭代化方法、变更管理、可视化建模和持续质量保证 过程。

　　RUP的迭代阶段强调一个或多个核心过程流：分析、设计、开发、测试和部署。每个阶段和每个流程都强调关注质量和寻求帮助团队来识别开发生命周 期中的早期问题，这时问题最容易解决。以下部分检验了RUP和IBM软件开发平台中的工具如何支持每个过程流中的面向质量的实践。

　　分析

　　Meta Group 报告，引起客户不满意问题的百分之八十可以追溯到对需求的糟糕理解上。对于任何软件开发项目－－不论是新的应用软件开发，打包应用软件集成，或遗留系统更新－－质量开始于分析业务，以确保系统需求清晰且准确地反映了业务和客户需求。

　　如果一个客户写满了一排需求，这就足够好吗？可能不是，因为理解这样一个需求列表很可能需要领域知识，你只能通过大量的经验来获取这些知识。由于构建的软件的人通常不会在领域世界中工作，因此需求必须按照一种他们可以理解的方式来编写。

　　此活动的工具包括IBM Rational RequisitePro，这是一个需求管理工具，可以使团队清晰地文档化需求（使用Microsoft Word），同时具有数据库的分析性能，可以执行需求分析、覆盖和变更。

　　要定义最佳的、基于需求的业务过程，以驱动你的应用软件开发，你可以使用IBM WebSphere Business Integration Modeler，这是一个帮助你设计、测试和沟通复杂业务过程的工具。它模拟了过程的运行效率，并分析可能的业务结果，同时，IBM WebSphere Business Integration Monitor显示多种环境的实时信息，允许决定性的业务性能的管理和优化。

　　设计

　　在设计中，主要的质量集中在构架上，这是软件的“灵魂”。低质量的构架会引起大范围的质量问题，包括（软件）脆弱，缺乏升级，以及难以修改。这 些问题随着应用软件项目不断发展，变得越来越难以解决；并且随着应用软件从设计到开发、测试和部署，纠正缺陷的成本以指数在增长。如果软件开发人员可以有 效地发现、隔离和解决设计和开发期间的结构上的不足，这项工作会在整个项目期间获得受益。开发人员也应该确保，软件是按照一种保持构架完整性和灵活性的方 式来实现的，因此，随着业务需求变化，开发人员可以快速地进行变更。

　　针对此工作流程的工具包括IBM Rational Software Architect，可以使软件构架师和高级开发人员能够创建应用软件的高质量构架，并使用UML进行模型驱动开发。IBM Rational Software Modeler包含Rational Software Architect的一些特性，专注于确保需求规格、构架和设计可以通过UML被清晰地定义，并与涉众进行沟通。这两个产品都可以帮助团队改善他们对系统 的理解，并节省时间出来关注在设计和以后工作期间的质量问题。

　　开发

　　平均起来，开发人员在他们写的每千行代码中会产生100到150个错误。当然，这个数量随着开发人员和项目不同而不同。即使只有一小段代码，产生百分之十的错误也是很严重的，一个相对小的应用软件的2万行代码将会大概产生200个严重的代码错误。

　　像这些部分是适合统计学的，开发组织近些年来将很大的重点放在开发人员主导的测试和分析上。这可以由“敏捷”实践所概括，其认可测试先行开发 －－在你编码之前构建测试。尽管单元测试和运行时分析已经变得更为主流，但是许多管理人员仍然有这样的误解，即这些过程向时间表中增加了不必要的时间。事 实上，时间表通常会延长，这是由于在QA或客户发现问题后，开发人员在生命周期中调试代码后所花费的时间。对于那些想要减少风险和增加可预测性的团队来 说，开发团队采用一种良好结构的、主动的QA方法是一个好的解决方案。对于Java开发人员，IBM Rational Application Developer for WebSphere Software对这种方法提供了全面的支持。它在一个用于构建、测试、集成和部署应用软件的单一的、集成的开发环境中，合并了Java、Web和企业级 开发工具。IBM Rational XDE Developer也为Java和.NET软件设计师和开发人员提供了一组丰富的模型驱动开发和运行时分析性能，用于构建基于Eclipse平台和在 Microsoft Visual Studio .NET环境中的高质量软件。IBM Rational PurifyPlus有一套自动化的、运行时分析工具，用于改善应用软件可靠性和基于Java、C/C++、.NET和Visual Basic语言。

测试

　　管理系统级功能和性能测试是持续保证质量的一个主要部分。执行这些测试的质量工程（QE）团队，在验证应用软件实现客户需求或业务规则方面，扮演了一个支持客户的角色。

　　一个开发组织既不应当过分强调，也应当减少系统测试的重要性。保证质量不只是QE团队的职责；测试也不只是QE的唯一领域。某些测试可以并且应当由开发人员来运行，在某些情况下，可以由构架师来运行。

　　不幸的是，许多组织将QE团队成员视为bug清除者，在生命周期后期将他们放在一个应用软件上，让他们去查找其它团队成员引入的缺陷。然而，单 独测试也不能创建质量。如果测试不足的应用软件检查出构架上的缺陷和bug，而这些都应当在单元测试期间就被识别和消除掉，那么在生命周期晚期的系统和性 能测试就不会有效。同意地，如果没有自动化工具，QE就不能期望有效地测试。为了最有效地测试，QE团队必须在他们关注系统级质量问题时，能够应用合适的 测试工具。

　　想要改善他们的手工测试工作的速度、广度和可靠性的测试人员和业务分析师，应当考虑IBM Rational Manual Tester，这是一个手工测试创建和执行工具。IBM Rational Functional Tester是特别适用于QA专家的一个工具，QA专家执行Java、.NET、WEB和基于终端应用软件的功能和回归测试。并且测试人员和IT专家可以 使用IBM Rational Performance Tester，一个负荷产生工具，在将它们置于真实世界用户负载下之前确保基于Web应用软件的可扩展性和可靠性。

　　部署

　　业务应用软件必须要持续运行。即使最完全的过程，也不可避免地会产生功能性和可靠性错误。如果应用软件满足或超过了服务标准协定 （SLAs），IT团队就必须承担保证质量的职责。通过持续地监测和评估，团队成员可以确保一个已部署系统的生存能力，并迅速地发觉和纠正性能问题。

　　IBM Tivoli Monitoring 产品可以帮助IT团队检测出瓶颈和潜在的问题，并且也可以提供危险情况下的自动恢复。IBM Tivoli Monitoring for Transaction Performance提供Web和企业结构上的性能管理能力。并且IBM Tivoli Provisioning Manager可以在测试和产品环境下，自动化进行供应和配置服务器、操作系统、中间件、应用软件、存储区和网络设备这些任务。

　　支持保证质量的团队职责

　　质量是开发团队中的每个人的职责，但是它也是团队作为一个整体的职责。在一个迭代的过程中，每个迭代本质上都是一个循环－－每个流程从另一个流 程接受输入，并对另一个流程提供输出。在高级别上，这个循环确保了每个工件质量的持续的重新评估。团队必须做他们可以做的任何事情，来集成工作流，建立可 追溯性，并简化沟通。对连接团队成员的链条的破坏，会导致数据丢失、返工、缺乏透明、没有效率－－并且最终会导致较低质量的软件。

　　IBM Rational Team Unifying Platform是一套完整的基本工件和过程，可以通过对开发资产、通信警报和工作流过程提供共同的访问，来统一开发团队。除了我们前面描述的RUP和 Rational RequisitePro之外，这个平台包括了完整的工具集，软件配置管理，变更管理，测试管理，以及使需求能够在整个开发、分析和测试中可追溯的报告。 软件配置管理解决方案集成了IBM Rational ClearCase产品家族的软件资产管理和IBM Rational ClearQuest家族的缺陷和变更追踪。有效的软件配置管理是保证质量的一个基本工具；它帮助组织确保软件构建是可重复的和可靠的，并且保证缺陷和变 更请求得到正确的管理。

　　IBM Rational Team Unifying Platform也包括IBM Rational TestManager，其提供了来自一个单一集中点的所有测试活动的控制、管理和报告。IBM Rational ProjectConsole使管理人员能够更加接近质量控制；它使用由开发环境自动收集的数据，动态产生一个项目Web站点和矩阵板。并且IBM Rational SoDA自动地产生和维护全面的项目文档和报告。

　　IBM也提供了许多服务，帮助开发团队交付高质量软件。团队成员可以被提供指导性的和基于Web的培训课程，这些课程都通过IBM developerWorks Web 门户，集中在工具使用和技巧改进上。并且专业服务咨询可以与开发团队一起创建定制质量实施计划，生成初始的项目评估、安装、指导、培训和维护。

　　获得软件高质量的高收益

　　当人们考虑需要什么来构建任务紧迫和高安全性的软件时，他们常常想像需要一个复杂的过程，带有监督、标准、正式手续和文档。实际上，有许多种方式来达到质量，而不是一定要有一个强壮的过程，例如全面质量管理或六西格玛。

　　质量改进，如软件开发，是一个迭代的过程。你不需要一步就完成所有的事情。即使是小的变化－－包括调整你的组织中对质量的看法－－也会产生一个切实的差异。尽管你不需要一个繁重的过程来达到质量，但是你需要一个关注质量的组织思维倾向，并且这必须由最高管理层驱动。

　　在你的软件开发生命周期的所有阶段中，包括面向质量活动的商业利益，这些度量不仅可以通过增加可预测性、减少风险和消除返工来促进创新和较低的 成本，而且他们也可以有助于你的业务有别于你的竞争对手。最重要的是，持续保证质量总是会比忽略考虑质量成本要低。事实上，提高产品质量基本上没有成本， 如果你正确地做的话。