软件质量管理论文15篇.docx
《软件质量管理论文15篇.docx》由会员分享，可在线阅读，更多相关《软件质量管理论文15篇.docx（43页珍藏版）》请在冰豆网上搜索。
软件质量管理论文15篇
软件质量管理论文15篇
软件质量管理论文
摘要：
软件产品的质量在很大程度上受到软件开发过程的影响。
为了提高竞争力、改进质量以及提高效率,软件企业就需要将更多的注意力放在过程上,通过过程控制其结果。
本文对软件质量管理过程进行了研究,通过过程性能基线和过程性能模型分析和管理质量,提出了一个基于过程性能模型的软件质量管理过程模型,并在研究的基础上,构建了软件质量管理系统的体系结构。
关键词
软件质量管理软件论文软件
软件质量管理论文:
软件质量管理体系研究
[摘要]随着软件行业的发展，软件质量越来越成为人们关注的焦点。
本文从软件质量管理体系出发，结合笔者自身多年的软件质量管理经验，对现有软件质量管理体系进行了总结和归纳，提出了软件开发过程中质量控制的具体改进方法，并将全面质量管理观念融汇于实际软件质量管理日常事务之中。
[关键词]软件质量管理体系改进全面质量管理持续发展
一个开发团队要提高效率，就需要思考目前的管理活动中有哪些要素是可以改进的:
如何把一些事务性的操作变得自动化，从而节约人力;如何找到更好的方法，让开发过程更为合理，更注重软件的质量;如何在团队中传播优秀的思想，让团队成员不断地学习和进取，自发地改进过程。
这些美好的愿望几乎是所有方法论和各种认证的共同心声，但要完全做到可就太难了。
在本文中，提出了一些优秀的实践，优秀实践均是来源于软件开发界中的一些新思路和新理论，它们能够为以上愿望的达成起到正面的作用。
在组织中引用这些实践决不是一个容易的过程，但它们确实非常有效。
这些实践包括：
建立日创建、测试驱动开发、建立核心框架和面向组件进行编程。
一、软件开发的有效管理:
日创建
一个组织应当拥有一个有效的工作流程，这个工作流程能够指导软件开发的进行。
这个流程应当是具体的、可操作的。
随意的计划和从来不遵循的进度决不是一个有效的工作流程。
日创建实践提出了一种对开发过程进行精细管理的方法，它是量化软件管理的基础。
有了日创建，你会发现计划的制定和进度的监控是非常容易的一件事情。
我们传统开发软件的流程一般是这样，理解领域问题，然后分配任务，由不同的人负责不同的软件部件，在开发完成之后，再把各人的部件整合起来，形成完整的软件。
这个思路看起来并没有什么问题，但是在实践中却问题多多。
首先，这种方式适合开发人员之间工作彼此没有交集的情况，以前这种现象很常见，但是现在，随着软件规模的扩大、分工合作的加深，开发人员间的相互依赖程度越来越高，这种清晰的职责划分已经变得越来越难了。
其次，在软件集成时，往往会出现各种各样的问题，可是却很难发现到底问题在哪里？
公说公有理，婆说婆有理。
每个人的代码都没有问题，结合到一起就出现大量的问题。
所以日构建就将平时难得一见的集成工作转换成频繁进行的一件工作，从而使得原先如同噩梦般的集成变成了一件简单的工作。
这也是很容易理解的，如果集成工作几个月才进行一次，谁能够记起几个月前的细节呢？
但是如果集成以天，甚至以分钟为单位进行，排除bug就变成一件很容易的事情了。
二、测试驱动开发
软件质量的根源来源于测试，测试做好了，软件质量就会好。
这是毫无疑问的。
问题的关键在于怎么做测试，才能保证测试的投入能够带来软件质量的有效提升。
测试驱动开发正是为了解决这个问题而出现的。
它不是一个完整的方法论，可以和任何一种开发流程进行融合。
测试驱动开发不但能够改善测试效果，还能够改进软件的设计。
测试驱动开发起源于XP法中提倡的测试优先实践。
测试优先实践重视单元测试，强调程序员除了编写代码，还应该编写单元测试代码。
在开发的顺序上，它改变了以往先编写代码，再编写测试的过程，而采用先编写测试，再编写代码来满足测试的方法。
这种方法在实际中能够起到非常好的效果，使得测试工作不仅仅是单纯的测试，而成为设计的一部分。
在编写程序之前，每个人都会先进行设计工作。
可能有些人的设计比较正式，绘制模型，编写文档。
有些人的设计只是存在于脑海之中。
且不论设计是精细还是粗糙，你都为随后的编码活动制定了一个标准。
这个标准的明确程度和你的设计的细致程度有关。
但应该承认，这个标准是不够细化的。
因为你的设计不可能精细到代码级的程度。
而标准不够明确则会产生一些问题，例如，在编写代码的过程中，你还可能会发现原先的设计出现问题，从而中途改变代码的编写思路。
这将会导致成果难以检验，进度难以度量。
既然以设计为导向的标准不够明确、不够具体。
那什么样的标准才是合适的呢？
只能是代码。
因为代码是最明确、最具体的。
所以测试优先的本质其实是目标管理。
编写测试代码其实是在制定一个小目标。
这个小目标非常明确，它规定了你需要设计的类、方法，以及方法需要满足的结果。
这些目标制定完成之后，你才开始编写代码来达成该目标。
测试的目标要比设计的目标粒度更小，但是成本上却更为经济。
测试优先是软件开发中一种细粒度的目标管理方法，通过明确的目标，推动软件开发的进行。
三、建立核心框架
框架是一种具有高度重用性的软件，这个特性决定了它非常适合成为软件组织积累知识的一种有效手段。
传统的知识积累的方法是文档，但是文档容易产生歧异，开发人员往往也不愿意去阅读和理解文档。
框架提供的是一种综合的手段，包括文档、模型和代码。
更容易理解，更重要的是，开发人员必须在日常的工作中使用框架，这使得他们对框架中的知识非常熟悉，并根据工作的需要来改进框架。
四、面向组件编程
有效的组织在于有效的分工。
体力活动容易进行分工，脑力劳动则比较难，而软件开发似乎就更难了。
所以，长久以来我们都习惯采用以功能块为单位的粗粒度划分方式。
面向组件编程采用更加细密的划分方式，并以服务作为组件之间相互依赖的契约，不但定义了组件和组件之间的关系，也规定了组件开发者、组件使用者、组件测试者的权利和义务。
从而能够进行软件开发工作的分配、管理、QA等工作。
软件质量管理论文:
软件质量管理6大最佳实践
软件形式上是产品，本质上是服务，是高科技计算机信息技术和人类创新智慧的结合。
在软件产品的研发过程中，软件质量一直处于最为核心的地位。
ISO9001标准和CMM原则被誉为软件质量管理的圣经，是当今国际上最推崇的软件质量改进方法和保证措施。
然而，很多实施ISO9001、CMM3级的企业过于强调过程管理，忽略了“人比过程更重要”这一原则，形式重于实质，这一做法在国外已受到猛烈抨击。
如何更好地将质量管理理论和企业经营生存之道密切融合，走出一条独辟蹊径、立竿见影的“质量革命”之路，是摆在诸多企业高管面前的重要课题之一。
这里总结了软件项目质量管理的6大最佳实践，供同行参考。
全面管理，塑造质量文化
全面质量管理即为全员、全过程、全方位的质量管理，它具有以下基本特点:
1．全员:
质量控制从少数质量保证人员扩展到企业的所有人员。
质量控制管理不是质量保证部门一个部门的事情，需要全员的大力支持、准确理解、精确执行。
2．全过程:
将质量控制、质量检验、质量统计延伸扩展到整个产品生命周期。
3．全方位：
全面运用一切有效方法，全面控制质量因素，如软件开发成本、进度、可靠性、安全性等。
全面质量管理可以归纳为两大基本原则:
首先是以满足顾客需求为导向，不断改善，最终实现顾客的全面满足；其次是以全员参与为基础，进行全过程的质量控制。
质量管理理论认为，“质量出自计划，而非出自检查”。
软件前期的质量保证主要依靠设计、生产、研发，后期的质量保证则主要依靠测试、完善、改进。
全过程的质量保证依靠行之有效的管理体系。
这种观点强调运用确定性、过程化的管理制度、程序、体制来控制管理潜在诸多不确定性、多变性因素的软件质量品质。
事实上，影响软件项目进度、成本、质量的三大因素分别是人、过程、技术，人永远是第一位的，人永远比过程更重要，人是影响质量的最关键因素，只有在软件质量管理过程中坚持“以人为本”，强调人与过程的和谐，塑造以人为核心的质量管理文化，才能让质量管理的成效得到淋漓尽致的发挥。
分级管理，把握
质量目标的层次性
ISO9001体系认为，建立质量方针、质量目标是实施质量管理的必经之路。
事实上，现代软件的架构是层次化的，这一点尤其重要，软件质量也应按照层次从里到外、功能由轻到重、地位从低到高因地制宜、区别对待，对于不同的软件层面和需求制定不同的质量目标。
例如:
对于一个大型网络游戏而言，大气炫丽、细腻仿真的3D动画操作界面是非常必要的；但对于一个小型超市仓库管理软件而言，只要能满足出库、入库、损益、盘点的基本需求就可以了,简单粗糙的操作界面反而更容易上手。
在进行软件工程的质量控制时，应把握关键层面，抓住质量控制的瓶颈。
一般来说，越是靠近底层、核心区域（如平台、框架、引擎、关键业务等）的代码质量要求越高，开发人员的素质要求越高，质量检测及保证工作代价开销越大。
精益求精只适用于靠近核心的代码层；而对于外围代码层,可酌情适当降低代码质量，放松测试条件。
验证确认，全程质量控制
质量控制是确定项目结果与质量标准是否相符，并及时纠正产品缺陷的过程。
质量控制的主要手段是验证与确认:
验证是从开发者的视角来检查是否正确地构造了产品，而确认则是以用户的视角来检查是否构造了正确的产品。
事实证明，具有清晰开发模式及过程管理规范的软件产品，在质量上要明显超过那些没有明确过程模型及规范指导的软件产品。
软件工程理论提出了诸多开发模型，如瀑布模型、喷泉模型、增量模型、快速原型模型、螺旋模型、迭代模型等，当前最常用的大型软件开发模式是螺旋式的增量开发方式（如图1所示）。
图中1〜7是各阶段的输出点，也是质量控制点，有相应的输出文档和阶段性成果，均需要得到质量保证部门的确认。
软件项目中最常用的质量控制工具手段，包括评审（技术评审、代码评审、设计评审、同行评审等）、审查、测试验证（黑盒测试、白盒测试、单元测试、集成测试、确认测试等）、抽查、调查、走查、旁站、缺陷跟踪等。
技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的，分为正式技术评审（FTR）和非正式技术评审（ITR）两种，该方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。
需要重点指出的是，同行评审是一种特殊类型的技术评审,由与产品开发人员具有同等背景和能力的人员对产品进行技术评审，非常有利于发现产品中潜在的问题。
成功的同行评审是提高质量和生产率的重要手段，评审的对象应该包括所有软件开发的中间和最终工作产品。
引入工具，复用成功模式
质量管理是可以通过信息化手段量化的，采用先进的质量管理工具可以极大地提高质量管理水平。
例如：
Bugzilla是Mozilla公司提供的一个开源的缺陷跟踪工具，在全世界拥有大量用户。
它能够为软件组织建立一个完善的缺陷跟踪体系，包括报告缺陷、查询缺陷记录并产生报表、处理解决缺陷等。
质量和缺陷是一对无法化解的矛盾,想要提高质量必须千方百计地减少缺陷。
有三种方法可以减少缺陷产生的频率、数量、规模等级。
1.事前预防：
在开发过程中始终要考虑工作成果可能产生缺陷，将高质量内建于开发过程之中。
主要措施包括提高技术水平和规范化水平，也就是练内功，通称为“软件过程改进”。
2.事中控制：
及时对各个阶段的工作成果进行质量检查，找出并消除其中的缺陷。
这种方式实践效果较好，已经被企业广泛采用，主要措施是技术评审、软件测试和过程检查。
3.事后补救：
当软件产品正式交付到用户手中投入生产经营时发现了重大缺陷（如系统常常崩溃、运行速度极慢、报表统计错误等），然后再进行修改维护。
这实质上反映出软件项目管理中存在较大的缺失和漏洞，建设单位、承建单位、监理单位三方都有不可推卸的责任，应规避这类水平低级、后果严重、影响恶劣的失误再次发生。
复用是在软件开发领域提高软件质量的重要方法之一。
被复用的对象往往是经过反复使用验证的，自身具有较高的质量，因此，合理化复用有利于提高质量、提高生产率和降低成本，技术开发活动与管理活动中的任何成果都应尽量被复用，如思想方法、经验、程序、文档等。
软件质量管理的最终目的除了能够不断持续改进之外，还在于形成有特色、有成效、可操作的质量管理模式，并最大程度地复用。
协同合作，三权分立
由于软件质量管理的专业性和复杂性，软件项目组织建设上应实行“设计、检验、监管”三权分离、鼎足而立的原则：
设计部门专攻软件需求分析、规划设计、系统研发工作;检验部门从事系统测试（性能测试、回归测试等）；质量监管部门制定质量管理工作计划，对各部门的质量管理工作提出指导建议，跟踪、内审、改进质量体系的运行。
技术评审、测试和质量保证是提高软件质量的三个重要法宝，但三者在作用上各不相同。
技术评审与测试关注的是产品质量而不是过程质量，两者的技术强度比质量保证要高得多。
技术评审和测试能弥补质量保证的不足，三者是相辅相承的质量管理方法。
我们在实践中不能将质量保证、技术评审和测试混为一谈，也不能把三者孤立起来执行。
建议让质量保证人员参加并监督重要的技术评审和测试工作（大约占其工作量的30％左右），只有这样他们才能更深入地了解软件的质量问题，把三者有机地结合起来，做到三位一体，全方位堵住质量缺陷的漏洞。
在部门职能规划上，质量保证部门具有充分的权力，可以对质量不合格的工作成果做出处理，只有这样质量保证工作才不会被轻视，才更有助于加强全员的质量意识（质量保证过程域的主要活动如下图2所示）。
和谐管理，做好一把手工程
当前很多软件企业都组建了质量保证部门，出台了质量保证制度，然而软件质量并未得到实质性突破，质量保证人员也没有发挥预期的效果，造成这种情况的常见原因有两个:
一是软件开发团队管理过程不够规范；二是企业领导者,尤其是最高领导者（即“一把手”）重视程度不足，措施不到位。
调查结果表明，在软件项目中，质量保证人员往往是最“吃力不讨好”的一族，通常没有实质性权力，项目成功功劳属于别人，自己缺乏成就感，项目失败却担负最多的责任。
鉴于这种情况，领导层一定要从根本上重视、爱护、支持质量保证工作，充分发挥组织协调作用，体现人文关怀，运用管理艺术，构建和谐团队，让每一个项目组成员都树立较强的责任感、归属感和大局意识。
事实上，软件开发工程是典型的“全员参与工程”、“一把手工程”，没有企业“一把手”的知情、重视、认可和支持，软件项目顺利实施和取得实效根本无从谈起。
有时候企业领导层对于软件质量保证的作用往往是决定性的，这是任何技术手段都无法替代的。
链接
软件质量管理常见误区
误区一:
软件质量是可以精确测量的。
软件的质量属性很多，如正确性、健壮性、可靠性等，但在大多数用户看来，实用、适用、好用的软件就是成功的。
成功的软件通常都会在功能、性能、界面、操作等方面，以最简捷有效的方式满足用户的最紧迫、最直接的需求。
质量是一个相对的概念，软件产品质量没有国际通用的评价标准，质量目标的弹性较大，没有绝对合格或不合格的界限，软件不可能做到“零缺陷”，有缺陷的软件仍然可以使用。
误区二:
企业软件的质量越高越好，最好是“零缺陷”。
商业目标决定了软件的质量目标。
软件的质量评价也不能从纯粹的软件工程、软件商品、软件技术的角度去考量。
理想的软件质量目标不是“零缺陷”，而是恰好能够满足应用需求、生存发展、市场竞争需要，并且将提高质量所付出的代价控制在预算之内。
一味追求高质量代码，把质量目标凌驾于赢利目标之上，是多数技术人员所犯的常见错误。
误区三:
通过ISO9001、CMM3级认证就意味着软件质量一定有保证。
当前很多通过CMM3或者ISO9001质量认证的软件企业在软件项目管理上的确更加规范了，但代表核心竞争力的软件质量驾驭能力并未得到实质性的提升。
产品生产过程与产品质量存在一定的因果关系，通常好的过程产生好的产品，而差的过程将产生差的产品。
实践证明，软件质量保证并不能绝对保证软件质量，质量保证只能检测出哪些不符合既定程序规范、肤浅的软件缺陷，对于潜藏在软件深处符合既定设计规范的缺陷却显得无能为力。
仅靠制度、规范、流程是无法全面识别出软件中的潜在缺陷的，质量保证对于保证质量而言只是必要的手段，而不是充分的手段。
误区四:
拥有充足的人力资源，软件质量就有保障。
软件开发并不一定是人多力量大，相反，人力资源配置不当反而会延误工期。
不同人员的水平和素质差异较大，软件项目增加新人可能会增加新的缺陷，无益于软件质量提升。
软件开发是一种智力创新活动，任何程序员都无法避免缺陷的发生，缺陷发生是必然的，程序员首先必须了解决定软件质量的各个关键因素（如成本、进度、可靠性、安全性等），搞清楚质量控制的目标和计划，然后才可以在进行需求开发、系统设计、编程测试时确保交付软件的高质量。
软件质量管理论文:
基于过程性能模型的软件质量管理过程的研究与应用
摘要:
软件产品的质量在很大程度上受到软件开发过程的影响。
为了提高竞争力、改进质量以及提高效率,软件企业就需要将更多的注意力放在过程上,通过过程控制其结果。
本文对软件质量管理过程进行了研究,通过过程性能基线和过程性能模型分析和管理质量,提出了一个基于过程性能模型的软件质量管理过程模型,并在研究的基础上,构建了软件质量管理系统的体系结构。
关键词:
软件质量管理过程性能基线过程性能模型
1引言
随着软件产业的飞速发展,软件的核心竞争力主要集中体现在质量、成本和交付工期上,而质量是最显著影响其它两方面的因素。
对软件企业来说,质量不再只是争夺市场的一个有利因素,而变成了公司在竞争中成功的必要条件。
然而,随着软件规模和复杂度的增加,软件开发过程越来越难以控制,导致开发过程中的产品质量和过程质量处于失控状态。
过去存在着一些片面的观点,认为先进的工具和方法可以神奇地解决软件开发中的质量问题。
目前的现实并不尽如人意。
有的企业由于缺乏对开发过程的控制,往往很难平衡客户和公司在质量、成本和交付工期的要求,成功的项目比例很小。
面对如前所述的现状,软件质量管理一定要面向预测式管理。
一个软件产品的质量主要是由它的开发、采购和维护过程决定的,为了改进软件产品的质量进而提高竞争力,就要把焦点放在能够稳定地开发优质产品所需的过程上[1],通过过程数据预测和控制结果。
过程性能模型重点强调过程和产品度量对结果的重要性,分析和建立过程和产品度量与结果的关系。
其通过过程性能基线控制过程的关键因子,分析过程的性能偏差,进而预测并控制最终结果。
由此可以看出,过程性能模型是解决上述问题的有效方法,本文将关注基于过程性能模型的软件质量管理过程。
本文首先归纳了软件质量和软件质量管理的研究现状,并指出了现有软件质量管理过程所存在的问题;随后引入了过程性能基线和过程性能模型,提出了基于过程性能模型的软件质量管理过程模型,阐述了过程性能基线和模型在质量计划、质量活动、质量度量和分析、质量预测和控制、质量评价和改进等五个质量管理子过程中的应用;最后在研究的基础上,构建了软件质量管理系统的体系结构,包括组织过程资产库,过程支持和软件质量管理三个子系统。
2软件质量及管理
当前业界已将交付软件的缺陷密度作为软件产品的质量的衡量关键标准。
即,已交付软件中每个单位规模的缺陷数,简称为交付缺陷密度。
因此,软件质量管理通常围绕缺陷而展开,软件项目的目标是使交付的软件存在尽可能少的缺陷[2]。
质量管理的任务是计划恰当的质量活动,然后正确执行和控制这些活动,以便可以在软件开发过程中（即在软件交付以前）检测到大多数缺陷[2]。
质量管理包括确定软件的质量目标,制定实现这些目标的计划,并监控和调整软件计划、软件工作产品、活动和质量目标,以满足客户和最终用户对高质量产品的需求和愿望。
质量管理基于机构、客户和最终用户的需求建立软件产品的质量目标。
为实现这些目标,机构制定相应的策略和计划,项目则为实现这些质量目标对其定义的软件过程进行具体调整[3]。
在软件质量管理过程和方法上,传统的包括:
全面质量管理（TotalQualityManagement,TQM）是一套能控制质量、提高质量的方法;在PMBOK[4]中,软件项目的质量管理是指保证项目满足其目标要求所需要的过程,包括质量计划、质量保证和质量控制三个过程域;著名的“Juran三部曲”[5]――TQM的理论基础和基本方法的主要基石――包含质量计划、质量控制和质量改进三个步骤,突出了对过程改进的支持。
最有成效的要属六西格玛质量管理方法,其理念是通过排除和预防缺陷来提高客户满意度,进而提高企业的收益率,包括过程性能度量集、多种改进框架和分析工具,尤以DMAIC框架（定义-度量-分析-改进-控制）最常用[6]。
将六西格玛与CMMI实施相结合将是更有效的过程改进途径。
在软件质量管理工具方面,Ishikawa提出了质量控制的七种基本统计工具[7],包括因果图[8]、Pareto图、直方图、控制图、散布图、运行图、检查单。
目前也有许多有关预测模型的论著,如:
Rayleigh模型。
现有的软件质量管理过程和方法提供了质量管理的高层指导,主要关注于实施步骤以及最终结果,质量管理工具也着力于解决质量管理中的具体的某“点”的质量问题和控制,但在如何通过过程控制其结果,业界正在寻求有效的途径,是亟待解决的问题。
例如:
如何制定低风险且切实可行的质量计划、如何在开发过程不同的影响因素下确保项目质量目标得以实现等。
这些正是本文致力于研究的主题。
3基于过程性能模型的软件质量管理过程
过程性能模型是解决通过过程控制其结果的有效方法,具体定义如下。
过程性能基线（ProcessPerformanceBaseline,PPB）是对遵循过程所达到的实际结果的文档化刻画,用于比较实际过程性能和预期过程性能的基准[9]。
过程性能模型（ProcessPerformanceModel,PPM）是对过程属性和过程工作产品之间关系的描述,基于历史过程性能数据而建立,并使用项目中收集的过程度量和产品度量进行校准,最终用于预测遵循过程将能达到的结果[9]。
过程性能基线可用于组织内任何独立的项目,通过分析所收集的度量,建立结果的分布和极差,其刻画了所选过程的预期性能[10]。
过程性能模型基于其他过程和产品的度量来估算或者预测某一过程性能的度量,刻画了过去的和当前的过程性能,对过程将来的性能进行预测。
过程性能基线控制子过程的能力;过程性能模型预测过程的中间目标和最终目标,通过过程控制结果,在子过程结束时进行调整和预测,确保最终目标的实现。
基于六西格玛质量管理的方法及其DMAIC框架（定义-度量-分析-改进-控制）,以及过程管理的四个核心职责（定义过程、度量过程、控制过程、改进过程）,并结合过程性能基线和模型的原理,本文提出了一种基于过程性能模型的软件质量管理过程模型,该模型在质量管理过程中增加了过程性能基线和模型的指导、统计管理以及预测和控制,提供了软件开发过程中进行质量控制和持续改进的框架,如图1所示。
模型主要包括:
质量计划、质量活动、质量度量和分析、质量预测和控制、质量评价和改进。
接下来将详细阐述过程性能基线和模型在上述五个质量管理子过程中的应用。
图1基于过程性能模型的软件质量管理过程模型
3.1质量计划
要生产出高质量的产品,首先必须制定质量计划。
质量计划作为基于过程性能模型的软件质量管理过程模型的一个核心环节,简言之,就是怎样以及何时将质量活动和质量材料应用到一个项目中。
质量计划中必须明确定义在软件开发的各个阶段应如何进行质量活动。
制定质量计划的前提是项目已完成任务计划、进度计划和规模估算,故在制定质量计划之前必须进行入口准则的验证。
基于过程性能模型的软件质量管理过程要充分发挥过程性能基线和模型在质量计划制定时的指导作用。
团队软件过程（TeamSoftwarePro
升级会员 