软件质量管理(一)

 

软件质量管理

         质量保障的基本原则为进行最快的软件开发提供了重要的支持。当软件产品中有太多的错误时，开发人员修补它花费的时间可能比编写它所花的时间还多。我们都认为，最好从一开始就远离错误。远离错误的关键就是从第一天开始就注意执行质量保障的基本原则。

1 质量理念：

         质量和成本，是衡量一个项目成功与否的两个关键因素。成本可以在项目问消化，而质量却直接关乎到一个项目的成败；另外，通过对质量的早期控制，也能降低整个项目的开发成本。因而，对一个项目来说，质量是最为重要的。

         软件质量保证不仅追求“零”错误率，更应该使软件给客户带来实际效益。对软件企业而言，软件质量甚至是攸关企业生命。软件中一个很小的失误，都有可能给客户造成巨大的损失，而这个损失又会由软件开发企业自己来承担，因而可能会直接威胁到企业的生存。

         软件质量问题，往往被认为是看不见、摸不着的事情，很难准确去把握。实际上，现在的观点是，软件质量和普通产品的质量一样，是可以用定量指标去衡量的，也是可以通过各种手段去保障的。

2 质量保障原则

         质量要从项目一开始就进行控制。质量越早控制，项目整体质量就越高，成本也能降得越低。质量控制的越早，开发过程中出现反复的可能性也就越低，潜在的隐患也就会越少。而问题发现的越晚，付出的代价就会越大。宁慢勿错，宁用笨办法，也不用危险的方法。动作快虽然能够提高效率，但是也容易出错。而一旦出错，就会使开发过程出现反复，反而影响效率。

         在制定软件质量计划过程中，应把人的管理和应用放在首位，因为对软件质量的影响莫过于人的主观能动性，轻则消极怠工、重则离职跳槽，即便安心工作，然而人与人之间的沟通交流合作，其默契程度、配合方式方法也会导致效率与效益的下降或难以正常发挥；其次，需求分析的正确与有效也将直接影响系统的设计与实施，而需求分析的低效与错乱，归根结底也在于人，在于是否积极有效地和客户进行当面沟通，在于双方对需求的正确理解；第三，测试的局限性与到位程度，也往往在于测试人员对软件质量意识的薄弱和工作的认真负责程度，以及相关测试用例设计安排的合理性等主客观因素，当然软件人员的传统习惯、软件开发规范、开发工具等也会影响软件的质量。同时考虑到当前软件行业存在着严重的浮躁，不管从管理人员、需求分析人员还是设计、研发、测试、维护人员都从不同的角度表现出了浮躁的技术、浮躁的观点、更严重的是浮躁的心态，如果处理不好很可能迅速导致项目失败，因此在制定计划时也充分全面地考虑了此类问题的规避方法。

3 质量保障手段

    从主观和客观上两方面着手，进行有效的质量控制。

    主观上，让每个开发人员都自觉地去保证质量。自己承诺做过的事情，就应该保证在那一点上没有错误，如果出现错误，特别是多次重复，就会使自己失去诚信，所以出现一次错误，就会战战兢兢的，会不断努力，去避免错误。使得每个人都具有较高的质量意识。不只是考虑如何实现功能，同时会考虑怎么样去提高可用性、可靠性，及实现产品的人性化。

    客观上，从项目计划、需求分析、软件开发和系统维护等四个关键环节来进行质量控制。

3.1易错模块

    在项目开发过程中，特别重要的一个方面就是对易错模块的质量保证。易错模块是那些容易存在或多或少漏洞的模块。据统计：在一个典型项目中20%的模块包含了80%的错误。

    在新项目开始时，我们需要鉴别出哪些是易错模块并将其优先处理。如果模块的错误率达到每千行10个错误，就要回顾一下以决定是否需要重新设计或实施。如果发现模块是缺少结构化，过于复杂，或者过长，就要从最基础开始重新设计和实施。这样做，才能让你达到节约时间并改善产品质量的目的。

 3.2项目资源构成

         一个大的项目，往往需要很多人力资源，而一个公司通常无法在每个时间段都能保证这么多的人力资源，但不会以不足的人力而牺牲项目质量。项目组内，除了常规的开发人员外，还有专业质量管理人员，通过各种文档去分析各种规律，及时发现潜在问题，帮助项目组提高质量。除此外，还会预留人手，确保项目按质保量完成。

         要从思想上给项目组全体成员“洗脑”，让他们深刻认识到此次软件项目质量的重要性：该项目的成败决定着公司的声誉以及今后的发展。

         在实施过程中，成立了专门的软件质量管理小组，该小组独立对软件工程各个环节工作进行不定期的审计与监理，随时抽查包括需求、设计、编码、测试等各环节的工作实施情况，进行实时跟踪和评估，一旦发现问题以及潜在的隐患及时向相关负责人提出修改和调整要求。一定要保证他们工作的独立性，才能对于保证此项目的质量问题起到较大的保障作用，这样，各环节人员就能保证高度认真、时时谨慎。

 3.2寻求技术支持

    “术业有专攻”，项目在开发过程中如果碰到什么疑难问题，会积极寻求外部的技术支持。如碰到数据库性能方面的问题，会直接寻求数据库软件公司的专业技术人员，这样就会在较短的时间内寻求到很好的解决办法。3.3软件架构

         一个好的体系结构，是一个项目成功的基石。大多项目均建构在优秀的底层框架上，并根据项目特点，在中间件基础上再扩展出一套公共组件。这样既使得项目整体架构合理、概念清晰，减少发生错误的机率，也使得开发过程省力不少。

