浅谈软件质量管理.docx
《浅谈软件质量管理.docx》由会员分享，可在线阅读，更多相关《浅谈软件质量管理.docx（23页珍藏版）》请在冰豆网上搜索。
浅谈软件质量管理
浅谈软件质量管理[1]
随着信息技术的广泛应用，软件已成为大多数产品的重要组成部分，如何提高软件质量，使软件更好地服务于各种应用需要，已成为各行各业广泛关注的课题。
本文介绍了软件质量概念和软件质量管理的内容。
针对软件的特点，并提出了加强软件质量管理的必要性。
一软件质量的定义
软件质量：
即国际化标准组织ISOISOIEO9126中将软件质量定义为反映软件产品满足规定需求和潜在需求能力的特征和特征的总和。
Fisller将软件质量定义所有描述计算机软件优秀程度的特性的组合也就是为了满足软件的各项精确定义的功能、性能要求合文档化的开发标准需要相应的给出或设计一些质量特性及其组合。
要得到高质量的软件产品就必须使这些质量特性得到满足。
目前对软件质量特性有多种提法但实际上是大同小异。
ISOIEC9126国际标准中定义的软件质量特性为以下六项：
功能性functionality可靠性reiiabilty易使用性usability效率efficiency可维护性maintainability可移植性portability。
二影响软件质量的因素
软件本身的特点和目前软件的开发模式的一些缺陷，使软件内部的质量问题有时不可能完全避免。
1、软件本身的特点软件具有复杂性、一致性、可变性和不可见性。
软件规模的增大，导致它的复杂程度大大增加，并且让整个开发工作变得难以控制和管理。
如果说编写一个数十行到数百行的程序连初学者也不难完成，那么开发一个数万以至数百万行的软件，其复杂度将大大上升，即使是富有经验的程序员，也难免顾此失彼。
例如，开发一个学生上机考试系统，需要根据实际情况考虑到不同专业、不同考试科目、不同层次的用户的使用，其复杂性是显而易见的。
尤其糟糕的是，软件的可靠性往往随规模的增长而下降，质量保证也越来越困难。
2，开发环节多根据传统的瀑布模型将软件的生存周期划分为：
计划时期的问题定义和可行性研究；开发时期的需求分析、概要设计、详细设计、编码和测试；运行时期的维护。
各个阶段之间具有顺序性和依赖性。
在这里，顺序性有两重含义：
第一，只有等前一阶段的工作完成以后，后一阶段的工作才能开始。
第二，前一阶段的输出文档，就是后一阶段的输入文档。
想在后阶段获得正确的结果，必须在前阶段有正确的输出。
因此，如果在生存周期的某一阶段出现了问题，往往要追溯到在它之前的一些阶段，必要时还要修改前面已经完成的文档。
3、选择支持工具目前软件开发工作大多是手工操作，借助工具自然可以提高效率，减少出错机会。
但是，在软件的整个开发过程中，能够得到的开发工具或管理工具十分有限。
Pasca、G语言、G++、VisualC++、Delphi、Java等都可以作为开发工具使用，在面临具体问题时，要根据各种语言自身的特点和开发人员的熟练程度，灵活机动地选择。
4，测试的局限性目前在软件开发过程中质量保证的主要手段是测试。
广泛采用的仍然是白盒测试和黑盒测试。
而软件测试的局限性在于，虽然它能够帮助我们尽可能多地发现软件中隐藏的问题，但是，有一些错误仍然存在，因为测试本身也是有缺陷的，不是尽善尽美的。
也就是说，我们通过测试，可以在一定程度上把错误减少到最低限度。
三、软件质量管理方法
由于软件是一种技术密集的、智力劳动的产品，一般软件具有实用性、抽象性、灵活性、复杂性、无磨损、不老化等特点，特定软件还具有高安全性、高可靠性、适应性强、实时性要求高等特点。
软件的生产与硬件也不同，软件没有明显的制造过程，软件的开发至今仍不能自动化地进行而以人工开发方式为主。
针对软件的特点，对软件的质量控制，更应该注重软件过程的控制，通过完善质量管理体系以适应软件质量管理要求和加强软件过程管理来实现。
浅谈软件质量管理[2]
1、软件质量管理体系软件及软件质量形成与硬件有明显的差别，因此软件质量管理要求与硬件质量管理要求也有所不同。
基于目前产品主要承制单位按照9000标准要求建立质量管理体系的实际，为了提高质量管理体系对软件质量管理的适应性，确保软件开发质量，根据软件的特点，对于承担软件研制的承制单位，应在现有质量管理体系的基础上，补充完善软件质量管理要求，以确保软件质量满足要求。
与此同时，根据软件质量形成的特点和软件作为产品管理的理念还没有得到普遍接受的实际，在质量管理体系建设中还要采取以下方法以强化软件的质量管理：
（1）建立标准软件过程。
标准软件过程是指承制方定义的基本软件过程，它描述基本的软件过程单元以及这些软件过程单元之间的关系，用它来引导建立项目软件过程。
（2）纳入项目计划。
软件应作为相应项目的配套产品纳入项目研制计划和产品配套表。
（3）管理开发和验证环境。
应确定、提供并维护软件开发和验证环境（工具、技术和方法），验证环境也应按质量管理标准有关监视和测量装置的控制要求进行控制。
（4）控制采购软件。
对采购的软件产品也应按照质量管理标准有关采购的要求进行控制。
2、软件过程管理方法
（1）软件给定需求控制给定需求，即“指定给软件的系统需求”，是系统需求的一部分，以文档形式给出。
（2）软件质量策划对具体的软件项目，承制方应根据软件项目的特点，策划和实施与质量有关的活动，软件质量策划应与质量管理体系其他过程的要求相一致。
（3）软件维护 根据合同的要求和策划的安排，对交付和安装后以及运行过程中的软件进行维护，维护活动结束应保持软件的一致性。
（4）软件开发策划对软件的开发进行策划和控制，应根据承制方的标准软件过程，通过策划确定项目软件过程编制项目开发计划。
（5）软件配置管理配置管理提供一个标识、控制和追踪每个软件项的正式版本的机制，以保证软件项目生成的产品在软件生命周期中的完整性。
（6）软件开发控制 软件开发应在受控条伴下进行，按选定的开发文档标准编制文档。
四加强软件质量管理的途径
软件企业可以通过多种途径加强质量管理，提高软件产品的质量。
1、重视质量管理 我们都知道，在工业生产中，即使有先进的设备与技术，管理不善的企业也不能获得良好的经济效益。
对于软件生产，不能按时按质完成计划，其中管理混乱往往是一条重要原因。
我国软件开发机构的管理相对比较薄弱，其中质量管理尤其显著，这与我们重技术、轻管理有关。
为了做好软件质量管理工作，首先要从认识上转变过来，因为思想往往是行动的先导。
2、开发小组的人员应该少而精 软件的质量依赖于参与开发工作人员的质量和数量。
开发过程，提高软件产品质量。
近年来，采用面向对象的开发技术、原型开发方法、三层结构、软件构件、软件复用、分布计算、Agent等方法，取得了一定的效果。
除此之外，还有一种净室开发技术，其基本思想在于“净化”软件开发过程，使得差错或缺陷不可能有机会混入开发过程。
如果软件的需求可以用形式描述方法方便地表达出来，那么整个开发过程就会像公式推导那样严谨、无懈可击。
总之提高软件质量势在必行，只有认识到软件质量的重要性，了解影响软件质量的因素，才能有的放矢，采用科学的管理技术和先进的技术方法，才可以确保软件的质量。
软件开发各阶段的质量控制[1]
提到软件开发，我们的脑海里总是浮现出这样的情景：
开发组的每一位成员都在辛苦的工作，有的加班加点，甚至通宵达旦是常有的事，虽然项目经理修改了一次又一次的进度计划，而实际的开发情况却总是很令人担忧，以至于每次向领导汇报工作的时候总是觉得以前制定的计划没有很好的完成，总是觉得人力资源不够，总是觉得我们没有太多的时间。
等到代码终于开发完成了，测试进度却又非常令人担忧，每一个小BUG都要花很长的时间去查找，改了某一个小错误却又引起了很多错误，结果产品发布遥遥无期，而项目组里的每一位成员已经筋疲力尽。
怎样摆脱这样的困境呢？
为何软件开发项目管理这么困难呢？
为何我们做的计划总是不能按时完成呢？
为何软件开发不能像硬件开发那样可以控制呢？
原因在于软件开发完全靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定的、可以变化的因素，我们怎样把握住这些变化因素呢？
就像我们题目所说的一样，软件开各阶段的成果质量管理，如果我们能够很好的控制软件生命周期每一个阶段的质量，也就很好的控制了整个软件开发的整个过程。
软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产物，就是将大脑里无形的看不见摸不着的思维变成一个可以看到的，可以解决实际问题的一组界面或者组件。
这样的一个复杂的过程，质量应该如何保证呢？
有人想到了ISO9000、CMM，也有人很反对，说应该用敏捷开发。
其实，不管用什么样的开发过程，关键是找到这些过程的真谛，有些人说，ISO和CMM到中国来就变了味了，为什么变味儿了呢？
其实我们只学到了该做什么，却不知道怎样去做，为什么要这样做？
大家都知道做软件开发需要写需求规格说明书和设计文档，为什么要写，文档的重要性有多高？
没有资深开发和管理经验的人员可能很难理解其重要性，如果只是简单的形式上去写一篇这样的文档，对后面的编码和测试没有实际的指导作用，甚至起了“误导”作用，同样会引起大量返工，那么这些文档除了负担之外就没有其他用途了，要知道写这些文档是需要消耗项目组资源的（进度、成本…）。
很多人又想到了测试，觉得是我们测试的力度不够，所以我们产品质量不过关，其实，软件开发的质量保证从开发最初就应该开始了，如果到了测试阶段才重视就已经晚了。
软件产品开发过程，不管采用瀑布式还是迭代式，都离不开需求、设计、编码、测试这几个阶段，在迭代式开发中，这几个阶段也是周期性出现的。
怎样把握好每个阶段的质量，确实不是一件容易的事，本期重点介绍一下需求、设计和编码阶段的成果质量，当然以后会共享一些过程质量方面的知识。
1、需求
我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。
如果对UML（unifiedModelingLanguage）
比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是UML可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解UML各种图形的意思。
除了工具之外，我们可以从以下几个方面来保证需求描述的质量。
软件开发各阶段的质量控制[2]
1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。
2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。
3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。
4、另外注意引用的术语和词汇是否前后一致。
5、是否存在一些形容词、比较性词语，比如：
容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。
另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。
那么我们怎样才能判断需求细化的程度呢？
需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢？
哪些需求又太粗了呢？
答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。
2、设计
软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：
用户、项目管理人员、程序员、测试员、维护人员等等。
不同的角色对架构设计的要求也不相同。
例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少？
对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。
对于维护人员来讲系统的扩展性、可维护性如何？
一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。
正是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。
一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：
1）、功能性：
包括完全性、正确性、安全性、兼容性、互用性。
完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。
正确性包括需求一致度。
安全性根据软件需求的不同有不同的安全性要求。
2）、效率：
包括产品运行的时间效率和利用的硬件资源两方面来考虑。
3）、维护性：
包括架构的可改正性，可扩充性以及可测试性。
如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。
4）、可移植性：
包括硬件的独立性、软件独立性、可安装性、可重用性。
软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。
5）、可靠性：
包括缺陷数量、容错性、可用性。
软件开发各阶段的质量控制[3]
6）、使用性：
包括可理解性、易学习性、可操作性、易沟通性。
我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。
因此在软件的可使用性也是非常重要的。
3、编码
代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。
如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。
类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的public方法太多也会导致类之间的高耦合性增加。
也许有的程序员会认为写出可读、规范的代码会影响工作进度。
的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作
周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长时间才读懂。
况且如果随着人员的调动等其他原因，往往维护代码的程序员已不是当初写代码的人，很多情况就是读懂了一段糟糕的代码还比重新写出一段代码花费的时间还长，严重影响工作效率（有些时候还影响维护人员的心情），反过来，如果大家都讲究把代码写成规范可读的，无疑对于整个组织来说提高总体工作效率是非常有用的。
代码质量另一个非常重要的衡量手段就是测试，通过统计测试代码所产生的缺陷情况，如严重等级分布、缺陷曲线的变化等可以从一个方面来简单地评估代码质量。
软件项目质量管理三部曲
质量目标+质量控制+质量保证
质量目标：
提出软件质量的特性和明确的可测量的标准。
它包含的动作有合理正确的解读需求，确定测试范围和测试内容，制定具体的测试准则。
这部分内容一般由质量部门完成。
我们后续做的软件测试工作，其实就是把执行的结果和预期设定的目标进行比对，符合的认为有质量的，不符号的则是错误的。
质量控制：
为了保证每个工作产品都能满足需求而进行的一系列的审查，评审和测试的工作。
审查，评审主要针对需求的正确性，它属于设计质量的范畴；测试主要针对需求实现的功能，是一致性质量的范畴。
我们可以把软件质量按照特征分为两类，设计质量和一致性质量。
设计质量是设计者所规定的产品的特征，包括需求说明，产品规格说明和设计说明；一致性质量是具体实现的问题，也就是编码所实现功能。
其实目前我们所做的主要工作就是质量控制阶段的测试部分，让它独立的去承担质量的风险，而我们所测试的基本都是一致性质量，对于设计质量很少涉及。
那么我们应该怎么去测试设计质量，由什么职能的人员和部门去完成，都是需要思考的。
质量保证：
质量保证由评估质量控制活动有效性和完整性的一系列审核和报告所构成。
其目的是为管理层提供了解产品质量所必须得测试数据，从而获得产品质量是否符合预定目标的信心。
此数据也是为持续的过程改进提高了数据依据。
它就是我们通常所说的测试总结和测试报告阶段，但包含的内容应该更丰富。
如何做好软件工程质量管理？
[1]
在实际的项目质量管理中，质量管理总是围绕着质量保证（QualityAssurance）过程和质量控制（QualityControl）过程两方面。
这两个过程相互作用，在实际应用中还可能会发生交叉。
正如引言所述，关于软件的质量，很难下一个非常明确的定义。
本文主要针对软件工程中的质量管理来进行讨论。
做软件“大餐”的工序
软件质量保证（SoftwareQualityAssurance，以下简称SQA）的目的是验证在软件开发过程中是否遵循了合适的过程和标准。
软件质量保证过程一般包含以下几项活动：
首先是建立SQA组；其次是选择和确定SQA活动，即选择SQA组所要进行的质量保证活动，这些SQA活动将作为SQA计划的输入；然后是制定和维护SQA计划，这个计划明确了SQA活动与整个软件开发生命周期中各个阶段的关系；还有执行SQA计划、对相关人员进行培训、选择与整个软件工程环境相适应的质量保证工具；最后是不断完善质量保证过程活动中存在的不足，改进项目的质量保证过程。
独立的SQA组是衡量软件开发活动优劣与否的尺度之一。
SQA组的这一独立性，使其享有一项关键权利——“越级上报”。
当SQA组发现产品质量出现危机时，它有权向项目组的上级机构直接报告这一危机。
这无疑对项目组起到相当的“威慑”作用，也可以看成是促使项目组重视软件开发质量的一种激励。
这一形式使许多问题在组内得以解决，提高了软件开发的质量和效率。
选择和确定SQA活动这一过程的目的是策划在整个项目开发过程中所需要进行的质量保证活动。
质量保证活动应与整个项目的开发计划和配置管理计划相一致。
一般把该活动分为以下五类：
1）评审软件产品、工具与设施
软件产品常被称为“无形”的产品。
评审时难度更大。
在此要注意的一点是：
在评审时不能只对最终的软件代码进行评审，还要对软件开发计划、标准、过程、软件需求、软件设计、数据库、手册以及测试信息等进行评审。
评估软件工具主要是为了保证项目组采用合适的技术和工具。
评估项目设施的目的是保证项目组有充足设备和资源进行软件开发工作。
这也为规划今后软件项目的设备购置、资源扩充、资源共享等提供依据。
2）SQA活动审查的软件开发过程
SQA活动审查的软件开发过程主要有：
软件产品的评审过程、项目的计划和跟踪过程、软件需求分析过程、软件设计过程、软件实现和单元测试过程、集成和系统测试过程、项目交付过程、子承包商控制过程、配置管理过程。
特别要强调的是，为保证软件质量，应赋予SQA阻止交付某些不符合项目需求和标准产品的权利。
如何做好软件工程质量管理？
[2]
3）参与技术和管理评审
参与技术和管理评审的目的是为了保证此类评审满足项目要求，便于监督问题的解决。
4）做SQA报告
SQA活动的一个重要内容就是报告对软件产品或软件过程评估的结果，并提出改进建议。
SQA应将其评估的结果文档化。
5）做SQA度量
SQA度量是记录花费在SQA活动上时间、人力等数据。
通过大量数据的积累、分析，可以使企业领导对质量管理的重要性有定量的认识，利于质量管理活动的进一步开展。
需要说明的是，并不是每个项目的质量保证过程都必须包含上述这些活动或仅限于这些活动，要根据项目的具体情况来定。
SQA计划中必须明确定义在软件开发的各个阶段是如何进行质量保证活动的。
它通常包含以下内容：
质量目标；定义每个开发阶段的开始和结束边界；详细策划要进行的质量保证活动；明确质量活动的职责；SQA组的职责和权限；SQA组的资源需求，包括人员、工具和设施；定义由SQA组执行的评估；定义由SQA组负责组织的评审；SQA组进行评审和检查时所参见的项目标准和过程；需由SQA组产生的文档。
选择合适的SQA工具并不是试图通过选择SQA工具来保证软件产品的质量，而是用以支持SQA的活动。
选定SQA工具时，首先需要明确质量保证目标。
根据目标制定选择SQA工具的需求并文档化，包括对平台、操作系统以及SQA工具与软件工程平台接口的要求等。
如何使白壁“无瑕”
按工序去做也不一定能得到一盘完美的“大餐”，因为火侯等因素实在很难掌握。
万一掌握不好怎么办？
软件质量控制主要就是发现和消除软件产品的缺陷。
对于高质量的软件来讲，最终产品应该尽可能达到零缺陷。
而软件开发是一个以人为中心的活动，所以出现缺陷是不可避免的。
因此，要想交付一个高质量的软件，消除缺陷的活动就变得很重要。
缺陷消除是通过“评审”和“测试”这类质量控制活动来实现的。
缺陷在软件开发的任何阶段都可能会被引入。
项目质量管理过程包含了许多可以识别缺陷、消除缺陷的过程。
“识别缺陷”和“消除缺陷”本来是两个不同的过程，但在这里为了简便统一用“消除”来代表它们。
潜在的缺陷越大，用来消除它所花的费用越高。
因此成熟的软件开发过程在每一个可能会引入潜在缺陷的阶段完成之后都会开展质量控制活动。
这些为了消除缺陷的活动包括：
需求评审、设计评审、代码走查、单元测试、集成测试、系统测试以及验收测试等。
质量控制的任务就是策划可行的质量管理活动，然后正确地执行和控制这些活动以保证绝大多数的缺陷可以在开发过程中被发现。
如何做好软件工程质量管理？
[3]
正如前面提到的，在进行评审和测试时可检测到缺陷。
评审是面向人的过程，测试是运行软件（或部分软件）以便发现缺陷。
在一个项目里，评审和测试活动是预先策划好的（计划书中确定执行哪些质量控制活动和何时执行这些活动）。
在执行过程中，根据已定义好的过程来执行这些活动。
通过执行这些活动来识别缺陷，然后消除这些缺陷。
例如，系统测试过程一般包括制定测试计划，测试计划中应列出在测试执行过程中所有的测试用例，评审测试计划，并且最终执行测试计划。
软件质量之路-软件质量框架[1]
软件质量的重要性是不言而喻的，但是当所有人都意识到它的重要性的时候，却很少有人能够清晰的描述出如何才能够提高软件质量。
软件质量框架的目的就在于提出一个评价的原型，帮助我们分析一种方法和技术是否能够提高软件质量。
本系列文章分日构建、测试驱动开发、建立核心框架、面向组件的大规模软件架构来进行深入分析。
什么才是一个高质量的软件
在讨论软件质量原型之前，我们先回答第一个问题。
一个软件之所以被认定为质量优秀，并不是因为它获得了一个省级或部级奖，而是它的内在具备了这样一些特性：
满足用户的需求。
这是最重要的一点，一个软件如果不能够满足用户的需要，设计的再好，采用的技术再先进，也没有任何的意义。
所以这一点非常的朴实，但却是软件质量的第一个评判标准。
合理进度、成本、功能关系。
软件开发中所有的管理都是围绕着这几个要素在做文章的，如何在特定的时间内，以特定的成本，开发出特定功能的软件。
三者之间存在一种微妙的平衡。
在PlanningXP一书中，专门有一个章节讨论它们。
一个高质量的软件的开发过程中，项目成员一定能够客观的对待这三个因素，并通过有效的计划、管理、控制，使得三者之间达成一
升级会员 