软件质量管理实践研究报告.docVIP

软件质量管理实践 ——软件缺陷预防、清除、管理实用方法前言 故事发生在2001年初，周一早晨，新上任的质量保证部经理召集部门的全体人员开会。当时该部门有8个测试人员和5个文档、3个美工。对于一个刚刚成立的拥有员工70多人的软件公司来说，该部门人员占比达23%之多，其投入的规模和同行小公司相比不算小。与会过程中，就软件质量问题，大家各抒己见。 经理说：“公司自从转向软件开发以来，开发工作开展很顺利，我们质量保证部主要工作是测试，尽快、尽多、尽早地发现程序中的错误，保证开发出来的产品质量，其责任重大。” 测试工程师甲说：“缺陷就是Bug，程序员开发完产品后，咱们测试人员尽可能多地发现其中的Bug，遗留在产品中的Bug就会越少，产品质量就会越高。” 测试工程师乙说：“只要我们发现了所有的Bug，让程序员改正过来，我们就可以放心地对用户说，我测过的软件你放心，绝对不会再有质量问题。” ……. 会议在经理的主持与分配任务中告一段落。 上述对软件产品和软件产品质量的说法，从事软件研发的人可能都听到过。相隔7年之后，回首往事，仔细思考一下，其中类似说法有多少是完全正确的呢？软件质量真的像他们说的那样吗？ 在20世纪90年代中期，几次著名的分析都得到了相同的具有普遍性的结论，即软件项目的成功率非常低。著名的观点如，软件开发仍然具有高度的不可预知性，只有大约10%的软件项目在最初估计的预算和进度内成功地交付；与其说管理规范是技术进步，还不如说是成功和失败的鉴别器；软件废品和返工的程度是不成熟过程的象征。 目前，随着软件工程技术的不断发展，人们已经逐渐认识到，软件质量是多方面的活动协力构建起来的，由软件开发整个过程的质量所决定，质量问题不是仅仅通过测试就能发现并解决的。大量实践证明，软件产品与传统产品有着不同的特征，如不可见性、灵活性、复杂性等，所以软件缺陷的预防自始至终是重要的，广义的软件开发质量保证活动，更多地强调软件缺陷的预防、及时发现与剔除。 因此，不像建筑工程那样精确地衡量、计算出每一元钱在软件产品中是如何花费的，软件开发过程的控制和软件质量也要远比其他工程制品的管理复杂得多。 那么，什么是“软件产品质量”呢？ Crosby将质量定义为“符合需求”，而Juran认为是“适于使用”。质量的这两个定义相互关联，已经被人们广泛采纳和使用。 “符合需求”隐含着需求必须明确陈述出来，使之不被误解。在开发和生产过程中，不断进行度量以确定对这些需求的符合性。不符合需求就被视为缺陷。 “适于使用”更多地考虑了客户需求和预期的作用。由于不同的客户会以不同的方式使用产品，产品必须具有适合使用的多种要素，这些要素的每一个都包含有质量特性（适于使用的参数）。最重要的两个质量特性参数就是设计质量和符合性质量。 由于生产者坚持将“符合需求”以及将客户满意度作为质量的最终验证标准，质量的定义实际上分成了两级：狭义的质量（“小q”），即内在产品质量，包括了缺陷率和可靠性；广义的质量（“大Q”），则包括了产品质量、过程质量和客户满意度。 总之，软件产品质量一般都指利用适当的资源为用户提供能满足要求的产品，达到用户满意。软件质量评价要素主要包括： 功能性； 可靠性； 易用性； 效率； 维护性； 可移植性； 正确性； 健壮性； 完整性； 安全性；? 可用性；? 可理解性；? 可测试性；? 可再用性等。 软件质量始于开发人员本身，如果任何程序模块都存在大量缺陷的话，就很难去测试且需要花很多时间才可能集成到较大的系统中，甚至还会给用户带来很多麻烦。不良质量也会导致进度问题，有缺陷的产品交付期会较长。经过测算，大多数的软件专业人员在开发和最终测试期间，花费近一半的时间来测试并修复他们的产品。 当写一些小程序时，大多数人都会有很高的生产率；而一旦开发较大的程序时，生产率会急剧下降。虽然开发较大的系统还涉及一些额外的架构和设计工作，但大多数增加的工作量还是由缺陷引起的。随着程序的增大，平均花费在发现和修复每个缺陷上的时间会以指数级增加。然而，如果我们能够自始至终地编写高质量的模块化程序，就会生产出更好的产品并且提高生产率和组织效率。 因此，为了保证软件产品质量，需要进行以下一系列的工作。 （1）定义质量需求，明确本产品的质量目标。要明确影响本产品质量的缺陷可能有哪些，如何避免。 （2）定义质量管理过程，采用软件工程的方法管理开发过程，可通过审查/评审/测试/验证等手段来贯彻落实“早预防、早检查、早控制”的保证质量策略。 （3）建立一个能尽早面对风险的迭代式的生命周期过程。 （4）定义每个过程成果的质量要求/质量标准，加强软件的测试。 （5）签订合同，确定客户方相关负责人、责任以及权利，并加强和客户的沟通，了解客户真实的要求和潜在需求。 （6）将过程建立在构架优先方法的基础上，同时设