硬件相关代码的分层设计

     嵌入式软件开发的特点是与硬件密切相关，而嵌入式的硬件平台又千差万别，通常每一个嵌入式项目的软件开发，都需要从底层到顶层全部编写一遍，即便是同一个公司、同一个实验室，代码共享的程度都十分有限。这就导致了重复开发，非常浪费人力、物力。

3.4各种测试手段

    最寻常的质量保障实践就是勿庸置疑的实施测试和进行各种检查，即运行程序，查错，并看看发生了什么。两种基本的测试方法是单元测试----程序员检查他自己的代码是否工作正常，和系统测试----独立测试员检查整个系统是否如期望的那样正常运行。

    在质量保障实践中的测试与开发速度发生冲突时，它就可能由于拖慢了进度而被匆忙的完成，但常常它是间接影响进度的。测试发现产品的质量太低不能发布，要延迟到它有所改进后才能发布。测试因此成为传递影响进度的坏消息的信使。

    平衡测试和快速开发的最佳办法是在坏消息出现之前做好计划----设置对坏消息的测试，尽早地发现问题。

严谨测试：作为测试人员要做到以下几点：

（1）、明确自己的责任―――尽可能多的发现软件中的bug。

（2）、尽可能早的测试，这样会尽早的发现软件中的错误，便于修改，以免造成后期更高的维护成本。

（3）、测试前编写完整的测试用例，有计划、有目的的进行测试，尽可能用最少的测试用例，达到最高的测试效率。

（4）、不断的执行回归测试 测试人员测试出bug后，等开发人员修改后，要执行回归测试，以免因此次的修改造成其他的Bug。

针对外包软件特殊的测试步骤

（1）首先执行本地测试 （2）其次执行远程测试

    为了最大化测试效果，构建合适的测试环境相当重要，如开发环境，实际运行环境。实践证明，很多问题常常会暴露在特定的环境中。

3.5重视文档

         文档既是交流的重要手段，同时也是留存的证据，可以推进工作的流转，用于查找问题的根源，还可以进行各种统计分析工作。文档在软件项目中的重要性已经是尽人皆知，我们要重视文档和使用文档，把每个细枝末节都要以文档的形式记录，同时文档还使开发者不能掉以轻心，通过写文档也能让开发者发现工作中的问题。

开发文档的编写

     由于嵌入式开发的特殊性，这里所说的开发文档并不一定要像一般的软件工程管理中那样各个环节面面俱到。但是，适当程度的开发文档还是十分必要的，它们和程序中的注释结合起来，才能够确保程序的可维护性。一个软件项目最低限度维护下列文档是很有必要的：¥ README：整个项目结构、功能的说明；¥ INSTALL：配置、编译该软件程序的说明；¥ FILES：本项目所包含的源文件tree及说明；¥ HISTORY：本项目的软件开发的历史记录。此外，如果一个嵌入式软件项目自成模块，且面对最终用户的话，另外编写一份较详细、全面的项目报告是有必要的，最好还有一份步骤清晰的用户手册(Step-bystep)。

3.6 加强沟通

         软件外包通常是不会外包需求、分析和设计阶段的。这样造成接包方和发包方对需求、分析和设计在理解上的分歧，从而导致设计或编码的不断变更。

         因为大多数情况下，如果某公司要制作一款软件会将其外包首先给比较有实力的大软件公司。而大软件公司为了节约成本，会将此项目中的部分模块或某个项目阶段转包给其他的软件外包公司。总公司负责接包，然后再将项目发到下面分公司进行最终制造。可想而知这里面一共倒了多少次手了，有的时候甚至到某开发公司手上的项目已经是三包四包了。项目小点还好说，如果是一个大项目，发包方要和接包方进行频繁的交流，大量的信息经由三四个节点的传输很难说不会变形。

这时就需要开发人员加强沟通，相互探讨，共同完成。这里引申出了协同开发——这点在现代的软件企业是很重要的一点。3.7控制版本发布后的错误修改过程

    当程序经过测试并发布后，对程序的修改将被严格控制起来。当实际运行中再发现错误需要修改时，首先由开发方提交程序修正申请，填写修改的原因、修正对象、方案、影响范围、需要的时间等。申请由项目负责人和客户一起讨论并批准后，将要修正的程序返回给开发人员进行修改，修改完成后需要对牵涉到的地方进行严格的再测试，填写各种文档。填写的文档进行审查确认无误后，项目负责人与客户商谈合适的发布时间再进行重新发布，确保尽量减少损失。